Remote gambling and software technical standards (RTS)

1 - Introduction

1.1 This document sets out remote gambling and software technical standards issued by the Gambling Commission (the Commission) under section 89 and section 97 of the Gambling Act 2005 (opens in new tab) (the Act).

1.2 This document replaces the Remote gambling and software technical standards (RTS) published in June 2017.

1.3 The RTS is drafted in a format that sets out the key principles, without being overly prescriptive as to how these must be met. The general makeup and format of each requirement is structured as follows:

• the aim - describing what the Commission is seeking to achieve
• the requirement - which sets out specific requirements to meet the aim, and
• implementation guidance - providing guidance as to how the requirement should be complied with, without exhaustively describing all possible solutions. Licensees may adopt alternative approaches to those set out in the guidance provided they can meet the requirement in full and can demonstrate that an alternative approach is reasonable and similarly effective in the particular circumstances.

Changes to the standards

1.4 This updated RTS document includes changes to the following provisions that were consulted on as part of the Commission’s consultation: online slots game design and reverse withdrawals (opens in new tab) in July 2020.

Changes include:

• RTS 2 – Displaying transactions
• RTS 8 – Auto-play functionality
• RTS 13 – Time requirements and reality checks
• RTS 14 – Responsible product design.

Testing and audit requirements

1.5 The Commission’s Testing strategy for compliance with the remote gambling and software technical standards (PDF) (testing strategy) sets out the Commission’s current requirements for the timing and procedures for testing. Compliance with the RTS and testing strategy is a licence condition¹.

1.6 Importantly the testing strategy sets out the circumstances in which independent third party testing is required. The relevant standards are given in chapter 3 - Remote gambling and software technical standards and chapter 4 - security requirements.

1.7 The testing strategy and accompanying security audit advice (opens in new tab) also sets out the independent audit requirements that licence holders should fulfil. This is based on the relevant sections of ISO/IEC 27001: 2013, which are summarised in chapter 4 - security requirements.

1.8 Licensees that are responsible for procuring games testing will also need to submit a Games testing annual audit. Further details are provided in the testing strategy.

RTS summary table

1.9 For ease of reference, annex A lists all technical standards and their applicability to different gambling products. The summary should be treated as a high-level overview and be considered in conjunction with the relevant sections of the RTS.

Remote bingo and ancillary licences

1.10 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
• RTS 14.

1.11 Where bingo is offered across multiple premises the entity that holds the full remote operating licence will be responsible for ensuring compliance with the RTS. However, we would expect the ancillary licence holder (or individual premises) to have received sufficient assurance that the content offered via remote terminals is compliant with the relevant standards, as listed previously. Ancillary licence holders will still be required to comply with the bingo equipment specifications - Licence condition 2.3.2.

Remote lottery and ancillary licences

1.12 The Commission has adopted a risk based approach to lotteries – exempting from the technical standards lotteries offered under an ancillary remote licence² . Subscription lotteries, those products where customer spend is often controlled, are exempt from some aspects of the RTS (for example, RTS 12). The technical standards are primarily aimed at high frequency products offered under a full remote lottery licence, that enable consumers to participate in multiple draws in a relatively short space of time. These products present similar risks as instant lotteries (see definition of terms) and will need to adhere to the relevant technical standards.

Gambling software

1.13 In the case of gambling software, these technical standards only apply to manufacture, supply, installation or adaptation of software for use in connection with remote gambling which takes place in reliance on an operating licence issued by the Commission.

---

¹Licence condition 2.3.1 in Licence Conditions and Codes of Practice (LCCP).
² The ancillary remote licence is only suitable for holders of a non-remote society lottery operating licence who want to accept payment for participation in a lottery by remote means, up to a maximum of £250,000 in remote proceeds per annum. If you do not hold a non-remote society lottery operating licence and wish to take payments by remote means, you must hold a full remote licence. If you currently hold a non-remote and ancillary remote society lottery licence, but your remote proceeds are expected to exceed £250,000 per annum, a full remote society lottery operating licence will be required. Products offered under a non-remote society lottery operating licence and an ancillary remote licence must adhere to the relevant sections of the LCCP.

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

RTS 1 – Customer account information

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

1. Gambling pages and screens include virtual game pages, sports betting coupons, poker and other virtual gaming ‘tables’.
2. 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.

1. The gambling and account history should include:
   1. 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
   2. bets placed, the results of bets, winnings paid
   3. 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
   4. 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
   5. 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).
2. 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

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

