Remote gambling and software

technical standards
August 2009
Updated October 2014

Contents
1. Introduction

2. Definition of terms

3. Remote gambling and software technical standards

RTS 1 Customer account information

RTS 2 Displaying transactions
RTS 3 Rules, game descriptions and the likelihood of winning
RTS 4 Time-critical events
RTS 5 Result determination
RTS 6 Result determination for play-for-fun games
RTS 7 Generation of random outcomes
RTS 8 Auto-play functionality
RTS 9 Skill and chance games with auto-play
RTS 10 Interrupted gambling
RTS 11 Limiting collusion/cheating
RTS 12 Financial limits
RTS 13 Time requirements
RTS 14 Responsible product design

4. Information provision annex

IPA 1 Customer account information
IPA 2 Displaying transactions third party user-interfaces
IPA 3 In-running betting
IPA 4 Use of automated gambling software
IPA 5 Time-critical events
IPA 6 Interrupted gambling
IPA 7 Limiting collusion/cheating

5. RTS - Security requirements

Standard - A.5 Security policy
Standard - A.6 Organisation of information security
Standard - A.8 Human resources security
Standard - A.9 Physical and environmental security
Standard - A.10 Communications and operational management
Standard - A.11 Business requirement for access control
Standard - A.12 Correct processing in applications

6
7
9
11
12
13
14
17
18
19
20
21
22
23

24
24
25
26
27
28
29
30

31
31
31
31
31
32
33
34

6. Alternative provisions: RTS security requirements 35

Annex A. RTS security requirements
ISO/IEC 27001:2013
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 9 Access Control
Standard 10 Cryptography
Standard 11 Physical and Environmental Security
Standard 12 Operations Security
Standard 13 Communications Security
Standard 14 System acquisition, development and maintenance
Standard 15 Supplier Relationships
Standard A.18 Compliance
2

36
36
36
36
37
37
37
38
38
38
38
38
39

Introduction

1.1

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

1.2

This document replaces the Remote gambling and software technical standards (RTS)
June 2007.

Review of RTS
1.3

The Commission has monitored RTS since they came into force on 1 September 2007.
The Commission also carried out an initial review of RTS between October and December
2008 to determine whether there were any possible issues or changes that warranted a full
consultation.

1.4

Feedback from stakeholders indicated that the RTS remain fit for purpose and there are no
issues that required full consultation. The Commission published an information note on
this in December 2008.

1.5

In October 2013, the British Standards Institute (BSI) published an updated security
standard; ISO/IEC 27001:2013. The Commission therefore has undertaken an
assessment and produced a security requirements summary which translates the existing
requirements under ISO/IEC 27001:2005 into the new standard under ISO/IEC
27001:2013.
No further requirements have been added to this requirements summary as the existing
requirements have simply been mapped onto the new standard.

Changes to RTS
1.6

This updated RTS document does not include any changes to policy. However, the
Commission has decided to publish an updated version to document the mapped security
requirements of ISO/IEC 27001/2013 as Annex A.

1.7

This version now includes:

remote gambling and software technical standards
information provision annex
a summary of the RTS security requirements that licence holders must meet (in
chapter 5)
a summary of the new RTS security requirements under the new standard ISO/IEC
27001:2013 (in Annex A).

Testing and audit requirements

1.8

The Commissions Testing strategy for compliance with the remote gambling and software
technical standards(Testing strategy)- October 2014 sets out the Commissions current
requirements for the timing and procedures for testing. Compliance with the RTS and
testing strategy is a licence condition 1.

1.9

Importantly it sets out the circumstances in which independent third party testing is
required. The relevant standards are given in chapters 3 and 4 of this document.

1.10

The Testing strategy also sets out the independent audit requirements that licence holders
should fulfil. This is based on the relevant sections of ISO/IEC 27001: 2005 which are

Condition 2.3 in Licence Conditions and Codes of Practice (LCCP), May 2014
3

summarised in chapter 5 of this document, or for those adhering to the new security
standards, the relevant sections of ISO/IEC 27001:2013 which are summarised in Annex A
of this document.

Application to remote bingo licences

1.10

