Technical requirements on

gambling operators

for obtaining a licence to provide

online gambling services in Denmark

Version 1.09

2

Contents Change log ........................................................................................................................................... 2

1.0 Introduction .................................................................................................................................... 4

2.0 Introduction to the overall system complex ................................................................................... 5

3.0 General requirements ..................................................................................................................... 6

4.0 SAFE – The Licence Holder’s data store ....................................................................................... 7

4.1 Technical requirements for SAFE.............................................................................................. 7

4.2 Use case and process for retrieving data from SAFE ................................................................ 8

UC 2.1 Retrieve Standard Records from SAFE ........................................................................... 9

5.0 Interface to security system – Tamper Token .............................................................................. 11

5.1 Technical requirements in relation to Tamper Token .............................................................. 11

6.0 Interface to the Problem Gambling Register (ROFUS) ............................................................... 12

6.1 Technical requirements in connection with the Problem Gambling Register ......................... 12

6.2 Inquiry to ROFUS upon account opening and account login .................................................. 13

6.2.1 Inquiry to ROFUS when accounts are opened .................................................................. 13

6.2.2 Process description – inquiry to ROFUS upon account login .......................................... 14

7.0 Technical information to be given in the application form .......................................................... 17

8.0 Connection process ...................................................................................................................... 17

Change log

Version Description of changes Date

1.01 Document published 20-10-2010

1.02 Minor proof corrections and name changes of services in section 5.1 26-10-2010

1.03 Change log added. Minor proof corrections and addition of section 4

and 4.1

05-11-2010

1.04 Minor proof corrections in section 4.0 (Datatransfer is done over the

internet with FTPS.)

ROFUS is the short version of The Problem Gambling Register.

Corrections in section 6.0. Licence Holder cannot carry out entries of

a person in the Problem Gambling Register (ROFUS) which is why

the service GamlerCreate is no longer used.

30-06-2011

1.05 Minor corrections in the process diagram regarding the account open-

ing.

1.06 Corrections regarding the checking of a players civil registration

number.

Adding allowed certificates for FTPS.

Adding IP-addresses for accessing SAFE.

25-10-2011

1.07 Bullet 14 added to section 4.1. The bullet holds a description of the

configuration of the FTPS connection to SAFE, including change of

port from port 22 as previously specified. The change of port has

been done in order to be consistent with common internet standards

for FTPS.

18-11-2011

1.08 Section 4.1 has been updated with ip-adresses. 23-01-2012

1.09 Section 8.0. Information about the connection process can be found

on Danish Gambling Authority’s website

15-02-2012

3

4

1.0 Introduction The purpose of this document is to describe the technical requirements to be met by the Licence

Holder before a licence is granted. The requirements are described in relation to the systems that

will be used in connection with the Danish Gambling Authority's control of the Licence Holder, i.e.

the Licence Holder's data store - SAFE, the security system Tamper Token and the Problem Gam-

bling Register (ROFUS).

The individual sections contain descriptions of the requirements to be met by the Licence Holder in

relation to data, processes and interfaces in connection with gambling and gambling control.

Next, there is an outline of the requirements in respect of technical information in connection with

the application process. The requirements stated as to information to be provided in the application

process are not exhaustive at this time. Thus, it should be expected that there will be further re-

quirements on gambling operators in connection with their licence applications, including a gam-

bling systems approval procedure.

The document will also be updated with information about the elements of the connection process

upon approval.

5

2.0 Introduction to the overall system complex The overall system complex for gambling control is shown in the illustration below.

Outline of the components of the overall gambling and control system

The system complex consists of the Licence Holder's gambling system, the Licence Holder's data

store (SAFE), a security system (Tamper Token) and a Problem Gambling Register (ROFUS).

1. SAFE is the Licence Holder's own data store (a file server) where the Licence Holder is

required to store data - in accordance with Standard Records - for all games hosted by

the Licence Holder. All Licence Holders are required to establish data storage facilities

(SAFE). The Danish Gambling Authority must be able to obtain online access to the Li-

6

cence Holder's data store.

2. Tamper Token is a security system which is aimed to ensure that the data saved by the

Licence Holder in its SAFE data store remain unchanged while stored by the Licence

Holder. Tamper Token will be implemented in the Danish Gambling Authority’s system

and handle:

• Creating keys (tokens) used for calculation of identification codes.

• Storing identification codes for later control.

• Ongoing control of compliance with time periods for termination of tokens.

• Verifying that a retrieved series of data has not been changed in relation to the identi-

fication code received.

3. The Problem Gambling Register (ROFUS) is a register of all players in Denmark

