UKGC Technical Standards

Skip key takeaways

Updated October 4, 2026

• The RTS bind through license condition 2.3.1 and leave the implementation open Each of the seventeen standards is an aim, a requirement and implementation guidance, the requirement is the acceptance criterion and the introduction allows any alternative approach that meets it in full and can be shown to be reasonable and similarly effective.
• Only the RNG, the game math, live RTP measures, live dealer and security need a third party Table 1 of the testing strategy sends RTS 7A, 7B, 7C, 7E and the 9B(b) and 9B(d) jackpot math to an approved test house, RTS 5A to annual independent assessment, RTS 17A to a regulator or test house and the security requirements to an annual audit, while everything else is licensee product testing or licensee verification on the live product.
• The customer-led tools in RTS 12 to 14 are state machines with clocks the licensee tests itself Limit setting from registration with a 24-hour cooling-off on increases and immediate decreases, reality checks that block the next auto-play game, a 2.5-second slots cycle and no cancel control on withdrawals are all product-tested by the licensee before release.
• The security requirements are ISO/IEC 27001:2022 Annex A controls with an annual independent audit The Commission scopes its listed controls to the systems holding customer data, random numbers and game state, requires the annual audit for the license categories its annex lists, does not approve audit firms, expects a first audit within 6 months of a new license and a copy of any report with a major non-conformity within 7 days of its receipt.
• GAMSTOP publishes the cadence and the data handling and the rest of the integration is platform design GAMSTOP's pages fix daily checks plus a check at every login and registration, hashed data kept only for the check and a seven-year flag after removal, while synchronous checks, batch re-checks, indeterminate answers and connection hardening are platform design.

Copy takeaways

The UKGC technical standards are the part of a UK gambling license that lives in code. The Gambling Commission publishes them as the Remote gambling and software technical standards (RTS), seventeen numbered standards plus a security section, and binds remote operating licenses, other than remote betting intermediary trading-room licenses, and gambling software licenses to them through license condition 2.3.1 of the LCCP. For a platform team each standard is a behavior the software has to exhibit, a test that proves it and a record that survives an audit.

In short: an approved test house examines the RNG and the game math before release and the licensee tests the customer-led tools in RTS 12, 13A and 13B itself. An annual games testing audit samples updates, and an annual independent security audit against selected ISO/IEC 27001:2022 Annex A controls applies to the license categories the annex lists, not to gambling software licenses. The national self-exclusion scheme adds a register check at every login and registration and once a day, and the Malta Gaming Authority covers similar ground with a system audit and a live system review.

What the RTS are and who they bind

LCCP license condition 2.3.1 requires licensees to comply with the Commission's technical standards and with "requirements set by the Commission relating to the timing and procedures for testing", and it applies to remote operating licenses and gambling software licenses alike, so a B2B platform supplier is bound under its own license. A shortfall against the RTS is a license-condition breach, reportable as an event, not a defect.

The standards are issued under the Gambling Act 2005 in five sections: an introduction, definitions, the seventeen standards, the security requirements and an annex mapping standards to product types. Every standard is an aim, a requirement and implementation guidance, where the requirement carries the obligation and the guidance describes acceptable ways to meet it. The introduction keeps the engineering open: "Licensees may adopt alternative approaches to those set out in the guidance provided they can meet the requirement in full and can demonstrate that an alternative approach is reasonable and similarly effective in the particular circumstances."

The same pages split the duties between the two license types.

License	What it owns
Remote operating license (the B2C operator)	The RTS and the testing strategy under license condition 2.3.1. Participation in the national self-exclusion scheme under code 3.5.5. An annual security audit where its license category is on the annex list. Third-party game content, payment providers and hosting brought into scope by supplier controls 5.19 to 5.23
Gambling software license (the platform supplier)	The RTS and the testing strategy under its own license condition 2.3.1. The mechanism behind the operator's self-exclusion check, not the 3.5.5 duty, whose exclusions include gambling software and host licenses. No place on the annex list for the full security audit, which names host licenses and not gambling software licenses. No vendor duty from RTS 16, which covers player-side software in peer-to-peer products