The following standards do not 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 1
RTS 2
RTS 6
RTS 8
RTS 9
RTS 11
RTS 12
RTS 13
RTS 14
IPA 1-5
IPA 7

Gambling software
1.11

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.

Definition of terms

2.1

In this document the following terms have the following meanings:

Compensated games or events

Game
Instant lottery
Mapping

Lottery

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.
A game of chance as defined in section 6(2) of the Act
A lottery in which the draw takes place before any of the tickets in the
lottery are offered for sale.
Is 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.
As described by section 14 of the Act.

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
(a) retain the message electronically or
(b) print it.

Non-commercial society

As described by section 19 of the Act.

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.

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 or personal digital assistant 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.

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 1 and 100,000
but these possible outcomes need to be scaled to the potential game
outcomes of, for example, between 1 52 (ie to correspond to a
standard pack of cards).
Refers to the process used to determine the initial state of the RNG.

Seeding
Subscription lottery

Telephone gambling

Virtual

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.
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.
As described by s353(3) of the Act. Virtual event and virtual game are
to be construed accordingly.

Remote gambling and software technical standards (RTS)

RTS 1 Customer account information

All gambling except subscription lotteries
RTS aim 1
To provide customers with easily accessible information about their current balances.
RTS requirement 1A
Where customers hold a credit or debit balance, the pages or screens used to move money into
and out of accounts or products must be designed to display the customers current account or
product balance, either in the currency of their account or the currency of the gambling product
(e.g. dollars, euros or pounds sterling), whenever that customer is logged in.
For telephone betting this information is to be delivered at the customers request by the customer
service agent or automated response system.
RTS implementation guidance 1A
a. Where funds are moved between products (for example, from a betting product to a gaming
product) the balance does not necessarily have to represent all of the balances that a customer
may hold with an operator in respect of those products.
RTS requirement 1B
Where customers hold a credit or debit balance, the pages or screens used for gambling must be
designed to display the customers current account or product balance, or where this is not
practical to display a link to a page or screen that shows the balance, whenever that customer is
logged in. Balances are to be presented either in the currency of the customers account or the
currency of the gambling product (e.g. dollars, euros or pounds sterling).
For telephone betting this information is to be delivered at the customers request by the customer
service agent or automated response system.
RTS implementation guidance 1B
a. Where funds are moved between products, the balance does not necessarily have to represent
all of the balances that a customer may hold with an operator in respect of other products.
b. Gambling pages and screens include virtual game pages, sports betting coupons, and poker
and other virtual gaming tables.

RTS 2 Displaying transactions

All gambling
RTS aim 2
To enable the customer to understand the value and content of their transactions.
RTS requirement 2A
The remote gambling system must be designed to 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.
For telephone gambling, this information is to be delivered by the customer service agent or
automated response system.
RTS implementation guidance 2A
a. It is preferable for the amount being gambled to be displayed either in the currency of the
customers account or in the currency of the product. The use of credits, chips or other tokens with
no face value should be avoided wherever possible.
b. 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.
c. Information about the value of the gamble should be displayed including, as appropriate:
i. unit stake and total stake, whether currency, credit, tokens, chips, or any other form of
payment
ii. entry fees, for example, payment for entry to poker tournaments
iii. the price of lottery tickets and the number of draws entered.
d. 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 be designed to display sufficient relevant information about the
customers 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.
For telephone betting, this information is to be delivered by the customer service agent or
automated response system.
RTS implementation guidance 2B
a. The following items provide guidelines about the type of information that may be relevant:
i. selections the items the customer has chosen to gamble on;
ii. the bet type
iii. the accepted odds, for example current odds, starting price, first show, etc.
These items, where relevant, are required on applications designed for use on restricted display
devices.
b. For telephone gambling the content of the customers bet should be read back to them before
the bet is confirmed.
c. 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
7

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.
d. 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 3 Rules, game descriptions and the likelihood of winning

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
a. Explanatory content includes information in artwork and text displayed within the virtual event, in
help or how to play pages, or other supporting material.
b. 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.
c. As a minimum, restricted display devices should provide explanatory content via a menu item or
other link.
d. The following items provide guidelines on the type of explanatory content that may be relevant
and should be considered for inclusion:
i. the name of the game, lottery or virtual event
ii. the applicable rules, including clear descriptions of what constitutes a winning outcome
iii. restrictions on play or betting, such as any play duration limits, maximum wins, etc
iv. the number of decks or frequency of shuffles in virtual card games
v. 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
vi. instructions on how to interact with the game
vii. 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
viii. 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.
a. Where a game builds up a collection of tokens (symbols etc), the current number collected.
b. An indication of which rules are currently relevant, such as displaying bonus round or other
feature labels.
c. 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:
9