who have voluntarily requested exclusion - temporarily or permanently - from playing

online games in Denmark. The register is located at the Danish Gambling Authority,

which is also responsible for keeping the register. It must be possible for all players to

register through either the Licence Holder or the Danish Gambling Authority. The regis-

ter will contain information about all excluded players in Denmark. Prior to opening an

account for a new player, the Licence Holder must check that the person in question is

not listed in the register. The Licence Holder is responsible for ensuring that players on

the register are unable to play.

Together, the three systems will help ensure that:

• players are able to play online games with approved Licence Holders;

• Licence Holders are able to legally provide online games in Denmark and prove that

they meet statutory requirements; and

• the Danish Gambling Authority is able to check that online gambling will meet the re-

quirements of current legislation.

3.0 General requirements As outlined above, the Danish Gambling Authority develops systems to be used in the control of

online gambling, and Licence Holders must ensure to develop gambling systems that are capable of

using interfaces to the Danish Gambling Authority’s systems. This will allow the Danish Gambling

Authority to process data and check that online gambling takes place in accordance with regulatory

requirements. It is a requirement that the Licence Holder uses the specified interfaces to the Danish

Gambling Authority’s systems developed by the Authority for this purpose and that the Licence

Holder sets up a SAFE to which the Danish Gambling Authority will be given access.

To live up to the rules laid out in the new legislation, Licence Holders must satisfy a number of

technical requirements in relation to the three systems mentioned. In the sections below, these tech-

7

nical requirements will be specified in greater detail. The requirements are grouped according to the

system to which they belong.

4.0 SAFE – The Licence Holder’s data store The Licence Holder must establish a data store (SAFE) for the storage of gambling data. The Li-

cence Holder must transfer and save gambling data in the data store according to Standard Records.

The Licence Holder must store gambling data in SAFE for 12 consecutive months and data from a

further 48 months must be stored on a digitally readable medium.

Datatransfer is done over the internet with FTPS. The License Holder must establish a suitable con-

nection to secure an unproblematic transfer of data.

4.1 Technical requirements for SAFE

1. SAFE must be established on a separate server, which is physically detached from the Li-

cence Holder’s gambling system.

2. Data stored in SAFE must be separated logically and safely from any other data.

3. The Licence Holder must ensure the necessary backup of all data. SAFE and the backup of

SAFE must be geographically separated. In addition, the data storage on a digitally readable

medium must be geographically separated from the backup of the data thus stored.

4. SAFE must meet the same safety requirements as the gambling system. The requirements

will be set during the application procedure.

5. The Licence Holder must ensure that the Danish Gambling Authority will have online ac-

cess to retrieving gambling data from SAFE. The Licence Holder must establish access to

SAFE via a secure connection as defined in the service description.

6. The folder structure in SAFE must be built up on the basis of the structure specified by the

Danish Gambling Authority. The folder structure may be found at

www.spillemyndigheden.dk.

7. Data stored in SAFE must have been saved in accordance with the specified Standard Rec-

ords. The specification of Standard Records may be found at www.spillemyndigheden.dk.

8. Data stored in SAFE must be zipped in accordance with the directions for service usage. The

directions may be found at www.spillemyndigheden.dk.

9. The Licence Holders must document that their respective SAFE systems comply with the

requirements defined.

10. SAFE must be available 24 / 7 365 days and there should be a guaranteed uptime of at least

98.5 %.

11. Licence Holders are responsible for the operation of their own SAFE systems.

12. For the Danish Gambling Authority to access safe using FTPS, the Licence Holder must

place a certificate on the FTPS connection. The certificate must be issued by one of the fol-

lowing Certificate Authorities: VeriSign, Thawte, Geotrust, GoDaddy, Comodo

13. The Danish Gambling Authority will access SAFE from these ip-addresses: 91.230.68.13,

91.230.68.190, 194.239.239.10, 194.239.239.30, 194.239.239.31, 194.239.239.32,

194.239.239.33, 194.239.239.34. The Licence Holder must open SAFE for access from

those ip-addresses.

14. The Licence Holder must configure SAFE such that the following connection is possible:

The Danish Gambling Authority must be able to access SAFE with implicit FTPS (FTP-

SSL) in passive mode on port 990 (control). As data ports should be used a port range be-

8

tween 40.000 and 50.000. The Licence Holder may use a smaller port range as long as it is

with in the two limits.

4.2 Use case and process for retrieving data from SAFE The Licence Holder must develop an interface for its SAFE that will allow the Danish Gambling

Authority to access the SAFE to retrieve data. The required functionality for this interface is de-

scribed in the ‘use case’ below. The case may be used in the development of the interface.

