How to catch duplicate casino player profiles before they reach loyalty campaigns

Build a crosswalk between approved player IDs from each property and channel. Apply exact matches only when the identifiers and policy support them, then send conflicts to a steward. Publish a certified view that carries source lineage and contact restrictions through to loyalty, reporting and campaign tools.

Make identity and permission separate decisions

A duplicate profile can split visits and rewards across two records. A false merge can attach someone else’s history or preference to a player. Define which system owns identity, contactability, tier and points separately. Store each source ID with its source namespace and dates. If two feeds disagree about whether a member can be contacted, apply the approved restrictive rule or hold the record for review.

Konami describes a one-card deployment connecting three Golden Entertainment locations and an architecture that shares status changes between properties. Those are examples of the operating need for shared identifiers and current restrictions. Each property still needs its own decision on data rights and matching rules. Golden Entertainment deployment · SYNKROS OneCard architecture

Build the crosswalk and exception queue

What to automate

Inventory the player feeds and their permitted uses

Create a source register with the property, namespace, approved keys, allowed fields, delivery schedule and freshness target. Record which destinations may use each field. When an extract arrives, record its version and compare row counts and coverage with the contract. Mark a late or incomplete feed so affected players can be held from downstream use. The governance owner approves each source and field before it enters the shared view.

Validate rows before attempting a match

Check unique keys within each source namespace, required identifiers, accepted status values and effective timestamps. Keep rows with missing keys, duplicate source keys or invalid permissions in a quarantine file with source IDs and reason codes. Route the error to the owner of that feed and preserve the last accepted version where the release policy allows it. Report accepted, quarantined and missing counts independently for each source.

Link only verified profiles and queue uncertain matches

Look up each source ID in the accepted crosswalk first. Apply exact matches only against the verified identifiers allowed by the policy. Send conflicting verified IDs and weak signals such as shared contact information to the steward with the underlying evidence reference. Keep both records separate until an authorized decision. Record the decision, reviewer, effective time and crosswalk version so the merge can be reversed.

Publish the certified view for each destination

Create an output per authorized use. Include the approved crosswalk fields, version and status freshness, then attach current contact eligibility only to destinations that are allowed to receive it. Apply approved restrictive handling or hold when source statuses conflict or are stale. Reconcile counts back to accepted source rows and confirm unresolved records stay out of the affected destination. The data owner signs off on release rules.

Confirm changes and corrections reached their consumers

Track restriction updates, merges and reversals as versioned events. Rebuild affected views on change and record the received version from each downstream destination. Alert the owner when an audience or reporting job still uses a stale version. Preserve both old and corrected mappings and replay affected downstream outputs as authorized. Review false matches and recurring source defects with the steward.

Use code to enforce source keys, required fields and release rules. A similarity model can suggest which ambiguous pairs to review. Shared addresses, household email accounts and spelling similarity can produce convincing false matches, so keep reviewer approval on uncertain pairs.

Check four cases in a small synthetic dataset

Measure duplicate and unmatched records, reviewer-confirmed precision, time to resolve conflicts and suppression propagation lag. Test downstream loyalty reporting and audience exports separately. They may use the same accepted identity mapping with different data permissions.

Implement matching and review as separate transactions

Use a staging record at source_system × source_player_id × revision and a link table at source_system × source_player_id × canonical_player_id × effective_period. Add an immutable review history with reviewer, action, rule version and evidence references. Keep identity material scoped to authorized reviewers.

1. Normalize fields with versioned rules and retain originals. Match exact authoritative keys before creating fuzzy candidates. Keep ambiguous, missing and conflicting identifiers in the review queue. A near match can suggest a candidate without granting permission to merge.
2. Produce one proposed link change with a version precondition for each approval. Protect exclusions, consent, balance and status from being silently overwritten. Store link history so a mistaken merge can be undone without losing transaction attribution.
3. Run verification immediately after each accepted merge. Recompute owner-approved totals and record unmatched transactions. Rebuild only the consumers dependent on the changed identity link and deliver versioned corrections through the normal release path.
4. Replay the same correction, test two people with similar names and distinct official IDs, and test a profile with a missing consent value. Expect one review action per version, no automatic merge on name alone, and a separate unknown state for consent.

def decision(source_id, target_id, has_other_conflict):
    if not source_id or not target_id or has_other_conflict:
        return "review"
    return "link candidate" if source_id == target_id else "keep separate"

assert decision("P-1", "P-1", False) == "link candidate"
assert decision("P-1", "P-2", False) == "keep separate"
assert decision("P-1", "P-1", True) == "review"