i.

a description of the way the game works and the way in which winners are determined
and prizes allocated;
ii. house edge (or margin);
iii. the return to player (RTP) percentage; or
iv. the probability (likelihood) of winning events occurring.
RTS implementation guidance 3C
a. The following items provide further guidance on acceptable types of information about the
likelihood of winning:
i. 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;
ii. 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.
iii. the average theoretical return to player percentage. Where an event (other than peerto-peer) involves an element of skill, return to player percentage should be calculated
using either the auto-play strategy or a standard/published strategy;
iv. the house edge, margin or over-round, for example for a virtual race;
v. 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.
b. 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.
c. 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
a. 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.
b. 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.
c. 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.
d. Information may be included in artwork and text displayed within the virtual event, in help or
how to play pages, or other supporting material.
e. 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.
f. 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.

10

RTS 4 Time-critical events

Gaming (including bingo), 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, where response time has a significant impact on the likelihood of winning.
RTS requirement 4A
Where speed of interaction has a significant effect on the customers 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:
a. 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 (e.g. high, medium, low)
b. applying a handicapping system based on estimated performance and/or system
latency
c. 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.

11

RTS 5 Result determination

All gambling
RTS aim 5
To ensure that the gambling system implements the operators 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
a. Under normal operation, in the absence of technical faults, the system should act in accordance
with the rules.
b. Reasonable steps include testing of systems and new products against the published rules.
c. 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 customers account.

12

RTS 6 Result determination for play-for-fun games

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-fun games.
RTS requirement 6A
Play-for-fun games must implement the same game rules as the corresponding play-for-money
games. Operators must take all reasonable steps to ensure that play-for-fun 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
a. 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.
b. Where 6a is not reasonably possible, it should be demonstrated that the method of producing
outcomes does not introduce a systematic bias, for example:
i. if tables of random numbers are used, they should be sufficiently long to support a
large number of games without repeating
ii. the method should represent game probabilities accurately, ie it should not produce a
higher than expected proportion of winning outcomes.
c. The prize distribution should accurately represent the play-for-money game. For example,
where play-for-fun 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.

13

RTS 7 Generation of random outcomes

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 (i.e. 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 (for example, using numbers from the National Lottery) the outcome must be
unpredictable and externally verifiable.
RTS implementation guidance 7A
a. RNGs should be capable of demonstrating the following qualities:
i. 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/theoretical probabilities
ii. 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
iii. 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)
iv. any forms of seeding and re-seeding used do not introduce predictability
v. any scaling applied to the output of the random number generator maintains the
qualities above.
b. For lotteries using external events - where it is not practical to demonstrate 7a. - the events
outcomes should be:
i. unpredictable, that is, events should be selected only where they may reasonably be
assumed to be random events
ii. unable to be influenced by the lottery operator (or external lottery manager)
iii. publicly available and externally verifiable, for example, events that are published in
local or national press would be acceptable.
c. 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:
i. the mechanical pieces should be constructed of materials to prevent decomposition of
any component over time (e.g. a ball shall not disintegrate)
ii. the properties of physical items used to choose the selection should not be altered
iii. players should not have the ability to interact with, come into physical contact with, or
manipulate the mechanics of the game.
d. 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.

14

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
a. Games should implement the rules as described in the rules available to the customer before
play commenced.
b. The mapping of the random inputs to game outcomes should be in accordance with prevailing
probabilities, pay tables, etc.
c. When random numbers, scaled or otherwise, are received, e.g. following a game requesting a
sequence of random numbers, they are to be used in the order in which they are received. For
example, they may not be discarded due to adaptive behaviour.
d. 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
a. 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).
b. Where multiple physical devices are simulated the probabilities of each outcome should be
independent of the other simulated devices.
c. Games may not falsely display near-miss results, that is, the event may not substitute one
losing outcome with a different losing outcome.
d. 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.
e. 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.
f. 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 customers attention.
RTS implementation guidance 7D
a. 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.

