KYC and AML Integration for iGaming: From Provider Results to Safe Decisions

A verification provider returns an approval. Your platform still has to decide which player, legal entity and verification attempt it belongs to, what was checked, whether another concern remains open and which actions may now proceed. Treating the response as a permanent account-wide green flag creates a fragile integration: a late message can undo a review, an identity check can obscure an unresolved sanctions match, and a document-upload success can be mistaken for permission to gamble.

KYC means knowing and verifying the customer; AML means the controls used to prevent and detect money laundering. Identity verification is one input to that wider process. This guide is for product, engineering and compliance teams designing the boundary between providers, the platform and human reviewers. It explains how to turn evidence into controlled decisions, with concrete failure cases and release checks.

Start with the actions your policy must control

Before choosing an SDK or verification tier, agree the operating policy with compliance and legal owners. For each entity, jurisdiction and product, list the actions that need a decision: registration, deposits, gambling, withdrawals, changes to customer details and continued account use. Specify the required evidence, when it is needed, who may resolve an exception and what happens while the result is unknown. Vendor tier names are not a substitute for this policy.

For example, Great Britain's identity-verification condition requires applicable remote licensees to establish identity before gambling. It also limits withdrawal-stage requests for information reasonably obtainable earlier, while preserving requests required then by another legal obligation. Model those timing requirements explicitly; do not transplant them unchanged to every market.

Record policy versions and effective dates. Product owns clear customer journeys; compliance owns the applicable requirements and escalation rules; engineering implements and tests the controls. A queue timeout or a conversion target cannot silently change the policy. The player-verification workflow guide provides related context for the journey, but your integration still needs its own decision boundaries.

AML also continues after onboarding. The Gambling Commission's guidance for Great Britain casino operators describes ongoing scrutiny of transactions and keeping due-diligence information current. Define how transaction-monitoring alerts reach the review workflow; a document check alone does not implement the complete AML programme.

Separate verification evidence, decisions and permission

Use an internal case record that remains stable across provider requests and document resubmissions. Give it an unambiguous customer and entity scope. Keep the provider's applicant identifier, the purpose of the check, attempt identifiers and evidence references alongside it. A retry of an interrupted submission and a fresh attempt with new documents are different events; treating both as a new customer can split the history and create unnecessary charges.

• Evidence: what a provider or reviewer observed, which checks ran, their outcome and when the information was obtained.
• Decision: the operator's assessment under a named policy version, including reason, authority, restrictions and review conditions.
• Permission: whether a particular action is currently allowed for this customer in this context.

Model identity, screening, document completeness and open reviews separately. Useful case states might include awaiting evidence, provider processing, manual review, resolved and needs reassessment; these are design examples, not regulatory verification levels. The permitted-action calculation must consider all relevant dimensions. A verified identity does not close an unrelated financial-crime concern or remove a responsible-gambling restriction.

Enforce permission at the backend that accepts the action, not only by hiding a button. Define the point at which a bet or payment is authorised and how a restriction change invalidates an earlier permission. Test a policy change between the player's click and execution. Where services cache decisions, document their invalidation and consistency limits; an old cached approval must not become an undocumented route around a required control.

Choose a provider by the exceptions you must operate

Evaluate providers with representative, approved test cases for the documents, countries, languages and devices you intend to support. Look beyond a successful demo: inspect unreadable documents, changed names, unsupported evidence, accessibility problems and disputed results. Ask how rejection reasons distinguish a correctable submission problem from a final outcome. Your team needs that distinction to offer an appropriate next step.

• Creation and lookup: what happens after an ambiguous timeout, which identifiers can retrieve the original request, and whether retries can create another applicant or billable attempt.
• Events and status: authentication, delivery attempts, ordering guarantees, current-state queries and behaviour when a case is reopened.
• Evidence and controls: access roles, export format, retention, processing locations and contractual arrangements for personal data.
• Operating cost and exit: chargeable retries, screening refreshes, manual work, support coverage and the records available when the contract ends.