9

UC 2.1 Retrieve Standard Records from SAFE

Purpose The Danish Gambling Authority must carry through periodic control of completed and ongoing games based

on Standard Records. The Standard Records are placed in the structure specified by the Danish Gambling

Authority.

To retrieve Standard Records the Danish Gambling Authority must be logged on to SAFE. When the transfer

of data has been ended, the Danish Gambling Authority must log out of SAFE.

Frequency As required.

Actors The Danish Gambling Authority

Starting conditions The Danish Gambling Authority is a recognised user (user name/password) on SAFE.

Main path

Actor Solution Service/Service operations

Step 1: Log on to SAFE

The actor requests access to data in

SAFE by opening an FTPS connec-

tion.

The solution asks the actor for a

user name and password.

Step 2: Access to SAFE provided

The actor gives correct user name

and password.

Access to SAFE has been provided.

Step 3: Retrieve Standard Records from SAFE

In the file structure the actor locates

the Standard Records necessary for

control and decides to download

them.

SAFE starts download and transmits

the requested data.

Step 4: Repeat step 3

The actor repeats step 3 if neces-

sary.

Step 5: Log out of SAFE

The actor chooses to log off from

the FTPS connection.

The solution logs out the actor and

interrupts the connection.

Concluding conditions The Danish Gambling Authority has access to SAFE, has received the data transferred and logged off after the

ending of the transfer.

Notes

Service description

10

The process to be used by the Danish Gambling Authority when retrieving data from SAFE is illus-

trated and described below.

Gambling Authority

Licence Holder

Flow chart – retrieve Standard Records

Process survey Danish Gambling Authority

Process name: Process owner: Process stakeholders

UC 2.3 Retrieve Standard

Records from SAFE

Danish Gambling Authority Licence Holders and Danish Gambling

Authority

Purpose of the process

The purpose of the process is to ensure that the Danish Gambling Authority can

retrieve data from the Licence Holder’s SAFE.

The process is to be used when the Danish Gambling Authority wants to retrieve

data from SAFE to be used in its control of online gambling.

Process interfaces

FTPS access

Input (start)

The process starts when the Danish Gambling Authority requests access to

SAFE giving its user name and password. SAFE has been set up by the Li-

cence Holder to provide access for the Danish Gambling Authority.

Output (end)

The process ends when the Danish Gambling Authority has obtained the re-

quested data and has logged off SAFE.

Description of process flow (activities)

No. Description

1. The Danish Gambling Authority requests access to SAFE.

11

2. The Danish Gambling Authority ‘fills in’ its user name and password.

3. The system validates user name and password

4. If the user name and password are not valid, access to SAFE is denied

5. If the user name and password are valid, the system grants access to viewing data in SAFE and download

may be commenced.

6. Data are transferred to the Danish Gambling Authority’s database.

7. The Danish Gambling Authority logs off SAFE FTPS

8. SAFE logs off the Danish Gambling Authority.

5.0 Interface to security system – Tamper Token The Danish Gambling Authority implements a security system – Tamper Token. The purpose of the

Tamper Token system is to ensure that data, i.e. Standard Records, will remain unchanged while

they are stored in SAFE at the Licence Holder’s end.

Tamper Token will handle the following functions:

• Creation of keys (tokens) to be used in the calculation of the MAC (Message Authentication

Code)

• Storage of MACs for later control

• Continuous control to check that the period of time for terminating tokens is observed

• Verifying that a retrieved series of Standard Records has not been altered relative to the re-

ceived MAC

The frequency of the issue of the Tamper Token will be agreed in the course of the application pro-

cess. The agreed frequency may be adjusted later based on a specific assessment in relation to the

particular Licence Holders.

5.1 Technical requirements in relation to Tamper Token The License holder must retrieve a token, at the designated frequency (e.g. once every 24 hours).

The token must be used when saving data based on Standard Records in SAFE. For that purpose

The Danish Gambling Authority will develop a service named “TamperTokenAnvend” which has

two operations:

1. TamperTokenHent: The operation must be used when the License Holder has to retrieve a

token.

2. TamperTokenLuk: The operation must be used when the License Holder has to finish a to-

ken.

It is a requirement on the Licence Holder that a token is terminated within the defined period of

time.

The descriptions of the particular services are published on the Danish Gambling Authority’s web-

site very soon (www.spillemyndigheden.dk).

12

6.0 Interface to the Problem Gambling Register (ROFUS) In connection with the introduction of the new Gambling Regulation Act, a legal requirement has

been introduced to ensure that it is possible for a player to opt for exclusion – temporarily or per-

