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

Technical Directive for Online Gaming in Schleswig-Holstein
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.h
tml
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/veroeffentlic
hteTestateundSelbsterklaerung/testate.html
4https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/Veroeffentlichungen/ISO
27001Auditoren/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/Aufsichtund
AkkreditierungsvonAnbietern/ZertifizierungsDiensteAnbietr node.html
9http://www.bundesnetzagentur.de/cln 1912/DE/Service-
Funktionen/Qualifizierteelektronische/Signatur/WelcheAufgabenhatdieBundesnetzagenturGeeigneteAl
gorithmrnfestlegen/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.

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
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
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: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:inhabernam
eDigest [mandatory]
Full name which appears on the card. To create the hash value, the details of
/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:sonstigeZahlungsdienste/afz:anbieteridenti
fikation [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:kontoidentifik
ationDigest [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: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:fremderBenutzerna
me [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:sportwettbew
erb [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
erb/afz:sportart [mandatory]
Official name of the type of sport, in the framework of which the betting is completed.
erb/afz:veranstaltungsname [mandatory]
Official name of the sporting event, in the framework of which the betting is completed.
erb/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/af
z: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:s
wquenzID [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:sequenzR
EF [2..*]
Identifier (numbering) of the referenced individual bet in accordance with
/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette/@af
z:sequenzID or
/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette/@a
fz: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:s
equenzREF [mandatory]
Identifier (numbering) of the referenced (individual) bet in accordance with
/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette/@af
z:sequenzID or
/afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette/@a
fz: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]
4.1.6.
/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]
4.1.6.
/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]
4.1.6.

/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:lizenzInhaberIdtns:
tns:erstellungsDatumtns:
tns:manifestSequenceNumbertns:
tns:InhaltZfg
tns:inhaltZfgtns:
tns:anzahlAufzeichnungentns:
tns:ersteAufzeichnungtns:
tns:letzteAufzeichnungtns:
tns:sizeUncompressedtns:
tns:sizeCompressedtns:
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>

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

Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version

Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version

Recomendados

Recomendados

Más contenido relacionado

Similar a Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version

Similar a Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version (20)

Más de Market Engel SAS

Más de Market Engel SAS (20)

Último

Último (20)

Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version