The seventeen standards and who tests them

Section 3 of the RTS lists the seventeen standards in this order, and the annex maps each standard to the product types it applies to, which is where a casino, a sportsbook or a peer-to-peer product reads its own subset. The third column is derived from Table 1 of the testing strategy, which sorts the requirements into independent assessment, licensee testing before release or licensee verification on the live product, with the interruption policies in RTS 10A and 10C verified as published.

RTS	Title	Testing route (derived from Table 1)
1	Customer account information	Licensee verification
2	Displaying transactions	Licensee verification, with licensee testing for 2C
3	Rules, game descriptions and the likelihood of winning	Licensee verification
4	Time-critical events	Licensee testing for 4A, licensee verification for 4B
5	Result determination	Annual independent assessment of the live RTP monitoring measures (5A)
6	Result determination for play-for-free games	Licensee testing
7	Generation of random outcomes	Approved test house for the RNG (7A) and the game (7B, 7C, 7E), licensee testing for 7D
8	Auto-play functionality	Licensee testing
9	Progressive jackpot systems	Licensee verification for 9A, approved test house for the jackpot math in 9B(b) and 9B(d), licensee testing for the rest
10	Interrupted gambling	Licensee testing for 10B, published policies verified for 10A and 10C
11	Limiting collusion and cheating	Licensee testing for 11A, licensee verification for 11B
12	Financial limits	Licensee testing before release, with 12D also verified on the live product
13	Time requirements and reality checks	Licensee testing for 13A and 13B, licensee verification for 13C
14	Responsible product design	Licensee testing before release
15	In-play betting	Licensee verification
16	Use of third party software	Licensee verification
17	Live dealer studios	Independent assessment by a regulator or test house
Section 4	Security requirements	Annual security audit by a qualified independent third party

RTS requirement, software behavior and evidence

This table reads the UKGC technical standards requirement by requirement. The second column is editorial, an engineering reading of the requirement and its guidance that is one way to meet it and not the Commission's words. The third names the evidence from the testing strategy and the security pages, marked (ed.) where the artifact is a platform's own rather than one a page names.

RTS requirement	Software behavior (editorial)	Evidence
Time-critical events (RTS 4A)	Latency estimate shown to the customer, or handicapping on estimated latency, or a simultaneity window under a stated policy, wherever speed of interaction has a significant effect on the chance of winning	Risk assessment demonstrable to the Commission. Licensee testing before release
Random outcomes (RTS 7A)	RNG statistically random, unpredictable without algorithm and seed, non-cycling, non-synchronizing, never adaptive	Approved test house statistical analysis of the RNG with its scaling and mapping before release. Report provided to the Commission before the RNG goes live. RNG version in the release record (ed.)
Game implementation and change (RTS 7B, 7D, 7E)	Random numbers consumed in order, an out-of-range value the only one discarded, logged as an error and investigated. Rules changed only with the game offline and a notice. Result displayed long enough to be understood	Game test report with math verification and source code analysis for 7B and 7E. Licensee testing before release for 7D. Change record per game with a major or minor classification
Interrupted gambling (RTS 10B)	Persisted round state (deck, hands, tokens, prize layouts, jackpot values, stakes) sufficient to restore or void. Automatic void and refund with a manual fallback. Market suspension	Licensee testing before release. Recovery test cases and incident records (ed.)
Financial limits (RTS 12A to 12E)	Limit setting from registration, free-text amount, account-level minimum, 24-hour, 7-day and one-month periods with the lowest winning, 24-hour cooling-off on increases, immediate decreases, limit as the default choice, annual and six-monthly prompts	Licensee testing before release. Limit-change audit trail with timestamps (ed.)
Gross deposit limits (RTS 12B phase two)	Gross deposit limit as the minimum type and the only one named deposit limit. Equal prominence. Deposits blocked at the limit until the period restarts or an increase clears its cooling-off. Fixed time frames. Net deposit limit as a defined term (deposits minus withdrawals over the period)	Licensee testing before release. Effect date in the what-changed note
Time and reality checks (RTS 13A to 13C)	Clock or elapsed time inside full-screen clients. Configurable reality-check frequency, acknowledged to dismiss, blocking the next auto-play game. Elapsed time for the whole casino session	Licensee testing for 13A and 13B. Licensee verification for 13C
Withdrawals and pacing (RTS 14B to 14G)	No cancel control on a pending withdrawal. No simultaneous play. 2.5-second slots cycle and 5-second casino cycle. Release-and-press per cycle. No turbo, quick spin or slam stop. No celebration at or below the stake	Licensee testing before release. Game configuration under change control (ed.)
Security requirements (section 4)	Critical systems scoped to customer data, RNG, game state, entry and exit points and networks. Logging, clock synchronization, backups, secure development life cycle, separated environments, change management, supplier controls	Annual independent security audit for the license categories the annex lists, report on file, a copy to the Commission within 7 days on request or on a major non-conformity. First audit within 6 months of the license
Live RTP monitoring and change control	Automated backend comparison of actual against theoretical RTP with alerting per game. Per-change record with id, identifier, channels, description, classification with justification, test confirmation and authorization	Annual games testing audit by an approved test house sampling major and minor updates. Test reports in the games register in eServices