15

b. 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.
c. 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:
i. virtual events, such as virtual racing products where the odds differ from event to event
depending on the virtual runners
ii. virtual games, such as bingo where the odds of winning are dependent on the number
of entrants
iii. games with progressive jackpots, where the amount that can be won changes over
time
iv. games with bonus rounds where different rules apply, so long as these rounds are
properly described to the customer
v. 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 must be designed to clearly and accurately
display the result of the game or event and the customers 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.

16

RTS 8 Auto-play functionality

Gaming
RTS aim 8
To ensure that the customer is still in control of the gambling where auto-play functionality is
provided.
RTS requirement 8A
Auto-play must be implemented in such a way that the customer is able to control the amount
gambled through selecting the stake and the number of auto-play gambles. The number of autoplay gambles may not exceed 25 in one batch.
RTS implementation guidance 8A
a. The customer should choose the stake and either the number of auto-play gambles or the total
amount to be gambled.
b. During auto-play the customer should be able to stop the auto-play regardless of how many
auto-play gambles they initially chose or how many remain.
c. 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).

17

RTS 9 Skill and chance games with auto-play

Gaming
RTS aim 9
To minimise the risk that auto-play functionality disadvantages a customer or that autoplay or
other strategy advice is misleading.
RTS requirement 9A
Strategy advice and auto-play functionality must be fair, not misleading and must not represent a
poor choice.
RTS implementation guidance 9A
a. In implementing this control, the following should be considered, where appropriate:
i. if there is a standard strategy, for example, for well known games like blackjack, the
standard strategy should be used
ii. strategies or auto-play should (theoretically) produce at least the average Return to
Player (RTP) for the game over time.

18

RTS 10 Interrupted gambling

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
a. For gaming the following policies should be applied:
i. where an interruption occurs after the operator receives notification of the customers
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
ii. 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
iii. 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
iv. games with multiple participants (equal chance or otherwise) should be dealt with fairly
on a case-by-case basis
v. progressive jackpot values should be restored to their pre-failure state.
b. For peer-to-peer betting the following policies should be applied:
i. 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
ii. 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
a. For gaming the system should:
i. be capable of voiding gambles and restoring the amount gambled to the customer
automatically, or in conjunction with manual operational controls; and
ii. 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, e.g. who has staked what on what outcome
bets placed or offered.
b. For peer-to-peer betting, it should be possible to suspend betting markets manually or
automatically.

19

RTS 11 Limiting collusion/cheating

Peer-to-peer gaming
RTS aim 11
To reduce the risk that cheating or collusion by players unfairly disadvantages another player.
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.
RTS implementation guidance 11A
a. The Information Provision Annex standard 7 provides guidance on the minimum information that
should be made available to deter cheating.
b. Relevant activities to be recorded will vary by game but may include:
i. which players played at which tables
ii. the amounts won from and lost to accounts
iii. game activities to an individual bet/action level.
c. Where appropriate, prevention measures may include:
i. taking steps to prevent a player from occupying more than one seat at any individual
table.
d. Detection measures may include, detecting and investigating the following, where appropriate:
i. players who frequently share the same tables
ii. players from same address who share the same table
iii. suspicious patterns of play (such as chip dumping).
e. Customer complaints about cheating should be investigated.

20

RTS 12 Financial limits