manently – from being able to play online games in Denmark. The Danish Gambling Authority is

the data controller. It must be possible for players to register both via the Danish Gambling Authori-

ty and via the Licence Holder’s website.

The register must include data about all players in Denmark who wish to exclude themselves from

playing online games in Denmark. The information held in the register must include:

a. The Licence Holder’s name (from which a player has chosen exclusion temporarily

or permanently).

b. The player’s civil registration number.

c. The date and hour of exclusion.

d. The date when temporary exclusion ends (only if the exclusion is temporary).

A player who has been entered in the register as permanently excluded may always, but not earlier

than one year from the date of entry on the register, ask a Licence Holder or the Danish Gambling

Authority to be deleted from the Register.

In connection with the Problem Gambling Register, the Licence Holder must meet a number of re-

quirements for functions that must be made available to players. The Licence Holder must ensure to

make the following options possible:

• A player can request exclusion and registration in the Problem Gambling Register via a link

on the Licence Holders website.

• A player’s status is checked against the Problem Gambling Register in connection with ac-

count opening and all account logins

• A player’s civil registration number is checked before he opens an account.

6.1 Technical requirements in connection with the Problem Gambling Register The Danish Gambling Authority will develop the following services to be used for registration on

the Problem Gambling Register.

1. GamblerCheck – a service to be used when a player wants to open an account and for each

login.

2. GamblerCSRPValidation – a service to be used to check a player’s age prior to account

opening. The services also returns an answer whether the player’s civil registration number

exists. This answer is not to be used, as the player’s identity is checked with NemId.

Descriptions of the particular services are published on the Danish Gambling Authority’s website

www.spillemyndigheden.dk.

The processes to be used for opening accounts and for login are illustrated and described below in a

flow chart and a process survey, respectively, to give precise information about the functions to be

developed by the Licence Holder in order to enable the process to be carried through. The Licence

Holder is under an obligation to make this option available.

13

6.2 Inquiry to ROFUS upon account opening and account login To gamble on a Licence Holder’s website players must have an account. New players must open a

new gambling account and existing players must log onto their gambling accounts before being

allowed to play.

6.2.1 Inquiry to ROFUS when accounts are opened

This section describes the process for an inquiry to the Problem Gambling Register when a new

player opens an account. The process is illustrated by a flow chart and subsequently described step

by step in a Process survey. The purpose is to give precise information about the functionalities the

Licence Holder must develop to allow this process to be carried through.

When a new player wants to open an account on the Licence Holder’s website, the Licence Holder

must check, before the account opening has been completed, the player’s identity via NemId, the

player’s age and whether the player is registered on the Problem Gambling Register. If the player

cannot log in via NemId, the player is younger than 18 years old or the player is registered on the

Problem Gambling Register, a player cannot open an account.

The process for inquiries to the Problem Gambling Register when an account is opened is illustrated

and described below.

Inquiry to the Problem Gambling Register

Ga

mb

ling

Auth

ori

ty

Ga

mb

ling

Au

tho

rity

Lic

en

ce H

old

er

Lic

en

ce H

old

er

1. Player opens new

account

2. Checking of player’s age

agains CSRP

3. Is the player older

than 18 years?

4a. Player cannot

open an account

4b. Inquiry sent to

Problem Gambling Register to check if the

player is registered as excluded

5. Checking of

whether the player is registered in the

Problem Gambling Register as excluded

6. Excluded?

7a. Deny opening

of new account

7b. Open new

account

No

Yes

Yes

No

Flow chart – account opening

Process survey Danish Gambling Authority

Process name: Process owner: Process stakeholders

UC 1.3 Query about a

person to the Problem

Gambling Register

Danish Gambling Authority Licence Holders and Danish Gambling

Authority

Purpose of the process

The purpose of the process is to ensure that the Licence Holder can make in-

quiries to the Problem Gambling Register when a player opens a new gambling

account. If the player cannot log in via NemId, or if the player is younger than

14

18 years, or the player is registered on the problem Gambling Register a new

account cannot be opened.

The process must be used each time a player wants to open an account with the

Licence Holder.

Input (start)

The process starts when the player decides to open a new account via a link on

the Licence Holder’s website. Player is logged in via NemId.

Output (end)

If the player could log in via NemId, if the player is not younger than 18 years

old, and the player is not registered on the Problem Gambling Register the pro-

cess ends with the player having opened a (temporary) account and being able

to gamble on the Licence Holder’s website.

If the player cannot log in via NemId, if the player is younger than 18 years old,

or the player is registered on the Problem Gambling Register the process ends

with denial of the opening of an account.

Description of process flow (activities)

No. Description