1. 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.
2. 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.
3. Information about the value of the gamble should be displayed including, as appropriate:
   1. unit stake and total stake, whether currency, credit, tokens, chips, or any other form of payment
   2. entry fees, for example, payment for entry to poker tournaments
   3. the price of lottery tickets and the number of draws entered.
4. For telephone gambling, this information is to be delivered by the customer service agent or automated response system.
5. 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

1. The following items provide guidelines about the type of information that may be relevant:
   1. selections – the items the customer has chosen to gamble on
   2. the bet type
   3. the accepted odds, for example current odds, starting price, first show, etc
   4. 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.

2. For telephone gambling the content of the customer’s bet should be read back to them before the bet is confirmed.
3. 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.
4. 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

1. Players should be presented with options to control whether a price change should be accepted or not.
2. 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.
3. Information sufficient to explain the options to the customers should be provided.
4. 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.
5. 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

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

1. Explanatory content includes information in artwork and text displayed within the virtual event, in ‘help’ or ‘how to play’ pages, or other supporting material.
2. 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.
3. As a minimum, restricted display devices should provide explanatory content via a menu item or other link.
4. The following items provide guidelines on the type of explanatory content that may be relevant and should be considered for inclusion:
1. the name of the game, lottery or virtual event
2. the applicable rules, including clear descriptions of what constitutes a winning outcome
3. restrictions on play or betting, such as any play duration limits, maximum wins, etc
4. the number of decks or frequency of shuffles in virtual card games
5. 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
6. instructions on how to interact with the game
7. 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
8. 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.

1. Where a game builds up a collection of tokens (symbols etc), the current number collected.
2. An indication of which rules are currently relevant, such as displaying ‘bonus round’ or other feature labels.
3. 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:

1. a description of the way the game works and the way in which winners are determined and prizes allocated
2. house edge (or margin)
3. the return to player (RTP) percentage or
4. the probability (likelihood) of winning events occurring.

RTS implementation guidance 3C

1. The following items provide further guidance on acceptable types of information about the likelihood of winning:
1. 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
2. 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
3. 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
4. the house edge, margin or over-round, for example for a virtual race
5. 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.
6. The odds displayed in virtual event betting should reflect the probability of each event occurring as closely as possible.
2. 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.
3. 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

1. 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.
2. 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.
3. 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.
4. Information may be included in artwork and text displayed within the virtual event, in ‘help’ or ‘how to play’ pages, or other supporting material.
5. 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.
6. 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

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:

1. 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)
2. applying a handicapping system based on estimated performance and/or system latency
3. 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

1. Information should be included in game descriptions, rules, ‘help’ or ‘how to play’ pages.

RTS 5 – Result determination

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

1. Under normal operation, in the absence of technical faults, the system should act in accordance with the rules.
2. 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.
3. 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

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

1. 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.
2. Where 6A is not reasonably possible, it should be demonstrated that the method of producing outcomes does not introduce a systematic bias, for example:
   1. if tables of random numbers are used, they should be sufficiently long to support a large number of games without repeating
   2. the method should represent game probabilities accurately, ie it should not produce a higher than expected proportion of winning outcomes.
3. 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.
4. 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

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

1. RNGs should be capable of demonstrating the following qualities:
1. 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
2. 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
3. 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)
4. any forms of seeding and re-seeding used do not introduce predictability
5. any scaling applied to the output of the random number generator maintains the qualities as detailed
2. For lotteries using external events - where it is not practical to demonstrate 7A the events outcomes should be:
1. unpredictable, that is, events should be selected only where they may reasonably be assumed to be random events
2. unable to be influenced by the lottery operator (or external lottery manager)
3. publicly available and externally verifiable, for example, events that are published in local or national press would be acceptable.
3. 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:
1. the mechanical pieces should be constructed of materials to prevent decomposition of any component over time (for example, a ball shall not disintegrate)
2. the properties of physical items used to choose the selection should not be altered
3. players should not have the ability to interact with, come into physical contact with, or manipulate the mechanics of the game
4. 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

1. Games should implement the rules as described in the rules available to the customer before play commenced.
2. The mapping of the random inputs to game outcomes should be in accordance with prevailing probabilities, pay tables, etc.
3. 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.
4. 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

1. 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).
2. Where multiple physical devices are simulated the probabilities of each outcome should be independent of the other simulated devices.
3. Games may not falsely display near-miss results, that is, the event may not substitute one losing outcome with a different losing outcome.
4. 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.
5. 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.
6. 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