All gambling
RTS aim 12
To provide customers with facilities that may assist them in sticking to their personal budgets for
gambling with the operator.
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).
For lotteries, where the customers spend is controlled through subscriptions, additional facilities
do not have to be provided.
RTS implementation guidance 12A
a. 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 customers
request. The customer should be informed when the limit will come into force.
b. 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.
c. Limits could be in the form of:
i. deposit limits: where the amount a customer deposits into their account is limited over a
particular duration
ii. 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
iii. loss limits: where the amount lost (i.e. winnings subtracted from the amount spent) is
restricted (for instance when a customer makes a 10 bet and wins 8, the loss is 2).
d. The period/duration of the limit should be no less than one day (or 24 hours).
e. In addition:
i. limits may be implemented per customer, per account, or other means
ii. limits could also be implemented across all products or channels or for individual
products or channels
iii. financial limit facilities should be provided via a link on the home page
iv. facilities should be available on deposit pages/screens or via a link on these
pages/screens.
RTS requirement 12B
All reasonable steps must be taken to ensure that customer-led limits are only increased at the
customers request, and only after a cooling-off period of 24 hours has elapsed.
RTS implementation guidance 12B
a. Increases should not be implemented until a cooling-off period of at least 24 hours from the
point at which the request to increase the limit was received. Where it is practicable to do so, the
customer should be required to confirm that they still wish to increase the limit at the end of the
cooling-off period.
b. Where possible (for instance, unless systems/technical failures prevent it) limit reductions are to
be implemented within 24 hours of the request being received.
21

RTS 13 Time requirements

All gambling except telephone gambling
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
customers 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
a. Time of day should either be taken from the customers own device or server time and should
be displayed in hours and minutes.
b. Operators will not be expected to detect whether or not customers have hidden their clocks.
c. Elapsed time should be displayed in minutes and hours.
d. For restricted display devices, time of day or elapsed time should be displayed where the device
supports it.
e. In addition, customers may be offered the ability to set a session or game-play duration
reminder.

22

RTS 14 Responsible product design

All gambling
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
a. 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:
i. the amount of funds taken into a product should not be topped up without the customer
choosing to do so on each occasion, e.g. when a customer buys-in at a poker table
they should have to choose to purchase more chips to play at the table - automatic rebuys should not be provided
ii. written or graphical information should not encourage customers to try to win back their
losses
iii. customers who have chosen to exit a game should not be encouraged to continue
playing by, for example, being offered a free game.
b. This requirement is not intended to prevent operators from offering special features or wellknown games such as blackjack that allow customers to increase their stake on the occurrence of
specific events (e.g. split).

23

Information provision annex (IPA) standards

IPA 1 Customer account information

All gambling except subscription lotteries
IPA aim 1
To provide customers with facilities that enable them to review previous gambling and account
transactions.
IPA requirement 1A
Customers must have easy access to their account and gambling history. Where customers
access operators products or register via websites, it is acceptable to provide access to
statements via these websites. For customers who do not access or register via websites,
information is to be provided via the medium of access, or a copy must be sent via email, fax, or
post.
IPA implementation guidance 1A
a. 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.
b. For betting, gambling history should include bets placed, and the results of bets, including
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.
c. 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.
d. For telephone betting, 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.
e. For gaming, where detailed historic game information may not necessarily be directly available
to customers, as a minimum, customers should have easy access to details of the last game
played and summarised information for previous activities.
f. For restricted display devices, where customers demonstrate that they also have access to
websites for example, by registering online or using other online products it is acceptable to
provide access to statements via these websites. Otherwise, if the information cannot practicably
be provided on the device, customers should be sent a copy of the statement via email, fax or
post.

24

IPA 2 Displaying transactions third party user-interfaces

IPA aim 2
To inform customers who choose to use third party user-interfaces that they may not receive full
information about their gambles.
IPA requirement 2A
Customers must be informed that third party interface applications may not display full information
about the customers gambles.
IPA implementation guidance 2A
a. 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.

25

IPA 3 In-running betting

Betting and peer-to-peer betting
IPA aim 3
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.
IPA requirement 3A
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-running betting pages must be
designed to include this information where practicable.
IPA implementation guidance 3A
a. Brief information should be included on main in-running pages or screens, such as the inrunning home page or screen. More detail should be provided in help or how to or other product
pages or screens.
b. 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.
c. 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.

26

IPA 4 Use of automated gambling software

Peer-to-peer gambling
IPA aim 4
To make customers in peer-to-peer(s) gambling aware that they may be gambling against a
software program (designed to automatically participate in gambling within certain parameters),
rather than another (human) participant. This software is sometimes referred to as a robot or bot.
IPA requirement 4A
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.
IPA implementation guidance 4A
a. Peer-to-peer(s) 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.
b. 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.
IPA requirement 4B
Where peer-to-peer(s) customers may be gambling against programs deployed by other
customers to play on their behalf, information should be made available that describes that this is
possible, and if it is against the operators terms and conditions to use robots, how to report
suspected robot use.
IPA implementation guidance 4B
a. 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.
b. 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.

