Chapter 1	Scope of application
Chapter 2	Information for the player
Chapter 3	Bonus
Chapter 4	Playing games and so on.
Chapter 5	Wasting systems
Chapter 6	Crow
Chapter 7	Supervision
Chapter 8	Punishment
Chapter 9	Entry into force
Appendix 1

Publication on land-based wager 1)

In accordance with section 11 (4), 4, section 36, paragraph. 2, section 41, paragraph. 1, and § 60 of Law No 848 of 1. July 2010 on gambling, and section 17 (3). 2, section 19 and section 46 of the Act 223 of 22. March 2011, for Greenland, on certain games :

Chapter 1

Scope of application

§ 1. The notice shall apply to the provision of land-based betting, cf. Act on Act 11 and Law for Greenland on certain games of paragraph 7.

Paragraph 2. Permissions for tenders as referred to in the Act on Act, Section 42 (2), shall be authorised. 5, and in the law of Greenland, on certain gambling sections 8 (3). 1 shall not be subject to the notice.

Chapter 2

Information for the player

§ 2. All information which the holder of authorisation is obliged to make available to the player according to the rules laid down in law on gambling or the law of Greenland on certain games and related regulations should be available in Danish on the point of sale. All other communication between players and the authorisation holder must be able to be done in Danish.

Paragraph 2. An authorisation holder authorised to play the game in Greenland shall provide information as provided for in paragraph 1. 1 in Danish and Greenlandic.

§ 3. The sales place must :

1) The record show that it is not permitted for persons under the age of 18 to participate in the games.

2) It is informed of responsible gambling and the potential harmful effects of gambling. The information must be drawn up in cooperation with a treatment centre.

3) Information on and contact addresses of Danish treatment centers is communicated.

Paragraph 2. The information provided for in paragraph 1 1 must be positioned in a prominent place at the point of sale.

Paragraph 3. An authorisation holder authorised to play the game in Greenland shall communicate information as referred to in paragraph 1. 1 in Danish and Greenlandic and information on the contact addresses of Greenland treatment centres.

§ 4. The sales site must indicate that authorisation holder has permission from and is under the supervision of the Fiddle-up Authority.

§ 5. The authorisation holder shall take measures to prevent the placing on the market of players which have ruled out themselves from participating in the temporary or final event.

Chapter 3

Bonus

§ 6. If the consent holder offers the player a bonus for participating in the game, all terms must be provided in a clear and clear way in immediate attachment to the offering. Payment of a bonus for the player must take place without further notice when the terms and conditions are met.

Paragraph 2. Bonus must not be given to individual players on terms that differ from tender given to other players.

Paragraph 3. The gambler must have at least 60 days to meet any terms associated with the payment of a bonus.

Chapter 4

Playing games and so on.

§ 7. The authorisation holder shall take measures suitable to reduce the risk of an agreed game ("match-are") In the pool of bets and shall refuse the reception of efforts to be wager, where there is a reasonable suspicion of a fixed game.

§ 8. Permission holders must not offer betting on sports events for young people under the age of 18.

Chapter 5

Wasting systems

§ 9. Permission holder shall comply with the technical requirements of the control system and the system of the game system resulting from Annex 1.

§ 10. The gaming system, which means IT equipment used for the provision of bets, cf. Annex 1 shall be located here in the country.

Paragraph 2. The competition authority may approve the requirement set out in paragraph 1. 1 shall be devised if the holder of the consent shall :

1) has permission to supply games in another country where a public authority supervises the recording of authorisations holder, and this supervisory authority has concluded an agreement with the Member State of the Management of Authorisation of the Authorisation of Authorisation of the Authorisation of the Authorisation of Authorisation ; in the country, or

2) may provide the Bureau of the Games to control the waste system by means of a remote access or similar system.

§ 11. Permission holder's system, business and business systems must be certified by an accredited test facility before the gaming system is used for the supply of bets. The competition authority may lay down requirements for certification.