1. 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.
2. 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.
3. 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:
   1. virtual events, such as virtual racing products where the odds differ from event to event depending on the virtual runners
   2. virtual games, such as bingo where the odds of winning are dependent on the number of entrants
   3. games with progressive jackpots, where the amount that can be won changes over time
   4. games with bonus rounds where different rules apply, so long as these rounds are properly described to the customer
   5. 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:

In respect of requirement RTS 8A and 8B – Gaming (except slots)

In respect of requirement RTS 8C – Slots

RTS aim 8

To ensure that the customer is still in control of the gambling where auto-play functionality is provided and to minimise the risk that the functionality disadvantages a customer or that auto-play or other strategy advice is misleading.

RTS requirement 8A

The gambling system must provide easily accessible facilities that:

1. make available the following three controls, each of which stops auto-play functionality when it is triggered:
1. 'loss limit’, that is, where the player selects an option to not lose more than X from their starting balance, where X is an amount that can be selected by the player. A ‘loss’ in this context equates to accumulated auto-play bets minus accumulated auto-play wins.
2. 'single win limit’ that is, single win greater than Y where Y is an amount that can be selected by the player, and
3. ‘jackpot win’ (where applicable).
2. require auto-play to be implemented in such a way that each time a customer chooses to use auto-play they must select the stake, the number of autoplay gambles and at least the first of the above three controls.

The number of autoplay gambles must not exceed 100 in one batch. During auto-play the customer must be able to stop the autoplay regardless of how many autoplay gambles they initially chose or how many remain.

RTS implementation guidance 8A

1. Auto-play should not override any of the display requirements (for example, the result of each gamble must be displayed for a reasonable length of time before the next gamble commences, as set out in RTS 7E).

RTS requirement 8B

In relation to skill and chance games, strategy advice and auto-play functionality must be fair, not misleading and must not represent a poor choice.

RTS implementation guidance 8B

In implementing this control, the following should be considered, where appropriate:

1. if there is a standard strategy, for example, for well-known games like blackjack, the standard strategy should be used.
2. strategies or auto-play should (theoretically) produce at least the average Return to Player (RTP) for the game over time.

RTS requirement 8C

The gambling system must require a customer to commit to each game cycle individually. Providing auto-play for slots is not permitted.

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

1. 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.
2. 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.
3. 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.
4. 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

1. The gambling system shall maintain strict access and logging controls over the configuration and changes made to live jackpots.
2. 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.
3. 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:
1. waiting until the jackpot is next awarded before decommissioning it.
2. adding any remaining contributions onto another jackpot system, preferably one with a similar player base.
3. returning remaining contributions as a one off event, with adequate customer disclosure to explain the origin of money.
4. 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

1. For gaming the following policies should be applied:
1. 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
2. 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
3. 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
4. games with multiple participants (equal chance or otherwise) should be dealt with fairly on a case-by-case basis
5. progressive jackpot values should be restored to their pre-failure state.
2. For peer-to-peer betting the following policies should be applied:
1. 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
2. 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

1. For gaming the system should:
1. be capable of voiding gambles and restoring the amount gambled to the customer automatically, or in conjunction with manual operational controls; and
2. 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.
2. 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

1. Relevant activities to be recorded will vary by game but may include:
   1. which players played at which tables
   2. the amounts won from and lost to accounts
   3. game activities to an individual bet/action level.
2. Where appropriate, prevention measures may include:
   1. taking steps to prevent a player from occupying more than one seat at any individual table.
3. Detection measures may include, detecting and investigating the following, where appropriate:
   1. players who frequently share the same tables
   2. players from same address who share the same table
   3. suspicious patterns of play (such as chip dumping)
   4. unusual gameplay statistics.
4. Customer complaints about cheating should be investigated.
5. Records should be kept of investigations which result in an account being closed including:
   1. 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
   2. the reason for investigation (including whether it was initiated by customer contact) and the outcome
   3. 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

1. As a minimum deterrent, customers should be informed that accounts will be closed if the customer is found to have cheated.
2. 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.
3. Relevant information should be included in terms and conditions or rules.

RTS 12 – Financial limits

Applies to:

All gambling - except subscription lotteries

RTS aim 12

To provide customers with facilities that may assist them in sticking to their personal budgets for gambling with the operator. Customers must be also be given the option to set financial limits at an account level.

RTS requirement 12A

The gambling system must provide easily accessible facilities that make it possible for customers to impose their own financial limits. Customers must be given the opportunity to set a limit as part of the registration process (or at the point at which the customer makes the first deposit or payment).

RTS implementation guidance 12A