27

IPA 5 Time-critical events

Gaming (including bingo), betting on virtual events, and peer-to-peer betting
IPA aim 5
To make the customer aware that they may be at a disadvantage due to technical characteristics,
such as slower network connections or lower end user device performance, if they are
participating in a time-critical form of gambling (where the customers speed of interaction
influences their chance of winning).
IPA requirement 5A
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.
IPA implementation guidance 5A
a. Information should be included in game descriptions, rules, help or how to play pages.

28

IPA 6 Interrupted gambling

Gaming (including bingo), betting on virtual events, and peer-to-peer betting
IPA aim 6
To inform customers about the operators policies with regard to service interruptions and how
they are likely to be treated if interruption occurs so that they may make an informed decision
about whether to gamble and in what way.
IPA requirement 6A
Operators must make available information about their policies regarding service interruptions in
various different circumstances.
IPA implementation guidance 6A
a. 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.

29

IPA 7 Limiting collusion/cheating

Peer-to-peer gaming
IPA aim 7
To inform customers about the risks posed by collusion/cheating and to deter individuals from
attempting to cheat.
IPA requirement 7A
Information must be made available about the operators policies and procedures with regard to
cheating, and about how to complain if a customer suspects other participants are cheating.
IPA implementation guidance 7A
a. As a minimum deterrent, customers should be informed that accounts will be closed if the
customer is found to have cheated.
b. Relevant information should be included in terms and conditions or rules.

30

Remote gambling and software technical standards

security requirements

5.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: 2005 standard.

5.2

The Commissions 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
Commissions aims and the security standards apply to these critical systems:
electronic systems that record, store, process, share, transmit or retrieve sensitive
customer information, eg 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 customers 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 Security Policy
Objective A.5.1 Information security policy
Requirement A.5.1.1 Information security policy document
Requirement A.5.1.2 Review of the information security policy
Standard A.6 Organization of information policy
Objective A.6.1 Internal organization
Requirement A.6.1.8 Independent review of information security
Standard A.8 Human resources security
Objective A.8.2 During employment
Requirement A.8.2.2 Information security awareness, education and training
Objective A.8.3 Termination or change of employment
Requirement A.8.3.3 Removal of access rights
Standard A.9 Physical and environmental security
Objective A.9.2 Equipment security
Requirement A.9.2.1 Equipment siting and protection
Requirement A.9.2.6 Secure disposal or re-use of equipment
31

Standard A.10 Communications and operations management

Objective A.10.1 Operational procedures and responsibilities
Requirement A.10.1.4 Separation of development, test and operational facilities
Objective A.10.2 Third party service delivery management
Requirement A.10.2.1 Service delivery
Requirement A.10.2.2 Monitoring and review of third party services
Requirement A.10.2.3 Managing changes to third party services
Objective A.10.4 Protection against malicious and mobile code
Requirement A.10.4.1 Controls against malicious code
Requirement A.10.4.2 Controls against mobile code
Objective A.10.5 Back-up

Requirement A.10.5.1 Information back-up

Objective A.10.6 Network security management
Requirement A.10.6.1 Network controls
Requirement A.10.6.2 Security of network services
Objective A.10.7 Media handling
Requirement A.10.7.1 Management of removable data
Requirement A.10.7.2 Disposal of media
Requirement A.10.7.3 Information handling procedures
Requirement A.10.7.4 Security of system documentation
Objective A.10.9 Electronic commerce services
Requirement A.10.9.1 Electronic commerce
Requirement A.10.9.2 On-line transactions
Objective A.10.10 Monitoring
Requirement A.10.10.1 Audit logging
Requirement A.10.10.2 Monitoring systems use
Requirement 10.10.3 Protection of log information
Requirement 10.10.4 Administrator and operator logs
Requirement 10.10.5 Fault logging
32

Requirement A.10.10.6 Clock synchronization