Paragraph 2. The game authority may lay down requirements for the accreditation of the test establishments.

§ 12. When a system is certified, the game authority may, at any time, order the authorisation holder to carry out further tests, verification and certification of the system.

§ 13. Permission holder shall keep all data on the supply of betting in the game system for at least five years.

Chapter 6

Crow

§ 14. Permission holders shall deal with complaints from players concerning the authorisation of the authorisation holder of the game. A complaint shall contain information on the identity of the player and the reasons for the complainal. The complaint may be rejected if the requirements are not met.

Paragraph 2. Permission holder shall process the complaint as soon as possible. If the complaint matter is not settled within 14 days, the authorisation holder must inform the gambler of when this may expect a decision on the matter.

Paragraph 3. Permission holder shall keep documents covered by complaints, including documents in cases of rejected complaints, at least two years. On request, these shall be forwarded to the Fishing Authority.

Chapter 7

Supervision

§ 15. The game authority shall monitor compliance with this notice, cf. Chapter 9 of the Act and Chapter 6 of the Law of Greenland on Certain Plays.

Chapter 8

Punishment

§ 16. Unless higher penalties have been imposed on other legislation, penalties shall be punished by fine, which is intentionally or gross negligent, § § 2-6, section 8-10, section 11, paragraph 11. ONE, ONE. pkt., section 12, sections 13 and section 14 (4). ONE, ONE. Act. and paragraph 3.

Paragraph 2. Companies can be imposed on companies, etc. (legal persons) punishable by the rules of Chapter 5 of the penal code.

Chapter 9

Entry into force

§ 17. The announcement shall enter into force on 1. -February 2012.

---

Appendix 1

Technical requirements for the permission holders

A. Introduction

This document describes the technical requirements to be met by an authorisation holder, including safeguard of data basis for control, and requirements for accessibility, internal controls, business and organization.

B. abbreviations and definitions

C. Total System Complex to Use

The total system complex consists of the permission holder's system, the data memory of the allowable holder (SAFE) and a security system (Tamper Token).

1. SAFE is the permission number of the permission holder (a file server) to store the recording of the game data according to Standard Records-for all games performed at the authorisation holder. All permission indexes must establish a data store (SAFE). The game authority shall be able to obtain on-line access to the data memory of the permission holder of the consent holder.

2. Token up. The game authority implements a security system that will be used for the Token Token. Tamper Token is designed to ensure that the game data that the permissions holder hides on SAFE in the form of Standard Records is not changed while they are stored on SAFE. The game authority shall draw up a server for the issue of token issued on a daily basis to the authorisation holder. The frequency of the frequency can be regulated by a practical assessment. Permit holder must implement a function that follows the Specifications of the game authority to generate an identification code based on the stored data and the issued token. The identification code must be reported back to the game authority prior to the expiry of that token. Permit Index of Permit Allowed by Tamper Token is taking place via web services.

By the way, Token with the Fiddleboard handles all the following :

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

• Storage of identification codes for subsequent verification.

• Ongoing check that the time period for the completion of tokens is being checked.

• Verification that a retrieved series of game data has not been changed in relation to the identification code received.

It is a requirement that the permission holder can handle a changed token frequency when issuing a new token.

Permission holder shall inform the game board of errors on the Token Token as soon as possible.

D. Plain Data Requirements (Standard Records)

The permission holder must store the game data on SAFE in XML files with fields and with a frequency that the Fishing Authority will publish. The following division shall be operated on :

• EndOfDay

• Pool Play

• FastOdds

• Managergames

• Jackpot

For game types that fall outside the above-mentioned division, the game authority is agreed with the game authority how to save the game data on SAFE. This must be carried out in advance of the supply of gambling.

The game authority shall publish a technical description of the format in which the data for SAFE is to be sent (Standard Records). The technical description contains the conceptual model and field definitions. The description includes a group of XSD files whose structure is to be observed when saving the game data on SAFE.

E. Requirements for SAFE