Account, money and game information: RTS 1 to 4

The first four standards are mostly information duties checked on the live product, the exceptions being the price-change choice in 2C and the latency assessment in 4A, which the licensee tests before release. RTS 1 requires the current balance, in the account currency, on every gambling and cashier screen while the customer is logged in, and it fixes two history windows: "Customers must have easy access to at least three months account and gambling history without having to contact the licensee. A minimum of 12 months of gambling and account history must be made available on request." The guidance defines net deposits too: "Net deposits are defined as the running total of all deposits minus the sum of all withdrawals for the lifetime of the account." That guidance asks for a running total across the lifetime of the account, or from a fallback start point it provides itself where lifetime history is not available, so the net-deposit figure is carried forward whatever retention period applies to the underlying transactions.

Transactions come under RTS 2: the amount gambled and any conversion to chips or credits at the point of conversion, the content of a bet before the commit and a net position for the casino session. For a sportsbook the operational item is 2C, the customer's per-bet choice whether to accept a price movement in either direction. RTS 3 puts the rules, the house edge and the RTP or probability of winning in front of the customer before the commit, and RTS 4 requires a risk assessment, demonstrated to the Commission, wherever speed of interaction has a significant effect on the chance of winning.

Random outcomes and interrupted play: RTS 7 and 10

RTS 7 keeps the requirement short: "Random number generation and game results must be ‘acceptably random’." The page defines that as output whose randomness can be demonstrated to a high degree of confidence through statistical analysis, and it forbids adaptive behavior, meaning a compensated game. The guidance has random numbers used in the order received and not discarded, the one exception being a value outside the range the event needs, which may be discarded, with the occurrence logged as an error and investigated. Requirement 7D keeps rules, payouts and outcome probabilities fixed while a game is available for gambling except as its own rules provide, and the result must stay on screen long enough to be understood.

RTS 10 turns recovery into a functional requirement: "Systems must be capable of recovering from failures that cause interruptions to gambling", including, where appropriate, the capability to void gambles with or without manual intervention, to suspend betting markets and to take all reasonable steps to retain enough information to restore an event to its pre-failure state. The guidance settles the default: where the operator has received the gamble and the customer can no longer influence the outcome, the result stands. Where a single-stage event is interrupted before an outcome exists, the stake goes back. Persisting round state with the RNG draw already committed is what makes either outcome provable.

Limits, reality checks and product design: RTS 12 to 14

The customer-led tools in RTS 12 and in 13A and 13B are product-tested by the licensee before release, never by a test house, and 13C is verified on the live product. RTS 12 opens with availability: "The gambling system must provide easily accessible facilities for customers to set their own financial limits at any time from the point of registration."