Standard A.11 Business requirement for access control
Objective A.11.1 Business requirement for access control
Requirement A.11.1.1 Access control policy
Objective A.11.2 User access management
Requirement A.11.2.1 User registration
Requirement A.11.2.2 Privilege management
Requirement A.11.2.3 User password management
Requirement A.11.2.4 Review of user access rights
Objective A.11.3 User responsibilities
Requirement A.11.3.1 Password use
Requirement A.11.3.2 Unattended user equipment
Objective A.11.4 Network access control
Requirement A.11.4.1 Policy on use of network services
Requirement A.11.4.2 User authentication for external connection
Requirement A.11.4.3 Equipment identification in networks
Requirement A.11.4.4 Remote diagnostic and configuration port protection
Requirement A.11.4.5 Segregation in networks
Requirement A.11.4.6 Network connection control
Requirement A.11.4.7 Network routing control
Objective A.11.5 Operating system access control
Requirement A.11.5.1 Secure log-on procedures
Requirement A.11.5.2 User identification and authentication
Requirement A.11.5.3 Password management system
Requirement A.11.5.4 Use of system utilities
Requirement A.11.5.5 Session time-out
Requirement A.11.5.6 Limitation of connection time
Objective A.11.6 Application and information access control
Requirement A.11.6.1 Information access restriction
33

Requirement A.11.6.2 Sensitive system isolation

Objective A.11.7 Mobile computing and teleworking
Requirement A.11.7.1 Mobile computing and communications
Requirement A.11.7.2 Teleworking
Standard A.12 Correct processing in applications
Objective A.12.2 Correct processing in applications
Requirement A.12.2.1 Input data validation
Requirement A.12.2.2 Control of internal processing
Requirement A.12.2.3 Message integrity
Requirement A.12.2.4 Output data validation
Objective A.12.3 Cryptographic controls
Requirement A.12.3.1 Policy on the use of cryptographic controls
Requirement A.12.3.2 Key management
These requirements were notified in draft to the European Commission in accordance with
Directive 98/34/EC, as amended by Directive 98/48/EC.

34

Alternative provisions: Remote gambling and software

technical standards security requirements

6.1

Following a recent review, the British Standards Institution has updated the standard
ISO/IEC 27001:2005 to ISO/IEC 27001:2013.

6.2

The new standard has already been released and came into force in October 2013. The
Commission is aware that operators may wish to have their security systems audited
against the new standard.

6.3

The Commission therefore has undertaken an assessment and produced a security

requirements summary which translates the existing requirements under ISO/IEC
27001:2005 into the new standard under ISO/IEC 27001:2013.

6.4

No further requirements have been added to this requirements summary as the existing
requirements have simply been mapped onto the new standard. The new security
standards under ISO/IEC 27001:2013 have been included in the Commissions Remote
gambling and software technical standards under Annex A (below).

35

Annex A: Remote gambling and software technical standards

security requirements ISO/IEC 27001:2013
1.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 the ISO/EIC 27001: 2005 standard and, where appropriate, has mapped them on to the
relevant sections of the ISO/IEC 27001:2013 standard. A full copy of the British Standards
can be obtained from BSI Customer Services, 389 Chiswick High Road, London, W4 4AL.
Tel: +44 (0)845 086 9001. Email: cservices@bsigroup.com

1.2

The Commissions 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
Commissions aims and the security standards apply to these critical systems:
electronic systems that record, store, process, share, transmit or retrieve sensitive
customer information, e.g. 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 customers 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

36

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 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 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

37

Standard 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 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 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 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
Standard 15 Supplier Relationships
Objective A.15.1 Information security in supplier relationships.
38

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.18 Compliance

Objective A.18.2 Information Security Review

Requirement A.18.2.1 Independent review of security policy

Gambling Commission October 2014

Keeping gambling fair and safe for all

For further information or to register your interest in the Commission please visit our website at:
www.gamblingcommission.gov.uk
Copies of this document are available in alternative formats on request.
Gambling Commission
Victoria Square House
Victoria Square
Birmingham B2 4BP
T 0121 230 6666

F 0121 230 6720

E info@gamblingcommission.gov.uk
ADV 14/17
39