What this screen is for
Use Identity Graph Control to check whether the Identity Graph integration is ready, update the system settings that control sync, preview possible tag matches, run a bounded suspicious-user lookup, and watch the latest Identity Graph backfill status.
This page is a control surface, not the main backfill runner. Starting and stopping historical backfill jobs remains on Identity Graph Backfill.
Who can open it
Access is limited to a named administrator allow-list. If the current admin is not allowed, the page shows a warning and does not load the control data. The backend enforces the same restriction, so a hidden link alone is not enough to read or update the configuration.
How to read the Overview tab
The top cards answer four operational questions:
Config: whether the required settings are present.Health: whether the configured Identity Graph endpoint responds to a backend health check.Merchant: which merchant code/name will be used for sync.Tags: how many tag codes are allowed to sync and which match signals are enabled.
The Sync capabilities chips show what the current configuration enables:
Usersis on when URL, API key, and merchant code are present.Customersis on only when the integration is configured and merchant id is set.Tagsis on only when the integration is configured and the tags-to-sync allow-list is not empty.Payment evidenceis on only when the integration is configured and the payment-evidence toggle is enabled.SuspiciousPatternis on only when the integration is configured andEnable SuspiciousPatternis on. This chip reports configuration readiness, not whether any player currently matches the policy.
Sync Config tab
This tab updates Identity Graph system settings. The API key is write-only from the page: leaving it blank keeps the existing encrypted key, while entering a new value replaces it.
Important configuration fields:
Identity Graph URL: base URL used by backend calls.API Key: secret key used by backend calls to Identity Graph.Merchant Code: merchant code used in Identity Graph payloads and match requests.Merchant ID: required for customer sync readiness.Merchant Name: readable merchant label shown in results.Tags to sync: comma-separated allow-list of tags that may be sent to Identity Graph.Tag match signals: comma-separated signals used for tag dispatch matching. Supported dispatch values areemail,phone,global_id,payment, andpayout; invalid or empty values fall back toemail.HTTP timeout, ms: backend request timeout. The control service clamps it to a safe range.Collect payment evidence into Identity Graph: enables payment evidence sync only when the base integration is ready.Enable SuspiciousPattern: master switch for the SuspiciousPattern capability. Default: on.Honeypot card deposits: allows an eligible cross-brand card deposit to be stopped before it reaches the payment provider. Default: on.Same-day cross-brand only: requires the source-brand and target-brand activity to match the selected same-day rule. Default: on.Same-day reference: choosesRegistration dateorFirst seen date. Registration date is the default; first-seen date can be useful for accounts imported or backfilled after registration.Failed card threshold: number of failed card deposits, after the most recent successful card deposit, used for source-brand activation. Default:2; the effective value is constrained to1..20.SuspiciousPattern match signals: acceptsemail,uid, andip. Empty or invalid input falls back toemail,uid. IP is evidence-only and cannot trigger the automatic honeypot by itself.
Unsaved changes are local to the browser. While the form is dirty, automatic config refresh is paused so the page does not overwrite the operator's edits.
SuspiciousPattern behavior
The behavior matrix separates three different stages:
- On the source brand, the configured failed-card threshold can create SuspiciousPattern evidence and tag state. The source-brand card attempt still proceeds to its payment provider.
- On another brand, a strong match can activate the card-deposit honeypot. The card form can still open, but the payment initialization is stopped before provider dispatch and the player receives a generic payment-failed response.
- Email and UID/device identity are strong automatic match signals. IP can be retained as supporting evidence, but IP-only, browser-only, user-agent-only, or timing-only similarity must not activate the automatic honeypot.
The payment guard applies only to recognized card deposits. Non-card methods continue normally. If the Identity Graph check itself fails, the guard fails open and allows the payment flow to continue rather than blocking the player on an integration error.
Current save limitation
The page currently sends Same-day reference on every Save configuration attempt, but Core does not yet register that setting. Core rejects the unknown setting and rolls back the complete update, so none of the submitted fields should be treated as saved even if only another field was changed. Until the product contract is aligned, use the generic System Settings page for the five registered SuspiciousPattern settings and verify each effective value after the change.
Tag Preview tab
Use Tag Preview to check which Identity Graph users would match a set of strong signals before relying on tag sync behavior.
Preview fields:
- Global ID / identity UUID
- Device ID
- IP address
- Account ID
- Customer key
- DOB:last name
At least one filter is required. The backend sends a bounded match request and limits the result size, so this is not a global graph scan.
Suspicious Users tab
Use Suspicious Users for the same bounded lookup model when an operator needs a diagnostic grid of possible graph matches. The visible table shows user identity, email, merchant, match signals, creation time, and update time.
This tab does not automatically classify a player as fraudulent. It only displays Identity Graph match rows for the supplied filters.
Backfill Status tab
This tab shows the latest Identity Graph backfill jobs so an operator can see status without leaving the control page. It is read-only for job control:
- start and stop controls remain on
Identity Graph Backfill - this tab can refresh status
- the table shows job key, status, processed count, failed count, skipped count, heartbeat, and last error
Common confusion
- Saving configuration changes system settings; it does not immediately start a historical backfill.
Tagsreadiness requires both a complete connection config and at least one allowed tag code.- Phone, payment, and payout are supported for dispatch matching, but the current preview/search read model supports only the listed preview fields.
- A healthy config does not guarantee every downstream sync has run; check
Backfill Statusand the dedicated backfill page for job progress. - The suspicious-user grid is diagnostic. It is not a decision engine and does not change player status by itself.
Tag match signalsandSuspiciousPattern match signalscontrol different workflows. Changing one does not change the other.- Turning off the honeypot switch does not remove existing tags or evidence; it changes whether eligible cross-brand card attempts may be stopped.