For the platform that is a limit state machine with clocks: an increase waits out a cooling-off of at least 24 hours and a positive confirmation at its end, while a reduction applies immediately. The guidance expects the periods on offer to include 24 hours, 7 days and one month, with the lowest applying where several run at once.

What changed in RTS 12B: the Commission split its financial-limit changes into two phases. Phase one is the RTS 12 text above, in force since October 2025. Phase two concerns gross deposit limits: operators must offer or re-introduce a gross deposit limit, only a gross limit may be called a deposit limit, it must have at least equal prominence, the gambling system must block further deposits at the limit until the period restarts or an increase clears its cooling-off and gross deposit limits must be offered over fixed time frames, and net deposit limit becomes a defined term for a limit on deposits minus withdrawals over the limit period. The platform implements each of those for the licensee. The RTS upcoming changes page gives the regulator's published effect date, "The new elements of RTS 12B requirements and implementation guidance will come into effect on 30 September 2026.", and its change log records that the date moved from 30 June 2026, so the June date in older change logs and blog copy on the same site is not a second deadline.

RTS 13 covers time in the client, and the guidance is explicit about auto-play: "The reality check must prevent a new game within an auto-play sequence from commencing until the player has acknowledged the reality check." In the client that is a blocking prompt inside the auto-play loop, dismissed only by an acknowledgement.

RTS 14 is the pacing standard, and on the cashier side its rule is one sentence: "Consumers must not be given the option to cancel their withdrawal request." The guidance adds that funds requested for withdrawal must not be offered back for deposit. For the platform the pacing rules are game configuration under change control and the withdrawal rule is a cashier with no cancel control.

Security requirements and the security audit

Section 4 of the UKGC technical standards is not a bespoke security standard. Its page states that "The Commission has based the security requirements on the relevant sections of Annex A to the ISO/IEC 27001:2022 standard." That 2022 edition replaces 2013, and the requirements are scoped to critical systems: those holding sensitive customer information such as card details, authentication data and balances, those generating or processing the random numbers behind game outcomes, those storing results or the current state of a gamble, their entry and exit points and the communication networks that carry sensitive customer information. In platform terms that is the wallet, the identity service, the RNG, the game state store and every gateway in front of them.

Control family	ISO/IEC 27001:2022 Annex A controls in scope
Organizational	5.1, 5.10, 5.15, 5.16, 5.17, 5.18, 5.19, 5.20, 5.21, 5.22, 5.23, 5.24, 5.25, 5.26, 5.28, 5.35
People	6.3, 6.5, 6.7, 6.8
Physical	7.8, 7.10, 7.14
Technological	8.1, 8.2, 8.3, 8.5, 8.7, 8.13, 8.15, 8.17, 8.18, 8.20, 8.21, 8.22, 8.24, 8.25, 8.26, 8.27, 8.29, 8.30, 8.31, 8.32, 8.33

The run from 8.25 to 8.33 shapes delivery, from the secure development life cycle through separated environments to change management, and the supplier controls 5.19 to 5.23 are where third-party game content, payment providers and hosting fall within the scope. RTS 16 is about player-side software in peer-to-peer products and says nothing about vendors.

The annex lists the license categories that need the full audit: remote betting other than telephone-only and trading-room licenses, remote casino, remote bingo, all host licenses and remote lotteries with entries above £250,000 a year. A gambling software license is not on that list. For those categories the audit is annual and independent, and unlike game testing it is not tied to an approved list: the Commission does not intend to approve security audit firms, so the licensee satisfies itself that the auditor is reputable, independent and qualified against ISO/IEC 27001:2022. The audit report stays on file with two clocks attached. The testing strategy sets the first: "Where major non-conformities are identified during a security audit, the licensee must submit a copy of the security audit to the Commission within 7 days of its receipt." On request, the same 7 days run from the Commission's request.

