Compliance by Design in iGaming: Why AML Must Be Built Into Your Product From Day One

There is a pattern that keeps appearing in iGaming enforcement actions: an operator launches, grows its player base, and during a licensing audit it is discovered that compliance controls were added after the core product was built. They sit alongside the product rather than inside it. They break under volume. They cannot produce audit-ready evidence on demand. The fine or license condition that follows is the visible consequence. The underlying cause is an architectural decision made at the start of development, when compliance was treated as something to sort before launch rather than something to design from the first sprint.

That approach no longer works. In 2024 and 2025, the UKGC carried out 9,700 compliance actions, up from 4,200 the previous year, and has pledged to maintain this intensified oversight in 2026. Among the most persistent weaknesses identified were weak AML controls, with one in four firms failing to achieve a satisfactory rating. 

The MGA has confirmed it is strengthening a risk-based supervisory approach and now expects the underlying technology to do the heavy lifting. Operators can no longer rely solely on written policies; the platform must prove it works. The compliance-by-design model is not a philosophical position. It is the response to a regulatory environment that tests systems, not documents. 

{{snippets-guide}}

What Compliance by Design Actually Means

Compliance by design means regulatory obligations are built into the architecture, data model, and user flows of a product from the beginning of development, not retrofitted once the core platform exists. In iGaming, KYC verification, AML transaction monitoring, sanctions screening, PEP checks, and responsible gambling controls are not external modules bolted onto a finished casino platform. 

They are part of the platform, integrated at the data layer, triggered automatically by player actions, and generating a continuous, timestamped audit trail as a native output of normal operations.

The contrast with the legacy approach is direct. Under the legacy model, the compliance team receives a finished product, selects third-party tools, integrates them via API before launch, and handles alerts through a case management system disconnected from core platform data. Under compliance by design, compliance requirements are scoped at the start of the product roadmap. Identity verification logic, transaction risk scoring, screening calls, and SAR-triggering thresholds are specified as functional requirements, built into core workflows, and tested alongside the product.

Why iGaming Is High-Risk by Regulatory Definition

The FATF has classified casinos as "Designated Non-Financial Businesses and Professions" (DNFBPs), requiring them to implement AML measures similar to financial institutions. This classification extends to online operators. The EU's AML directives apply full obliged-entity obligations to all gambling service providers operating within the EU, not just those with physical premises. The practical consequence is that iGaming operators carry AML obligations structurally equivalent to those of a bank: customer due diligence, sanctions and PEP screening, transaction monitoring, SAR filing, and comprehensive recordkeeping. 

Money laundering in online casinos replicates the classic placement, layering, and integration pattern digitally. A player who deposits funds, makes a small number of low-variance bets, and withdraws the majority is using the platform as a conversion mechanism, not a gaming product. Detecting that pattern requires monitoring that understands both the financial and behavioral dimensions of the activity; something a compliance system added as an afterthought to a finished product is poorly positioned to do. 

What Regulators Require in 2026

UKGC: Verify Before Deposit, No Exceptions

In 2025, the UKGC officially eliminated the 72-hour grace period for identity checks. Operators must now verify a player's identity and age immediately upon sign-up, before any deposit can be made, forcing a major wave of AML implementation upgrades across the British market. For operators that built their onboarding flow around the grace period, this required architectural work, not a configuration change. Any platform where KYC sits outside the deposit workflow cannot comply without rebuilding the user flow. 

MGA: Technology Must Demonstrate Compliance

The MGA now requires operators to maintain system traceability with detailed audit trails for every player action and transaction, automate monitoring to flag fraud and responsible gambling triggers in real time, and ensure reporting infrastructure can produce accurate data on demand without requiring a total code rewrite. If a regulator requests a report of all transactions above a threshold from a specific jurisdiction over a defined period and the operator must engage developers to extract that data, the compliance system is not built to regulatory standard. The MGA is finding this gap in audits and treating it as a compliance failure.

CGA and the Global Enforcement Trend

Regulators globally have intensified scrutiny of AML and KYC processes, and the adoption of advanced RegTech solutions including biometric verification, AI-driven transaction monitoring, and integrated compliance systems is now expected, not optional. Manual checking at scale cannot demonstrate consistency, speed, or auditability. A compliance team reviewing deposit patterns by spreadsheet once a week is not meeting the 2026 regulatory standard. 

The Architecture of a Compliance-Ready Platform

Identity Verification as a Core Gate

The KYC layer must be a first-class platform component, not an appended integration. This means:

