technical directive for online gaming in schleswig holstein v2.0_2013_english version

*This translation of 'Technical Directive for Online Gaming in Schleswig-Holstein' is based on the document released on the 14th of August, 2013 by the German Ministry of the Interior.

Th is trans lation is provi ded to you as a courtesy by Dictao and G LI.

Technical Directive for Online Gaming in Schleswig-Holstein

Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0

Version 2.0 of 14/08/2013

This translation is provided to you as a courtesy by


Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 2/74

Communication, reproduction and use forbidden without prior written permission from Dictao

Reference : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0

Version : 2.0

Date of latest update : 08/14/2013

Confidentiality : RESTRICTED DISTRIBUTION

Revision history

Revision Description of modification Author

Date Version checked

21.06.2013 2.0 Beta Complete revision Project group

09.08 2013 2.0 Incorporation of feedback Project group

12.08.2013 2.0 Final editorial work Project group

Approval history

The following table provides a summary of all approvals which have resulted in the present document being given the “completed“ status.

Date Version

checked Comments Controller

21.06.2013 2.0 Beta QA, final Project group

14.08.2013 2.0 QA, final Project group




Note:

If certain manufacturer’s products are mentioned in this document, they are only named as an example without there being any recommendation of the product in question.

References to male persons are used solely for the purpose of making the document easier to read.




CONTENTS

CONTENTS ..................................................................................................................................................... 4

1. INTRODUCTION .................................................................................................................................... 6

2. ARCHITECTURAL OVERVIEW OF THE CONTROL SYSTEM ......................................................................... 7

2.1 Data protection with distributed operation of the control system ........................................................ 7

2.2 Data encryption and signature ........................................................................................................... 7

2.3 IT security .......................................................................................................................................... 8

3. DATA CAPTURING ................................................................................................................................ 9

3.1 Storage .............................................................................................................................................. 9

3.2 Data retention period.......................................................................................................................... 9

3.3 Up-to-dateness .................................................................................................................................. 9

3.4 Availability ........................................................................................................................................ 10

3.5 Backup requirements ....................................................................................................................... 10

3.6 Confidentiality, integrity and authenticity .......................................................................................... 10

3.6.1 Authentication and encryption ..................................................................................................... 10

3.6.2 Signature and time stamp ............................................................................................................ 10

4. DATA FORMATS ................................................................................................................................. 12

4.1 Data log model ................................................................................................................................. 12

4.1.1 Root element “data logs” ............................................................................................................. 13

4.1.2 Basic types of data log information .............................................................................................. 14

4.1.3 Main element “player” .................................................................................................................. 16

4.1.4 Main element “single player game” .............................................................................................. 23

4.1.5 Main element “community game” ................................................................................................ 26

4.1.6 Main element “betting completion” ............................................................................................... 28

4.1.7 Main element “betting result” ....................................................................................................... 34

4.1.8 Main element “betting result correction” ...................................................................................... 37

4.1.9 Main element “game-independent transaction” ........................................................................... 40

4.2 Manifest model ................................................................................................................................. 42

4.2.1 Ensuring integrity and authenticity ............................................................................................... 42

4.2.2 Compression and encryption ....................................................................................................... 43

4.2.3 Packing of log data and control structure .................................................................................... 44

4.2.4 Schema of control manifest ......................................................................................................... 45

4.3 Processing instructions .................................................................................................................... 49

4.4 Validity, updating and adjustment of the data provided .................................................................... 50

5. DATA FORMATS ................................................................................................................................. 52




5.1 Access technology ........................................................................................................................... 52

5.2 Logical data organisation ................................................................................................................. 52

5.3 Example ........................................................................................................................................... 53

6. CONTACT OPTIONS ............................................................................................................................ 56




1. INTRODUCTION

Under § 4 clause 8, item 1 in association with § 46, clause 3 of the new Gaming Regulatory Act (Gambling Act) of 20 October 2011, the Ministry of the Interior is authorised by decree to publish regulations on technical requirements for gaming operators.

The present document defines the technical requirements for an IT system to monitor online gaming in Schleswig-Holstein.

Operators of online gaming services must set up and operate a technical control system which records and digitally stores the data relevant to implementing online gaming monitoring after a period of time (see chapter 3.3) or a trigger event and enables electronic control by the regulatory authority and the respective tax authorities.

The terms described in the document must be fulfilled and recorded for the licensing authority before gaming operations can be commenced.




2. ARCHITECTURAL OVERVIEW OF THE CONTROL SYSTEM

The control system combines the gaming operator’s applications with those of the regulatory authority and respective tax authorities via the analysis systems.

Figure 1 Overview of the architecture

The data capturing component within the control system is responsible for the construction of technical XML log data with information on gaming and betting procedures, payment, account statuses and gamblers. The data capturing is triggered by events which are activated by the gaming operations of the gaming operator.

The downstream component carries out a digital sealing of data logs combined into data records for the purpose of verifying confidentiality, integrity, undeniability and the option of authentication. The sealing comprises the sub-steps compression, encryption and signing. (see Chapter 4.3). The sealed data records are made directly available to the regulatory authority and respective tax authorities online for control purposes, by the safe system (storing).The XML data records of an individual gaming operator described in this Technical Directive must be stored on a SAFE system and separated from any other data

A safe system may only be assigned to one gaming operator. It may also be a virtual server.

2.1 Data protection with distributed operation of the control system

It is permissible to deliver the operation of the safe system (storing) for one service operator. In this case, the access to unencrypted customer data of the gaming operator during the sealing of the data by the operator of the safe systems represents a data protection risks. It is therefore necessary to seal data outside the safe system, i.e. wherever data capturing occurs, see figure 1.

The sealed data is made available on the safe system for the regulatory authority and the respective tax authority and must be accessed via HTTPS (see Chapter 5.1).

2.2 Data encryption and signature

The data in the safe system, which is to be made available to the regulatory authorities and respective tax authority, must be given an advanced signature of the gaming operator. The data




must be encrypted with the regulatory authority’s public certificate. More details are contained in Chapter 4.2.

2.3 IT security

The safe system and all other necessary components must

fulfil at least the requirements of ISO/IEC 27001:2005 with ISO/IEC 27033 and

prove this by means of certification from an accredited body, ideally by means of an “ISO 27001 certificate based on IT baseline protection1”

Certification must be implemented within 12 months of the commissioning of the safe system, with the exception of certification based on IT baseline protection. In this case, proof of certification must be presented in compliance with the following framework conditions only after 24 months:

6 months after the commissioning of the safe system, the gaming operator must submit to the regulatory authority a self-declaration of baseline protection2 for the safe system. Together with the self-declaration, the security concept for the safe system based on BSI standard 100-2 and the result of the basic security check must be provided.

An auditor certificate3 can be provided within 12 months of the commissioning of the safe system. A full test report and the auditor's certificate must be submitted to the regulatory authority without being asked to do so, if necessary with a list of the measures still to be carried out.

An ISO 27001 certificate based on IT baseline protection must be submitted for the safe system's IT network with in 24 months.

When selecting the IT baseline protection procedure and the implementation of the current baseline protection catalogues of the BSI, the certification of the “safe system” IT network is to be undertaken by a licensed ISO 27001 auditor4, otherwise the certification must be implemented by an accredited body5.

In general, recertification is required after the expiry of the validity of a certificate issued. The certificates issued must be submitted in full to the regulatory authority without being asked to do so, together with audit reports, if necessary with a list of the measures still to be carried out based on these reports.

1https://bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/itgrundschutzzertifikat_node.html 2A self-declaration of IT baseline security is a statement by the institution that it has implemented all the required measures for entry level and upgrade level. 3https://bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/AuditoenTestate/veroeffentlichteTestateundSelbsterklaerung/testate.html 4https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/Veroeffentlichungen/ISO27001Auditoren/auditoren27001.html 5http://www.iaf.nu//articles/IAF_MEMBERS_SIGNATORIES/4




3. DATA CAPTURING

Gaming operators are responsible for setting up and operating the entire control system,

Data logs must be stored in a digital safe system. The safe system must be physically separate from the operator’s gaming system and must be installed on a separate server within the Federal State of Schleswig-Holstein. Only the regulatory authority and respective tax authorities are authorised to access the data in the safe system on a read-only basis.

Data must be stored in the safe system in accordance with chapter 3.3 after the completion of individual transactions (games, payments).

The regulatory authority stipulates which information must be recorded for control purposes as well as its data format in the current valid version of this document. The detailed data model (XSD/XML) for data logs is defined in chapter 4.1.

Data logs comprise the following information:

Financial transactions

Personal data of the gaming participants

Gaming and betting procedures

Player protection

Details are contained in chapter 4.

3.1 Storage

In the event of a control system failure, it must be possible to automatically transfer control data not yet copied into the safe system after operations recommence, so that the data remains chronological and complete.

The operator must ensure that only the regulatory authority and the relevant tax authorities may access the data in the safe system via the internet. The operator must enable access to the safe system via the HTPPS protocol for control purposes (see chapter 5) and must provide the aforementioned authorities with the corresponding access information without being requested to do so.

3.2 Data retention period

The operator must store the data for 8 consecutive months. The data must be available in the safe system for the fist 36 months. The data can then be archived on externally stored digital media (offline data) for a further 60 months. After 5 calendar days at the latest, it must be possible for the offline data to be made available again for direct access via the internet. After 8 years the data must be irrevocably deleted.

3.3 Up-to-dateness

Data logs are combined into a data record and digitally sealed (see chapter 4.2):

after a max. interval of thirty minutes, unless data has accrued

or as soon as the received data volume to be compressed (raw data) has reached 10,000 data records,




or when it is 23:59:59 (UTC) (mandatory, even with empty data records).

3.4 Availability

The control system must guarantee a degree of availability to the regulatory authority and respective tax authorities. Access to the safe system must be possible at least during the authorities’ normal working hours6.

In the event that availability fails or is impaired, the regulatory authority will tolerate maximum down time of one working day.

3.5 Backup requirements

The operator ensures the necessary backup of all data. The safe system and its backup must be geographically separate, at least in different compartments. Data storage on digital media must also be geographically separate from its corresponding backup.

The back-up system must be located in the EU and EEA.

Online backup and recovery data transfer between both locations must be carried out in a safe manner.

3.6 Confidentiality, integrity and authenticity

Using cryptographic procedures, the safe system ensures the goals of confidentiality, integrity and authenticity of the log data. Digital linking and sealing (signature) of the data makes any change to the data (amendment, deletion, supplementation) provable.

3.6.1 Authentication and encryption

The provision of confidentiality by the safe system when saved data is accessed by the regulatory authority is protected by several technical measures:

Access is safeguarded by means of the authentication TLS-client authentication. The authentication/authorisation to be carried out is described in more detail in chapter 5.1

In addition, the log data is encrypted by means of a hybrid encryption process on the basis of the public certificates from the regulatory authority and tax authorities. The mechanisms to be used for encryption are described in chapter 4.2.

3.6.2 Signature and time stamp

Integrity and authenticity is to be protected by an electronic signature and cryptographic time stamp. The signature must be at least an advanced signature. The certificates used must have been published by a trustworthy, public certification authority (CA).

6Workdays from 6:00 until 18:00




A cryptographic time stamp is to be added to the signature according to XAdES7 V1.3.2 (ETSI TS 101 903). The XAdES signature time stamp is to be obtained in the form of a RFC3161 timestamp from a trustworthy, independent Time Stamping Authority (TSA)8.

In the event of the unavailability of the independent time stamp service, the time stamp must be applied by the end of the next working day at the latest. The mechanisms to be used for the signature and time stamp are described in chapter 4.2.

