iGaming regulations in the UK.

Premium market, premium bar

A UKGC licence opens one of the most valuable markets in the world — and demands the strictest controls. We build to that bar from sprint one. See the wider regulations guide.

What the UKGC requires

• Robust KYC and AML with affordability checks
• Strong responsible-gambling tools — limits, self-exclusion (GAMSTOP), reality checks
• Game fairness and certified RNG
• Transparent terms and advertising rules
• Detailed regulator reporting

Building for the UK

UK compliance is an engineering effort, not paperwork. We architect these controls into the platform so certification is the smooth part of your launch.

The LCCP is your obligation. The RTS is your spec.

If you take one thing from this page, take this: the Licence Conditions and Codes of Practice (LCCP) and the Remote Gambling and Software Technical Standards (RTS) are two different documents, and your engineers only need to live inside one of them.

The LCCP binds the licensee. It sets what the business must do — the controls, the policies, the reporting. Your compliance officer owns it.

The RTS is the Gambling Commission's technical standard for remote gambling and gambling software. It is numbered, it is sectioned, and it is what your platform is actually tested against. RTS 7 covers generation of random outcomes, RTS 8 auto-play, RTS 12 financial limits, RTS 13 time requirements and reality checks, RTS 14 responsible product design, RTS 16 use of third-party software, RTS 17 live dealer studios.

That numbering is a gift. Most teams open a vague "UK compliance" epic and then meet the real requirements at the test house. Structure the backlog against the RTS sections instead. Each one becomes a ticket with an acceptance criterion somebody external is going to check.

The Commission states it has based the RTS security requirements on the relevant sections of Annex A to ISO/IEC 27001:2022. So your security work is not bespoke gambling security. It is an ISO 27001 control set with a gambling scope.

Where each UK rule actually lands

Compliance documents are organised by regulator logic. Platforms are organised by service boundaries. The translation between the two is where UK projects slip — so here it is directly.

GAMSTOP: exclusion is a national fact, not a local flag

Most platforms ship with self-exclusion already built. A player asks to be excluded, you set a flag on their account, the flag blocks login. That is local exclusion. In the UK it is not enough on its own.

GAMSTOP is the national scheme, and participation has been a condition of holding a Gambling Commission remote operating licence since March 2020. The register is not yours. It lives outside your database and it is filled with people who have never touched your brand.

That one fact breaks the usual design in four places.

• The truth is remote. Someone can self-exclude through GAMSTOP today having never held an account with you. Nothing in your data says so. Only the register does.
• Registration-only checks fail. A player who registers on Monday and self-excludes on Tuesday must be stopped on Wednesday. The Commission requires operators to check before letting someone open or use an account — so the check belongs on the login path, not just the sign-up form. Operators are also required to refresh their list of self-excluded consumers every 24 hours.
• It is a third-party dependency on your hottest endpoint. You have just put an external call inside login. You need a written decision for what happens when the register is unreachable, and in gambling the answer is fail closed. That is uncomfortable for a growth team and non-negotiable for a compliance one. Decide it at design time, not during an incident.
• One person, many brands. If you run several brands on one platform, the exclusion attaches to the person, not the brand. Identity resolution across brands stops being a marketing nicety and becomes a licence condition.

Failures here do not get filed as bugs. They get filed as regulatory breaches. This is why we wire KYC and AML controls in from sprint one rather than bolting them on before certification — the check has to sit on a path designed to carry it.

Financial risk checks: build the threshold as configuration

The UK's direction of travel is toward checking whether a customer can afford what they are losing. The Gambling Commission has run a pilot of frictionless financial risk assessments using credit reference data, and its Board has approved a staged approach to implementation. As of the Commission's July 2026 update, the thresholds and the start date for the first stage are still to be confirmed through consultation.

So do not hard-code any of it. What is stable is the engineering shape, and you can build that now.

Spend has to be queryable in real time

The checks are framed around net deposits over a rolling window. Both of those words are expensive. Net means deposits minus withdrawals, so you cannot just read a deposit counter. Rolling means a continuously moving window, not "since Monday" — the number changes on every transaction, withdrawals included.

Teams get this wrong the same way every time. They compute it in the reporting warehouse on a nightly batch, because that is where the finance queries already live. Overnight is useless here: the customer you needed to assess did their spending four hours ago and is still in session.

The control acts at the wallet

A risk signal that arrives in a CRM dashboard has not done anything. The control has to sit in the deposit path and be able to hold a transaction while an assessment resolves. Your wallet needs a pending state that means "check in flight", and your cashier needs a screen for it. Design the timeout deliberately: a check that hangs and then quietly lets the deposit through is worse than no check at all, because now you believe you have a control.