1. For telephone gambling (except lotteries), customers should be asked if they would like to set a deposit or spend limit when they register. Customers should be able to request a limit at any point after registration. The limit should be implemented as soon as practicable after the customer’s request. The customer should be informed when the limit will come into force.
2. For other access media (including internet, interactive TV and mobile), customers should be offered the opportunity to select a deposit/spend limit from a list which may contain a ‘no limit’ option or to enter a limit of their choice as part of the registration or first deposit process. The ‘no limit’ option should not be the default option.
3. Limits could be in the form of:
   1. deposit limits: where the amount a customer deposits into their account is limited over a particular duration
   2. 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
   3. 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).
4. The period/duration of the limits on offer should include:
1. 24 hours and
2. 7 days and
3. one month
5. In addition:
1. limits may be implemented per customer, per account, or other means
2. limits could also be implemented across all products or channels or for individual products or channels. Where limits are also set across separate products it should be clear to customers using the facility that a limit will need to be set for each individuals product. 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.
3. financial limit facilities should be provided via a link on the homepage
4. facilities should be available on deposit pages/screens or via a link on these pages or screens
5. 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

All reasonable steps must be taken to ensure that customer-led limits are only increased at the customer’s request, only after a cooling-off period of 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.

RTS implementation guidance 12B

Where possible (for instance, unless systems/technical failures prevent it) limit reductions are to be implemented within 24 hours of the request being received. In addition, at the point at which the customer requests a decrease in their limit, they should be informed when the limit reduction will take effect.

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 – Slots.

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

1. Time of day should either be taken from the customer’s own device or ‘server time’ and should be displayed in hours and minutes.
2. Operators will not be expected to detect whether or not customers have hidden their clocks.
3. Elapsed time should be displayed in minutes and hours.
4. For restricted display devices, time of day or elapsed time should be displayed where the device supports it.
5. 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

1. 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
2. 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:
1. 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.
2. 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.
3. 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.

3. 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).
4. The reality check should provide a link to the customer’s account history.
5. 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.
6. 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

1. Time displayed should begin either when the game is opened or once play commences.
2. 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, 14D, 14E and 14F – Slots.

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

1. 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:
   1. 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
   2. written or graphical information should not encourage customers to try to win back their losses
   3. customers who have chosen to exit a game should not be encouraged to continue playing by, for example, being offered a free game.
2. 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 slots games at the same time.

RTS implementation guidance 14C

1. Operators are not permitted to offer functionality designed to allow players to play multiple slots at the same time. This includes, but is not limited to, split screen or multi-screen functionality.
2. Combining multiple slots titles 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

1. 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.
2. This applies to all remote slots, regardless of game cycle speed.
3. This requirement does not apply to bonus/feature games where an additional stake is not wagered.

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

1. 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.
2. The following items provide guidelines for reasonable steps to inform the customer of the result of their game cycle:
   1. Display of total amount awarded.
   2. 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).
   3. Brief sound to indicate the result of the game and transfer to player balance. The sound should be distinguishable to that utilised with a win above total stake.

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

1. 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.
2. 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.
3. 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

1. 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.
2. 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³ , 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

1. 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.
2. 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.

---

³LCCP Social responsibility code 4.2.3


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

1. Equipment and consumables should be of commercial casino quality. Designated staff should be responsible for monitoring the integrity of all operational equipment.
2. 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.
3. 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.
4. Secure areas, gambling equipment and consumables shall be protected by appropriate access controls to ensure that only authorised personnel are allowed access.
5. 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

Standard - A.5 Information security policies
Standard - A.6 Organisation of information security
Standard - A.7 Human resources security
Standard - A.8 Asset management
Standard – A.9 Access Control
Standard – A.10 Cryptography
Standard – A.11 Physical and environmental security
Standard – A.12 Operations Security
Standard – A.13 Communications Security
Standard – A.14 System acquisition, development and maintenance
Standard – A.15 Supplier Relationships
Standard – A.16 Information Security Incident Management
Standard – A.18 Compliance

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/EIC 27001:20013 standard.

4.2 This 2013 standard replaces ISO/IEC 27001:2005.

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.

Security requirements summary

Standard - A.5 Information security policies

Objective A.5.1 Information security policy
Requirement A.5.1.1 Policies for information security
Requirement A.5.1.2 Review of the information security policy

Standard – A.6 Organisation of information security

Objective A.6.2 Mobile devices and teleworking
Requirement A.6.2.1 Mobile device policy
Requirement A.6.2.2 Teleworking

Standard – A.7 Human resources security

Objective A.7.2 During employment
Requirement A.7.2.2 Information Security Awareness, Education and Training.
Objective A.7.3 Termination or change of employment
Requirement 7.3.1 Termination or change of employment responsibilities

