Lottery KYC Integration Guide: States, Data & Manual Review
A lottery KYC integration should translate a verification provider’s decisions into clear, controlled player-account permissions. Define the status model, manual-review path, update handling and data boundary before connecting the first verification screen. A completed upload is not the same as an approved applicant. This guide covers technical and operational requirements, not jurisdiction-specific legal advice or […]
A lottery KYC integration should translate a verification provider’s decisions into clear, controlled player-account permissions. Define the status model, manual-review path, update handling and data boundary before connecting the first verification screen. A completed upload is not the same as an approved applicant.
This guide covers technical and operational requirements, not jurisdiction-specific legal advice or actual WhiteLotto API documentation. The responsible operator and advisers must define applicable checks and permitted account actions. The KYC journey guide considers the player experience alongside those controls.
Map provider states to operator decisions
Keep provider workflow status, decision outcome and internal account permissions separate. “Completed” may describe a finished review with either an approval or a rejection. “Requires action” can mean another document is needed rather than a final decline.
| Internal state | Meaning to define | Operator action |
|---|---|---|
| Not started | No required verification journey has been initiated. | Show the applicable next step and configured restrictions. |
| Awaiting applicant | Information or a resubmission is needed. | Provide a safe, clear request without exposing internal risk logic. |
| Pending review | The provider or reviewer has not reached a usable decision. | Preserve pending status; do not silently approve on timeout. |
| Manual review | An authorised human decision is required. | Assign an owner, access boundary and escalation path. |
| Approved | The agreed checks passed for the relevant level and time. | Apply only the permissions authorised by operator policy. |
| Rejected or restricted | A final outcome or later restriction requires action. | Apply controlled restrictions and permitted customer communication. |
Sumsub’s applicant-status documentation illustrates the distinction between a completed review, approval and retryable rejection. This is one provider’s example, not a statement that WhiteLotto uses Sumsub or has identical states.
Make updates safe, including changed decisions
Link the applicant reference to the correct player and verification level. Validate event origin through the provider’s documented mechanism. Store enough event metadata to detect duplicates and investigate timing without placing identity documents in routine logs.
An applicant may receive a later decision after the first completion. The Sumsub results guide describes follow-up final events and recovering missed delivery. Agree how your integration determines the current decision, handles older updates and rechecks permissions after a legitimate change. A permanently cached approval is not a complete state model.
Build a supported recovery route for missed notifications. Use a status query or provider replay as a fallback under the actual contract rather than continuously polling every applicant without a reason. Connect this design to the parent integration architecture.
Minimise the data copied into the platform
Identify which information each system needs: provider reference, decision, verification level, relevant timestamps and permitted reason codes may serve a workflow without copying every uploaded document. Define who can access the provider dashboard, what is retained locally and how deletion or retention instructions propagate.
Use synthetic applicants for development and demonstrations. Do not ask staff to upload real passports into an unapproved test environment. Apply role-based access to manual review and keep sensitive identifiers out of URLs, analytics events and general-purpose error tracking. Resolve contractual rights separately using the player data ownership guide.
Define manual handling before launch
Name the reviewer, escalation owner and permitted actions for ambiguous cases. Specify how duplicate accounts, mismatched identifiers, unavailable providers and reopened verification are handled. Separate a technical integration failure from a negative verification decision so the customer is not incorrectly told they failed a check.
The support team needs safe messages, case references and a route to an authorised reviewer—not unrestricted document access. Agree operational expectations and exception ageing in the support and SLA checklist.
KYC integration acceptance cases
- New applicant, approval, resubmission, final rejection and manual review.
- Duplicate, delayed and out-of-order events for the same applicant.
- A later decision that changes an existing account’s permitted actions.
- Provider outage, missed notification and controlled recovery.
- Wrong player reference, unauthorised reviewer and restricted-data access.
- Localised customer messages and usable mobile verification journeys.
For each case, capture the provider outcome, internal state, account permission and audit evidence. Include the exact configuration in UAT and track queue ageing with the operator KPI framework.
KYC integration FAQ
Does an approved provider result establish full compliance?
No. Verification is one control within the operator’s wider obligations and operating policy. The technical connection cannot determine every applicable legal requirement.
Can staff approve unresolved technical cases?
Only through the operator’s authorised review process. A missing response should not become an automatic approval or an improvised bypass.
Bring your verification journeys, decision owners and data boundaries to WhiteLotto. CONTACT.