KYC Workflows for iGaming: From Identity Evidence to an Authorised Decision

A player submits identity evidence. Before the provider finishes, the player updates their details and the operator applies an account restriction. A successful callback then arrives for the earlier submission. If it writes a global “verified and active” flag, the platform can approve the wrong identity version and remove a restriction it has no authority to change.

Know your customer, or KYC, includes more than identity proofing. This article focuses on the player-verification workflow: collecting appropriate evidence, interpreting a provider result, handling exceptions and connecting a scoped decision to an authorised action. It is for product owners, architects and verification operations teams. The state names and worked scenario are design examples; the operator and qualified advisers must approve the real market rules. SPINDO.TECH's payments and KYC integration capability covers the wider commissioning scope.

Specify the action that requires verification

List the actions separately: registration, depositing, gambling, requesting a withdrawal, changing identity details and viewing statements or contacting support. For each, specify the required evidence, current restrictions, permitted decision maker and result when a check is unresolved. Completing identity proofing does not itself establish a right to gamble, clear an anti-money-laundering concern or authorise a payment. Enforce the decision at the action boundary; a prior page load or cached label cannot authorise a new request. Specify how a concurrent restriction is ordered against an accepted action.

For relevant remote licensees in Great Britain, Gambling Commission condition 17.1.1 requires identity verification before gambling. It also limits withdrawal-stage information demands that could reasonably have been made earlier, while allowing information then required by another legal obligation. Other markets need separate review. Set the approved checks at the appropriate stage; avoid turning “KYC pending” into an unexplained, universal withdrawal block.

Agree provider access, the operator entity, market, verification product and supported evidence before integration. A sandbox result does not establish permission to use the service in production. Publish a versioned policy that links evidence requirements to decisions and player messages. Identity updates and access enforcement belong in the player-account architecture, not solely in a document-upload screen.

Keep cases, attempts and account permissions separate

Keep an account identity version, verification case, provider attempt, evidence references and operator decision distinct. A case records its purpose and the identity snapshot under review. An attempt records the provider account, environment, requested checks, external references and result. The operator decision records what that evidence establishes, for which identity version and purpose, with a policy version and authorised actor.

NIST's identity-proofing overview distinguishes identifying the claimed identity, validating its evidence and linking that identity to the applicant. It also separates proofing from service entitlement. These are useful engineering distinctions, not a gambling-law specification or a reason to label a vendor profile with an unproven assurance level.

Use explicit case states, such as collecting evidence, submitted, awaiting provider, awaiting player information, manual review, approved, declined, cancelled or superseded. A technical provider failure needs its own reason; it is not evidence that the player is fraudulent. A successful document check might still leave another required check unresolved. Store the actual check results rather than compressing them into one colour. Account exclusions, limits and financial-operation state remain separately owned.

Receive provider evidence without letting it decide account access

Bind a provider attempt to the internal case, operator account, submitted identity version and verification scope. Keep production and test mappings separate. Authenticate notifications, validate their schema and route only recognised events. For a concrete provider example, Sumsub's webhook manager documentation specifies HMAC checking over the original body bytes and bounded delivery retries. Follow the actual provider contract; do not assume endless redelivery or that a re-serialized JSON body verifies correctly.

Durably record a validated notification in a restricted inbox before acknowledging successful receipt. Process it with duplicate protection and a guarded case transition. If persistence fails, do not claim it was safely received; use the provider's documented failure and recovery behaviour. Acknowledgement means receipt, not completion of the operator decision. An invalid signature or unknown account mapping must never grant a permission.

Protect against authentic but obsolete evidence. Use a provider-supported sequence, revision or status query where available; receipt time alone does not establish business order. Preserve the raw meaning and the adapter mapping version. If the contract cannot order conflicting results, escalate or reconcile rather than selecting whichever message arrived last. The integration-layer article provides the adjacent adapter context.

Follow a changed identity through a late result

Consider a hypothetical account with identity version 7. Case A sends attempt 1 for that snapshot. The player then corrects their name, creating identity version 8 and a new scoped review with attempt 2. An independent protective restriction becomes active. A late positive result for attempt 1 is valid evidence about the older submission; it is not approval of version 8 and cannot clear the protective restriction.

Record that late result against its original attempt and retain the case relationship. Decide under the approved policy whether any unchanged evidence can be reused; do not silently apply the old result to the changed attributes. If attempt 2 reports unreadable evidence, route it to a specific request for replacement evidence or an approved alternative review. Do not mark the player as dishonest or repeatedly create new provider attempts to obtain a different answer.