1. The player keys in the necessary information and chooses ”ok”.

2. It is checked in the CSRP registry if the player is younger than 18 years.

3. The CSRP registry processes the inquiry.

4a. If the player is younger than 18 years, this is reported back to the Licence Holder/player. Account opening

is denied.

4b. If the player is not younger than 18 years, the Licence Holder will make an inquiry to the Problem Gam-

bling Register to check if the player is registered as excluded.

5. The Problem Gambling Register processes the inquiry. If the Problem Gambling Register does not respond

it will not have any suspending effect. The lack of response may therefore be considered to mean that the

player is not excluded and the process continues to step 6b.

6a. If the player is excluded, the opening of an account is denied on the Licence Holder’s website.

6b. If the player is not excluded a temporary account will be opened.

6.2.2 Process description – inquiry to ROFUS upon account login

This section describes the process for an inquiry to the Problem Gambling Register upon a player’s

account login. The process is illustrated by a flow chart and then described step by step in a Process

survey. The purpose is to give precise information about he functions which the Licence Holder

must develop to enable this process to be carried through.

When an existing player wants to log into his/her gambling account on the Licence Holder’s web-

site, the Licence Holder must check, before the login has been carried through, whether the player

has been registered on the Problem Gambling Register since his/her last login. If so, the player can-

not log into his/her account because it has been either deactivated or closed.

15

The process when an inquiry is made to the Problem Gambling Register upon account login is illus-

trated and described below.

Inquiry to the Problem Gambling Register - player login to account

Gambling

Authority

Licence Holder

1. Player logs

in

2. Checking of

whether player

has registered

cooling off period

or exclusion from

Licence Holder

3. Excluded? 4a./5a. Deny login.Yes

4b. Inquiry

transmitted to the

Problem Gambling

Register to check

if player is

registered as

excluded

No

5. Excluded?

Yes

5b. Allow login

No

Flow chart – account login

Process survey The Danish Gambling Authority

Process name: Process owner: Process stakeholders

UC 1.3 Inquiry about a

person to the Problem

Gambling Register

The Danish Gambling Authority Licence Holders and Danish Gambling

Authority

Purpose of the process

The purpose of the process is to ensure that the Licence Holder can make inquir-

ies to the Problem Gambling Register when a player logs into his/her gambling

account. If the player is registered on the Problem Gambling Register, the ac-

count must be deactivated or closed and the player cannot log on.

The process must be used each time a player wants to log into his/her account

with the Licence Holder.

Input (start)

The process starts when the player logs into his/her existing account with the

Licence Holder.

Output (end)

If the player is not registered on the Problem Gambling Register, the process will

end with the player being logged into his/her account and the player can gamble

on the Licence Holder’s website.

If the player is registered, login and gambling on the Licence Holder’s website

will be denied and the account will be deactivated or closed.

Description of process flow (activities)

16

No. Description

1. The player logs on to his/her account with the Licence Holder.

2. A check is made in the Licence Holder’s system to see if the Licence Holder has registered the player with

a cooling-off period or as excluded.

3. The Licence Holder’s system processes the inquiry.

4a. If the player is excluded ‘locally’ in the system of the Licence Holder, login to the account is denied.

4b. If the player is not excluded ‘locally’ in the Licence Holder’s system it is checked against the Problem

Gambling Register whether the player is temporarily or permanently excluded (the civil registration num-

ber is not checked here because this check was carried out when the account was opened).

5. The Problem Gambling Register processes the inquiry. If the Register does not respond it will not have any

suspending effect. The lack of response may therefore be considered to mean that the player is not excluded

and the process continues to step 5b.

5a. If the player is excluded the player is denied logon to his/her account and it will be deactivated or closed.

5b. If the player is not excluded, the player is logged into his/her account.

17

7.0 Technical information to be given in the application form The application for permission will involve a number of requirements for technical information,

including information such as:

1. Domain name

2. IP address

3. Address of the location of the gambling system and SAFE

4. Address of the location of backup systems

5. Technical description of the gambling system with an illustration

6. Information about licences in other countries, if any

- Identification on RNG(s)

- Gambling software

- Information about use of a network provider

- Description of backup systems, including business rules defining how errors etc. will be

handled

7. Possible certifications of hardware, software and security

8. Technical contact person

As stated above, the list should not be considered exhaustive and further requirements to be met by

the Licence Holder may therefore be added.

8.0 Connection process The application phase will include a process around the connection to the Danish Gambling Author-

ity’s systems, including testing, exchange of passwords, etc. Further information about this process

can be found on the Danish Gambling Authority’s website (www.spillemyndigheden.dk).