New licensees carry a third. The security audit advice states that "Newly licensed remote gambling operators with one or more of the above licences must complete and provide their first security audit within 6 months of the granted licence, by a due date set by the Commission." The same page names ISO 27001 Lead Auditor, CISA, CISM and CISSP as certifications that may demonstrate an auditor's suitability. An audit against PCI DSS or another standard may overlap provided the scope covers section 4 of the RTS.

Testing strategy and test-house certification

The testing strategy is the document license condition 2.3.1 points at. Its summary sets the release gate: "Licensees must ensure that all new products have been adequately tested by an approved test house prior to release", and the Commission maintains the list of approved test houses.

Table 1 on the approach page is the allocation: "For those requirements identified in the final column, external testing must be assessed by an independent third party." Those rows are the RNG, the game and jackpot math, live RTP monitoring, live dealer operations and the security audit.

The procedure page fixes the release order: no new game or RNG goes live until testing is complete and the report has been provided to the Commission. The game report carries at least a certificate reference, the game name, RTP, software number and digital signature, the tests applied, the platform supplier and platform version, the channels covered, the result and any versions superseded, which is why a platform version string has to be stable and reportable. Reports go to the licensee's games register in eServices, and a platform or RNG change means retesting a representative sample of games.

Every later change is classified. Annex A of the strategy draws the line: "A major update, which will require external retesting by an approved test house, is any software change which may affect the fairness of a game." Fairness elements are the RNG, the scaling and mapping layer and the game rules including how the software processes them, so a performance fix that changes the implementation of a rule is major even though no rule changed. A new sound format or replaced artwork is minor and tested internally. The good-practice page expects the testers to be separate from the developers, in separate development and testing environments. The annual games testing audit, by an approved test house, samples major and minor updates to confirm the classification and checks that live RTP monitoring works: wherever possible an automatic backend process that alerts when actual RTP leaves tolerance, and never aggregated so far that an error at a lower level disappears. Our game development guide covers the build pipeline that feeds this flow.

GAMSTOP integration as platform design

Social responsibility code 3.5.5 is one sentence: "Licensees must participate in the national multi-operator self-exclusion scheme." It applies to remote licenses generally and its exclusions include gambling software and host licenses, so the duty sits with the B2C operator while the platform carries the mechanism. The register behind the scheme is GAMSTOP, whose pages state that all operators are required to check whether their customers are registered with it.

What GAMSTOP publishes about the operator side comes from its privacy policy: "Operators must undertake checks on a daily basis and every time a customer attempts to login or register for an account." On the data: "To undertake these checks, operators send their customers’ data to us. The data we receive from operators is hashed and we only store this information as long as is necessary to perform the check and let the operator know if there is a match." On a match the operator should prevent access, after removal the register flags the person to operators for seven years without requiring a block and an incorrect identification can be reported back, after which the register may store data to stop it recurring.

Everything else is platform design, not a GAMSTOP rule. Run the check synchronously at registration and at every login before a session is issued, fail closed when the register cannot be reached and schedule the daily re-check as a batch job over the active customer base. Normalize the fields sent on every call, route an unclear answer or a disputed block to a manual review queue, restrict which hosts may make the call, rotate the credentials and log every call with its input and result, keeping the register's answer only as a decision and an audit record. A previously self-excluded flag inside the seven-year window is an input to the operator's customer interaction rules, not an automatic block.

How the MGA compares: system audit and review

The Malta Gaming Authority reaches the same ground by a different route: approved Audit Service Providers run a System Audit around licensing and, later, a System Review against the live system. Its regulatory update on the revised checklists states that "System Reviews will generally be required one year after issuance of a new licence, or within a shorter time frame if a system audit was not required at licence issuance stage." The review runs on the live environment with the licensee's staff demonstrating functionality, and the checklist is split into four variants for B2C, B2C with DLT, B2B and B2B software.

Directive 3 of 2018 defines the critical components, the components hosting random number generators, jackpots and games, the gaming, player and financial databases and the control system, and the key technical setup, with audit logs of any change to that setup kept for at least two years. The practical difference is the unit of evidence: the Commission's flow certifies games and RNGs individually and audits security annually, while the MGA's audits the system as declared and then reviews it live.

