Provider dependent
Identity & player
One player record: registration, history, limits and exclusions. Identity providers plug in through ready-made interfaces.
The problem
When identity, limits and history live in different systems, nobody has the whole player. Support guesses, compliance chases, and the player repeats themselves.
What the platform does
Every player has one account record that carries registration, account history, balances, limits and exclusions. Identity verification and national exclusion schemes connect through provider interfaces that already exist in the platform.
How it works
Follow it through.
- Front end
- Platform API
- Accounts
- Identity provider
- 01
A player registers through any front end; the API creates the account.
- 02
Verification requests go to the identity provider configured for that deployment.
- 03
Limits, cooling-off and exclusions attach to the same record and are checked on every decision.
- 04
Staff see the account, its KYC status and its history in one place.
Controls
- Exclusions and limits enforced server-side
- KYC status recorded on the account
- Account history kept with the player
- Player data export and anonymisation
Operator experience
Player administration lets staff search accounts and inspect the operational information they need for account, wallet and safer-gambling decisions.
Integration points
- Identity verification provider (per deployment)
- National exclusion schemes, configured and accepted per market
Audit & reporting
Staff actions on an account are written to the audit record with a named actor.
Software is evidence
The real interface.
Not a mock-up. This is the implemented screen, populated by a test environment.
Related capabilities
Let’s talk about what you’re building.
Tell us what you’re building. We’ll tell you plainly what the platform does today and what it would take.