Skip to content
Showing all 49 standards
RTS-1
Part RTS-1

RTS 1 Customer account information

Enable customers to easily access balance, history, and net-deposit information.

3 standards 3 player-flagged
100%
player-flagged
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 Rights RG 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 Rights RG 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 standards 5 player-flagged
100%
player-flagged
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 Rights Game 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 Rights Game 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 Rights Affiliate 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 Rights RG 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 standards 4 player-flagged
100%
player-flagged
RTS 3A

Availability of rules explanation

Player Rights Game 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 Rights Game 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 Rights Game 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 Rights Game 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 standards 2 player-flagged
100%
player-flagged
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.

Requirements
  • Estimate network latency; surface disadvantage information.
  • Apply handicapping or equal-treatment policies for simultaneous winning responses.
RTS 4B

Customer notification of technical disadvantage

Player Rights Game 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 standard 1 player-flagged
100%
player-flagged
RTS 5A

Rules implementation and error handling

Game Design Player 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 standard 1 player-flagged
100%
player-flagged
RTS 6A

Parity between play-for-free and play-for-money

Player Rights Game Design Bonus & 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 standards 5 player-flagged
100%
player-flagged
RTS 7A

Acceptably random RNG

Player Rights Game 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 Rights Game 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 Rights Game 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 Rights Game 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 standard 1 player-flagged
100%
player-flagged
RTS 8A

Individual game cycle commitment

RG Critical Game 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 standards 2 player-flagged
100%
player-flagged
RTS 9A

Jackpot rules availability

Player Rights Game Design

An explanation of the jackpot rules must be clearly available before the customer commits.

Requirements
  • Rules describe funding, seed, ceiling, combined/split RTP (base + jackpot).
  • Indicate ineligible-player RTPs.
  • Describe prize determination including simultaneous-trigger policy.
  • Explain ceiling overflow handling.
RTS 9B

Jackpot system fairness and security

Player Rights Game 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 standards 3 player-flagged
100%
player-flagged
RTS 10A

Fair service interruption policies

Player Rights Game 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.

Requirements
  • Void gambles automatically with manual controls.
  • Maintain card-deck state, collected tokens, progressive jackpot values, gamble states, placed bets.
  • Peer-to-peer betting: enable manual/automatic market suspension.
RTS 10C

Customer information on interruption policies

Player Rights

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 standards 2 player-flagged
100%
player-flagged
RTS 11A

Prevention, detection, investigation

Game Design Player 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.
  • Detect table-sharing, same-address players, chip dumping, unusual statistics.
  • Maintain investigation records: player details, offense scale, timeframe, outcome, evidence.
RTS 11B

Customer information on cheating policies

Player Rights Game 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 standards 5 player-flagged
100%
player-flagged
RTS 12A

Accessible limit-setting and registration prompts

RG Critical Player 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 Critical Player 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 Critical Player 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 Critical Player 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 Critical Player 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 standards 3 player-flagged
100%
player-flagged
RTS 13A

Time display in full-screen applications

RG Critical Player 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 Critical Player 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 Critical Player 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 standards 7 player-flagged
100%
player-flagged
RTS 14A

Prohibition on encouraging continuation and loss-chasing

RG Critical Bonus & 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 Critical Player 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 Critical Game 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 Critical Game 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 Critical Game 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 Critical Game 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.
RTS 14G

Minimum game-cycle duration, casino (excl. slots, P2P poker)

RG Critical Game Design

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 standard 1 player-flagged
100%
player-flagged
RTS 15A

Live broadcast delay disclosure

Player Rights Game 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 standards 3 player-flagged
100%
player-flagged
RTS 16A

Disclosure of bot/third-party software against customers

Player Rights Affiliate Rules Game 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 Rules Player 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 Rights Affiliate Rules Game 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 standard 1 player-flagged
100%
player-flagged
RTS 17A

Fair and independently auditable operations

Player Rights Game 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.