Given algorithms and key lengths comply with the recommendations of the current technical directives from the Federal Network Agency9. Implementation must always comply with the latest version of these recommendations.

7XML Advanced Electronic Signatures (XAdES) 8 http://www.bundesnetzagentur.de/cln 1912/DE/Service-Funktionen/Qualifizierteelektronische/Signatur/WelcheAufgabenhatdieBundesnetzagentur/AufsichtundAkkreditierungsvonAnbietern/ZertifizierungsDiensteAnbietr node.html 9http://www.bundesnetzagentur.de/cln 1912/DE/Service-Funktionen/Qualifizierteelektronische/Signatur/WelcheAufgabenhatdieBundesnetzagenturGeeigneteAlgorithmrnfestlegen/geeignetealgorithmenfestlegen-node.htmll




4. DATA FORMATS

This chapter defines the processing and format regulations for the generation of the data which is to be provided by a gaming operator in a safe system (see chapter 2). These regulations are subdivided as follows:

Data log model (chapter 4.1)

o Defines the structures for the recording of data relevant to regulatory measures.

Manifest mode (chapter 4.2)

o Defines structures and algorithms which guarantee the integrity, confidentiality and authenticity of the information recorded using cryptographic.

The models are defined by XML schemas which can change. UTF 8 format is to be used for coding and UTC is to be used for the time zone instead of CET.

The data is provided by the gaming operators within the framework of this technical directive only in accordance with the regulations defined in chapters 0, 4.2 and 5.

Chapter 4.3 contains additional explanations regarding the requirements in terms of validity and dealing with updates and corrections in the data provided.

The XML schemas corresponding to this technical directive have the following namespace and the following version:

Model Namespace Version

Data log model http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-aufzeichnungsmodell-v2.0.xsd

2.0.0

Manifest model http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-manifestmodell-v2.0.xsd

2.0.0

4.1 Data log model

The data log model describes the recording regulations for data sets relevant to regulatory matters. The data log model differentiates in particular between root elements and main elements. Main elements are direct “child elements” of a root element, which are written as instances of a main data type into an XML file. The following Table 1 provides an overview of all the main elements for which information must be recorded by the gaming operator for the regulatory authorities. The same table also lists when a specific main element must be generated for transfer into the safe system. Together with the explanations in chapter, 0, chapter 4.2 and chapter 5, the form (e.g. particularly in which file) in which a specific main element is to be saved is defined

Main element When generated?

/afz:aufzeichnungen/afz:spieler ● as soon as a new player was registered ● as soon as the change to one or more of a player’s values, recorded via this main element, becomes known. ● as soon as a request is carried out by the regulatory authority.

/afz:aufzeichnungen/afz:einzelspielerspiel ● as soon as all gaming activities directly following one another in time (several game rounds) with respect to a specific game by a player were concluded and the transaction to be recorded was completed.

http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-manifestmodell-v2.0.xsd

http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-manifestmodell-v2.0.xsd




The player’s activity with regard to a game is regarded as concluded when the player has actively ended the game (e.g. special function or closure of a browser window) or the game was automatically ended by the system (e.g. if the player is inactive for a long time)

/afz:aufzeichnungen/afz:gemeinschaftsspiel

● as soon as all the winners of the game are known and all the transactions to be concluded have been completed.

/afz:aufzeichnungen/afz:wettabschluss ● as soon as the bets are regarded as completed and the transaction to be recorded has been completed.

/afz:aufzeichnungen/afz:wettergebnis ● as soon as a betting result for a betting conclusion is known and the transaction to be recorded has been completed.

/afz:aufzeichnungen/afz:wettergebniskorrektur ● as soon as a corrected betting result for a betting conclusion is known, which results in a change to a player account status, and the transaction to be recorded has been completed.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion ● as soon as a change to a player account status occurs, which is not recorded via a main element from chapters 4.1.4 to 4.1.8 and the associated translation was completed.

Table 1: Permissible main elements of the data log model in version 2.0

The XML root element /afz:aufzeichnungen (see chapter 4.1.1) is the “carrier” of the different main elements.

4.1.1 Root element “data logs”

Figure 2: Schema of the root element data logs

Technical explanations

/afz:aufzeichnungen [Mandatory]




Highest structural element in the data log model, which contains a sequence of main elements. These main elements can occur in any order and there can be any number of them. There can only be one data log element per XML file.

/afz:aufzeichnungen/@afz:lizenzinhaberREF [mandatory]

Identifier (key) of the licence holder, which is assigned by the Gaming Regulatory Authority

/afz:aufzeichnungen/afz:spieler [optional]

Information on a player. See chapter 4.1.3.

/afz:aufzeichnungen/afz:aufzeichungen/afz:einzelspielerspiel [optional]

Information on an online casino game in which only one player can take part. See chapter 4.1.4.

/afz:aufzeichnungen/afz:gemeinschaftspiel [optional]

Information on an online casino game in which at least two players can play against one another. See chapter 4.1.5.

/afz:aufzeichnungen/afz:aufzeichnungen/afz:wettabschluss [optional]

Information on a betting event. See chapter 4.1.6.

/afz:aufzeichnungen/afz:aufzeichnungen/afz:wettergebnis [optional]

Information on a betting result which follows an event on which bets were placed. See chapter 4.1.7.

/afz:aufzeichnungen/afz:aufzeichnungen/afz:wettergebniskorrektur [optional]

Information on a betting correction (betting settlement) which follows an event on which bets were placed. See chapter 4.1.8.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion [optional]

Information on a value change of a player account status (or subaccount status) which was caused independently of a gaming activity or betting activity. See chapter 4.1.9.

4.1.2 Basic types of data log information

Figure 3: Schema of the basis type of data log information




Technical explanation

Meta information which is added to each main element in order to record the technical parameters, to provide information about the creation process for a main element and to allow the addressing of individual main elements without reference to the technical content.

Each main element inherits the schema of the basic data log information.

/afz:aufzeichnungen/<Hauptelementname>/@afz:aufzeichnungsID [mandatory]

Identifier (key) of the data log. This identifier is to be assigned clearly to all the listed main elements within a safe system.

/afz:aufzeichnungen/<Hauptelementname>/@afz:datenerfassungsDatum [mandatory]

Time of the generation of the main element prescribed in accordance with Table 1.




4.1.3 Main element “player”

Figure 4: Schema of the main element player





The main element player records information which refers to the person of an individual player. The data set is created when a player is registered and is then always created when there is a change to any of the subelements recorded in this main element. Upon registration of a player a unique identifier (key) is to be assigned in the content of the gaming operator.

This main element inherits the schema of the basic data log information in chapter 4.1.2.

/afz:aufzeichnungen/afz:spieler

Contains registration information about players. Such a main element is to be created for transfer into the safe system

as soon as a new play was registered

as soon as the change to one of more values of a player, recorded via this main element, becomes known.

as soon as a request is made by the regulatory authority.

/afz:aufzeichnungen/afz:spieler/afz:spielerID [mandatory]

Unique one-off identifier (key) to be allocared to the registered player by the gaming operator. The value must not provide any information about the actual identity of the player. Is not reallocated in the event of changes to the database.

/afz:aufzeichnungen/afz:spieler/afz:vorname [mandatory]

First names of the player. All the first names must be recorded, they must be separated using a space.

/afz:aufzeichnungen/afz:spieler/afz:name [mandatory]

Surname of the player.

/afz:aufzeichnungen/afz:spieler/afz:geburtsname [mandatory]

Birth name of the player. If the surname does not correspond to the birth name, the surname is to be re-entered in this element.

/afz:aufzeichnungen/afz:spieler/afz:geburtsdataum [mandatory]

Date of birth of the player.

/afz:aufzeichnungen/afz:spieler/afz:geburtsort [mandatory]

Place of birth of the player.

/afz:aufzeichnungen/afz:spieler/afz:wohnsitz [mandatory]

Information regarding the domicile of the player, which can be derived from his identity papers. If this domicile is not in Schleswig-Holstein, a reported additional domicile or a usual place of residence in Schleswig-Holstein must be recorded in the element /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz

/afz:aufzeichnungen/afz:spieler/afz:wohnsitz/afz:strasse [mandatory]




Street with house number of the place of residence.

/afz:aufzeichnungen/afz:spieler/afz:wohnsitz/afz:postcode [mandatory]

Postcode of the place of residence.

/afz:aufzeichnungen/afz:spieler/afz:wohnsiz/afz:ort [mandatory]

Name of the town in the player’s place of residence is located.

/afz:aufzeichnungen/afz:spieler/afz:wohnsitz/afz:staat [optional]

Country code in accordance with ISO 3166-1 (ALPHA-2) of the country in which the place of residence is located. Must be recorded if the place of residence is not in Germany.

/afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz [optional]

Place of residence which must be recorded if the player’s identity papers show no place of residence which is in Schleswig-Holstein. This can be a recorded additional place of residence or a usual place of residence. With a usual place of residence, this is a location at which the player only stays temporarily, although for a specific duration and with a specific regularity.

/afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:strasse [optional]

Street with house number of the additional place of residence or the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz) for the player.

/afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:postcode [mandatory]

Postcode of the additional place of residence or the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz) for the player.

/afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:ort [mandatory]

Name of the town in which the additional place of residence or the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz) for the player is located.

/afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:grund [optional]

Reason for the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz). This element does not apply if this is a reported additional place of residence.

/afz:aufzeichnungen/afz:spieler/afz:staatsangehoerigkeit [mandatory]

Nationality in accordance with DIN EN ISO 3166-1 (ALPHA-2).

/afz:aufzeichnungen/afz:spieler/afz:benutzername [mandatory]

User name chosen by the player himself. There may only be one unique and one-off user name for a gaming operator. The user name is the name with which the player appears to third




parties. If the gaming operator does not allocate a user name, the note "N/A" is to be entered here.

/afz:aufzeichnungen/afz:spieler/afz:registrierungsstatus [mandatory]

Registration status in connection with the validation of the player’s identity and the usability of a player account. Takes one of three pre-defined values:

Provisional Status of the registration before a player’s registration information is authenticated by a trustworthy instance (e.g. Post-Ident).

Authenticated Status of the registration after a player is authenticated by a trustworthy instance (e.g. Post-Ident).

Deregistered Status of the registration if a gaming account is closed by the operator, if the player quits or if the player applies for a voluntary, definitive self-block. In the latter case the child element /afz:aufzeichnungen/afz:spieler/afz:sperre must be written in the same data log.

/afz:aufzeichnungen/afz:spieler/afz:automatischerGewinntransaktion [optional]

Amount above which winnings are automatically transferred to the player’s bank account (see /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg)(see § 8(2) of the GGVO). If no limit applies, this element is not to be recorded.

/afz:aufzeichnungen/afz:spieler/afz:sperre [optional]

Duration of a block in days which a player has applied himself or was imposed for an account by a gaming operator (see Blocks in accordance with § 8(3) of the GGVO). For a block in accordance with § 10(3) of the GGVO), the duration in days must be entered here which the gaming operator reserves the right to impose or order to decide on the consequences resulting from this sort of block. The gaming operator can extend this period at any time. This element does not apply is no block is imposed.

/afz:aufzeichnungen/afz:spieler/afz:sperre/@sperrart [mandatory]

Type of block. Describes whether the block is determined by the player himself (self-block) or by the gaming operator (third-party block). The following values are to be used.

Temporary break from gaming in accordance with § 8 (3) of the GGVO

Self

Temporary block in accordance with § 8 (3) of the GGVO

Self