E. 1 Permit Index Data Storage

Permission holder must establish a data store (SAFE) for the retention of the game data.

Permit holder must transfer and save the game data according to Standard Records on the data store. Permission holder shall keep recording of the game data on SAFE for the last 12 months, and retain the recording of the waste data from an additional 48 months on a digital readable medium.

Data transfer between the authorisation holder SAFE and the control system of the game authority shall be carried out via the Internet with FTPS with a minimum speed of 8 Mbit / s. Permission holder shall ensure that the connection is appropriate for an unproblematic transfer of the game data.

E. 1.1 Technical Requirements for SAFE

• SAFE must be established on a separate server that is physically separated from the system of authorisation-holder's system.

• The game data on SAFE must be segregated logically and defensible from any other data.

• The authorisation holder shall provide for the necessary backup of all the data. SAFE and backup of SAFE must be geographically separate. Similarly, data retention on digitally readable media must be geographically separated from the backup of the same.

• SAFE must, before it is applied to data store, meet IT security requirements at a minimum level of equivalent level as the permit holder's game system, in accordance with the notice of land-based wager.

• Permission holder shall ensure that the Fiddler has on-line access to retrieve the game data from SAFE.

• Permit holder must establish access to SAFE via secure access (FTPS).

• The structure of the SAFE must be built up in accordance with the structure specified in the Fiddler. section E. 3 "Folder structure on SAFE and naming Standard Records".

• The game data on SAFE must be stored according to the specified Standard Records, cf. section D "Plain data requirements (Standard Records)".

• Permission holder must document that SAFE complies with the specified requirements.

• The authorisation holder shall prepare operational documentation for SAFE, including documentation of the necessary operating environment, operating procedure and routines, backup systems and error handling.

• All documentation must be provided in Danish. However, technical specifications of a general nature may be provided in English.

• The documentation must be made available electronically (e.g. per the per. E-mail, USB, CD rum, DVD) for the Games Authority without delay and never later than 2 business days.

• All documentation must be provided in a format that can be handled by the VP, and can be read in Microsoft Office or Adobe Reader.

• The documentation must be updated continuously and at least at each release. The documentation that describes the basis for the release must be updated for each release.

• SAFE availability per month :

• SAFE service windows :

• Incidents (events) :

The authorisation holder shall report incidents via the incident reporting system in the game authority. The requirements and information about this will be published on the Home Office's website.

• Permit holder is responsible for the operation of SAFE.

• If SAFE is inaccessible, the gaming data must be collected and saved on SAFE after completion of the inaccessibility period.

E. 2 Transfer of the game system data to SAFE

Permit holder must transfer and store the game data on SAFE according to Standard Records (info concerning. data structures). It is the responsibility and responsibility of the authorisation holder to ensure that this data transfer is transferred.

The game authority shall be able to transmit the game data as needed from SAFE to the Data Store's own data store for inspection purposes. The transfer takes place via the Internet with FTPS, and the validity of the data is checked with the Token Token.

E. 3 Folder structure on SAFE and naming Standard Records

Permit holder must build the folder structure on SAFE and name Standard Records based on the following structure :

Level 1 : The outer folder is named "Folderstructure waste system".

Level 2 : Folder that is named "Zip".

Level 3 : Folders are created for each day named after the date in YYYY-MM-DD format.

Level 4 : Here, zip files will be located each assigns to one token. In addition, there must be folders for the tokens that are not yet closed. A folder that is not yet closed is named "SpilkatIdencation-TamperTokenID". Zip file containing the folder is named

"Wasting-Identification-TamperTokenID.zip". The certificate identification is a unique identification of the holder of the authorisation holder, which the Fiddler will assign. TamperTokenID is a unique identification of the individual Tamper Token.

Level 5 : Folders are created in accordance with the contents of each zip file. They are named "EndOfDay", "FastOdds", "Jackpot", "Pool Game", and "ManagerGames."