Implement the work step by step

Use immutable source identities and a reversible crosswalk. Link records with approved exact rules. Route ambiguous matches and restrictions to a steward, and reconcile each publication receipt.

1. Set access and ingest

• CAS-03.01.01 Approve source contracts and lineage. Validate versioned contracts and access scopes. Read Casino management, loyalty and permitted destination schemas. Record Approved source/consumer contracts. Owner Data owners approve field access and source handoff. Check Fields outside the consumer's approved scope fail publication.
• CAS-03.01.02 Check extract coverage and freshness. Compare manifest counts, schema, freshness and missing permissions. Read Source extracts and event feed manifests. Record Validated inputs or held batch to matching. Owner Analyst requests corrected feeds and marks affected destination hold. Check A stale required identity or restrictions extract leaves the affected batch on hold.

2. Validate and match

• CAS-03.02.01 Normalize and check source keys. Enforce unique keys, idempotent events and source precedence. Read Validated player IDs, namespaces and source status history. Record Accepted records and quarantined defects. Owner Engineer owns schema drift or missing key remediation. Check The same source ID in two namespaces produces two separate source records.
• CAS-03.02.02 Generate crosswalk candidates. Exact match and optional similarity shortlist with evidence features. Read Verified identifiers and historical crosswalk. Record Confirmed links and conflict queue. Owner Steward handles ambiguous identity and exceptions. Check Two conflicting verified links create a steward case and no automatic merge.

3. Review and certify

• CAS-03.03.01 Resolve ambiguous matches. Prioritize and display evidence. AI may explain similarity only. Read Candidate pairs and permitted source evidence. Record Versioned stewardship decision and lineage. Owner Steward approves ambiguity and unmerge. Prohibited attributes excluded. Check An ambiguous match stays separate until an authorized steward records a disposition.
• CAS-03.03.02 Reconcile restrictions and release. Hold stale/missing restrictions and validate restricted fields by destination. Read Crosswalk and authoritative permission statuses. Record Certified versioned output for CAS-01 and analytics. Owner Governance approves overrides and conflicting restrictions. Check A stale or conflicting restriction blocks activation until the approved policy resolves it.

4. Distribute and maintain

• CAS-03.04.01 Verify downstream application. Compare destination acknowledgment and audit update lag. Read Certified identity view, audience extract and delivery receipt. Record Delivery accepted or notification on hold. Owner Operations investigates failed propagation with destination owner. Check An acknowledgment for the prior revision leaves the current publication incomplete.
• CAS-03.04.02 Apply correction and verify unmerge. Rebuild impacted links and confirm downstream version without overwriting history. Read Reported identity error, historical changes and downstream uses. Record Corrected view and downstream acknowledgment. Owner Steward authorizes correction and verifies against source evidence. Check Undoing a mistaken link restores each affected identity and reconciles new receipts.

Build it yourself with AI

Create synthetic profiles.csv, steward_decisions.csv and status_events.csv with made-up property and player IDs. Put namespace ownership, verified match fields, release rules and permitted destinations in identity-playbook.md. Use fake contact tokens in place of contact information. Use SQLite to keep crosswalk decisions and status history between runs.

Build a Python and SQLite prototype for these synthetic feeds. Uniquely key
records by namespace and source ID. Quarantine invalid inputs with reason
codes. Apply an exact link only when the supplied playbook verifies the key.
Keep weak or conflicting matches separate and emit candidate_pairs.csv with
the evidence IDs and reason. Record decision and crosswalk versions.

Use four fake profile rows. Two share one verified cross-property key and should link. Two share contact token HOUSE-1 but have different verified keys and should stay separate. Add a new suppression on one accepted record and verify that its campaign export is held even after replaying an older event.

Generate tests for an approved exact link, a shared-contact collision, a new
restriction arriving ahead of an older event and a steward reversal. Assert
two distinct profiles stay separate until explicitly approved. Test a
destination acknowledgment with an older crosswalk or restriction version
and report the stale feed. Keep prior decisions and input rows available
after an unmerge. Produce candidate exports only.

If AI is used to prioritize the review queue, give it opaque evidence IDs and synthetic signals. Ask it for a reason and the signals it used. Keep its output as a queue suggestion and let the steward see original source evidence through the approved interface. Pilot with one feed pair and verify reviewed match precision, restriction lag and correction delivery for loyalty and reporting separately.

Need help automating this?

Explore the related casino workflows for matching player activity, reviewing exceptions and delivering checked records. Explore Mage's casino player data workflows.