A trained reviewer follows the approved checks for the current identity and records the evidence and reasoning. Even when that review approves version 8, the independent protective restriction remains in force. A request to start new gambling is still evaluated against it. Access to support, statements or an authorised funds-return process follows its own rules. When two staff decisions race, the case version guard must reject a stale update and require a fresh review, not overwrite the later decision.

Test this sequence with duplicate delivery, reversed delivery order and a restart between receipt and application. Inspect the case history, resulting permissions and explanation shown to staff. A success banner from the provider cannot prove this behaviour.

Give manual reviewers a decision they can defend

A manual queue should show why the case needs attention, what has already been checked, which evidence is current and the permitted next actions. Route by capability, market and urgency, and track time awaiting a player separately from time awaiting a reviewer. Keep a named owner when a case moves between teams. A queue containing only “pending” makes both service quality and recovery hard to assess.

The reviewer needs scoped evidence access, a policy reference, a reasoned decision and a record of the action taken. Where policy requires another approval, a draft decision must not immediately release the controlled action. Record overrides explicitly and enforce the same market constraints as the automatic path. Provide an approved exception route for people who cannot complete the ordinary process; assistance or an alternative method must not become an undocumented lower standard.

Explain to the player what needs correcting and how to continue, using an approved message that does not reveal sensitive fraud controls or another person's data. Define disputes and reconsideration without promising that every adverse outcome is reversible. The back-office capability covers the workspace; the verification service must still own the decision and audit trail.

Protect evidence and make re-verification explicit

Separate operational decision metadata from document images and other sensitive evidence. Case identifiers, check summaries and restricted evidence references are often sufficient for ordinary support. Authorise document access at use time, log it and protect exports. Do not place identity documents in general application logs, analytics events or unrestricted notification attachments.

Where the EU GDPR applies, the European Commission's processing-principles guidance explains purpose limitation, minimisation and retention based on purpose and legal obligations. Have responsible specialists approve what the platform and provider retain, for how long and how deletion or required preservation works. An audit requirement does not justify keeping every document indefinitely.

Define re-verification triggers, such as changed identity attributes, an applicable document-policy event, a changed risk decision or a requirement to keep information accurate. Establish which prior evidence remains usable and which actions need a fresh decision. Do not turn expiry of one piece of evidence into automatic deletion of the whole identity history. Also define how provider suspension or replacement affects open cases, future checks and access to required records.

Choose a first release that proves the difficult paths

Release a complete approved journey: evidence collection, a recoverable provider submission, notification processing, a scoped decision, account enforcement and manual resolution. Start with a market and evidence scope the provider and operations team can actually support. Use permitted representative test data and state the differences from production. Simulated provider approval is not proof of acceptable real-world coverage.

The acceptance exercise should include a lost submission response after provider acceptance. Find the existing attempt through a supported reference or reconciliation route before submitting another; if that is unavailable, keep it unresolved and escalate. Do not confuse “request timed out” with “no case was created”. Restore queued notifications without applying a decision twice, and prove that a stale result cannot reopen a restricted account.

Measure unresolved age, missing-result reconciliation, repeated evidence requests, manual-review effort, decision reversals and failures to enforce restrictions alongside completion time. Segment measurements by relevant method and audience without exposing unnecessary personal data. Faster automated acceptance is not improvement if valid applicants cannot recover from a capture problem or restrictions are skipped.

For a project review, keep the adjacent decisions visible. Payment orchestration explains payment attempts and money outcomes that identity approval does not resolve. The bonus-engine guide addresses entitlement checks that must also respect current restrictions. When comparing custom and turnkey delivery, inspect verification history exports, provider access and case ownership before treating a vendor change as a simple API replacement.

An initial review should leave an approved action-policy map, a case and attempt model, provider-contract gaps, an evidence-access plan and replayable acceptance cases. Name any unresolved legal interpretation or provider capability and its owner. An engineering implementation makes approved decisions enforceable; it cannot supply the approval by itself.

• Decision map: For each player action, record the required evidence, current restrictions, policy owner and unresolved outcome.
• Case and provider contract: Define case, attempt and identity references, duplicate handling, result ordering, status recovery and cancellation semantics.
• Review and data controls: Demonstrate scoped staff access, reasoned decisions, stale-update rejection, evidence retention and an approved exception route.
• Recovery evidence: Replay changed details, late or conflicting results, provider timeouts and restarts; reconcile the history and prove the resulting account permissions.