Permanent block in accordance with § 8 (3) of the GGVO or § (2) in connection with §§ 18 (5), 21 (7) of the Gaming Act.

Self or third-party

Block in accordance with § 10 (3) of the GGVO

Third-party




/afz:aufzeichnungen/afz:spieler/afz:sperre/@geltungsbereich [mandatory]

Scope of a block with respect to gaming operators. Describes whether a block is valid only with recording gaming operators (local) or with all gaming operators (global). The following values are to be used:

Temporary break from gaming in accordance with § 8 (3) of the GGVO

Local

Temporary block in accordance with § 8 (3) of the GGVO

Local

Permanent block in accordance with § 8 (3) of the GGVO or § (2) in connection with §§ 18 (5), 21 (7) of the Gaming Act.

Local or global

Block in accordance with § 10 (3) of the GGVO

Local

/afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung [mandatory]

Payment limit which a player has set himself. The limit can be increased if the period, for which the limit applies, is shortened, or when a limit which has been is completely cancelled.

/afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afx:antragsdatum [mandatory]

Date on which the limit was applied for (set) by the user. With a new registration of a player, no (voluntary) payment limit applies. Instead, the date of the player’s registration is to be entered in this case. If the data record is recorded without their being a change in the payment limit, the same values are to be entered here which were recorded in the last /afz:aufzeichnungen/afz:spieler data record.

/afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory]

Date on which the limit or change to the limit comes into force for the first time. With a new registration of a player, no (voluntary) payment limit applies. Instead, the date of the player’s registration is to be entered in this case. If the data record is recorded without their being a change in the payment limit, the same values are to be entered here which were recorded in the last /afz:aufzeichnungen/afz:spieler data record.

/afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit [optional]

Information regarding the maximum amount of all accumulated payments into the gaming account within a relative period, which is recorded under /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:zeitraum. If no payment limit applies or if a payment limit is inapplicable on a validity date, this element is not written in the data record. If a payment limit is active, however, no change to the payment limit is entered with the data record, so in this case the same values are to be entered which were also recorded in the last /afz:aufzeichnungen/afz:spieler data record for this player.

/afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:betrag [mandatory]

Maximum amount of all accumulated payments within a relative period which is recorded under /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:zeitraum.




/afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:zeitraum [mandatory]

Period in which a maximum amount of accumulated stakes may not be exceeded. The following pre-defined values can be adopted.

Day All accumulated payments are reset every 24 hours, from the start of the accumulation of payments. Payments are to be accumulated from the dated recorded in /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory]

Week All accumulated payments are reset every 168 hours (7 days), from the start of the accumulation of payments. Payments are to be accumulated from the dated recorded in /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory]

Month All accumulated payments are reset every 720 hours (30 days) from the start of the accumulation of payments. Payments are to be accumulated from the dated recorded in /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory]

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg [mandatory]

Payment method between the player and its gaming account. The bank account, card payment, other payment services or exclusively cash must be recorded as child elements.

/afz:aufzeichnungen/afz:spieler/afz:zahlungs/afz:bakkonto [optional]

Bank account used for financial transactions by way of transfer, direct debit or EC card payment to and from the player’s account.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest [mandatory]

International bank account number in accordance with ISO 13616. The value is not written in plain writing for the purposes of pseudonymisation, but is saved as a hash value (digest). In addition the UTF-8 coded value is to be converted into a byte sequence and added to the hash value.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest@digestMethod [mandatory]

The algorithm used for generating the hash value. Currently, the algorithm SHA-256 is to be used. For identification purposes, the attribute value of the URI http://www.w3.org/2001/04/xmlenx#sha256 is to be entered.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:bicDigest [mandatory]

Bank identification code in accordance with ISO 9362. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung [mandatory]

Information on financial transactions which are settled between the player and player account via a credit card company.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:kartengesellschaft [mandatory]




Name of the credit card company (e.g. Mastercard, Visa, etc.). The issuing organisation (e.g. a bank or a society) is not to be recorded.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:kartennummerDigest [mandatory]

Number on the card. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:inhaber/afz:inhabernameDigest [mandatory]

Full name which appears on the card. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:referenzBankkonto [mandatory]

Bank account of the player which (ultimately) is debited for debit adjustments, repayments and fees for the card recorded. It is used in the event that financial transactions from the gaming account to the player cannot be posted to the registered card.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:referenceBankkonto/afz:ibanDigest [mandatory]

Bank identification code in accordance with ISO 9362. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:sonstigeZahlungsdienste/afz:anbieteridentifikation [mandatory]

Information regarding financial transactions which settled between the player and gaming account using other payment services.

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:sonstigeZahlungsdienste/afz:kontoidentifikationDigest [mandatory]

Unique identification of the account used at the financial services operator. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply

/afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:ausschliesslichBar [mandatory]

This element is to be recorded if only cash payments are used for this player in stationary betting operations. If as cashless transaction takes place between the player and the gaming operator, a corresponding other element must be recorded in /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg




4.1.4 Main element “single player game”

Figure 5: Schema of the main element single player game


The main element single player game records the gaming activities of a player in a specific single player game (“human verses random generator”) in a closed, complete time interval. The gaming activity starts with the first stake with the specific game and ends when the player explicitly leaves




(e.g. the corresponding browser window is closed) or the game is automatically terminated by the system (e.g. due to a long period of inactivity on the part of the player).


/afz:aufzeichnungen/afz:einzelspielerspiel

Accumulated information on a single player game over several rounds. Such a main element is to be generated for transfer into the safe system.

as soon as all gaming activities directly following one another in time (several game rounds) with respect to a specific game by a player were concluded and the transaction to be recorded was completed. The player’s activity with regard to a game is regarded as concluded when the player has actively ended the game (e.g. special function or closure of a browser window) or the game was automatically ended by the system (e.g. if the player is inactive for a long time).

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:einzelspielerspielID [mandatory]

Distinct, one-off identifier (key) of the single player game to be assigned by the gaming operator.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielerREF [mandatory]

Identifier (key) of the player, in accordance with /afz:aufzeichnungen/afz:spieler/afz:spieler in chapter 4.1.3.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielart [mandatory]

Type of game. Possible values: slot game, scratchcard, videopoker or other.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielname [mandatory]

Name of the game in accordance application documentation.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:jackpot [mandatory]

Indication as to whether a jackpot was won with the game (true) or not (false).

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamteinsatz [mandatory]

