KYC & AML,
wired into every flow.

Compliance that doesn’t cost you conversions

Heavy-handed verification kills sign-ups. We build risk-based KYC and AML that verifies fast for low-risk players and steps up only when needed — so you stay compliant and keep the funnel intact.

It is a core part of the broader regulatory stack.

Every check costs you players. Every skipped check costs you the licence.

Sign-up is where the funnel leaks hardest, and KYC is the heaviest thing in it. Each extra field, each document upload, each selfie is another exit. So one instinct is to strip registration back to an email address and sort identity out later. The opposite — verify everything, in full, up front — is what a compliance team asks for when nobody pushes back. Both are wrong, and the argument between them usually gets settled by whoever is louder rather than by the rules.

The engineered answer is staged, risk-based verification. Let the player in on the minimum the jurisdiction allows. Attach the remaining checks to the events that actually carry risk: a withdrawal, a deposit crossing a threshold, a change in behaviour, a mismatch between the stated profile and the observed one. Friction then lands on the small share of accounts that warrant it instead of on everyone.

What can be deferred, and what cannot

The line moves by jurisdiction, which is exactly where operators get burned by assumption. Age is never deferrable. An underage player who deposits and plays is not a bug you patch next sprint; it is the class of failure that ends licences. Treat the age gate as a hard precondition on every path into real-money play, including any promotional or free-play route that feeds into one.

"Defer it all to the withdrawal" is not universally available either. The UK Gambling Commission's licence condition 17.1.1 requires licensees to obtain and verify information establishing a customer's identity — it names the customer's name, address and date of birth explicitly — before that customer is permitted to gamble. The same condition closes the obvious escape hatch: a withdrawal request must not trigger a demand for information the licensee could reasonably have requested earlier. In that market, parking KYC at the cash-out fails at the front door and is unenforceable at the back one.

That has an architectural consequence. Verification policy differs by market, so it has to be configuration, not code. A platform with one regulator's rules hard-wired into its registration controller cannot open a second market without a fork, and two forks later nobody can say which brand runs which policy. Model the policy as data — an ordered set of triggers, required checks and outcomes, versioned per jurisdiction — and evaluate it server-side. Adding a market becomes a policy record and a certification run, not a release.

Confirm the current position in each market with the regulator or your counsel before you build to it; rules here move, and a page like this is not the source of truth. What does not move is the shape of the problem: you need a policy engine you can change without changing the platform — a decision made in week one of platform development, or an expensive retrofit later.

The verification stack, and why you orchestrate it

"Which KYC vendor should we use?" is the wrong first question. The right one: what happens when the vendor you picked returns a no-match for a real player in a market you need?

Match rates are not a property of a provider. They are a property of a provider, in a country, against a particular data source, for a particular demographic — the registries, credit files and telco data underneath differ market by market. Marry one vendor and you have made their weakest market your weakest market. If they under-perform in Brazil, you do not have a vendor problem in Brazil. You have no Brazil. So put an interface of your own in front of verification and make providers swappable adapters behind it, with per-market routing and a fallback before you ever fail a real player. On a white-label that layer belongs to the platform owner; on a build you own, it is your asset.

Within it the layers compose in a deliberate order: electronic and database checks first wherever coverage supports them, being cheapest and invisible to the player; document plus liveness when that route fails or risk steps up, binding the document to a present human, which is what stops the borrowed passport and the printed still; address as a separate problem from identity and routinely the weakest link; age as the non-negotiable; and PEP and sanctions screening — where operators fail is not onboarding but rescreening the existing book, because lists change and yesterday's clean player becomes today's match. Screening that only runs at registration is decorative.

AML monitoring is a system, not a rule list

Rules are deterministic and auditable: a rule you can put in front of an inspector — deposits above X, from Y instruments, inside Z hours — is worth more than a model score nobody can explain. Baselining catches what rules miss: not the player who crossed a number, but the player whose own pattern changed. Run both.

And thresholds create the behaviour they measure. The EU's fourth Money Laundering Directive set a customer due diligence trigger for gambling services at transactions of EUR 2,000 or more — on the collection of winnings, the wagering of a stake, or both — and the 2024 EU AML Regulation carries it forward. Name a number and the predictable response is deposits sized just underneath it. Which is why aggregation matters more than the threshold: monitor cumulative and linked activity over rolling windows, per player, per instrument, per device. A structuring pattern is invisible to any check that reads one row at a time.

