UKGC Technical Standards: An Operator’s Guide to RTS Compliance
Most operators treat the Remote Gambling and Software Technical Standards (RTS) as a compliance exercise. Something for the legal team to worry about, something to check off before license renewal, something that slows down the roadmap. This framing is expensive.
The RTS defines the engineering constraints your platform must operate within. Every architectural decision you make, from wallet service design to event logging to player account management, either aligns with these constraints or creates technical debt that compounds with each regulatory update. If your platform architecture treats compliance as a bolt-on rather than a design principle, you’re building in cost. Not hypothetical cost. Real cost measured in re-architecture sprints, failed audits, and delayed market entry.
The UKGC has been tightening its enforcement posture. Financial penalties have grown larger. License conditions are being imposed more frequently. The 2024 updates to the RTS reflect a regulator that expects operators to demonstrate compliance at the system level, not just in policy documents. For a CTO or Head of Platform evaluating platform modernisation, migration, or a build vs. buy decision, understanding what the RTS actually requires at the engineering layer is a prerequisite, not an afterthought.
This article breaks down the RTS framework into its functional components, explains the ISO 27001 audit requirements, details the testing and verification process, and maps the real consequences of getting it wrong.
The RTS applies to every holder of a UKGC remote operating license and remote gambling software license. If you’re operating or supplying software for online casino, sports betting, bingo, poker, or virtual events targeting GB customers, you’re in scope.
What the RTS is not is a prescriptive technology mandate. It doesn’t specify programming languages, cloud providers, database engines, or architectural patterns. It specifies outcomes. Your platform must achieve certain results around fairness, security, and player protection, and you must be able to prove it.
This distinction matters because it creates both flexibility and ambiguity. Flexibility in that you can choose your technology stack. Ambiguity in that “achieving the outcome” is subject to interpretation during audits and enforcement actions. The UKGC expects you to demonstrate compliance, not simply assert it. That means audit trails, system logs, documented processes, and testable controls.
The RTS spans multiple domains. It covers everything from random number generation and game rules display through to self-exclusion integration, financial transaction handling, and information security. Each domain carries specific requirements, and the standard is structured so that different license types trigger different applicable sections. A pure software supplier has a different compliance surface than an operator running the full player-facing stack.
One common mistake: treating the RTS as static. The UKGC updates these standards, and those updates carry implementation deadlines. If your platform architecture makes regulatory change expensive (because you’re on a monolithic backend, or because your white-label vendor controls the roadmap), each update amplifies your technical debt.
The UKGC‘s design principle for the RTS is technological equivalence. This concept is frequently cited and frequently misunderstood.
Technological equivalence means that the regulatory standards don’t favour or penalise any particular technology choice. A platform built on microservices running on AWS should meet the same compliance bar as a legacy monolith on bare metal. The UKGC doesn’t care about your architecture. It cares about whether your players are protected, your games are fair, and your systems are secure.
In practice, though, technological equivalence cuts both ways. It means the UKGC won’t block you from adopting new technology, but it also means new technology doesn’t earn you any exemptions. If you’re deploying ML models for personalisation or risk scoring, those models still need to operate within the RTS framework for player protection and responsible gambling. “We’re using AI” doesn’t satisfy a regulatory requirement; demonstrating the outcome does.
The three objectives running through the entire framework:
Fairness. Games must operate as described. RNG outputs must be statistically random. RTPs must match published values. Players must have access to game rules before they commit funds.
Player protection. Account management, self-exclusion, reality checks, deposit limits, transaction history. The platform must give players control and must not undermine that control through dark patterns or system design that makes it difficult to exercise.
Information security. Player data and financial transactions must be protected. Systems must be resilient. Access controls must be documented and enforced.
These objectives drive every specific requirement in the standard. When you’re evaluating whether a particular platform design meets the RTS, trace back to these three. If your architecture makes any of them harder to achieve or harder to prove, that’s a compliance risk.
Results Are Designed, Not Hoped For
Clear Objectives. Tangible Outcomes.
Well engineered software is only part of the equation. True impact comes from aligning technology with commercial intent from the outset.
We define success early, measure consistently and refine continuously to ensure every product delivers meaningful and sustained value.
The Compliance Gauntlet: Testing and Verification Explained
Proving compliance with the RTS involves multiple layers of testing, conducted by UKGC-approved third-party test houses. The major ones include firms like BMM Testlabs, eCOGRA, GLI, and NMi.
Initial game testing happens before any new game title goes live. The test house evaluates the game against the RTS requirements for fairness, rules display, RNG integrity, and RTP accuracy. If you’re an operator sourcing content from third-party suppliers, those suppliers should have test certificates for each title. But here’s the nuance: the UKGC holds the operator responsible for ensuring the games on their platform are compliant. Having a supplier certificate doesn’t fully discharge that obligation. You need to verify that the game behaves on your platform as it was tested, that the integration hasn’t introduced issues, and that the game rules displayed to players match the certified version.
Platform testing covers the broader system: player account management, financial transactions, self-exclusion, responsible gambling features. This testing is typically part of the initial licensing process and may be required again for material platform changes.
Ongoing monitoring is your responsibility. The RTS expects continuous compliance, not point-in-time certification. This means your internal QA processes, your monitoring systems, and your incident response procedures all contribute to your compliance posture.
The UKGC does accommodate equivalent international standards to some degree. If a game or system has been tested against standards from another respected jurisdiction (like the MGA or Gibraltar GGC), the test house may be able to conduct a gap analysis rather than a full re-test. This can save time and cost, but it’s not automatic. The gap analysis must specifically address where the RTS requirements diverge from the other jurisdiction’s standards.
For multi-jurisdiction operators, this is a planning consideration. If you’re entering the GB market with a platform already certified for MGA, budget time for the gap analysis and remediation of any differences. The UKGC’s player protection requirements, particularly around self-exclusion and reality checks, are generally more prescriptive than some other jurisdictions.
Building a Proactive, Compliance-First Platform Architecture
There are two approaches to RTS compliance. The reactive approach treats each regulatory requirement as a ticket, bolted onto whatever platform exists. The proactive approach treats the RTS as a set of design constraints that inform architecture decisions from the start.
The reactive approach works until it doesn’t. As long as regulatory changes are minor and infrequent, you can absorb them. But the UKGC‘s update cadence has been growing, and each update layer on a platform that wasn’t designed for regulatory flexibility adds cost. On a monolithic backend or a white-label platform with limited configurability, a single regulatory change can trigger a multi-sprint engineering effort.
A compliance-first architecture looks different in specific ways:
Event-driven player account services that emit auditable events for every state change. Player registration, login, limit changes, self-exclusion, session activity. Every event timestamped, immutable, and queryable. This makes annual audits faster and makes it straightforward to demonstrate compliance to the UKGC.
Modular responsible gambling controls that can be configured per jurisdiction without code changes. When the UKGC updates its requirements for reality checks or deposit limits (which it has done multiple times), the change should be a configuration update, not a code deployment.
Separated wallet services with per-player ledgers and real-time event streaming. This supports both the RTS transaction history requirements and downstream systems for fraud detection and AML monitoring.
Infrastructure as code with enforced environment separation. Your ISO 27001 audit goes more smoothly when you can demonstrate that development, staging, and production environments are provably isolated, with access controls managed through code rather than manual processes.
Continuous compliance monitoring built into your observability stack. RTP deviation alerts, self-exclusion propagation checks, transaction reconciliation. These shouldn’t be manual processes run quarterly; they should be automated checks running continuously.
This isn’t aspirational architecture. Operators like Rank Group and other tier-one licensees operate platforms with these characteristics. The cost of building compliance into your architecture from the start is real, but it’s predictable and amortises well over a three to five year horizon. The cost of retrofitting compliance onto a platform that wasn’t designed for it compounds in the other direction.
If you’re evaluating a platform migration, a build vs. buy decision, or a modernisation programme, the RTS should be one of your primary inputs into the architectural requirements. Not because compliance is the most exciting engineering problem, but because getting it wrong is one of the most expensive.
Latest from our blog
Insights & Perspectives
Our insights explore the intersection of technology, commercial strategy and disciplined execution across complex digital environments.