Level 6 : Folders will be created for the relevant dates, named after the date in YYYY-MM-DD format. The individual Standard records are placed at this level or level 7 and placed in the folder that match the time the file is created.

Level 7 : [ Optional ] There is the option to specify subfolders with time intervals in the format HH. MM-HH. MM.

Pool pool files must be placed in the folder that represents the location of the wager.

In relation to all other types of game, the files must be placed in the folder where they are expected to be ended.

The names of folders and Standard Records must follow the Specifications of the game authority.

The game data must be continuously zipped as specified in the folder structure and a zip file must be created for each Tamper Token key. Each zip file must contain just the game data that is packaged with the associated Tamper Token key.

For the provision of compliance with the authorisation requirements,

F. 1 Requestation of the game data

Permit holder must be able to provide archived gaming data from digitally readable medie, cf. Section E 1 to the Fiddleball Authority within 5 business days.

F. 2 Request other information

In addition to the amount of waste referred to in Section E 1, the permission holder must be able to generate information from its waste system and, if necessary, by the authorisation holder. associated systems, including :

• Information about gambling accounts.

• Statistical information.

• Extract of actual registrations on the system permission-holder's system.

This information must be provided to the game authority within 5 business days.

G. Requirements for the licensing index controls, business and organization requirements

The authorisation holder shall prepare, document and carry out ongoing checks on whether the applicable requirements of the notice are continually adhering to both the authorisation holder and its partner. These shall include at least :

• Daily check exercised by employees and managers (as far as possible in business and systems).

• Periodically, as well as random internal audits.

• External audits when this may be required in order to obtain a satisfactory level of documentation for compliance with the applicable requirements.

• Treatment and archiving of the results of the check.

• Immediate reporting to the game authority in the detection of errors or infringements, as well as suspicion of failure or violation of the authorizing holder and / or by its partner. The reporting shall include the appraisal of the consequences of the failure or the offence.

The authorisation holder shall be responsible for the preparation, document and follow of relevant business practices designed to support and ensure that both the authorisation holder and its possible partners continue to comply with the applicable requirements in : The announcement. The business corridors shall include at least :

• Permission holder shall ensure monitoring of all components and data transmissions in the total system, including data lines, data packs, networks, SAFE, RNG, waste system, etc. (including components and data transmissions in any other way. involved third parties, in order to ensure both reliability and availability.

• Permission holder ensures a backup and restore procedure for the response to data loss.

• Permission holder shall ensure maintenance and safety procedures for safe and stable operation in accordance with ISO 27001.

The authorisation holder shall be appropriately organised and sufficiently manned in order to tender its products in accordance with the purpose of the Act of Act, as well as with the requirements laid down by the Fiction Authority.

In addition to the role and person-related requirements which the law provides for the granting of authorisation, the authorisation holder must at least create the following organisational roles :

• Responsible for gaming software and the operation of games ; including ensuring that all the games are built and executed correctly and reliable without errors and deception at the authorisation holder and any other partners.

• Responsible for IT security, including ensuring that all IT hardware, software and networks used by the authorisation holder (and the allowable holder of the permission index (s), if any partners), operate in security terms.

• Responsible for system changes cf. The programme management program for the management of system changes.

• Responsible for the economy, including ensuring that SKAT is always receiving the correct share of the gross gaming income.

The authorisation holder shall inform the game authority of who is in conflict with the responsibilities.

The responsible people must possess the necessary skills and the necessary experience in order to be able to assume the role and responsibility. The holder of the authorisation shall ensure that the persons have the power to establish measures and to implement necessary changes to ensure that the authorisation holder complies with the required requirements.

In the case of checks, those responsible will be direct contact points. Therefore, people must always be able to provide and provide an explanation of all the information and documentation that the Fiddledo may require in the respective fields.

1) The announcement has, as a draft, been notified in accordance with Directive 98 /34/EC of the European Parliament and of the Council of 22. In June 1998, an information procedure with regard to technical standards and regulations as amended by Directive 98 /48/EC.