kansspelautoriteit data model for the remote gambling data ... · technically, any xml node may be...

Kansspelautoriteit

Data model for the remote gambling

data safe (the CDB)

Version 0.90

Date 19 May 2020

Status Draft – EC notification

Kansspelautoriteit | Data model for the remote gambling data safe | 19 May 2020

Draft – EC notification

of 48

Index

PREFACE ........................................................................................................................................................ 3

DISCLAIMER.................................................................................................................................................. 4

FREQUENTLY USED TERMS ........................................................................................................................ 5

GUIDELINES FOR DATA TRANSFERS ......................................................................................................... 6

THE DATA MODEL ....................................................................................................................................... 9

1. ROOT.................................................................................................................................................. 9

2. KEY FIELDS ........................................................................................................................................ 9

3. WOK_OPERATOR...........................................................................................................................10

4. WOK_CORRECTION.......................................................................................................................12

5. WOK_PLAYER_PROFILE ................................................................................................................14

6. WOK_PLAYER_FLAGS....................................................................................................................18

7. WOK_PLAYER_ACCOUNT_TRANSACTION ................................................................................20

8. WWFT_PLAYER_ACCOUNT_TRANSACTION .............................................................................23

9. WOK_PLAYER_LIMITS...................................................................................................................26

10. WOK_INTERVENTION ...................................................................................................................32

11. WOK_GAME ...................................................................................................................................35

12. WOK_GAME_SESSION..................................................................................................................37

13. WOK_BET........................................................................................................................................39

14. WOK_COMPLAINT.........................................................................................................................45

15. CUSTOM DATA TYPES USED IN THE DATA FORMATS .............................................................48



of 48

Preface

The revision of the Dutch Gambling Act, passed by Dutch Senate on February 20,

2019, stipulates the use of a data-based control system (Controle Data Bank, the

CDB). Purpose of this system is a secure exchange of regulatory data between

licensed operators and Dutch regulators.

The Netherlands Gambling Authority (Kansspelautoriteit, Ksa) describes its

requirements regarding the CDB in two documents:

The ‘technical requirements’ document contains requirements of a technical,

organisational and procedural nature

The ‘data model’ details content and processing.

Both must be used by operators when designing, operating or discontinuing the

aforementioned CDB, when they apply for or already obtained a remote gambling

licence under Dutch regulations.

In addition to the documents Ksa may separately provide:

practical information like explanations, updates and schemas

specific technical information that is likely to vary over time (like IP-addresses,

encryption materials)

A review of the two documents is expected after approximately 12-18 months. This

will be done in order to accommodate initial use phase feedback and further

European level harmonisation concerning data reporting for remote gambling.

When review takes place this will be communicated through the Ksa website.

The Dutch Tax Authority has independent access to the CDB. It uses the CDB for

different regulatory purposes and has the right to inspect its own (limited) data set.

The Tax Authority uses its own means to access the CDB and has its own data

model, access frequency and the like.

Tax Authority requirements with regard to the CDB are therefore published in a

separate document. For convenience, publication of the Tax Authority requirements

is done centrally via the Gambling Authority so that all relevant information can be

found in one location.

The licensee has an obligation to implement the CDB in accordance with the

specifications set out below.

https://zoek.officielebekendmakingen.nl/stb-2019-127.html



of 48

Disclaimer

No independent permission can be derived from these requirements -or any

additional information provided by Ksa regarding these requirements- for offering a

particular game of chance or part thereof. Permission to offer a certain game of

chance exists only and to the extent that the operator has been granted a licence

for offering a game of chance as referred to in the Dutch Gambling Act.

Operators must comply with all requirements, including updates and additions.

Noncompliance with these requirements is considered a violation of Dutch regulation

and may lead to corrective measures by Ksa.

Under all circumstances the text of the Dutch Gaming Act -including regulations

based on that Act- prevails. An operator must contact Ksa whenever there is no

clarity or ambiguity about the way a certain requirement can be interpreted.



of 48

Frequently used terms

Data safe or Controle Data Bank (CDB)

The data safe is a secure storage location for data files that is accessible to the

regulator. The data safe is made available and maintained by the operator. A single

operator may have multiple data safes.

Record

Technically, any XML node may be considered a data record. In the context of this

document however, a record is a single XML node, that may have zero or more

subnodes but has no parent nodes other than <root>.

Regulator

The regulator in this document is The Netherlands Gambling Authority.

Currency

In the CDB there is only one type of currency: EURO. The operator must convert all

other currency such as but not limited to Pound Sterling, Dollars, in game Coins,

diamonds or in kind winnings, to the equal value in Euro’s.

Time Zone

All timestamps in the database are always in Coordinated Universal Time (UTC)

Real Time / Near Real Time

The gambling regulation requires that data is transferred into the CDB final data

repository real time or near real time. To assist operators with this transfer, the

frequency of extraction and the trigger for reporting the information is noted in the

description of the record. Unless otherwise specified:

source extraction of the data must take place immediately after the original

registration in that source;

placement of the data into the CDB final data repository must take place

within 30 minutes after the extraction.



of 48

Guidelines for data transfers

This chapter describes the way in which data files must be stored in the data safe.

FILE FORMAT AND SIZE

Data must be stored in XML. XML files must be compliant with the XSD schemas

published on the regulator’s website. An XML file must be in UTF 8 and may contain

multiple records. A record, in the context of this document, is an XML element which

has no parents other than the mandatory <root> element which must be the root

element for each XML file.

Each XML file must be stored batchwise in a batch data file when it reaches a

maximum of 512 records or when the batch data file is closed.

The XML file should be named according to the following format:

[XSD_name]-[N]-[yyyymmddhhmmss_start].xml

in which

