Why is KYC for casino harder than for any other regulated vertical?
Three things stack up. The licence regimes are fragmented: the MGA, the UKGC, AGCO in Ontario, ADM in Italy, Spelinspektionen in Sweden, ANJ in France, Curacao. Each one has its own age-assurance rules, source-of-funds thresholds, and self-exclusion register.
Player drop-off at document upload is brutal in gambling. And the data that gets collected to clear KYC sits on the operator’s stack for years, becoming the liability that funds the next breach headline. The average cost of a data breach hit USD 4.88M in 2024, and a regulated operator pays a multiplier on top.
For background, see crypto KYC compliance (the patterns overlap heavily) and how to reduce KYC onboarding drop-off.
What we hear from operators and partners
"Casinos strictly limit data sharing to regulators."
"Operators put their money into affiliates. Compliance vendors come last."
"Gambling rankings change multiple times a day. Onboarding is where you lose them."
"Nobody budged on a new vendor. Nobody cared."
The pattern is consistent. The compliance team wants the licence. The marketing team wants the signup. The CFO wants to stop paying twice for the same player.
What does KYC for a casino actually need to cover?
A licensed casino’s KYC stack has more checks than a typical fintech onboarding. At minimum, you need age verification (with the threshold set by jurisdiction, 18 in most of Europe, 21 in some US states), government-issued ID with NFC chip read where available, biometric liveness with deepfake detection, address verification, sanctions and PEP screening, adverse media, source of funds for higher-stakes players (EDD), and a check against self-exclusion registries like GAMSTOP in the UK or Spelpaus in Sweden.
| Check | Why a casino needs it | Zyphe coverage |
|---|---|---|
| Age verification | Licence condition; underage access is the fastest path to losing the licence | NFC chip read, ID OCR, and liveness, with jurisdiction-specific thresholds |
| Identity (ID and liveness) | KYC core; deepfake-resistant under MGA and UKGC guidance | Document OCR, NFC, liveness, deepfake detection |
| Address verification | Required for tax residency, geo-restrictions, deposit limits | Document or trusted source verification |
| Sanctions, PEP, adverse media | AML obligation under FATF and local AML directives | Continuous re-screening, configurable thresholds |
| Source of funds (EDD) | Required for high-deposit players in most regimes | Document upload, automated review, decisioning workflow |
| Self-exclusion check | Operator must reject excluded players (GAMSTOP, Spelpaus, equivalents) | Integrated registry checks at signup and at deposit |
| Ongoing monitoring | Continuous CDD, transaction monitoring, behavioural triggers | Pair with AML software |
| Multi-accounting and bonus abuse | Operational, not regulatory, but a serious revenue leak | Reusable identity removes the most common abuse vectors |
For deeper context on the screening layer, see our adverse media screening AML guide and enhanced due diligence vs standard CDD.
What are the casino KYC requirements under each licence regime?
Casino KYC requirements share an AML baseline and differ in timing, thresholds and the registers you must check. The summary below is what a compliance lead needs before choosing a vendor; the licence conditions themselves are the authority.
- UK Gambling Commission. Licence condition 17.1.1 requires a remote licensee to verify a customer’s name, address and date of birth before the customer deposits or gambles, and social responsibility code 3.2.11 requires age verification before any access to gambling, including free-to-play games. GAMSTOP self-exclusion checks, customer interaction triggers and the financial vulnerability checks covered below sit on top.
- Malta Gaming Authority. Full customer due diligence under the Prevention of Money Laundering and Funding of Terrorism Regulations and the MGA’s implementing procedures, with enhanced due diligence triggered by deposit thresholds and risk, and record-keeping aligned to the MGA’s reporting requirements.
- AGCO Ontario. Age and identity verification before play under the Registrar’s Standards for Internet Gaming, responsible gambling triggers, and checks against Ontario’s self-exclusion programme.
- ADM Italy. Identity verification against a national identity document within the concession framework, address verification, and reporting fields aligned to ADM’s requirements.
- Spelinspektionen and ANJ. Sweden requires Spelpaus checks and BankID-grade identity; France requires identity, age and address verification with French-resident specifics under ANJ’s rules.
The age verification and KYC software products apply these as configurable policies, one per licence, so a group with a UK, Maltese and Ontario brand runs three overlays on one verification.
How does KYC verification at a casino work at signup, deposit and withdrawal?
KYC verification at a casino is not one event. It runs at three points, and regulators judge operators on all three.
- Signup. The player captures a government identity document and a selfie. Zyphe verifies the document against 4,000+ document versions, runs active liveness with injection detection against photos, screens, videos and masks, matches the face to the document, and reads the date of birth for the age check. Sanctions, PEP and adverse media screening return a banded 0 to 100 score with the number of contributing sources. In the UK this must complete before the first deposit or bet.
- Deposit and play. Self-exclusion is checked at first deposit and on configurable triggers. Deposit velocity and net loss feed the affordability and customer interaction rules. A sanctions match on re-screening updates the risk score, and transaction monitoring returns Allow, Review or Block on the next deposit.
- Withdrawal and enhanced due diligence. Higher-risk or higher-value players supply source of funds evidence into their own vault, a reviewer signs off, and the rationale is recorded. Holding a withdrawal to run a check the operator should have completed at signup is the pattern that draws regulatory action.
Every decision is logged with the policy version applied, which is the record an inspector asks for.
How does Zyphe deliver KYC for casinos without holding the documents?
Same architecture we use everywhere else. We run the verification: NFC ID read, liveness, sanctions, PEP, address, source of funds, age. Then instead of keeping the documents on a server we own, we encrypt them into the player’s own vault with the player holding the key, and process documents and biometrics transiently. The casino keeps the verification results, logs and proofs. We keep nothing reconstructable. The player keeps their PII.
For an MGA, UKGC, or AGCO audit, the regulator gets threshold-encrypted access. They can verify the check happened without us ever exposing the underlying file. That’s what compliance teams in regulated gambling have been asking for: full auditability without the storage liability.
See Decentralized PII Storage and Decentralized KYC for the architecture, and the identity breach epidemic 2026 analysis for why operators are now writing this into procurement RFPs.
How does the KYC Passport change the affiliate-to-operator handoff?
This is the part that’s specific to gaming. The economics of iGaming push most operator spend into affiliates, not into compliance vendors. So the most painful place in the player journey, the document upload, happens after the affiliate has already done the expensive work of acquiring the player. The drop-off lands on the operator. The CPA gets paid anyway.
Zyphe inverts the flow. The affiliate or aggregator runs the verification before the player arrives at your signup page. The player walks in with a KYC Passport: a signed, portable credential they own, shared with your organisation after an accepted invite and the player’s consent. Your operator backend reads the shared result after an accepted invite and the player’s consent, and confirms the licence-relevant checks (age, sanctions, jurisdiction, self-exclusion). No document re-upload. No CRM stitching. The deposit lands on a verified player.
Two things this changes:
- Returning players skip the document step. Most operators today re-KYC the same player every time they cross a brand boundary. With a portable credential, repeat verification is a passkey tap.
- Make affiliates accountable for the right thing. The affiliate’s bounty depends on a verified, depositing player, not a tyre-kicker who abandoned at the document screen.
For the conversion math, see reduce KYC onboarding drop-off.
How does Zyphe handle age assurance, GAMSTOP, and source of funds?
The age check itself is a product in its own right: age verification reads the date of birth from a verified document with liveness, enforces the minimum age you configure per market, and lets a returning player prove they are over the limit again without a new document.
These are the three checks that get a compliance lead fired when they fail. Underage access loses the licence. A missed self-exclusion costs the operator a regulator-imposed fine plus a public reprimand. A weak source-of-funds review on a player who turns out to be a money launderer is a referral to the FIU. We treat all three as first-class concerns, not bolt-on policies.
Age assurance. We read the date of birth from the chip on chip-equipped IDs (nearly all EU passports, biometric driving licences in most regions) rather than relying on OCR alone. The age threshold is configurable per jurisdiction, 18 by default in most of Europe, 21 for affected US states, with explicit gating for any vertical that’s stricter (regulated gambling adjacent to alcohol or tobacco licensing). The UKGC’s social responsibility code 3.2.11, which requires age verification before any access to gambling including free-to-play, is the floor we ship to by default; you tighten from there.
Self-exclusion. Zyphe checks the player against the relevant registry at sign-up, at first deposit, and on configurable triggers thereafter. GAMSTOP and Spelpaus are integrated. For other jurisdictions where the registry is less mature, we surface a policy hook so your team can add the check without a code release.
Source of funds and EDD. Source of funds is an input to customer interaction and the AML assessment. For higher-stakes players, our flow collects supporting documents (payslips, tax returns, bank statements, crypto transaction history) into the same user-controlled vault. Your compliance reviewer sees a structured record, signs off, and the result is recorded in the audit trail. EDD that used to take five business days becomes a decision in less than a day: the agent automates the review, a human reviewer signs off.
Affordability and financial vulnerability checks. Under social responsibility code 3.4.4 the UK Gambling Commission requires a financial vulnerability check once a customer’s deposits minus withdrawals exceed a threshold in a rolling 30-day period: 500 pounds from 30 August 2024, and 150 pounds from 28 February 2025. The check is a customer-specific public record search for bankruptcy orders, county court judgments, individual voluntary arrangements and similar indicators, not a request for documents from the player, and it need not be repeated if one was run in the previous 12 months. These checks are not KYC, but they depend on it: an affordability signal is only as good as the identity it is attached to, and a player verified once across brands cannot reset their net deposit clock by moving to a sister site. Zyphe supplies the verified identity and the cross-brand recognition; the operator’s responsible gambling system applies the thresholds.
For the regulatory background on customer due diligence in gambling, see our enhanced due diligence vs standard CDD post.
Which casino license regimes does Zyphe support?
Most of the regimes that matter for a Tier 1 or Tier 2 operator. We ship preset policies for the major European, North American, and offshore licences, and the policy layer lets your team clone and modify them per brand or per market without code changes.
- Malta Gaming Authority (MGA): full CDD, sanctions, EDD thresholds, MGA-aligned record-keeping.
- UK Gambling Commission (UKGC): age-assurance technical standards, GAMSTOP self-exclusion, source-of-funds review workflow, customer interaction triggers.
- AGCO Ontario: registered supplier requirements, age and identity verification, responsible gambling triggers, register-of-persons checks.
- ADM Italy: concessione-based requirements, document and address verification, ADM-aligned reporting fields.
- Spelinspektionen (Sweden): Spelpaus integration, identity and age, transaction-based ongoing CDD.
- ANJ (France): identity, age, address, French-resident specifics, ANJ-aligned KYC reporting.
- Curacao Gaming Control Board: identity and AML checks under the island’s current licensing framework.
- State-level US (DraftKings/FanDuel-style sportsbooks): geolocation, age, identity, source of funds, multi-state reciprocity policies.
If your jurisdiction isn’t listed, you can configure a custom policy from the dashboard or talk to compliance via contact. For multi-vertical operators that run sportsbook plus DFS plus casino on the same player base, see KYC for iGaming.
How does Zyphe compare to Sumsub, Onfido, IDnow, and Jumio?
The feature checklist overlaps for everyone. The differences that matter for a regulated gambling operator are about player drop-off, audit posture, and what your data exposure looks like the day a competitor’s vendor gets breached.
| What you actually care about | Sumsub / Onfido / IDnow / Veriff / Jumio | Zyphe |
|---|---|---|
| Player documents stored on vendor | Yes, retained 5 to 7 years per licence rules | Sharded, user-held, vendor cannot reconstruct |
| Reusable verification across your brands | Vendor-locked or unsupported | KYC Passport, one-click re-verification |
| Affiliate or aggregator pre-verification | Not standard | Built in: verify upstream, deposit on a cleared player |
| Time to ship in production | 2 to 6 weeks | 15 minutes (no-code link) or 1 to 2 days (API) |
| GAMSTOP plus Spelpaus integration | Often a separate vendor | Built into the policy layer |
| Custom policies per licence | Engineering effort | Preset MGA, UKGC, AGCO, ADM, Spelinspektionen, configurable per brand |
| Audit posture under MGA or UKGC inspection | Manual, vendor-dependent | Threshold-encrypted, regulator and user co-sign |
Read Zyphe vs Sumsub, the Persona / Discord identity verification incident, and the Sumsub security breach lessons for what’s at stake when the vendor is the breach.
What does an integration look like for a casino operator or aggregator?
Most operators go live in two weeks. The fastest path is the no-code verification link with one of our preset gambling policies, that’s about 15 minutes from dashboard signup to first verification. Full API or SDK integrations with custom branding take one to two engineering days. We support webhook callbacks, server-side validation of the KYC Passport, and structured payloads for your responsible gambling and AML systems.
curl -X POST "https://api.zyphe.com/sdk/flow/$ZYPHE_FLOW_ID/vr/create?sandbox=false" \
-H "x-api-key: $ZYPHE_SECRET_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"email": "player@example.com",
"customData": { "playerReference": "player_42", "brand": "casino-ukgc" }
}'
# The response carries the session id, token and access signature.
# Compose the hosted URL and open it for the player:
# https://verify.zyphe.com/flow/<flowSlug>?zypheVr=...&zypheToken=...&zypheAccessSig=...For operators running multiple brands, we ship a shared-policy mode: verify once, recognise the player across the group, with brand-specific overrides where the licence demands them.
For pricing by verification volume, see pricing. For a fuller technical walkthrough, how it works.
What’s the best KYC software for online casinos?
For licensed online casinos and sportsbooks, Zyphe is the best KYC software because it verifies the player, runs self-exclusion and EDD, and stores zero documents.
This page was reviewed against the licence conditions cited above on 18 September 2026. Casino KYC requirements change; where this page and a regulator’s published conditions differ, the regulator is right and we would like to hear about it at contact.