The durable tells are worth hard-coding: deposit, minimal play, withdraw — ideally to a different instrument than the one that funded it — is the classic, so track play-through as a ratio and treat a low ratio plus a payout request as an alert, not a VIP. Add velocity against the account's own baseline, instrument and identity graphs (link on device, IP, instrument and address, then judge the cluster), and in-product value transfer, because wherever the product lets value move between players it will be used to.

What your compliance team actually needs

Tier source-of-funds escalation against two thresholds — the regulatory one and your own, lower one — from automated request to document review to senior sign-off to exit. Then build the case tooling, the part that gets underbuilt. An analyst cannot work an alert from an inbox. They need a prioritised queue with an SLA; the evidence assembled at alert time — transactions, sessions, device and instrument links, KYC artefacts, prior alerts — not a link sending them hunting across four systems; an immutable audit trail of who saw what and decided what; and four-eyes sign-off on escalation, dismissal, closure and payout release. And a player under review must not learn they are under review, so your CRM and bonus automation must be suppressible per account, from the case.

Controls belong below the UI, not in it

Here is the rule that decides whether your platform survives an audit: KYC status and responsible-gaming limits gate the wallet, not the interface.

A greyed-out deposit button is not a control. A limit checked in the client is not a control. A cool-off enforced by hiding the login form is not a control. Those are hints. The control is the wallet refusing to credit or debit — server-side, on every path: the API the mobile app calls, the endpoint behind an affiliate iframe, the internal tool a support agent opens at 2am to "just help the player out", the bonus engine crediting free spins. If any route to the balance can reach it without passing the gate, you do not have a gate.

This is the specific place retrofitted platforms fail. Bolt compliance on after the product works and the checks land wherever they were easiest to add — the front-end, the registration controller, a middleware covering the routes somebody remembered. Certification then finds the route nobody covered. Putting the gate inside the wallet from sprint one is dramatically cheaper than adding it later, because later means unpicking every caller.

Responsible gaming is a wallet feature, not a footer link

Deposit, loss and time limits belong at the wallet and the session service, with the asymmetry built in deliberately: a decrease takes effect immediately, an increase does not. Several regulators require that shape — check the rule in each market, but you will need the capability somewhere. Markers of harm — loss chasing, stake escalation, session creep, cancelled withdrawals — run on the same behavioural event stream as your AML monitoring with a different rule set. Build one pipeline and two sets of rules; two pipelines is how the signals drift apart.

Self-exclusion is the one that gets built wrong. Key it on the email address and the excluded player signs up again with a new address — your control has evaporated, and you are holding the evidence in your own transaction log. Exclusion must be keyed on matched identity: name, date of birth and the verified identifiers you hold, checked at registration and at login, above the brand rather than inside it. A multi-brand operator matching per brand has implemented self-exclusion once, on one brand. Where a jurisdiction runs a central register, participation is usually a licence condition — the Gambling Commission has required UK-licensed online operators to participate in GAMSTOP, the national online self-exclusion scheme, since March 2020. Treat that check as another gate in front of the wallet, and decide now what happens when the register is unreachable, because failing open is not an option you have.

You are now holding a stranger's passport

KYC turns your platform into a store of identity documents. Minimise: you need proof a check happened and what it returned, not usually the artefact — every document you keep is a document you can lose. Retain on a clock: holding records longer "just in case" is a breach, not caution. Separate and encrypt: documents belong in encrypted object storage with their own keys, not as blobs in the application database. Gate access per view: named roles, authorised against an open case, logged each time — an agent needs the verdict, not the scan.

None of this is exotic. It is ordinary engineering applied early, in the right layer — cheapest at the start, most expensive at the end. If you are weighing a custom build against a white-label, be honest about the trade: white-label is faster and cheaper to launch, and its compliance stack arrives already certified. What arrives with it is also what you are stuck with — their vendors, their rules engine, their roadmap, their revenue share. Custom wins when you have volume, multiple brands or markets, a product you intend to differentiate, or an intention to sell, because owned IP is the asset. See how these controls sit inside our wider iGaming solutions, how the licensing route shapes what you must build, and which regulatory obligations apply in your markets.