Thresholds are config, not constants

Every number in this area has already moved once and will move again. Anything the Commission can change belongs in configuration that a compliance officer can edit and an audit log can prove — not in a constant that needs a release train. If answering "what was the threshold on 14 March?" requires a git blame, you have built it wrong.

Rules that land in your game code

Most jurisdictions regulate the operator. The UK also regulates the product, in enough detail that it changes what your engine and client are allowed to do. RTS 14 is titled "responsible product design" and it is prescriptive:

• No auto-play. RTS 8 requires the customer to commit to each game cycle individually, so auto-play is not available for online gaming. The Commission's guidance carves out auto-posting of blinds in peer-to-peer poker.
• A floor on speed of play. RTS 14 sets a minimum time between game cycles — 2.5 seconds for slots, and 5 seconds for casino games other than slots and peer-to-peer poker. Enforce it server-side. A client-side timer is a suggestion, and suggestions do not pass testing.
• Nothing that accelerates play. RTS 14E prohibits turbo, quick spin and slam stop: anything letting a customer cut short the presentation of a result.
• No simultaneous play. RTS 14C prohibits functionality that facilitates playing multiple games at once, including split-screen formats.
• No celebrating a loss as a win. RTS 14F says the system must not celebrate a return that is less than or equal to the total stake gambled. Your win-presentation logic has to compare return against total stake, not against zero — a one-line rule and a deep refactor in an engine that assumed any return is good news.
• No reverse withdrawal. RTS 14B: the customer must not be given the option to cancel a withdrawal request, and withdrawn funds should not be re-depositable. This is a wallet and payments change, and it deletes a retention mechanic some platforms are quietly built around.
• Reality checks. RTS 13 defines a reality check as a display of the time elapsed since the session began. The customer picks the frequency from a reasonable range, any default must be set at the minimum, and the check must be acknowledged before it disappears. Casino games must also show elapsed time for the duration of the session.

Read that list as a buyer rather than a lawyer. Every item is a change to code you may not own. If your games came from a supplier who built for a market without these rules, they are non-compliant by default — and RTS 16 covers use of third-party software, so "the supplier's game did that" is not a defence. You need to know, per game and per supplier, what has been certified for Great Britain and what has not.

The same logic reaches your bonus engine. UK marketing and bonus rules constrain what you may offer, to whom, and how it must be described — so those constraints belong in the promotion engine as rules, not in a marketer's head. See casino software development for how the game and bonus layers fit together.

Certification is a checkpoint, not a finish line

The Commission publishes a testing strategy alongside the RTS, and it is risk-based rather than uniform. Some things need an independent third-party test facility before release — random number generation, game mathematics and source code review among them. Some areas a licensee may test in-house. Security is assessed by a qualified and independent auditor on an annual cycle. Two consequences get underestimated on almost every build.

Your release train is now in scope

You do not certify once and then ship freely. Changes to already-tested software carry testing obligations of their own, scaled to the severity of the change. Your pipeline therefore needs to answer a question it probably cannot answer today: does this pull request touch anything in RTS scope? Teams who solve it tag their modules — RNG, game maths, limits, session, wallet — and gate those paths differently from the marketing site. Teams who don't freeze all releases before every submission, which is how a two-week change becomes a quarter.

Live monitoring is a build item

Testing before release is not the whole obligation. Licensees must monitor games in live operation to confirm they behave according to their rules, and that monitoring is itself assessed. Actual return-to-player gets measured against theoretical, and drift gets investigated. That is a data pipeline and an alerting story, and it needs to exist on day one.

This is the strongest argument for owning your platform. When the RTS changes — and the Commission published updates effective January 2025 — an operator on someone else's stack joins a queue behind every other tenant on it. An operator who owns the code schedules the work. The honest counterpoint: white-label is faster and cheaper to launch, and it is the right call for a first brand testing whether a market exists. An owned platform wins when you have volume, several brands, a product worth differentiating, or an exit in mind — because then compliance change is a permanent cost centre, and you want your hands on it.

Before you build against any of this

This page is engineering guidance, not legal advice. The UK regime is actively changing: financial risk assessments are mid-implementation and the RTS has been revised recently. Confirm current requirements with the Gambling Commission and your own counsel before committing them to a specification. What we can tell you is how the controls get built and what they cost to change later.

If you are still comparing markets, our iGaming regulations overview sets the jurisdictions side by side, where iGaming is legal maps legal status by market, and iGaming licensing walks the application route. Operators weighing the UK against a European base usually read this alongside Malta and the MGA.