Keep provider-specific authentication, status mapping and error handling behind an adapter. The integration-layer guide explains that boundary. Preserve relevant provider detail in the evidence model rather than flatten every result into approved or rejected. Otherwise a replacement provider can appear compatible while changing what approval actually means.

After an ambiguous creation timeout, use the provider's supported lookup or reconciliation before submitting again. If the original outcome cannot be established, retain an unresolved attempt and escalate it instead of assuming nothing was created. A second provider is not automatically a safe fallback. Agree when it may be used, whether the evidence satisfies the same purpose, how conflicting outcomes are resolved and whether customer data may be transferred. Do not route a rejected applicant to another vendor until one returns a favourable answer. Cost comparisons should include review effort and repeated checks, without pretending there is a universal price per verified player.

Treat sanctions matches and PEP status as different questions

Keep identity checks, sanctions screening and politically exposed person screening distinct. Screening for politically exposed persons, or PEPs, identifies prominent public roles. FATF's PEP guidance treats additional measures as preventive, without presuming criminal activity. Applicable treatment still depends on the jurisdiction and customer relationship.

For sanctions, preserve the candidate record, relevant list and list version or retrieval time, matching attributes and the review outcome. UK OFSI guidance distinguishes a name match from a target match. Compare relevant identifiers and escalate uncertainty under the applicable policy; a similar name alone does not establish that the player is the listed person. Equally, an unresolved alert must not be treated as a cleared result.

Design separate routes for a possible match, a confirmed or sufficiently substantiated concern, a PEP assessment and a technical screening failure. Compliance must define applicable restrictions, reporting and escalation. Do not wait for an internal case to be labelled final if the legal threshold already requires action, and do not let a generic support override remove those restrictions.

Plan reassessment triggers: changed identity data, updated screening information, a new relevant alert or a scheduled review under the policy. A reviewer clearing one candidate match should record the basis and scope of that clearance. It should not suppress every future alert about the customer. Transaction patterns and source-of-funds questions belong in the wider risk workflow; a screening vendor does not replace that judgement.

Make manual review an accountable workflow

A manual-review queue needs cases that can be worked, not just a list of red badges. Show the question to resolve, available evidence, earlier decisions, applicable policy, current restrictions and the next permitted action. Distinguish waiting for the player, waiting for a provider and waiting for an internal decision. Each requires a different owner and customer message.

Give reviewers only the access and actions their role requires, scoped to the relevant entity and brand. For sensitive overrides, define a separate approval role where the policy calls for it. Record who acted, the evidence considered, the reason, the previous and new decision versions and any review date or condition. Engineering should not invent a convenient “approve everything” button to clear a backlog.

Use concurrency control so two reviewers cannot overwrite one another without seeing the change. If one has already resolved a case, the other's stale submission should be rejected or returned for explicit reassessment. Reopening must be an accountable transition that retains the earlier decision; it should not erase why permission was previously granted or refused.

Measure the oldest unresolved case and waiting time by queue and cause, not merely average API latency. Agree escalation for urgent risks and excessive delays. Customer messages should explain the required next step and realistic status without exposing confidential investigation detail; compliance must define what can be communicated. An outage, a possible screening match and a request for a clearer document should not all produce the same “verification failed” message.

Handle callbacks without losing newer decisions or new risks

Authenticate a callback under the provider's documented contract before accepting it as evidence. For example, Sumsub's webhook documentation describes HMAC verification against the original body bytes and finite delivery retries. This is a vendor-specific example: inspect the contract you actually use, including permanent failures and test events. Do not assume that every provider uses the same signature or retries forever.

Verify the customer, entity and attempt mapping before a transition; a valid signature does not justify assigning evidence to an unrelated case. After authentication and validation, persist the event in a controlled inbox before acknowledging successful acceptance. Process it durably, with a deduplication identity suitable for that provider's event model. Keep the provider event, the internal case and the verification attempt linked. If a delivery does not have a stable unique identifier, define a tested alternative using the documented fields; deduplicating only by customer would discard legitimate later updates.

