2 - Definition of terms
2.1 In this document the following terms have the following meanings.
All links open in a new tab.
Compensated games or events
Games or virtual events that adjust the likelihood of winning outcomes occurring based on previous payouts or intake. Sometimes referred to as adaptive behaviour or percentage compensation.
Easily accessible
This term generally means the facilities or information is either on the screen, or can be intuitively accessed via efficient navigation or other means.
Game
A game of chance as defined in section 6(2) of the Gambling Act 2005 (the Act).
Gambling
The Gambling Act 2005 defines gambling as follows:
* gaming - within the meaning of section 6
* betting - within the meaning of section 9 and
* participating in a lottery within the meaning of section 14 and subject to section 15 .
Gaming session
A gaming session is the playing of any of the applicable activities, for example bingo or casino games, and commences when a player starts playing a game for real money. A gaming session ends when a player exits a game.
High frequency lottery
A lottery in which any draw takes place less than one hour after a draw in a previous lottery promoted on behalf of the same non-commercial society or local authority or as part of the same multiple lottery scheme.
Instant lottery
A lottery in which every draw takes place either before, or at the point of, purchase of tickets by participants in the lottery.
Lottery ticket
As described by section 253 of the Act and a reference in this document to a lottery ticket includes:
* a lottery ticket which is sent by post following entry by means of remote communication
* a message sent or displayed to a person electronically in a manner which enables him to retain the message electronically or print it.
Mapping
The process of selecting an outcome using the result from a Random Number Generator (RNG). For example, the result from a RNG is mapped to a reel strip symbol.
Peer-to-peer gambling
A type of gambling where customers gamble against each other rather than against the house. For example, equal chance gaming such as poker or peer-to-peer betting through betting exchanges.
Play-for-free
Also known as play-for-fun. Demonstration version of a real money game where the customer is not staking or winning any money or money’s worth.
Progressive or progressive jackpot
An incremental prize that increases as a result of contributions from the monies staked within a game from pre-set base value.
Random Number Generator (RNG)
Refers to any item of hardware or software which is used to generate random numbers with the intended property of statistical randomness.
Restricted display device
A device such as a mobile phone which has limited space on which to display information, when used to access gambling facilities that the operator intends a customer to use by means of such a device.
We expect that a player using a restricted display device would still have the ability to use all required responsible gambling tools, such as financial limits or self-exclusion. We would not consider it acceptable to require a player to login via, for example, the desktop website version of the gambling facilities in order to access responsible gambling tools. Such an approach would create unreasonable barriers and may deter or prevent mobile users from utilising the available tools.
Scaling
Scaling is the process used to convert the output from a RNG into the format required to produce a result for a particular gambling product. To illustrate, an RNG may produce a result of between one and 100,000 but these possible outcomes need to be scaled to the potential game outcomes of, for example, between 1 – 52 to correspond to a standard pack of cards.
Seeding
Refers to the process used to determine the initial state of the RNG.
Slots
Casino games of a reel-based type (includes games that have non-traditional reels).
Subscription lottery
A series of lotteries (other than instant lotteries) promoted on behalf of the same non-commercial society or local authority in respect of which participants pay for participation in one or more future lotteries by regular subscription over a fixed or indefinite period.
Telephone gambling
Gambling which takes place via a telephone, without the use of visual displays, by interaction with a customer service agent or an automated system, such as intelligent voice recognition systems or touch tone.
Third party software
Refers to software that is separately available from the core software product and is designed to add optional features. It includes additional software, supplied, or used, by the gambling operator, or player, which was not part of the basic package.
Virtual
As described by section 353(3) of the Act. Virtual event and virtual game are to be construed accordingly.
3 - Remote gambling and software technical standards
Applies to:
All gambling – except subscription lotteries.
RTS aim 1
To provide customers with easily accessible information about their current balances and facilities that enable them to review previous gambling and account transactions.
RTS requirement 1A
Where customers hold a credit or debit balance, the pages or screens used for gambling and to move money into and out of accounts must display the customer’s current account balance, in the currency of their account for example dollars, euros or pounds sterling, whenever that customer is logged in. Where it is not practical to display current balance from gambling screens then easily accessible links to this information must be provided.
RTS implementation guidance 1A
* Gambling pages and screens include virtual game pages, sports betting coupons, poker and other virtual gaming ‘tables’.
* For telephone betting this information is to be delivered at the customer’s request by the customer service agent or automated response system.
RTS requirement 1B
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 ability to request this information should be made clear to customers and be provided as soon as is practicable.
The gambling and account history should include:
* credit and debit information such as deposits, withdrawals, movement of funds between products, payments off credit accounts, entry fee deductions, and bonus information, as appropriate
* bets placed, the results of bets, winnings paid
* for gaming (including bingo) full or summarised gaming information should be available, for example, £10 taken into game, £100 turned over, £3 taken away from game. Where detailed historic game information may not necessarily be directly available to customers, as a minimum, customers must have easy access to details of the last game played and summarised information for previous activities
* where customers are able to move funds between gambling products, account information and statements should clearly display movement of funds into and out of products
* an option for customers to use their own defined time period or to select from a range of time periods. A summary total for the period selected should be displayed (at least on the first screen or page if the transactions span multiple screens).
For telephone betting and restricted display devices, where customers demonstrate that they also have access to websites – by registering online or using other online products – it is acceptable to provide access to statements via these websites, otherwise customers should be sent a regular copy of their statement via email, fax or post unless they elect not to receive this information. Customers should be sent a statement on request, even if they have opted out of receiving regular statements.
RTS requirement 1C
Customers must be able to access information about their net deposits.
RTS implementation guidance 1C
Net deposits are defined as the running total of all deposits minus the sum of all withdrawals for the lifetime of the account. This should be displayed at an account level so the figure represents the net position of all payment methods. Where full account lifetime history is not possible then, as a minimum, the net deposits should be displayed from 1 April 2018, or the account opening date if after 1 April 2018. Information which explains the net deposit figure, including the timeframe it covers, should be provided.
RTS 2 – Displaying transactions
Applies to:
In respect of requirements 2A to 2D - All gambling.
In respect of requirements 2E - Casino (excluding peer-to-peer poker).
RTS aim 2
To enable the customer to understand the value and content of their transactions.
RTS requirement 2A
The remote gambling system must make available clear information about the amount of money being gambled by the customer, including any conversions from one form of currency to another, or from currency to credits, chips or other tokens etc, at the point of conversion.
RTS implementation guidance 2A
* The financial commitment for each gamble should be displayed somewhere on the screen either in the currency of the customer’s account or in the currency of the product. The use of credits, chips or other tokens with no face value should only be used when the corresponding currency amount is clearly visible, or where the customer is not staking additional money such as a poker tournament.
* Any conversion from one currency to another should be clearly presented to the customer and any conversion rules are also to be presented. Where currency is converted into tokens, chips or credits, etc, the conversion should be clearly displayed.
* Information about the value of the gamble should be displayed including, as appropriate:
* unit stake and total stake, whether currency, credit, tokens, chips, or any other form of payment
* entry fees, for example, payment for entry to poker tournaments
* the price of lottery tickets and the number of draws entered.
* For telephone gambling, this information is to be delivered by the customer service agent or automated response system.
* For subscription lotteries, sending a confirmation by email or post and/or displaying the stake and the number of draws entered when the customer subscribes is sufficient.
RTS requirement 2B
The gambling system must display sufficient relevant information about the customer’s gamble so that the content of the gamble is clear. This information must be made available before the customer commits to the gamble including, for example, in the artwork and textual information displayed during gaming, or on an electronic equivalent of a betting slip or lottery ticket.
RTS implementation guidance 2B
* The following items provide guidelines about the type of information that may be relevant:
* selections – the items the customer has chosen to gamble on
* the bet type
* the accepted odds, for example current odds, starting price, first show, etc
* the odds format that will take precedence in settling bets must be set out in the rules.
* These items, where relevant, are also required on applications designed for use on restricted display devices.
* For telephone gambling the content of the customer’s bet should be read back to them before the bet is confirmed.
* Where the customer is able to choose, through the use of a third party user-interface, to override the display of this information, this must not be the default option. That is, the customer must make an active choice not to have the information available or to install a user-interface that does not contain the information. The remote gambling system should continue to make available or send the information to the customer; it should not assume that the information is not required.
* For subscription lotteries, sending a confirmation by email or post and/or displaying the first draw and the number of draws for which the customer will be entered is sufficient.
RTS requirement 2C
The gambling system must enable customers to choose whether to accept price fluctuations (in either direction) that occur after their bet is requested.
RTS implementation guidance 2C
* Players should be presented with options to control whether a price change should be accepted or not.
* These options must be presented on a per bet basis, except in circumstances where a customer has requested a default account setting to disable price change alerts prior to bet acceptance. Where the functionality is offered at an account level the default option should not be set to accept all fluctuations. Where a customer chooses not to accept price changes automatically any bet where the price changes must be reoffered before it is accepted.
* Information sufficient to explain the options to the customers should be provided.
* An optimum solution would enable consumers to choose to automatically accept price movements within a particular margin range. Account level options offered to consumer could include accepting all bets with higher price, accepting all bets with shorter price or accepting all bets regardless of price movements.
* This requirement does not intend to capture currency fluctuations.
RTS requirement 2D
Customers who choose to use third party user interfaces must be informed that applications may not display full information about their gambles.
RTS implementation guidance 2D
Information should be included in terms and conditions, rules or other general information about the gambling product that is made available to and/or sent out to customers.
RTS requirement 2E
All gaming sessions must clearly display a customer’s net position, in the currency of their account or product (for example, pounds sterling, dollar, Euro) since the session started.
RTS Implementation guidance 2E
Net position is defined as the total of all winnings minus the sum of all losses since the start of the session.
RTS 3 – Rules, game descriptions and the likelihood of winning
Applies to:
Gaming (including bingo), lotteries and betting on virtual events
RTS aim 3
To enable customers to make informed decisions about whether to gamble based on their chances of winning, the way the game, lottery or event works, the prizes or payouts on offer and the current state of multi-state games or events.
RTS requirement 3A
An explanation of the applicable rules must be easily available to the customer before they commit to gamble. The content including artwork and text must be accurate, and sufficient to explain all of the applicable rules and how to participate. All reasonable steps must be taken to ensure that the content is understandable.
RTS implementation guidance 3A
* Explanatory content includes information in artwork and text displayed within the virtual event, in ‘help’ or ‘how to play’ pages, or other supporting material.
* Links to the information should be prominently placed, for example on home pages for gaming sections, game selection pages or menus, or within individual games, so that customers can easily locate them.
* As a minimum, restricted display devices should provide explanatory content via a menu item or other link.
* The following items provide guidelines on the type of explanatory content that may be relevant and should be considered for inclusion:
* the name of the game, lottery or virtual event
* the applicable rules, including clear descriptions of what constitutes a winning outcome
* restrictions on play or betting, such as any play duration limits, maximum wins, etc
* the number of decks or frequency of shuffles in virtual card games
* whether there are contributions to jackpots (progressives) and the way in which the jackpot operates, for example, whether the jackpot is won by achieving a particular outcome
* instructions on how to interact with the game
* rules pertaining to metamorphosis of games, for example, the number and type of tokens that need to be collected in order to qualify for a feature or bonus round and the rules and behaviour of the bonus round
* the rules for entering a single lottery draw or a series of lottery draws and the frequency of the draws.
RTS requirement 3B
Where relevant, as the game or event progresses, information that may reasonably be expected to enable the customer to understand the current state must be displayed.
RTS implementation guidance 3B
The following items provide guidelines on the type of information that may be relevant.
* Where a game builds up a collection of tokens (symbols etc), the current number collected.
* An indication of which rules are currently relevant, such as displaying ‘bonus round’ or other feature labels.
* This requirement does not apply to lotteries.
RTS requirement 3C
For each virtual event, game (including bingo), or lottery, information that may reasonably be expected to enable the customer to make an informed decision about his or her chances of winning must be easily available before the customer commits to gamble. Information must include:
* a description of the way the game works and the way in which winners are determined and prizes allocated
* house edge (or margin)
* the return to player (RTP) percentage or
* the probability (likelihood) of winning events occurring.
RTS implementation guidance 3C
* The following items provide further guidance on acceptable types of information about the likelihood of winning:
* for types of peer-to-peer games where the likelihood of winning may depend on skill and/or the actions of other participants, a description of the way the game works and how winners are determined will be sufficient
* for bingo, and some types of lottery or other games where it is not possible to determine the likelihood of winning because it depends on the eventual number of participants, a description of the way in which prizes are allocated will be sufficient
* the average theoretical return to player percentage. Where an event (other than peer- to-peer) involves an element of skill, return to player percentage should be calculated using either the auto-play strategy or a standard/published strategy
* the house edge, margin or over-round, for example for a virtual race
* the probability of each winning event occurring, or such information as may reasonably be expected to allow the customer to calculate the probability that the event will occur. The nature of some games may mean that the game itself provides sufficient information, for example, the likelihood of rolling a six on a six-sided die would not require further explanation.
* The odds displayed in virtual event betting should reflect the probability of each event occurring as closely as possible.
* Information may be included in artwork and text displayed within the virtual game or event, in ‘help’ or ‘how to play’ pages, or other supporting material.
* Information should be easily accessible, for example by placing links on home pages for gaming or virtual event sections, game selection pages or menus, or within individual games.
RTS requirement 3D
For each virtual event, game (including bingo), or lottery, content describing the potential prizes and payouts or the means by which these are calculated or determined must be easily available before the customer commits to gamble.
RTS implementation guidance 3D
* Information should be made available about the amounts that customers may potentially win, for example in the form of pay-tables, or by showing the odds paid for particular outcomes.
* For peer-to-peer games where the prize is determined based on the actions of the participants, a description of the way the game works and the rake or commission taken will be sufficient.
* For lotteries and other types of events where the potential amount or prize paid out may not be known before the customer commits to gamble, describing the way in which the prize amount is determined will be sufficient.
* Information may be included in artwork and text displayed within the virtual event, in ‘help’ or ‘how to play’ pages, or other supporting material.
* Information should be easily accessible, for example by placing links on home pages for gaming sections, game selection pages or menus, or within individual games.
* Displays of jackpot amounts that change over time (progressives) should be updated as frequently as practicable, particularly after the amount has been reset following a win.
RTS 4 – Time-critical events
Applies to:
Gaming (including bingo), lotteries and betting on virtual events
RTS aim 4
To reduce the risk that customers are unfairly disadvantaged by technical factors that may affect speed of response, and to ensure customers are made aware of the risk.
RTS requirement 4A
Where speed of interaction has a significant effect on the customer’s chance of winning, operators must assess the level of risk and demonstrate to the Commission that they are taking reasonable steps to reduce the risk to customers.
RTS implementation guidance 4A
Examples of possible approaches include:
* estimating the degree of network latency (delay) a customer is experiencing and displaying regularly updated information to the customer about any disadvantage that they may be operating under (for example high, medium, low)
* applying a handicapping system based on estimated performance and/or system latency
* treating winning responses that arrive within a period of time as simultaneous and implementing a policy on how simultaneous wins are to be dealt with.
RTS requirement 4B
For time-critical events, the customer should be informed that they might be at a disadvantage because of technical issues such as slower network speeds, or slower end user device performance.
RTS implementation guidance 4B
* Information should be included in game descriptions, rules, ‘help’ or ‘how to play’ pages.
RTS 5 – Result determination
Applies to:
All gambling
RTS aim 5
To ensure that the gambling system implements the operator’s rules, game rules and betting rules as they are described to the customer.
RTS requirement 5A
All reasonable steps should be taken to ensure that gambles are accepted, processed and settled in accordance with the operators’ published terms and rules, and the rules of the specific game, event, or bet.
Where unexpected system flaws, faults, or errors that affect the customer occur, steps are to be taken as soon as practicable to remedy the problem and ensure that the customer is treated fairly according to the circumstances.
RTS implementation guidance 5A
* Under normal operation, in the absence of technical faults, the system should act in accordance with the rules.
* Reasonable steps include testing of systems and new products against the published rules and monitoring the ongoing performance of those products in the live environment. Refer to our testing strategy for more detailed requirements in this area.
* Customers should be notified when errors that affect them, for example, incorrectly settled bets, have occurred as soon as practicable after the event occurs. Steps should be taken to rectify the error, for example, by manually adjusting the customer’s account.
RTS 6 – Result determination for play-for-free games
Applies to:
Gaming (including bingo), lotteries and betting on virtual events.
RTS aim 6
To minimise the risk that customers are misled about the likelihood of winning due to the behaviour of play-for-free games.
RTS requirement 6A
Play-for-free games must implement the same game rules as the corresponding play-for-money games offered on the same facilities (that is, the same website). Operators must take all reasonable steps to ensure that play-for-free games accurately represent the likelihood of winning and prize distribution in the play-for-money game. For the purpose of this requirement playing a game includes participating in a lottery and/or betting on a virtual event.
RTS implementation guidance 6A
* The play-for-free game should use the same RNG as the corresponding play-for-money games, another RNG that fulfils the requirements set out in RTS requirement 7A, or a publicly available RNG, (such as those available as standard within operating systems) that may reasonably be expected to produce no systematic bias.
* Where 6A is not reasonably possible, it should be demonstrated that the method of producing outcomes does not introduce a systematic bias, for example:
* if tables of random numbers are used, they should be sufficiently long to support a large number of games without repeating
* the method should represent game probabilities accurately, that is it should not produce a higher than expected proportion of winning outcomes.
* The prize distribution should accurately represent the play-for-money game. For example, where play-for-free games use virtual cash, the virtual cash payouts should be the same as the corresponding play-for-money game, and where tokens are used, the allocation of tokens as prizes should be proportionate to the stakes and prizes in the play-for-money game.
* Where videos are used to advertise a game’s features it should be made clear to consumers where footage has been edited or sped-up for promotional purposes. Similarly, where a non-consumer (for example supplier’s) website is demonstrating a game with higher than normal returns (that is, on a website that is different to the real money gambling facility websites) it should be made clear that it is a demonstration game specifically designed to demonstrate the bonus features.
RTS 7 – Generation of random outcomes
Applies to:
Gaming (including bingo), lotteries, and betting on virtual events
RTS aim 7
To ensure that games and other virtual events operate fairly.
RTS requirement 7A
Random number generation and game results must be ‘acceptably random’. Acceptably random here means that it is possible to demonstrate to a high degree of confidence that the output of the RNG, game, lottery and virtual event outcomes are random through, for example, statistical analysis using generally accepted tests and methods of analysis. Adaptive behaviour (that is, a compensated game) is not permitted.
Where lotteries use the outcome of other events external to the lottery, to determine the result of the lottery the outcome must be unpredictable and externally verifiable.
RTS implementation guidance 7A
* RNGs should be capable of demonstrating the following qualities:
* the output from the RNG is uniformly distributed over the entire output range and game, lottery, or virtual event outcomes are distributed in accordance with the expected or theoretical probabilities
* the output of the RNG, game, lottery, and virtual event outcomes should be unpredictable, for example, for a software RNG it should be computationally infeasible to predict what the next number will be without complete knowledge of the algorithm and seed value
* random number generation does not reproduce the same output stream (cycle), and that two instances of a RNG do not produce the same stream as each other (synchronise)
* any forms of seeding and re-seeding used do not introduce predictability
* any scaling applied to the output of the random number generator maintains the qualities as detailed
* For lotteries using external events - where it is not practical to demonstrate 7A the events outcomes should be:
* unpredictable, that is, events should be selected only where they may reasonably be assumed to be random events
* unable to be influenced by the lottery operator (or external lottery manager)
* publicly available and externally verifiable, for example, events that are published in local or national press would be acceptable.
* For games or virtual events that use the laws of physics to generate the outcome of the game (mechanical RNGs), the mechanical RNG used should be capable of meeting the requirements in a. where applicable and in addition:
* the mechanical pieces should be constructed of materials to prevent decomposition of any component over time (for example, a ball shall not disintegrate)
* the properties of physical items used to choose the selection should not be altered
* players should not have the ability to interact with, come into physical contact with, or manipulate the mechanics of the game
* Restricting adaptive behaviour prohibits automatic or manual interventions that change the probabilities of game outcomes occurring during play. Restricting adaptive behaviour is not intended to prevent games from offering bonus or special features that implement a different set of rules, if they are based on the occurrence of random events.
RTS requirement 7B
As far as is reasonably possible, games and events must be implemented fairly and in accordance with the rules and prevailing payouts, where applicable, as they are described to the customer.
RTS implementation guidance 7B
* Games should implement the rules as described in the rules available to the customer before play commenced.
* The mapping of the random inputs to game outcomes should be in accordance with prevailing probabilities, pay tables, etc.
* When random numbers, scaled or otherwise, are received, for example, following a game requesting a sequence of random numbers, they are to be used in the order in which they are received and they may not be discarded due to adaptive behaviour.
* Numbers or sequences of numbers are not to be discarded, unless they fall outside the expected range of numbers required by the virtual event – such an occurrence should result in an error being logged and investigated.
RTS requirement 7C
Game designs or features that may reasonably be expected to mislead the customer about the likelihood of particular results occurring are not permitted, including substituting losing events with near-miss losing events and simulations of real devices that do not simulate the real probabilities of the device.
RTS implementation guidance 7C
* Where a virtual event simulates a physical device, the theoretical game probabilities should match the probabilities of the real device (for example, the probability of a coin landing heads must be 0.5 every time the coin is tossed).
* Where multiple physical devices are simulated the probabilities of each outcome should be independent of the other simulated devices.
* Games may not falsely display near-miss results, that is, the event may not substitute one losing outcome with a different losing outcome.
* Where the event requires a pre-determined layout (for example, hidden prizes on a map), the locations of the winning spots should not change during play, except as provided for in the rules of the game.
* Where games involve an element of skill, every outcome described in the virtual event rules or artwork should be possible, that is, the customer should have some chance of achieving an advertised outcome regardless of skill.
* Where a customer contributes to a jackpot pool, that customer should be eligible to win the jackpot whilst they are playing that game, in accordance with the game and jackpot rules.
RTS requirement 7D
The rules, payouts and outcome probabilities of a virtual event or game may not be changed while it is available for gambling, except as provided for in the rules of the game, lottery or virtual event. Such changes must be brought to customer’s attention.
RTS implementation guidance 7D
* Changes to game or event rules, paytables or other parameters that change the way in which a game, lottery, or event works, the winnings paid, or likelihood of winning (except as described in 7Dc), should be conducted with the game or event taken offline or suspended.
* Altered games, lotteries, and events should display a notice that informs customers that the game or event has been changed, for example, ‘rules changed’, ’new odds’, or 'different payouts’. The notice should be displayed on game selection screens and on the events themselves if it is possible for the customer to go straight to the event without using a selection screen.
* This requirement is not intended to prevent games and virtual events where specified changes occur legitimately, in accordance with the game or event rules, for example:
* virtual events, such as virtual racing products where the odds differ from event to event depending on the virtual runners
* virtual games, such as bingo where the odds of winning are dependent on the number of entrants
* games with progressive jackpots, where the amount that can be won changes over time
* games with bonus rounds where different rules apply, so long as these rounds are properly described to the customer
* unspecified changes to rules, paytables or other parameters that change the way in which a game, lottery or event works are not permitted, for example, rules that state ‘game rules may be changed at any time’ would not be acceptable.
RTS requirement 7E
Except in the case of subscription lotteries, the system clearly and accurately display the result of the game or event and the customer’s gamble. The result must be displayed for a length of time that may reasonably be expected to be sufficient for the customer to understand the result of the game or event in the context of their gamble.
RTS implementation guidance 7E
The game artwork and text should be sufficient to provide the customer with all of the information required to determine whether they have lost or won, and the value of any winnings.
RTS 8 – Auto-play functionality
Applies to:
Gaming (including bingo).
RTS aim 8A
To make clear that auto-play cannot be offered for online gaming.
RTS requirement 8A
The gambling system must require a customer to commit to each game cycle individually.
RTS guidance 8A
This requirement does not prohibit offering functionality to automatically post blinds in peer-to-peer poker.
RTS 9 – Progressive jackpot systems
Applies to:
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 (for example, 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 10 – Interrupted gambling
Applies to:
Peer-to-peer betting and gaming (including bingo)
RTS aim 10
To ensure that customers are treated fairly in the event of interrupted play or betting and that they are aware of how they will be treated if interruptions occur.
RTS requirement 10A
Operators must take all reasonable steps to ensure that their policies for instigating or dealing with service interruptions are fair and do not systematically disadvantage customers.
RTS implementation guidance 10A
* For gaming the following policies should be applied:
* where an interruption occurs after the operator receives notification of the customer’s gamble and where the customer can have no further influence on the outcome of the event or gamble the results of the gamble should stand
* where an interruption to a single-participant single stage event occurs before an outcome has been generated the customer should have any deducted stake returned to their balance
* for stateful games (games where there are multiple stages or decision points), all reasonable steps should be taken to restore the game to its last known state to enable the customer to complete the game
* games with multiple participants (equal chance or otherwise) should be dealt with fairly on a case-by-case basis
* progressive jackpot values should be restored to their pre-failure state.
* For peer-to-peer betting the following policies should be applied:
* where a service interruption is caused by failures in the gambling system, operators should suspend betting on all betting markets that have been affected by a significant event before service is restored
* other failures should be dealt with fairly on a case-by-case basis.
RTS requirement 10B
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), the capability to suspend betting markets, and taking all reasonable steps to retain sufficient information to be able to restore events to their pre-failure state.
RTS implementation guidance 10B
* For gaming the system should:
* be capable of voiding gambles and restoring the amount gambled to the customer automatically, or in conjunction with manual operational controls; and
* implement all reasonable measures to maintain sufficient information to be capable of automatically restoring an event to its pre-failure state so that it may be completed by the customer. The following information should be restored, as appropriate:
* the state of a deck of cards, and any hands that have been dealt
* number of tokens collected
* any other predetermined information, such as maps or prize layouts
* the value of any progressive jackpots
* the state of any gambles, for example, who has staked what on what outcome
* bets placed or offered.
* For peer-to-peer betting, it should be possible to suspend betting markets manually or automatically.
RTS requirement 10C
Operators must make available information about their policies regarding service interruptions in various different circumstances.
RTS implementation guidance 10C
Operators should make information available to customers about how they will be treated in various common scenarios. However, this does not mean that operators have to detail all possible scenarios or responses to service interruptions.
RTS 11 – Limiting collusion and cheating
Applies to:
Peer-to-peer gaming
RTS aim 11
To reduce the risk that cheating or collusion by players unfairly disadvantages another player and to inform customers about the risks posed.
RTS requirement 11A
Measures intended to deter, prevent, and detect collusion and cheating must be implemented. Gambling systems must retain a record of relevant activities to facilitate investigation and be capable of suspending or disabling player accounts or player sessions. Operators must monitor the effectiveness of their policies and procedures.
RTS implementation guidance 11A
* Relevant activities to be recorded will vary by game but may include:
* which players played at which tables
* the amounts won from and lost to accounts
* game activities to an individual bet/action level.
* Where appropriate, prevention measures may include:
* taking steps to prevent a player from occupying more than one seat at any individual table.
* Detection measures may include, detecting and investigating the following, where appropriate:
* players who frequently share the same tables
* players from same address who share the same table
* suspicious patterns of play (such as chip dumping)
* unusual gameplay statistics.
* Customer complaints about cheating should be investigated.
* Records should be kept of investigations which result in an account being closed including:
* player details (name, location, which licence the activity was in reliance on), scale of the offences (financial and number of players), time and date etc
* the reason for investigation (including whether it was initiated by customer contact) and the outcome
* any relevant evidence such as reports, screenshots, chat history etc. This information should be considered when updating the risks identified in relevant policies and procedures.
RTS requirement 11B
Information must be made available about the operator’s policies and procedures with regard to cheating, recovered player funds and about how to complain if a customer suspects other participants are cheating.
RTS implementation guidance 11B
* As a minimum deterrent, customers should be informed that accounts will be closed if the customer is found to have cheated.
* Information regarding funds that are recovered from accounts during integrity investigations is not expected to cover every scenario but should highlight the main aims of the policy.
* Relevant information should be included in terms and conditions or rules.
RTS 12 – Financial limits
Applies to:
All gambling - except subscription lotteries
RTS 12 aim
To provide all customers with facilities to apply financial limits to their accounts to enable them to set and maintain a gambling budget that is suitable for their personal circumstances.
RTS requirement 12A
The gambling system must provide easily accessible facilities for customers to set their own financial limits at any time from the point of registration.
Customers must be prompted to set a limit as part of the registration process or at the point at which the customer makes the first deposit or payment. The limit must be implemented as soon as practicable after the customer’s request. The customer must be informed when the limit will come into force.
RTS implementation guidance 12A
* Limits could be in the form of:
* deposit limits: where the amount a customer deposits into their account is limited over a particular duration
* spend limits: where the amount a customer spends on gambling (or specific gambling products) is restricted for a given period – this type of limit may be appropriate where the customer does not hold a deposit account with the operator
* loss limits: where the amount lost (that is, winnings subtracted from the amount spent) is restricted (for instance when a customer makes a £10 bet and wins £8, the loss is £2).
* The period/duration of the limits on offer should include:
* 24 hours and
* 7 days and
* one month
* where a customer sets simultaneous time frames, for example a daily deposit limit and a weekly limit, the lowest limit should always apply. Therefore if a daily deposit limit of £10 and a weekly limit of £100 are both set then the maximum the system should allow to be deposited is £10 per day and £70 per week.
RTS requirement 12B
Customers must be presented with a ‘free text’ box to set a limit, or the equivalent in the case of telephone gambling.
As a minimum, limits must be applied at the account level.
RTS implementation guidance 12B
* In addition to account-level limits, limits could be implemented across individual products or channels. Where gambling licensees offer the facility to set limits for individual products or channels it should be made clear to customers using the facility whether those limits apply at the account or product/channel level. For example, where a limit has been set for a specific game, a customer should not be misled into assuming that the limit automatically applies to other products.
* Where a customer sets simultaneous time frames, gambling licensees should provide clear information on how the interaction between those limits works.
* Operators could provide links to tools or resources to inform budgeting and aid customers in determining appropriate limits for their personal circumstances.
* In order to mitigate against user error, the gambling system could permit specific monetary increments for limits, such as whole pounds.
RTS requirement 12C
Financial limit facilities must be provided via a direct link on the homepage and be clearly visible and accessible.
Financial limit facilities must be clearly visible and accessible on deposit pages/screens or via a direct link on these pages or screens.
The gambling system must minimise the number of clicks or pages customers make in order to access financial limit facilities.
RTS implementation guidance 12C
* Links to limit-setting facilities from communications such as emails or notifications should link directly to the facilities and not via a home page or other intermediate page(s), unless required by account log in security settings.
RTS requirement 12D
Customer-led limits must only be increased at the customer’s request, only after a cooling-off period of at least 24 hours has elapsed and only once the customer has taken positive action at the end of the cooling off period to confirm their request.
Unless systems/technical failures prevent it, customer-led reductions to limits must be implemented immediately.
The gambling system must provide a prompt to customers to review their own account and transaction information, as is currently made available under RTS 1 – Customer account information. This must be provided at a minimum of six-month intervals for accounts with activity within a rolling 12-month period. Customers must be provided with facilities to set more frequent reminders to receive this statement and review their limits.
RTS implementation guidance 12D
* In the event of systems or technical failure not facilitating an automated and/or immediate reduction in limits, the customer should be informed when the limit reduction will take effect.
* Operators should monitor engagement with and responses to alerts, in order to inform good design and best practice.
RTS requirement 12E
Financial limit-setting facilities must present setting a limit as the default choice. The gambling system must require an action by the customer in order to decline setting a limit.
The gambling system must receive confirmation that the customer does not wish to set a limit before moving on to deposit/gamble.
The gambling system must prompt existing customers without limits set to review this position as a minimum on an annual basis.
RTS implementation guidance 12E
* Presentation of financial limits as the default option could take the form of pre-selected fields such as tick boxes, or through visual distinction.
* Action to decline setting a limit and receiving confirmation could take the form of a tick box, dismissing a message or other action by the customer.
* Customers who choose to opt out of setting a limit could be provided with information or links to tools and resources such as budgeting tools and information about safer gambling.
RTS 13 – Time requirements and reality checks
Applies to:
In respect of requirement RTS 13A – All remote gambling except telephone gambling.
In respect of RTS 13B – Remote gaming (including bingo but excluding peer to peer gaming), remote instant win lotteries and high frequency lotteries.
In respect of RTS 13C – Casino (excluding peer to peer poker).
RTS aim 13
To provide customers with facilities to assist them to keep track of the time they spend gambling.
RTS requirement 13A
Where the gambling system uses full screen client applications that obscure the clock on the customer’s device the client application itself must display the time of day or the elapsed time since the application was started, wherever practicable.
RTS implementation guidance 13A
* Time of day should either be taken from the customer’s own device or ‘server time’ and should be displayed in hours and minutes.
* Operators will not be expected to detect whether or not customers have hidden their clocks.
* Elapsed time should be displayed in minutes and hours.
* For restricted display devices, time of day or elapsed time should be displayed where the device supports it.
* In addition, customers may be offered the ability to set a session or game-play duration reminder.
RTS requirement 13B
The gambling system must provide easily accessible facilities that make it possible for customers to set a frequency at which they will receive and see on the screen a reality check within a gaming session. A ‘reality check’ means a display of the time elapsed since the session began. The customer must acknowledge the reality check for it to be removed from the screen.
RTS implementation guidance 13B
* The customer should be offered the opportunity to set or amend a reality check via easily accessible means at all times. Customers should be able to select a frequency at which the reality check will appear on the screen. Customers can be presented with a pre-set list time periods but these must have a reasonable and appropriate range from which to select and where a default time period is offered it must be set at the minimum
* The reality check should continue to appear at the selected time intervals until the customer’s gaming session ends (see definition of terms) or the customer exits their account (this will depend on solutions i ii iii below). If a customer is participating in multiple gaming sessions at once (for example, playing bingo as well as participating in slots games in between draws) the gaming session began when the player commenced with the first product. The reality check facility could be implemented via one of the following ways:
* Player account level implementation - there are two potential solutions for account level implementation. The optimum approach would enable customers to set a reality check reminder for their account, which would commence at the start of the first gaming session and roll over to subsequent sessions. An alternative solution would be for the reality check to commence before a customer accesses a gaming session (for example, at account login stage). The second solution would meet the requirement although it would not take into account natural breaks in play, such as when customers are in the casino lobby.
* Product level implementation - this approach will enable a customer to set a reality check for each individual gaming session, for example the player commences playing roulette and then later starts playing blackjack and has two reality checks running concurrently but covering different time periods.
* Hybrid solution - some games are subject one reality check and others are subject to another for example all slot games are subject to a single reality check and live dealer products are subject to a separate reality check.
* A clear explanation of how the reality check is implemented must be provided to players so they are aware of how they can use it to assist them in managing their gambling. Where possible a player’s preferences should be applied to all future account logins or gaming sessions (where applicable). If this is not possible players must be provided with clear information that explains that they will have to set a reality check for each account login or gaming session.
* The reality check should offer the customer the facility to exit the gaming session or log out of their account (depending on which of the above solutions is adopted).
* The reality check should provide a link to the customer’s account history.
* The reality check can be presented at the end of a game but a player cannot be permitted to commit further funds to a new game until they have acknowledged the reality check, unless it occurs mid-way through a multi-state game such as blackjack where a player would need to commit additional funds if they wanted to split or double down.
* The reality check must prevent a new game within an auto-play sequence from commencing until the player has acknowledged the reality check.
RTS requirement 13C
The elapsed time should be displayed for the duration of the gaming session.
RTS implementation guidance 13C
* Time displayed should begin either when the game is opened or once play commences.
* Elapsed time should be displayed in seconds, minutes and hours.
RTS 14 – Responsible product design
Applies to:
In respect of requirements RTS 14A and 14B – All gambling.
In respect of requirement RTS 14C – Casino (excluding peer-to-peer poker).
In respect of requirement RTS 14D – Slots.
In respect of requirement RTS 14E and 14F – Casino.
In respect of requirement RTS 14G – Casino (excluding slots and peer-to-peer poker).
RTS aim 14
To ensure that products are designed responsibly and to minimise the likelihood that they exploit or encourage problem gambling behaviour.
RTS requirement 14A
Gambling products must not actively encourage customers to chase their losses, increase their stake or increase the amount they have decided to gamble, or continue to gamble after they have indicated that they wish to stop.
RTS implementation guidance 14A
* By actively encourage, we mean the inclusion of specific features, functions or information that could reasonably be expected to encourage a greater likelihood of the behaviours described occurring. For example:
* the amount of funds taken into a product should not be topped up without the customer choosing to do so on each occasion, for example, when a customer buys-in at a poker table they should have to choose to purchase more chips to play at the table, automatic re-buys should not be provided
* written or graphical information should not encourage customers to try to win back their losses
* customers who have chosen to exit a game should not be encouraged to continue playing by, for example, being offered a free game.
* This requirement is not intended to prevent operators from offering special features or well-known games such as blackjack that allow customers to increase their stake on the occurrence of specific events (for example, split).
RTS requirement 14B
Consumers must not be given the option to cancel their withdrawal request.
RTS implementation guidance 14B
Once a customer has made a request to withdraw funds, they should not be given the option to deposit using these funds. Operators should make the process to withdraw funds as frictionless as possible.
RTS requirement 14C
The gambling system must not offer functionality which facilitates playing multiple games at the same time.
RTS implementation guidance 14C
* Operators are not permitted to offer functionality designed to allow players to play multiple games at the same time. This includes, but is not limited to, split screen or multi-screen functionality.
* Combining multiple games in a way which facilitates simultaneous play is not permitted.
RTS requirement 14D
It must be a minimum of 2.5 seconds from the time a game is started until the next game cycle can be commenced. It must always be necessary to release and then depress the 'start button’ or take equivalent action to commence a game cycle.
RTS implementation guidance 14D
A game cycle starts when a player depresses the ‘start button’ or takes equivalent action to initiate the game and ends when all money or money’s worth staked or won during the game has been either lost or delivered to, or made available for collection by the player and the start button or equivalent becomes available to initiate the next game.
A player should commit to each game cycle individually, continued contact with a button, key or screen should not initiate a new game cycle.
RTS requirement 14E
The gambling system must not permit a customer to reduce the time until the result is presented.
RTS implementation guidance 14E
* Features such as turbo, quick spin and slam stop are not permitted. This is not intended to be an exhaustive list but to illustrate the types of features the requirement is referring to.
* This applies to all remote games, regardless of game cycle speed.
* This requirement does not apply to bonus and/or feature games where an additional stake is not wagered.
* This requirement does not prohibit the ‘scratch-all’ and/or ’reveal-all’ feature.
* This requirement does not prohibit games where the customer will lose their stake unless they take action to end the game.
RTS requirement 14F
The gambling system must not celebrate a return which is less than or equal to the total stake gambled.
RTS implementation guidance 14F
* By ‘celebrate’ we mean the use of auditory or visual effects that are associated with a win are not permitted for returns which are less than or equal to last total amount staked.
* The following items provide guidelines for reasonable steps to inform the customer of the result of their game cycle:
* Display of total amount awarded.
* Winning lines displayed for a short period of time that will be considered sufficient to inform the customer of the result. This implementation should not override any of the display requirements (as set out in RTS 7E).
* Brief sound to indicate the result of the game and transfer to player balance.
RTS requirement 14G
It must be a minimum of 5 seconds from the time a game is started until the next game cycle can be commenced. It must always be necessary to release and then depress the 'start button’ or take equivalent action to commence a game cycle.
RTS implementation guidance 14G
A game cycle starts when a player depresses the ‘start button’ or takes equivalent action to initiate the game and ends when all money or money’s worth staked or won during the game has been either lost or delivered to, or made available for collection by the player and the start button or equivalent becomes available to initiate the next game.
A player should commit to each game cycle individually, continued contact with a button, key or screen should not initiate a new game cycle.
RTS 15 – In-play betting
Applies to:
Betting and peer-to-peer betting
RTS aim 15
To make the customer aware that they may not have the latest information available when betting on live events, and that they may be at a disadvantage to operators or other customers who have more up-to-date information.
RTS requirement 15A
Information must be made available that explains 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.
RTS implementation guidance 15A
* Brief information should be included on main in-play pages or screens, such as the in-play home page or screen. More detail should be provided in ‘help’ or ‘how to’ or other product pages or screens.
* For telephone betting the information should be included in the general betting or product information that is made available to and/or sent out to customers.
* Where a brief notice cannot be practicably included on the main pages or screens, the information should be provided on easily accessible ‘help’, ‘how to’ or other product pages or screens.
RTS 16 – Use of third party software
Applies to:
Peer-to-peer gambling
RTS aim 16
To make customers in peer-to-peer gambling aware that they may be gambling against a software program (designed to automatically participate in gambling within certain parameters, sometimes referred to as a bot), or a human aided by third party software.
RTS requirement 16A
Where peer-to-peer customers may be gambling against programs deployed by other customers to play on their behalf, or customers assisted by third party software, information should be made available that describes that this is possible, and if it is against the operator’s terms and conditions, how to report suspected use.
RTS implementation guidance 16A
* The warning and information about how to complain should be included in game descriptions, rules, terms and conditions, ‘help’, ‘how to play’ or other general product information pages.
* The warning should also inform customers that if they use a program to gamble on their behalf, other customers may be able to exploit it.
RTS requirement 16B
Operators must make it clear to players whether the use of third party software is permitted and if so which types. Operators that prohibit certain types of third party software must implement measures intended to deter, prevent, and detect their use.
RTS implementation guidance 16B
Clear, accessible information about the types of software that are permitted or prohibited should be included within terms and conditions and the players guide (LCCP Social responsibility code 4.2.3), as a minimum. This does not have to be an extensive list but could be a description of the key features of the software.
RTS requirement 16C
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.
RTS implementation guidance 16C
* Peer-to-peer gambling operators that use software to gamble on their behalf (for example, poker robots) should display a notice to customers on the home pages or screens and in the game description, ‘help’ or ‘how to play/bet’ pages or screens.
* As a minimum, restricted display devices should provide a link to further information on gambling pages/screens or in ‘help’, ‘about’ or ‘how to bet/play’ pages or screens.
RTS 17 – Live dealer studios
Applies to:
Gaming (including bingo)
RTS aim 17
To ensure that live dealer operations are fair.
RTS requirement 17A
Live dealer operations must be fair and independently auditable.
RTS implementation guidance 17A
* Equipment and consumables should be of commercial casino quality. Designated staff should be responsible for monitoring the integrity of all operational equipment.
* Croupiers need to undergo adequate training to provide the gambling in a fair way according to documented procedures and game rules. Evidence of training and refresher training should be maintained.
* Gambling provision should be supervised by staff responsible to oversee dealer activities and integrity. Video surveillance to record all dealer activity should be in place, enough to cover the predefined gaming areas with sufficient detail to confirm whether dealing procedures and game rules were followed.
* Secure areas, gambling equipment and consumables shall be protected by appropriate access controls to ensure that only authorised personnel are allowed access.
* Game logs should be maintained and game events collated into statistics which can be analysed for trends relating to game performance, staff and/or locations in the gaming area.
4 - Remote gambling and software technical standards (RTS) security requirements
Security requirements summary
4.1 This section sets out a summary of the RTS security requirements that licence holders must meet. The Commission has based the security requirements on the relevant sections of Annex A to the ISO/IEC 27001:2022 standard.
4.2 This 2022 standard replaces ISO/IEC 27001:2013.
4.3 The Commission’s aim in setting out the security standards is to ensure customers are not exposed to unnecessary security risks by choosing to participate in remote gambling. The Commission has highlighted those systems that are most critical to achieving the Commission’s aims and the security standards apply to these critical systems:
* electronic systems that record, store, process, share, transmit or retrieve sensitive customer information, for example, credit/debit card details, authentication information, customer account balances
* electronic systems that generate, transmit, or process random numbers used to determine the outcome of games or virtual events
* electronic systems that store results or the current state of a customer’s gamble
* points of entry to and exit from the above systems (other systems that are able to communicate directly with core critical systems)
* communication networks that transmit sensitive customer information.
Organisational controls
- 5.1 Policies for information security
- 5.10 Acceptable use of information and other associated assets
- 5.15 Access control
- 5.16 Identity management
- 5.17 Authentication information
- 5.18 Access rights
- 5.19 Information security in supplier relationships
- 5.20 Addressing information security within supplier agreements
- 5.21 Managing information security in the ICT supply chain
- 5.22 Monitoring, review and change management of supplier services
- 5.23 Information security for use of cloud services
- 5.24 Information security incident management planning and preparation
- 5.25 Assessment and decision on information security events
- 5.26 Response to information security incidents
- 5.28 Collection of evidence
- 5.35 Independent review of information security
People controls
- 6.3 Information security awareness, education and training
- 6.5 Responsibilities after termination or change of employment
- 6.7 Remote working
- 6.8 Information security event reporting
Physical controls
- 7.8 Equipment siting and protection
- 7.10 Storage media
- 7.14 Secure disposal or re-use of equipment
Technological controls
- 8.1 User endpoint devices
- 8.2 Privileged access rights
- 8.3 Information access restriction
- 8.5 Secure authentication
- 8.7 Protection against malware
- 8.13 Information backup
- 8.15 Logging
- 8.17 Clock synchronisation
- 8.18 Use of privileged utility programs
- 8.20 Networks security
- 8.21 Security of network services
- 8.22 Segregation of networks
- 8.24 Use of cryptography
- 8.25 Secure development life cycle
- 8.26 Application security requirements
- 8.27 Secure system architecture and engineering principles
- 8.29 Security testing in development and acceptance
- 8.30 Outsourced development
- 8.31 Separation of development, test and production environments
- 8.32 Change management
- 8.33 Test information
5 - Annex
| RTS numbers |
Bingo* |
Casino |
Betting (Virtual) |
Betting (Real event) |
Betting (Peer-to-peer) |
Subscription lotteries |
Instant Win/High frequency lotteries |
| RTS 1 – Customer account information |
X |
X |
X |
X |
X |
|
X |
| RTS 2 A-D – displaying transactions |
X |
X |
X |
X |
X |
X |
X |
| RTS 2E – displaying transactions |
|
X |
|
|
|
|
|
| RTS 3 – Rules, game descriptions and likelihood of winning |
X |
X |
X |
|
|
X |
X |
| RTS 4 – time critical events |
X |
X |
X |
|
|
|
|
| RTS 5 – result determination |
X |
X |
X |
X |
X |
X |
X |
| RTS 6 – Result determination for play for free games |
X |
X |
X |
|
|
X |
X |
| RTS 7 – Generation of random outcomes |
X |
X |
X |
|
|
X |
X |
| RTS 8 – Auto play functionality |
X |
X |
|
|
|
|
|
| RTS 9 – Progressive jackpots |
X |
X |
|
|
|
|
|
| RTS 10 – Interrupted gambling |
X |
X |
|
|
X |
|
|
| RTS 11 – Limiting collusion/cheating |
|
X** |
|
|
|
|
|
| RTS 12 – Financial Limits |
X |
X |
X |
X |
X |
|
X |
| RTS 13A – Time requirements |
X |
X |
X |
X |
X |
X |
X |
| RTS 13B – Reality checks |
X*** |
X*** |
|
|
|
|
X |
| RTS 13C – Time requirements |
|
X |
|
|
|
|
|
| RTS 14A&B – Responsible product design |
X |
X |
X |
X |
X |
X |
X |
| RTS 14C – Responsible product design (excluding peer-to-peer poker) |
|
X |
|
|
|
|
|
| RTS 14D – Responsible product design (slots) |
|
X |
|
|
|
|
|
| RTS 14E and 14F – Responsible product design |
|
X |
|
|
|
|
|
| RTS 14G – Responsible product design (excluding slots and peer-to-peer poker) |
|
X |
|
|
|
|
|
| RTS 15 – In play betting |
|
|
X |
X |
X |
|
|
| RTS 16 – Third party software |
|
X** |
|
|
X |
|
|
| RTS 17 – Live dealer studios |
If applicable |
If applicable |
|
|
|
|
|
| Security requirements**** |
X |
X |
X |
X |
X |
X |
X |
- The following standards apply to holders of remote bingo licences when making facilities available by means of remote communication in respect of games of bingo played on more than one set of premises: RTS 3, RTS 4, RTS 5, RTS 7, RTS 10 and RTS 14.
** Peer-to-peer gaming only
*** Excluding peer-to-peer gaming
**** The following categories of licences require the full security audit by an independent auditor: Remote betting – general (but not telephone only or trading rooms), remote betting (virtual events) pool and intermediary, remote casino, remote bingo, all host licences and remote lotteries (with entries greater than £250,000 per year).
NB: The table lists the main gambling variants as set out in the RTS. The standards that apply to a specific products will vary based on the underlying event. For example, the underlying event of pool betting will determine whether it is caught as betting (real event) or betting (virtual).