How Pharos Production helps

We build all three product shapes the RTS reach. An online casino platform such as the Gambit Stream online casino platform carries most of the standards in its wallet, game state store and customer-led tools. A sportsbook such as the Gambit Stream sportsbook platform carries them in bet acceptance, price-change handling and market suspension. A games aggregator such as the Lucky Bets casino games aggregator is where third-party game builds, their versions and their change records meet the platform.

If you are scoping a platform for a Commission license, our gaming software development team can map the UKGC technical standards to the behavior, the test and the record each needs.

Sources: the Gambling Commission's Remote gambling and software technical standards (sections 1 to 5, the section 3 contents list and the pages for RTS 1 to 4, 6 to 10, 12 to 14 and 16), LCCP condition 2.3.1 and code 3.5.5, testing strategy (sections 1 to 8), security audit advice and RTS upcoming changes page. GAMSTOP privacy policy. Malta Gaming Authority regulatory update of 14 November 2022 and Directive 3 of 2018. Read on 16 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: October 4, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• What are the UKGC technical standards?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  They are the Remote gambling and software technical standards, a document the Gambling Commission issues under the Gambling Act 2005 with seventeen numbered standards, a security section and an annex mapping standards to product types. License condition 2.3.1 of the LCCP binds remote operating licenses and gambling software licenses to them and to the Commission's testing strategy, so a shortfall is a license-condition breach rather than a technical defect.

• Which RTS requirements need an independent test house?

  Copy link Copies a direct link to this answer to your clipboard.

  Table 1 of the testing strategy marks the rows that need independent assessment: the random number generator under RTS 7A, the game implementation under RTS 7B, 7C and 7E together with the jackpot math under RTS 9B(b) and 9B(d), the live RTP monitoring measures under RTS 5A, live dealer operations under RTS 17A and the security requirements, which are covered by an annual security audit. Every other requirement is either product-tested by the licensee before release or verified by the licensee as present on the live product, and RTS 12, 13A and 13B are in the first group.

• Is ISO 27001 certification required by the RTS security requirements?

  Copy link Copies a direct link to this answer to your clipboard.

  Certification is not what the pages ask for. The security requirements are a selected set of Annex A controls from ISO/IEC 27001:2022, applied to the critical systems that hold sensitive customer data, generate random numbers or store game state, and an independent auditor the licensee chooses checks them in an annual security audit required for the license categories the annex lists, which do not include gambling software licenses.

  An audit against another standard such as PCI DSS may overlap, provided the scope covers section 4 of the RTS.

• How often must a platform check customers against GAMSTOP?

  Copy link Copies a direct link to this answer to your clipboard.

  GAMSTOP's published rule for operators is a check once a day and at every login or registration attempt. The operator sends customer data for the check, the register states that the data it receives is hashed and kept only as long as the check takes, and it tells the operator whether there is a match.

  On a match the operator should prevent access, and after a self-exclusion ends the register flags the person for seven years without requiring a block. How the platform schedules the daily batch and handles an unclear answer is its own design.

• What counts as a major update that needs retesting?

  Copy link Copies a direct link to this answer to your clipboard.

  Annex A of the testing strategy defines a major update as any software change that may affect the fairness of a game, meaning the random number generator, the scaling and mapping layer or the game rules and how the software processes them, and it requires external retesting by an approved test house. A new sound format or replaced artwork is minor and tested internally, and the annual games testing audit samples both kinds to confirm the classification.

• How do the MGA technical requirements differ from the RTS?

  Copy link Copies a direct link to this answer to your clipboard.

  The Malta Gaming Authority audits the whole system rather than certifying games one by one: approved Audit Service Providers carry out a System Audit around licensing and a System Review on the live environment, generally one year after a new license is issued, using checklists split by license type. Directive 3 of 2018 defines the critical components, from the RNG, jackpot and game hosts to the gaming, player and financial databases and the control system, and requires audit logs of changes to the key technical setup to be kept for at least two years.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.