Total of all stakes which the player has placed over all the completed rounds of this single player game.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamtgewinn [optional

Total of all winnings which the player has won over all the completed rounds of this single player game. If no winnings have been won, this element need not be recorded.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:jackpotgewinn [optional]

Amount of the jackpot winnings which the player has won. If there is no jackpot, this element need not be recorded.




/afz:aufzeichnungen/afz:einzelspielerspiel/afz:sachgewinne [optional]

Merchandise which the player has won over all the completed rounds. If no merchandise has been won, this element need not be recorded.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:sachgewinne/afz:sachgewinne [mandatory]

Informal description of the merchandise.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielanfang [mandatory]

Time of the start of the player activities in the game (first stake).

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielende [mandatory]

Time of the end of the player activities in the game (active or passive “logout”)

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:anzahlSpielrunden [mandatory]

Number of rounds completed between the start and end of the gaming activities of the player in the game.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:realityChecks [mandatory]

Times of all implemented “reality checks”.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:realityChecks’afz:realityChecks [optional]

Times of all implemented “reality checks”.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion [mandatory]

Arithmetic overall transactions between gaming account and gaming operator based on the gaming activities recorded in this main element.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/@afz:subkontotyp [optional]

Subaccount type of the gaming account to which the transaction refers. If no subaccounts have to be set up by the gaming operator, the attribute can be omitted. Otherwise the following values are to be entered:

blocked Logs the value changes to the subaccount from which no payments can be made to the player.

remote operation Logs the value changes to the subaccount for payment movements in remote operation, from which payments can be made to the player.

/afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag [optional]

Scope and direction of a cash-less payment movement. A minus sign (-) corresponds to a debit from the gaming account (reduction of the value of the gaming account), while no sign corresponds to a credit to the gaming account (increase in the value of the gaming account). A plus sign (+) is not used.




/afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielkontostand [optional]

Value of the gaming account (or subaccount) after completion of the transaction. A negative amount is not permitted. The amount corresponds to the balance of the player which can be used to take part in a game or for payment. A plus sign (+) is not used.

4.1.5 Main element “community game”

Figure 6: Schema of the main element community game


The main element community game logs information regarding a game in which at least two players have played against one another. If participation in the game has been via a network covering all gaming operators, each gaming operator must record this data set using a safe system in accordance with this directive and save it in its safe system. A community game is regarded as started as soon as the first stake has been made, and ends as soon as all winners are certain. No new players can join the game while a community game is running.


/afz:aufzeichnungen/afz:gemeinschaftsspiel

Protocol of a community game. Such a main element is to be created for transfer to the safe system

as soon as all winners of the game are certain and to transactions to be recorded have been concluded.




/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:gemeinschaftsspielID [mandatory]

Distinct, one-off identifier (key) of the community game to be assigned by the gaming operator.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:netzwerkspiel [optional]

Information if the community game was implemented in a gaming network spanning all faming operators. If the game took place with just one gaming operator, this element is not applicable.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:netzwerkspiel/afz:plattformanbieter [mandatory]

Name of the platform operator on whose gaming platform the network game was implemented.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:netzwerkspiel/afz:netzwerkspielID [mandatory]

Identifier (key) of the game assigned by the platform operator.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielart [mandatory]

Name of the type of game. Possible values are Poker and Other.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielvariante [mandatory]

Name of the game variation in accordance with application documents (e.g. Texas Hold ‘Em).

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielanfang [mandatory]

Time at which the first stake was made.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielende [mandatory]

Time at which the winners are certain.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:rake [mandatory]

Fee for participation in a community game.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:rake/afz:gesamtrake [mandatory]

Total fee deducted from all participants in a community game. Even if the gaming operator retains only a part or nothing of the fees collected (network), the entire fee collected is to be logged.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:rake/afz:einbehaltenerAnteil [optional]

Proportion of the total rake which remains with the gaming operator keeping the records. If the gaming operator completely retains the entire rake (no network), no entry is required.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll [mandatory]

Information regarding all players which have participated in the game.




/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler [2..*]

Information regarding a player who has participated in a game.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:fremderBenutzername [optional]

User name of a player who is not registered with the gaming operator keeping the records.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:registrierterSpieler [optional]

User name of a player who is registered with the gaming keeping the records.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:registrierterSpieler/afz:spielerREF [mandatory]

Player identification of a player, in accordance with /afz:aufzeichnungen/afz:spieler/spielerID in chapter 4.1.3, who is registered with the gaming operator keeping the records.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:registrierterSpieler/afz:einsatz [mandatory]

Total stake of a player up to determination of all final winners.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:gewinn [optional]

Total winnings of a player after determination of all final winners. This element is not applicable if the player has no winnings.

/afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:gesamttransaktion [optional]

Arithmetic total transaction in reference to the gaming account of a player based on the relevant gaming activities. Is only logged by the gaming operator with which the player is registered. See /afz:aufzeichnungen/afz:einselspielerspiel.afz:gesamttransaktion.

4.1.6 Main element “betting completion”




Figure 7: Schema of the main element betting completion





The main element betting completion logs the details of the betting completed between a player and a gaming operator (organiser).


/afz:aufzeichnungen/afz:wettabschluss

Specific betting of an individual player with a gaming operator. Such a main element is to be created for transfer to the safe system.

as soon as the betting is regarded as completed and the transaction to be recorded has been completed.

/afz:aufzeichnungen/afz:wettabschluss/afz:wettabschlussID [mandatory]

Unique key to be assigned by the gaming operator for the specific betting.

/afz:aufzeichnungen/afz:wettabschluss/afz:wettscheinID [optional]

Identifier for associated bets which is to be used in two cases.

If several independent bets have been completed at the same time (e.g. preset package of several individual bets, multi-bets), these bets are each to be logged as an independent main element and allocated a common identifier.

If bets, due to their conditions, cannot be registered as combination bets or system bets in accordance with the preset schema (e.g. bank tip, system trixie), the different bet rows are each to be logged as an independent main element and allocated a common identifier.

/afz:aufzeichnungen/afz:wettabschluss/afz:spielerREF [mandatory]

Player identification in accordance with /afz:aufzeichnungen/afz:spieler/afz:spielerID in chapter 4.1.3.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis [mandatory]

Details of a bet depending on the type of bet.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette [optional]

Details of the result of an individual bet.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbewerb [mandatory]

Separate, detailed description of the sports betting application. In the framework of which the betting is completed.

Examples (see also child elements)

Type of sport Name of event Date held

Football Men’s 2014 World Championship, group A, Italy – Mexico 18.08.2014

Handball Men’s Bundesliga 2013/2014, 3rd day, THW Kiel – SC Magdeburg

21.11.2013




Basketball Tryout, Germany – Austria 01.04.2014

Athletics 2016 Olympic Games, men’s 100m final 15.08.2016

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbewerb/afz:sportart [mandatory]

Official name of the type of sport, in the framework of which the betting is completed.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbewerb/afz:veranstaltungsname [mandatory]

Official name of the sporting event, in the framework of which the betting is completed.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbewerb/afz:austragungsdatum [mandatory]

Expected date of the event of the sports betting application with betting completion.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:ereignis [mandatory]

Informal, precise description of the event which must be held so that the bet is won by the player. Any applicable handicap is to be incorporated into this description.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:handicap [optional

Indication as to whether this is a handicap bet. With a handicap bet, this element must be logged with the value true. Otherwise, the value false is to be recorded, or this element can be omitted.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:quote [mandatory]

Quote for the individual bet which was valid when the bet was completed.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:liveWette [optional

Indication as to whether betting completed refers to live bets. Must be logged with the value true if the betting completed involves live bets.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:kombiwette [mandatory]

Derails of a combi bet.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:kombiwette/afz:wette [1..*]




Details of an individual bet which is part of the combi bet. See /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz;wette/@afz:swquenzID [mandatory]

Identifier (numbering) of an individual bet, within the overall betting.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette [mandatory]

Details of a system bet.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/@afz:tipps [mandatory]

Minimum of individual bets won so that the system bet overall applies as won.

/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette [1..*]

Details of an individual bet which is part of the system bet. See /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette

/afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss [optional]

If the bet is completed in stationary operation not via the internet), the unique identification features of the operating location must be entered here.

/afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:vertriebsstättename [mandatory]

Name of the operating location in accordance with the application documents.

/afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:adresse/afz:strasse [mandatory]

Street and building number of the operating location.

/afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:adresse/afz:postcode [mandatory]

Postcode of the operating location.

/afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:adresse/afz:ort [mandatory]

Name of the tow in which the operating location is located.

/afz:aufzeichnungen/afz:wettabschluss/afz:datum [mandatory]

Time the betting was completed.




/afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion [mandatory]

Transaction from gaming account to the gaming operator, in order to pay the betting stake.

/afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp [optional]

Subaccount type of a gaming account to which the transaction refers. If no subaccounts have to be set up by the gaming operator, this attribute can be left out. Otherwise the following values are to be entered.

Blocked Logs the value changes on the subaccount, from which no payments can be made to the player.

remote operation Logs the value changes on the subaccount for payment movements in remote operation, from which payments can be made to the player.

Stationary Logs the value changes on the subaccount for payment movements in stationary operation, from which payments can be made to the player.

/afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:unbarbetrag [mandatory]

Scope of a cash-less payment which is carried out to partially or fully pay for a betting stake. If no cash-less payment is carried out, the value ‘0’ is to be logged. See also /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A positive amount is nor permissible here.

/afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:spielkontostand [mandatory]

See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielkontostand

/afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:barbetrag [Optional]

Scope of a cash payment made in partial or full settlement of a betting stake. If no cash payment is made, this element can be omitted. It is not permissible to enter a positive amount here.




4.1.7 Main element “betting result”

Figure 8: Schema of the main element betting result


The main element betting result logs the result (and/or the outcome) of previously completed betting.


/afz:aufzeichnungen/afz:wettergebnis

Result of a previously completed bet by a single player. Such a main element is created for transfer to the safe system.

as soon as a betting result is determined for a bet completed and the transaction to be recorded has been concluded.

/afz:aufzeichnungen/afz:wettergebnis/afz:wettergebnisID [mandatory]

Unique key which identifies the betting result of a completed bet.

/afz:aufzeichnungen/afz:wettergebnis/afz:wettabschlussREF [mandatory]

Unique key which identifies the associated bet completed of a player in accordance with




/afz:aufzeichnungen/afz:wettabschluss/afz:wettabschlussID in chapter 4.1.6.

/afz:aufzeichnungen/afz:wettergebnis/afz:ergebnisID [mandatory]

Overall result of the bet from the player’s perspective. The following values can be logged here;

cancelled The gaming operator invalidated or cancelled the bet. The winnings of the player equal a simple refund of the stake or the agreed buy-back value of the completed bet.

won The bet was won. The player receives winnings which result from the stipulated quote.

lost The bet was lost. The player receives no winnings.

/afz:aufzeichnungen/afz:annullierungsdetail [optional]

Informal detailed information regarding the cause of the invalidation of the bet. Must be written if the result of the bet is “invalidated”.

/afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse [optional]

Results of all (individual) bets of which a system or combi bet is comprised. If the completed bet referred to is an individual bet, this element is not applicable.

/afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse/afz:ergebnis [mandatory]

Result of an individual bet in accordance with the table under /afz:aufzeichnungen/afz:wettergebnis/afz:ergebnis or the value

not evaluated To be used if the result of the corresponding individual bet is not known, and due to the known results of other individual bets is insignificant for the end result.

/afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse/afz:ergebnis/@afz:sequenzREF [2..*]

Identifier (numbering) of the referenced individual bet in accordance with /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette/@afz:sequenzID or /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette/@afz:sequenzID.

/afz:aufzeichnungen/afz:wettergebnis/afz:annullierungsdetail [0..*]

Informal detailed information regarding the cause of the invalidation of an (individual) bet. Must be written if the result of the bet is “invalidated”.




/afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse/afz:annullierungsdetail/@afz:sequenzREF [mandatory]

Identifier (numbering) of the referenced (individual) bet in accordance with /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette/@afz:sequenzID or /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette/@afz:sequenzID.

/afz:aufzeichnungen/afz:wettergebnis/afz:datum [mandatory]

Time from which the betting result is regarded as being valid,

/afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion [mandatory]

Transaction from the gaming operator to the gaming account in order to pay winnings. If the player lost, this element is not applicable.

/afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion/@afz:subkontotyp [optional]

See /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp in chapter 4.1.6.

/afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion/@afz:unbarbetrag [mandatory]

See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A negative amount is not permissible.

/afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion/@afz:spielkontostand [mandatory]

See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielkontostand




4.1.8 Main element “betting result correction”

Figure 9: Schema of the main element betting result correction


The main element betting result adjustment logs the adjustment of an already logged betting result. It is only logged if the previously logged (total) result has changed and this has resulted in a change to the gaming account

This main element inherits the schema of the betting result in chapter 4.1.7

/afz:aufzeichnungen/afz:wettergebniskorrektur




Adjustment of a result of a previously completed bet by a single player. Such a main element is created for transfer to the safe system.

as soon as an adjusted betting result for a completed is determined for a bet, which resulted in a change to a gaming account, and the transaction to be recorded has been concluded.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:wettergebnisID [mandatory]

Unique identifier (key) which identifies thus betting result adjustment (not the previously logged betting result /afz:aufzeichnungen/afz:wettergebnis).

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:wettabschlussREF [mandatory]

Unique identifier key which identifies the associated bet completed of a player in accordance with /:afz:aufzeichnung0en/afz:wettabschluss/afz:wettabschlussID in chapter 4.1.6.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:ergebnis [mandatory]

Adjusted overall result from the perspective of the player. See /afz:aufzeichnungen/afz:wettergebnis/afz:ergbenis in chapter 4.1.7 or the value

open If, due to adjustments in the individual betting results, the overall result of an already evaluated bet has been opened again.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:annullierungsdetail [optional]

Informal detailed information regarding the reason for the invalidation of the bet. Must be written if the result of the bet is “invalidated”.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:einzelwettebergebnisse [optional]

Adjusted individual betting results from the perspective of the player. See. /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse in chapter 4.1.7 with the exception of /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:einzelwettenergebnisse/afz:ergebnis (see below)

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:einzelwettenergebnisse/afz:ergebnis [mandatory]

Result of an individual bet in accordance with the table under /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnis or the value

Open To be used if the result of the corresponding individual bet is open again after the adjustment and it is not yet certain whether this individual result is relevant to the overall result (/afz:aufzeichnungen/afz:wettergebnis/afz:ergebnis or /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:ergebnis)

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:datum [mandatory]




Time from which the adjusted betting result is to be regarded as valid.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion [optional

Value transaction from the gaming operator to the player in order to adjust winnings. This element is only logged if the winnings are higher than in the previously logged (regular) result (/afz:aufzeichnungen/afz:wettergebnis), if the winnings are less then the element /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung is to be used and this element is omitted.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion/afz:subkontotyp [optional]


/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion/afz:unbarbetrag [mandatory]

Amount of the cash-less winnings adjustment. See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A negative amount is not permissible here. Only the difference above the previously logged betting result wings is logged.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion/afz:spielerkontostand [mandatory]

See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielerkontostand

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:details [mandatory]

Informal detailed description regarding the cause of the adjustment.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung [optional]

Transaction from the player to the gaming operator in order to adjust previously paid out winnings. This element is omitted if no wings have to be cancelled.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung/afz:subkontotyp [optional]


/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung/afz:unbarbetrag [mandatory]

Amount of a cash-less cancellation. See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A positive amount is not permissible.

/afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung/afz:spielerkontostand [mandatory]




Value of the player’s account (or subaccount) after completion of the transaction. A negative amount equals a debt still to be paid by the player to the gaming operator. A positive amount equals the player’s balance which can be used for participation in a game or for a payment. A plus symbol (+) must not be used.

4.1.9 Main element “game-independent transaction”

Figure 10: Schema of the main element game-independent transaction.


The main element game-dependent transaction logs transactions which change the value of the gaming account (or subaccount) but the reason for the change is independent of direct gaming activities. A combination of two such main elements is to be logged to record the release of values blocked for payment to the player (bonuses). In such a case, an element game-independent transaction is logged which logs the value reduction (negative value of non-cash amount) of the




subaccount with the values blocked for payment to the player (subaccounttype = “blocked”0. In addition, a second element game-independent transaction is logged which records the corresponding value increase (positive value of non-cash amount) of a subaccount for internet operations (subaccount type = “online”) or stationary operations (subaccount type = “stationary”).

This main element inherits the schema of the data log information in chapter 4.1.2.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion

Information regarding a transaction which changes the value of the virtual player account (or subaccount), but which was caused independently (outside) of direct gaming activities. Such a main element is created for transfer to the safe system.

as soon as a change to a player account occurs which was not logged using a main element from chapters 4.1.4 to 4.1.8 and the associated transaction was completed.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaktionID [mandatory]

Unique key assigned by the gaming operator which identifies the transaction.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:spielerREF [mandatory]

Identification of the player, in accordance with /afz:aufzeichnungen/afz:spieler/afz:spielerID in chapter 4.1.3.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:details [mandatory]

Informal details of the transaction which must provide information about the cause of the transaction (e.g. deposit, payment, adjustment with exact reason).

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:automatiscjGewinntransaktion [optional]

Indicates whether the game-independent transaction was automatically completed in accordance with §8 (2) of the GGVO. Otherwise this element is omitted.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:zeitpunkt [mandatory]

Time at which the transaction was completed.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:stationaererVertrieb [optional]

Unique identification features of an operating location. Must be logged if a transaction was caused in stationary operations (not via the internet. See /afz:aufzeichnungen/afz:wettabschluss/afz:stationaererVertrieb

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaktion [mandatory]

Transaction information regarding changes to the gaming account (or subaccount),

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/@afz:subkontotyp [optional]





/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/afz:unbarbetrag [mandatory]

Cash-less paid amount of a transaction. See /afz:aufzeichnungen/afz:inzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag in chapter 4.1.4.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/afz:spielkontostand [mandatory]

Account balance of the player account (or subaccount) at the time the transaction was completed. See /afz:aufzeichnungen/afz:wettabschlusskorrektur/afz:gewinnstornierung/afz:spielkontostand in chapter 4.1.8.

/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction//afz:barbetrag [optional]

Amount of a transaction paid in cash. If no cash payment is made, this element is omitted or contains the value ‘0’. If cash payment is made, the cashless amount (/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/afz:unbarbetrag) contains the value ‘0’. The use of prefixes in this element is similar to how they are used in /afz:aufzeichnungen/afz:einzelspielerspiel/afz:geamttransaction/afz:unbarbetrag in chapter 4.1.4.

4.2 Manifest model

The safe model defines how XML documents with the log data are to be processed in order for them to be stored in the safe system with guaranteed confidentiality, authenticity and integrity. The manifest model also specifies data structures which carry the necessary cryptographic information.

4.2.1 Ensuring integrity and authenticity

In order to permit regulatory authorities and the relevant tax authorities to verify the integrity and authenticity of the logged data, cryptographic mechanisms are to be used as described below.

In order to ensure the verifiable absence of loopholes in the recorded log data, the documents with the container element <afz:aufzeichnungen> are linked to one another through the generation of hash values. For this purpose, a control data structure <safe:kontrollManifest>is defined in the manifest model, in which the hash value of the logged data is combined with the hash value of the control structure of the previous logs.

Each control structure is to have at least an advanced signature.

Details on data structures and processing are given in chapters 4.2.4 and 4.3. The principle of cryptographic linking is illustrated in figure 11.




Figure 11: Diagram of the principle of cryptographic linking

4.2.2 Compression and encryption

After the generation of the hash values (see chapter 4.2.1), the documents with the log data are compressed with the ‘deflate‘ algorithm (RFC1951) in order to reduce the volume of the stored data.

The compressed document is then encrypted to ensure confidentiality using the hybrid process. The safe system dynamically generates a symmetric key (256 Bit) for each document for this purpose and uses it to carry out encryption according to the Advanced Encryption Standard (AES256).

The generated AES256 key is asymmetrically encrypted with regulatory authorities’ public keys (X.509 certificate) according to the RSA2048 process. The thus encrypted key is stored according to the XML encryption standard within the control structure <safe:kontrollManifest> as an <xenc:EncryptedKey> element. If the different authorities have different public keys (X.509 certificates), the symmetric key is to be encrypted several times and stored in the control structure.

Data log

Data log

Data log

…

DocumentN

Hash value of document N

Hash value of previous manifest (N-1)

ManifestN

Signature N (XAdES)

Control manifest N

Data log

Data log

Data log

…

DocumentN+1

Hash value of document N+1

Hash value of previous manifest(N)

ManifestN+1

Signature N+1 (XAdES)

Control manifest N+1

Link Link




Figure 12: Mechanisms for compression and encryption of log data

4.2.3 Packing of log data and control structure

The compressed and encrypted documents with the log data and the signed control manifest are packed in a ZIP file. The ZIP file exclusively contains both file entries without path information (see also Figure 12):

data.bin - compressed and encrypted XML data logs

manifest.xml - signed XML control manifest

The resulting ZIP file is archived in the safe system in the folder structure of the respective day (see chapter 5.2.). The name of the ZIP file is formed according to the following example:

<lizenzinhaber>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

With

<lizenzinhaber> - Owner of gaming licence, no capitals

<seqno> - Day’s sequential counter, with leading zeros, 7 figures

<YYYYMMDD> - Date of creation of file

<hhmmss> - Time of creation with hour, minute and second

Data log

Data log

Data log

…

Document

xenc:EncryptedKey

Control manifest

RFC1951 deflate

RSA2048 encryption

symmetr. key

AES256 encryption

X.509 certificate of

regulatory authorities

compressed Compressed and encrypted

ZIP file




4.2.4 Schema of control manifest

The control manifest is an XML document, which is principally a carrier of meta-information and cryptographic data (hash values and key information). It represents the digital sealing and linking of technical log data.

Figure 13: Schema of control structure

The individual elements of the control structure are described in the following:

/safe:kontrollManifest/safe:lizenzinhaberREF

Distinct, identifying name of licence holder (gaming operator)

/safe:kontrollManifest/safe:erstellungdDatum

Date and time of generation of control manifest

kontrollManifest

tns:lizenzInhaberId tns:

tns:erstellungsDatum tns:

tns:manifestSequenceNumber tns:

tns:InhaltZfg

tns:inhaltZfg tns:

tns:anzahlAufzeichnungen tns:

tns:ersteAufzeichnung tns:

tns:letzteAufzeichnung tns:

tns:sizeUncompressed tns:

tns:sizeCompressed tns:

enc:EncryptedKey

1 ¥..

enc:EncryptedData

ds:ManifestType

dsig:Manifest

attributes

Id

ds:Reference

1 ¥..

dsig:Signature




/safe:kontrollManifest/safe:manifestSequenceNumber

Sequential counter of control manifests (beginning with “1“)

/safe:kontrollManifest/safe:metadaten

Element contains summarised meta-information on the XML document with the data logs.

/safe:kontrollManifest/safe:metadaten/safe:anzahlAufzeichnungen

Total number of log data records within the XML document

/safe:kontrollManifest/safe:metadaten/safe:ersteAufzeichnung

Date and time of the first log data record (identical to the element value <afz:datum> of the first element <afz:datenerfassung>)

/safe:kontrollManifest/safe:metadaten/safe:letzteAufzeichnung

Date and time of the last log data record (identical to the element value <afz:datum> of the last element <afz:datenerfassung>)

/safe:kontrollManifest/safe:metadaten/safe:sizeUncompressed

Size of the non-compressed XML document in bytes

/safe:kontrollManifest/safe:metadaten/safe:sizeCompressed

Size of RFC1951 compressed XML document in bytes

/safe:kontrollManifest/enc:EnryptedKey

Element contains the asymmetric, encrypted, dynamically generated AES256 key with which the data file is encrypted, according to the XML encryption standard10 . The encryption algorithm (RSA 1.5) and identification of the X.509 encryption certificate are to be coded. The element for identification of the symmetric key must also contain a name in the element <xenc:CarriedKeyName>.

Example:

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:X509Data>

<ds:X509SubjectName>CN=Behoerde, OU=Aufsicht, C=DE</ds:X509SubjectName>

</ds:X509Data>

</ds:KeyInfo>

<xenc:CipherData>

10see: http:///www.w3.org/TR/xmlenc-core/




<xenc:CipherValue>Z3wSdtXI7kpD3GwDlzhvIWRi…eYrO+Mwx76XkA=</xenc:CipherValue>

</xenc:CipherData>

<xenc:CarriedKeyName>K1456</xenc:CarriedKeyName>

</xenc:EncryptedKey>

If there are several X.509 encryption certificates for the regulatory authorities and the relevant tax authorities, several elements <xenc:EncryptedKey> are to be generated, which all contain the same symmetric key and name.

/safe:kontrollManifest/xenc:EncryptedData

______________________

see: http:///www.w3.org/TR/xmlenc-core/

This element represents the reference to the encrypted data according to the XML encryption standard. It contains the encryption algorithm (AES256) as well as the internal

reference to the symmetric key via the identifying name (identical to the value of the element <xenc:CarriedKeyName>).

The actual reference to the encrypted data is expressed by a logical URI which is generated by concatenation of both parts as follows:

Absolute path in URL syntax (without scheme and host) to the ZIP file. The path corresponds with the folder structure, which is described in chapter 5.2. Example:

/…/… …/<lizenzinhaber>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

Path extension to data.bin file within the ZIP file. Example:

/data.bin

An Id attribute is to be added to the element to express the link (see next chapter). Example:

<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="D1456">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>

<dsig:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<dsig:KeyName>K1456</ds:KeyName>

</dsig:KeyInfo>

<xenc:CipherData>

<xenc:CipherReference

URI="/ACME/Aufzeichnungen/2011/12/31/ACME_1456_20111231_235403.zip/data.bin"/>

</xenc:CipherData>

</xenc:EncryptedData>

/safe:kontrollManifest/dsig:Manifest

This element from the XML signature schema represents the cryptographic link of data log units (see chapter Erreur ! Source du renvoi introuvable.). It contains in general two references to data fields including their respective hash values:

External reference to the XML element <dsig:Manifest> from the control manifest within the previously constructed ZIP file (predecessor in the chain). The hash value is generated from the canonised XML element.




The reference is to be expressed by a logical URI, which is generated by concatenation of the three parts as follows:

o Absolute path in URL syntax (without scheme and host) to the previous ZIP file. The path corresponds with the folder structure, which is described in chapter Erreur ! Source du renvoi introuvable.. Example:

/…/… …/<lizenzinhaber>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

o Path extension to the manifest.xml file within the ZIP file. Example:

/manifest.xml o Reference to XML Id on the manifest element in URI fragment notation. Example:

#<Id>

Canonisation of the sub-element, which is to be carried out before hash value generation, is expressed by the transform URI for the C14N algorithm (with exclusive name spaces with sub-elements) as defined by the W3C:

http://www.w3.org/2001/10/xml-exc-c14n#

Internal reference to the XML element <xenc:EncryptedData> of this control structure. Processing rules are coupled with this reference, which convey that reference is made to the unencrypted and uncompressed data. The hash value is to be generated from the unencrypted and uncompressed XML document. The transformation instructions (Transform-URIs) are to be formulated from the view point of a system which wants to retrace the hash value for the purpose of validation: therefore decryption and then decompression should first be carried out before hash value generation. Two URIs are to be entered accordingly into the processing sequence. The URI http://www.w3.org/2002/07/decrypt#Binary is defined for decryption by the W3C. The URI

http:// www.schleswig-holstein.de/IM/transform/rfc1951#inflate is stipulated for RFC1951 decompression. Example:

<dsig:Manifest Id="M1456">

<dsig:Reference URI="/ACME/Aufzeichnungen/2011/12/31/ACME_1455_20111231_235304.zip/manifest.xml#M1455">

<dsig:Transforms>

<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</dsig:Transforms>

<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<dsig:DigestValue>w+7o4caCHF6+N/KFLoC8itsBNhTTIX2BgMOvgI09VUM=</dsig:DigestValue>

</dsig:Reference>

<dsig:Reference URI="#D1456">

<dsig:Transforms>

<dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#Binary"/>

<dsig:Transform Algorithm="http://www.schleswig-holstein.de/IM/transform/rfc1951#inflate"/>

</dsig:Transforms>

http://www.w3.org/2001/10/xml-exc-c14n

http://www.w3.org/2001/10/xml-exc-c14n




<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<dsig:DigestValue>agD4HdakRr1d3xR/t5YRyS5RstucSCakrWlbvryiJWM=</dsig:DigestValue>

</dsig:Reference>

</dsig:Manifest>

An Id attribute is also to be added to the manifest element to enable external reference to it for linking. For the exceptional case of the very first control manifest of a safe entity, for which there is no predecessor, the manifest only contains internal reference to the encrypted data.

/safe:kontrollManifest/dsig:Signature The complete control manifest is to have a qualified or advanced signature. The signature is to be applied as enveloped Signature (transformURI: http://www.w3.org/2000/09/xmldsig#enveloped-signature) in accordance with XAdES V1.3.2 incl. time stamp (XAdES-T).

4.3 Processing instructions

The individual processing steps leading up to creation and storage of a ZIP file to be provided by the gaming operator on the safe system (see 4.2.3) are listed in order below, comprising log data and the control manifest:

Step 0:

When one of the conditions for the conclusion of a data record is fulfilled (see chapter 3.3), the XML log document is immediately created.

Step 1:

The hash value of the XML log document is calculated with the hash algorithm SHA256.

Step 2:

The XML log document is compressed with the RFC-1951-DEFLATE algorithm.

Step 3:

A 256Bit long random key is generated for the purpose of symmetric encryption.

Step 4:

The compressed XML log document is encrypted with the AES256 algorithm using the key from step 3.

Step 5:

The XML control manifest is built and filled with meta data from the log document.

Step 6:

The symmetric key from step 3 is encrypted with the public key from the regulatory authority’s X.509 certificate and written in the XML control manifest as <xenc:EncryptedKey> according to XML encryption. An identifying name for the key is to be given in the element <xenc:CarriedKeyName>.

If there are several X.509 certificates, step 6 is to be repeated accordingly several times using the same key name.




Step 7:

The element <xenc:EncryptedData> with the reference to the encrypted data is to be built, given an Id attribute and written in the XML control manifest.

The URI value is to be generated as described in chapter 4.2.4. The key used is to be referenced via the identifying key name generated in step 6 using the element <dsig:KeyInfo>.

Step 8:

The hash value of the canonised element <dsig:Manifest> from the control manifest of the previous data record is to be calculated with the hash algorithm SHA256 (alternatively, the temporarily-stored hash value calculated during the construction of the previous data record can be accessed).

This step is not applicable for the exceptional case of the very first data record.

Step 9:

The element <dsig:Manifest> is to be built and given both references including their respective hash values (from step 1 and step 8). The transform URIs described in chapter 4.2.4 are to be entered.

The element is to be given an Id attribute and written in the control manifest.

Step 10:

The complete XML control manifest is to be given at least an advanced enveloped signature in accordance with XAdES, and a time stamp is to be added in accordance with chapter 3.6.2.

Step 11:

A ZIP file is to be created with both data entries consisting of the encrypted data file data.bin and the signed control manifest manifest.xml.

The name of the ZIP file is to be generated according to the rules defined in chapter 4.2.3.

Step 12:

The created ZIP file is stored in the safe system in the folder accessible to the regulatory authorities and the relevant tax authorities.

4.4 Validity, updating and adjustment of the data provided

Chapters 0. 4.1, 4.2 and 5 describe how and when data must be provided by the gaming operator for the regulatory authority and the relevant tax authorities. It is important that the gaming operators ensure the validity of the data provided, which is affected by the provisions of this directive, by adhering to this directive. Should the data in question not satisfy the provisions of this directive, the gaming operator can be requested to create again all the defective data in accordance with the provisions of this directive. In this case, the exact procedure is to be agreed with the regulatory authority.

This chapter indicates several points in the directive in order to support the gaming operator in ensuring the validity of data provided.

This directive specified XML schema (see annexes) which are also available as independent xsd schema files from the regulatory authority11. As the regulatory authority will check all XML files in

11The xsd schema files are not published on the internet under the URL of the targetNamespace, but are provided by the regulatory authority by e-mail.




terms of conformity with these schema, the technical assistance available should be used to ensure the required structure and the required element data standardisation, using these schema specifications, even in the creation of the XML data. There are no cases foreseen which would permit deviating from this direct schema conformity. If the XML schema is not adhered to in the data, the data will not be regarded as valid.

However, this directive also places requirements in terms of validity which lie outside the checking possibilities offered by an XML schema. These requirements are described in the technical explanations for the individual elements in chapters 4.1 and 4.2. Amongst other things, this involves the specification of value ranges for element content (e.g. with transactions), but also in terms of critical uniqueness requirements for identifiers (keys) and the requirements for the correct use of references. The gaming operator is thus requested to study the directive in detail in this respect and if necessary asking the regulatory authority to guarantee these "flexible" validity requirements. The regulatory authority will check these requirements and will not recognise as valid data which does not comply with them.

In this connection, you should also note that the main element player (defined in chapter 4.1.3) is the only main element through which updates of a basic database are recorded. When a corresponding database is updated, a main element player is logged in full, i.e. so that the main element must also contain all the relevant but unchanged information about the database in addition to the updated information, and in addition the instructions in chapter 4.1.3 are to be followed. All other main elements (chapters 4.1.4 to 4.1.9) correspond to databases which may not be updated. Should the information recorded by the latter main elements be defective and requires adjustment, the following procedure is to be applied. The main elements in question are to be recreated completely while maintaining the original object ID (see Table 2), although with a new <Hauptelement>/afz:aufzeichnungsID (see chapter 4.1.2). If corrections are implemented, the regulatory authority is to be provided with a report by 23:59:59 which contains a list the object ID of all the main elements corrected on this day and the reason for the correction of the respective main element.

Selected main element (without root) Object ID element

afz:einzelspielerspiel ./einzelspielerspielID

afz:gemeinschaftsspiel ./gemeinschaftssielID

afz:wettabschluss ./wettabschlussID

afz:wettergebnis ./wettergebnisID

afz:wettergebniskorrektur ./wettergebnisID

afz:spielunabhaengigeTransaktion ./transaktionID

Table 2: Element values in the column with the heading "Object ID element" may not be changed by corrections




5. DATA FORMATS

The following chapter describes how access to the ZIP files created in accordance with chapter 4.2.3 is to be provided for the regulatory authority and the relevant tax authorities.

5.1 Access technology

The ZIP files created in accordance with Chapter 4.2.3 are to be made available on a web server for access via the internet. Access may only be by means of HTTPS (HTTO over TLS) and the HTTP(S) request model GET. The server-SSL certificate must have been awarded by a trustworthy public certification authority (CA).

At the same time, the web server must guarantee access by means of TLS-client-authentication. Access is only to be granted if a NTTPS-request was authenticated with a valid X,509 certificate which is currently listed by the regulatory authority for authorised users and was supplied to the operator of the safe system by the regulatory authority.

As a supplementary measure to limit access, the web server is to be protected by firewalls which only accept connection requests from certain IP addresses (IP whitelisting). The IP addresses to be approved shall be provided by the regulatory authority.

Using the HTTP(S) request method GET, it must be possible to both determine the content of the folders (directory listing) and also obtain the ZIP files.

5.2 Logical data organisation

It must be possible to address the ZIP files to be created in accordance with chapter 4.2.3 via URLs. The URLs are to be implemented hierarchically as follows:

+ FQDN of the web server + Licence holder ID allocated by the supervisory authority (see also chapter 4.1.1) + "Data logs" + Identifier of the safe "Safe<N>" + Folder for the current year <YYYY> + Folder for the current month <MM> + Folder for the current day <DD> + Name of the ZIP file in accordance with chapter 4.2.3

The use of a HTTP(S) request method GET, which specifies the URL of the folder in the request URI, should return a HTML document as the reply (HTTP(S) response, from which can be obtained all the relative or absolute URLs of the subfolders contained or the ZIP files contained. It is not possible to store both subfolders and ZIP files under one folder. These relative and absolute URLs in different data lines (not as heading lines) should be contained in a table as HTML references.

The use of a HTTP(S) request method GET, in which the access URI is the URL or a ZIP file created in accordance with chapter 4.2.3, should return the corresponding ZIP file as the reply.

In principle, it is only permissible to use "Safe1" in the third hierarchical stage of the enquiry URI. You must apply to the regulatory authority for permission to use other "safes".

It must be possible to send the following URL pattern as enquiry URIs to the web server:

Pattern

Reply

https://<WebserverFQDN>/<lizenzinhaberREF>/Aufzeichnungen Director listing of the subfolders as HTML




https://<WebserverFQDN>/<lizenzinhaberREF>/Aufzeichnungen/Safe<N> Director listing of the subfolders as HTML

https://<WebserverFQDN>/<lizenzinhaberREF>/Aufzeichnungen/ Safe<N>/ Safe<YYYY>

Director listing of the subfolders as HTML

https://<WebserverFQDN>/<lizenzinhaberREF>/Aufzeichnungen/ Safe<N>/ Safe<YYYY>/<MM>


https://<WebserverFQDN>/<lizenzinhaberREF>/Aufzeichnungen/ Safe<N>/ Safe<YYYY>/<MM>/<DD>


https://<WebserverFQDN>/<lizenzinhaberREF>/Aufzeichnungen/ Safe<N>/ Safe<YYYY>/<MM>/<DD>/<lizenzinhaberREF>_<SeqNo>_<YYYMMDD>_<HHMMSS>.zip

ZIP file

5.3 Example

To explain the expected web server behaviour, it can be assumed as an example that a gaming operator, which has been assigned the licence holder ID ACME by the regulatory authority, has set up a web server which can be accessed via the domain name known in the internet www.acme.operator.com. ZIP files are already provided on this server for the first few days of the month of June of 2013. Figure 14 illustrates a view of the folder and file organisation on the intended web server.




Figure 14: Organisation of folders and files of a virtual web server in accordance with the specifications of this directive.

Access to the first ZIP file, which in this example was generated on 03.06.2013, is via the enquiry URI

https://www.acme-operator.com/ACME/Aufzeichnungen/Safe1/2013/06/03/ACME_0000001_20130603_140010.zip

In order to receive the contents lists of a folder, examples of the enquiry URIs used are

https://www.acme-operator.com/ACME/Aufzeichnungen/Safe1/2013/06

and

https://www.acme-operator.com/ACME/Aufzeichnungen/Safe1/2013/06/03

Figures 15 and 16 show representations of the corresponding possible replies in a HTML browser




Figure 15: Possible browser view of the reply of a HTTP(S) Get request method with the URI https://www.acme-

operator.com/ACME/Aufzeichnungen/Safe1/2013/06.

Figure 16: Possible browser view of the reply of a HTTP(S) Get request method with the URI https://www.acme-

operator.com/ACME/Aufzeichnungen/Safe1/2013/06/03.








6. CONTACT OPTIONS

The Ministry of the Interior of the State of Schleswig-Holstein is responsible for this document.

Address:

Innenministerium des Landes Schleswig-Holstein

Referat IV 36

Düsternbrooker Weg 92

24105 Kiel

E-mail address: [email protected]

Internet address: http://schleswig-holstein.de/IM

Internet address of the department: http:///www.schleswig-holstein.de/IM/DE/Service/Gluecksspiel_node.html

Annexe Example Manifest Model (not normative)

<?xml version="1.0" encoding="UTF-8"?> <kontrollManifest xmlns="http://www.schleswig-holstein.de/IM/safesystem-manifestmodell-v2.0.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <lizenzInhaberREF>ACME</lizenzInhaberREF> <erstellungsDatum>2011-12-22T23:58:02Z</erstellungsDatum> <manifestSequenceNumber>1456</manifestSequenceNumber> <metadaten> <anzahlAufzeichnungen>1197</anzahlAufzeichnungen> <ersteAufzeichnung>2011-12-22T23:52:59Z</ersteAufzeichnung> <letzteAufzeichnung>2011-12-22T23:57:59Z</letzteAufzeichnung> <sizeUncompressed>2097014</sizeUncompressed> <sizeCompressed>11241</sizeCompressed> </metadaten> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509SubjectName>CN=Behoerde, OU=Aufsicht, C=DE</ds:X509SubjectName> </ds:X509Data> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>Z3wSdtXI7kpD32EvRtm........ .......1RgkdDtvuHXlc9hCSIm+bQ9yPEeYrO+Mwx76XkA=</xenc:CipherValue>

mailto:[email protected]

http://schleswig-holstein.de/IM

http://www.schleswig-holstein.de/IM/DE/Service/Gluecksspiel_node.html

http://www.schleswig-holstein.de/IM/DE/Service/Gluecksspiel_node.html




</xenc:CipherData> <xenc:CarriedKeyName xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">K1456</xenc:CarriedKeyName> </xenc:EncryptedKey> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="D1456"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>K1456</ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherReference URI="/ACME/Aufzeichnungsdaten/Safe1/2011/12/22/ACME_0001456_20111222_235802.zip/data.bin"/> </xenc:CipherData> </xenc:EncryptedData>




<dsig:Manifest Id="M1456"> <dsig:Reference URI="/ACME/Aufzeichnungsdaten/Safe1/2011/12/22/ACME_0001455_20111222_235302.zip/manifest.xml#M1455"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <dsig:DigestValue>w+7o4caCHF6+N/KFLoC8itsBNhTTIX2BgMOvgI09VUM=</dsig:DigestValue> </dsig:Reference> <dsig:Reference URI="#D1456"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#Binary"/> <dsig:Transform Algorithm="http://www.schleswig-holstein.de/IM/transform/rfc1951#inflate"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <dsig:DigestValue>agD4HdakRr1d3xR/t5YRyS5RstucSCakrWlbvryiJWM=</dsig:DigestValue> </dsig:Reference> </dsig:Manifest> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="xmldsig-bfb45623-1ee0-4dea-9653-431336b90f31"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference Id="xmldsig-bfb45623-1ee0-4dea-9653-431336b90f31-ref0" URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>A1JILr+S3NQ+U4g+syqawwldczrKS6/bqhuQ7i+n02g=</ds:DigestValue> </ds:Reference> <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-bfb45623-1ee0-4dea-9653-431336b90f31-signedprops"> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>b5nRJYkPNwilj9Xn2wnbWu+/8BPnaRBEK2UFYdfV1ug=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue Id="xmldsig-bfb45623-1ee0-4dea-9653-431336b90f31-sigvalue">LEf55eHNn… ………..9atliFsJqcBH5.z5McGVEXd3h0=</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIICbTCCAdqgAwIBAgIQpkK0ls+ItH......1mqdZ99b/MugsaA== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo>




<ds:Object> <xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#xmldsig-bfb45623-1ee0-4dea-9653-431336b90f31"> <xades:SignedProperties Id="xmldsig-bfb45623-1ee0-4dea-9653-431336b90f31-signedprops"> <xades:SignedSignatureProperties> <xades:SigningTime>2011-12-22T23:58:02.963+02:00</xades:SigningTime> <xades:SigningCertificate> <xades:Cert> <xades:CertDigest> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>4btVb5gQ5cdcNhGpvDSWQZabQ… rR9jf1x8e3YF9Ajss=</ds:DigestValue> </xades:CertDigest> <xades:IssuerSerial> <ds:X509IssuerName>CN=Itermediate,O=CA,C=DE</ds:X509IssuerName> <ds:X509SerialNumber>119284162484605703133798696662099777223 </ds:X509SerialNumber> </xades:IssuerSerial> </xades:Cert> </xades:SigningCertificate> </xades:SignedSignatureProperties> </xades:SignedProperties> <xades:UnsignedProperties> <xades:UnsignedSignatureProperties> <xades:SignatureTimeStamp> <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <xades:EncapsulatedTimeStamp>MIIHlgYJKoZIhvcN........…OArP3STt04EwOajC2s= </xades:EncapsulatedTimeStamp> </xades:SignatureTimeStamp> </xades:UnsignedSignatureProperties> </xades:UnsignedProperties> </xades:QualifyingProperties> </ds:Object> </ds:Signature> </kontrollManifest>




Annexe Schema Manifest Model

<?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:afz="http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-aufzeichnungsmodell-v2.0.xsd" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:tns="http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-manifestmodell-v2.0.xsd" targetNamespace="http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-manifestmodell-v2.0.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.0.0"> <import namespace="http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-aufzeichnungsmodell-v2.0.xsd" schemaLocation="safesystem-aufzeichnungsmodell-v2.0.xsd"/> <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/> <import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/> <complexType name="Metadaten"> <sequence> <element name="anzahlAufzeichnungen" type="unsignedInt"/> <element name="ersteAufzeichnung" type="dateTime"/> <element name="letzteAufzeichnung" type="dateTime"/> <element name="sizeUncompressed" type="unsignedInt"/> <element name="sizeCompressed" type="unsignedInt"/> </sequence> </complexType> <element name="kontrollManifest"> <complexType> <sequence> <element name="lizenzInhaberREF" type="afz:SimplerName"/> <element name="erstellungsDatum" type="dateTime"/> <element name="manifestSequenceNumber" type="nonNegativeInteger"/> <element name="metadaten" type="tns:Metadaten"/> <element ref="enc:EncryptedKey" maxOccurs="unbounded"/> <element ref="enc:EncryptedData"/> <element ref="dsig:Manifest"/> <element ref="dsig:Signature" minOccurs="0"/> </sequence> </complexType> </element> </schema

Annexe Schema Data Log Model

<?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:afz="http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-aufzeichnungsmodell-v2.0.xsd" targetNamespace="http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem-aufzeichnungsmodell-v2.0.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.0.0">  <simpleType name="Identifikator"> <annotation> <documentation xml:lang="en">Value for identifiers of entities</documentation> </annotation> <restriction base="token"> <maxLength value="40"/> </restriction> </simpleType> <simpleType name="Text100"> <annotation> <documentation xml:lang="en">String with a maximum length of 100 characters</documentation> </annotation> <restriction base="string"> <maxLength value="100"/> </restriction> </simpleType> <simpleType name="Text256"> <annotation> <documentation xml:lang="en">String with a maximum length of 256 characters</documentation> </annotation> <restriction base="string"> <maxLength value="256"/> </restriction> </simpleType> <simpleType name="Staat"> <annotation> <documentation xml:lang="en">Used for DIN EN ISO 3166-1 (ALPHA-2) </documentation> </annotation> <restriction base="string"> <pattern value="[A-Z]{2}"/> </restriction> </simpleType> <simpleType name="Betragswert"> <restriction base="decimal"> <totalDigits value="11"/> <fractionDigits value="2"/> </restriction> </simpleType> <simpleType name="SimplerName"> <annotation> <documentation xml:lang="en"> Simple names are eventually used to build file names, so there are restrictions to accomodate most file systems. </documentation> </annotation> <restriction base="string"> <maxLength value="50"/> <pattern value="[-_a-zA-Z0-9]+"/> </restriction>

</simpleType>

<simpleType name="Postcode"> <annotation> <documentation> Instance of a postal code system id. </documentation> </annotation> <restriction base="string"> <minLength value="4"/> <maxLength value="10"/> </restriction> </simpleType> <simpleType name="PLZ"> <restriction base="afz:Postcode"> <pattern value="[0-9]{5}"/> </restriction> </simpleType> <simpleType name="Ergebnis"> <annotation> <documentation> Possible values for a result of a bet settlement. </documentation> </annotation> <restriction base="string"> <enumeration value="verloren"/> <enumeration value="gewonnen"/> <enumeration value="annulliert"/> <enumeration value="nicht ausgewertet"/> <enumeration value="offen"/> </restriction> </simpleType>   <complexType name="AdresseNational"> <annotation> <documentation> Postaladdress in germany. </documentation> </annotation> <sequence> <element name="strasse" type="afz:Text100"/> <element name="postcode" type="afz:PLZ"/> <element name="ort" type="afz:Text100"/> </sequence> </complexType> <complexType name="Betrag"> <annotation> <documentation xml:lang="en">currency value</documentation> </annotation> <simpleContent> <extension base="afz:Betragswert"> <attribute name="waehrung" use="optional" default="EUR"> <annotation> <documentation xml:lang="en">ISO 4217 Currency Code</documentation> </annotation> <simpleType> <restriction base="string"> <maxLength value="3"/> <minLength value="3"/>




</restriction> </simpleType> </attribute> </extension> </simpleContent> </complexType> <complexType name="NichtNegativerBetrag"> <annotation> <documentation xml:lang="en">non negative currency values</documentation> </annotation> <simpleContent> <restriction base="afz:Betrag"> <minInclusive value="0"/> </restriction> </simpleContent> </complexType> <complexType name="UnbareTransaktion"> <annotation> <documentation xml:lang="en"> Account movement from (negative amount) or to (positive amount) players virtual account </documentation> </annotation> <sequence> <element name="unbarbetrag" type="afz:Betrag"/> <element name="spielkontostand" type="afz:Betrag"/> </sequence> <attribute name="subkontotyp" default="fernvertrieb"> <simpleType> <restriction base="string"> <enumeration value="fernvertrieb"/> <enumeration value="stationaer"/> <enumeration value="blockiert"/> </restriction> </simpleType> </attribute> </complexType> <complexType name="Transaktion"> <annotation> <documentation xml:lang="en"> Account movement from (negative amount) or to (positive amount) players virtual account, which can also capture cash movements. </documentation> </annotation> <complexContent> <extension base="afz:UnbareTransaktion"> <sequence> <element name="barbetrag" type="afz:Betrag" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <complexType name="BankkontoDigests"> <annotation> <documentation xml:lang="en"> Players bank details </documentation> </annotation> <sequence> <element name="ibanDigest" type="afz:DigestValue"> <annotation>

<documentation xml:lang="en">Digest of ISO 13616 International Bank Account Number</documentation> </annotation> </element> <element name="bicDigest" type="afz:DigestValue"> <annotation> <documentation xml:lang="en">Digest of ISO 9362 Bank Identifier Code</documentation> </annotation> </element> </sequence> </complexType> <complexType name="DigestValue"> <simpleContent> <extension base="base64Binary"> <attribute name="digestMethod" type="string"/> </extension> </simpleContent> </complexType>   <complexType name="Aufzeichnungsgrundinformation"> <sequence> <element name="datenerfassungDatum" type="dateTime"> <annotation> <documentation xml:lang="en"> The date, when the associated, relevant event occured, not the date when the data was stored in the safe-system. </documentation> </annotation> </element> </sequence> <attribute name="aufzeichnungsID" type="afz:Identifikator" use="required"> <annotation> <documentation xml:lang="en"> globally unique ID of record </documentation> </annotation> </attribute> </complexType>   <complexType name="Einzelspielerspiel"> <annotation> <documentation xml:lang="en"> Record of a single player game (e.g slot machine) </documentation> </annotation> <complexContent> <extension base="afz:Aufzeichnungsgrundinformation"> <sequence> <element name="einzelspielerspielID" type="afz:Identifikator"/> <element name="spielerREF" type="afz:Identifikator"/> <element name="spielart"> <simpleType> <restriction base="string"> <enumeration value="Slotgame"/> <enumeration value="Scratchcard"/> <enumeration value="Videopoker"/>




<enumeration value="sonstige"/> </restriction> </simpleType> </element> <element name="spielname" type="afz:Text100"/> <element name="jackpot" type="boolean"/> <element name="gesamteinsatz" type="afz:NichtNegativerBetrag"/> <element name="gesamtgewinn" type="afz:NichtNegativerBetrag" minOccurs="0"/> <element name="jackpotgewinn" type="afz:NichtNegativerBetrag" minOccurs="0"/> <element name="sachgewinne" minOccurs="0"> <complexType> <sequence> <element name="sachgewinnbeschreibung" type="string" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="spielanfang" type="dateTime"/> <element name="spielende" type="dateTime"/> <element name="anzahlSpielrunden" type="positiveInteger"/> <element name="realityChecks"> <complexType> <sequence> <element name="realityCheck" type="dateTime" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="gesamttransaktion" type="afz:UnbareTransaktion"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Gemeinschaftsspiel"> <annotation> <documentation xml:lang="en"> Ring games (e.g poker cashgame) </documentation> </annotation> <complexContent> <extension base="afz:Aufzeichnungsgrundinformation"> <sequence> <element name="gemeinschaftsspielID" type="afz:Identifikator"/> <element name="netzwerkspiel" minOccurs="0"> <complexType> <sequence> <element name="plattformanbieter" type="afz:Text100"/> <element name="netzwerkspielID" type="afz:Text100"/> </sequence> </complexType> </element> <element name="spielart"> <simpleType> <restriction base="string"> <enumeration value="Poker"/> <enumeration value="sonstige"/> </restriction> </simpleType> </element> <element name="spielvariante" type="afz:Text100"/>




<element name="spielanfang" type="dateTime"/> <element name="spielende" type="dateTime"/> <element name="rake"> <complexType> <sequence> <element name="gesamtrake" type="afz:NichtNegativerBetrag"/> <element name="einbehaltenerAnteil" type="afz:NichtNegativerBetrag" minOccurs="0"/> </sequence> </complexType> </element> <element name="spielprotokoll"> <complexType> <sequence> <element name="spieler" minOccurs="2" maxOccurs="unbounded"> <complexType> <choice> <element name="fremderBenutzername" type="afz:Text100"/> <element name="registrierterSpieler"> <complexType> <sequence> <element name="spielerREF" type="afz:Identifikator"/> <element name="einsatz" type="afz:NichtNegativerBetrag"/> <element name="gewinn" type="afz:NichtNegativerBetrag" minOccurs="0"/> <element name="gesamttransaktion" type="afz:UnbareTransaktion" minOccurs="0"/> </sequence> </complexType> </element> </choice> </complexType> </element> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="Spieler"> <annotation> <documentation> Player's registration information </documentation> </annotation> <complexContent> <extension base="afz:Aufzeichnungsgrundinformation"> <sequence> <element name="spielerID" type="afz:Identifikator"/> <element name="vorname" type="afz:Text100"/> <element name="name" type="afz:Text100"/> <element name="geburtsname" type="afz:Text100"/> <element name="geburtsdatum" type="date"/> <element name="geburtsort" type="afz:Text100"/> <element name="wohnsitz"> <complexType> <sequence> <element name="strasse" type="afz:Text100"/> <element name="postcode" type="afz:Postcode"/>




<element name="betrag" type="afz:Betrag"/> <element name="zeitraum"> <simpleType> <restriction base="string"> <enumeration value="Tag"/> <enumeration value="Woche"/> <enumeration value="Monat"/> </restriction> </simpleType> </element> </sequence> </complexType> </element> </sequence> </complexType> </element> <element name="zahlungsweg"> <annotation> <documentation xml:lang="en"> Players generic bank details </documentation> </annotation> <complexType> <choice> <element name="bankkonto" type="afz:BankkontoDigests"/> <element name="kartenzahlung"> <complexType> <sequence> <element name="kartengesellschaft" type="afz:Text100"/> <element name="kartennummerDigest" type="afz:DigestValue"/> <element name="inhabernameDigest" type="afz:DigestValue"/> <element name="referenzbankkonto" type="afz:BankkontoDigests"/> </sequence> </complexType> </element> <element name="sonstigeZahlungsdienste"> <complexType> <sequence> <element name="anbieteridentifikation" type="afz:Text100"/> <element name="kontoidentifikationDigest" type="afz:DigestValue"/> </sequence> </complexType> </element> <element name="ausschliesslichBar"> <simpleType> <restriction base="string"> <length value="0"/> </restriction> </simpleType> </element> </choice> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="SpielunabhaengigeTransaktion"> <annotation> <documentation xml:lang="en">




Account movement from (negative amount) or to (positive amount) players virtual account, triggered by non-playing mechanisms. </documentation> </annotation> <complexContent> <extension base="afz:Aufzeichnungsgrundinformation"> <sequence> <element name="transaktionID" type="afz:Identifikator"/> <element name="spielerREF" type="afz:Identifikator"/> <element name="details" type="afz:Text100"/> <element name="automatischeGewinntransaktion" type="boolean" default="false" minOccurs="0"/> <element name="zeitpunkt" type="dateTime"/> <element name="stationaererVertrieb" type="afz:vertriebsstaette" minOccurs="0"/> <element name="transaktion" type="afz:Transaktion"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Wette"> <sequence> <element name="sportwettbewerb"> <complexType> <sequence> <element name="sportart" type="afz:Text100"/> <element name="veranstaltungsname" type="afz:Text256"/> <element name="austragungsdatum" type="date"/> </sequence> </complexType> </element> <element name="ereignis" type="afz:Text256"/> <element name="handicap" type="boolean" default="false" minOccurs="0"/> <element name="quote" type="decimal"/> <element name="liveWette" type="boolean" default="false" minOccurs="0"/> </sequence> </complexType> <complexType name="Subwette"> <complexContent> <extension base="afz:Wette"> <attribute name="sequenzID" type="positiveInteger" use="required"/> </extension> </complexContent> </complexType> <complexType name="Kombiwette"> <sequence> <element name="wette" type="afz:Subwette" minOccurs="2" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="Systemwette"> <sequence> <element name="wette" type="afz:Subwette" minOccurs="2" maxOccurs="unbounded"/> </sequence> <attribute name="tipps" type="positiveInteger" use="required"/> </complexType> <complexType name="vertriebsstaette"> <sequence> <element name="vertriebsstaettenname" type="afz:Text100"/> <element name="adresse" type="afz:AdresseNational"/> </sequence> </complexType>




<complexType name="Wettabschluss"> <annotation> <documentation xml:lang="en"> Bet placement Natural key: wettIdentifikation </documentation> </annotation> <complexContent> <extension base="afz:Aufzeichnungsgrundinformation"> <sequence> <element name="wettabschlussID" type="afz:Identifikator"/> <element name="wettscheinID" type="afz:Identifikator" minOccurs="0"/> <element name="spielerREF" type="afz:Identifikator"/> <element name="bewettetesEreignis"> <complexType> <choice> <element name="einzelwette" type="afz:Wette"/> <element name="kombiwette" type="afz:Kombiwette"/> <element name="systemwette" type="afz:Systemwette"/> </choice> </complexType> </element> <element name="stationaererVertrieb" type="afz:vertriebsstaette" minOccurs="0"/> <element name="datum" type="dateTime"/> <element name="einsatztransaktion" type="afz:Transaktion"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Wettergebnis"> <annotation> <documentation xml:lang="en"> Bet settlement / resettlement </documentation> </annotation> <complexContent> <extension base="afz:Aufzeichnungsgrundinformation"> <sequence> <element name="wettergebnisID" type="afz:Identifikator"/> <element name="wettabschlussREF" type="afz:Identifikator"/> <element name="ergebnis" type="afz:Ergebnis"/> <element name="annullierungsdetail" type="afz:Text100" minOccurs="0"/> <element name="einzelwettenergebnisse" minOccurs="0"> <complexType> <sequence> <element name="ergebnis" minOccurs="2" maxOccurs="unbounded"> <complexType> <simpleContent> <extension base="afz:Ergebnis"> <attribute name="sequenzREF" type="positiveInteger" use="required"/> </extension> </simpleContent> </complexType> </element> <element name="annullierungsdetail" minOccurs="0" maxOccurs="unbounded"> <complexType> <simpleContent>

<extension base="afz:Text100">

<attribute name="sequenzREF" type="positiveInteger" use="required"/> </extension> </simpleContent> </complexType> </element> </sequence> </complexType> </element> <element name="datum" type="dateTime"/> <element name="gewinntransaktion" type="afz:UnbareTransaktion" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>   <element name="aufzeichnungen"> <annotation> <documentation xml:lang="en"> Container data element for gathering data records </documentation> </annotation> <complexType> <sequence minOccurs="0" maxOccurs="unbounded"> <choice> <element name="spieler" type="afz:Spieler"/> <element name="einzelspielerspiel" type="afz:Einzelspielerspiel"/> <element name="gemeinschaftsspiel" type="afz:Gemeinschaftsspiel"/> <element name="wettabschluss" type="afz:Wettabschluss"/> <element name="wettergebnis" type="afz:Wettergebnis"/> <element name="wettergebniskorrektur" type="afz:Wettergebniskorrektur"/> <element name="spielunabhaengigeTransaktion" type="afz:SpielunabhaengigeTransaktion"/> </choice> </sequence> <attribute name="lizenzinhaberREF" type="afz:SimplerName" use="required"/> </complexType> <key name="SpielerIDConstraint"> <selector xpath="aufzeichnungen/spieler"/> <field xpath="spielerID"/> </key> <key name="EinzelspielerspielIDConstraint"> <selector xpath="aufzeichnungen/einzelspielerspiel"/> <field xpath="einzelspielerspielID"/> </key> <key name="GemeinschaftsspielIDConstraint"> <selector xpath="aufzeichnungen/gemeinschaftsspiel"/> <field xpath="gemeinschaftsspielID"/> </key> <key name="WettabschlussIDConstraint"> <selector xpath="aufzeichnungen/wettabschluss"/> <field xpath="wettabschlussID"/> </key> <key name="WettergebnisIDConstraint"> <selector xpath="aufzeichnungen/wettergebnis"/> <field xpath="wettergebnisID"/> </key> <key name="WettergebniskorrekturIDConstraint">

<selector xpath="aufzeichnungen/wettergebniskorrektur"/> <field xpath="wettergebnisID"/> </key> <key name="SpielunabhaengigeTransaktionIDConstraint"> <selector xpath="aufzeichnungen/spielunabhaengigeTransaktion"/> <field xpath="transaktionID"/> </key> </element> <complexType name="Wettergebniskorrektur"> <annotation> <documentation xml:lang="en"> Bet resettlement </documentation> </annotation> <complexContent> <extension base="afz:Wettergebnis"> <sequence> <element name="details" type="afz:Text100"/> <element name="gewinnstornierung" type="afz:UnbareTransaktion" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>  </schema>

technical directive for online gaming in schleswig holstein v2.0_2013_english version

Technology