UK Gambling Commission, Remote Technical Standards — Standards Explorer
All 49 UK remote gambling standards, organised by part
The UKGC's Remote Technical Standards are the technical rulebook for UK-licensed remote gambling software, covering account information, game fairness, RNGs, time and financial controls, responsible product design, and the security of critical systems.
Enable customers to easily access balance, history, and net-deposit information.
3 standards3 player-flagged
100%
player-flagged
RTS 1 Customer account information 3
RTS 1A
Display of current account balance
Player Rights
Gambling and money-movement pages must display the customer's current balance, in their account currency, whenever the customer is logged in.
Requirements
Balance appears on gambling pages or via easily accessible link.
Telephone betting: balance provided on customer request via agent or automated system.
For restricted-display devices, ensure balance is reachable via a menu link.
RTS 1B
Access to account and gambling history
Player RightsRG Critical
Customers must have easy access to at least three months of account and gambling history without contacting the licensee; a minimum of 12 months must be available on request.
Requirements
History includes deposits/withdrawals, bets/results, gaming summaries, fund movements, transaction totals.
Telephone/restricted channels: statements via email/post acceptable if customer has online access; otherwise regular statements required.
RTS 1C
Net deposits information
Player RightsRG Critical
Customers must be able to access information about their net deposits, lifetime total deposits minus withdrawals, at account level.
Requirements
Display at account level from April 1 2018 minimum.
Include explanatory information about the timeframe covered.
RTS-2
Part RTS-2
RTS 2 Displaying transactions
Make the amount wagered, the content of the gamble, and net position unambiguous to the customer.
5 standards5 player-flagged
100%
player-flagged
RTS 2 Displaying transactions 5
RTS 2A
Clear information about gambling amount
Player Rights
The gambling system must make available clear information about the amount of money being gambled, including any currency-to-credit or currency-to-currency conversions at the point of conversion.
Requirements
Show unit/total stake, entry fees, lottery ticket details.
Telephone gambling: delivered via agent or automated system.
RTS 2B
Relevant gamble information before commitment
Player RightsGame Design
Sufficient relevant information about the customer's gamble must be made available before the customer commits, so the content of the gamble is clear.
Requirements
Include selections, bet type, odds format.
Telephone betting: read back bet before confirmation.
Customer may not suppress information via third-party interface as default.
RTS 2C
Price fluctuation options
Player RightsGame Design
The gambling system must enable customers to choose whether to accept price fluctuations that occur after their bet is requested.
Requirements
Options per bet, unless customer sets account-level default.
Default must not accept all fluctuations automatically.
Offer: accept higher prices; accept shorter prices; accept all changes.
RTS 2D
Third-party interface warning
Player RightsAffiliate Rules
Customers using third-party user interfaces must be informed that those interfaces may not display full information about their gambles.
Requirements
Include notice in terms/conditions or product rules.
RTS 2E
Net position display (casino)
Player RightsRG Critical
All gaming sessions must clearly display a customer's net position since the session began, in the currency of their account or product.
Requirements
Net position = total winnings minus total losses since session commencement.
RTS-3
Part RTS-3
RTS 3 Rules, game descriptions, and likelihood of winning
Enable informed decisions about chances of winning, game mechanics, prizes, and game state.
4 standards4 player-flagged
100%
player-flagged
RTS 3 Rules, game descriptions, and likelihood of winning 4
RTS 3A
Availability of rules explanation
Player RightsGame Design
An explanation of the applicable rules must be easily available before the customer commits. Artwork and text must be accurate and sufficient to explain all applicable rules and how to participate.
Requirements
Rules inside games or on help/how-to pages; prominent links from home or game menu.
Restricted devices: menu access minimum.
Cover game name, winning definitions, play restrictions, deck counts, jackpot mechanics, bonus rules, lottery entry/draw frequency.
RTS 3B
Current game state information
Player RightsGame Design
Where relevant, information that enables the customer to understand the current state of the game or event must be displayed as play progresses.
Requirements
Collected tokens/symbols; active rules/features; current-state indicators.
Does not apply to lotteries.
RTS 3C
Information about winning chances
Player RightsGame Design
For every virtual event, game or lottery, information sufficient to let customers make an informed decision about chances of winning must be easily available before commitment, including game mechanics, house edge/margin, and RTP or probability of winning events.
Requirements
Peer-to-peer: description of mechanics sufficient.
Bingo/lotteries with participant-dependent odds: prize-allocation description acceptable.
Provide average theoretical RTP; display odds reflecting event probabilities.
RTS 3D
Prize and payout information
Player RightsGame Design
For every game or lottery, content describing potential prizes and payouts (or how they are calculated) must be easily available before the customer commits.
Requirements
Show pay-tables or odds paid.
Peer-to-peer: describe mechanics plus rake/commission.
Progressive jackpots: update displays frequently, especially after resets.
RTS-4
Part RTS-4
RTS 4 Time-critical events
Reduce unfair technical disadvantage risk and inform customers of speed-of-response risks.
2 standards2 player-flagged
100%
player-flagged
RTS 4 Time-critical events 2
RTS 4A
Risk assessment for speed-based outcomes
Game Design
Where speed of interaction significantly affects the chance of winning, operators must assess the level of risk and demonstrate to the Commission that they are taking reasonable steps to reduce risk to customers.
Apply handicapping or equal-treatment policies for simultaneous winning responses.
RTS 4B
Customer notification of technical disadvantage
Player RightsGame Design
For time-critical events, the customer should be informed that they might be at a disadvantage due to technical issues such as slower network speeds or device performance.
Requirements
Include notifications in game descriptions, rules, help, or how-to-play pages.
RTS-5
Part RTS-5
RTS 5 Result determination
Ensure gambling systems implement operator, game, and betting rules as described to customers.
1 standard1 player-flagged
100%
player-flagged
RTS 5 Result determination 1
RTS 5A
Rules implementation and error handling
Game DesignPlayer Rights
All reasonable steps must be taken to ensure gambles are accepted, processed and settled per the operator's published terms and rules and per the rules of the specific game, event, or bet. Where unexpected system flaws or errors affect a customer, remediation must happen as soon as practicable.
Requirements
Test against published rules; monitor live performance.
Notify customers of errors affecting them as soon as practicable and rectify (for example via manual account adjustment).
RTS-6
Part RTS-6
RTS 6 Result determination for play-for-free games
Minimise misleading information about winning likelihood in demonstration games.
1 standard1 player-flagged
100%
player-flagged
RTS 6 Result determination for play-for-free games 1
RTS 6A
Parity between play-for-free and play-for-money
Player RightsGame DesignBonus & Ads
Play-for-free games must use the same game rules as the corresponding play-for-money games, and must accurately represent winning likelihood and prize distribution.
Requirements
Use identical RNG or a publicly available unbiased RNG.
Prize distributions must match (virtual cash payouts identical, token allocations proportionate).
Disclose edited/sped-up footage in promotional videos; identify demonstration-only high-return versions.
RTS-7
Part RTS-7
RTS 7 Generation of random outcomes
Ensure games and virtual events operate fairly and cannot be rigged against the player.
5 standards5 player-flagged
100%
player-flagged
RTS 7 Generation of random outcomes 5
RTS 7A
Acceptably random RNG
Player RightsGame Design
Random number generation and game results must be acceptably random. Adaptive behaviour (a compensated game) is not permitted. External-event lotteries must use outcomes that are unpredictable and externally verifiable.
Requirements
RNGs must demonstrate uniform distribution, unpredictability, non-cycling, fair seeding, and maintained scaling quality.
Mechanical RNGs must use durable materials and prevent player interaction/manipulation.
RTS 7B
Fair implementation according to rules
Player RightsGame Design
Games and events must be implemented fairly and in accordance with the rules and prevailing payouts as described to the customer.
Requirements
Map random inputs to outcomes per prevailing probabilities and pay-tables.
Use random numbers in received order without discarding based on adaptive behaviour.
Log and investigate numbers falling outside expected ranges, do not discard.
RTS 7C
Prevention of misleading game design
Player RightsGame Design
Game designs that may reasonably be expected to mislead customers about the likelihood of particular results, including substituting losing events with near-miss losing events, or simulations that do not reflect real device probabilities, are not permitted.
Requirements
Virtual device simulations must match real-device probabilities (e.g., fair coin tosses at 0.5).
Prohibit false near-miss displays substituting one losing outcome for another.
Predetermined layouts (hidden prizes) must not shift except per rules.
RTS 7D
Protection against unannounced rule changes
Player RightsGame Design
Rules, payouts, and outcome probabilities may not be changed while a virtual event or game is available for gambling, except as provided for in the rules. Changes must be brought to the customer's attention.
Requirements
Changes require taking the game offline or suspending it.
Changed games must display 'rules changed' / 'new odds' / 'different payouts' notices on selection screens and within events.
Blanket 'change any time' provisions are not acceptable.
RTS 7E
Result display duration
Game Design
Except in subscription lotteries, the system must clearly and accurately display the result of the game or event and the customer's gamble, for a length of time sufficient for the customer to understand the result.
Requirements
Artwork and text must convey loss/win status and winning value.
RTS-8
Part RTS-8
RTS 8 Auto-play
Auto-play is not permitted for online gaming, every game cycle requires customer commitment.
1 standard1 player-flagged
100%
player-flagged
RTS 8 Auto-play 1
RTS 8A
Individual game cycle commitment
RG CriticalGame Design
The gambling system must require a customer to commit to each game cycle individually.
Requirements
Does not prohibit automatic blind posting in peer-to-peer poker.
RTS-9
Part RTS-9
RTS 9 Progressive jackpot systems
Ensure progressive jackpot systems operate fairly and securely.
2 standards2 player-flagged
100%
player-flagged
RTS 9 Progressive jackpot systems 2
RTS 9A
Jackpot rules availability
Player RightsGame Design
An explanation of the jackpot rules must be clearly available before the customer commits.
Describe prize determination including simultaneous-trigger policy.
Explain ceiling overflow handling.
RTS 9B
Jackpot system fairness and security
Player RightsGame Design
Jackpot systems must be configured and operated with adequate fairness and security.
Requirements
Strict access and logging controls over live jackpot configuration/changes.
Odds should correlate with contribution amounts.
For decommissioned contributor-funded jackpots, return contributions fairly.
RTS-10
Part RTS-10
RTS 10 Interrupted gambling
Ensure fair treatment during service interruptions and inform customers of interruption policies.
3 standards3 player-flagged
100%
player-flagged
RTS 10 Interrupted gambling 3
RTS 10A
Fair service interruption policies
Player RightsGame Design
Operators must take all reasonable steps to ensure that their policies for dealing with service interruptions are fair and do not systematically disadvantage customers.
Requirements
Gaming: outcomes stand if received pre-interruption and customer can no longer influence; return stakes for interruptions before outcome generation in single-participant events.
Restore stateful games to last known state; restore progressive jackpots to pre-failure values.
RTS 10B
System recovery capabilities
Game Design
Systems must be capable of recovering from failures that cause interruptions, including voiding gambles, suspending betting markets, and retaining sufficient information to restore events to their pre-failure state.
Operators must make information available about their policies regarding service interruptions in various different circumstances.
Requirements
Provide information on common-scenario treatment without exhaustive scenario detail.
RTS-11
Part RTS-11
RTS 11 Limiting collusion and cheating
Reduce collusion and cheating harm and inform customers of risks and reporting channels.
2 standards2 player-flagged
100%
player-flagged
RTS 11 Limiting collusion and cheating 2
RTS 11A
Prevention, detection, investigation
Game DesignPlayer Rights
Measures to deter, prevent, and detect collusion and cheating must be implemented. The system must retain a record of relevant activities and be capable of suspending or disabling player accounts or sessions. Operators must monitor effectiveness of policies and procedures.
Requirements
Record table associations, win/loss patterns, game-level activities.
Maintain investigation records: player details, offense scale, timeframe, outcome, evidence.
RTS 11B
Customer information on cheating policies
Player RightsGame Design
Information must be made available about the operator's policies and procedures with regard to cheating, recovered player funds, and how to complain if a customer suspects other participants are cheating.
Requirements
Inform customers that account closure results from cheating.
Describe recovered-funds policy aims.
Include in terms, conditions, or rules.
RTS-12
Part RTS-12
RTS 12 Financial limits
Provide all customers with budget-management tools and sensible defaults.
5 standards5 player-flagged
100%
player-flagged
RTS 12 Financial limits 5
RTS 12A
Accessible limit-setting and registration prompts
RG CriticalPlayer Rights
The gambling system must provide easily accessible facilities for customers to set their own financial limits at any time from the point of registration, and must prompt customers to set a limit as part of registration or at the point of the first deposit.
Requirements
Offer deposit, spend, or loss limits over 24-hour / 7-day / monthly periods.
Implement the limit as soon as practicable; inform the customer when it comes into force.
Where multiple timeframes apply, the lowest limit governs.
RTS 12B
Free-text limit input and account-level minimums
RG CriticalPlayer Rights
Customers must be presented with a free-text box to set a limit (or equivalent for telephone gambling). Limits must be applied at the account level as a minimum.
Requirements
May add product/channel limits; clarify which level applies.
Provide interaction clarity for simultaneous timeframes.
Allow whole-pound or similar increments to mitigate user error.
RTS 12C
Prominent accessibility of limit facilities
RG CriticalPlayer Rights
Financial-limit facilities must be reachable via a direct link on the homepage and be clearly visible and accessible; also on deposit pages. Number of clicks to reach them must be minimised.
Requirements
Email/notification links to limit facilities should not route via intermediate pages.
RTS 12D
Limit increase cooling-off and reduction immediacy
RG CriticalPlayer Rights
Customer-led limit increases require a 24-hour cooling-off period plus positive customer action to confirm. Reductions must be implemented immediately. Customers must be prompted to review account/transaction information at least every six months (for accounts with activity in rolling 12 months).
Requirements
On system-failure delaying reductions, inform the customer when the reduction takes effect.
Monitor alert engagement to inform design.
Allow customers to set more frequent reminders.
RTS 12E
Default limit-setting and annual review
RG CriticalPlayer Rights
Financial-limit-setting must present setting a limit as the default choice. Customers must actively opt out, and existing limit-free accounts must be prompted to review annually.
Requirements
Default via pre-selected fields or visual distinction; require active opt-out and confirmation.
Offer opt-out customers links to budgeting tools and safer-gambling resources.
RTS-13
Part RTS-13
RTS 13 Time requirements and reality checks
Provide tools to track gambling time, including mandatory reality-check prompts.
3 standards3 player-flagged
100%
player-flagged
RTS 13 Time requirements and reality checks 3
RTS 13A
Time display in full-screen applications
RG CriticalPlayer Rights
Where the gambling system uses full-screen client applications that obscure the device clock, the client itself must display the time of day or elapsed time since start, wherever practicable.
Requirements
Display time from device or server in hours/minutes.
Restricted devices should display time where supported.
RTS 13B
Reality-check frequency and display
RG CriticalPlayer Rights
The gambling system must provide easily accessible facilities for customers to set the frequency at which they receive a reality check (display of elapsed session time). The customer must acknowledge the reality check for it to be removed from the screen.
Requirements
Offer amend options at all times; customer-selectable frequency with a sensible default.
Position checks at game-end; prevent a new game or auto-play until acknowledged.
Include account-history links and session-exit options.
RTS 13C
Continuous elapsed-time display
RG CriticalPlayer Rights
The elapsed time should be displayed for the duration of the gaming session.
Requirements
Begin at game-open or play-start; display in seconds, minutes, hours.
RTS-14
Part RTS-14
RTS 14 Responsible product design
Ensure responsible design that does not encourage chasing, continuation, or exploitation.
7 standards7 player-flagged
100%
player-flagged
RTS 14 Responsible product design 7
RTS 14A
Prohibition on encouraging continuation and loss-chasing
RG CriticalBonus & Ads
Gambling products must not actively encourage customers to chase losses, increase their stake, or continue to gamble after they have indicated they wish to stop.
Requirements
Prohibit automatic fund top-ups without per-instance choice (e.g., auto-buy chips at poker).
Prohibit loss-recovery text/graphics.
Prohibit exit-game incentives (free games).
RTS 14B
Withdrawal request cancellation prohibition
RG CriticalPlayer Rights
Customers must not be given the option to cancel their withdrawal request.
Requirements
Prevent fund redeposit after withdrawal request; minimise withdrawal friction.
RTS 14C
Prohibition on simultaneous multi-game play
RG CriticalGame Design
The gambling system must not offer functionality which facilitates playing multiple games at the same time.
Requirements
Prohibit split/multi-screen or combined-game interfaces enabling simultaneous play.
RTS 14D
Minimum game-cycle duration, slots
RG CriticalGame Design
Minimum of 2.5 seconds from the time a slots game is started until the next cycle can commence. The customer must release and then depress the start button (or equivalent) to commence a new cycle.
Requirements
Game cycle: starts on button depression; ends when all staked/won money lost or delivered.
Continued contact must not initiate new cycles.
RTS 14E
Prohibition on result-timing reduction
RG CriticalGame Design
The system must not permit a customer to reduce the time until the result is presented, turbo/quick-spin/slam-stop features are prohibited for all remote games regardless of base cycle speed.
Requirements
Does not apply to bonus/feature games without additional stakes.
Does not prohibit scratch-all/reveal-all or games lost unless the player acts.
RTS 14F
No celebration of below-stake returns
RG CriticalGame Design
The gambling system must not celebrate a return which is less than or equal to the total stake gambled.
Requirements
Celebrate = audio/visual win-association effects prohibited for returns <= last total stake.
Display total-awarded amounts, winning-line displays, or brief result-indicating sounds is fine.
Minimum of 5 seconds from the time a casino game is started until the next cycle can commence. Release-and-depress start-button (or equivalent) required.
Requirements
Same cycle mechanics as RTS 14D.
RTS-15
Part RTS-15
RTS 15 In-play betting
Make customers aware of information-lag disadvantages when betting on delayed broadcasts.
1 standard1 player-flagged
100%
player-flagged
RTS 15 In-play betting 1
RTS 15A
Live broadcast delay disclosure
Player RightsGame Design
Information must be made available explaining that live TV or other broadcasts are delayed and that others may have more up-to-date information. Main in-play betting pages must include this information where practicable.
Requirements
Include a brief notice on main in-play pages/screens; detail on help/how-to/product pages.
Telephone betting: include in general product information.
RTS-16
Part RTS-16
RTS 16 Use of third-party software
Inform peer-to-peer customers of bot and assisted-play possibilities.
3 standards3 player-flagged
100%
player-flagged
RTS 16 Use of third-party software 3
RTS 16A
Disclosure of bot/third-party software against customers
Player RightsAffiliate RulesGame Design
Where peer-to-peer customers may gamble against programs deployed by other customers or assisted by third-party software, information must be made available describing the possibility and, if prohibited, how to report suspected use.
Requirements
Include warnings and complaint procedures in game descriptions, rules, terms, help, how-to, or product-information pages.
RTS 16B
Third-party software permissibility clarity and enforcement
Affiliate RulesPlayer Rights
Operators must make clear whether third-party software is permitted and if so which types; operators prohibiting certain types must implement measures to deter, prevent, and detect their use.
Requirements
Describe key features of prohibited categories; exhaustive lists unnecessary.
RTS 16C
Operator-deployed bot disclosure
Player RightsAffiliate RulesGame Design
Where operators use programs to participate in gambling on their behalf in peer-to-peer gambling, easily accessible information must be displayed which clearly informs customers that the operator uses this kind of software.
Requirements
Display notices on home pages/screens, game descriptions, help, how-to-play/bet pages.
RTS-17
Part RTS-17
RTS 17 Live dealer studios
Ensure live dealer operations are fair and independently auditable.
1 standard1 player-flagged
100%
player-flagged
RTS 17 Live dealer studios 1
RTS 17A
Fair and independently auditable operations
Player RightsGame Design
Live dealer operations must be fair and independently auditable.
Requirements
Use commercial casino-quality equipment/consumables with designated monitoring staff.
Require croupier training per documented procedures/rules; maintain evidence.
Supervise via video surveillance with sufficient detail to confirm rule adherence.
Protect secure areas; authorised personnel only.
Maintain game logs; analyse collated statistics for trends.