• Identity verification is triggered by registration events, not deposit events. The player cannot reach the deposit screen before verification is complete.
• Verification state is stored in the core user data model so every subsequent player action is evaluated against a verified identity record.
• The API layer for document verification, biometric checks, and database lookups can be swapped between providers without rebuilding the onboarding flow, since acceptable verification methods change over time.
• Re-verification triggers fire automatically when EDD thresholds are crossed, such as cumulative deposit limits or source-of-funds requirements.

Transaction Monitoring as a Platform-Native Function

Transaction monitoring cannot be an external system querying platform data at intervals. It must receive real-time event streams and evaluate them against risk rules as they occur. The required architecture includes an event-driven model where deposits, withdrawals, game sessions, and bonus claims publish to a monitoring layer in real time; risk rules operating on the live event stream rather than historical snapshots; dynamic risk scoring that updates a player's profile based on observed behavior; and automated alert generation that creates a case file with attached transaction history and routes it to the compliance team without manual evidence compilation.

Sanctions and PEP Screening Integrated Throughout

Screening must be embedded as a native call within the onboarding flow and triggered automatically on an ongoing basis. A compliance-ready architecture screens against the EU consolidated list, the UN Security Council Consolidated List, OFAC's SDN list where US-nexus applies, and the UK OFSI list for UKGC-licensed operators. 

Ongoing screening triggers fire when list updates occur or when a player's risk profile changes, without manual initiation. When a potential match is returned, the system routes it to a human reviewer with the match details, confidence score, and supporting data. The outcome of that review is recorded, with documentation of who decided and on what basis.

{{snippets-case}}

Audit Trail as a Native Output

The audit trail is not a reporting module. It is the consequence of every other component working correctly. When identity verification, transaction monitoring, and screening all operate as described, the audit trail is generated automatically as a byproduct of normal operations. Incomplete documentation is now a leading cause of audit failure at the MGA. The operational test is simple: can the platform produce a complete compliance record for any player, any time period, or any event type within minutes of a regulatory request? If it takes days, the architecture was not built for this purpose. 

Why Retrofitting Costs More Than Building It Right

The argument against compliance-by-design investment is usually cost and timeline. The counterargument is that retrofitting compliance into a finished platform is consistently more expensive. It means rebuilding user flows designed without verification gates, rearchitecting data models that did not capture the fields AML requires, and delivering integration work under regulatory time pressure rather than planned development cycles. Technical debt accumulates as each new compliance requirement adds another external module alongside the core platform rather than a native function within it.

Where controls are fragmented or reactive, risk and exposure follow. Compliance readiness depends on clear ownership, consistent application of controls, reliable systems, and well-documented outcomes. A platform that cannot demonstrate well-documented outcomes because it was never designed to produce them is not simply behind on a technical task. It is in a state of ongoing compliance risk that accumulates with every player interaction and every deposit processed. 

First Sprint Checklist

For development teams starting a new build in 2026, compliance requirements should be scoped before any feature development begins:

• Define target markets and their licensing requirements. Architecture must accommodate the most stringent requirements across all markets, not the least demanding.
• Specify identity verification as a functional requirement. Define what verification is needed, when it triggers, what initiates re-verification, and what the fallback is when verification fails.
• Design the event data model for monitoring from day one. Every player action and financial event should be a structured, queryable record, not unstructured logs parsed later.
• Plan the screening integration layer. Identify which sanctions and PEP sources must be covered, how API responses are handled, and how results are stored and reviewed.
• Build the audit trail as a first-class requirement. Define what the regulatory record for each player must contain, in what format it is retrievable, and which team owns it.
• Assign a compliance owner in the product team. Compliance must have named ownership in the product function, involved in sprint planning and acceptance criteria from the first sprint, not brought in after features are built.

Conclusion

Regulators in the UK, Malta, Curacao, and across the EU have made clear that compliance added after the fact is no longer acceptable. The KYC flow is not a friction point to minimize. The transaction monitoring system is not an operational overhead. The audit trail is not a reporting function. They are the infrastructure that makes it possible to hold a license, retain it under scrutiny, and scale a business in markets where the regulatory bar is rising every year. Building them in from the first sprint is not the cautious option. It is the commercially rational one.

sanctions.io is a highly reliable and cost-effective solution for real-time screening. AI-powered and with an enterprise-grade API with 99.99% uptime are reasons why customers globally trust us with their compliance efforts and sanctions screening needs.

To learn more about how our sanctions, PEP, and criminal watchlist screening service can support your organisation's compliance program: Book a free Discovery Call.

We also encourage you to take advantage of our free 7-day trial to get started with your sanctions and AML screening (no credit card is required).

‍