Consider a hypothetical sequence. An automated approval is produced, a reviewer then restricts the account after examining additional evidence, and the earlier approval arrives late. The integration must retain that event without overwriting the newer operator decision. Arrival time alone cannot establish which evidence or attempt is current. Use the relevant attempt, documented provider sequence or revision where available, and current-state reconciliation where necessary.

Now add a genuinely new adverse screening result after the manual decision. It must raise the appropriate review or restriction under policy, rather than disappear because “manual decisions win.” Separate stale delivery from new evidence. If the provider cannot establish ordering, retain the ambiguity and resolve it through a status query or an accountable review; do not infer a reliable sequence from unrelated clocks.

Recover missed events with supported status queries or exports and reconcile unresolved cases. Bound retries and escalate persistent failures. A request timeout remains unknown until evidence resolves it; it is neither an automatic rejection nor permission to proceed. The security architecture guide adds context for protecting the provider and administrative boundaries.

Keep enough evidence to explain a decision

For a sampled decision, operations should be able to explain which customer and case were assessed, the checks performed, the provider evidence, the policy and decision versions, the reviewer or automated authority, the time and the resulting restrictions. Capture the provenance of evidence and material changes. Record the permission used by the relevant downstream action so the review history can be connected to what the platform actually allowed.

Keep documents and sensitive payloads out of general application logs, support tickets and analytics. Use controlled evidence storage, role-based access, access auditing and a defined response to expired or unavailable provider links. A hash can help detect a changed file; it cannot replace the underlying evidence or explain what the file showed.

Retention must be designed by record type and purpose, with applicable legal obligations and holds considered. The ICO's UK storage-limitation guidance explains that the UK GDPR does not set one retention period for every data type. Agree the schedule with legal and privacy owners, and implement deletion or anonymisation where appropriate. An audit history is not a reason to retain all raw identity documents forever.

Test an authorised export independently of the provider dashboard: can the reviewer reconstruct the decision and the relevant permissions from the retained evidence? Include the limits of the export and the treatment of corrections. Preserve accountability while applying the agreed retention rules; “immutable” must not become an excuse to put unnecessary personal data into permanent, widely accessible records.

Release a complete journey, then expand

Begin with a bounded combination of legal entity, jurisdiction, product journey and provider. Build the complete path: customer entry, evidence collection, provider processing, permission enforcement, exceptions, manual review and audit export. Agree acceptance with product and compliance before expanding to additional markets or vendors. The payments and KYC integration service relates these controls to the payment journeys they affect.

Use synthetic or approved test data in isolated environments. Test replayed events, a missing callback, an ambiguous creation timeout, stale reviewer actions and a changed risk decision during a player action. Exercise both denied and permitted paths with actual operating roles. Confirm that a test-mode event cannot grant production permission.

A controlled rollout may limit traffic or run selected new checks in observation mode, but it must preserve the controls already required for that population. Define a rollback that restores software or configuration without erasing accepted evidence, reopening resolved cases indiscriminately or removing required restrictions. Keep policy and schema compatibility explicit.

Monitor completion and abandonment by stage, provider failures, unresolved-case age, manual-review demand and downstream permission denials. Set targets from the operating policy and measured workload, rather than adopt an arbitrary industry conversion figure. Expansion is justified when the team can explain decisions, resolve exceptions and maintain required controls, including when the provider is unavailable.

• Ambiguous creation timeout: locate or explicitly reconcile the original attempt; a retry does not silently create a second customer or duplicate verification charge.
• Duplicate callback: repeat one delivery and prove that its effect occurs once while a distinct later event still reaches the case.
• Late approval: deliver an older provider outcome after a newer operator restriction; preserve the restriction and retain the event for explanation.
• New adverse evidence: deliver a relevant alert after manual resolution; demonstrate the configured review or restriction without losing the earlier history.
• Competing reviewers: submit two changes from the same case version; the stale action cannot overwrite the accepted decision.
• Permission enforcement: change a restriction during the player journey and test the backend execution boundary; a cached UI approval does not bypass it.
• Provider outage: expose pending cases, current permitted actions and an accountable recovery path; unknown results do not become approvals.
• Evidence and access: reconstruct a sampled decision from an authorised export and prove that another brand's reviewer cannot access its documents.