Practical iGaming compliance guide
iGaming compliance across licences, products and markets.
For operators and suppliers, compliance is not one licence or one policy. It is the complete system connecting the market, product, technical estate, player controls, financial flows, reporting and every material change.
The compliance perimeter
Eight connected domains—not eight separate checklists.
The headings look similar across markets, but the licence holder, scope, definition, standard, approval route and evidence can differ. A reliable model preserves those differences and still gives the team one operating view.
Licensing and market perimeter
Identify the legal entity, role, activity, product, customer location and supplier chain before deciding which licence or approval route applies.
Platform, games and technical systems
Map system approval, testing, game rules, fairness, security, hosting, geolocation, logging and controlled-change requirements market by market.
Player protection
Connect age and identity controls, limits, exclusions, customer interaction, complaints and vulnerable-person safeguards to accountable owners.
Financial crime and payments
Define the applicable AML, transaction, funds, withdrawal and payment controls without confusing the compliance record with the systems that operate them.
Marketing and customer terms
Govern promotions, affiliates, targeting, required disclosures, terms, consent and market-specific restrictions before campaigns go live.
Reporting and recordkeeping
Retain recurring filings, material-event notifications, regulator requests, complaints, incidents, decisions and evidence with dates and owners.
Suppliers and outsourced services
Record licences, approvals, contracts, control responsibilities, service dependencies and evidence for platform, game, payment and technology suppliers.
Change and release control
Assess new rules and product changes against the approved system, identify affected requirements and complete testing, notification and sign-off work.
Responsibility model
Operator, supplier and shared work must be separated.
A platform agreement can divide delivery tasks, but the licence and governing rules decide who remains accountable. Record the legal duty, contractual allocation, operational owner and evidence separately.
Operator work
Operating licences, customer accounts, player protection, payments, marketing, reporting, customer funds and the end-to-end operating system.
Supplier work
Software or supplier licensing, product and system approvals, testing, release control, security evidence, integration responsibilities and customer-market scope.
Shared work
Requirement mapping, approved architecture, incident response, audit support, regulator requests, evidence exchange and controlled decisions about change.
Operating model
Move from market scope to a reviewable compliance record.
The same sequence works for market entry, a new product, a material regulatory change or an existing-control review.
- 01
Define the perimeter
Record the entity, licence, role, activities, products, systems, customer locations and material suppliers in scope.
- 02
Build the market baseline
Organise governing material into requirements and identify differences rather than copying one market template everywhere.
- 03
Connect controls and evidence
Show which policy, process or system meets each requirement and what proves the control is designed and operating.
- 04
Govern owners and decisions
Assign accountable people, deadlines, review states and escalation paths; preserve assumptions and unresolved questions.
- 05
Monitor and re-test change
Assess legal, technical, product and supplier changes against the baseline, then update approvals, controls and evidence.
Official market signals
The rulebook is layered. The evidence should be too.
These examples show why a generic global checklist is not enough. Use the governing material that applies to the entity and activity, confirm current versions, and retain specialist advice where interpretation remains unresolved.
Great Britain — Licence Conditions and Codes of Practice
The Gambling Commission organises current licence conditions and code provisions across technical standards, funds, payments, AML, advertising, identity, player protection and reporting.
Great Britain — remote technical standards
The Gambling Commission states that relevant remote operating and gambling software licensees must meet its technical and security requirements.
Great Britain — what counts as gambling software
The Gambling Commission distinguishes gambling software licensing from operating licences and explains the testing duties that apply before software reaches operators.
Great Britain — software and online sector guidance
The Gambling Commission separates B2B and B2C responsibilities and directs suppliers to the technical and testing requirements of each jurisdiction where their software is offered.
Michigan — technical bulletins and memos
MGCB publishes market-specific material on server location, communications, data logging, geofencing, software changes, identity and strong authentication.
United States — FinCEN casino programme guidance
FinCEN explains that a casino or card-club BSA programme should reflect its products, services, customer base, geography and risk profile.
System boundaries
Organise the programme without pretending one product operates every control.
Atlas can keep requirements, owners, decisions, controls and evidence connected. It does not replace the specialist systems or professional work that executes customer-level controls and independent assurance.
- Identity verification and transaction monitoring
- Player-risk detection and safer-gambling interventions
- Suspicious-betting and sports-integrity surveillance
- Game and system laboratory certification
- Penetration testing and independent security assurance
- Legal advice on unresolved applicability or interpretation
Questions
iGaming compliance FAQ
Short answers to the questions teams should settle before relying on a cross-market operating model.
What is iGaming compliance?
iGaming compliance is the work required to launch and operate online gambling lawfully in each market. It can include licensing, technical approvals, game and platform controls, player protection, financial crime, payments, marketing, reporting, recordkeeping and managed change. The exact perimeter depends on the jurisdiction, licence, product and role.
Do iGaming operators and suppliers have the same obligations?
No. Operators, platform suppliers, game suppliers, payment providers and other vendors can face different licensing, approval, reporting and technical duties. Contracts may allocate work, but they do not automatically move a legal obligation away from the entity that holds it.
Are GLI standards enough for iGaming compliance?
Not on their own. GLI states that jurisdictions set their own standards and may use GLI standards as a starting point. A team must map the standards, local rules, licence conditions, regulator directions, approved testing scope and any market-specific variations that apply to its system.
What is the difference between iGaming compliance and iGaming server compliance?
iGaming compliance is the wider operating perimeter. Server compliance is the technical subset covering matters such as system architecture, equipment location, data storage, communications, logging, geolocation, access, security, testing, release control and regulator access.
Can one compliance platform replace KYC, AML or player-protection systems?
No. A compliance platform can organise requirements, owners, decisions, controls and evidence around those programmes. Identity verification, transaction monitoring, player-risk detection, interventions and suspicious-betting surveillance still require specialist systems and operating procedures.
How should a multi-market iGaming team manage compliance?
Define the entity, role, licence, product and system perimeter for each market. Map each requirement to controls, owners and evidence; identify market variants; govern releases and supplier dependencies; monitor change; and retain the completed decision history. Unresolved legal questions should be escalated to qualified counsel.
Atlas
Put the market context next to the compliance work.
See how Atlas connects requirements, systems, owners, evidence and monitored change across your priority markets.