An account in a regulated iGaming platform is protected by two checks that are constantly confused with each other. Age assurance answers whether this person may gamble at all. Identity verification answers who this person is, so that the account, the money and the regulatory record all attach to the same human being. Neither substitutes for the other, and a platform that implements one of them well can still fail the other, because the evidence each one needs is not the same evidence.
For an operator’s compliance lead, platform architect or identity supplier, the delivery artifact is a verification control pack: the obligation that triggers a check, the assurance level the check must reach, the evidence class it may accept, the timing rule that decides when it runs, the record that proves it ran, and the defined behaviour for every outcome that is not a clean pass.
Age assurance and identity verification answer different questions
Great Britain’s remote social responsibility code 3.2.11 requires licensees to have and apply procedures that verify the age of a customer before that customer can deposit funds, access free-to-play versions of gambling games, or gamble using their own money or any free bet or bonus. Note what that list contains: a free-to-play version of a game sits inside the boundary. A surface that product teams treat as marketing sits behind an age gate in the same way a real-money wallet does.
Licence condition 17.1.1 asks for something else. Licensees must obtain and verify information in order to establish the identity of a customer before that customer is permitted to gamble, and that information must include the customer’s name, address and date of birth. One obligation is a threshold predicate about age; the other is an identity record with three components. A single “KYC step” in a cashier flow usually satisfies the second and quietly assumes the first.
Both obligations are also scoped, and the scoping is part of the design. 3.2.11 applies to all remote licences except lottery licences, gaming machine technical, gambling software, host, and ancillary remote casino and bingo licences; 17.1.1 has its own stated exceptions, including lottery licences that only offer low-frequency or subscription lotteries. Verification logic therefore has to be a per-licence decision rather than a global switch. A supplier that hard-codes “always verify” for one client meets the exception list when a second client’s licence class is audited.
Choose an assurance level, then choose the evidence path
Identity proofing frameworks describe levels before they describe methods. NIST’s SP 800-63A-4, published in final form on 31 July 2025 and superseding SP 800-63A, defines technical requirements for three identity assurance levels and treats the level as the decision an organisation makes. The United Kingdom’s digital verification services framework takes the same shape: the Data (Use and Access) Act 2025 established a statutory register of digital verification service providers, and the trust framework beneath it defines levels of confidence.
The engineering consequence is that the assurance level decides which evidence paths are admissible at all. A name checked against a reference dataset, a document image checked with a liveness test, and a supervised comparison of a person against a document are different classes of evidence, and no risk score converts a weaker class into a stronger one. Write the intended level per check, then choose the evidence, then record which path actually ran. When a reviewer asks why an account was verified, “the vendor returned a pass” is not a record of an evidence path.
Keep the three questions separate in the data model as well: is this person old enough, is this person who they claim to be, and is the session in front of us still that person. They carry different failure costs and different re-check triggers, and the back-office access control guidance covers the privilege side of the third question.
Verify before value moves, not at the withdrawal screen
Timing is where a defensible design is usually lost. Condition 17.1.1 states that a customer’s request to withdraw funds must not result in a requirement for additional information to be supplied as a condition of withdrawal if the licensee could reasonably have requested that information earlier. That sentence is an architectural instruction: verification belongs at or before the point where an account acquires value, not at the moment the player asks for their money back.
The EU rulebook says the same thing from the other direction. Regulation (EU) 2024/1624, the anti-money-laundering regulation in the 2024 package that applies directly from 10 July 2027, requires in Article 23 that verification of the identity of the customer and the beneficial owner take place before the establishment of a business relationship or the carrying out of an occasional transaction. The derogation in the same article permits completion during establishment only where it is necessary so as not to interrupt the normal conduct of business and where there is little risk of money laundering or terrorist financing, and requires those procedures to be completed as soon as practicable after initial contact. That is a narrow exception with a documented condition attached, not a general licence to finish later.
A design that parks the check at the withdrawal step therefore does two things badly at once. It weakens the platform’s own evidence, because account history was built by a person the operator never established; and it converts an onboarding step into a customer-experience incident at the most sensitive moment in the relationship.
Treat thresholds as versioned configuration
Age and identity requirements are rarely “always” rules. They are threshold-and-trigger rules that move on a schedule. Under the AML regulation, providers of gambling services must apply customer due diligence not only when establishing a relationship but upon the collection of winnings, the wagering of a stake, or both, when carrying out transactions amounting to at least EUR 2 000 or the equivalent, whether in a single operation or through linked transactions. Article 19(9) then requires the EU’s anti-money-laundering authority to develop draft regulatory technical standards specifying lower values for higher-risk obliged entities and transactions, the related transaction values, the criteria to identify occasional transactions and business relationships, and the criteria to identify linked transactions. Those criteria decide whether two wagers by one person are one transaction or two, which is a data-modelling question before it is a compliance question.
Great Britain’s technical standards move on their own timetable. The Gambling Commission’s remote gambling and software technical standards carry a change effective 30 September 2026 in RTS 12B, the financial limits standard, including the requirement that the gambling system prevents a customer from further depositing once a deposit limit is reached until the defined period restarts or the customer takes the action to increase it, subject to the standard 24-hour cooling-off period.
The design lesson is not which number is right this month. It is that thresholds, trigger events, linking windows and cooling-off periods belong in versioned configuration with a record of which version was active when a specific decision was taken. A platform that ships thresholds as constants re-releases software every time a regulator moves a value, and cannot say afterwards which rules governed a decision made three years earlier.
Accept the credentials your markets will require
Europe is building a wallet-based identity layer, and the acceptance obligation carries a date. Regulation (EU) 2024/1183 requires, in Article 5a, that each Member State provide at least one European Digital Identity Wallet within 24 months of the entry into force of the implementing acts, at assurance level high, capable of selective disclosure so that a wallet can present a fact without presenting the document it came from. Article 5f(2) requires private relying parties, other than micro and small enterprises as defined in the referenced recommendation, that are required by Union or national law, or by contractual obligation, to use strong user authentication for online identification to also accept those wallets, no later than 36 months from the entry into force of those implementing acts, and only upon the voluntary request of the user. The areas that article lists as examples are transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications. Gambling is not named there, so an operator’s position depends on whether a rule or contract binding it requires strong user authentication, and that is a question to answer per market rather than by assumption.
Two properties of the framework shape the integration more than the date does. Article 5a(15) states that use of the wallets is voluntary and that access to public and private services must not be restricted or made disadvantageous to anyone who does not use one, which means the existing document path cannot be retired as a convenience feature. And Article 5a(4) requires selective disclosure, so the request the platform sends should ask for a predicate about age rather than a date of birth, and should ask for identity attributes only where an obligation genuinely needs them. A cashier that demands a full attribute set when the obligation is an age threshold has built a wallet integration that is harder to defend in a data-protection review and worse for the player.
The United Kingdom has taken a different route to the same destination, and its mechanism is instructive because it is explicitly conditional. The Licensing Act 2003 (Mandatory Licensing Conditions) (Amendment) Order 2026 allows licensed premises in England and Wales to accept digital identification for age checks, but only where the responsible person is covered by an agreement with a provider registered in the statutory digital verification services register, the provider confirms whether the age threshold has been met, and the delivered identification reaches at least a medium level of confidence as defined in the relevant version of the trust framework. The published explanatory material is explicit that a mere visual inspection of a digital document is not sufficient. That is the shape of a compliance-grade age check: a registered verifier, a stated confidence level, and a service that answers the age question directly instead of handing over an image.
Keep the evidence, not only the decision
Verification decisions age badly when the evidence behind them is not kept. Article 77(1)(a) of the AML regulation requires obliged entities to retain a copy of the documents and information obtained in the performance of customer due diligence, including information obtained through electronic identification means, and to ensure that retained records are not redacted. Article 77(2) permits references to that information to be retained instead of copies, but only where the nature and method of retention lets the entity provide the information immediately to competent authorities and the information cannot be modified or altered, and only where the categories where that substitution applies are defined in the entity’s own internal procedures. Article 77(3) sets a five-year retention period running from the termination of the business relationship, the occasional transaction, or the refusal, requires personal data to be deleted when that period expires, and allows a case-by-case extension of up to a further five years where a competent authority needs it.
That is a specification rather than a general instruction to keep everything. The platform has to store verification evidence in a form a reviewer can use, prove it has not been altered, produce it immediately where a reference was retained instead of a copy, and delete it on a defined clock without deleting records another obligation requires. Retention is also where the identity system meets the security logging and audit evidence control pack, because a retention rule that nothing enforces is a data-protection exposure rather than a control.
Re-verify on change, not on a calendar
Condition 17.1.1 requires licensees to take reasonable steps to ensure that the information they hold on a customer’s identity remains accurate. The AML regulation triggers fresh due diligence when there are doubts about the veracity or adequacy of previously obtained customer identification data, and when there are doubts as to whether the person the entity is interacting with is the customer or a person authorised to act for them.
Three practical triggers follow. A material change event — a name change, a new address, a payment instrument in another name — should open a re-verification task rather than silently overwrite the established record. A session that behaves like a different person should be treated as a new authentication question, with the account-takeover path that the incident response plan defines for confirmed compromises. And identity fraud should be assumed to be at least as well tooled as the platform: the Gambling Commission’s 2026 assessment of money laundering and terrorist financing risks in the British gambling industry, published on 30 July 2026, notes that rapid development in artificial intelligence capability tests the effectiveness of customer due diligence controls, and rates the casino sector high relative to other gambling sub-sectors even though the national risk assessment rates casinos medium across all regulated sectors.
Test the failures, not only the happy path
Acceptance for an age and identity system should be a list of contradictions, each with an expected platform state, an expected player-visible behaviour and an expected record. Start with an applicant whose document expires between capture and check, and one whose address has changed since the document was issued. Continue with a name that does not match the reference data and a name that matches only approximately. Then the credential paths: a wallet that returns an age predicate with no identity attributes at all, a wallet user who declines the attribute and keeps browsing, and a user who presents a second wallet after the first was revoked. Then the platform’s own contradictions: the same identity presented against a second account, a verification provider that times out after accepting the request, an identity record edited after verification completed, a withdrawal attempted on an account whose verification was deferred, and a retention clock that expires while a review is still open.
Each test should state the state the platform must reach, the evidence it must leave, and the person responsible for the exception class. A verification control that has never been forced into a contradictory state has not been tested; it has only been used.
For operators and suppliers specifying identity and age assurance, Wizards certification and compliance turns this control pack into platform, provider and acceptance requirements.
Frequently asked questions
Is age verification the same as identity verification in an iGaming platform?
No. In Great Britain, remote social responsibility code 3.2.11 requires age to be verified before a customer can deposit, reach a free-to-play version of a gambling game, or gamble, while licence condition 17.1.1 requires name, address and date of birth to be obtained and verified before the customer is permitted to gamble. One is a threshold about age; the other is an identity record, and the evidence that satisfies one does not automatically satisfy the other.
When must a remote operator verify a customer’s identity?
Before the customer is permitted to gamble, under licence condition 17.1.1, and the same condition says a withdrawal request must not become the first time additional information is demanded if it could reasonably have been requested earlier. Regulation (EU) 2024/1624 takes the same position for markets it covers: verification takes place before the business relationship is established or the occasional transaction is carried out, with only a narrow, conditioned derogation for completing it during establishment.
Does the EU anti-money-laundering regulation apply to online gambling operators?
Yes, and it adds events that are not onboarding events. Regulation (EU) 2024/1624 applies directly from 10 July 2027, defines gambling services at EU level for the first time, and requires providers of gambling services to apply customer due diligence upon the collection of winnings, the wagering of a stake, or both, where transactions reach EUR 2 000, whether in a single operation or through linked transactions. Member States may exempt some providers on proven low risk, but the exemption cannot be used for casinos or for providers whose principal activity is online gambling or sports betting.
What must a platform retain to prove a verification happened?
Under Article 77 of Regulation (EU) 2024/1624, a copy of the documents and information obtained while performing customer due diligence — including information obtained through electronic identification means — kept unredacted, or a reference to it where retention rules allow immediate production and the information cannot be altered. The retention period is five years from the end of the relationship, the occasional transaction or the refusal, after which personal data must be deleted, with a possible case-by-case extension of up to five further years.
Should a gambling platform accept European Digital Identity Wallets?
Only where the obligation actually applies, and then on the user’s voluntary request. Article 5f(2) of Regulation (EU) 2024/1183 obliges certain private relying parties that are required to use strong user authentication for online identification to accept the wallets; gambling is not one of the sectors named in its illustrative list, so the answer depends on the national law or contract binding the operator. Two requirements hold either way: use of a wallet is voluntary and non-users must not be disadvantaged, and the platform should request a selective-disclosure attribute such as an age predicate rather than a full identity document.
