Remote gambling and software technical standards (RTS)
Remote gambling and software technical standards under section 89 and section 97 of the Gambling Act 2005.
- 1 - Introduction
- 2 - Definition of terms
3 - Remote gambling and software technical standards
- - RTS 1 – Customer account information
- - RTS 2 – Displaying transactions
- - RTS 3 – Rules, game descriptions and the likelihood of winning
- - RTS 4 – Time-critical events
- - RTS 5 – Result determination
- - RTS 6 – Result determination for play-for-free games
- - RTS 7 – Generation of random outcomes
- - RTS 8 – Auto-play functionality
- - RTS 9 – Progressive jackpot systems
- - RTS 10 – Interrupted gambling
- - RTS 11 – Limiting collusion and cheating
- - RTS 12 – Financial limits
- - RTS 13 – Time requirements and reality checks
- - RTS 14 – Responsible product design
- - RTS 15 – In-play betting
- - RTS 16 – Use of third party software
- - RTS 17 – Live dealer studios
- 4 - Remote gambling and software technical standards (RTS) security requirements
- 5 - Annex
RTS 9 – Progressive jackpot systems
Gaming (including bingo)
RTS aim 9
To ensure that progressive jackpot systems operate fairly.
RTS requirement 9A
An explanation of the jackpot rules must be clearly available to the customer before they commit to gamble.
RTS implementation guidance 9A
- The rules for a jackpot shall describe how it is funded, what the start-up seed and any ceiling values are. The jackpot system’s return to player percentage should be displayed as per RTS 3C, this could be one combined game and progressive jackpot RTP figure or broken down into the base game and jackpot component. If a player is not eligible for a game’s progressive jackpot prize this should be made clear, along with their respective theoretical RTP.
- The rules for a jackpot shall describe how the prizes are determined and awarded, including what happens when two or more players simultaneously trigger the same jackpot, or appear to simultaneously trigger the jackpot, for example due to network latency issues.
- All eligible players should be able to see the current jackpot values and these should be updated as frequently as is practicable, particularly after the amount has been reset following a win.
- Where a jackpot is capped at a ceiling value, an explanation of how subsequent player contributions are handled should be provided (eg the operation of any redirected overflow or reserve pools).
RTS requirement 9B
Jackpot systems must be configured and operated with adequate fairness and security.
RTS implementation guidance 9B
- The gambling system shall maintain strict access and logging controls over the configuration and changes made to live jackpots.
- Where a customer contributes to a jackpot pool, that customer should be eligible to win the jackpot whilst they are playing that game. The chances of winning a jackpot should increase in correlation with the amount contributed.
- Where a jackpot containing player contributions is decommissioned those contributions need to be returned fairly according to the circumstances, with priority given to the players who made the contributions. Some example methods to achieve this include:
- waiting until the jackpot is next awarded before decommissioning it.
- adding any remaining contributions onto another jackpot system, preferably one with a similar player base.
- returning remaining contributions as a one off event, with adequate customer disclosure to explain the origin of money.
- The gambling system shall ensure that a winning customer is notified of a jackpot win immediately after it is triggered and that other participating customers are adequately notified of the jackpots reset value.
RTS 8 – Auto-play functionality Next section
RTS 10 – Interrupted gambling
Last updated: 1 February 2021
Show updates to this content
No changes to show.