XSD_name is the filename of the XSD used to create the xml (WOK_bet_v1.0.xsd => XSD_name is WOK_bet_v1.0;

N is a sequential counter of the safe instance, with leading zeros, 10 digits , to be resetted at the beginning of a new day;

yyyymmddhhmmss_start is the timestamp for the moment the file was created.

Batching The XML’s are stored batchwise in a batch data file

The batch data file should be named according to the following format:

[operator_id]-[datasafe_id]-[N]-[yyyymmddhhmmss_start].gz

in which operator_id is the unique number granted by the regulator;

datasafe_id is the id of the data safe, provided by the operator. If there is only one data safe, the ID is ‘1’.;

N is a sequential counter of the safe instance, with leading zeros, 10 digits ,

to be resetted at the beginning of a new day; yyyymmddhhmmss_start is the timestamp for the moment the file was

created.

A batch data file is closed when one of the following instances occurs: after a maximum interval of 5 minutes;

as soon as the received data volume (in compressed form) has reached 100

MB;

at 00:00 (UTC) every day.

Before a batch data file is added to the final data repository, it must be processed as

described below.



of 48

FILE PROCESSING

Before a batch data file is added to the final data repository, it must be processed.

The following steps must be taken:

Control Manifest XML

The control manifest XML is created. The name of the manifest XML consist of

the name of the batch data file preceded by the name of the control manifest

XSD.

A XSD schema for the control manifest file will be made available by the

regulator (i.e. on it’s website).

Chaining

The batch data file is chained to the immediately preceding batch data file

through the inclusion of a hash (SHA-256) of the ‘Hash_file’ of the latter. The

‘Hash_file’ consists of the hash value of the current batch data file and the

hash value of the preceding Hash_file.

The hash value of the current batch data file and the hash value of the

previous Hash_file are added to the control manifest XML. In this way, by

referencing hashes of previous records, a “chain” of batch data files is created.

In case of the first Hash_file, a hash value of 0 shall be used for the absent

previous Hash_file.

Compression

The batch data file must be compressed to a .gz file using the Deflate algorithm

(RFC1951).

Timestamp

The .gz file must be digitally signed using XAdES-T1. The time for the

timestamp must be delivered by any Timestamp Server compatible with the

European eIDAS timestamps standard ETSI EN 319 422 (RFC 3161). The

signature has to be included in the control manifest XML.

Encryption

The compressed file must be encrypted using the AES-256 algorithm. The

compressed data is encrypted with a symmetric AES-256 session key,

dynamically generated by the operator. This session key is itself encrypted with

RSA-2048, using the regulator’s public key (X.509 certificate). The encrypted

session key is stored in the control manifest XML.

Referencing

References to the locations of files are added to the control manifest XML:

Absolute path in URL syntax (without scheme and host) to the ZIP file. The

path corresponds with the folder structure; Absolute path in URL syntax (without scheme and host) to the previous ZIP

file. The path corresponds with the folder structure;

1 https://www.w3.org/TR/XAdES/



of 48

Archiving

The compressed batch data file and the control manifest xml must be included

in a single .zip file. The .zip file must have the same name as the data file.

Adding separate .zip files to the final data repository should be done

throughout the day.

DIRECTORY STRUCTURE The files in the data safe should be in folders that are named according to the

following structure: [Operator ID]

[Data safe ID]

year month

day

The year, month and day refer to the moment the batch data file is created.



of 48

The data model

1. Root

Field name Minimum Maximum Data type

Root 1 1 n/a

The root element has to be the outermost node of any XML file added to the data

safe.

2. Key fields

The following fields will only be described in this paragraph but they need to be

included in every record.


Record_ID 1 1 UID2

The record ID needs to be unique across the entire data safe. It will be used in case

the operator needs to make a correction.


Extraction_Date 1 1 timestamp3

The extraction date indicates when the data was extracted form the operator’s

systems.


Operator_ID 1 1 stringMedium4

Operator_ID is the unique ID granted by the regulator. A legal entity which exploits

different brands under a single license, needs to use the same ID in all data in its

datasafe(s).

2 See UID 3 See timestamp 4 See stringMedium



of 48

3. WOK_Operator

What? Description

Field name WOK_Operator

Minimum 1

Maximum 1

Data type n/a

Trigger 00:00 UTC time

Frequency Once a day

WOK_Operator represents the party that holds the remote gambling license.

Totals


Totals 1 1 n/a

Totals is a parent element for totals. A legal entity which exploits different brands

under a single license, must add the totals of its different brands together.

Subtotal_Previous_Day


Subtotal_Previous_Day 1 1 Integer

Subtotal_Previous_Day is the revenue of the day that is being reported. Revenue is

the gross result, i.e. all customer stakes minus customer winnings. Taxes and

operational costs must not be taken into consideration.

This information is intended as an extra check on the consistency of the XML file.

The correctness of this amount may also be verified via reports from other sources.



of 48

Subtotal_Previous365Days


Subtotal_Previous365Days 1 1 Integer

Subtotal_Previous365Days is the subtotal of the previous 365 days (or 366 in case

of a leap year) plus the day that is currently being reported. Revenue is the gross

result, i.e. all customer STAKES minus customer WINNINGS. Taxes and operational

costs must not be taken into consideration.

It is intended as an extra check on the consistency of the XML file. The correctness

of this amount may also be verified via reports from other sources.



of 48

4. WOK_Correction


WOK_Correction 1 unbounded n/a

WOK_Correction represents a correction of data that was previously added to the

data safe.



of 48

Original_Record_ID


Original_Record_ID 1 1 UID5

Original_Record_ID is equal to the Record_ID of the record that needs to be

corrected. There are three ways of making a correction.

Correction method 1: Delta


Delta 0 1 monetaryAmount6

This method may be used in case the data that needs to be corrected is an

monetary amount. If this method is chosen, the delta with the previously reported

amount must be reported. The XML node name should be the same as before.

Correction method 2: send the record again

This method may be used for all corrections. If this method is chosen, the entire

record needs to be reported again, with the correct information in it.

Correction method 3: send nothing at all

This method may be used for cancellations. If this method is chosen, a record must

be completely cancelled by reporting only the Original_Record_ID and nothing else.

5 See UID 6 See monetaryAmount



of 48

5. WOK_Player_Profile

What? Description

Field name WOK_Player_Profile

Minimum 1

Maximum No maximum

Data type n/a

Trigger

1. Already present players at the first moment of operation of the data safe

2. New Player at registration

3. Existing player after saved change in profile

Frequency

@1. At 00:01 on the first day of operation

@2. After the player has saved the profile, even if it is not yet completed

@3. After the player has saved the changes in profile

WOK_Player_Profile represents every customer who has ever registered, regardless

of whether he or she has ever partcipated in any games or bets.

It is not necessary to provide all player profiles, all the time. The very first time data

is supplied, all players must be submitted. After that, only new player profiles and

player profiles which have changed (i.e. one of its subnodes has changed) need to

be included. When a player profile is included, the entire profile must be submitted.



of 48

Player_Profile_ID


Player_Profile_ID 1 1 stringMedium7

Player_Profile_ID is the unique identifier of a user with the operator. Any

Player_Profile_ID may only occur once with an operator in all its history.

Player_Profile_ID may not be independently traceable to an (identified) natural

person and also may not be traceable in combination with other data such as those

relating to the interventions that a operator has made. Data is thus made available

to the regulator pseudonymized.

The technical requirements document8 describes pseudonymisation.

Player_Profile_Registration_Datetime


Player_Profile_Registration

_Datetime

1 1 timestamp 9

Player_Profile_Registration_Datetime is the time and date when the

Player_Profile_ID was created by the operator. Generally this is the date when the

player first created an account.

Player_Profile_DOB


Player_Profile_DOB 1 1 date

Player_Profile_DOB is the player’s date of birth.

Player_Profile_Modified


Player_Profile_Modified 1 1 timestamp

Player_Modified is the date when the subelements under Player were last modified.

This means that every modification of a subnode of Player means a modification of

this field. If there have never been changes, Player_Profile_Modified is equal to

Player_Profile_Registration_Datetime. If there are multiple changes in a day, all

records must be submitted.

Player_Profile_Status


Player_Profile_Status 1 1 Enumeration

Player_Profile_Status is the status a player has. For this field, options are:

- ACTIVE: the player’s identity has been verified and his/her status is normal;

- TRIAL: the verification of the player’s identity is still ongoing;

- SUSPENDED: the player has been suspended by the operator due to not

accessing his account for a certain amount of time;

- SUSPENDED_DEATH: the player has been suspended by the operator

because he died;

7 See stringMedium 8 Ksa Requirements for the remote gambling datasafe (the CDB) 9 See timestamp



of 48

- BLOCKED: the player’s account has been blocked because the operator

suspects fraudulent behavior and/or the player does not meet the operator’s

terms and conditions;

- SELF_EXCLUDED_TEMP: the player has requested to be excluded from

playing for a set period;

- SELF_EXCLUDED_INDEF: the player has requested to be excluded from

playing for an indefinite period;

- OTHER: the player has another status not mentioned above.

It is possible that the regulator will add other options in the future.

Player_Profile_EOD_Balance


Player_Account_End_Of_Day 1 1 monetaryAmount10

Player_Account_End_Of_Day is the balance (in Euros) in the player account at the

end of the day (UTC).

Player_Profile_Bank_Account


Player_Profile_Bank_Account 0 No maximum n/a

Player_Profile_Bank_Account represents a player’s bank account. There may be

multiple bank accounts, but only one can be active. If the player’s identity is still

being verified, this field may be empty.

Bank_Account_ID


Bank_Account_ID 1 1 stringMedium11

Bank_Account_ID must be unique within the data of a player. This means that a

single player cannot have two bank accounts with the same ID.

The Bank_Account_ID may not be independently traceable to an (identified) natural

person and also may not be traceable in combination with other data such as those

relating to the interventions that a operator has made. This data field is thus made

available to the regulator pseudonymized.

The technical requirements document12 describes pseudonymisation.

Bank_Account_Datetime


Bank_Account_Datetime 1 1 timestamp13

Bank_Account_Datetime is the combination of date and time when the

Bank_Account_ID was created.

10 See monetaryAmount 11 See stringMedium 12 Ksa Requirements for the remote gambling datasafe (the CDB) 13 See timestamp



of 48

Bank_Account_Active


Bank_Account_Active 1 1 boolean

Bank_Account_Active indicates whether this is the current bank account for the

player account. There can only ever be one active bank account. When the player

modifies his or her bank account, the previous bank account gets a

Bank_Account_Active value of 0.



of 48

6. WOK_Player_Flags

What? Description

Field name WOK_Player_Flags

Minimum 1

Maximum no maximum

Data type n/a

Trigger The classification that indicates the risk of gambling addiction of a player is changed.

Frequency Immediately after the change is made.

WOK_Player_Flags is the mandatory parent element for separate Flag elements. A

flag represents a classification assigned to a Player by the operator.

Player_Profile_ID

See Player_Profile_ID

Flag_RG_Class


Flag_RG_Class 1 1 n/a

Flag_RG_Class represents the classification that indicates the risk of gambling

addiction. The regulator does not make a limitative list, but there should be at least

be one class for young adults (18-24 years old). If no risk classification has been

assigned, the value “NO_RISK_ASSIGNED” must be used.

RG_Class_Value


RG_Class_Value 1 1 stringShort14

RG_Class_Value is the value of Flag_RG_Class.

14 See stringShort



of 48

RG_Class_Datetime


RG_Class_Datetime 1 1 timestamp15

RG_Class_Datetime is the combination of the date and time when the Flag_Value of

the Flag_RG_Class was last changed.

15 See timestamp



of 48

7. WOK_Player_Account_Transaction

What? Description

Field name WOK_Player_Account_Transaction

Minimum 1

Maximum No maximum

Data type n/a

Trigger

A WOK_Player_Account_Transaction is created whenever a transaction

is attempted, even if it is unsuccesful. This includes the setting aside or earmarking funds in the player account (sometimes known as

‘exposure’) for bets which have not been settled yet.

Frequency Immediately after a transaction is attempted

WOK_Player_Account_Transaction represents a single transaction to or from the

player account. A WOK_Player_Account_Transaction is created whenever a

transaction is attempted, even if it is unsuccesful. This includes the setting aside or

earmarking funds in the player account (sometimes known as ‘exposure’) for bets

which have not been settled yet.



of 48

Player_Profile_ID


Transaction_ID


Transaction_ID 1 1 UID16

Transaction_ID is the unique identifier of any Player_Account_Transaction.

Transaction_ID may occur only once in combination with a player account. This

means that a single operator cannot have multiple transactions with the same ID

and the same Player_Profile_ID.

Transaction_Datetime


Transaction_Datetime 1 1 timestamp17

Transaction_Datetime is the combination of date and time when the transaction was

finished.

Transaction_Amount


Transaction_Amount 1 1 monetaryAmount18

Transaction_Amount is the transaction’s amount in EURO. This may be a positive or

a negative number. If funds have been deducted from the player account, the

amount must be preceded by a minus sign. If the funds have been added to the

player account, the amount has no sign.

Transaction_Deposit_Instrument


Transaction_Deposit_Instrument 0 1 Enumeration

Transaction_Deposit_Instrument is an indication of the payment method of the

transaction. For this field, the options are:

- CREDIT_CARD;

- ELECTRONIC_MONEY;

- BANK_TRANSFER;

- OTHER.

It is possible that the regulator will add other options in the future. This field is

optional, it only needs to be added if the transaction does entail a deposit by the

player.

16 See UID 17 See timestamp 18 See monetaryAmount



of 48

Transaction_Type


Transaction_Type 1 1 Enumeration

Transaction_Type indicates for which reason the transaction took place. For this

field, the options are: - DEPOSIT: the player transferred money with his deposit instrument of

choice to his player account;

- WITHDRAWAL: the player transferred money from his player account to his

bank account;

- WINNING: the player won money in a game or a bet;

- BONUS: the player earned a bonus;

- STAKE: the player lays money on a betting event;

- CASH_OUT: a partial cash out was made while the sports event to which a

bet pertained was still ongoing;

- VOID_BET: the stake is returned, that is the player has not won any money

but did not lose it either;

- BONUS_CANCELLED: The bonus is cancelled by the customer or by the

operator;

- BONUS_EXPIRED:the bonus has expired;

- RESETTLEMENT: From time to time obvious errors are made, either through

human or system error, and bets are accepted at a price that is materially

different from those available in the general market or clearly incorrect

given the chance of the event happening at the time the bet was struck;

- OTHER.




of 48

8. WWFT_Player_Account_Transaction

What? Description

Field name WWFT_Player_Account_Transaction

Minimum 0

Maximum No maximum

Data type n/a

Trigger

A WWFT_Player_Account_Transaction is created whenever a transaction

is attempted, even if it is unsuccesful. This includes the setting aside or earmarking funds in the player account (sometimes known as

‘exposure’) for bets which have not been settled yet.

Frequency Immediately after a transaction is attempted

WWFT_Player_Account_Transaction represents a single transaction to or from the

player account. A WWFT_Player_Account_Transaction is created whenever a

transaction is attempted, even if it is unsuccesful. This includes the setting aside or

earmarking funds in the player account (sometimes known as ‘exposure’) for bets

which have not been settled yet.

Player_Profile_ID




of 48

Transaction_ID


Transaction_ID 1 1 UID19

Transaction_ID is the unique identifier of any Player_Account_Transaction.

Transaction_ID may occur only once in combination with a player account. This

means that a single operator cannot have multiple transactions with the same ID

and the same Player_Profile_ID.

Transaction_Datetime


Transaction_Datetime 1 1 timestamp20

Transaction_Datetime is the combination of date and time when the transaction was

finished.

Transaction_Amount


Transaction_Amount 1 1 monetaryAmount21

Transaction_Amount is the transaction’s amount. This may be a positive or a

negative number. If funds have been deducted from the player account, the amount

must be preceded by a minus sign. If the funds have been added to the player

account, the amount has no sign.

Brand_Name_Deposit_Instrument


Brand_Name_Deposit_Instrumen

t

0 1 stringShort

Brand_Name_Deposit_Instrument is the brand name of the deposit intrument used,

such as the name of the bank in case of electronic bank tranfser, the name of the

electronic wallet, the name of the credit card. It is not the name of the Payment

Service Provider (PSP). In case a PSP is used, the name of the ‘source of the money

should be used, such as the name of the bank.

19 See UID 20 See timestamp 21 See monetaryAmount



of 48

Transaction_Type


Transaction_Type 1 1 Enumeration

Transaction_Type indicates for which reason the transaction took place. For this

field, the options are: - DEPOSIT: the player transferred money from his bank account to his player

account;

- WITHDRAWAL: the player transferred money from his player account to his

bank account;

- WINNING: the player won money in a game or a bet;

- BONUS: the player earned a bonus;

- BET: the player put money on a sports bet;

- CASH_OUT: a partial cash out was made while the sports event to which a

bet pertained was still ongoing;

- VOID_BET: the stake is returned, that is the player has not won any money

but did not lose it either;

- BONUS_CANCELLED: The bonus is cancelled by the customer or by the

operator;

- BONUS_EXPIRED:the bonus has expired;

- RESETTLEMENT: From time to time obvious errors are made, either through

human or system error, and bets are accepted at a price that is materially

different from those available in the general market or clearly incorrect

given the chance of the event happening at the time the bet was struck;

- OTHER.




of 48

9. WOK_Player_Limits

What? Description

Field name WOK_Player_Limits

Minimum 1

Maximum No maximum

Data type n/a

Trigger

When the limit comes into effect: For example:

- Creation of new player account; - If a limit is changed and comes into effect immediately: the change of

the limit; - If a limit is changed, and the limit comes on a later day into effect:

the day when the limit comes into effect.

Frequency

Immediately after the limit comes into effect immediately;

Or At the start of 'into effect day'



of 48



of 48

WOK_Player_Limits is a parent element for player limits. Player limits can be set by

the player or the operator. The limits listed below must always be present from the

moment the player registers.

If a limit is changed, a new record is created. Old limits are therefore not changed,

removed, or cancelled. If there are more limits of one type for one player, the

date/time shows which limit is active. The only exception is Limit_Game_Type. Of

this limit, more can be active at the same time. That is the reason that this limit

also has an end date.

Player_Profile_ID


Limit_Deposit


Limit_Deposit 1 No maximum n/a

Limit_Deposit represents the limitation of the amount of money that a player may

deposit into his player account.

Deposit_Request_Datetime


Deposit_Request_Datetime 1 1 timestamp22

Deposit_Request_Datetime is the combination of the date and time when the

Limit_Deposit was created.

Deposit_Start_Datetime


Deposit_Start_Datetime 1 1 timestamp23

Deposit_Start_Datetime is the combination of the date and time when the

Limit_Deposit comes into effect.

Deposit_Amount


Deposit_Amount 1 1 Integer

Deposit_Amount is the maximum amount (rounded to whole euros) that can be

deposited into the player account per period specified in Deposit_Time_Window.

This can only happen through a request by the player himself, i.e. a transaction with

Transaction_Type DEPOSIT.

Deposit_Time_Window


Deposit_Time_Window 1 1 timeWindow24

Deposit_Time_Window is the time interval within which the limit applies.

22 See timestamp 23 See timestamp 24 See timeWindow



of 48

Limit_Participation


Limit_Participation 0 No maximum n/a

Limit_Participation represents the limitation of the player’s stake.

Participation_Request_Datetime


Participation_Request_Datetime 1 1 timestamp25

Participation_Request_Datetime is the combination of date and time when the limit

was created.

Participation_Start_Datetime


Participation_start_Datetime 1 1 timestamp26

Participation_Start_Datetime is the combination of date and time when the limit

comes into effect.

Participation_Amount


Participation_Amount 1 1 Integer

Participation_Amount is the maximum stake (rounded in euros) that the player may

bet per period specified in Participation_Time_Window.

Participation_Time_Window


Participation_Time_Window 1 1 timeWindow27

Participation_Time_Window is the time interval within which the limit applies.

Limit_Login

Field name Minimum Maximum Data ype

Limit_Login 1 No maximum n/a

Limit_Login represents the limitation on the number of times a player can log onto

the player account. Having such a limitation will be mandatory based on the remote

gambling decree (Besluit kansspelen op afstand28).

Login_Request_Datetime


Login_Request_Datetime 1 1 timestamp29

Login_Datetime is the combination of date and time when the limit is created.

25 See timestamp 26 See timestamp 27 See timeWindow 28 https://www.internetconsultatie.nl/besluitkansspelenopafstand/document/3918 (PDF) 29 See timestamp

https://www.internetconsultatie.nl/besluitkansspelenopafstand/document/3918



of 48

Login_Start_Datetime


Login_Start_Datetime 1 1 timestamp30

Login_Start_Datetime is the combination of date and time when the limit comes into

effect.

Login_Times


Login_Times 1 1 Integer

Login_Times is the maximum number of times a player can log in, per period

specified in Login_Time_Window.

Login_Time_Window

Field name Minimum Maximum Date type

Login_Time_Window 1 1 timeWindow31

Login_Time_Window is the time interval within which the limit applies. For this field,

there is a choice of: "Hour", "Day", "Week", "Month", "Quarter", "Year", “Other”. It

is possible that the regulator will add other options in the future.

Limit_Game_Type


Limit_Game_Type 0 No maximum n/a

Limit_Game_Type represents an exclusion of a certain game type. It is possible that

a player has multiple active limits of this type, in case a player is excluded for more

than one game type.

Game_Type_Request_Datetime


Game_Type_Request_Datetime 1 1 timestamp32

Game_Date_Type_Request_Datetime is the combination of date and time when the

limit was created.

Game_Type_Start_Datetime


Game_Type_Start_Datetime 0 1 timestamp

Game_Type_Start_Datetime shows the combination of date and time when the limit

comes into effect.

Game_Type_End_Datetime


Game_Type_End_Datetime 0 1 timestamp

Game_Type_End_Datetime shows the combination of date and time when the limit

ended. This field is optional, if a limit is still active, this field can be omitted.

30 See timestamp 31 See timeWindow 32 See timestamp



of 48

Game_Type_Type


Game_Type_Type 1 1 stringMedium33

Game_Type_Type shows which game type the player is excluded from.

This field may contain game types for which there is currently no legal basis but

which are set up for future developments and for supervisory purposes.

Game_Type_Time_Window


Game_Type_Time_Window 1 1 timeWindow34

Game_Type_Time_Window is the time interval within which the limit applies.

Limit_Balance


Limit_Balance 1 No maximum n/a

Limit_Balance represents the limitation of the amount of money that a player may

have in his player account.

Balance_Request_Datetime


Balance_Request_Datetime 1 1 Timestamp

Balance_Request_Datetime is the combination of the date and time when the

Limit_Balance was created.

Balance_Start_Datetime


Balance_Start_Datetime 1 1 Timestamp

Balance_Start_Datetime is the combination of the date and time when the

Limit_Balance comes into effect.

Balance_Amount


Balance_Amount 1 1 Integer

Balance_Amount is the maximum amount (rounded to whole euros) that can be in

the player’s account at any given moment.

Balance_Time_Window


Balance_Time_Window 1 1 timeWindow

Balance_Time_Window is the time interval within which the limit applies.

33 See stringMedium 34 See timeWindow



of 48

10. WOK_Intervention

What? Description

Field name WOK_Intervention

Minimum 1

Maximum No maximum

Data type n/a

Trigger An intervention is performed by the operator.

Frequency Immediately after the start of the intervention

WOK_Intervention represents an intervention by the operator in connection with

addiction prevention or (a suspicion of) fraud by a player.

Player_Profile_ID




of 48

Intervention_ID


Intervention_ID 1 1 UID35

Intervention_ID must be unique within the data of a player. I.e. one player may not

have two interventions with the same ID.

Intervention_Begin_Datetime


Intervention_Begin_Datetime 1 1 timestamp36

Intervention_Begin_Datetime is the combination of the date and time when the

intervention started.

Intervention_End_Datetime


Intervention_End_Datetime 0 1 timestamp

Intervention_End_Datetime is the combination of date and time when the

intervention ended

This field is optional and does not have to be included in interventions that consist of

a short-term action such as setting a limit.

Intervention_Type


Intervention_Type 1 1 Enumeration

Intervention_Type is the type of the intervention activity. Intervention is a response

to an action or set of actions by a player. Interventions are often linked to a flag

related to problem gambling or (suspicion of) fraud, but there may also be other

reasons, e.g. misbehavior towards customer service.

Accepted values are: - CONVERSATION_V_INFORM: a voice conversation (phone call) with the

purpose of warning the player about the risk of problematic gambling and/or

informing the player about means by which he or she can gain insight into

his own gambling habits;

- CONVERSATION_V_ANNOUNCE: a voice conversation (phone call) with the

purpose of announcing that the operator intends to take some action, like

blocking the player’s access or setting a limit;

- CONVERSATION_T_INFORM: a message via e-mail, a popup or some other

means of written communication with the purpose of warning the player

about the risk of problematic gambling and/or informing the player about

means by which he or she can gain insight into his own gambling habits;

- CONVERSATION_T_ANNOUNCE: a message via e-mail or some other means

of written communication with the purpose of announcing that the operator

intends to take some action, like blocking the player’s access or setting a

limit;

- SET_FLAG: a flag has been set for this player;

- SET_LIMIT: a limit has been set for this player by the operator;

- EXCLUDE: a player has been excluded (permanently or temporarily) from

the gambling platform by the operator;

35 See UID 36 See timestamp



of 48

- OTHER.


Intervention_Cause


Intervention_Cause 1 1 Enumeration

Intervention_Cause is the reason for carrying out the intervention, for example in

case of exceeding limits. Accepted values are: - FRAUD: the player has been involved in (suspected) fraudulent behavior;

- SOCIAL: the player has misbehaved, for example by using abusive language

towards staff or other players;

- PROBLEM_GAMBLING: the player has shown behavior which indicates there

is a risk of gambling addiction;

- OTHER.


Intervention_Owner


Intervention_Owner 1 1 stringMedium37

Intervention_Owner is the name of the business unit or person who carried out the

intervention.

37 See stringMedium



of 48

11. WOK_Game

What? Description

Field name WOK_Game

Minimum 0

Maximum No Maximum

Data type n/a

Trigger

1. At the start of the first day of operation of the CDB;

2. When a game becomes available to the players; 3. When a game is retracted

Frequency

@1: At the start of the first day of operation of the CDB

@2: at the beginning of the day the game becomes available @3: at the beginning of the day the game is retracted

WOK_Game represents a game of chance offered by the operator. This does not

include bets. This information is optional, if only bets are offered, it does not have to

be included.

Games only need to be included if something changes, i.e. a game becomes

available or unavailable to players.



of 48

Game_ID


Game_ID 1 1 UID38

Game_ID must be unique within the data of an operator. I.e. one operator may not

have two games with the same ID.

Game_Type


Game_Type 1 1 Enumeration

Game_Type is the type of the game. Accepted values are;

- SLOTS;

- CASINO;

- BINGO;

- OTHER.


Game_Commercial_Name

Veldnaam Minimaal Maximaal Gegevenstype

Game_Commercial_Name 1 1 stringMedium39

Game_Commercial_Name is the name of the game as it is shown to the player.

Game_Datetime_Introduction


Game_Datetime_Introduction 1 1 timestamp40

Game_Datetime_Introduction is the combination of the date and time when a game

became available to players for the very first time.

Game_Datetime_Active


Game_Datetime_Active 1 1 Timestamp

Game_Datetime_Active is the combination of the date and time when a game

became available to players. If the game has always been available since it was first

intoduced, this field is equal to Game_Datetime_Introduction. If a game was

temporarily withdrawn and then becomes available again, Game_Datetime_Active is

updated. Game_ID must not change in such a case.

Game_Datetime_Inactive


Game_Datetime_Inactive 0 1 Timestamp

Game_Datetime_Inactive is the combination of the date and time when a game

stops being available to players.

38 See UID 39 See stringMedium 40 See timestamp



of 48

12. WOK_Game_Session

What? Description

Field name WOK_Game_Session

Minimum 1

Maximum No maximum

Data type n/a

Trigger When a Game_Session is ended

Frequency Immediately after a Game_session is ended

WOK_Game_Session represents a play session. This information is optional, if a

game is not played within the reporting period, this field does not need to be added.

Game_ID

See Game_ID

Game_Session_ID


Game_Session_ID 1 1 UID41

Game_Session_ID must be unique within the data of a game. I.e. one game may

not have two sessions with the same ID.

41 See UID



of 48

Game_Session_Start_Datetime


Game_Session_Start_Datetime 1 1 timestamp42

Game_Session_Start_Datetime is the combination of the date and time when the

game session was started.

Game_Session_End_Datetime


Game_Session_End_Datetime 1 1 timestamp

Game_Session_End_Datetime is the combination of the date and time when the

game session ended.

Game_Session_Commission


Game_Session_Commission 0 1 monetaryAmount

Game_Session_Commission is the total amount of commission that has been

withheld from this game session by the operator, for example an entry fee or the

rake at poker. This field is optional, for game types where no commission is

withheld, it does not have to be included

Game_Transaction


Game_Transaction 1 unbounded n/a

Game_Transactions is a reference to a transaction to or from a player account that

is related to this game session.

Player_Profile_ID


Transaction_ID

See Transaction_ID

42 See timestamp



of 48

13. WOK_Bet

What? Description

Field name WOK_Bet

Minimum 1

Maximum No maximum

Data type n/a

Trigger 1. A Bet is placed and accepted 2. A Bet is setteled or cancelled

Frequency 1. Immediately after the bet has been accepted 2. Immediately after when a bet is completed or cancelled



of 48

WOK_Bet represents a placed and accepted bet or a setteled or canceled bet.If no

bets have been completed or canceled within the reporting period, no data of

already accepted bets will be submitted.. This data follows when the bets have been

setteled or cancelled.



of 48

Bet_ID


Bet_ID 1 1 UID43

Bet_ID must be unique within the data of an operator. I.e. one operator may not

ever have two bets with the same ID.

Bet_Start_Datetime


Bet_Start_Datetime 1 1 timestamp44

Bet_Start_Datetime is the combination of date and time when the player has placed

the bet.

Bet_Cancellation_Reason


Bet_Cancellation_Reason 0 1 stringLong45

Bet_Cancellation_Reason is a description of the reason why a bet, for which the

player already paid the stake, has been canceled.

Bet_Type


Bet_Type 1 1 Enumeration

Bet_Type is an indication of the bet type. For this field, options are:

- SINGLE: a bet is placed on one single sports event;

- COMBINED: a bet is placed on a combination of sports events, for every

match one or more predictions are made and a player only wins if all

predictions are correct;

- XY: a bet is placed on a combination of Y sports events and a player wins if

X out of Y predictions are correct;OTHER.


Bet_XY


Bet_XY 0 1 Integer

Bet_XY indicates how many results should be correctly predicted in the case of an

X/Y bet (see Bet_Type). This field is optional, it only needs to be included if the

Bet_Type is "XY".

43 See UID 44 See timestamp 45 See stringLong



of 48

Bet_Commission


Bet_Commission 0 1 monetaryAmount

Bet_Commission is the total amount of commission that has been withheld from this

bet by the operator. This field is optional, for bets where no commission is withheld,

it does not have to be included.

Bet_Parts


Bet_Parts 1 1 n/a

Bet_Parts is a required root element.

Part


Part 1 64 n/a

Part represents a part of a bet. There must be a Part for every prediction that is

made within one bet.

Part_ID


Part_ID 1 1 UID46

Part_ID must be unique within the data of a bet. I.e. one bet may not have two

parts with the same ID.

Part_Event


Part_Event 1 1 stringMedium47

Part_Event is the description of the sports event that is being bet on.

Part_Odds


Part_Odds 0 1 Decimal number

Part_Odds shows the odds/quotation of the bet. This field is optional. In cases

where there are no odds (e.g. pool betting), it does not need to be included.

Part_Sport


Part_Sport 1 1 stringShort48

Part_Sport is an indication of the sport that is being practiced during the betting

match. A limitative list of sports will be provided.

Part_Live


Part_Live 1 1 Boolean

Part_Live indicates whether the bet has been placed before or during the sports

match.

46 See UID 47 See stringMedium 48 See stringShort



of 48

Part_Bank


Part_Bank 0 1 Boolean

Part_Bank indicates whether this bet is a "bank tip" or not.

If a player is strongly convinced of the correctness of a prediction, some operators

provide the possibility to mark the prediction as a bank tip/banker. This field is

optional, as the banker option is generally only available for system bets.

Part_Match_Datetime


Part_Match_Datetime 1 1 timestamp49

Part_Match_Datetime is the combination of the date and time when the sports

match related to the bet started. If the sports match has been rescheduled, the

actual date and time that the event took place need to be listed here.

Part_Prognosis_Result_Type


Part_Prognosis_Result_Type 1 1 Enumeration

Part_Prognosis_Result_Type is the type of uncertainty that was bet upon. Examples

are the final outcome of the match or the score at halftime. A limitative list will be

provided.

Part_Prognosis_Value


Part_Prognosis_Value 1 1 stringMedium50

Part_Prognosis_Value is the predicted result value.

Part_Stake


Part_Stake 1 1 monetaryAmount51

Part_Stake is the amount in euros that the player has set on this prediction.

Part_Cancellation_Reason


Part_Cancellation_Reason 0 1 stringLong52

Part_Cancellation_Reason is a description of the reason why this part of the bet has

been canceled. If the bet was cancelled in its entirety, the reason why should be

specified at Bet_Cancellation_Reason and this field does not need to be included

Bet_Total_Stake


Bet_Total_Stake 1 1 monetaryAmount

Bet_Total_Stake is the total amount in euros that the player has set on this bet.

49 See timestamp 50 See stringMedium 51 See monetaryAmount 52 See stringLong



of 48

Bet_Transaction


Bet_Transaction 1 unbounded n/a

Bet_Transaction is a reference to a transaction to or from a player account that is

related to this bet.

Player_Profile_ID


Transaction_ID

See Transaction_ID



of 48

14. WOK_Complaint

What? Description

Field name WOK_Complaint

Minimum 1

Maximum No maximum

Data type n/a

Trigger 1. The complaint is submitted 2. The complaint is closed

Frequency 1. Immediately after the complaint is submitted

2. Immediately after the complaint is closed

WOK_Complaint represents an incident (for example a complaint to the operator

about an advertising campaign, a complaint to the Advertizing Standards

Association about a campaign, a complaint to the authorities about an advertising

form or complaints about unfair game play).

Complaint_ID


Complaint_ID 1 1 UID53

Complaint_ID must be unique within the data of an operator. I.e. one operator may

not have two complaints with the same ID.

53 See UID



of 48

Complaint_Type


Complaint_Type 1 1 stringMedium54

Complaint_Type indicates what type of incident has occurred.

Complaint_Datetime


Complaint_Datetime 1 1 timestamp55

Complaint_Datetime is the combination of the date and time when the incident

occurred.

Complaint_Player_ID


Complaint_Player_ID 0 1 UID

Complaint_Player_ID is a reference to the player who was involved in the incident.

This field is optional, if no people with a player account were involved, it does not

have to be included.

Responses


Responses 1 1 n/a

Responses is a parent element for the operator’s responses to complaints.

Response


Response 0 No maximum n/a

Response is a response from the operator to an incident. This concerns the control

of one part of the internal business processes: customer service (article 31h, first

paragraph, gambling law).

Response_ID


Response_ID 1 1 UID56

Response_ID must be unique within the data of an incident. I.e. one incident may

not have two responses with the same ID.

Response_Type


Response_Type 1 1 stringMedium57

Response_Type is the type of response that the incident was followed up with (for

example, intervention, follow-up, investigation).

54 See stringMedium 55 See timestamp 56 See UID 57 See stringMedium



of 48

Response_Description


Response_Description 1 1 stringLong58

Response_Description is the description of the final result of the incident follow -up.

Response_Datetime


Response_Datetime 1 1 timestamp59

Response_Datetime is the combination of the date and time when the response to

the incident occurred.

58 See stringLong 59 See timestamp



of 48

15. Custom data types used in the data formats

timestamp

This data type indicates a date and time in the format yyyy-mm-ddThh: mm: ssZ,

for example: 2016-02-27T10:24:15Z

All timestamps in the database are always in Coordinated Universal Time (UTC).

timeWindow

This data type is an enumeration to indicate how long a time interval lasts. For the

time being the permitted values are:

- HOUR;

- DAY;

- WEEK;

- MONTH;

- QUARTER;

- YEAR;

- OTHER.

Other values may be added in the future.

monetaryAmount

This data type serves to record a sum of money and may be preceded by a ‘-‘sign to

indicate a negative amount. Two decimal places are required.

UID

This data type serves to record a unique ID of an entity. This is a series of

characters built according to the pattern [8 characters] - [4 characters] - [4

characters] - [4 characters] - [12 characters], the permitted characters are

lowercase a-z and number 0-9. The UID can not be a consecutive number.

stringShort

This data type is a series of characters of up to 32 characters.

stringMedium

This data type is a series of characters of up to 256 characters.

stringLong

This data type is a series of characters of a maximum of 1024 characters.

*** End of document ***

Kansspelautoriteit Specifications for the remote gambling data safe (the CDB)

Version 0.90

Date 19 May 2020 Status Draft – EC notification

Kansspelautoriteit | Specifications for the remote gambling data safe | 19 May 2020 Draft – EC notification

Page 2 of 26

Index

Preface .................................................................................................................................................... 3

Disclaimer................................................................................................................................................ 4

1 Introduction .................................................................................................................................... 5

2 The infrastructure and security of the CDB .................................................................................... 8

3 Data storage in the CDB ................................................................................................................ 14

4 Access to the CDB ......................................................................................................................... 18

5 Procedures in case of maintenance or malfunctioning of the CDB .............................................. 20

6 Procedures regarding backup, mirrors and retention .................................................................. 21

7 Location of the CDB and the separation of digital means regarding the gambling system ......... 22

8 Testing ........................................................................................................................................... 23

9 Changes ......................................................................................................................................... 25

10 Communication ......................................................................................................................... 26


Page 3 of 26

Preface The revision of the Dutch Gambling Act, passed by Dutch Senate on February 20, 2019, stipulates the use of a data-based control system (Controle Data Bank, the CDB). Purpose of this system is a secure exchange of regulatory data between licensed operators and Dutch regulators. The Netherlands Gambling Authority (Kansspelautoriteit, Ksa) describes its requirements regarding the CDB in two documents:

• The ‘technical requirements’ document contains requirements of a technical, organisational and procedural nature

• The ‘data model’ details content and processing. Both must be used by operators when designing, operating or discontinuing the aforementioned CDB, when they apply for or already obtained a remote gambling licence under Dutch regulations. In addition to the documents Ksa may separately provide:

• practical information like explanations, updates and schemas • specific technical information that is likely to vary over time (like IP-addresses, encryption

materials) A review of the two documents is expected after approximately 12-18 months. This will be done in order to accommodate initial use phase feedback and further European level harmonisation concerning data reporting for remote gambling. When review takes place this will be communicated through the Ksa website. The Dutch Tax Authority has independent access to the CDB. It uses the CDB for different regulatory purposes and has the right to inspect its own (limited) data set. The Tax Authority uses its own means to access the CDB and has its own data model, access frequency and the like. Tax Authority requirements with regard to the CDB are therefore published in a separate document. For convenience, publication of the Tax Authority requirements is done centrally via the Gambling Authority so that all relevant information can be found in one location.

The licensee has an obligation to implement the CDB in accordance with the specifications set out below.

https://zoek.officielebekendmakingen.nl/stb-2019-127.html


Page 4 of 26

Disclaimer No independent permission can be derived from these requirements -or any additional information provided by Ksa regarding these requirements- for offering a particular game of chance or part thereof. Permission to offer a certain game of chance exists only and to the extent that the operator has been granted a licence for offering a game of chance as referred to in the Dutch Gambling Act. Operators must comply with all requirements, including updates and additions. Noncompliance with these requirements is considered a violation of Dutch regulation and may lead to corrective measures by Ksa. Under all circumstances the text of the Dutch Gaming Act -including regulations based on that Act- prevails. An operator must contact Ksa whenever there is no clarity or ambiguity about the way a certain requirement can be interpreted.


Page 5 of 26

1 Introduction

1.1 About this document The revision of the Dutch Gambling Act was passed by Dutch Senate on February 19, 2019. It establishes the national and legislative framework for gambling activities in its different forms for the purposes of ensuring the protection of public order, combating fraud, preventing addictive behaviour, protecting the rights of minors and safeguarding the rights of gambling participants. The Dutch Gambling Act stipulates that all parties holding a remote gambling licence are obliged to implement a data-based control system for monitoring and supervising of their gambling activities by Dutch regulators: ControleDataBank (the CDB). A total of three regulators have been entitled to use this datasafe or the CDB:

1. Regulator for the Gambling Act (Kanspelautoriteit, Ksa), 2. The regulator for Anti-Money Laundring regulation (Ksa) 3. The regulator for Gambling Taxes (Tax Office).

This document outlines the specific requirements regarding this datasafe in the context of its use by Ksa (for both regulatory tasks). The requirements apply to licenced operators, and licence applicants. The requirements have been attuned as much as possible with requirements that are common in other areas, for example:

• European gambling jurisdictions requiring a similar datasafe system. • audit best practises from IT or finance • open standards set by the Dutch government • international harmonised standards, such as ISO27001

Legal reference Lower legislation

1.2 Legal basis The most important legislation around the CDB can be found in:

• articles 31h (sub 1 and 2) and 34l of the Dutch Gambling Act (WoK), • article 5.3 of the Governmental Decree remote gambling (AmvB), • and article 4.22 of the Ministerial Regulation remote gambling (MR)

The Ministry of Justice and Security is the legislating body and has expressed their intentions around the CDB in various other locations in the decree and regulation (‘lower legislation’). See for example:

• article 4.42 section 2 AmvB (location of the CDB in The Netherlands) • article 5.2 section 1 AmvB (access to operator equipment, including the CDB). • article 4.12, section 2 MR (particular player balance data that should be in the CDB)

All these stipulations and details concerning the CDB are not explicitly repeated or summarised in this technical requirements document, although in some cases a reference may be made.


Page 6 of 26

Article 4.22 MR Additional requirements

The legal reference for these Ksa requirements, Ksa data model and similar requirements from other regulators is article 4.22 MR. According to this article these requirements must describe at least:

a. The infrastructure and security of the CDB b. Data storage in the CDB (see also the separate document for the data model) c. Electronic access to the CDB d. Procedures in case of malfunctioning of the CDB e. Procedures regarding backup and mirrors f. Location of the CDB and the separation of digital means regarding the gambling system

Article 4.22 MR also provides Ksa with a legal base to further extend these requirements. Ksa has identified such requirements on several other topics, like pseudonimisation or communication and included them in this document.

Licence application, changes

The operator must provide Ksa with (full) documentation about its CDB implementation at the moment of licence application, in the case of changes and upon request from Ksa. The operator must also participate in testing and perform assessments during these occasions.

Reading guide Definitions

1.3 Reading guide Requirements are placed under the relevant header as much as possible, with reference to the topics listed in article 4.22 MR. Requirements regarding pseudonimisation are placed under Data storage in the CDB for example. Specific data-related requirements to correctly populate the CDB can be found in a separate document describing the data model1. For easy navigation keywords are placed on the left throughout the document.

The use of definitions and abbreviations is kept minimal, and described at first time use. Further information around the CDB, such as detailed explanations or illustrative technical schemas may be published by Ksa from time to time, primarily on its website: www.kansspelautoriteit.nl

Versioning

Ksa may issue a new version of these requirements and the data model. Operators are obliged to use the new version when it is effectuated.

1 Kansspelautoriteit data model for the remote gambling datasafe (the CDB)


Page 7 of 26


Page 8 of 26

2 The infrastructure and security of the CDB

As stated in legislation, the CDB is considered a data provisioning infrastructure owned and operated by a gambling operator. This means that individual operators have a certain degree of freedom to setup their CDB infrastructure. However, specific requirements around infrastructure and security are needed to support a safe, harmonized use of the CDB environment. Also, on the regulators end, not every single technique can be supported. For reasons such as cost-efficiency as well as that an operator’s CDB environment can be used by multiple Dutch regulators. Operators and Ksa should follow international harmonized open standards and best practises when implementing or using the CDB environment. For example these Dutch government guidelines on security that can be found here: www.informatiebeveiligingsdienst.nl (BIO version 1.0.4, guidelines in Dutch, closely related to or derived from ISO27001)

the CDB environment

The following schema illustrates the main functions of the CDB environment. The functions are derived from descriptions in legislation. For convenience an indication of expected conformity assessment scopes is included in this schema.

Data Sources CDB Final Data Repository (located in NL)

Retrieval & Validation Platform Storage & Analysis

Operator Assessment Scope

OperatorData extraction & provisioning

KSA Data retrieval & analysis

KSA Assessment Scope

Segregation of data

Because of the segregation in roles and tasks of the different Dutch regulators entitled to access the CDB environment, operators must separately store the necessary data for each regulator in the CDB final data repository and provide separate access accordingly. This is regardless of:

• the role(s) and data retrieval frequency of regulatory bodies; • the infrastructure used by the operator; • the required file content (segregated files could contain similar records but have a

different destination). Additionally, when an operator uses several unique customer administrations, this operator should segregate the CDB final data repository according to the number of unique client administrations. A customer file is considered to be the complete set of customers of an operator. This customer file may comprise multiple unique customer administrations, for example for a


Page 9 of 26

specific game or brand. An operator needs to build a CDB for each unique client administration. Some examples:

• a single customer administration with a single CDB environment is likely to be used by most operators. Segregation in this situation can be achieved for instance by use of different file folders or domains;

• some operators may choose to market their offering via strictly segregated brands. This could lead to the existence of multiple unique customer administrations with a single the CDB environment. In such situations the operator should apply separation of access and file location per unique customer administration;

• specific situations may even lead to the existence of multiple unique customer administrations with multiple CDB environments. For example as a result of a takeover situation, or by design (i.e. because of company security policies). Separation of access and file location per unique customer administration must also be applied, although this might be already achieved because of the use of multiple CDB environments.

Data content and format (XSD, XML). Data model.

Data intended for Ksa must be stored in the CDB final data repository according to the data model and XSD (XML Schema Definition) file structure as provided by Ksa. Prior to the start of data storage and retrieval a data mapping procedure against Ksa data model must take place (see chapter 3). Ksa will make its data model document and XSD files available separately (see Ksa website). The operator must ensure that the correct items (such as data, files) shall be extracted from the appropriate source(s). For example by use of procedures, secure connections and documenting (i.e. the data mapping outcome).

Regular data retrieval Ad hoc data retrieval

For regular data retrieval the CDB environment must support machine-based access, with automated data retrieval (i.e. by use of scripts). And it must support human-based access with manual data retrieval. The CDB final data repository must contain a separate location for ad-hoc data exchange between Ksa and an operator (i.e. a file folder named ‘ad hoc’). This can only be used in specific cases, for instance in an emergency recovery situation, and needs prior approval of Ksa.


Page 10 of 26

Additional data (non-data model)

Additional data delivery (non-data model related) may be requested by Ksa. This could be temporary or permanent (in which case a data model change is likely to occur). This could for instance be a tailored data exchange during fraud investigation, when a request is made for exchange of personally identifiable information. Ksa and operator must agree upon the distribution method (the CDB or a different channel) and release policies prior to release of this additional data.

Additional data request

Any request for additional (non-data model related) data must contain at least: • collected characteristics of the requested items, such as required data fields and their

respective extraction frequencies; • the reason of the request; • exact date/time of the occasion(s) of sharing; • data retention periods.

Normally these requests will be made in writing through the central contact of an operator, unless otherwise specified or agreed upon. The operator should respond to the request for additional (non-data model related) data as follows:

• operators need to send a confirmation of receipt within 72 hours after the request was made;

• the operator must provide the requested information as soon as possible within a maximum window of 4 weeks.

Additional data response

Prior to placing the additional data or reports in the CDB, or any alternative channel, the operator should verify (in line with best practices for handling any data) that this data is cleared to be received by Ksa and can be stored or transferred securely.

User provisioning

To make it possible for Ksa to access the CDB using SFTP, the operator and Ksa must exchange the required connectivity information, such as device fingerprints, IP addresses, FQDN, encryption keys through a secure communication channel. Sharing this information might be required during licence application for example.


Page 11 of 26

Security Key management Algorithm selection Certificate usage

Operators must notify Ksa immediately when breaches, errors or violations occur that (may) effect the security of CDB, or when suspicion of errors or violations occur. Operators and Ksa shall follow international best practises and their respective organisation guidelines for managing digital keys and other cryptographic means or procedures. The algorithm selection as elaborated in the data model document must be used. This selection was made by Ksa based on current international standards and best practices, and public advice from Dutch government institutions for standardization and cyber security. Based on, among other things, the development of technology and computing power, advice and standards may change and as a result, the current algorithm selection may prove insufficient. In that case, Ksa will publish an amended selection on its website. X.509 certificates - insofar as used in the interaction between operator and Ksa - must meet the requirements of PKIOverheid (PKI for the government). The requirements for PKIOverheid are based on European standards and Dutch legislation. This allows users to trust that they are using a high-quality and reliable PKI infrastructure, which also complies with internationally accepted guidelines. Please note that an operator is free to use other (including self-generated) X.509 certificates in company internal systems and procedures. However, this must be sufficiently reliable if used in relation to the CDB environment and during internal or third party conformity assessments.


Page 12 of 26

Control plan The operator must write and manage a control plan. This plan must be formally approved, following company approval policies. The control plan – or parts thereof - must be shared with Ksa during licence application and –depending on the assessment scope- anyone performing a conformity assessment. On a periodical basis, operators must review their control plan and adjust if necessary.

Control plan content

The control plan must contain functional specifications on (IT) systems in relation to the CDB, including:

a. access rules to determine the access that a human user or system may have to the CDB systems and/ or data (with a particular label);

b. security rules for determining from the content the protection level(s) that should be applied to a particular the CDB item (like a data field or a system);

c. categorization and/or labelling rules: rules determining the categorization and the content of category markings and/or label(s) to ensure consistent interpretation by human users and by systems.

Control plan content examples

Examples of items that should be in such a control plan: • licence reference and validity period; • the CDB implementation design and test methods; • allowable data fields and formats; • exclusions; • recordkeeping requirements (incl. retention); • roles and responsibilities; • training requirements and other support requirements (Manuals, Reference like

intranet pages, helpdesk, etc.); • which individuals/organizations may have access to the CDB; • categorization rules, labelling rules and access rules; • location of the back-up system; • predescibed events that trigger data extraction; • auditing requirements, including a compliance check/reporting guidelines for the

electronic systems housing the CDB data.

Controlled release

Operator must ensure a controlled release of data files to Ksa which should include mechanisms for:

• proper access control (besides user access controls, data labelling is a sound method to ensure this);

• the release. Depending on the release method desired by the operator, a submission response mechanism could be a method of choice;

• verification continuous data release. A dedicated service (e.g. a staging server) could be used to allow for a controlled release;

• secure extraction and packaging of data an automated XML generation & publication service could be used for example.

Internal control The operation of the CDB described by the design, control plan or test plan should be regularly

checked by an internal control official.


Page 13 of 26

(third party) Conformity assessment

The operator needs to periodically perform a conformity assessment on the CDB. The initial assessment (required for licence application) will be extensive. It is expected that following assessments will consist of continuous validation. In case of a conformity assessment:

• procedural controls must have been correctly implemented and show effective data protection;

• technical controls implemented must successfully demonstrate the ability to protect information according to the requirements;

• implemented guidelines and rules (like stated in the control plan) are verified and used in accordance with requirements, such as security guidelines and audit trail methods.

This information must be made available to any party performing assessments (this could also be Ksa when performing site visits for example).


Page 14 of 26

3 Data storage in the CDB

Data mapping The operator must map its source data and CDB output format in accordance with the appropriate reference format(s) (i.e. ‘Ksa data model’) to see if all output is delivered according to expectations. The mapping outcome or mapping result must be shared with and approved by the corresponding authority (Ksa for the Ksa data model). For example the mapping of the CDB output data for Ksa format must be applied in accordance with the most recent version of the Ksa data model. The mapping result (i.e. a matrix) must make clear what CDB output Ksa will receive from that individual operator / client administration. Ksa must approve this mapping result.

The reference data model consists of a number of record descriptions. All descriptions must be

mapped. All applicable source data - and this may include process, control or test data - must be mapped to the reference material provided. This process should include particular details such as mapping operator internal player statuses or bet types to the Ksa data model enumeration options. Please note that deviations or impossibilities should be reported in the mapping result. For example, transaction records are expected to apply to all operators. However the records around sports betting are not applicable for an operator offering casino games only. In this case a particular record is not applicable, however this may not be left out of the mapping process and the mapping result must contain a (brief) explanation allowing Ksa to understand this deviation from the model.

Future developments

Future standardisation or best practise collection may result updated or additional reference material from Ksa. In this case Ksa shall provide the necessary input and verify the updated mapping result accordingly.

Additional data fields

An operator may be required – on demand - to apply specific data fields or reporting elements, in addition to Ksa reference format. This may require an additional mapping and the results of this mapping must also be shared with and approved by Ksa.

Integrity of data

Ksa and/or an auditor should be able to verify the CDB output on integrity and be able to detect anomalies or (un)intended modification to the mapped data format.

No absent fields

In case of a mapping result against Ksa reference format (data model) where fields do not apply to a particular operator, the actual CDB output for that field must be 'null' (no empty fields, no absent fields).

Individual tailoring

It is prohibited to tailor the reference format and the mapped output to individual needs. In other words: DO NOT DEVIATE FROM THE XSDs PROVIDED BY Ksa!

Extraction

The operator extracts items (such as data, files and event logs) from the appropriate source(s) in batch, on-demand or continuous mode as defined in the mapping outcome.


Page 15 of 26

Control plan Extraction follows a controlled predefined process (e.g. with scripts) and triggered by

predefined events. These processes and events must be described in the control plan.

Qualified personnel

Operator personnel are trained/qualified to make the determination whether data can be extracted and placed in the CDB. Regardless of this being done in relation to the data model or to an ad hoc on demand data request.

Logging data requests

The identity and qualifications of all operator representatives who associate a request with a piece of data will be captured and recorded for audit purposes. This record will be maintained by the operator, and will not be visible to external recipients.

Determination process

This request and data determination process is followed according to written policies and procedures (e.g. scripts), and controlled (e.g. through self-assessment or audit). A system may be available to support these procedures or scripts. If so, that system should be able to:

• present all available regulations that apply to the CDB (e.g. company policies); • assist the user in determining applicable regulations, for example though a guided

decision tree; • prompt the user to consider all restrictions that may apply to an information object,

including proprietary information restrictions, personally identifiable information restrictions, etc.

Validation Prior to loading items into the CDB the operator must validate the extracted items (data, files,

event logs,…) and perform improvements (if required) -> this is a balancing act: From perspective of authority there is a need to have certainties on the quality, origin and trustworthiness of data. From a practical point there can always be a technical error possible that needs to be corrected. Validation should include data integrity, eligibility and data persistence checks. The validation methods should be listed in the Control Plan (and should also have been tested). This process must be described in detail, monitored (with logging) 24x7 where applicable and frequently audited (at least half yearly). Validation could include data eligibility and data persistence checks. It must include integrity checks.

Documentation Sources

The operator ensures a complete description of the sources that are used. The source description must correlate to the data or report. This must be included in the operator’s mapping output.

Audit Mapping

The source description must be stored and made available for licence application, testing and upon request by Ksa. An (internal/external) auditor or any other supervising entity, for example company officials like the compliance officer, a security officer, a technical lead may have access to this information. This must be included in the operator’s mapping output.


Page 16 of 26

Outsourcing Subcontractor

The source description may contain sources not owned and/or operated by the operator (outsourced services). In such cases the source description should contain (a reference to) an agreement between operator and the subcontractor on the purpose, availability and extraction of that source by the operator. This must be included in the operator’s mapping output.

Audit / conformity assessment

In case of an audit of the sources: An identified agenda / scope (of testing, audit, etc.) must be present and correlate to the purpose of using a data source for the CDB.

Audit guidelines

Audit reports, either written manually or generated by a system that are delivered to operator and/or Ksa should be formatted according to internationally harmonized audit guidelines and should permit auditors to verify the compliance of the operator with requirements.

Audit report guidelines differ by company and are usually not shared externally. Therefore a list of expectations on audit reports is placed on the Ksa website.

Release Notification

The operator will release the production level CDB and notify Ksa (and if desired other stakeholders that the operators wishes to inform). The notification to Ksa must be done in writing, must be dated, and be formally signed off by the official, responsible for the CDB.

Notification must take place via email with an attachment to the email in the form of a memo/pdf including the above mentioned signature. Ksa will add these documents to the operators file. Contact details will be made available on the Ksa website.

Notification to Ksa of production level release must be done, and Ksa shall acknowledge the receipt and return confirmation in writing. Notification and acknowledgement should take place prior to release of any product offering under the Dutch licence.


Page 17 of 26

3.1 Pseudonimisation of data Some data that needs to be placed in the CDB is considered Personal Identifiable Information and pseudonyms should be used instead. The appropriate data elements can be found in Ksa data model. Please note that under specific supervision circumstances (i.e. fraud investigation) Ksa may require the operator to reveal (a limited number of) customer identities (see Chapter 2, additional data). Operators are free to choose a pseudonym as long as:

• the pseudonym does not exceed the data field specifications (i.e. maximum characters) as required in Ksa data model;

• GDPR requirements around pseudonymisation are met (including EDPA opinions); • the chosen prerequisites for a legally secure pseudonymisation as well as the process

steps for carrying out a pseudonymisation must be documented (i.e. in the control plan) and belong to the scope of the (periodical) independent audit. Please note that a pseudonymisation may take place in several stages, for example, with the participation of one or more trust bodies;

• the pseudonymisation procedure should ensure the linkability of pseudonyms: identical pseudonyms can only be used to identify identical persons. However, the linking of pseudonymised data with identified persons without knowledge of the pseudonymisation must be avoided. Only the operator should be able to pseudonymise its customer records accordingly. Ksa should not be able to link pseudonyms (or reverse pseudonymisation);

• the operator is able to fulfil a request from Ksa to reveal (a limited number of) identities;

• the operator limits pseudonymisation problems as much as possible (i.e. limit synonym errors by use of procedures);

• appropriate security and quality measures are in place, such as: • good application semantics; • cross domain functions; • controlled changes; • anti-collusion measures; • security controls on the ‘data trust zone’; • protection against statistical analysis.


Page 18 of 26

4 Access to the CDB

In the following chapter, access requirements are described from the perspective of the overall CDB infrastructure that an operator must build. As explained in chapter 2 the CDB is considered to be a data-exchange infrastructure that can be composed of different machines, software, processes, connections, interfaces etc. Please note that lower legislation specifies under Article 5.3 AmvB that – for the particular function of inspection or retrieval of data from the CDB- access needs to be separate for each regulator. And that both regulator and operator should not be able to modify when it resides on the final data repository.

Regulators Operators (independent) third parties

4.1 Entities The following parties may have access to the CDB environment via their respective interfaces.

a. Entitled regulators that wish to inspect or retrieve data from the CDB. Each must have independent access from the other (i.e. different credentials, separate file folders). This will only be via a digital interface.

b. Ksa, as Gambling Act regulator in general, should have remote and physical access to (elements of) the CDB environment to verify the correct implementation and performance of the CDB environment. In case of investigation, licence application or change requests for example.

c. Operators should have access to the CDB environment since they are responsible for the correct implementation and should control the quality of data reporting service. It is expected that operators have both automated access (i.e. source extraction) and manual access (i.e. service management).

d. Third parties may need access in some situations. Their access is considered to always fall under the responsibility of either a regulator or an operator. For example: • operators may need to contract an independent auditor to perform periodical

conformity assessments. This might also be imposed by Ksa as a corrective measure;

• operators may outsource elements of the CDB infrastructure (such as maintenance or platform hosting services), and allow a service provider access to (parts of) the CDB;

• operators may have an internal auditor / compliance officer that needs access to verify proper operation of the CDB;

• Ksa may also outsource its work, for example Ksa can contract an independent auditor to perform work on behalf of Ksa as mentioned under b.

Automated or manual access

Access control can be implemented according to company policies of the operator, as long as access by the regulators will follow specifications (i.e. SFTP for Ksa). All forms of access should be accommodated for as needed. Some examples:

• automated access (script on machine) and manual access (human on local computer) access by should both be accommodated;

• physically entering the machine room for maintenance or inspection;


Page 19 of 26

Identity management Separation of duties Logging & monitoring Documentation

• access to support conformity assessments (i.e. using a gateway proxy system). Access controls must be implemented in such a way that access can be granted in a uniform, stable manner so tasks like data transfers can be performed smoothly and without interruptions. Any form of access to the CDB must be restricted to authorized individuals, men or machines from both the operator and the regulators. With proper identity and access management (i.e. credentialing, privilege management) to service all entities that require access. If particular credentials are required (by anyone entitled for access) those credentials should meet the operator’s company security standards. The operator should also:

• put access management in place according to open standards where possible; • enforce separation of duties for all Operator employees and employees of

subcontractors involved in the CDB, both in technical management or procedural management;

• include control measures on services and not just on humans or machines. In particular services around handling data, ensuring that data files are only transferred if fit for purpose (i.e. validated against the XSD, correctly stored according to filing requirements, properly marked if that is required by operators security requirements).

All access to the CDB and actions that were taken must be logged in the appropriate (audit) log. Access logging, data submission response, or data download should be part of the logging and monitoring services. Logging and monitoring should take place in such way that it can support a sound governance and any conformity assessment of the CDB. The procedures for access should be documented (i.e. in the control plan) and shared with Ksa when applying for a licence and upon request.


Page 20 of 26

5 Procedures in case of maintenance or malfunctioning of the CDB

Scheduled maintenance

An operator may, with at least five days prior notice, decommission its CDB environment or parts thereof for scheduled maintenance purposes. An operator must perform scheduled maintenance outside of the peak hours of its company, whilst ensuring that:

• all required data is still extracted from source systems according to the data model and stored securely. For example by temporary storage on a secure intermediate server;

• maintenance outcome is formally approved following company policies before the CDB is turned back on;

• the data must be included in the CDB storage platform for retrieval by regulators immediately after.

Please note that temporary storage solutions are considered to be part of the overall the CDB infrastructure and therefore all requirements from regulations and Ksa specifications are applicable.

Emergencies In case of emergencies, the operator may decommission the CDB or parts thereof for repairing purposes without prior notice. In these cases the operator must inform Ksa as soon as possible, no longer than 72 hours after decommissioning the system. Accountability must be given afterwards in writing within a tome window of 4 weeks. Data that was generated in the gaming system during the period in which the CDB environment was unavailable must be filed (i.e. using a backup system) and restored in the main the CDB repository as soon as possible after recovery. This must be logged and logs must be made available for assessment purposes. The operator must provide information in its control plan how this is achieved securely to prevent breaches like data loss or manipulation of data.

Communication around problems

Maintenance announcements or emergency notifications may be done by the regular communication channels unless otherwise specified (i.e. Ksa may open a specific channel for emergency notifications in case regular channels seem inconvenient). Ksa may experience technical or functional problems. Or issues with content in the CDB repository. In this case Ksa will contact the operator concerned through the regular channels to find a solution. In some cases multiple operators or multiple regulators may experience similar technical problems. In such case Ksa will coordinate this, ensuring a central point of contact.


Page 21 of 26

6 Procedures regarding backup, mirrors and retention

The operator is responsible for the correct implementation of the CDB environment, including its availability and data loss prevention. See also Chapter 2 of this document or legislation around the CDB. Different solutions are available and operators may choose solutions that fit its business operations best.

Backup Mirror

All operators are obliged to keep a backup system that will ensure availability of the data while allowing recovery in case of file/folder deletion or corruption. Ksa needs to be informed about the location, specifications and operation of the backup system and changes thereof. The operator must specify this in its control plan. If a mirror repository or similar solution must be available, preferably on a secondary location (physically separated from the original the CDB final data repository and separated from the gaming systems). This mirror will allow the CDB to keep working in the event of hardware failure, reducing lost availability. Such a mirror may not also serve as the back-up solution.

Retention Minimum retention period of the data in the CDB final data repository is 12 months counting from the moment of the compulsory registration. Operators must guarantee this retention in their control plan and also in their exit plan.


Page 22 of 26

7 Location of the CDB and the separation of digital means regarding the gambling system

The complete CDB environment may be composed of several systems, services etc. according to the operators choice of implementation. Besides any requirements from legislation or Ksa specification, these different components:

• may be dispersed over different virtual and physical locations, within the EER; • should be easily accessible for Ksa (e.g. trough one uniform interface portal); • must meet the operator's company security standards.

The operator must describe its complete CDB environment in a written statement in either Dutch or English, including a schema of the configuration at the moment of licence application and/or upon request by Ksa. This written statement shows that all requirements have been met and that the design matches with all that the operator (intends to) offer under the Dutch gambling licence. The operator is free to send any additional information, such as for example a video, explaining how the CDB environment is designed and operated.

Separated server Location

The CDB final data repository must be located in the Netherlands physically separated from the operators gambling system. Both may be located in the same data centre if an operator chooses to do so, however data stored in this main the CDB final data repository must be logistically and safely separated from any other data.

Intermediate or staging server

If an intermediate or staging server is used by an operator in its the CDB-environment than this component should be secured (i.e. limited access) and physically separated from the operators gambling system. Data source extraction (‘data capture’) may be run on such a staging server, for instance. Similary an intermediate server might be used in case of emergencies.


Page 23 of 26

8 Testing

This chapter is about test procedures between operator and Ksa, for example during licence application or when changes to the CDB environment are made. This testing deals primarily with the technical interface and (automated) data exchange between Ksa and operator (‘the CDB front-end’). On a case by case basis such testing could also have other objects in scope, i.e. new communication techniques. Please note that this testing differentiates from the conformity assessment by an independent third party, as mandated by the legislator. That assessment deals with the correct implementation of the CDB environment by the operator (‘the CDB back-end’).

Production test Test plan

Prior to any production level use of the CDB environment testing with Ksa must be done. Testing will take place based on a test plan that has been approved by Ksa. Once the testing has been completed and Ksa has approved the subsequent test results further use of the CDB is allowed. For each case a specific test plan should be agreed upon between each operator and Ksa. This is because the CDB environments are likely to vary among operators. And availability of testing personnel and equipment needs to be organized. Test participants should perform tests and capture results as stated in this test plan. Ksa cannot approve further use of the CDB environment if a test plan cannot be agreed upon, individual tests are not executed or fail and when testing is not possible. More information about the completion or discontinuation of the test program is included in the Ksa Policy Rules for Licence Applications.

Test requirements for licence application

For licence application Ksa shall provide minimum, appropriate test requirements (i.e. on its website). Ksa shall also provide appropriate test environment(s). Among others, the following examples could be part of a test programme during application:

• connection tests (volume, bandwidth, latency, availability, protocol, etc.); • encryption tests (key exchange, decryption, decompression, etc.); • data transport tests; • data quality tests.

In other cases, like change or decommissioning of the CDB environment, test requirements, personnel and equipment needs to be tailored to the situation. Operators must take into account the time that is necessary for performing data mapping and testing procedures. They should therefore notify Ksa in advance in order to agree upon a test plan in time (see also chapter 9). The change can only be effectuated after testing has been completed and approved.


Page 24 of 26

Other test occasions

Besides the formally required pre-production tests, Ksa and operators may enter into other testing. For example:

• Ksa is legally entitled to perform site visits. Depending on the occasion this may also include testing. Operators should grant access and assist with testing accordingly;

• on a voluntary basis Ksa and an operators may decide to perform tests for other reasons. Like preliminary testing in preparation for licence application. Or development-level testing. Please note that voluntary also means that participation is on a request-basis and requests may not be granted. No rights can be derived from the results of these types of testing.

Test Outcome Ksa informs the operators about the outcome of tests, as agreed upon in the approved test plan.


Page 25 of 26

9 Changes

Ksa must be informed in advance by an operator when its CDB operations change, including circumstances regarding the operator’s business. A detailed explanation (including examples of the alterations) to must be submitted along with the notification. For some specific types of changes a submission window is stated. Incorrect application may result in corrective measures from Ksa. On the other hand such a timeframe cannot always be provided by Ksa as this depends on the nature of the change:

• some changes may require full investigation and may even impact licence conditions. This can be the case when for example a casino game operator decides to add betting to its product range;

• other changes may be handled within 5 working days. An example of this type of change is maintenance (see chapter 5);

• some changes have a recurring character (weekly operating system updates) and can be handled via a single notification in advance (instead of a weekly change notification, 72 hours afterwards).

Over time, Ksa will make an overview of best practises available for reference (i.e. on Ksa website).

General changes

Changes that do not affect the way in which the CDB environment is used can commence without prior notification to Ksa. In these cases Ksa must be informed within 72 hours after commencement. Some possible changes in this category are:

• Regular software updates • Change in processes • Revision of documentation • Some types of security updates and emergency fixes (i.e. workarounds or patches)

Specific changes

Other changes are likely to have high impact on the CDB environment and may require additional preparation by the operator or even approval by Ksa. In case of a substantial change, which would affect operations to an extent where the CDB can possibly not be used, this must be notified to Ksa at least 3 months in advance and the change is not allowed to commence without prior approval from Ksa.


Page 26 of 26

10 Communication

Contact between operator and Ksa

Ksa provides a central point of contact for operators to send questions, change notifications, requests etc. Requests intended for the tax authorities will be forwarded by Ksa. The tax authorities will handle these requests. The operator should also provide a central point of contact for Ksa.

Communication with third parties

Communications around the CDB should take place between Ksa and an operator representative, not between Ksa and any third party acting on behalf of this operator. In some cases a meeting with both Ksa, the operator and a representative of a third party may be possible. This could for example be necessary during the test phase when technical aspects that have been outsourced need to be discussed.

XSD / XML File structure Update

The Ksa internet website is the central information platform regarding requirements, specifications, procedures and other information regarding the CDB (like changes). Operators should regularly check this website.

*** End of document ***

kansspelautoriteit data model for the remote gambling data ... · technically, any xml node may be...

Documents