Standard – A.8 Asset management

Objective A.8.2 Information classification
Requirement A.8.2.3 Handling of assets.
Objective A.8.3 Media Handling
Requirement A.8.3.1 Management of removable media
Requirement A.8.3.2 Disposal of media

Standard – A.9 Access Control

Objective A.9.1 Business requirements of access control
Requirement A.9.1.1 Access control policy
Requirement A.9.1.2 Access to network and network services
Objective A.9.2 User access management
Requirement A.9.2.1 User registration and de-registration
Requirement A.9.2.2 User access provisioning
Requirement A.9.2.3 Management of privileged access rights
Requirement A.9.2.4 Management of secret authentication information of users
Requirement A.9.2.5 Review of user access rights
Requirement A.9.2.6 Removal or adjustment of access rights
Objective A.9.3 User responsibilities
Requirement A.9.3.1 Use of secret authentication information
Objective A.9.4 System and application access control
Requirement 9.4.1 Information access restriction
Requirement A.9.4.2 Secure log-on procedure
Requirement A.9.4.3 Password management system
Requirement A 9.4.4 Use of privileged utility programmes

Standard – A.10 Cryptography

Objective A.10.1 Cryptographic controls
Requirement A.10.1.1 Policy on use of cryptographic controls
Requirement A.10.1.2 Key management

Standard – A.11 Physical and Environmental Security

Objective A 11.2 Equipment
Requirement A.11.2.1 Equipment siting and protection
Requirement A.11.2.7 Secure disposal or re-use of equipment.
Requirement A.11.2.8 Unattended user equipment

Standard - A.12 Operations Security

Objective A.12.1 Operational procedures and responsibilities
Requirement A.12.1.4 Separation of development, testing and operational environments.
Objective A.12.2 Protection from malware
Requirement A.12.2.1 Controls against malware
Objective A.12.3 Protect against loss of data
Requirement A.12.3.1 Information backup
Objective A.12.4 Logging and monitoring
Requirement A.12.4.1 Event logging
Requirement A.12.4.2 Protection of log information
Requirement A.12.4.3 Administrator and operator logs.
Requirement A.12.4.4 Clock synchronisation.

Standard – A. 13 Communications Security

Objective A.13.1 Network security management
Requirement A.13.1.1 Network controls
Requirement A.13.1.2 Security of network services
Requirement A.13.1.3 Segregation in networks

Standard – A.14 System acquisition, development and maintenance

Objective A.14.1 Security requirements of information systems.
Requirement A.14.1.2 Securing application services on public networks
Requirement A.14.1.3 Protecting application service transactions
Objective A. 14.2 Security in development and support processes
Requirement A. 14.2.1 Secure development policy
Requirement A. 14.2.2 System change control procedures
Requirement A. 14.2.3 Technical review of applications after operating platform changes
Requirement A.14.2.4 Restrictions on changes to software packages
Requirement A. 14.2.5 Secure system engineering principles
Requirement A. 14.2.6 Secure development environment
Requirement A. 14.2.7 Outsourced development
Requirement A. 14.2.8 System security testing
Requirement A. 14.2.9 System acceptance testing
Objective A. 14.3 Test Data
Requirement A. 14.3.1 Protection of test data

Standard – A.15 Supplier Relationships

Objective A.15.1 Information security in supplier relationships.
Requirement A.15.1.1 Information security policy for supplier relationships.
Requirement A.15.1.2 Addressing security within supplier agreements
Requirement A.15.1.3 Information and communication technology supply chain
Objective A.15.2 Supplier service delivery management.
Requirement A.15.2.1 Monitoring and review of supplier services
Requirement A 15.2.2 Managing changes to supplier services

Standard – A.16 Information security incident management

Objective A. 16.1 Management of security incidents and improvements
Requirement A. 16.1.1 Responsibilities and procedures
Requirement A. 16.1.2 Reporting information security events
Requirement A. 16.1.3 Reporting information security weaknesses
Requirement A. 16.1.4 Assessment of and decision on information security events
Requirement A 16.1.5 Response to information security incidents
Requirement A. 16.1.7 Collection of evidence

Standard – A.18 Compliance

Objective A.18.2 Information security review
Requirement A.18.2.1 Independent review of security policy

5 - Annex

	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 (Slots)		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
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 (Slots)		X
RTS 14A&B – Responsible product design	X	X	X	X	X	X	X
RTS 14C-F – Responsible product design (Slots)		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), pool and intermediary, remote casino, remote bingo 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).