ANJ, décision n°2021-030 du 21 janvier 2021

ANJ 21 janvier 2021

Arguments

Le contenu a été généré à l’aide de l’intelligence artificielle. Pensez à vérifier son exactitude.

Signaler une erreur.

Accepté
Respect des obligations légales et réglementaires
La cour a constaté que les exigences techniques établies par l'ANJ sont conformes aux dispositions légales en vigueur et nécessaires pour garantir la protection des données des joueurs.

Commentaire • 0

Augmentez la visibilité de votre blog juridique : vos commentaires d’arrêts peuvent très simplement apparaitre sur toutes les décisions concernées.

Sur la décision

Référence :	ANJ, 21 janv. 2021
Télécharger le PDF original fourni par la juridiction

Texte intégral

Décision publiée sur le site de l’ANJ le 22 janvier 2021

Article 5 : Le directeur général de l’Autorité nationale des jeux est chargé de l’exécution de la présente décision.
Fait à Paris, le 21 janvier 2021.
La Présidente de l’Autorité nationale des jeux
I. FALQUE-PIERROTIN

RÉPUBLIQUE FRANÇAISE
EXIGENCES TECHNIQUES RELATIVES
A LA MISE A DISPOSITION DES DONNEES
EN APPLICATION DES ARTICLES 31 ET 38 DE LA LOI DU 12 MAI 2010
Décision n°2021-030 du Collège de l’ANJ en date du 21 janvier 2021
Résumé Conformément à l’article 32 du décret n°2010-518 dans sa version applicable à compter du 1er octobre 2020, qui prévoit que le Collège de l’ANJ détermine les exigences techniques nécessaires à son application, ce document précise les exigences techniques relatives tant à l’architecture des systèmes d’information qu’au format et au contenu des données concernées
1/202

2/202

Table des matières
I EXIGENCES TECHNIQUES RELATIVES AU SUPPORT MATERIEL D’ARCHIVAGE 6
I.1 Présentation générale et rappel des textes applicables 6 I.1.1 Rappel des obligations légales et règlementaires 6 I.1.2 Glossaire 7
I.2 Exigences générales 8 I.2.1 Gouvernance 8 I.2.2 Politique de contrôle d’accès 8 I.2.3 Chiffrement 9 I.2.4 Durcissement 10
I.3 Exigences en matière d’architecture et de fonctions 10 I.3.1 Principe de recueil 10 I.3.2 Fonction de création et de collecte de traces 11 I.3.3 Fonction d’interconnexion sécurisée 11 I.3.4 Fonction de contrôle d’accès 11 I.3.5 Fonction d’administration 12 I.3.6 Fonction de Stockage et d’archivage 13
I.4 Exigences relatives à l’accès aux données par les agents de l’ANJ 14 I.4.1 Exigences générales 14 I.4.2 Accès à distance 15 I.4.3 Saisie des données sur site 16
II EXIGENCES TECHNIQUES RELATIVES AUX DONNEES MISES A LA DISPOSITION DE L’ANJ SELON LES MODALITES PREVUES A L’ARTICLE 31 DE LA LOI DU 12 MAI 2010 17
II.1 Exigences communes 17 II.1.1 Instant de capture 17 II.1.2 Chaînage 18 II.1.3 Traitement par évènement unitaire ou par lot 19 II.1.4 Création d’enregistrement : chronologie des actions 21 II.1.5 Conventions d’écriture 21 II.1.6 Format des données de validation 22
II.2 Description de l’entête 23 II.2.1 Evènements du compte joueur et l’activité de jeu 23 II.2.2 Evènements d’identification des points de vente 25
II.3 Liste des types de données de jeu par famille 27 II.3.1 Compte joueur (CJ) 28 II.3.2 Identification des points de vente 28 II.3.3 Paris sportifs 29 II.3.4 Paris hippiques 29 II.3.5 Poker 29 II.3.6 Loterie 29
II.4 Évènements relatifs au fonctionnement du compte joueur 30 II.4.1 Ouverture de comptes 30 II.4.2 Modérateurs et seuil de reversement – PREFCPTE 37 II.4.3 Confirmation de l’identité du joueur – CPTEIDENTITE 40 II.4.4 Confirmation de l’adresse – CPTEADRESSE 42 II.4.5 Confirmation du compte – OUVOKCONFIRME 43 II.4.6 Références du compte de paiement – CPTEREF 44
3/202

II.4.7 Refus d’accès – ACCESREFUSE 46 II.4.8 Modification du compte joueur 47 II.4.9 Déclaration d’auto-interdiction du joueur – AUTOINTERDICTION 49 II.4.10 Limitation des mises d’un joueur – LIMITIMISE 51 II.4.11 Clôture du compte joueur – CLOTUREDEM 52 II.4.12 Alimentation et retrait sur le compte du joueur 54 II.4.13 Attribution de lots en nature – LOTNATURE 63 II.4.14 Ajustement – CPTEAJUSTOPE 64
II.5 Identification des points de vente permettant la prise de jeu sur compte 66 II.5.1 Ouverture d’un point de vente à la prise de jeu sur compte – OUVPOINTDEVENTE 66 II.5.2 Modification des informations relatives à un point de vente ouvert à la prise de jeu sur compte – MODIFPOINTDEVENTE 68 II.5.3 Clôture d’un point de vente au jeu sur compte – CLOTUREPOINTDEVENTE 69
II.6 Activité de jeu 70 II.6.1 Pari sportif 70 II.6.2 Pari hippique 95 II.6.3 Poker 103 II.6.4 Loterie 121
III EXIGENCES TECHNIQUES RELATIVES AUX DONNEES MISES A LA DISPOSITION DE L’ANJ DE FAÇON PERIODIQUE OU A LA DEMANDE 136
III.1 Caractéristiques techniques générales du service 136
III.2 Format des données et conventions de nommage 138 III.2.1 Généralités 138 III.2.2 Précisions 138
IV ANNEXES 140
IV.1 Exemples relatifs à l’utilisation de la balise 140
IV.2 Exemples relatifs aux évènements de fonctionnement du compte joueur 144 IV.2.1 Informations personnelles – OUVINFOPERSO 144 IV.2.2 Acceptation des conditions générales du site – OKCONDGENE 144 IV.2.3 Modérateurs et seuil de reversement – PREFCPTE 145 IV.2.4 Confirmation de l’identité du joueur – CPTEIDENTITE 145 IV.2.5 Confirmation de l’adresse – CPTEADRESSE 145 IV.2.6 Confirmation du compte – OUVOKCONFIRME 147 IV.2.7 Références du compte de paiement – CPTEREF 147 IV.2.8 Refus d’accès – ACCESREFUSE 148 IV.2.9 Rectification des informations personnelles – MODIFINFOPERSO 149 IV.2.10 Déclaration d’auto-interdiction du joueur – AUTOINTERDICTION 149 IV.2.11 Déclaration de limitation du joueur – LIMITMISE 150 IV.2.12 Clôture du compte joueur – CLOTUREDEM 151 IV.2.13 Alimentation du compte joueur – CPTEALIM 151 IV.2.14 Retrait du compte joueur – CPTERETRAIT 151 IV.2.15 Abondement du compartiment solde – CPTEABOND 152 IV.2.16 Abondement du compartiment bonus – CPTEALIMOPE 152 IV.2.17 Attribution de lots en nature – LOTNATURE 153 IV.2.18 Ajustement – CPTEAJUSTOPE 153
IV.3 Exemples relatifs aux évènements d’identification des points de vente permettant la prise de jeu sur compte 155 IV.3.1 Ouverture d’un point de vente à la prise de jeu sur compte – OUVPOINTDEVENTE 155
4/202

IV.3.2 Modification des informations relatives à un point de vente ouvert à la prise de jeu sur compte – MODIFPOINTDEVENTE 155 IV.3.3 Clôture d’un point de vente au jeu sur compte – CLOTUREPOINTDEVENTE 155
IV.4 Exemples relatifs aux évènements des paris sportifs 156 IV.4.1 Mise sur un pari – PASPMISE 156 IV.4.2 Gain sur un pari – PASPGAIN 170 IV.4.3 Annulation d’un pari – PASPANNUL 176 IV.4.4 Cas particulier de la « Fantasy league » 178
IV.5 Exemples relatifs aux évènements des paris hippiques 184 IV.5.1 Mise sur un pari – PAHIMISE 184 IV.5.2 Gain sur un pari – PAHIGAIN 188 IV.5.3 Annulation d’un pari – PAHIANNUL 189
IV.6 Exemples relatifs aux évènements du poker 190 IV.6.1 Inscription d’un participant à un jeu de cercle – POINSCRIT 190 IV.6.2 Déroulement d’une partie lors d’un jeu de cercle – POJEU 190 IV.6.3 Bilan financier d’un jeu de cercle – POBILAN 194 IV.6.4 Achat en cours de jeu – POACHAT 194 IV.6.5 Gain en cours de jeu – POGAIN 195 IV.6.6 Annulation d’une participation – POANNUL 195
IV.7 Exemples relatifs aux évènements des jeux de loterie et instantanés 196 IV.7.1 Mise sur un jeu de tirage – LOTIMISE 196 IV.7.2 Gain sur un jeu de tirage – LOTIGAIN 197 IV.7.3 Bilan sur un jeu de tirage – LOTIBILAN 198 IV.7.4 Annulation sur un jeu de tirage – LOTIANNUL 199 IV.7.5 Mise sur un jeu instantané– LOJIMISE 199 IV.7.6 Gain sur un jeu instantané– LOJIGAIN 200 IV.7.7 Bilan sur un jeu instantané– LOJIBILAN 201 IV.7.8 Annulation sur un jeu instantané– LOJIANNUL 201

5/202

I Exigences techniques relatives au support matériel d’archivage I.1 Présentation générale et rappel des textes applicables
Ce chapitre a pour objectif de définir les exigences relatives au support matériel d’archivage (ci-après SMA) prévu à l’article 31 de la loi n°2010-476 du 12 mai 2010.
I.1.1 Rappel des obligations légales et règlementaires
Loi du 12 mai 2010.
Article 31 : L’opérateur de jeux ou de paris en ligne titulaire de l’agrément prévu à l’article 21 est tenu de procéder à l’archivage en temps réel, sur un support matériel situé en France métropolitaine, de l’intégralité des données mentionnées aux 1° à 3° de l’article 38. L’ensemble des données échangées entre le joueur et l’opérateur transitent par ce support. L’obligation d’archivage prévue au premier alinéa s’applique à compter du 1er juillet 2015 s’agissant des données portant sur les références du compte de paiement mentionnées au 2° du même article 38.
Article 38 : I.- Un contrôle permanent de l’activité des opérateurs de jeux ou de paris en ligne agréés et de l’activité de l’opérateur titulaire de droits exclusifs pour son activité de jeux de loterie en ligne est réalisé par l’Autorité nationale des jeux aux fins d’assurer le respect des objectifs définis à l’article L. 320-3 du code de la sécurité intérieure. […] Un décret en Conseil d’Etat, pris après avis de la Commission nationale de l’informatique et des libertés, précise la liste des données que les opérateurs de jeux ou de paris en ligne et la société titulaire des droits exclusifs mentionnée à l’article 137 de la loi n° 2019-486 du 22 mai 2019 précitée sont tenus de mettre à la disposition de l’Autorité nationale des jeux. Il précise les modalités techniques de stockage et de transmission de ces données, le délai pendant lequel l’opérateur est tenu de les archiver, ainsi que les modalités des contrôles réalisés par l’Autorité nationale des jeux à partir de ces données. II.- Un contrôle de l’activité des opérateurs titulaires de droits exclusifs au titre de leur activité en réseau physique de distribution est réalisé par l’Autorité nationale des jeux aux fins d’assurer le respect des objectifs de la politique des jeux définis à l’article L. 320-3 du code de la sécurité intérieure. […]
Code de la sécurité intérieure : Article L 320-18 : Les dispositions des articles 18 à 20 et 31 de la loi n° 2010-476 du 12 mai 2010 relative à l’ouverture à la concurrence et à la régulation du secteur des jeux d’argent et de hasard en ligne s’appliquent à l’activité de la personne morale unique mentionnée à l’article 137 de la loi n° 2019-486 du 22 mai 2019 précitée pour l’exploitation des jeux de loterie en ligne ainsi que pour l’exploitation des jeux de loterie et de paris hippiques sur compte en réseau physique de distribution. Elles s’appliquent également au groupement d’intérêt économique Pari mutuel urbain pour son activité de paris hippiques sur compte en réseau physique de distribution.
Décret n°2010-518 Article 23 : Au sens du présent chapitre :
1° Les données tracées s’entendent des données électroniques échangées entre chaque joueur et l’opérateur qui doivent être conservées dans le support matériel d’archivage, en application de l’article 31 de la loi du 12 mai 2010 susvisée et de l’article L. 320-18 du code de la sécurité intérieure ;
2° Le support matériel d’archivage s’entend du dispositif technique, tel que mentionné à l’article 31 de la loi du 12 mai 2010 susvisée, mis en place pour recueillir, mettre en forme et conserver les données tracées ; il est composé d’un capteur et d’un coffre-fort ; le capteur s’entend de la partie du support matériel d’archivage dédiée à la fonction de recueil et de mise en forme des données tracées ; le coffre-fort s’entend de la partie du support matériel d’archivage dédiée à la fonction de sécurisation et de conservation de ces données ; 3° La plate-forme s’entend du système d’information de l’opérateur contenant notamment les informations personnelles liées au joueur et le logiciel de jeu. Article 24 : Avant toute activité de jeu ou de pari, l’opérateur de jeu en ligne agréé en application de l’article 21 de la loi du 12 mai 2010 susvisée ou les opérateurs mentionnés à l’article L. 320-18 du code de la sécurité intérieure déclarent
6/202

auprès de l’Autorité nationale des jeux la mise en fonctionnement du support matériel d’archivage dans les conditions prévues par le dossier des exigences techniques mentionné à l’article 32.
Afin de garantir que son fonctionnement est conforme aux spécifications du présent décret et aux dispositions du dossier des exigences techniques, le support matériel d’archivage fait l’objet, dans le délai de six mois à compter de sa date de mise en fonctionnement, de la certification mentionnée au II de l’article 23 de la loi du 12 mai 2010 susvisée.
Article 25 : Le support matériel d’archivage est développé et exploité sous la seule responsabilité de l’opérateur.
Les échanges électroniques entre le joueur, le support matériel d’archivage et la plate-forme de l’opérateur sont sécurisés de sorte que soient garanties leur authentification et leur confidentialité.
Le support matériel d’archivage doit être au moins doté de quatre fonctions :
1° Recueil et mise en forme des données tracées ;
2° Conservation de ces données ;
3° Consultation et extraction de ces données ;
4° Administration et gestion des utilisateurs du support matériel d’archivage.
Article 26 : La conception du coffre-fort garantit :
1° Que seuls les agents de l’Autorité nationale des jeux peuvent déchiffrer le contenu des données qui y sont conservées ;
2° Que toute suppression ou altération de ces données, malveillante ou non, est identifiable par ces agents ;
3° Que la gestion des droits d’accès au coffre ne peut être réalisée que par des agents de l’Autorité nationale des jeux. L’Agence nationale de la sécurité des systèmes d’information se prononce sur la conception du coffre-fort au regard des garanties exigées.
Article 27 : Le coffre-fort contient deux espaces de conservation des données, l’un pour les données d’administration du support matériel d’archivage, l’autre pour les données tracées. Lorsque l’opérateur dispose de plusieurs agréments, le coffre-fort contient un espace de conservation des données tracées par activité de jeu ou de pari faisant l’objet d’un agrément. Les données tracées et conservées dans le coffre-fort sont chiffrées de manière à en garantir la confidentialité. Elles sont horodatées, chaînées et scellées de manière à ce qu’elles ne puissent être altérées et à ce que tout ajout, suppression ou modification soit détectable par les agents de l’Autorité nationale des jeux.Les données tracées font l’objet d’un codage spécifique correspondant aux catégories d’informations précisées dans le dossier des exigences techniques et portant notamment sur [….]
Article 28 : L’Autorité nationale des jeux peut accéder aux données conservées dans le coffre-fort du support matériel d’archivage soit sur le site d’hébergement de ce dernier, soit en téléchargeant ces données à distance. A cette fin, l’opérateur fournit à l’autorité une version des outils d’extraction et de validation des données que celle-ci pourra utiliser dans ses locaux. Les données restent accessibles sur le site d’hébergement du support matériel d’archivage durant toute leur durée de conservation exigée à l’article 10. Les données accessibles à distance doivent couvrir au moins les douze derniers mois d’activité de l’opérateur. Les agents de l’Autorité nationale des jeux mentionnés au II de l’article 42 de la loi du 12 mai 2010 susvisée peuvent se rendre à tout moment sur le site d’hébergement du support matériel d’archivage pour saisir l’ensemble ou un sous- ensemble des données qui y sont conservées. A cette fin, ils informent au moins deux heures à l’avance le représentant de l’opérateur mentionné au cinquième alinéa de l’article 16 de cette même loi de leur intention d’accéder à ce site et de l’heure à laquelle cet accès devra leur être donné.
I.1.2 Glossaire
ANSSI : Agence Nationale de la Sécurité des Systèmes d’Information.
Authenticité : caractère d’une information (document, données) dont on peut prouver qu’elle est bien ce qu’elle prétend être, qu’elle a été effectivement produite ou reçue par la personne qui prétend l’avoir produit ou reçu, et qu’elle a été produite ou reçue au moment où qu’elle prétend l’avoir été.
Capteur : élément constitutif du système de collecte et archivage, dont la fonction est la création de traces. La fonction de création de traces correspond au formatage des données circulant entre le joueur et la plateforme de jeu puis au transfert de ces données vers le module coffre-fort du système de collecte et d’archivage.
7/202

Coffre-fort : élément constitutif du système de collecte et archivage, dont la fonction est de chiffrer, signer, horodater et archiver les données tracées et collectées depuis le flux en provenance du joueur ou fournis par la plateforme de jeux. Ceci afin de garantir la confidentialité, l’authenticité et l’exhaustivité dans le temps.
Confidentialité : propriété selon laquelle l’information n’est pas rendue disponible ni divulguée à des personnes, des entités ou des processus non autorisés.
Disponibilité : propriété d’être accessible et utilisable à la demande par une entité autorisée.
Intégrité : caractère complet et non altéré d’une information prouvant que celle-ci n’a subie aucun ajout, aucun retrait ni aucune modification accidentelle ou intentionnelle, depuis sa validation.
Support Matériel d’Archivage (SMA) : est un dispositif de recueil et d’archivage des données échangées entre le joueur et la plateforme de l’opérateur à l’occasion des opérations de jeux. Ce dispositif est développé et exploité sous la responsabilité de l’opérateur.
Système d’information : un système d’information est un ensemble de ressources destinées à élaborer, collecter, classifier, stocker, diffuser les informations au sein d’une organisation. Ainsi, il comprend l’ensemble organisé de personnes, de procédures, de processus et d’équipements du système informatique.
Système informatique : un système informatique représente l’ensemble des ressources matérielles et logicielles organisées pour collecter, stocker, traiter et communiquer les informations.
Traçabilité : propriété qui permet la non-répudiation et d’assurer l’imputabilité. Cela signifie que cette propriété garantit l’origine de la source, de la destination, la véracité d’une action et l’identification de l’entité responsable.
I.2 Exigences générales
I.2.1 Gouvernance
E_SMA GG_1. L’opérateur communique à l’ANJ une description détaillée du SMA.
Information : Il s’agit de préciser à minima la stratégie employée en matière de gouvernance, la localisation physique du SMA, le type d’hébergement mis en œuvre, l’appréciation des risques et la politique de sécurité en découlant, les contrats d’hébergement et de prestation particulièrement le plan d’assurance sécurité.
E_SMA_GG_2. L’opérateur désigne et communique à l’ANJ un point de contact pour toute question sur l’ensemble du SMA.
E_SMA_GG_3. En cas de sous-traitance du SMA, l’opérateur communique le nom et la localisation de son ou ses prestataires.
I.2.2 Politique de contrôle d’accès
Le contrôle d’accès se caractérise par 3 propriétés importantes :
authentification qui permet de s’assurer que l’identité de l’utilisateur est légitime ;
autorisation qui détermine les tâches qu’un utilisateur est autorisé à faire ;
non-répudiation qui permet de s’assurer qu’un utilisateur ne peut pas nier avoir effectué une tâche. E_SMA_GPCA_1. L’opérateur met en place une gouvernance et une gestion des identités et des accès au sein de l’écosystème du SMA.
Important : Cette gestion des accès et des identités inclut les fonctionnalités permettant de gérer l’identité d’un utilisateur dans le réseau. Cela se traduit principalement par une authentification des utilisateurs sur le réseau et de pouvoir assurer la traçabilité des droits qui doivent être conformes aux exigences de sécurité et à l’activité métier.
8/202

E_SMA_GPCA_2. L’opérateur distingue quatre rôles d’utilisateurs différents :
déposant
lecteur
administrateur technique et opérationnel
administrateur fonctionnel.
Figure 1 : les rôles et profils associés aux utilisateurs
Information : La figure ci-dessus présente les rôles et profils associés des différents utilisateurs. Le rôle « déposant » est un profil applicatif attribué au module « capteur » du SMA. Il permet uniquement d’écrire des traces dans le journal. Il est à noter que le module capteur du SMA doit s’authentifier à l’aide d’un certificat X.509v3 auprès de la partie coffre-fort avec une identité associée à ce profil.
Le rôle « lecteur » est un profil métier attribué aux agents de l’ANJ dotés des pouvoirs de contrôle et d’audit, qui permet l’extraction des données enregistrées, soit sur support amovible, soit via un dépôt de fichiers accessible à travers un service Web. Le rôle « administrateur technique et opérationnel » est un profil métier attribué au personnel technique de l’opérateur ou e son sous-traitant, responsable de l’administration et de la supervision technique du coffre-fort, pour effectuer les tâches suivantes par exemple :
arrêt/démarrage du coffre,
configuration du médium de stockage,
consultation des journaux techniques, notamment en termes de traçabilité des accès locaux et distants, de gestion des erreurs, etc. Le rôle « administrateur fonctionnel » est un profil métier attribué aux personnes physiques de l’ANJ ou désignées par l’ANJ, qui peuvent définir des rôles et leur associer un certificat d’authentification. Cette opération est nécessaire à l’initialisation des coffres, puis lors des renouvellements ou des révocations des certificats. Important. Dans son dossier de demande d’agrément, l’entreprise expose à l’ANJ, de façon détaillée, les mesures qu’elle prend pour que son SMA permette la captation et la sauvegarde de la totalité des données qu’il doit servir à recueillir. Préalablement au début de son activité, l’entreprise ayant obtenu son agrément a l’obligation de déclarer à l’ANJ que son SMA est en mode de fonctionnement, permettant ainsi l’accès de l’Autorité aux données.
I.2.3 Chiffrement
9/202

E_SMA_GC_1. Les mécanismes (fonctions et algorithmes) de chiffrement mis en œuvre sont conformes aux bonnes pratiques spécifiées dans le référentiel général de sécurité¹. E_SMA_GC_2. L’opérateur chiffre les traces collectées avec la clef publique de l’ANJ. E_SMA_GC_3. L’authentification de l’opérateur se fait à l’aide de la bi-clef RSA ²d’une taille minimale de 2048 bits. Conformément au RGS, l’utilisation de cette taille minimale ne pourra pas excéder l’année 2030. E_SMA_GC_4. La clef publique correspondant au module du crypto-système mis en place pour l’authentification de l’opérateur est communiquée par celui-ci à l’ANJ et avant le début de son de son activité.
I.2.4 Durcissement
Le durcissement dans le monde informatique est un processus qui a pour objectif de réduire les vulnérabilités du système informatique et de manière générale du système d’information. Ce qui a pour conséquence directe la diminution des risques opérationnels qui pourraient lui être lés. E_SMA_GD_1. Le SMA comporte des fonctionnalités de sécurité telles que l’utilisation de protocoles sécurisés. Information : Ces fonctionnalités visent à protéger le SMA des attaques par saturation tant au niveau :
transport, si ce composant termine les connexions TCP initiées par les clients : protection contre les dénis de service réseau, qui visent un épuisement de ressources TCP par des attaques de type SYN Flood, ou des attaques qui s’appuient sur un établissement complet de connexion TCP;
applicatif, avec l’envoi de multiples requêtes HTTP qui viseraient la saturation du SMA, qui constitue potentiellement un point de défaillance unique de l’architecture, afin de le protéger contre un épuisement de ressources (saturation des enregistrements en attente d’acquittement) et d’une saturation du « coffre » avec des enregistrements malicieusement forgés.
E_SMA_GD_2. L’ensemble des composants du SMA et ceux ayant un lien direct ou indirect sont durcis selon l’état de l’art. E_SMA_D_3. Le durcissement doit être effectif tant au niveau matériel que logiciel. Information : Il s’agit de réduire le niveau de menace en intervenant sur les surfaces d’attaque potentielle. Cela
peut se traduire par la suppression des logiciels inutiles et superflus ainsi que des périphériques inutiles, la rationalisation des comptes utilisateurs et de services, chiffrement des données, utilisation de canal sécurisé pour des transferts de bout en bout, etc.
I.3 Exigences en matière d’architecture et de fonctions
I.3.1 Principe de recueil
Conformément aux dispositions en vigueur, l’opérateur met en place un dispositif de collecte et d’archivage « SMA3 » permettant de collecter et de stocker les données échangées entre le joueur et l’opérateur de manière sécurisée à des fins de contrôle.
La cinématique du flux peut se traduire de la façon suivante :
connexion du joueur redirigée vers le SMA.
transmission de réponse et acquittement de la plateforme de jeux ;
enregistrement sécurisé de l’évènement dans le coffre.
E_SMA_AFPR_1. L’opérateur utilise des composants de confiance (tels que décrits dans les référentiels de certification de l’ANSSI) dans son architecture du SMA.
¹ RGS : référentiel établi par l’Agence National de la Sécurité des Systèmes d’Information.
² RSA : Rivest-Shamir-Adelman RSA initiales du nom des créateurs de cet algorithme de cryptographie asymétrique.
³ SMA : Support Matériel d’Archivage
10/202

Important : Il est attendu de l’opérateur l’ensemble de la documentation relative au SMA. Cette documentation contient à minima la description détaillée de chaque module et composant du SMA, l’architecture fonctionnelle, applicative et réseau mise en œuvre, les rapports d’évaluation et d’audit du SMA ainsi que les différents tests de fonctionnement (nominal, en mode dégradé, interconnexion, etc.).
E_SMA_AFPR_2. Dans le cadre d’une sous-traitance partielle ou complète du SMA, l’opérateur doit obtenir de son prestataire d’un plan d’assurance sécurité (PAS) prévu par l’appel d’offre.
Information : Le PAS est un document contractuel qui établit l’ensemble des dispositions spécifique que le
prestataire s’engage à mettre en œuvre pour assurer la conformité des exigences de sécurité spécifiées. Cela a pour objectif majeur la maîtrise des risques de l’infogérance si elle existe au sein de l’opérateur.
I.3.2 Fonction de création et de collecte de traces
La fonction de création de traces correspond à l’écriture de données liées à un événement de jeu ou à un compte joueur dans le module coffre-fort du SMA.
Cette fonction intercepte voire relaie le flux applicatif entre le joueur et l’opérateur. Elle est implantée en amont de la logique de jeu.
E_SMA_AFCCT_1. Cette fonction est appelée systématiquement à chaque échange de données dont les traces sont exigées particulièrement les demandes de contenu statique (image, pages HTML, etc.), ou encore les pages dynamiques sans rapport avec les événements de jeux dont la traçabilité est exigée, n’ont pas à faire l’objet d’une analyse par le capteur.
E_SMA_AFCCT_3. Le SMA offre une architecture dotée d’une haute disponibilité avec une redondance de mécanismes afin de limiter les incidents potentiels de stockage.
E_SMA_AFCCT_4. Les traces collectées correspondent aux évènements spécifiés au II du présent document.
I.3.3 Fonction d’interconnexion sécurisée
La fonction d’interconnexion correspond au canal d’échange de flux d’opérations relatif à l’activité du joueur. Ce canal doit disposer de mécanismes de protection pour à la fois assurer la sécurité des échanges particulièrement entre les modules « capteur » et « coffre » du SMA, entre le SMA et la plateforme de jeux ainsi qu’entre le module « coffre » et le système d’information de l’ANJ.
E_SMA_AFIS_1. Des mécanismes cryptographiques éprouvés doivent être mis en œuvre pour tous les échanges de transactions entre :
le joueur et le SMA ;
les différents modules du SMA ;
le SMA et la plateforme de jeux de l’opérateur ;
le SMA et le SI de l’ANJ.
Information : Il est essentiel que les transactions entre les équipements (capteur, coffre, et SI de l’ANJ, composant de la plateforme de jeux, etc.) soient sécurisées par le biais de la mise en œuvre de mécanismes cryptographiques.
Toutefois le caractère obligatoire de l’exigence devient une recommandation dès lors que les équipements sont colocalisés permettant ainsi de se prémunir de toutes attaques d’écoute passive ou par interception dont pourrait faire
l’objet le réseau de transport.
I.3.4 Fonction de contrôle d’accès
E_SMA_AFCA_1. L’opérateur contrôle et protège l’accès aux salles serveur et/ou aux locaux techniques hébergeant le
SMA.
E_SMA_AFCA_2. Les rôles spécifiés en amont dans ce document sont implémentés.
E_SMA_AFCA_3. L’architecture de la partie coffre-fort du SMA distingue :
11/202

un espace de stockage des données situé dans une zone réseau sécurisée ;
une couche d’accès à l’espace de stockage accessible. Cette couche doit elle-même être sécurisée, aux niveaux applicatif et réseau, vis-à-vis de l’extérieur, notamment contre les attaques de déni de service, et les accès autres que ceux par l’ANJ. La couche d’accès expose un service web doté des deux principales interfaces suivantes :
une interface de consultation ;
une interface de synchronisation.
Information : L’interface de consultation permet l’extraction d’une trace ou d’un ensemble de traces à partir
d’une date ou d’une tranche caractérisée par une date de début et une date de fin. À une même date peuvent correspondre aucun, un ou plusieurs évènements. Quant à l’interface de synchronisation, elle permet l’extraction d’une trace et ou d’un ensemble des traces à partir de l’identifiant d’un évènement ou d’une tranche d’évènements. (le détail concernant la formation d’enregistrements ou de lots d’enregistrement est précisé plus bas).
I.3.5 Fonction d’administration
La fonction d’administration correspond à la gestion et à l’exploitation des éléments matériels ou logiciels du SMA ainsi qu’à son bon fonctionnement.
Cette fonction veille à la cohérence, à l’accessibilité et à la sécurité des informations qui sont créées, transmises et stockées dans le SMA. Cela implique une mise en place d’un contrôle d’accès et d’une ségrégation des rôles des différents utilisateurs comme indiqué précédemment.
La figure suivante présente de manière schématique les interactions entre les fonctions établies.
12/202

Figure 2 : différentes interactions entre les fonctions du SI relatif au SMA étant précisé que les relations entre le rôle d’administrateur ANJ et l’administrateur du SMA sont préalables à la mise en fonctionnement de ce dernier.
E_SMA_AFA_1. Les accès à la partie du coffre-fort du SMA s’appuient sur des mécanismes d’authentification forte.
E_SMA_AFA_2. Le certificat de chiffrement X.509v3 fourni par l’ANJ doit être mis en place avant ouverture du service. Important : Le coffre-fort est hébergé et exploité par l’opérateur, mais seuls certains agents de l’ANJ peuvent déchiffrer le contenu des données archivées : l’ANJ fournit donc le certificat X.509v3 de chiffrement des données du coffre. L’ANJ fournit également les certificats X.509v3 utilisés pour son authentification à distance au coffre. E_SMA_AFA_3. La conception du coffre garantit que seule l’ANJ peut, si elle le souhaite, gérer les utilisateurs de l’autorité à savoir les lecteurs, et leur accorder des droits. E_SMA_AFA_4. Toute suppression ou altération des données archivées, de manière malveillante ou non, doit pouvoir être identifiée par l’ANJ.
I.3.6 Fonction de Stockage et d’archivage La fonction de stockage correspond à l’archivage des données tracées et collectées dans le coffre-fort afin d’en garantir l’intégrité et l’exhaustivité dans le temps. Ainsi le stockage des données consiste en les étapes décrites par la figure ci- dessous.
13/202

Figure 3 : les différentes étapes de la fonction de stockage et d’archivage
Lors de l’étape 1, un canal sécurisé est établi suite à l’authentification mutuelle du déposant (module capteur du SMA) avec le coffre-fort. Ce canal se fait par une session TLS mutuellement authentifiée par certificat X.509v3 et vérification de l’habilitation du profil à déposer des traces.
L’étape 2 correspond au dépôt des données évoqué plus bas.
L’étape 3 consiste, en cas de succès des étapes précédentes, à retourner un accusé de dépôt pour poursuivre la transaction.
E_SMA_AFSA_1. L’opérateur met en place des mécanismes de confiance de sorte à garantir l’intégrité, l’authenticité et l’enregistrement des données tracées.
E_SMA_AFSA_2. Le format de signature utilisée est XADES-T avec un jeton d’horodatage (conforme à la RFC 3161), afin d’assurer la non-répudiation de la transaction.
E_SMA_AFSA_3. Le coffre-fort met en œuvre une ségrégation entre l’espace de stockage destiné aux données de son administration et celui ou ceux destinés aux données de jeu tracées.
E_SMA_AFSA_4. Dans le cadre d’un coffre mutualisé entre plusieurs agréments, chaque agrément doit faire l’objet d’un espace de stockage spécifique.
Information. Cette ségrégation des espaces de stockage est, a fortiori, implantée dans le cadre d’une mutualisation inter-opérateurs, le cas échéant.
E_SMA AFSA_5. Dans le cadre d’une architecture de stockage comprenant plusieurs coffres forts opérés en parallèle, l’opérateur doit mettre en place une interconnexion sécurisée au profit de l’ANJ pour interroger à distance un ou plusieurs coffres.
Important. Pour des raisons de performances ou de disponibilité, l’opérateur pourra proposer une architecture de stockage comprenant plusieurs coffres-forts opérés en parallèle, éventuellement chez plusieurs prestataires. Dans ce cas, l’ANJ pourra interroger à distance un ou plusieurs coffres, suivant la configuration mise en place par l’opérateur, à charge pour l’exploitant de gérer correctement les identifiants (notamment identifiant de coffre et identifiant
d’évènement) pour lui permettre de satisfaire les exigences de l’ANJ.
I.4 Exigences relatives à l’accès aux données par les agents de l’ANJ
I.4.1 Exigences générales
E_SMA_ADEG_1. L’opérateur met en place les outils suivants :
un mécanisme d’accès aux données permettant :
la saisie des données sur site (copie de tout ou partie du coffre-fort),
l’interrogation des données à distance, par l’intermédiaire d’un outil de collecte ;
14/202

un outil de validation des données du SMA et d’extraction des traces des opérations de jeu : extraction des événements de jeu après validation de l’intégrité des données copiées depuis le SMA :
utilisable sur le site du SMA,
utilisable à distance par l’ANJ, dans un mode hors-ligne (i.e. déconnecté d’internet).

E_SMA_ADEG_2. Les données archivées sont mises à disposition de l’ANJ localement ou par accès à distant.
Pour mémoire, le rôle « lecteur » est un profil métier attribué aux agents de l’ANJ qui permet l’extraction des données enregistrées, soit sur support amovible, soit via un dépôt de fichiers accessible à travers un service Web. Les certificats associés à ce rôle sont utilisés :
soit par des personnes physiques, pour les contrôles réalisés sur site, avec des biclefs RSA et un certificat X.509v3 d’authentification conservés sur un support matériel (ex : carte à puce) fourni par l’opérateur,
soit par des agents de collecte, pour les consultations réalisées à distance, avec une authentification fondée sur un certificat X.509v3 client SSL/TLS, dans le cadre de la négociation d’un tunnel SSL/TLS mutuellement authentifié.
Figure 4 : les phases d’accès aux traces archivées dans le module « coffre » du SMA
I.4.2 Accès à distance
E_SMA_ADAC_1. Le dispositif mis en place par l’opérateur permet à l’ANJ :
d’une part, d’interroger à distance le coffre de l’opérateur pour télécharger les traces demandées ;
d’autre part, d’extraire les traces ainsi téléchargées pour ensuite les déchiffrer et vérifier l’intégrité des données. Important : Les données stockées dans le coffre doivent être accessibles à distance, depuis les locaux de l’ANJ (depuis une ou plusieurs adresses IP identifiées qui seront communiquées à l’opérateur, par exemple). E_SMA_ADAC_2. L’outil d’interrogation à distance doit implémenter à minima les options suivantes :
la configuration d’une URL⁴, comportant un nom de domaine pleinement qualifié identifiant le service Web ;
la configuration d’un identifiant de coffre, dans le cas où l’architecture mise en place par l’opérateur compterait plusieurs coffres à des fins de haute-disponibilité ;
la configuration d’une plage horaire, permettant le téléchargement du fichier de traces correspondant aux évènements de jeux horodatée enregistrés dans cette plage ;
la configuration d’une plage d’évènements, permettant le téléchargement du fichier de traces correspondant aux évènements de jeux dont les identifiants sont présents dans la tranche.
⁴ URL : Uniform Resource Locator, il s’agit d’une adresse web composé d’une chaîne de caractère uniforme permettant de localiser une page web.
15/202

E_SMA_ADAC_3. Les données accessibles à distance couvrent au moins les 12 derniers mois d’opération (période glissante).
E_SMA_ADAC_4. L’opérateur doit offrir la possibilité à l 'ANJ de pouvoir extraire du coffre une tranche de données, correspondant à une période d’activité ou une tranche d’identifiants d’évènements, sans avoir à se déplacer, et dans des conditions de sécurité logique équivalentes.
E_SMA_ADAC_5. Les outils d’interrogation à distance et d’extraction de respectent les contraintes suivantes :
fonctionnement multi-plate-formes, sous les systèmes Windows et Linux, avec les derniers niveaux de mise à jour ;
utilisation d’une interface en ligne de commande, et afin d’être exécutés sous la forme d’une tâche journalisée, ou en mode démon (sans terminal de contrôle) ;
prise de paramètres en ligne de commande et par l’intermédiaire d’un fichier de configuration (la ligne de commande supplantant, le cas échéant, les options du fichier de configuration). E_SMA_ADAC_6. Ces outils sont exempts de dysfonctionnement. Dans ce cadre l’opérateur mettra en place une politique de maintien en condition opérationnelle (MCO) et de maintien en condition de sécurité (MCS).
E_SMA_ADAC_7. Les outils présentent un niveau de performance « raisonnable » : en particulier, le temps d’exécution de l’outil de déchiffrement doit être « significativement » inférieur à celui de la plage horaire du lot d’évènements à déchiffrer.
E_SMA_ADAC_8. Avant de débuter son activité, l’opérateur effectue des tests de connectivité selon des modalités précisées par les services de l’ANJ
I.4.3 Saisie des données sur site
E_SMA_ADSD_1. L’ensemble des données du journal de traces contenues dans le SMA peut être copié sur un support amovible sécurisé par un représentant de l’ANJ intervenant dans le cadre fixé au III de l’article 42 de la loi du 12 mai 2010.
Information : Le mécanisme de copie des données dépendra du médium de stockage choisi par l’opérateur. La
protection de la confidentialité des données lors du transport entre le site d’hébergement du SMA et le laboratoire de l’ANJ est assurée par leur chiffrement.
16/202

II Exigences techniques relatives aux données mises à la disposition de l’ANJ selon les modalités prévues à l’article 31 de la loi du 12 mai 2010 II.1 Exigences communes
E_DATA_EC_1. Les traces archivées dans le SMA respectent les modalités d’enregistrement défini ci-après
Chacune des structures de données considérées est formalisée, schématisée sous forme d’objets appelés dans le présent document « événement ».
Les événements sont des ensembles d’informations unitaires représentant chacune une propriété de l’événement.
Chaque évènement de jeu est archivé sous forme d’un enregistrement qui est :
structuré suivant le format XML⁵ ;
horodaté, chaîné, scellé. Un enregistrement est composé de deux ensembles de données :
Des données techniques ou données de validation : il s’agit des informations permettant de valider les données de jeu entreposées dans l’ensemble de données fonctionnelles qu’elles accompagnent. En outre, elles contiennent également des éléments permettant le chainage avec les enregistrements précédents ;
Des données fonctionnelles : il s’agit des informations contenant la trace des évènements de jeu liés à l’activité du joueur. Elle est composée d’une partie présente pour chaque évènement de jeu (entête) et d’une partie spécifique à l’évènement enregistré (corps) ;
Les enregistrements, au choix de l’opérateur, peuvent contenir un seul événement ou un lot d’événements.
La structure des données fonctionnelles étant décrite plus bas, les éléments qui suivent décrivent la structure des donnée techniques ou données de validation.
E_DATA_EC_2. Il convient d’enregistrer l’annulation d’un évènement de façon à pouvoir le relier facilement à l’évènement initial.
II.1.1 Instant de capture Dans les conditions d’architectures décrites plus haut, les événements attendus sont capturés à l’instant précis de leur génération :
- immédiatement du fait de l’action du joueur. Exemple :
o le joueur place un pari ;
o le joueur modifie un modérateur.
- immédiatement après la survenance d’une opération à consigner. Exmple :
⁵ • La description du format XML est donnée à l’adresse suivante : http://www.w3.org/XML.
17/202

o l’attibution d’un gain lors du débouclage d’un résultat de compétition ;
o L’ouverture d’un point de vente.
Les données capturées concourant à l’élaboration des événements qui figureront dans les enregistrements consignés au coffre, ces données peuvent être accompagnées de données d’enrichissement provenant de la plateforme.
E_DATA_IC_1 : L’enregistrement est effectué seulement quand les informations captées et consolidées par le SMA sous forme d’événements sont réputées valides et cohérentes.
Information : les données ont été contrôlées par ailleurs et la saisie est acceptable du point de vue de la plate-
forme. Ainsi, on évite d’avoir à enregistrer un mouvement d’annulation pour cause de saisie non valide (vérification syntaxique) ou incohérente (vérification sémantique).
II.1.2 Chaînage Afin de garantir la consistance des ensembles de données enregistrés au coffre, il convient que chaque enregistrement puisse être relié sans équivoque à son prédécesseur.
Ce chainage se concrétise par la présence d’une emprunte de l’enregistrement précédent dans les données de validation.
E_DATA_CN_1 : Une occurrence de données de validation référence l’occurrence de données de validation précédentes et est/sera référencée par l’occurrence qui la suivra.
La figure suivante illustre de façon globale l’organisation d’enregistrements successifs et permet également de visualiser la portée du chiffrement.
18/202

II.1.3 Traitement par évènement unitaire ou par lot
Un identifiant, présent tant dans les données de l’événement que dans les données de validation, permet la liaison de ces deux ensembles de données.
E_DATA_TE_1 : Cet identifiant de donnée de jeu est généré par le coffre : il est unique pour un coffre donné.
E_DATA_TE_2 : Les identifiants sont générés consécutivement par le coffre sans discontinuité.
Information : Dans le cas de la mise en œuvre de plusieurs coffres, le coffre entretient un séquencement continu qui lui est local. L’unicité au sein de la plate-forme de l’opérateur sera en ce cas assurée par la notion
d’identifiant de coffre.
L’unicité d’un évènement est donc assurée :
- au sein d’un coffre, par son numéro de séquence ;
- chez un opérateur, par la combinaison du numéro de séquence et de l’identifiant de coffre ;
- sur l’ensemble des opérateurs (cas de la mutualisation de coffres), par la combinaison du numéro de séquence, de l’identifiant de coffre et de l’identifiant d’opérateur.
E_DATA_TE_3 : A un identifiant correspond un et un seul événement. Le compteur ne doit souffrir d’aucune discontinuité. Le cas échéant, la détection et la reprise sur erreur devront être traitées par l’outil de validation et d’extraction
E_DATA_TE_4 : le coffre intègre des mesures afin de protéger des attaques contre l’enchaînement naïf des opérations de signature et de chiffrement, et inversement.
19/202

La date d’horodatage de la donnée de validation est générée par le coffre, elle correspond à la date de signature. La date d’horodatage est postérieure ou égale à la date de l’événement de donnée de jeu qui elle est fixée à l’instant de la captation.
Le traitement par lot est tout à fait adapté à la gestion des pics de charge, il est indispensable toute foi que les objectifs d’intégrité et d’exhaustivité restent garantis, en particulier, les identifiants des événements contenus dans un lot seront obligatoirement consécutifs.
Un lot d’évènements correspond à un enregistrement d’un ou plusieurs événements de jeu consécutif et à une donnée unique de validation pour le groupe. L’horodatage ne porte plus sur un évènement seul, mais sur un ensemble d’évènements.
La date d’horodatage de la donnée de validation est générée par le coffre à l’issue de l’assemblage des événements constituants le lot considéré, elle correspond à la date de signature. La date d’horodatage est postérieure ou égale à la date de l’événement de donnée de jeu, toujours fixée à l’instant de la captation des événements eux-mêmes, le plus ressent du lot.
E_DATA_TE_5 : L’horodatage doit être réalisé sur le lot d’évènements en clair.
Une donnée de jeu d’un évènement ne peut faire partie que d’un seul lot et possède donc une seule donnée de validation associée.
Le fonctionnement des outils d’extraction et de validation décrits plus haut, implique que le mécanisme de création de lot tienne compte de deux paramètres conditionnant la taille des lots :
20/202

une durée maximale pendant laquelle les événements captés peuvent être groupés dans un même lot ;
un nombre maximal d’évènements à regroupé dans un lot. Quand l’une ou l’autre de ces valeurs est atteinte, un nouveau lot doit être initié.
E_DATA_TE_6 : La granularité est de l’ordre de l’évènement. Autrement dit, en fixant le nombre maximal d’évènements à 1, le coffre est capable d’horodater unitairement chaque évènement.
Information Le choix de ces paramètres est laissé à la discrétion de l’opérateur, qui les dimensionne en fonction de
ses besoins de disponibilité, et les communique à l’ANJ.
II.1.4 Création d’enregistrement : chronologie des actions E_DATA_CECA_1 : Qu’il soit fait le choix de regrouper les événements par lot ou non, le processus de création d’enregistrement respecte une certaine chronologie.
Constitution d’un lot d’évènements (captation) ;
Calcul des données de validation ;
Compression⁶ du lot d’évènements ;
Horodatage, signature et chiffrement (par exemple) de l’événement, ou du lot d’évènements. Information L’implantation des mécanismes cryptographiques privilégie la signature des données avant leur
chiffrement.: Le choix de l’utilisation et de la méthode de compression est à la discrétion de l’opérateur. L’outil de validation devra implanter de façon transparente la décompression des informations, après leur déchiffrement.
II.1.5 Conventions d’écriture Dans la suite du présent document, la représentation XML attendue pour la formalisation du corps de chaque évènement est décrite sous la forme d’un tableau.
E_DATA_CE_1 : De façon générale,
Le format d’encodage est UTF⁷-8.
Les dates et heures sont à l’échelle de temps UTC⁸. (Cela sous-entend une mise en place d’une source de temps fiable et non modifiable dont l’écart avec le temps UTC est inférieur à une seconde. Il peut s’agir d’une mise en place d’un serveur NTP sécurisé).
L’exemple de tableau suivant récapitule l’ensemble des caractéristiques des entités formant le TAGXML considéré :
[TAGXML] Entité XML Min Max Type Description
[Entité] [Min] [Max] [Type] [Description]
[Choix1]
[Min1]
[Max1]
[Type1]
[Description]
[Choix2]
[Min2]
[Max2]
[Type2]
- [TAGXML]désigne la racine de la structure XML. Elle est composée de plusieurs [Entité]
- [Entité] est un élément de [TAGXML] dont le type est donné par [Type]. L’élément possède entre [Min] et [Max] occurrence(s). Si [Min] est égale à zéro, l’élément est optionnel. Si [Min]=[Max]=1 alors l’élément est obligatoire et unique.
- [Description] est une description de premier niveau de l’élément.
- [ChoixN] (N est ici un entier) représente des entités dont la présente au sein de [TAGXML] est conditionnée :
o Soit par le contexte
o Soit par la valeur prise par une autre entité du même objet.
⁶ L’efficacité d’un algorithme de compression est plus grande sur un volume de données plus important ce qui rend avantageux le choix de procéder à la création d’enregistrement par lot d’événements.
⁷ UTF : Unicode Transformation Format
⁸ UTC : temps universel coordonné
21/202

Ces alternatives sont alors présentées sous la forme d’un ensemble d’entité [ChoixX]. Dans ce cas, la présence d’exactement une valeur choisie parmi ces alternatives est obligatoire.
Chaque [Entité]est caractérisée par son [Type]. Cette indication fait référence
o Soit à un type complexe sous la forme d’un autre [TAGXML] dont la description figure dans le présent document ;
o Soit à un type scalaire : si nécessaire les caractéristiques sont décrites à la suite sous la forme d’un tableau :
[Type]
Sous-type Contraintes
Enfin, le tableau [TAGXML] décrivant la structure d’un événement, est suivi d’un ensemble de descriptifs permettant de définir précisément le rôle (ce qu’il représente et dans quel cas) de chaque entité.
II.1.6 Format des données de validation
Les données de validation, tout comme les données de jeux, prennent la forme d’un objet XML.
VALIDATION
Entité XML Min Max Type Description DateHorodatage 1 1 date-aammjjhhmmss Date d’horodatage
IDEvtDebut 0 1 nonNegativeInteger Identifiant du premier événement de jeu dans le cadre de la création d’enregistrement par lot (voir §II.1.3) IDEvt 1 1 nonNegativeInteger Identifiant de l’événement de jeu ou du dernier évènement de jeu le cadre de la création d’enregistrement par lot (voir
§II.1.3) IDCoffre 0 1 nonNegativeInteger Identifiant du coffre
EmpVal 1 1 Libre Empreinte de la donnée de validation précédente Sig 1 1 Libre Signature numérique des données de jeu de
l’évènement ou du lot d’évènements (format
XADES-T)
Description
DateHorodatage
Obligatoire. Date et heure, au format UTC, inscrites par le coffre pour horodater le ou les évènements. Cette date est générée par le capteur.
IDEvtDebut
Optionnel. Présent seulement dans le cas du traitement par lots, il s’agit de l’identifiant du premier évènement du lot.
IDEvt
Obligatoire. Identifiant de l’évènement de jeu à valider. Dans le cas du traitement par lots, il s’agit de l’identifiant du dernier évènement du lot.
IDCoffre
Optionnel. Identifiant du coffre pour l’opérateur : le premier coffre de l’opérateur commence à 1, le second à 2, etc. Cette information est optionnelle si l’opérateur ne dispose que d’un seul coffre : dans ce cas, l’identifiant de coffre possède implicitement la valeur 1.
EmpVal
Obligatoire. Empreinte numérique de la précédente donnée de validation traitée par le coffre. Le format de cette empreinte est laissé au choix de l’opérateur. Toutefois, il est demandé d’utiliser des algorithmes de calcul d’empreinte conformes au référentiel général de sécurité (RGS). Les outils mis à disposition de l’opérateur pour vérifier les données de validation devront reconnaître cette empreinte.
Exemple : valeur en hexadécimal de l’empreinte SHA256 (256 bits) de la précédente donnée de validation.
Sig
22/202

Obligatoire. Signature numérique de la donnée de validation, portant sur les données de jeu de l’évènement ou du lot d’évènements, afin d’en garantir la date d’enregistrement. Cette signature doit être au format XADES-T⁹.
date-aammjjhhmmss Sous-type Contraintes String 12 chiffres représentant la concaténation des deux décimales de l’année, du numéro du mois, du numéro du jour, de l’heure, de la minute et de la seconde. Regex : \d{12} Exemple : 100411124202 représente la date du 11 avril 2010 à 12:42 et 2 secondes.
II.2 Description de l’entête
Rappel des dispositions légales et réglementaires Décret n° 2010-518 du 19 mai 2010 relatif à l’offre de jeux et de paris des opérateurs de jeux et à la mise à disposition de l’Autorité nationale des jeux des données de jeux (ci-après décret n°2010-518) Article 27 Les données tracées font l’objet d’un codage spécifique correspondant aux catégories d’informations précisées dans le dossier des exigences techniques et portant notamment sur :
1° L’identifiant du joueur, ou “ login “, saisi par le joueur pour s’identifier auprès de l’opérateur ;
2° Le pseudonyme du joueur ou “ pseudo “, c’est-à-dire le nom d’emprunt que se donne le joueur dans le cadre de ses activités de jeu ;
3° L’adresse IP “ du joueur, c’est-à-dire l’adresse dite “ Internet Protocol “ du terminal depuis lequel le joueur se connecte au site de l’opérateur ou tout élément fournissant une indication relative à la localisation de la prise de jeu réalisée au moyen d’un terminal ou poste d’enregistrement mis à la disposition des joueurs dans des lieux publics ou des lieux privés ouverts au public au sens du deuxième alinéa de l’article L. 320-5 du code de la sécurité intérieure.
II.2.1 Evènements du compte joueur et l’activité de jeu
L’entête est une partie fixe présente dans chaque famille d’évènements de donnée de jeu. Elle permet d’identifier et de caractériser un évènement de jeu.
Structure de l’enregistrement en format XML En-tête commun à l’ensemble des évènements de jeu Entité XML Min Max Type Description IDOper 1 1 operator Identifiant de l’opérateur DateEvt 1 1 date-aammjjhhmmss Date de l’évènement IDEvt 1 1 nonNegativeInteger Identifiant de l’évènement IDJoueur 1 1 string-64 Identifiant du joueur HashJoueur 1 1 sha1 Empreinte cryptographique du joueur IPJoueur 0 1 IP Adresse IP de joueur IDPointDeVente 0 1 String-64 Identifiant du point de vente (pour les évènements de jeu sous droits exclusifs) IDSession 1 1 string-256 Identifiant de session IDCoffre 1 1 nonNegativeInteger Identifiant du coffre Supervision 0 1 Balise vide Indique si l’événement a été transmis au coffre à l’initiative de l’opérateur (sans acquittement de la part du joueur)
⁹ Le format XADES-T décrit à l’adresse suivante : http://www.w3.org/TR/XAdES
23/202

string-32 Sous-type Contraintes string Chaîne de caractères dont la taille est comprise entre 0 et 32 caractères.
string-64 Sous-type Contraintes string Chaîne de caractères dont la taille est comprise entre 0 et 64 caractères.
string-256 Sous-type Contraintes string Chaîne de caractères dont la taille est comprise entre 0 et 256 caractères.
operator Sous-type Contraintes string Chaîne de caractères fixe dont la taille est de 4 caractères numériques.
sha1 Sous-type Contraintes string Chaîne de caractères fixe dont la taille est de 40 caractères alphanumériques.
IP Sous-type Contraintes string Chaîne de caractères représentant une adresse IPv4 ou IPv6. Regex :(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})|(([0-9a-fA-F]{1,4}|0)(:([0-9a-fA-F]{1,4}|0)){7})
Description IDOper Obligatoire, unique. Identifiant de l’opérateur à quatre chiffres fournis par l’ANJ (il est garanti unique par l’ANJ entre les différents opérateurs). IDOper doit être identique entre les différents coffres de l’opérateur.
Remarques :
- Le cas échéant, les opérateurs proposant à la fois une activité en ligne et une activité sur compte sous droits exclusifs se verront attribuer des identifiants opérateurs différents pour le compte de chacune de ses activités.
-L’exploitation d’un compte joueur ouvert par un opérateur de titulaire de droits exclusifs a lieu dans le respect des règles protégeant le libre exercice de la concurrence, notamment de celles énoncées aux articles L. 420-1 et L. 420-2 du code de commerce. L’opérateur veille également à ce que cette exploitation ne porte pas atteinte à l’objectif défini au 4° de l’article L. 320-3 du code de la sécurité intérieure. DateEvt
Obligatoire, unique. Date et heure de l’évènement de jeu à la seconde près (UTC). DateEvt est généré par le capteur. IDEvt
Obligatoire, unique. Identifiant de l’évènement de jeu propre à chaque coffre de l’opérateur. Il doit être généré par ordre croissant (le premier évènement commence à 0), incrémenté comme un compteur. Le coffre doit garantir son unicité et la continuité de son séquençage. IDJoueur
Obligatoire, unique. Identifiant de joueur permettant d’identifier sans ambiguïté le joueur. Cet identifiant est constant de la création à la destruction du compte du joueur. Si la création de compte joueur est multi-agréments, le même identifiant de joueur doit être utilisé dans l’ensemble des évènements du compte joueur et des évènements de jeu relatifs à ces agréments. HashJoueur
Obligatoire, unique. Empreinte cryptographique calculée à partir de la fonction à sens unique SHA-1, sur les paramètres nom, prénom, date de naissance et lieu de naissance du joueur. Les modalités relatives à la création d’empreintes sont exposées dans le document ET4.
Par exemple, pour Grégory Dupont, né le 1er janvier 1970 à Toulon, dans le Var. La forme canonique finale avant calcul
24/202

d’empreinte est « GREGORYDUPONT19700101TOULON ».
L’empreinte SHA-1 vaut donc DC5BA74F0E74A4AB0AB276CFD7CF60DC02B9F402.
Aucun service de sécurité (ex : signature électronique) n’est mis en œuvre par cette fonction : l’algorithme SHA-1 est donc sciemment utilisé. En particulier, l’utilisation d’une fonction de la famille SHA-2 n’est donc pas requise. Par ailleurs, cette empreinte ayant vocation à être statique, l’utilisation d’un sel est également exclue.
Remarque : cette valeur doit être mise à jour si des modifications surviennent sur le nom ou les prénoms du joueur (évènement MODIFINFOPERSO) dans les conditions précisées par décret. IPJoueur Optionnel (obligatoire pour le jeu en ligne), unique. Adresse IP du joueur telle que vue par la plate-forme de jeu. Il s’agit nécessairement d’une adresse IP publique. Toutefois, lorsque l’évènement est envoyé avec la balise ce champ peut être renseigné avec une IP privée puisque l’évènement est généré par le serveur de l’opérateur. IDPointDeVente Optionnel (obligatoire pour le jeu en réseau physique), Présent dans le cas de paris pris en point de vente ou ceux correspondant à des paris pris par téléphone (jeux sous droits exclusifs uniquement). Représente l’identifiant du point de vente tel que défini par l’ensemble de données créées par les événements OUVPOINTDEVENTE, MODIFPOINTDEVENTE et CLOTUREPOINTDEVENTE IDSession Obligatoire, unique. Identifiant technique non visible par le joueur. Il permet d’identifier chaque session applicative si le joueur en a ouvert plusieurs. Il permet également de faire le lien entre les enregistrements pour reconstituer les actions du joueur. Ex : pour une session applicative HTTP, il peut s’agir de l’identifiant de session (Cookie). Lorsque l’évènement est envoyé avec la balise ce champ prend une valeur unique standardisée (« 0-sys » par exemple) puisque l’évènement ne provient pas d’une session de jeu du joueur. IDCoffre Obligatoire. Identifiant du coffre pour l’opérateur : le premier coffre de l’opérateur commence à 1, le second à 2, etc. Ce champ prend la valeur 1 si l’opérateur ne dispose que d’un seul coffre. La valeur de cette entité est fixée par le coffre lui- même. Supervision Optionnel, unique. La présence de cette balise indique que l’événement a été transmis à l’initiative de l’opérateur sans acquittement de la part du joueur. Cette balise est utilisée avec certains événements dans des contextes précis. Par opposition, son absence, indique que le joueur est à l’origine de l’action génératrice de l’événement ou qu’il l’a, à minima acquitté.
Le principe à retenir étant que les événements doivent être transmis immédiatement au coffre, la balise permet de distinguer les événements qui ont été générés par la plateforme de ceux qui sont une conséquence directe d’une action d’un joueur. Une table exposant les différents cas d’utilisation de la balise ainsi que des exemples figurent en annexe (partie IV).
II.2.2 Evènements d’identification des points de vente
Présentation de l’évènement Pour les évènements relatifs aux points de vente (OUVPOINTDEVENTE, MODIFPOINTDEVENTE et CLOTUREPOINTDEVENTE), tous les champs de l’en-tête précédents n’ont pas lieu d’être. Ainsi, pour ces évènements, et uniquement ces évènements, l’en-tête est réduit aux données suivantes.
Structure de l’enregistrement en format XML En-tête commun à l’ensemble des évènements de jeu Entité XML Min Max Type Description IDOper 1 1 operator Identifiant de l’opérateur DateEvt 1 1 date-aammjjhhmmss Date de l’évènement IDEvt 1 1 nonNegativeInteger Identifiant de l’évènement
25/202

IDCoffre 1 1 nonNegativeInteger Identifiant du coffre
Description IDOper Obligatoire, unique. Identifiant de l’opérateur à quatre chiffres fournis par l’ANJ (il est garanti unique par l’ANJ entre les différents opérateurs). IDOper doit être identique entre les différents coffres de l’opérateur. A noter que les opérateurs ayant à fois une activité en ligne et une activité sur compte sous droits exclusifs pourront se voir attribuer des identifiants opérateurs différents pour chacune de ces activités afin de permettre de bien pouvoir les distinguer. DateEvt Obligatoire, unique. Date et heure de l’évènement de jeu à la seconde près (UTC). DateEvt est généré par le capteur. IDEvt Obligatoire, unique. Identifiant de l’évènement de jeu propre à chaque coffre de l’opérateur. Il doit être généré par ordre croissant (le premier évènement commence à 0), incrémenté comme un compteur. Le coffre doit garantir son unicité et la continuité de son séquençage. IDCoffre Optionnel. Identifiant du coffre pour l’opérateur : le premier coffre de l’opérateur commence à 1, le second à 2, etc. Cette information est optionnelle si l’opérateur ne dispose que d’un seul coffre. La valeur de cette entité est fixée par le coffre lui-même.
26/202

II.3 Liste des types de données de jeu par famille
Rappel des dispositions légales et réglementaires Loi 2010-476 du 12 mai 2010 relative à l’ouverture à la concurrence et à la régulation du secteur des jeux d’argent et de hasard en ligne (ci-après loi n°2010-476) Article 38 I.- Un contrôle permanent de l’activité des opérateurs de jeux ou de paris en ligne agréés et de l’activité de l’opérateur titulaire de droits exclusifs pour son activité de jeux de loterie en ligne est réalisé par l’Autorité nationale des jeux aux fins d’assurer le respect des objectifs définis à l’article L. 320-3 du code de la sécurité intérieure. A cet effet, les opérateurs mettent à la disposition permanente de l’Autorité nationale des jeux des données portant sur :
1° L’identité de chaque joueur, son adresse et son adresse sur un service de communication au public en ligne ;
2° Le compte de chaque joueur, notamment sa date d’ouverture, et les références du compte de paiement mentionné au dernier alinéa de l’article 17 ;
3° Les événements de jeu ou de pari et, pour chaque joueur, les opérations associées ainsi que toute autre donnée concourant à la formation du solde du compte joueur ;
4° Les événements relatifs à l’évolution et à la maintenance des matériels, plates-formes et logiciels de jeux utilisés.
[…] II.-Un contrôle de l’activité des opérateurs titulaires de droits exclusifs au titre de leur activité en réseau physique de distribution est réalisé par l’Autorité nationale des jeux aux fins d’assurer le respect des objectifs de la politique des jeux définis à l’article L. 320-3 du code de la sécurité intérieure. A cette fin, les opérateurs mettent à la disposition permanente de l’Autorité nationale des jeux des données portant sur : 1° Pour les joueurs identifiés : L’identité de chaque joueur, son adresse et son adresse sur un service de communications électroniques au public ;
Le compte de chaque joueur, notamment sa date d’ouverture, et les références du compte de paiement mentionné au dernier alinéa de l’article 17 ;
Les événements de jeu ou de pari et, pour chaque joueur, les opérations associées ainsi que toute autre donnée concourant à la formation du solde du compte joueur ; 2° Les événements relatifs à l’évolution et à la maintenance des matériels, plates-formes et logiciels de jeux utilisés ;

3° L’évaluation de la politique de contrôle mise en place en point de vente, notamment au regard de l’objectif de protection des mineurs ;

4° Les rapports et résultats des contrôles effectués sur les personnes privées exploitant un poste d’enregistrement de jeux de loterie, de jeux de paris sportifs et de paris hippiques et le respect de leurs obligations par celles-ci. Lorsqu’ils constatent un manquement grave d’une de ces personnes à ses obligations légales ou réglementaires, ils en informent sans délai l’Autorité. Celle-ci communique ces informations aux ministres chargés du budget et de l’intérieur ;

5° Les rapports trimestriels sur l’exploitation des jeux sous droits exclusifs. Un arrêté du ministre chargé du budget, pris sur proposition de l’Autorité, approuve le modèle de tableau de bord de ce compte-rendu trimestriel. Décret n° 2010-518 Article 30 Les données que l’opérateur est tenu de mettre à la disposition de l’Autorité nationale des jeux sous forme exhaustive ou agrégée, pour les joueurs sur compte, portent sur : 1° Toute information détenue par l’opérateur concernant chaque joueur, et notamment les informations suivantes : nom de naissance, prénoms, sexe, date et lieu de naissance, adresse de courrier électronique, date d’ouverture du compte joueur et, le cas échéant, adresse postale du domicile, identifiant permettant l’accès au compte joueur, référence du compte de paiement tel que mentionné au dernier alinéa de l’article 17 de la loi du 12 mai 2010 susvisée, sur lequel l’opérateur reversera, le cas échéant, les avoirs du joueur ;
27/202

2° Les opérations de compte réalisées par les joueurs ;
3° Les opérations de jeu réalisées par les joueurs ainsi que toute donnée concourant à la formation du solde du compte joueur ;
II.3.1 Compte joueur (CJ)
TYPE D’ENREGISTREMENT SIGNIFICATION Ouverture de compte OUVINFOPERSO Saisie du détail des informations personnelles (pseudo, identité et adresse) CPTEREF Enregistrement des références du compte de paiement PREFCPTE Saisie des préférences compte joueur OKCONDGENE Acceptation des conditions générales CPTEIDENTITE Validation de l’identité du joueur CPTEADRESSE Validation de l’adresse du joueur OUVOKCONFIRME Confirmation du compte joueur ACCESREFUSE Refus d’accès à la plate-forme de jeu pour un joueur identifié Modification des paramètres du compte MODIFINFOPERSO Modification du détail des informations personnelles PREFCPTE Modification des préférences compte joueur (Idem ouverture de compte) AUTOINTERDICTION Auto interdiction du joueur OKCONDGENE Acceptation conditions générales (idem ouverture de compte) LIMITMISE Limitation des mises du joueur
Clôture de compte CLOTUREDEM Demande de clôture de compte Mouvements financiers sur le compte (hors mises et gains) CPTEALIM Versement d’une somme sur le compte joueur (quelque soit le moyen utilisé) CPTEABOND Mouvement d’alimentation en provenance de l’opérateur sur le compartiment solde (ou abondement du compartiment solde) CPTERETRAIT Retrait d’une somme ou de la totalité du montant depuis le compte joueur vers le compte de paiement CPTEALIMOPE Mouvement d’alimentation en provenance de l’opérateur sur le compartiment bonus (ou abondement du compartiment bonus) CPTEAJUSTOPE Mouvement d’ajustement en provenance de l’opérateur Attributions de lots en nature LOTNATURE Attribution au joueur d’un lot en nature par l’opérateur.
II.3.2 Identification des points de vente
TYPE D’ENREGISTREMENT SIGNIFICATION Ouverture d’un point de vente OUVPOINTDEVENTE Déclaration d’un nouveau point de vente pour l’activité de jeu sur compte sous droits exclusifs
28/202

Modification des informations relatives à un point de vente MODIFPOINTDEVENTE Modification du détail des informations concernant le point de vente Clôture d’un point de vente CLOTUREPOINTDEVENTE Fermeture d’un point de vente
II.3.3 Paris sportifs Type d’agrément : Paris sportifs (PS)
TYPE D’ENREGISTREMENT SIGNIFICATION PASPMISE Mise sur un pari sportif PASPGAIN Gain sur pari sportif PASPANNUL Annulation d’une prise de pari sportif Cas particulier de la « Fantasy League » FAINSCRIT Inscription pour participer à une « Fantasy League » FAJEU Composition d’une ou plusieurs sélections de « Fantasy League » FABILAN Bilan financier suite à la résolution du ou des paris FAGAIN Gain intermédiaire FAACHAT Achat d’un « avantage » de jeu au cours d’une « Fantasy League » FAANNUL Annulation d’une « Fantasy League »
II.3.4 Paris hippiques Type d’agrément : Paris hippiques (PH)
TYPE D’ENREGISTREMENT SIGNIFICATION PAHIMISE Mise sur un pari hippique PAHIGAIN Gain sur pari hippique PAHIANNUL Annulation d’une prise de pari hippique
II.3.5 Poker Type d’agrément : Jeux de cercle (JC)
TYPE D’ENREGISTREMENT SIGNIFICATION POINSCRIT Inscription d’un participant à un jeu de cercle POJEU Déroulement d’une partie lors d’un jeu de cercle POBILAN Bilan financier d’un jeu de cercle POACHAT Achat en cours de jeu POGAIN Gain en cours de jeu POANNUL Annulation d’une participation
II.3.6 Loterie
TYPE D’ENREGISTREMENT SIGNIFICATION LOTIMISE Mise sur un jeu de tirage LOTIGAIN Gain sur un jeu de tirage LOTIBILAN Bilan sur un jeu de tirage LOTIANNUL Annulation d’une prise de jeu sur un jeu de tirage LOJIMISE Mise sur un jeu instantané LOJIGAIN Gain sur un jeu instantané LOJIBILAN Bilan sur un jeu instantané LOJIANNUL Annulation d’une prise de jeu sur un jeu instantané
29/202

II.4 Évènements relatifs au fonctionnement du compte joueur
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 30 Les données que l’opérateur est tenu de mettre à la disposition de l’Autorité nationale des jeux sous forme exhaustive ou agrégée, pour les joueurs sur compte, portent sur :
1° Toute information détenue par l’opérateur concernant chaque joueur, et notamment les informations suivantes : nom de naissance, prénoms, sexe, date et lieu de naissance, adresse de courrier électronique, date d’ouverture du compte joueur et le cas échéant, adresse postale du domicile, identifiant permettant l’accès au compte joueur, référence du compte de paiement tel que mentionné au dernier alinéa de l’article 17 de la loi du 12 mai 2010 susvisée, sur lequel l’opérateur reversera, le cas échéant, les avoirs du joueur ;
2° Les opérations de compte réalisées par les joueurs ;
3° Les opérations de jeu réalisées par les joueurs ainsi que toute donnée concourant à la formation du solde du compte joueur ;[…]
II.4.1 Ouverture de comptes
Lors d’une ouverture de compte, le joueur doit :
- renseigner ses informations personnelles ;
- accepter les conditions générales du site.
Les évènements correspondants doivent être envoyés simultanément au coffre lorsque que le joueur valide son inscription sur le site et qu’il accède à son compte joueur, l’inscription s’entendant ici de l’ouverture du compte provisoire en l’absence d’utilisation des moyens d’identification électronique définis aux 1° et 2° de l’article R. 561-5-1 du code monétaire et financier. Ces évènements ne doivent pas être envoyés au coffre avant validation de l’inscription pour éviter l’enregistrement de comptes non susceptibles d’avoir une activité.
30/202

II.4.1.a Informations personnelles – OUVINFOPERSO
Rappel des dispositions légales et réglementaires Article 17 de la loi n°2010-476 I.- L’entreprise sollicitant l’agrément mentionné à l’article 21 et, pour l’exploitation des jeux de loterie en ligne, la personne morale mentionnée à l’article 137 de la loi n° 2019-486 du 22 mai 2019, précisent les modalités d’accès et d’inscription à leur site de tout joueur et les moyens leur permettant de s’assurer de l’identité de chaque nouveau joueur, de son âge, de son adresse et de l’identification du compte de paiement sur lequel sont reversés ses avoirs. Les entreprises titulaires de droits exclusifs précisent les modalités d’accès et d’inscription de tout joueur à son compte en réseau physique de distribution et les moyens de s’assurer de l’identité de chaque nouveau joueur, de son âge, de son adresse et de l’identification du compte de paiement sur lequel sont reversés ses avoirs. Décret n°2010-518 Article 2 Lorsqu’une personne sollicite l’ouverture d’un compte joueur auprès d’un opérateur agréé de jeux ou de paris en ligne ou d’un opérateur titulaire de droits exclusifs, celui-ci, préalablement à l’ouverture de ce compte, lui demande :
1° De lui communiquer ses nom de naissance, prénoms, date et lieu de naissance ainsi que son adresse postale. L’opérateur peut en outre demander à la personne sollicitant l’ouverture d’un compte de lui communiquer une adresse électronique.
La communication de l’adresse postale du domicile du joueur n’est pas exigée lors de l’ouverture d’un compte joueur en réseau physique de distribution auprès d’un opérateur titulaire de droits exclusifs, sous réserve des dispositions de l’article R. 561-5-3 du code monétaire et financier ;
[…]
Les réponses aux demandes énumérées aux 1° à 3° sont obligatoires. L’opérateur refuse l’ouverture d’un compte à toute personne ne lui ayant pas communiqué l’intégralité des informations requises ci-dessus. Il refuse également l’ouverture d’un compte à toute personne mineure ou faisant l’objet d’une mesure d’interdiction de jeu en application de l’article L. 320-9-1 du code de la sécurité intérieure. Code monétaire et financier Article R 561-5-3 Pour l’application du 2° du I de l’article L. 561-5, et par dérogation à l’article R. 561-5-2, lorsque les mesures prévues aux 1° à 3° de l’article R. 561-5-1 ne peuvent pas être mises en œuvre :
[…] 2° Les personnes mentionnées au 9° de l’article L. 561-2 et celles mentionnées au 9° bis pour leurs jeux et paris en réseau physique de distribution accessibles sans compte joueur vérifient l’identité de leur client en lui demandant communication de la copie d’un document officiel en cours de validité comportant sa photographie et justifiant de son identité et de sa date de naissance. Elles vérifient également son adresse et, lorsque leur client souhaite alimenter son compte ou recevoir ses avoirs par virement, ne procèdent à ces opérations qu’en provenance ou à destination d’un seul compte de paiement ouvert à son nom par le joueur auprès d’un prestataire de services de paiement établi dans un Etat membre de l’Union européenne ou dans un Etat partie à l’accord sur l’Espace économique européen ou dans un pays tiers imposant des obligations équivalentes en matière de lutte contre le blanchiment de capitaux et le financement du terrorisme.
Présentation de l’évènement
L’évènement OUVINFOPERSO constate la saisie par le joueur des éléments d’identification à l’occasion de la saisie du formulaire d’inscription. Il apparaît après la validation des informations saisies par le joueur sur la plate-forme de jeu (vérification de la syntaxe et de la cohérence des données renseignées).
31/202

En termes de cinématique, l’évènement OUVINFOPERSO est le premier évènement de la vie d’un compte joueur : il doit précéder tout autre enregistrement, en termes de date et de numéro de séquence, pour un même identifiant de joueur.
Structure de l’enregistrement en format XML
OUVINFOPERSO Entité XML Min Max Type Description Entête (cf. section II.2.1) Login 1 1 string-64 Identifiant utilisé pour la connexion au compte du joueur Pseudo 1 1 string-64 Pseudonyme utilisé par le joueur Nom 1 1 string-64 Nom de naissance du joueur Prenom 1 2 string-256 Prénoms du joueur Civilite 1 1 Civil Civilité du joueur DateN 1 1 date-aaaammjj Date de naissance du joueur VilleN 1 1 string-64 Ville de naissance du joueur DptN 1 1 Departement Département de naissance du joueur PaysN 1 1 string-64 Pays de naissance du joueur Ad 0 8 string-256 Adresse postale du joueur CP 0 1 Postal Code postal de la ville Ville 0 1 string-64 Ville de l’adresse postale Pays 0 1 string-64 Pays de l’adresse postale TelFixe 0 1 string-32 Numéro de téléphone fixe TelMob 0 1 string-32 Numéro de téléphone mobile Email 1 1 string-64 Adresse électronique Test 0 1 Balise vide Indique si ce compte est un compte de test créé par l’opérateur Info 0 1 string Informations complémentaires
Civil Sous-type Contraintes string La chaîne de caractères doit être égale à l’une des énumérations suivantes : « M », « Mme » désignant respectivement « Monsieur » ou « Madame ».
Departement Sous-type Contraintes string Chaîne de caractères d’une taille comprise entre 2 et 3 caractères. La chaîne peut contenir le format d’un département français, ou la valeur par défaut '99' dans le cas d’un territoire étranger.
Regex : [0-9][0-9AB][0-9]?
Exemple : 59 pour le département du Nord, 2A pour le département de Corse-du-Sud, 971 pour le département d’outre-mer de la Guadeloupe, 99 pour la Belgique.
Postal Sous-type Contraintes string Chaîne de caractères d’une taille de 5 caractères. La chaîne peut contenir le format d’un code postal français ou bien le code officiel géographique d’un territoire étranger.
Regex : (([0-8][0-9AB])|(9[0-9AB]))[0-9]{3}
Exemple : 21000 pour le code postal de la ville de Dijon, 99350 pour le Maroc.
Description Login
32/202

Obligatoire, unique. Identifiant utilisé par le joueur pour se connecter au compte. Cet identifiant est unique et permet d’identifier l’utilisateur. Cet identifiant de Login peut être, par exemple, utilisé pour renseigner le champ IDJoueur de l’entête de la donnée de jeu mais, dans ce cas, ne peut pas faire l’objet d’une modification ultérieure de la part du joueur. Exemple : l’adresse de messagerie électronique peut être utilisée comme identifiant. Pseudo
Obligatoire, unique. Pseudonyme utilisé par le joueur. Le Pseudo est généralement utilisé pour représenter les joueurs lors d’une partie de poker. Le joueur voit ainsi le pseudonyme des autres joueurs de la table. Suivant le mode de fonctionnement de la plate-forme de jeu, le pseudonyme peut être modifié par le joueur au cours de la vie du compte. Nom
Obligatoire, unique. Nom de naissance du joueur (nom patronymique et non pas nom d’usage, le premier étant celui utilisé pour la procédure d’interrogation du fichier des interdits de jeu). Prenom
Obligatoire, multiple. Prénoms du joueur. La première occurrence doit comporter le premier prénom du joueur, autrement dit celui sur la base duquel l’opérateur réalise l’interrogation des interdits de jeu. La seconde occurrence comporte les autres prénoms déclarés par le joueur, séparés par une espace. Remarque : le caractère multiple de cette entité ne pré-suppose naturellement pas des entrées multiples pour le champ prénom du formulaire d’inscription : il a uniquement vocation à isoler le premier prénom d’un joueur, afin de clarifier les paramètres sur la base desquels l’opérateur réalise ses interrogations du fichier des interdits de jeu. Civilite
Obligatoire, unique. Civilité du joueur. DateN
Obligatoire, unique. Date de naissance du joueur. VilleN
Obligatoire, unique. Ville de naissance du joueur. DptN
Obligatoire, unique. Département de naissance du joueur. PaysN
Obligatoire, unique. Pays de naissance du joueur. Ad Optionnel, multiple. Adresse postale du joueur. 8 lignes de 256 caractères sont disponibles. Remarque : Le caractère multiple de cette entité ne présuppose pas des entrées multiples pour le champ relatif à l’adresse postale du formulaire d’inscription. Ce champ est obligatoire pour les joueurs en ligne mais il est optionnel pour les joueurs sur compte sous droits exclusifs uniquement. Cependant ce champ devra être obligatoirement renseigné au moment de la confirmation du compte, il pourra être transmis avec l’évènement MODIFINFOPERSO (cf partie II.4.8.a). CP Optionnel, unique. Code postal de ville de l’adresse postale du joueur. Ce champ est obligatoire pour les joueurs en ligne mais il est optionnel pour les joueurs sur compte sous droits exclusifs uniquement. Cependant ce champ devra être obligatoirement renseigné au moment de la confirmation du compte, il pourra être transmis avec l’évènement MODIFINFOPERSO (cf partie II.4.8.a).
Ville Optionnel, unique. Ville de l’adresse postale du joueur. Ce champ est obligatoire pour les joueurs en ligne mais il est optionnel pour les joueurs sur compte sous droits exclusifs uniquement. Cependant ce champ devra être obligatoirement renseigné au moment de la confirmation du compte, il pourra être transmis avec l’évènement MODIFINFOPERSO (cf partie II.4.8.a).
Pays Optionnel, unique. Pays de l’adresse postale du joueur. Ce champ est obligatoire pour les joueurs en ligne mais il est optionnel pour les jeux les joueurs sur compte sous droits exclusifs uniquement. Cependant ce champ devra être obligatoirement renseigné au moment de la confirmation du compte, il pourra être transmis avec l’évènement MODIFINFOPERSO (cf partie II.4.8.a).
TelFixe
33/202

Optionnel, unique. Numéro de téléphone fixe du joueur. TelMob
Optionnel, unique. Numéro de téléphone mobile du joueur. Email Obligatoire, unique. Adresse de messagerie électronique du joueur. Test
Optionnel, unique. Permet l’identification d’un compte test de l’opérateur. Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Remarques complémentaires :
- 1 : L’identifiant de joueur IDJoueur et la date et l’heure d’enregistrement sont présents dans l’entête donc ils ne sont pas repris dans le descriptif ci-dessus.
- 2 : Sur le site ou l’application de jeu, les informations comme le Login doivent être choisies et validées dès la première étape du processus de création de compte de façon à pouvoir le renseigner dans l’enregistrement en même temps que les informations d’identité.
- 3 : La saisie des informations peut se dérouler en plusieurs étapes (pages web séparées par un clic de type « étape suivante »). Mais l’enregistrement se fait en une seule fois quand les données ont toutes été saisies et validées (page d’affichage des informations pour validation, par exemple).
- 4 : L’opérateur peut choisir d’avoir les champs IDJoueur, Login et Pseudo différents. Le Login et le Pseudo sont rattachés à un IDJoueur : ce dernier est invariable de la création à la clôture du compte du joueur.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.1).
34/202

II.4.1.b Acceptation des conditions générales du site – OKCONDGENE
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 2 Lorsqu’une personne sollicite l’ouverture d’un compte joueur auprès d’un opérateur agréé de jeux ou de paris en ligne ou d’un opérateur titulaire de droits exclusifs, celui-ci, préalablement à l’ouverture de ce compte, lui demande :
[…]
2° De certifier qu’elle a pris connaissance du règlement portant conditions générales de l’offre de jeux ou de paris et qu’elle l’accepte, cette acceptation devant être renouvelée lors de chaque modification du règlement ;
3° Si elle consent à ce que les données personnelles qu’elle confie à l’opérateur fassent l’objet d’utilisations à des fins de prospection commerciale.
La demande prévue au 3° doit être distincte de celle mentionnée au 2°. L’opérateur informe préalablement la personne de la finalité de ces utilisations.
Les réponses aux demandes énumérées aux 1° à 3° sont obligatoires. L’opérateur refuse l’ouverture d’un compte à toute personne ne lui ayant pas communiqué l’intégralité des informations requises ci-dessus. Il refuse également l’ouverture d’un compte à toute personne mineure ou faisant l’objet d’une mesure d’interdiction de jeu en application de l’article L. 320-9-1 du code de la sécurité intérieure. Article 3 Préalablement aux vérifications prévues à l’article 4 prévue à l’article 5, seul peut être ouvert un compte joueur provisoire ne permettant pas à son titulaire d’ordonner le reversement, même partiel, du solde créditeur de ce compte sur son compte de paiement. L’opérateur qui propose l’ouverture d’un compte provisoire informe le joueur qui sollicite l’ouverture d’un tel compte de ses conditions de fonctionnement. Lorsque le joueur sollicite l’ouverture d’un compte provisoire, l’opérateur lui demande d’accepter explicitement ces conditions de fonctionnement.
Présentation de l’évènement L’utilisateur accepte les conditions générales d’utilisation du site et les règlements de jeu du site.
En termes de cinématique, la première occurrence de cet évènement OKCONDGENE doit être concomitante à l’évènement OUVINFOPERSO, et antérieure à tout évènement de jeu, alimentation, retrait, etc.
Toutefois, cet évènement est susceptible de se renouveler à chaque modification des conditions générales d’utilisation et/ou des règlements de jeu : il est obligatoire à l’ouverture du compte, puis se reproduit quand la plate-forme fait, par exemple, évoluer ses conditions et fait accepter les nouvelles conditions à ses clients, ou bien lorsque l’opérateur ajoute un nouvel agrément à son offre et la propose aux comptes joueurs existants.
Structure de l’enregistrement en format XML OKCONDGENE Entité XML Min Max Type Description Entête (cf. section II.2.1) Info 0 1 string Informations complémentaires
Description Info Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
35/202

Un exemple illustratif de l’évènement figure en annexe (partie IV.2.2).
36/202

II.4.2 Modérateurs et seuil de reversement – PREFCPTE
Rappel des dispositions légales et réglementaires
Décret n°2010-518
Article 16
L’opérateur demande au joueur sollicitant l’ouverture d’un compte joueur d’encadrer sa capacité de jeu en fixant, avant son premier dépôt d’argent, le montant total maximal des dépôts qu’il pourra réaliser sur une période de sept jours et, avant sa première mise, le montant total maximal des mises qu’il pourra engager sur une période de sept jours.
Le joueur peut modifier ces limites à tout moment par un dispositif aisément accessible. En cas d’augmentation, la modification prend effet au plus tôt dans un délai de quarante-huit heures à compter de sa saisie par le joueur. En cas de diminution, la modification est d’effet immédiat.
Article 16-1
Pour les jeux de cercle en ligne, le temps de jeu effectif est le cumul du temps passé par un joueur à une table de jeu depuis la distribution des cartes de la première partie à laquelle il participe jusqu’au moment où il quitte la table.
Avant la première mise d’un participant à un jeu de cercle en ligne, l’opérateur demande au joueur d’encadrer sa capacité de jeu par la fixation d’une limite de temps de jeu effectif. Aucune opération de jeu ne peut être réalisée tant que le joueur n’a pas fixé cette limite, qui ne peut être prédéfinie par l’opérateur.
Cette limite s’applique immédiatement au temps de jeu effectif cumulé par période de sept jours.
L’opérateur affiche en permanence un compteur du temps de jeu effectif déjà réalisé sur la période considérée. Il avertit le joueur que cette limite sera bientôt atteinte par l’affichage d’un message d’alerte lorsque 75 % de son temps de jeu s’est écoulé ou au plus tard trente minutes avant l’échéance, puis de nouveau dix minutes avant celle-ci.
Lorsque la limite de temps de jeu que le joueur s’est fixée est atteinte au cours d’une partie de “cash game” au sens du 1° du II de l’article 1er du décret n° 2016-1326 du 6 octobre 2016 relatif aux catégories de jeux de cercle mentionnés au II de
l’article 14 de la loi n° 2010-476 du 12 mai 2010, le joueur ne peut plus, à compter de l’issue de la main, réaliser d’opérations de jeu jusqu’à la fin de la période mentionnée au troisième alinéa.
Lorsque la limite de temps de jeu que le joueur s’est fixée est atteinte pendant un tournoi ou après l’inscription à un tournoi pour lequel le joueur a versé un droit d’entrée, celui-ci ne peut plus, à l’issue de ce tournoi, réaliser d’opérations de jeu jusqu’à la fin de la période visée au troisième alinéa.
Le joueur peut modifier cette limite à tout moment jusqu’au premier avertissement prévu au quatrième alinéa. Lorsqu’il l’augmente, la modification prend effet au plus tôt dans un délai de quarante-huit heures à compter de sa saisie par le joueur. Lorsqu’il la diminue, la modification est d’effet immédiat.
Article 17
Immédiatement après avoir procédé à la vérification de l’identité du joueur prévue à l’article 4, l’opérateur demande au joueur de déterminer un montant au-delà duquel les crédits disponibles inscrits sur son compte joueur et dépassant ce montant sont reversés sur son compte de paiement.
S’il ne peut effectuer ce reversement parce qu’il n’a pas pu procéder aux vérifications prévues à l’article 5, l’opérateur en informe immédiatement le joueur.
Le joueur doit pouvoir en permanence modifier ce montant par un dispositif aisément accessible.
Le terme de modérateur s’entend des différents dispositifs de limites et de seuils devant être fixés par les joueurs.
Présentation de l’évènement
Un joueur doit fixer des limites sur son compte.
L’opérateur doit impérativement proposer au joueur les modérateurs suivants :
un plafond des dépôts susceptibles d’être réalisés par période glissante de sept jours. Ce plafond doit être fixé avant le premier dépôt ;
un plafond des mises susceptibles d’être effectuées par période glissante de sept jours. Ce plafond doit être fixé avant la première mise ;
37/202

un montant au-delà duquel est déclenché un virement automatique des sommes dépassant ce montant sur le compte de paiement. Ce modérateur doit être défini après la vérification de l’identité du joueur ;
une limite de temps de jeu effectif pour les jeux de cercle. Cette limite doit être fixée avant la première mise dans la catégorie « jeu de cercle ».
Structure de l’enregistrement en format XML
PREFCPTE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Compte 0 1 Compte Conditions de retrait automatique pour reversement sur le compte de paiement MiseMax 0 5 MiseMax Conditions du modérateur de mise
DepotMax 0 1 nonNegativeDecimal Modérateur de dépôt
TempsMax 0 1 nonNegativeInteger Modérateur de temps de jeu (au poker)
DateDebut 1 1 date-aammjjhhmmss Date à compter de laquelle le modérateur est effectif Info 0 1 string Informations complémentaires
Description
Compte
Optionnel, unique. Conditions de retrait automatique pour le reversement sur le compte de paiement.
MiseMax
Optionnel, multiple. Conditions du modérateur de mise. Ces champs doivent être renseignés autant de fois qu’il y a de modérateur définit par le joueur.
DepotMax
Optionnel, unique. Montant maximum d’approvisionnement de son compte sur une période glissante de sept jours.
TempsMax
Optionnel, unique. Temps maximum, en minutes, que le joueur accepte de passer sur les jeux de cercle sur une période glissante de 7 jours.
DateDebut
Obligatoire, Unique. Date au format UTC à partir de laquelle le modérateur est effectif.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Structure de l’enregistrement en format XML
Compte
Entité XML Min Max Type Description Min 0 1 nonNegativeDecimal Plafond minimal du compte (somme restante après le retrait automatique) Max 0 1 nonNegativeDecimal Plafond maximal du compte
Description
Min
Optionnel, unique. Montant minimal à conserver sur le compte du joueur.
Max
Optionnel, unique. Montant déclenchant un virement automatique vers le compte de paiement.
38/202

Structure de l’enregistrement en format XML MiseMax Entité XML Min Max Type Description Montant 1 1 nonNegativeDecimal Modérateur de mise TypeAct 1 1 string Agrément associé au modérateur
Description Montant Obligatoire, unique. Montant maximum des mises engagées sur une période glissante de 7 jours. TypeAct Obligatoire, unique. Type d’activité associé à la limite des mises. Ce champ peut prendre les valeurs suivantes :
- « PS » pour les activités liées aux paris sportifs ;
- « PH » pour les activités liées aux paris hippiques ;
- « PO » pour les activités liées au poker ;
- « LO » pour les activités liées aux jeux de loterie.
Ce champ peut prendre plusieurs valeurs si le modérateur de mises est associé à toutes les activités de l’opérateur.
Remarques complémentaires :
- 1 : Cet enregistrement doit être effectué lors de la première saisie d’un modérateur par le joueur ainsi que lors de toute modification de ses préférences.
- 2 : L’enregistrement s’organise en groupes de données. La composition de l’enregistrement dépend des modérateurs mis en place pour l’opérateur et de la manière dont la saisie s’organise sur son site (saisie par pages différentes). Plusieurs données peuvent donc soit être regroupées dans un enregistrement soit donner lieu à plusieurs enregistrements.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.3).
39/202

II.4.3 Confirmation de l’identité du joueur – CPTEIDENTITE
Rappel des dispositions légales et réglementaires
Décret n°2010-518
Article 4
I.La vérification de l’identité de toute personne sollicitant l’ouverture d’un compte joueur auprès d’un opérateur agréé de jeux ou de paris en ligne ou d’un opérateur titulaire de droits exclusifs peut être effectuée en recourant aux moyens
d’identification électronique définis aux 1° et 2° de l’article R. 561-5-1 du code monétaire et financier.
II.-A défaut de mise en œuvre de ces moyens d’identification, toute personne sollicitant l’ouverture d’un compte joueur auprès d’un opérateur agréé de jeux ou de paris en ligne ou d’un opérateur titulaire de droits exclusifs communique à ce dernier, dans le délai maximum de trente jours à compter de la demande d’ouverture du compte, la copie de sa carte nationale d’identité, de son passeport, de son permis de conduire, de son titre de séjour ou de sa carte de résident en cours de validité justifiant de son identité et de sa date de naissance.
Article 12
Le joueur peut rectifier les informations personnelles le concernant.
Lorsque la rectification porte sur les informations relatives à son état civil ou son adresse postale mentionnées au 1° de l’article 2, le joueur communique à l’opérateur, dans le délai de trente jours à compter de cette rectification, les pièces justificatives exigées à l’article 4. Si, à l’expiration de ce délai, ces pièces n’ont pas été communiquées à l’opérateur, celui- ci désactive le compte. Si, dans un délai de soixante jours à compter de la rectification d’informations, ces pièces n’ont pas été communiquées à l’opérateur, celui-ci clôture le compte dans les conditions prévues aux articles 8 et 9.
Dans l’hypothèse où l’opérateur constate une discordance entre les informations saisies par le joueur et les pièces justificatives transmises résultant d’une erreur matérielle de saisie, il en avise sans délai le joueur et lui propose de rectifier ces informations dans un délai de sept jours suivant cet avertissement. Le joueur peut soit procéder lui-même à la rectification des informations initialement saisies en accédant à son compte, soit donner son accord à l’opérateur pour que celui-ci procède à la rectification nécessaire. Dans cette dernière hypothèse, le joueur doit valider la rectification lors de sa prochaine connexion à son compte. A défaut de rectification, l’opérateur clôture le compte sans délai.
Présentation de l’évènement
Après l’ouverture de son compte, l’opérateur doit procéder à la vérification de l’identité du joueur soit en recourant à des moyens d’identification prévus à l’article R 561-5-1 du CMF, soit par vérification de la pièce d’identité que le joueur doit lui adresser dans un délai de 30 jours. Dès que cette vérification est effectuée et que la concordance avec les données renseignées par le joueur est établie,
l’opérateur transmet l’évènement CPTEIDENTITE qui atteste de cette vérification. Cet évènement est envoyé au coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
Remarque :
Cet évènement doit être envoyé au coffre même si la vérification de l’identité intervient alors que le compte joueur a été désactivé ou clôturé.
Structure de l’enregistrement en format XML
CPTEIDENTITE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) NatureVerification 1 1 string Nature de la vérification (sur pièces ou électronique) Info 0 1 string Informations complémentaires
Description
NatureVerification
Obligatoire, unique. Précise la nature de la vérification effectuée. Les valeurs possibles du champ sont :
40/202

« PieceIdentite » lorsque la vérification de l’identité du joueur s’est effectuée sur la base de l’une de ses pièces d’identité (carte d’identité, passeport, permis de conduire, titre de séjour ou carte de résident) ;
« Electronique » lorsque la vérification de l’identité du joueur repose sur des moyens d’identification électroniques.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.4).
41/202

II.4.4 Confirmation de l’adresse – CPTEADRESSE
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 4 I.-La vérification de l’identité de toute personne sollicitant l’ouverture d’un compte joueur auprès d’un opérateur agréé de jeux ou de paris en ligne ou d’un opérateur titulaire de droits exclusifs peut être effectuée en recourant aux moyens d’identification électronique définis aux 1° et 2° de l’article R. 561-5-1 du code monétaire et financier. II.-A défaut de mise en œuvre de ces moyens d’identification, toute personne sollicitant l’ouverture d’un compte joueur auprès d’un opérateur agréé de jeux ou de paris en ligne ou d’un opérateur titulaire de droits exclusifs communique à ce dernier, dans le délai maximum de trente jours à compter de la demande d’ouverture du compte, la copie de sa carte nationale d’identité, de son passeport, de son permis de conduire, de son titre de séjour ou de sa carte de résident en cours de validité justifiant de son identité et de sa date de naissance.
Dans ce délai, le joueur est tenu de justifier de son domicile par l’un des deux moyens suivants : 1° La communication d’un document portant justification de l’adresse postale de son domicile, notamment une quittance de loyer, une facture d’eau, de gaz, d’électricité, d’internet ou de téléphone ou son dernier avis d’imposition ou de non- imposition ;
2° La saisie d’un code d’activation que l’opérateur lui a notifié à l’adresse postale de son domicile.
Présentation de l’évènement Le joueur dispose d’un délai de 30 jours après son inscription pour justifier de l’adresse de son domicile soit en communiquant à l’opérateur un justificatif soit en saisissant le code d’activation que l’opérateur lui a transmis par courrier. Si la vérification de l’adresse s’effectue à partir d’un justificatif de domicile, l’évènement CPTEADRESSE est envoyé au coffre avec la balise dans l’entête. Si elle s’effectue par saisie du code d’activation, l’évènement est envoyé sans balise .
Remarque : Cet évènement doit être envoyé au coffre même si la vérification de l’adresse intervient alors que le compte joueur a été désactivé ou clôturé.
Structure de l’enregistrement en format XML CPTEADRESSE Entité XML Min Max Type Description Entête (cf. section II.2.1) Info 0 1 string Informations complémentaires
Description Info Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.2.5).
42/202

II.4.5 Confirmation du compte – OUVOKCONFIRME
Présentation de l’évènement
Suite à la transmission des pièces nécessaires par le joueur et à leur vérification par l’opérateur, le compte peut être validé.
Cet évènement est envoyé au coffre par l’opérateur, en incluant la balise , lorsque celui-ci change le statut du compte de non-confirmé à confirmé.
Structure de l’enregistrement en format XML
OUVOKCONFIRME
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Info 0 1 string Informations complémentaires
Description
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.6).
43/202

II.4.6 Références du compte de paiement – CPTEREF
Rappel des dispositions légales et réglementaires
Loi n° 2010-476
Article 17
[…]VI.-Les avoirs du titulaire d’un compte joueur auprès de l’opérateur ne peuvent être reversés que sur un seul compte de paiement ouvert par le joueur auprès d’un prestataire de services de paiement établi dans un Etat membre de l’Union européenne ou un Etat partie à l’accord sur l’Espace économique européen ayant conclu avec la France une convention contenant une clause d’assistance administrative en vue de lutter contre la fraude et l’évasion fiscales. Le reversement de ces avoirs ne peut être réalisé que par virement vers ce compte de paiement.
Décret n°2010-518
Article 5
Le reversement des avoirs du compte joueur en ligne sur le compte de paiement de son titulaire ne peut avoir lieu avant que l’opérateur ait reçu un document portant références du compte de paiement, mentionné au VI de l’article 17 de la loi du 12 mai 2010, attestant qu’il est ouvert au nom du joueur.
Présentation de l’évènement
La pièce justificative des références du compte de paiement, ouvert au nom du titulaire du compte joueur et répondant aux conditions précisées à l’article 17 de la loi du 12 mai 2010, doit être transmise avant tout retrait. L’évènement correspondant doit être envoyé dès sa validation par l’opérateur.
Structure de l’enregistrement en format XML
CPTEREF
Entité XML Min Max Type Description
Entête (cf. section II.2.1) PspCib 1 1 cib Code interbancaire (CIB) associé au prestataire de service de paiement par l’ACPR PspLib 1 1 string-256 Libellé associé au prestataire de service de paiement PspCpteRef 0 1 string-256 Référence du compte (si différent
d’un IBAN) PspIban 0 1 iban Référence du compte (si IBAN)
Info 0 1 string Informations complémentaires
Description
PspCib
Obligatoire, unique. Identifiant unique du prestataire de service de paiement. Ce code, dit CIB, est attribué par l’ACPR et est consultable sur le site internet https://acpr.banque-france.fr. Le code CIB est une donnée d’enrichissement, il est donc renseigné par le capteur. Pour les établissements n’ayant pas de code attribué par l’ACPR mais répondant aux conditions de l’article 17 de la loi du 12 mai 2010 le champ CIB doit être renseigné avec la valeur « 00000 ».
PspLib
Obligatoire, unique. Libellé associé au code CIB : il peut s’agir d’un libellé déterminé par la plate-forme de jeu ou bien, par défaut, du libellé associé par l’ACPR au CIB. Le format de la référence est spécifique au prestataire de service de paiement.
PspCpteRef
Optionnel, unique. Référence du compte de paiement chez le prestataire de service de paiement, si cette référence est différente d’un IBAN : le format de la référence est spécifique au prestataire de service de paiement.
PspIban
44/202

Optionnel, unique. Référence du compte de paiement chez le prestataire de service de paiement, s’il s’agit d’un IBAN. Le format est défini dans la norme ISO 13616 et doit impérativement être respecté.
L’une ou l’autre des entités PspCpteRef et PspIban doit impérativement figurer dans l’évènement.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Remarque : Toute modification des références du compte de paiement doit être portée à la connaissance de l’ANJ par la transmission d’un nouvel enregistrement CPTEREF avant tout reversement vers ce nouveau compte
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.2.7).
45/202

II.4.7 Refus d’accès – ACCESREFUSE
Présentation de l’évènement Le refus d’accès signifie que le joueur a saisi correctement ses identifiant / login et mot de passe mais qu’il ne peut pas accéder aux fonctions du site de jeu en ligne. Cet évènement doit donc être généré si et seulement si le joueur est correctement authentifié – l’ouverture d’une session applicative est d’ailleurs un pré-requis au renseignement correct de l’entité IDJoueur dans l’évènement.
En particulier, la génération d’un évènement ACCESREFUSE pour une erreur d’authentification (ex : mot de passe incorrect) est formellement proscrite.
Plusieurs situations peuvent conduire à un refus d’accès :
• refus d’ouverture de session, car le compte a été clôturé pour cause de non-réception des pièces justificatives au terme du délai règlementaire ou pour cause de rejet des pièces justificatives envoyées ;
• refus d’ouverture de session car le joueur est inscrit sur la liste des interdits de jeu, ;
• refus d’ouverture de session car le joueur s’est auto-interdit de jeu ;
• refus d’ouverture de session car le compte est clôturé.
Structure de l’enregistrement en format XML ACCESREFUSE Entité XML Min Max Type Description Entête (cf. section II.2.1) CauseRefus 0 1 string Cause du refus TypeRefus 1 1 string-1024 Type de cause du refus Info 0 1 string Informations complémentaires
Description CauseRefus Optionnel, unique. Message indiquant la cause du refus tel qu’il est indiqué au joueur. Ce champ est obligatoire lorsque que les valeurs du champ TypeRefus sont «OpVerrouille », «Cloture » et « Autre ». TypeRefus Obligatoire, unique. Précise la catégorie du refus, si applicable. Les valeurs possibles du champ sont :
« DelaiIdentite », lorsque les pièces justificatives n’ont pas été reçues au terme du délai règlementaire ;
« RejetIdentite », lorsqu’il y a rejet des pièces justificatives envoyées ;
« Interdit », lorsque le joueur est inscrit dans la liste des interdits de jeu ;
« AutoInterdit » lorsque le joueur s’est auto-exclu de jeu temporairement ;
« Verrouille » lorsque le compte du joueur est désactivé par l’opérateur (lorsque le joueur ne transmet pas ses pièces dans le délai prévu par exemple) ;
« OpVerrouille » lorsque le compte du joueur a été verrouillé par l’opérateur (pour suspicion de fraude ou de blanchiment par exemple) ;
« Cloture » lorsque le compte est clôturé à l’initiative du joueur ;
« Autre » dans les autres cas. La nature du refus est alors précisée dans l’entité CauseRefus. Info Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.8).
46/202

II.4.8 Modification du compte joueur
II.4.8.a Rectification des informations personnelles – MODIFINFOPERSO
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 4 Dans l’hypothèse où l’opérateur constate une discordance entre les informations saisies par le joueur et les pièces justificatives transmises résultant d’une erreur matérielle de saisie, il en avise sans délai le joueur et lui propose de rectifier ces informations dans un délai de sept jours suivant cet avertissement. Le joueur peut soit procéder lui-même à la rectification des informations saisies en accédant à son compte, soit donner son accord à l’opérateur pour que celui-ci procède à la rectification nécessaire. Dans cette dernière hypothèse, le joueur doit valider la rectification lors de sa prochaine connexion à son compte. A défaut de rectification, l’opérateur clôture le compte sans délai. Article 12 Le joueur peut rectifier les informations personnelles le concernant. Lorsque la rectification porte sur les informations relatives à son état civil ou son adresse postale mentionnées au 1° de l’article 2, le joueur communique à l’opérateur, dans le délai de trente jours à compter de cette rectification, les pièces justificatives exigées à l’article 4. Si, à l’expiration de ce délai, ces pièces n’ont pas été communiquées à l’opérateur, celui- ci désactive le compte. Si, dans un délai de soixante jours à compter de la rectification d’informations, ces pièces n’ont pas été communiquées à l’opérateur, celui-ci clôture le compte dans les conditions prévues aux articles 8 et 9. Dans l’hypothèse où l’opérateur constate une discordance entre les informations saisies par le joueur et les pièces justificatives transmises résultant d’une erreur matérielle de saisie, il en avise sans délai le joueur et lui propose de rectifier ces informations dans un délai de sept jours suivant cet avertissement. Le joueur peut soit procéder lui-même à la rectification des informations initialement saisies en accédant à son compte, soit donner son accord à l’opérateur pour que celui-ci procède à la rectification nécessaire. Dans cette dernière hypothèse, le joueur doit valider la rectification lors de sa prochaine connexion à son compte. A défaut de rectification, l’opérateur clôture le compte sans délai.
Présentation de l’évènement Les informations du compte joueur peuvent être modifiées après l’ouverture d’un compte.
Une modification des coordonnées personnelles, qu’elle soit faite en ligne ou hors-ligne (i.e. par l’opérateur), doit entraîner le calcul d’une nouvelle empreinte du joueur et une nouvelle interrogation du fichier des interdits.
Dans l’hypothèse où l’opérateur constate une discordance entre les informations saisies par le joueur et les pièces justificatives transmises, et que cette discordance résulte d’une erreur matérielle de saisie, le joueur bénéficie d’un droit de rectification des données à caractère personnel, selon la procédure décrite dans le décret n°2010-518, et peut donc rectifier ou bien faire rectifier par l’opérateur les informations personnelles le concernant.
Toute modification ou rectification des informations du compte doit impérativement faire l’objet d’un enregistrement au niveau du support matériel d’archivage.
Selon le choix du joueur, la correction des coordonnées personnelles peut être à l’initiative de l’opérateur et transmise sans acquittement du joueur. Dans ce cas la balise doit être présente dans l’entête. Suite à cette transmission « supervisée », l’opérateur pourra aussi présenter le MODIFINFOPERSO au joueur pour validation ce qui entrainera une 2ème transmission qui sera alors « non supervisée ».
Seules les modifications portant sur des éléments relevant de l’enregistrement OUVINFOPERSO sont susceptibles de générer l’évènement MODIFINFOPERSO. Pour les modifications des modérateurs ou des références du compte de paiement ainsi que pour l’acceptation de nouvelles conditions générales, il convient d’utiliser les évènements correspondants.
47/202

Structure de l’enregistrement en format XML
MODIFINFOPERSO
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Login 1 1 string-64 Identifiant utilisé pour la connexion au compte du joueur Pseudo 1 1 string-64 Pseudonyme utilisé par le joueur
Nom 1 1 string-64 Nom de naissance du joueur
Prenom 1 2 string-256 Prénoms du joueur
Civilite 1 1 Civil Civilité du joueur
DateN 1 1 date-aaaammjj Date de naissance du joueur
VilleN 1 1 string-64 Ville de naissance du joueur
DptN 1 1 Departement Département de naissance du joueur
PaysN 1 1 string-64 Pays de naissance du joueur
Ad 0 8 string-256 Adresse postale du joueur
CP 0 1 Postal Code postal de la ville
Ville 0 1 string-64 Ville de l’adresse postale
Pays 0 1 string-64 Pays de l’adresse postale
TelFixe 0 1 string-32 Numéro de téléphone fixe
TelMob 0 1 string-32 Numéro de téléphone mobile
Email 1 1 string-64 Adresse électronique
Test 0 1 Balise vide Indique si ce compte est un compte de test utilisé créé par l’opérateur Info 0 1 string Informations complémentaires
Description
Cf. la description de OUVINFOPERSO (paragraphe II.4.1.a)
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.9).
II.4.8.b Modification des préférences
Il convient d’utiliser l’enregistrement « PREFCPTE ».
II.4.8.c Acceptation de nouvelles conditions générales
Il convient d’utiliser l’enregistrement « OKCONDGENE ».
48/202

II.4.9 Déclaration d’auto-interdiction du joueur – AUTOINTERDICTION
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 19 L’opérateur met en permanence à la disposition du joueur de manière aisément accessible un dispositif lui permettant de demander son exclusion du jeu. Le joueur détermine la durée de son exclusion, qui ne peut être inférieure à vingt-quatre heures ni supérieure à douze mois. Lorsque le joueur demande son exclusion du jeu, celle-ci est d’effet immédiat. Dans l’hypothèse où un joueur demande la clôture de son compte pendant une période d’auto-exclusion, il ne peut en ouvrir un nouveau pendant la durée restant à courir de ladite exclusion.
Présentation de l’évènement Un joueur peut s’interdire / s’exclure pendant une durée de 24h minimum à 12 mois maximum de l’accès au jeu. Cette auto-exclusion empêche le titulaire du compte d’engager des mises mais ne fait pas obstacle à l’accès à son compte joueur. Les tentatives d’accès aux fonctions de jeu doivent être refusées au joueur et générer un évènement ACCESREFUSE, assorti de la cause du refus « AutoInterdit ».
Structure de l’enregistrement en format XML
AUTOINTERDICTION Entité XML Min Max Type Description Entête (cf. section II.2.1) DateModif 1 1 date-aammjjhhmmss Date de prise en compte de la demande d’auto-interdiction Duree 1 1 nonNegativeInteger Durée d’auto-interdiction Unite 1 1 string Unité de la durée d’auto-interdiction DateFin 1 1 date-aammjjhhmmss Date de fin d’auto-interdiction Info 0 1 string Informations complémentaires
Description DateModif Obligatoire, unique. Date de prise en compte de la demande d’auto-interdiction. L’auto-interdiction est à effet immédiat : cette date devrait donc correspondre, à la minute près, à la date de l’évènement. La date de l’évènement est au format UTC, elle est donc susceptible de différer de la date affichée au joueur, suivant sa localisation.
Duree Obligatoire, unique. Durée d’exclusion pendant laquelle l’auto-exclusion s’applique. Selon les modalités définies par l’opérateur dans les conditions générales d’utilisation, cette durée peut être proposée au joueur en jours, en semaines, en mois ou en année. Unite Obligatoire, unique. Unité de la durée d’auto-interdiction choisie par le joueur. Les valeurs possibles du champ sont : « J
», « S », « M » ou « A » désignant respectivement « Jours », « Semaines », « Mois » ou « Année ». DateFin Obligatoire, unique. Date de fin de l’auto-interdiction. Cette date est au format UTC, elle est donc susceptible de différer de la date affichée au joueur, suivant sa localisation. Dans tous les cas, le joueur auto-interdit est autorisé à rejouer seulement après la DateFin. Info
49/202

Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.10).
50/202

II.4.10 Limitation des mises d’un joueur – LIMITIMISE
Présentation de l’évènement Si l’opérateur venait, pour une raison ou une autre, à limiter l’activité d’un joueur de son propre chef, un évènement LIMITMISE doit être envoyé pour préciser les modalités et les raisons de cette limitation. A noter que l’existence de cet évènement ne préjuge en rien de la légalité ou non de telles limitations.
Structure de l’enregistrement en format XML
LIMITMISE Entité XML Min Max Type Description Entête (cf. section II.2.1) DateDebut 1 1 date-aammjjhhmmss Date de début de la limitation DateFin 1 1 date-aammjjhhmmss Date de fin de la limitation Nature 1 1 string Nature de la limitation Motif 1 1 string Motif de la limitation Info 0 1 string Informations complémentaires
Description DateDebut Obligatoire, unique. Date de début de la limitation La date de l’évènement est au format UTC, elle est donc susceptible de différer de la date affichée au joueur, suivant sa localisation. DateFin Obligatoire, unique. Date de début de la limitation La date de l’évènement est au format UTC, elle est donc susceptible de différer de la date affichée au joueur, suivant sa localisation.
Nature Obligatoire, unique. Nature de la limitation. L’opérateur précise dans ce champ les modalités de l’interdiction (par exemple limitation des mises quotidiennes à un seuil). Motif Obligatoire, unique. Raison pour laquelle l’opérateur a mis en place cette limitation. Info Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.11).
51/202

II.4.11 Clôture du compte joueur – CLOTUREDEM
Rappel des dispositions légales et réglementaires
Décret n°2010-518
Article 7
Sans préjudice des cas mentionnés aux articles 4, et 12, ainsi que des autres cas de clôture d’un compte pouvant être prévus dans le règlement portant conditions générales de l’offre de jeux ou de paris, l’opérateur clôture sans délai un compte joueur lorsque son titulaire :
1° En fait la demande ;
2° Lui communique, après l’ouverture d’un compte joueur, des pièces comportant des informations ne correspondant pas à celles qu’il a saisies lors de l’ouverture du compte, si cette discordance ne résulte pas d’une erreur matérielle de saisie ;
3° Lui communique, aux fins de rectification des informations associées à son compte joueur dans les conditions prévues par l’article 12, des pièces dont les informations ne correspondent pas à celles qu’il a saisies, si cette discordance ne résulte pas d’une erreur matérielle de saisie ;
4° Vient à être interdit de jeu en application de la réglementation en vigueur ;
5° N’a pas réalisé, dans les douze derniers mois, d’opération de jeu ou de pari.
Article 8
L’opérateur clôturant un compte joueur provisoire informe le joueur du motif de cette clôture et de la mise en œuvre des dispositions prévues ci-dessous dont il reproduit les termes dans sa communication.
Lorsque le compte provisoire clôturé présente un solde créditeur, l’opérateur met en réserve sans délai la somme correspondante, pour une durée de six ans à compter de la clôture du compte.
Durant cette période, et sans préjudice de l’application de l’article L. 561-16 du code monétaire et financier dans les conditions prévues à l’article 9, le titulaire du compte peut obtenir le versement du montant du solde créditeur en communiquant à l’opérateur les pièces exigées à l’article 4 ainsi que les références du compte de paiement sur lequel
l’opérateur reversera ses avoirs, sauf si ces pièces permettent d’établir qu’il n’était pas autorisé à jouer au moment où le compte provisoire était actif ou, le cas échéant, si les discordances entre les informations saisies par le joueur et les pièces justificatives transmises ne résultent pas d’une erreur matérielle de saisie.
Article 9
L’opérateur clôturant un compte joueur non provisoire :
1° Le cas échéant, reverse immédiatement son solde créditeur sur le compte de paiement du joueur sous réserve que ce dernier lui en ait communiqué les références ; cette opération peut toutefois être différée, en application de l’article L. 561- 16 du code monétaire et financier, si l’opérateur soupçonne qu’elle est liée au blanchiment de capitaux ou au financement du terrorisme ;
2° Informe le joueur de la clôture de son compte et du motif de cette clôture, par tout moyen à sa disposition et dans un délai de trois jours ouvrés ; il précise, le cas échéant, le montant des sommes qu’il a reversées sur son compte de paiement.
L’opérateur faisant application de l’article L. 561-16 du code monétaire et financier dans le cas prévu au 1° est tenu
d’émettre la déclaration prévue à l’article L. 561-15 du même code.
Article 10
L’opérateur met à disposition du joueur une procédure simple et aisément accessible lui permettant de demander à tout moment la clôture de son compte joueur.
52/202

Présentation de l’évènement
Cet évènement est généré lors de la survenance d’une clôture d’un compte effectuée à l’initiative du joueur ou de l’opérateur. La clôture est à effet immédiat :
Remarque complémentaire :
En cas de clôture à l’initiative de l’opérateur (exemples : absence de validation du compte, inscription sur la liste des interdits de jeu, absence d’opération de jeu ou de pari dans les 12 derniers mois), l’évènement CLOTUREDEM est transmis immédiatement au coffre en incluant la balise dans l’entête.
Structure de l’enregistrement en format XML
CLOTUREDEM
Entité XML Min Max Type Description
Entête (cf. section II.2.1) SoldeClos 1 1 decimal Solde à la clôture du compte
TypeCloture 1 1 string-64 Motif de la clôture du compte
Info 0 1 string Informations complémentaires
Description
SoldeClos
Obligatoire, unique. Montant du compartiment solde du compte joueur au moment de la clôture du compte.
TypeCloture
Obligatoire, unique. Ce champ précise les motifs de la clôture du compte. Les valeurs possibles du champ sont :
«Joueur», lorsque la clôture est à l’initiative du joueur ;
«DelaisIdentite», lorsque que l’opérateur n’a pas reçu les pièces d’identité du joueur dans les délais ;
«DelaisAdresse», lorsque que l’adresse n’est pas validé dans les délais ;
«Inactivite», lorsque le compte est clos suite à l’inactivité du joueur pendant 12 mois consécutifs;
«Interdits», lorsque le compte est clos en raison de la présence du joueur dans la liste des interdits de jeu ;
«Autre» le champ info servira alors à préciser la nature exacte.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.12).
53/202

II.4.12 Alimentation et retrait sur le compte du joueur
II.4.12.a Description générale
Dans les données tracées sur le support matériel d’archivage, les évènements de jeu concernant les montants distingueront les deux compartiments suivants :
Le compartiment solde qui présente le montant du compte joueur pouvant être engagé dans un jeu ou retiré sur le compte de paiement du joueur (retrait) ;
Le compartiment bonus qui présente le montant du compte joueur réservé exclusivement pour le jeu (crédit de jeu) et ne pouvant être retiré. Il s’agit d’un montant disponible immédiatement mais exclusivement pour effectuer une opération de jeu : son utilisation peut être soumise à conditions.
Les opérateurs ont la possibilité de distribuer des bonus et d’effectuer des abondements. Ces mécanismes se déclinent en trois types :
l’abondement de compte est la pratique par laquelle l’opérateur augmente l’un des deux compartiments du compte joueur. Il s’agit d’un crédit offert à la suite d’un jeu ou non. On distingue donc l’abondement de compte :
o sur le compartiment bonus (bonus apporté par l’opérateur). Ce montant doit être misé et ne peut pas être retiré du compte pour reversement sur le compte de paiement,
o sur le compartiment solde (montant apporté par l’opérateur). Ce montant apparaît sur le solde du compte joueur. Il peut être misé ou retiré sur le compte de paiement du joueur ;
l’abondement de mise (mise apportée par l’opérateur) est celui par lequel l’opérateur augmente la mise du joueur. Il doit précéder une action de jeu ;
l’abondement de gain (gain apporté par l’opérateur) est le complément de gain apporté par l’opérateur. Il doit être précédé par une action de jeu.
Le montant du compartiment solde du compte joueur est calculé en ajoutant :
le montant des versements faits par le joueur avec ses moyens de paiement ;
les gains du joueur suite à sa participation aux jeux ;
les annulations éventuelles de la participation d’un joueur aux jeux ;
les abondements de gain effectués par l’opérateur ;
les abondements de compte par l’opérateur (hors bonus non retirable). et soustrayant :
les mises du joueur ;
le montant des reversements vers le compte de paiement du joueur (retraits) ;
Un mécanisme d’ajustement des compartiments solde et bonus du compte joueur est également prévu : il permet la correction, par l’opérateur, des erreurs susceptibles de se produire sur ces compartiments et d’assurer la cohérence de leur suivi.
On ne distingue pas l’origine des sommes (versement initial, gain ou abondement) dans le compartiment « solde ».
NB :
La notion de bonus conditionnel n’est pas prise en compte via les données à mettre à disposition par le support matériel d’archivage : Si l’opérateur met en place ce type de bonus, et sous réserve de leur conformité juridique, ils donneront lieu à la génération d’évènement CPTEALIMOPE) lorsque leurs conditions seront remplies et que les sommes correspondantes deviennent exigibles par le joueur ;

Pour les paris « gratuits » l’opérateur doit créditer le compartiment bonus du montant attribué au joueur via l’évènement CPTEALIMOPE. Lors de la mise du joueur il faut préciser dans le champ BonusNom la mention « pari gratuit ». Si le pari est gagnant il est toléré que la mise soit déduite du gain payé au joueur soit un gain correspondant à la mise*(cote-1).
54/202

Moyens de Compte de paiement autorisés paiement du joueur
retrait versement
abondement de gain Compartiment solde gain miseJeu
Compartiments bonus abondement (par agrément) de bonus
abondement abondement de solde de bonus abondement de mise
Offre opérateur
Figure 5 – Alimentation et retrait du compte joueur
Exemple 1
Un opérateur de paris sportifs fait une offre commerciale appelée « bonus d’inscription » à hauteur de 100% du montant du premier versement du joueur pour toute ouverture d’inscription. Le joueur ne peut retirer le montant de ce « bonus d’inscription » sur son compte de paiement, mais doit le placer sur un pari sportif. Ce type de mécanisme est un abondement de compte sur le compartiment bonus.
Exemple 2
Un opérateur de paris sportifs fait une offre commerciale appelée « spéciale inscription » à hauteur de 100% du montant du premier versement du joueur pour toute ouverture d’inscription. La somme est libre d’utilisation : le joueur peut la retirer sur son compte de paiement ou la placer sur un pari. Ce type de mécanisme est un abondement de compte sur le compartiment solde.
Exemple 3
Un opérateur de poker fait une offre commerciale appelée « rake back ». Une somme d’argent est versée au joueur proportionnellement aux mises engagées dans les pots des parties réalisées (gagnées et perdues). La somme est libre d’utilisation : le joueur peut la retirer sur son compte de paiement ou l’utiliser pour de nouvelles mises ». Ce type de mécanisme est un abondement de compte sur le compartiment solde.
Exemple 4
Un opérateur de paris hippiques fait une offre commerciale appelée « doubler vos gains ». Durant une courte période de
l’année, l’opérateur double les gains d’un pari gagné. Ce type de mécanisme est un abondement de gain.
Exemple 5
Un opérateur de paris sportifs fait une offre commerciale appelée « pari moitié prix ». Durant une courte période de l’année, l’opérateur complète la moitié pour chaque mise d’un pari sportif. Ce type de mécanisme est un abondement de mise.
55/202

Exemple 6
Un opérateur de poker fait une offre de fidélisation. Pour chaque tournoi ou partie d’argent disputé par le joueur, un point de fidélité est gagné. Le support matériel d’archivage n’enregistre pas les évènements liés au calcul de point de fidélité. Après 1000 points accumulés, le joueur bénéficie d’un « bonus de fidélité » de 100 euros qu’il peut jouer ou retirer sur son compte. Le support matériel d’archivage enregistre un abondement de compte sur le compartiment solde une fois que le montant est transféré.
Exemple 7
Un opérateur de poker possède une offre de fidélisation. Pour chaque tournoi ou partie d’argent disputé par le joueur, un point de fidélité est gagné. Un tournoi gratuit est ouvert, mais l’inscription au tournoi nécessite de consommer 50 points. Le support matériel d’archivage n’enregistre pas les évènements liés au calcul de point de fidélité. A l’inscription au tournoi, le support matériel d’archivage enregistrera un abondement de mise dont le montant représentera la somme engagée par l’opérateur pour un joueur.
56/202

II.4.12.b Alimentation du compte joueur – CPTEALIM
Présentation de l’évènement
Le joueur dispose d’un compte chez l’opérateur, dont il peut alimenter le compartiment solde par versement (en euros) à l’aide d’un moyen de paiement autorisé. L’évènement est généré dès que l’alimentation est effective.
Remarque
Si un délai de traitement est nécessaire pour rendre effective l’alimentation (par exemple le temps qu’un virement soit effectué), le CPTEALIM est transmis au moment de la date effective sans acquittement de la part du joueur et en incluant la balise dans l’entête. Il est dans ce cas nécessaire de renseigner les différentes valeurs de date et notamment le champ DateDemande qui diffèrera alors du champ DateEffective
Structure de l’enregistrement en format XML
CPTEALIM
Entité XML Min Max Type Description
Entête (cf. section II.2.1) IDRef 1 1 string-256 Identifiant de la transaction
DateDemande 0 1 date-aammjjhhmmss Date de la demande d’alimentation de compte DateEffective 0 1 date-aammjjhhmmss Date effective d’alimentation du compte SoldeAvant 1 1 decimal Solde avant l’alimentation du compte
SoldeMouvement 1 1 nonNegativeDecimal Montant du versement
SoldeApres 1 1 decimal Solde après l’alimentation du compte
MoyenPaiement 1 1 string Moyen de paiement utilisé
TypeMoyenPaiement 1 1 string-32 Type de moyen de paiement utilisé
Info 0 1 string Informations complémentaires
Description
IDRef
Obligatoire, unique. Code technique interne permettant d’identifier la transaction sur la plate-forme de jeu.
DateDemande
Optionnel, unique. Date au format UTC à laquelle la demande d’alimentation de compte a été réalisée.
DateEffective
Optionnel, unique. Date au format UTC à laquelle le compte a été alimenté.
SoldeAvant
Obligatoire, unique. Montant du compartiment solde du compte joueur avant le versement.
SoldeMouvement
Obligatoire, unique. Montant du versement.
SoldeApres
Obligatoire, unique. Montant du compartiment solde du compte joueur après le versement.
MoyenPaiement
Obligatoire, unique. Moyen de paiement utilisé pour le versement (exemple : visa, skrill, paypal, ou paysafecard) .
TypeMoyenPaiement
Obligatoire, unique. Précise le type de moyen de paiement. Les valeurs possibles du champ sont :
« CarteBancaire » si le versement est fait à l’aide d’une carte de paiement (exemple : carte bleue VISA) ;
« Virement » si le versement est fait à l’aide d’un virement depuis le compte de paiement ;
« Intermediaire » si un intermédiaire réalise l’opération de versement (exemple : Paypal) ;
« MonnaieElectronique » si le versement est fait à l’aide de monnaie électronique (exemple : carte prépayée).
« Espece » si le versement est fait en liquide (pour les alimentations effectuées en point de vente pour les joueurs sur compte sous droits exclusifs uniquement ;
57/202

« Cheque » si le versement est fait en chèque (pour les alimentations effectuées en point de vente pour les joueurs sur compte sous droits exclusifs uniquement) ;
« RecepisseGagnant » si le versement est fait par le dépôt d’un récépissé gagnant (pour les alimentations effectuées en point de vente pour les joueurs sur compte sous droits exclusifs uniquement). Dans ce cas, le champ Info devra comporter toutes informations permettant d’identifier la provenance du gain (course, type de pari, mise…).
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Remarques
Le type de moyen de paiement utilisé est conservé, mais on ne conserve pas l’identification précise du moyen de paiement (ex : numéro de carte, etc.).
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.13).
58/202

II.4.12.c Retrait du compte joueur – CPTERETRAIT
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 15 Sans préjudice des clauses liées à la régularité du jeu prévues dans le règlement portant conditions générales de l’offre de jeux et de paris, l’opérateur crédite immédiatement le compte joueur en ligne ou en réseau physique de distribution des gains réalisés ainsi que des sommes versées par son titulaire, dès réception des fonds, après vérification que l’instrument de paiement permettant l’approvisionnement du compte joueur satisfait aux conditions prescrites au IV de l’article 17 de la loi du 12 mai 2010 susvisée. Toutefois, l’opération de crédit du compte joueur peut être différée, en application de l’article L. 561-16 du code monétaire et financier, si l’opérateur soupçonne qu’elle est liée au blanchiment de capitaux ou au financement du terrorisme. L’opérateur reverse immédiatement sur le compte de paiement du joueur, sur demande de ce dernier ou par l’effet des dispositions de l’article 17, les sommes figurant sur son compte joueur. Cette opération peut toutefois être différée, en application de l’article L. 561-16 du code monétaire et financier, si l’opérateur soupçonne qu’elle est liée au blanchiment de capitaux ou au financement du terrorisme. L’opérateur faisant application de l’article L. 561-16 du code monétaire et financier dans les cas prévus au présent article est tenu d’émettre la déclaration prévue à l’article L. 561-15 du même code.
Présentation de l’évènement Cet évènement permet de constater le retrait d’une partie ou de la totalité du compartiment solde du compte d’un joueur.
Un retrait peut être initié par le joueur ou par la plate-forme de jeu, dans le cas où le modérateur de retrait automatique est atteint, lors d’un reversement du solde concomitant à la demande de clôture ou après clôture d’un compte provisoire si le joueur envoie les pièces nécessaires et que les conditions de l’article 17 de la loi sont remplies. Elle se fait exclusivement à destination du compte de paiement du joueur.
Cet évènement est généré lorsque le retrait est effectif sur le compartiment solde du joueur.

Remarque Lorsque le joueur n’a plus la possibilité de réaliser cette action (exemple : le compte est clos) ou lorsque le retrait est déclenché automatiquement (modérateur de retrait atteint), le CPTERETRAIT est transmis immédiatement au coffre sans acquittement, en incluant la balise dans l’entête.
Structure de l’enregistrement en format XML CPTERETRAIT Entité XML Min Max Type Description Entête (cf. section II.2.1) IDRef 1 1 string-256 Identifiant de la transaction DateDemande 1 1 date-aammjjhhmmss Date de la demande de retrait SoldeDemande 1 1 nonNegativeDecimal Montant du retrait demandé SoldeAvant 1 1 decimal Solde du joueur avant le retrait SoldeMouvement 1 1 nonNegativeDecimal Montant du retrait SoldeApres 1 1 decimal Solde du joueur après le retrait Info 0 1 string Informations complémentaires
59/202

Description
IDRef
Obligatoire, unique. Code technique interne permettant d’identifier la transaction sur la plate-forme de jeu.
DateDemande
Obligatoire, unique. Date au format UTC à laquelle la demande de retrait sur le compte a été demandée.
SoldeDemande
Obligatoire, unique. Montant du retrait demandé par le joueur. Ce montant peut différer de celui retiré du compte joueur.
SoldeAvant
Obligatoire, unique. Montant du compartiment solde du compte joueur avant le retrait vers son compte de paiement.
SoldeMouvement
Obligatoire, unique. Montant du retrait (débit de son compte joueur).
SoldeApres
Obligatoire, unique. Montant du compartiment solde du compte joueur après le retrait vers son compte de paiement.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.14).
60/202

II.4.12.d Abondement du compartiment solde – CPTEABOND
Présentation de l’évènement
L’opérateur peut réaliser des abondements du compartiment solde du compte joueur liés, par exemple, à une offre commerciale ou de fidélisation. Cet abondement n’est pas systématiquement lié à un évènement de jeu.
Remarques
- Si l’abondement est à l’initiative de l’opérateur (exemple : récompense de l’activité de jeu), il est transmis immédiatement au coffre sans acquittement de la part du joueur, en incluant la balise dans
l’entête.
- Si l’abondement fait suite à une demande du joueur (exemple : échange de points de fidélité contre un abondement), il est transmis au coffre sans inclure la balise
Structure de l’enregistrement en format XML
CPTEABOND
Entité XML Min Max Type Description
Entête (cf. section II.2.1) IDRef 1 1 string-256 Identifiant de la transaction
SoldeAvant 1 1 decimal Solde du joueur avant l’abondement
MontAbond 1 1 nonNegativeDecimal Montant de l’abondement
SoldeApres 1 1 decimal Solde du joueur après l’abondement
Info 1 1 string Information sur l’abondement
TypeAbondement 1 1 string-32 Type d’abondement
Description
IDRef
Obligatoire, unique. Code technique interne permettant d’identifier la transaction sur la plate-forme de jeu.
SoldeAvant
Obligatoire, unique. Montant du compartiment solde du compte joueur avant l’abondement.
MontAbond
Obligatoire, unique. Montant de l’abondement.
SoldeApres
Obligatoire, unique. Montant du compartiment solde du compte joueur après l’abondement.
Info
Obligatoire, unique. Information de l’opérateur lié à l’abondement. Ce champ est libre, il indique les raisons de
l’abondement tel que présenté au joueur.
TypeAbondement
Obligatoire, unique. Ce champ précise le type d’abondement. Les valeurs possibles du champ sont :
« Ouverture » s’il s’agit d’un abondement lié à l’ouverture d’un compte (exemple : abondement de première inscription) ;
« RakeBack » s’il s’agit d’un abondement lié au nombre de parties ou paris engagés par le joueur ;
« HautFait » s’il s’agit d’un abondement lié à un « haut fait » d’un joueur (exemple : une quinte flush bat un carré) ;
« Code » s’il s’agit d’un abondement lié à code promotionnel (exemple : parrainage) ;
« Offre » s’il s’agit d’une offre promotionnelle ponctuelle (cas par défaut) ;
« Points » s’il s’agit de la conversion de points de fidélité ;
« Autre » dans les autres cas. La nature de l’abondement est précisée dans le champ Info
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.15).

61/202

II.4.12.f Abondement du compartiment bonus – CPTEALIMOPE
Présentation de l’évènement
L’opérateur peut réaliser des abondements du compartiment bonus du compte joueur liés, par exemple, à une offre (commerciale, fidélisation) ou un évènement de jeu. Le montant correspondant à l’abondement réalisé dans ce compartiment ne peut être retiré.
Remarques
- Si l’abondement du compartiment bonus est à l’initiative de l’opérateur (exemple : récompense de l’activité de jeu), il est transmis immédiatement au coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
- Si l’abondement du compartiment bonus fait suite à une demande du joueur (exemple : échange de points de fidélité contre un bonus), il est transmis au coffre sans inclure la balise .
Structure de l’enregistrement en format XML
CPTEALIMOPE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) IDRef 1 1 string-256 Identifiant de la transaction
BonusAvant 1 1 decimal Solde du compartiment bonus avant
l’abondement BonusMouvement 1 1 nonNegativeDecimal Montant de l’abondement
BonusApres 1 1 decimal Solde du compartiment bonus après
l’abondement BonusNom 1 1 string Information sur l’abondement
Info 0 1 string Informations complémentaires
Description
IDRef
Obligatoire, unique. Code technique interne permettant d’identifier la transaction sur la plate-forme de jeu.
BonusAvant
Obligatoire, unique. Montant du compartiment bonus du compte joueur avant l’abondement.
BonusMouvement
Obligatoire, unique. Montant de l’abondement.
BonusApres
Obligatoire, unique. Montant du compartiment bonus du compte joueur après l’abondement.
BonusNom
Obligatoire, unique. Information de l’opérateur lié à l’abondement. Ce champ est libre, il indique les raisons de
l’abondement tel que présenté au joueur.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.2.16).
62/202

II.4.13 Attribution de lots en nature – LOTNATURE
Présentation de l’évènement
L’opérateur peut attribuer des lots en nature au joueur.
Remarques
- Si le lot nature est attribué à l’initiative de l’opérateur (exemple : récompense de l’activité de jeu), il est transmis immédiatement au coffre sans acquittement de la part du joueur en incluant la balise dans l’entête.
- Si le lot nature est attribué suite à une demande du joueur (exemple : échange de points de fidélité contre un lot nature), il est transmis au coffre sans inclure la balise
Structure de l’enregistrement en format XML
LOTNATURE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) IDRef 1 1 string-256 Identifiant de la transaction
LotN 1 64 LotN Nom et valeur du lot nature
Info 0 1 string Informations complémentaires
Description
IDRef
Obligatoire, unique. Code technique interne permettant d’identifier la transaction sur la plate-forme de jeu.
LotN
Obligatoire, multiple. Chaque lot doit être décrit.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Structure de l’enregistrement en format XML
LotN
Entité XML Min Max Type Description Nom 1 1 string Description du lot
Valeur 1 1 nonNegativeDecimal Valeur du lot
Description
Nom
Obligatoire, unique. Description du lot : elle doit intégrer la référence du constructeur (si disponible).
Valeur
Obligatoire, unique. Valeur du lot.
Un exemple illustratif de l’évènement figure en annexe (partie IV.2.17).
63/202

II.4.14 Ajustement – CPTEAJUSTOPE
Présentation de l’évènement Cet évènement constate les ajustements des compartiments solde et bonus du compte joueur effectués par l’opérateur pour permettre la correction d’attributions ou d’erreurs techniques, par exemple liées à des opérations de crédit ou débit sur les compartiments solde ou bonus du compte joueur. Ces erreurs et leurs corrections doivent être transmises au coffre sans acquittement de la part du joueur.

L’évènement CPTEAJUSTOPE permet de corriger les mouvements financiers effectués par erreur. Il est donc corrélé à un autre évènement, sauf dans quelques cas exceptionnels, notamment lors du reversement des sommes dues à l’Etat en application de l’article 17 de la loi du 12 mai 2010. Le champ permet de lier l’évènement CPTEAJUSTOPE à l’évènement qu’il corrige.
Remarque Cet événement étant à l’initiative de l’opérateur, il est systématiquement transmis au coffre sans acquittement de la part du joueur en incluant la balise dans l’entête.
L’usage de cet évènement d’ajustement doit rester exceptionnel.
Structure de l’enregistrement en format XML
CPTEAJUSTOPE Entité XML Min Max Type Description Entête (cf. section II.2.1) IDRef 1 1 string-256 Identifiant de la transaction Info 1 1 string Information sur l’ajustement TypeAjust 1 1 string-32 Type d’ajustement SoldeAvant 0 1 decimal Montant du compartiment solde avant l’ajustement Ajustement 0 1 decimal Montant de l’ajustement SoldeApres 0 1 decimal Montant du compartiment solde après l’ajustement BonusAvant 0 1 decimal Montant du compartiment bonus avant l’ajustement BonusAjust 0 1 decimal Montant de l’ajustement BonusApres 0 1 decimal Montant du compartiment bonus après l’ajustement
Description IDRef Obligatoire, unique. Code technique interne permettant d’identifier la transaction sur la plate-forme de jeu. La valeur de ce champ dépend de l’évènement qu’il corrige, et, selon la nature de l’évènement qu’il corrige, il doit prendre la même valeur que le champ :
Tech> de l’évènement initial lorsque celui-ci concerne les paris sportifs, les paris hippiques ou la loterie ;
Inscription’ de l’évènement initial lorsque celui-ci est un évènement de « fantasy league » ou de poker ;
IDref> de l’évènement initial lorsque celui-ci est un évènement d’alimentation ou de retrait sur le compte joueur. Note : Si dans certains cas le champ IDRef peut en théorie désigner plusieurs évènements différents (i.e un pari sportif qui aurait le champ Tech y correspondant et une inscription de poker qui aurait le champ Inscription y correspondant), l’utilisation du champ id_joueur permettra en pratique de s’affranchir de ce problème. Il n’est donc pas nécessaire qu’il y ait unicité des valeurs entre les différents types de champs. Dans les rares cas où l’abondement ne viendrait pas corriger un évènement déjà existant (cas des frais ou du transfert des fonds à l’état), la valeur « 0 » pourra être donnée. Info
64/202

Obligatoire, Unique. Information de l’opérateur lié à l’ajustement. Ce champ est libre, il indique les raisons de
l’ajustement tel que présenté au joueur.
TypeAjust
Obligatoire, unique. Ce champ permet de préciser le compartiment sur lequel porte l’ajustement (compartiment solde ou bonus), le cas échéant, et la nature de la transaction que cet ajustement est supposé corriger (alimentation/retrait par le joueur, gain, abondement, attribution de bonus ou lot par l’opérateur) : les valeurs possibles du champ sont :
« Alimentation », dans le cas d’un ajustement du compartiment solde lié à une alimentation antérieure effectuée par le joueur ;
« Retrait », dans le cas d’un ajustement du compartiment solde lié à un retrait antérieur effectué par le joueur ;
« Gain », dans le cas d’un ajustement du compartiment solde lié à un gain (attribué par erreur, par exemple) ;
« Abondement », dans le cas d’un ajustement du compartiment solde lié à un abondement par l’opérateur ;
« Bonus », dans le cas d’un ajustement du compartiment bonus ;
« Lot », dans le cas d’une erreur d’attribution de lot en nature ;
« Frais » dans le cas d’un prélèvement de l’opérateur pour frais de gestion du compte sans préjudice de la légalité de ces frais ;
« Etat » dans le cas du transfert des fonds à l’Etat ;
« Autre » dans les autres cas. La nature de l’ajustement sera précisée dans le champ Info.
SoldeAvant
Optionnel, unique. Obligatoire lorsque l’ajustement concerne le compartiment Solde. Montant du compartiment solde du compte joueur avant l’ajustement.
Ajustement
Optionnel, unique. Obligatoire lorsque l’ajustement concerne le compartiment Solde. Montant de l’ajustement du compartiment solde du compte. Ce montant peut être négatif.
SoldeApres
Optionnel, unique. Obligatoire lorsque l’ajustement concerne le compartiment Solde. Montant du compartiment solde du compte joueur après l’ajustement. A noter qu’il peut arriver exceptionnellement qu’un ajustement conduise à un solde négatif. Pour autant, dès lors que le jeu à crédit est interdit en application de l’article 30 de la loi du 12 mai 2010, dans de tels cas il faut absolument que le joueur ait à nouveau un solde positif avant de pouvoir engager des mises.
BonusAvant
Optionnel, unique. Obligatoire lorsque l’ajustement concerne le compartiment Bonus. Montant du compartiment bonus du compte joueur avant l’ajustement.
BonusAjust
Optionnel, unique. Obligatoire lorsque l’ajustement concerne le compartiment Bonus. Montant de l’ajustement du compartiment bonus du compte. Ce montant peut être négatif.
BonusApres
Optionnel, unique. Obligatoire lorsque l’ajustement concerne le compartiment Bonus. Montant du compartiment bonus du compte joueur après l’ajustement.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.2.18).
65/202

II.5 Identification des points de vente permettant la prise de jeu sur compte
Rappel des dispositions légales et réglementaires Décret n°2010-518 Article 27
[…]Les données tracées font l’objet d’un codage spécifique correspondant aux catégories d’informations précisées dans le dossier des exigences techniques et portant notamment sur :
[…] 3° L’ « adresse IP » du joueur, c’est-à-dire l’adresse dite « Internet Protocol » du terminal depuis lequel le joueur se connecte au site de l’opérateur ou tout élément fournissant une indication relative à la localisation de la prise de jeu réalisée au moyen d’un terminal ou poste d’enregistrement mis à la disposition des joueurs dans des lieux publics ou des lieux privés ouverts au public au sens du deuxième alinéa de l’article L. 320-5 du code de la sécurité intérieure.

II.5.1 Ouverture d’un point de vente à la prise de jeu sur compte – OUVPOINTDEVENTE
Présentation de l’évènement Dans le cadre de l’activité de jeu sur compte sous droits exclusifs, les joueurs peuvent effectuer des prises de jeu depuis certains points de vente, équipés de bornes prévues à cet effet, ou dans lesquels il est possible de miser en guichet, par exemple. En l’absence d’adresse IP publique associée à ces points de vente, les opérateurs titulaires de droits exclusifs préciseront, pour chaque évènement relatif à une activité en point de vente, un identifiant de celui-ci (cf. 0). Pour permettre ensuite de localiser ces différents points de vente, les opérateurs concernés en préciseront les adresses via l’évènement OUVPOINTDEVENTE. Cet évènement sera envoyé chaque fois qu’un point de vente commencera à offrir la possibilité d’y effectuer des mises dans le cadre d’un jeu sur compte.
Structure de l’enregistrement en format XML OUVPOINTDEVENTE Entité XML Min Max Type Description Entête (cf. sectionII.2.2) IDPointDeVente 1 1 string-64 Identifiant unique du point de vente DateOuverture 0 1 date-aaaammjj Date effective de mise en service du point de vente pour le jeu sur compte, si différente de la date d’envoi présente dans l’entête Ad 1 8 string-256 Adresse postale du point de vente CP 1 1 Postal Code postal du point de vente Ville 1 1 string-64 Ville du point de vente Pays 1 1 string-64 Pays du point de vente Taille 1 1 nonNegativeDecimal Taille du point de vente (en nombre de bornes et de guichets où il est possible de miser) Test 0 1 Balise vide Indique si ce point de vente est un point de vente de test créé par l’opérateur Info 0 1 string Informations complémentaires
Description IDPointDeVente Obligatoire, unique. Identifiant unique du point de vente. DateOuverture
66/202

Optionnel, unique. Date à partir de laquelle il est effectivement possible d’effectuer des mises depuis le point de vente désigné, dans le cadre du jeu sur compte. A ne préciser si celle-ci est différente de la date d’envoi, telle que précisée dans le champ DateEvenement de l’entête.
Ad
Obligatoire, multiple. Adresse postale du point de vente. 8 lignes de 256 caractères sont disponibles.
CP
Obligatoire, unique. Code postal de ville de l’adresse postale du point de vente.
Ville
Obligatoire, unique. Ville de l’adresse postale du point de vente.
Pays
Obligatoire, unique. Pays de l’adresse postale du point de vente.
Taille
Obligatoire, Unique. Permet de décrire la taille du point de vente en quantifiant le nombre de bornes et de guichet depuis lesquels des mises pour le jeu sur compte peuvent être prises. Peut s’agir du nombre exact de bornes ou d’une fourchette.
Test
Optionnel, Unique. Permet l’identification d’un point de vente test de l’opérateur.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.3.1).
67/202

II.5.2 Modification des informations relatives à un point de vente ouvert à la prise de jeu sur compte – MODIFPOINTDEVENTE
Présentation de l’évènement
Les informations d’un point de vente peuvent-être modifiées après son ouverture au jeu sur compte, pour rectifier un élément, pour signaler un changement d’adresse (nom de la rue ou de la ville qui changerait par exemple) ou pour informer d’un changement de taille de celui-ci.
Structure de l’enregistrement en format XML
MODIFPOINTDEVENTE Entité XML Min Max Type Description
Entête (cf. section II.2.2) IDPointDeVente 1 1 string-64 Identifiant unique du point de vente
Ad 1 8 string-256 Adresse postale du point de vente
CP 1 1 Postal Code postal du point de vente
Ville 1 1 string-64 Ville du point de vente
Pays 1 1 string-64 Pays du point de vente
Taille 1 1 string-64 Taille du point de vente (en nombre de bornes et de guichets où il est possible de miser) Test 0 1 Balise vide Indique si ce point de vente est un point de vente de test créé par l’opérateur Info 0 1 string Informations complémentaires
Description
Cf. la description de OUVPOINTDEVENTE (paragraphe II.5.1)
Un exemple illustratif de l’évènement figure en annexe (partie IV.3.2).

68/202

II.5.3 Clôture d’un point de vente au jeu sur compte – CLOTUREPOINTDEVENTE

Présentation de l’évènement
Certains points de vente peuvent fermer ou ne plus permettre une activité de jeu sur compte. Cet évènement a donc vocation à préciser que ces points de vente ne sont plus actifs pour le jeu sur compte.
Remarque
A noter que si un point de vente venait à redonner la possibilité de reprendre des mises dans le cadre du jeu sur compte, après une fermeture temporaire, un nouvel évènement d’ouverture (OUVPOINTDEVENTE) devrait être envoyé pour déclarer à nouveau le point de vente.
Structure de l’enregistrement en format XML
CLOTUREPOINTDEVENTE
Entité XML Min Max Type Description
Entête (cf. section II.2.2) IDPointDeVente 1 1 string-64 Identifiant du point de vente
DateClotureEffective 0 1 date-aaaammjj Date effective de fermeture du point de vente au jeu sur compte, si différente de la date d’envoi présente dans l’entête Info 0 1 string Informations complémentaires
Description
IDPointDeVente
Obligatoire, unique. Identifiant unique du point de vente.
DateFermeture
Optionnel, unique. Date effective de fermeture du point de vente au jeu sur compte. A ne préciser si celle-ci est différente de la date d’envoi, telle que précisée dans le champ DateEvenement de l’entête.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.3.3).
69/202

II.6 Activité de jeu
II.6.1 Pari sportif
II.6.1.a Mise sur un pari – PASPMISE
Présentation de l’évènement Cet évènement constate le placement d’une mise sur un support de pari sportif autorisé par l’ANJ, en choisissant la nature (pari simple, combiné ou système) et les paramètres de l’opération.
*
* *
Définitions :
Pronostics et pronostics élémentaires :
La notion de pronostic élémentaire correspond au choix d’un joueur sur un type de résultat défini. La nomenclature utile à la codification des types de résultats autorisés et les phases de jeu sur lesquels ils portent, est publiée sur le site de l’ANJ.
Un pronostic est défini comme l’union de pronostics élémentaires. Une cote peut être associée au pronostic.
Remarque : pour un même support de pari, il convient de distinguer le pari simple, union de pronostics élémentaires formant un pronostic à une cote (le cas échéant), et le pari combiné, formé à partir d’au moins deux pronostics distincts, chacun étant associé à sa propre cote (le cas échéant). Par exemple, pour un match de football donné, il est possible de former un pari simple à partir du pronostic « 
*
* * Paris simples :
Le pari simple consiste à miser sur un pronostic portant sur une rencontre sportive ; le pari est gagnant si le pronostic correspond au résultat officiel de la rencontre sportive promulgué par les organisateurs.
En termes de formalisme, un pari simple est composé des éléments suivants :
un support de pari sportif autorisé (i.e. une compétition autorisée) ;
une rencontre sportive ;
un pronostic ;
une mise ;
une cote, le cas échéant.
En termes de combinatoire, le pari simple correspond à une unique combinaison, et donne donc lieu à un seul pari.
Un pari simple multiple correspond à N paris simples, et donc N mises.
*
* * Paris combinés :
Le pari combiné consiste à miser en un seul pari sur l’union de plusieurs paris élémentaires, chaque pari élémentaire faisant individuellement l’objet d’un pronostic. Le pari est gagnant lorsque la totalité des pronostics correspond aux résultats en fin de matchs, c’est à dire que tous les pronostics sont bons.
Un pari combiné est donc l’association des éléments suivants :
70/202

l’union de tierces constituées de :
o un support de pari sportif autorisé,
o une rencontre sportive,
o un pronostic ;
une mise ;
une cote, le cas échéant. En termes de combinatoire, le pari combiné correspond à une seule combinaison, et donne donc lieu à un seul pari. On parle alors de pari combiné simple.
Si au moins deux des pronostics ne peuvent être combinés (ex : victoire et défaite simultanées sur une même rencontre sportive), le pari devient un pari combiné multiple, et donne lieu à N combinaisons, donc N paris et autant de mises – N étant à déterminer en fonction du nombre de paris combinés que l’on peut dénombrer.
*
* * Paris système :
Le pari système est un pari multiple qui consiste à miser sur Y pronostics de résultats, avec Y ≥ 3 : on distingue alors le pari système dit « X sur Y » et le pari système dit « complexe ».
Le pari système « X sur Y », avec X < Y, est un pari multiple, gagnant lorsqu’au moins X des Y pronostics de résultats sont bons. 𝑌 En termes de combinatoire, le pari X sur Y consiste donc à effectuer (
)combinaisons. La mise totale est donc constituée 𝑋 𝑌 de (
)mises élémentaires. 𝑋
Remarque :
ce type de pari système est également appelé pari multiple simple ou accumulateur ;
si X = Y, il s’agit d’un pari combiné simple.
Le pari système complexe est la combinaison de paris simples, combinés et paris système « X sur Y ».
Les formules de pari système sont définies comme suit :
Nombre de pronostics Formule de Pari système Nombre de combinaisons Type de combinaisons 3 doubles TRIXIE 4 1 triple 3 3 simples PATENT 7 3 doubles 1 triple 6 doubles YANKEE 11 4 triples 1 quadruple 4 4 simples 6 doubles LUCKY15 15 4 triples 1 quadruple 10 doubles 10 triples CANADIAN 26 5 quadruples 1 combiné simple 5/5 5 5 simples 10 doubles LUCKY31 31 10 triples 5 quadruples 1 combiné simple 5/5
71/202

15 doubles 20 triples HEINZ 57 15 quadruples 6 systèmes 5/6 1 combiné simple 6/6 6 6 simples 15 doubles 20 triples LUCKY63 63 15 quadruples 6 systèmes 5/6 1 combiné simple 6/6 21 doubles 35 triples 35 quadruples 7 SUPERHEINZ 120 21 systèmes 5/7 7 systèmes 6/7 1 combiné simple 7/7 28 doubles 56 triples 70 quadruples 8 GOLIATH 247 56 systèmes 5/8 28 systèmes 6/8 8 systèmes 7/8 1 combiné simple 8/8 36 doubles 84 triples 126 quadruples 126 systèmes 5/9 9 SUPERGOLIATH 502 84 systèmes 6/9 36 systèmes 7/9 9 systèmes 8/9 1 combiné simple 9/9
La combinatoire de ces paris système doit être soigneusement respectée par l’opérateur dans son offre de paris sportifs.
*
* * Paris spéciaux :
Un pari spécial est un pari simple qui consiste à miser sur plusieurs pronostics dépendants mais avec une seule cote.
Un pari spécial est composé des éléments suivants :
un support de pari sportif autorisé (i.e. une compétition autorisée) ;
une rencontre sportive ;
plusieurs pronostics dépendants;
une mise ;
une cote.
En termes de combinatoire, le pari simple correspond à une seule combinaison, et donne donc lieu à un seul pari.
Remarque : Certains paris spéciaux peuvent être décrits comme des paris simples classiques (notamment lorsque la liste des pronostics est courte). Dans ces cas, il est tout à fait possible, et même encouragé, de présenter ces paris comme des paris simples. Par exemple, le pari spécial constitué des pronostics « Alice marque au moins un but » et « Bob marque au moins un but » peut s’exprimer comme un pari simple « Alice et Bob marquent au moins un but chacun ».
Lors de la prise de jeu, si une partie de la mise est dédiée à un jeu complémentaire, comme par exemple un jackpot, deux évènements PASPMISE sont envoyés au coffre. Le premier avec la mise correspondant à la prise de jeu principale et le second à celle du jeu annexe. Ces deux évènements ont des codes Tech différents mais présentent un code supplémentaire, TechJeu, permettant d’identifier de manière unique le jeu dans son ensemble.
72/202

Dans l’évènement correspondant à la prise de jeu annexe, la balise Jackpot sera présente. A noter que dans le cas où il y aurait plusieurs jeux complémentaires, autant d’évènements PASPMISE que de jeux supplémentaires devront être envoyés.
Structure de l’enregistrement en format XML PASPMISE Entité XML Min Max Type Description Entête (cf. section II.2.1) Tech 1 1 string-256 Code technique interne du coupon de pari TechJeu 0 1 string Code technique interne du jeu (permettant de relier une ou plusieurs mises complémentaires à la mise principale) Jackpot 0 1 balise vide Précise si la prise de jeu correspond à une participation à un jeu complémentaire (cagnotte, jackpot…) PaSp 1 64 PaSp Description du pari SoldeAvantMise 0 1 decimal Montant du compartiment solde avant le pari Mise 0 1 nonNegativeDecimal Montant de la mise SoldeApresMise 0 1 decimal Montant du compartiment solde après le pari MiseAbond 0 1 nonNegativeDecimal Montant de l’abondement de mise BonusAvantMise 0 1 decimal Montant du compartiment bonus avant le pari BonusMise 0 1 nonNegativeDecimal Montant de la mise BonusApresMise 0 1 decimal Montant du compartiment bonus après le pari BonusNom 0 1 string Nom du bonus Tel 0 1 Balise vide Précise si le pari a été pris par téléphone Info 0 1 string Informations complémentaires
Description Tech Obligatoire, unique. Code technique interne du coupon de pari. Ce code est utilisé par l’opérateur pour identifier le pari dans la plate-forme de jeu. TechJeu Optionnel, unique. Code technique interne du jeu. Ce code doit être renseigné lorsque dans la prise de jeu une partie de la mise est dédiée à un ou plusieurs jeux complémentaires, comme par exemple une cagnotte ou un jackpot. Ce code sera identique pour tous les évènements composant la prise de jeu du joueur. Jackpot Optionnel, unique. Précise si la mise correspond à la participation à un jeu complémentaire (comme une cagnotte ou un jackpot). PaSp Obligatoire. Description d’une combinaison de paris, unique dans le cas d’un pari simple, combiné ou système XY. Peut- être multi-valué dans le cas d’un pari système complexe, si le pari système ne correspond pas aux formules usuelles (TRIXIE, PATENT, etc.) rappelées en II.6.1.a.
Si l’opérateur souhaite introduire sa propre formule de pari système, il doit au préalable en fournir la description, notamment en termes de combinatoire, à l’ANJ.
73/202

SoldeAvantMise
Optionnel, unique. Montant du seul compartiment solde du compte joueur avant le pari. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un abondement de mise et / ou d’un bonus. Mise
Optionnel, unique. Montant de la mise effectuée depuis le seul compartiment solde du compte joueur. SoldeApresMise
Optionnel, unique. Montant du seul compartiment solde du compte joueur après le pari. Ce champ est optionnel, et serait absent dans le cas où le pari serait exclusivement réalisé à partir d’un abondement de mise et / ou d’un bonus. MiseAbond
Optionnel, unique. Montant de l’abondement de l’opérateur. BonusAvantMise
Optionnel, unique. Montant du seul compartiment bonus du compte joueur avant le pari. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un abondement de mise et / ou à partir du compartiment solde du compte joueur. BonusMise
Optionnel, unique. Montant du bonus. BonusApresMise
Optionnel, unique. Montant du seul compartiment bonus du compte joueur après le pari. BonusNom
Optionnel, unique. Nom du bonus tel qu’affiché au joueur. Tel
Optionnel, unique. Précise si le pari a été pris par appel téléphonique ou par SMS (jeu sur compte sous droits exclusifs uniquement). Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
PaSp Entité XML Min Max Type Description Combi 1 1 Combinatoire Type de combinatoire Mutuel 0 1 Balise vide Pari mutuel X 0 1 Xxy Paramètre du pari XY LigSp 1 64 LigSp LigSp de bulletin MiseBase 0 1 nonNegativeDecimal Mise de base, ou mise élémentaire
Description Combi Obligatoire, unique. Type de combinatoire du pari.
L’entité Combi est de type Combinatoire :
Combinatoire Sous-type Contraintes string La chaîne de caractères doit être égale à l’une des énumérations suivantes :
« S » pour un pari simple (y compris pari spécial) ;
« C » pour un pari combiné ;
« XY » pour un pari X/Y, ou accumulateur, ou pari multiple simple. Le paramètre X est déduit de l’entité XML X de l’entité PaSp. Le paramètre Y est déduit du nombre d’occurrences de l’entité XML LigSp de l’entité PaSp ;
« TRIXIE », « PATENT », « YANKEE », « LUCKY15 », « CANADIAN », « LUCKY31 », « HEINZ », « LUCKY63 », « SUPERHEINZ » « GOLIATH », et « SUPER GOLIATH » pour les paris système complexes prédéfinis ;
74/202

Mutuel Optionnel, unique. Précise qu’il s’agit d’un pari mutuel (enjeux mutualisés) X Optionnel, unique. Paramètre X du pari dans le cadre d’un pari X/Y. L’entité X est du type Xxy.
Xxy Sous-type Contraintes integer Entier compris entre 1 et 64 LigSp Obligatoire, unique dans le cas d’un pari simple, multiple dans le cas d’un pari combiné (simple ou multiple) et d’un pari système (simple ou complexe). Ligne du bulletin correspondant au pari. MiseBase Optionnel, unique. Mise élémentaire. La mise totale associée à la prise de jeu est le produit de la mise élémentaire par le nombre de combinaisons du pari.
Par exemple :
pour un pari simple ou un pari combiné (simple), la mise totale vaut la mise de base ;
pour un pari X/Y, la mise totale vaut (^𝑌
) fois la mise de base. Pour un 2/3, la mise totale vaut 3 fois la mise de 𝑋 base ;
pour un pari TRIXIE, la mise totale vaut 4 fois la mise de base ; pour un pari PATENT, 7 fois la mise élémentaire, etc.
LigSp Entité XML Min Max Type Description Renc 1 1 string Nom de la rencontre et de la compétition Tech 1 1 string-256 Code technique de la rencontre Sport 1 1 codeSport Sport Cat 0 1 codeCategorie Catégorie Evnt 1 1 codeEvenement Nom de l’évènement Disc 0 1 codeDiscipline Discipline Genr 1 1 Genre Genre Date 1 1 date-aammjjhhmmss Date de la rencontre Part 0 2 codeParticipant Participant(s) PronoSp 1 64 PronoSp Pronostics indépendants Cote 0 64 nonNegativeDecimal Cote du pari Live 0 1 Balise vide Pari effectué sur la rencontre en direct (live betting) Banque 0 1 Balise vide Pari « banque »
Remarque : les types préfixés par la chaîne code font l’objet d’une normalisation, totale ou partielle, par l’ANJ. Ces codes sont précisés dans la nomenclature ANJ.
Toute demande d’ajout d’un code doit parvenir à l’adresse nomenclature@anj.fr.
Cette démarche doit être distinguée de la demande d’inscription d’une compétition ou d’un type de résultats sur la liste prévue par le décret n° 2010-483 du 12 mai 2010 relatif aux compétitions sportives et aux types de résultats sportifs définis par l’Autorité de régulation des jeux en ligne
Description Renc Obligatoire, unique. Nom de la compétition et de la rencontre. Ce champ ne fait pas l’objet d’une codification : il s’agit de l’intitulé la compétition et de la rencontre tels qu’ils sont affichés au joueur. Il doit, en revanche, être mis sous forme canonique :
la suppression des diacritiques indépendamment de la casse (accents aigus, graves et circonflexes, trémas et cédilles),
75/202

le passage à la casse supérieure,
la suppression des caractères hors de la classe de caractères [0-9A-Zˈ -]. Tech Obligatoire, unique. Code technique de la rencontre. Utilisé par l’opérateur pour identifier la rencontre dans la plate- forme de jeu. Cet identifiant est commun à l’ensemble des joueurs. Sport Obligatoire, unique. Sport auquel est rattachée la rencontre sportive. Ce champ est normalisé et fait l’objet d’une codification. Ce code est précisé dans la nomenclature ANJ. Cat Optionnel, unique. Catégorie du sport pratiqué. Ce champ est normalisé et fait l’objet d’une codification. Cette entité est optionnelle au sens du XSD : si la nomenclature référence des catégories pour un sport, cette entité devient obligatoire pour les évènements XML relatifs à ce sport. Evnt Obligatoire, unique. Evènement auquel est rattachée la rencontre sportive. Ce champ est normalisé et fait l’objet d’une codification. Ce code est précisé dans la nomenclature ANJ. Disc Optionnel, unique. Discipline du sport pratiqué. Ce champ est normalisé et fait l’objet d’une codification. Cette entité est optionnelle au sens du XSD : si la nomenclature référence des disciplines pour un sport, cette entité devient obligatoire pour les évènements XML relatifs à ce sport. Genr Obligatoire, unique. Genre associé à la rencontre.
Genre Sous-type Contraintes String La chaîne de caractères doit être égale l’une des énumérations suivantes : « H », « F » ou « M » désignant respectivement « Homme », « Femme » ou « Mixte »
Date Obligatoire, unique. Date de la rencontre, au format UTC. Part Obligatoire. Multi-valué (x2). Participant à la rencontre. Présent lorsque la rencontre oppose deux participants (deux équipes, deux joueurs) uniquement : il n’est en particulier pas question de lister l’ensemble des participants à une course, ou l’ensemble des membres d’une équipe, ni d’inclure plusieurs équipes dans une seule valeur. Ce champ peut faire l’objet d’une énumération partielle disponible sur le site de l’ANJ. Si la valeur correspondante est présente dans le dictionnaire, elle doit être utilisée. Dans le cas contraire, la valeur reprend le nom du participant tel qu’il est affiché au joueur. Il doit, en revanche, être mis sous forme canonique, tout comme l’entité Renc. :
- suppression des diacritiques indépendamment de la casse (accents aigus, graves et circonflexes, trémas et cédilles),
- passage à la casse supérieure,
- suppression des caractères hors de la classe de caractères [0-9A-Zˈ -].
Enfin, les deux participants à la rencontre doivent être renseignés dans le même ordre que présenté dans le champ Renc, qui doit lui-même être conforme à l’ordre donné par l’organisateur de la compétition. PronoSp Obligatoire. Pronostic du pari. A noter que cette valeur peut être multi-variée lorsque le joueur a pris plusieurs paris différents sur une même issue (exemple : grille de paris où un joueur aurait « coché » plusieurs résultats possibles). Cote Optionnel. Cote européenne (format décimal) affichée au joueur lors de la prise de pari. Il s’agit de la cote présentée au joueur. La cote est associée à un pronostic PronoSp et peut être multi-variée si PronoSp l’est. A noter que dans ce cas les entités PronoSp et Cote constituent une séquence.
La cote peut ne pas apparaître dans le cas d’un pari combiné présenté sous forme de grille. Live Optionnel. Nul si présent. Présent lorsque le pari est effectué, en temps réel, sur la rencontre en direct.
76/202

Banque Optionnel. Nul si présent. Présent lorsque le pari est un pari « banque ».
PronoSp Entité XML Min Max Type Description TypeRes 1 64 codeTypeResultat Type de résultat Choix 1 64 string Choix de résultat
TypeRes Obligatoire. Type de résultat associé au pronostic. Ce champ est normalisé et fait l’objet d’une codification par sport. Ce code est précisé dans la nomenclature ANJ. Dans le cas de paris spéciaux il peut y avoir plusieurs valeurs (une pour chaque choix, en précédant à chaque fois le choix correspondant). Choix Obligatoire. Choix associé au type de résultat, comprenant également l’intitulé du pari affiché au joueur, de telle manière à ce que ce champ suffise à décrire le support du pari. Dans le cas de paris spéciaux ce champ peut apparaître plusieurs fois.
Remarque 1 Les champs [SoldeAvantMise, Mise, SoldeApresMise] [BonusAvantMise, BonusMise, BonusApresMise] doivent être présents ou absents simultanément.
Remarque 2 L’opérateur peut proposer des paris « gratuits ». Dans ce cas, le bonus doit être attribué au joueur à partir d’un évènement CPTEALIMOPE. Lors de la prise de pari, le montant du pari « gratuit » sera déduit du compartiment bonus et la mention pari « gratuit » sera précisée dans le champ BonusNom>. Si le pari est gagnant il est toléré que la mise soit déduite du gain payé au joueur, soit un gain correspondant à la mise*(cote-1).
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.1).
77/202

II.6.1.b Gain sur un pari – PASPGAIN
Présentation de l’évènement
Au moment du débouclage des paris, un évènement de gain PASPGAIN est généré pour chaque pari gagnant.
A l’issue du résultat d’une compétition sportive ayant fait l’objet de paris mutuels, l’opérateur calcule le rapport des paris, identifie les gagnants et génère le gain correspondant pour chacun d’entre eux ;
Pour les paris à cote, l’opérateur identifie les gagnants et génère un gain correspondant à la cote annoncée lors du pari (ou lors du cashout le cas échéant) à l’issue d’une compétition.
Remarques
- Si l’événement de gain fait suite à la promulgation d’un résultat ou à une action de l’opérateur, il est poussé immédiatement dans le coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
- Si l’événement de gain fait suite à une action du joueur (exemple : cashout manuel), l’action du joueur fait office d’acquittement et la balise n’est pas utilisée.
Structure de l’enregistrement en format XML PASPGAIN Entité XML Min Max Type Description Entête (cf. section II.2.1) Tech 1 1 string-256 Code technique interne du coupon pari DateMise 1 1 date-aammjjhhmmss Date et heure de la mise DateHeure 1 1 date-aammjjhhmmss Date et heure du résultat du pari Cashout 0 1 Cashout Cashout du joueur SoldeAvantGain 0 1 Decimal Montant du compartiment solde avant le gain Gain 0 1 nonNegativeDecimal Montant du gain SoldeApresGain 0 1 Decimal Montant du compartiment solde après le gain GainAbond 0 1 nonNegativeDecimal Montant de l’abondement de gain BonusAvantGain 0 1 Decimal Montant du compartiment bonus avant le gain BonusMouvement 0 1 nonNegativeDecimal Montant du gain BonusApresGain 0 1 Decimal Montant du compartiment bonus après le gain Info 0 1 string Complément d’information
Description Tech Obligatoire, unique. Code technique du pari gagné identique à celui utilisé lors de la mise sur le pari. DateMise Obligatoire, unique. Date et heure au format UTC de la mise associée au gain. DateHeure Obligatoire, unique. Date et heure au format UTC du résultat sur lequel portait la mise associée au gain. (Dans le cas d’un pari combiné ou système, c’est la date et l’heure du résultat de la patte entraînant le gain, et dans le cas d’un cashout, c’est l’heure de la demande par le joueur qui est attendue). Cashout Optionnel, unique. Ce champ permet de d’indiquer, dans le cas du rachat partiel ou total du pari par l’opérateur à une cote différente, les conditions de l’opération. Ce champ est obligatoire lorsque le joueur effectue un cashout de sa mise. SoldeAvantGain
78/202

Optionnel, Unique. Montant du compartiment solde du compte joueur avant le gain. Gain
Optionnel, Unique. Montant du gain : hors abondement. SoldeApresGain
Optionnel, Unique. Montant du compartiment solde du compte joueur après le gain. GainAbond
Optionnel, Unique. Montant de l’abondement de gain. BonusAvantGain
Optionnel, unique. Montant du compartiment bonus du compte joueur avant le gain. BonusMouvement
Optionnel, unique. Montant du bonus. BonusApresGain
Optionnel, unique. Montant du compartiment bonus du compte joueur après le gain. Info
Optionnel, Unique. Information complémentaire fournie au joueur, résultat gagnant et dans le cas des paris mutuels, montant de la masse des paris.
Structure de l’enregistrement en format XML Cashout Entité XML Min Max Type Description Rachat 0 1 nonNegativeDecimal Montant du pari racheté Cote 0 1 nonNegativeDecimal Cote du rachat
Description Rachat Optionnel, unique. Montant de la mise racheté par l’opérateur. Ce montant peut être inférieur ou égal à la mise. Cote Optionnel, unique. Cote à laquelle a été racheté le pari par l’opérateur.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.2).
II.6.1.c Annulation d’un pari – PASPANNUL
Présentation de l’évènement Le pari est annulé par le joueur ou bien par l’opérateur, par exemple, si la ou une des compétitions sur laquelle le pari porte est annulée.
Remarque 1 :
- Si l’annulation est à l’initiative de l’opérateur (exemple : abandon lors d’un match de tennis) elle est alors transmise immédiatement au coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
- Si l’annulation est demandée par le joueur, la demande faisant office d’acquittement, l’événement est alors transmis au coffre sans inclure la balise .
Remarque 2 :
Certaines options permettent aux joueurs de modifier leurs paris avant le début de la rencontre. Dans ce cas, le pari initial est annulé avec un évènement PASPANNUL, en précisant dans le champ le code Tech correspondant au nouveau pari. Un nouvel évènement PASPMISE est transmis au coffre avec un code Tech différent de celui du pari initial. Dans le champ associé à la nouvelle mise, le code Tech du pari initial sera précisé.
Structure de l’enregistrement en format XML
79/202

PASPANNUL
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string-256 Code technique interne du pari annulé
DateMise 1 1 date-aammjjhhmmss Date et heure de la mise
Motif 1 1 string-32 Motif de l’annulation
SoldeAvantRembours 0 1 decimal Montant du solde avant l’annulation
MontantRembours 0 1 nonNegativeDecimal Montant du remboursement
SoldeApresRembours 0 1 decimal Montant du solde après l’annulation
BonusAvant 0 1 decimal Montant du compartiment bonus avant
l’annulation BonusMouvement 0 1 nonNegativeDecimal Montant de l’annulation
BonusApres 0 1 decimal Montant du compartiment bonus après
l’annulation Tel 0 1 Balise vide Précise si l’annulation a été effectuée via téléphone Info 0 1 string Complément d’information
Description
Tech
Obligatoire, unique. Code technique du pari annulé identique à celui utilisé lors de la mise sur le pari.
DateMise
Obligatoire, unique. Date et heure au format UTC de la mise associée à l’annulation.
Motif
Obligatoire, unique. Ce champ permettra de préciser le motif de l’annulation, les valeurs possibles sont :
« NonConforme » lorsque le pari porte sur une rencontre, ou sur type d’évènement, non autorisé par l’ANJ ;
« MSE » lorsque que le match est sans enjeu ;
« RencontreAnnulee » lorsque que la rencontre est annulée ;
« Resultat » lorsque que le pari est annulé du fait du résultat (par exemple suite à un abandon au tennis) ;
« Joueur » lorsque le pari est annulé à l’initiative du joueur ;
« PariModifie » lorsque le joueur modifie sa prise de pari. La mise initiale est annulée et une nouvelle mise est transmise au coffre. Les champs de ces évènements permettront de relier les évènements entre eux ;
« Autre ». Dans ce cas, le champ Info servira à préciser la nature exacte de l’annulation.
SoldeAvantRembours
Optionnel, unique. Montant du compartiment solde du compte joueur avant l’annulation du pari.
MontantRembours
Optionnel, unique. Montant du remboursement.
SoldeApresRembours
Optionnel, unique. Montant du compartiment solde du compte joueur après l’annulation du pari.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant l’annulation.
BonusMouvement
Optionnel, unique. Montant de l’annulation.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après l’annulation.
Tel
Optionnel, unique. Précise si l’annulation a été effectuée via un appel téléphonique ou un SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Information complémentaire fournie au joueur, cause et conditions de l’annulation.
80/202

Des exemples illustratifs de l’évènement peuvent être trouvés en annexe (partie IV.4.3).
81/202

II.6.1.d Cas particulier de la « Fantasy League »
Pour participer à une « Fantasy League », chaque joueur choisit un nombre déterminé d’acteurs de la compétition ou manifestation sportive considérée (composition). Lors de son inscription à la « Fantasy League », le joueur acquitte une mise qui vient alimenter la masse commune attachée à la « Fantasy League ». Il formule ensuite une liste de paris sportifs portant sur la réalisation de faits de jeu par ces acteurs. L’exactitude des pronostics sportifs permet au joueur d’acquérir un nombre de points fixé selon le règlement du jeu. Les joueurs de chaque « Fantasy League » sont enfin classés selon le nombre de points obtenus à l’issue de la compétition ou manifestation sportive, leur rang au classement détermine le montant de leur gain, les rangs gagnants se partageant la masse après déduction des prélèvements et commissions par l’opérateur.
Les paris sportifs sous la forme mutuelle répondant au fonctionnement décrit des « Fantasy League » suivent une cinématique composée, a minima, de 3 étapes :
Inscription et mise pour participer à une « Fantasy League » (FAINSCRIT) ;
Composition d’une ou plusieurs sélections (FAJEU) ;
Bilan financier suite à l’exécution du ou des paris (FABILAN).
D’autres évènements peuvent survenir au cours d’une « Fantasy League » :
Si le joueur réalise, au cours d’une « Fantasy League », un objectif optionnel et préalablement fixé par l’opérateur, il peut immédiatement obtenir un gain intermédiaire (FAGAIN) ;
Si l’opérateur le propose, le joueur peut acheter un « avantage » de jeu au cours d’une « Fantasy League » (FAACHAT) ;
L’opérateur ou le joueur peuvent annuler une « Fantasy League » en cours pour diverses raisons (FAANNUL), dans ce cas les gains et dépenses peuvent nécessiter d’être remboursés (CPTEAJUSTOPE).
Les opérateurs intègrent les six événements présentés ci-dessus pour les jeux répondant au fonctionnement de la « Fantasy League » par dérogation aux événements spécifiques aux paris sportifs (PASPMISE, PASPGAIN et PASPANNUL).
Le schéma ci-dessous présente sous forme d’automate le principe de fonctionnement :
82/202

Afin d’assurer la traçabilité des opérations de jeu, quatre codes techniques sont utilisés dans les évènements de jeu, les trois derniers étant spécifiques à l’offre de paris sportifs sous la forme mutuelle répondant au fonctionnement de la « Fantasy League ».
Le code Tech est l’identifiant unique d’une « Fantasy League », tous les évènements d’une même « Fantasy League » partagent ce code.
Le code Inscription est un code associé à l’inscription d’un joueur et l’acquittement de sa mise. Tous les évènements rattachés à cette inscription partagent ce code. Si un joueur s’inscrit plusieurs fois à la même « Fantasy League » (cas du multi-entrée), chacune de ces inscriptions dispose de son propre code Inscription.
Au cours d’une « Fantasy League », les règles peuvent impliquer que la sélection d’un joueur « n’affronte » qu’une partie des autres sélections. Elles sont dans ce cas regroupées à l’aide du code Pool. Ce code est à usage unique et ne doit pas être réutilisé au cours d’une même « Fantasy League ».
Enfin, jusqu’à une date fixée par l’opérateur, un joueur peut modifier la composition de sa sélection. Dans ce cas, un nouvel évènement FAJEU remplace le précédent. Le code IDCompo permet d’associer ces différents FAJEU entre eux, ainsi couplés à la date de l’évènement, il est possible de suivre l’évolution de la sélection d’un joueur sous la forme d’un historique.
83/202

II.6.1.d.1 Inscription d’un joueur : FAINSCRIT
Présentation de l’évènement Le joueur peut s’inscrire pour une ou plusieurs « Fantasy League » ; l’évènement FAINSCRIT enregistre toutes les informations relatives à cette inscription. Il spécifie en particulier le code Tech et le code Inscription qui permet la traçabilité des évènements.
L’évènement dispose de tous les champs nécessaires pour décrire un mouvement financier.
Structure de l’enregistrement en format XML
FAINSCRIT Entité XML Min Max Type Description Entête (cf. section II.2.1) Inscription 1 1 string Identifiant de l’inscription Tech 1 1 string Identifiant de la « Fantasy League » Description 1 1 string Description de la « Fantasy League » Sport 1 1 codeSport Sport Cat 0 1 codeCategorie Catégorie Evnt 1 1 codeEvenement Nom de l’évènement Disc 0 1 codeDiscipline Discipline Format 1 1 format Format de la « Fantasy League » SoldeAvant 0 1 decimal Solde du joueur avant évènement SoldeMouvement 0 1 nonNegativeDecimal Montant du mouvement SoldeApres 0 1 decimal Solde du joueur après évènement BonusAvant 0 1 decimal Bonus du joueur avant évènement BonusMouvement 0 1 nonNegativeDecimal Montant du mouvement BonusApres 0 1 decimal Bonus du joueur après évènement Tel 0 1 Balise vide Précise si l’inscription a été prise par téléphone Info 0 1 string Informations complémentaires
Description Inscription
Obligatoire, unique. Identifiant unique d’inscription. Un joueur s’inscrivant plusieurs fois à une même « Fantasy League » (i.e. multi-entrée), dispose d’un code Inscription différent pour chaque inscription. Tech
Obligatoire, unique. Identifiant unique de la « Fantasy League ». Tous les joueurs inscrits à une même « Fantasy League » disposent du même identifiant. Description
Obligatoire, unique. Description de la « Fantasy League ». Sport
Obligatoire, unique. Sport auquel est rattachée la rencontre sportive. Ce champ est normalisé et fait l’objet d’une codification. Ce code est précisé dans la nomenclature ANJ. Cat Optionnel, unique. Catégorie du sport pratiqué. Ce champ est normalisé et fait l’objet d’une codification. Ce code est précisé dans la nomenclature ANJ Evnt
Obligatoire, unique. Evènement auquel est rattachée la rencontre sportive. Ce champ est normalisé et fait l’objet d’une codification. Ce code est précisé dans la nomenclature ANJ. Disc
84/202

Optionnel, unique. Discipline du sport pratiqué. Ce champ est normalisé et fait l’objet d’une codification. Ce code est cfprécisé dans la nomenclature ANJ. Cette entité est optionnelle au sens du XSD : si la nomenclature référence à plusieurs disciplines pour un sport, cette entité devient obligatoire pour les évènements XML relatifs à chacune d’elle.
Format
Obligatoire, unique. Format de la « Fantasy League ». Celui-ci est présenté sous la forme d’un quadruplet de la valeur
A/B/C[/D] où A représente le nombre de joueurs minimum accepté, B représente le nombre de joueurs maximum accepté (ou 0 s’il n’y a pas de maximum), C le nombre de gagnants à l’issue de la « Fantasy League » (ou 0 s’il n’est pas déterminé au moment de l’inscription) et D les options de cette dernière. Les options (cumulables) sont S s’il s’agit d’un satellite, A si les achats intermédiaires sont autorisés et G si les gains intermédiaires sont autorisés. Par exemple : 2/0/0 ou 10/0/5/AG.
SoldeAvant
Optionnel, unique. Montant du seul compartiment solde du compte joueur avant la prise de jeu. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un abondement de mise et / ou d’un bonus.
SoldeMouvement
Optionnel, unique. Montant de la mise effectuée depuis le seul compartiment solde du compte joueur.
SoldeApres
Optionnel, unique. Montant du seul compartiment solde du compte joueur après la prise de jeu. Ce champ est optionnel, et serait absent dans le cas où le pari serait exclusivement réalisé à partir d’un abondement de mise et / ou d’un bonus.
BonusAvant
Optionnel, unique. Montant du seul compartiment bonus du compte joueur avant la prise de jeu. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un abondement de mise et / ou à partir du compartiment solde du compte joueur.
BonusMouvement
Optionnel, unique. Montant du bonus.
BonusApres
Optionnel, unique. Montant du seul compartiment bonus du compte joueur après le pari.
Tel
Optionnel, unique. Précise si le pari a été pris par appel téléphonique ou par SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.4).
85/202

II.6.1.d.2 Choix d’une sélection : FAJEU
Présentation de l’évènement
La composition du joueur est tracée à l’aide d’un évènement FAJEU qui précise la sélection retenue et ajoute les informations complémentaires de traçabilité. Cet évènement est à utiliser aussi bien pour les nouvelles sélections que pour le remplacement d’une sélection existante.
Structure de l’enregistrement en format XML
FAJEU
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Inscription 1 1 string Identifiant de l’inscription
Tech 1 1 string Identifiant de la « Fantasy League »
Pool 1 1 string Identifiant de masse
Description 1 1 string Description du support de jeu
Info 0 1 string Informations complémentaires
IDCompo 1 1 string Identifiant de la composition
DateCompo 1 1 date-aammjjhhmmss Date de prise en compte
Composition 1 64 Choix Composition
Description
Inscription
Obligatoire, unique. Identifiant unique d’inscription. Un joueur s’inscrivant plusieurs fois à une même « Fantasy League » (i.e. multi-entrée), dispose d’un code Inscription différent pour chaque inscription.
Tech
Obligatoire, unique. Identifiant unique de la « Fantasy League ». Tous les évènements relatifs à une même « Fantasy League » disposent du même identifiant Tech.
Pool
Les joueurs d’une même « Fantasy League » peuvent être amenés à se rencontrer par sous-groupes. Chaque sous-groupe dispose d’un identifiant unique et non réutilisable dans une « Fantasy League ».
Description
Obligatoire, unique. Description du support de jeu (règles, etc.).
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
IDCompo
Obligatoire, unique. Identifiant de la composition permettant sa traçabilité.
DateCompo
Obligatoire, unique. Date de prise en compte de la composition du joueur.
Composition
Obligatoire, multiple. Ensemble de choix détaillant la composition sélectionnée par le joueur.
Structure de l’enregistrement en format XML
CHOIX
Entité XML Min Max Type Description
Nom 1 1 string Nom du sportif sélectionné
Info 1 1 string Informations complémentaires
Description
Nom
Obligatoire, unique. Nom du participant entrant dans la composition du joueur.
86/202

Info
Obligatoire, unique. Ce champ permet d’ajouter des précisions à la sélection du joueur tel que le poste du participant occupé dans la sélection du joueur.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.4).
87/202

II.6.1.d.3 Clôture et bilan financier d’une « Fantasy League » – FABILAN
Présentation de l’évènement
A la fin d’une « Fantasy League », un évènement de clôture FABILAN est généré pour chaque joueur afin d’établir un bilan financier et cela, même si un joueur ne remporte aucun gain. Les éventuels gains et achats intermédiaires ne doivent pas être pris en compte pour établir ce bilan financier.
Remarque : Cet événement est transmis au coffre au moment de la promulgation du résultat de la Fantasy League sans acquittement de la part du joueur, en incluant la balise dans l’entête.
Structure de l’enregistrement en format XML
FABILAN Entité XML Min Max Type Description Entête (cf. section II.2.1) Inscription 1 1 string Identifiant de l’inscription Tech 1 1 string Identifiant de la « Fantasy League » Classement 0 1 integer Classement du joueur Points 1 1 nonNegativeDecimal Nombre de points du joueur SoldeAvant 0 1 decimal Solde du joueur avant évènement SoldeMouvement 0 1 nonNegativeDecimal Montant du mouvement SoldeApres 0 1 decimal Solde du joueur après évènement BonusAvant 0 1 decimal Bonus du joueur avant évènement BonusMouvement 0 1 nonNegativeDecimal Montant du mouvement BonusApres 0 1 decimal Bonus du joueur après évènement Info 0 1 string Informations complémentaires
Description Inscription Obligatoire, unique. Identifiant unique d’inscription. Un joueur s’inscrivant plusieurs fois à une même « Fantasy League » (i.e. multi-entrée), dispose d’un code Inscription différent pour chaque inscription. Tech Obligatoire, unique. Identifiant unique de la « Fantasy League ». Tous les évènements relatifs à une même « Fantasy League » disposent du même identifiant Tech. Classement Facultatif, unique. Classement final du joueur à la fin de la « fantasy league ». Ce champ doit être obligatoirement renseigné pour les joueurs classés. En particulier, il doit impérativement être précisé lorsque le joueur finit à une place lui octroyant un gain. Points Obligatoire, unique. Nombre de points obtenu par le joueur à la fin de la « fantasy league ». SoldeAvant Optionnel, unique. Montant du seul compartiment solde du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus. SoldeMouvement Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment solde du compte joueur.
88/202

SoldeApres
Optionnel, unique. Montant du seul compartiment solde du compte joueur après le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus.
BonusAvant
Optionnel, unique. Montant du seul compartiment bonus du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir du solde. BonusMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment bonus du compte joueur.
BonusApres
Optionnel, unique. Montant du seul compartiment bonus du compte joueur après le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir du solde.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.4).
89/202

II.6.1.d.4 Gain intermédiaire – FAGAIN
Présentation de l’évènement Si l’opérateur souhaite offrir des gains intermédiaires suite à des résultats particuliers, ceux-ci seront reversés au joueur au cours d’une « Fantasy League » à l’aide de l’évènement FAGAIN.
Le motif d’un tel gain doit être précisé dans le champ dédié.
Remarque Cet événement est transmis au coffre au moment de la promulgation du résultat intermédiaire de la Fantasy League sans acquittement de la part du joueur, en incluant la balise dans l’entête.
Structure de l’enregistrement en format XML
FAGAIN Entité XML Min Max Type Description Entête (cf. section II.2.1) Inscription 1 1 string Identifiant de l’inscription Tech 1 1 string Identifiant de la « Fantasy League » Motif 1 1 string Motif de l’évènement SoldeAvant 0 1 decimal Solde du joueur avant évènement SoldeMouvement 0 1 nonNegativeDecimal Montant du mouvement SoldeApres 0 1 decimal Solde du joueur après évènement BonusAvant 0 1 decimal Bonus du joueur avant évènement BonusMouvement 0 1 nonNegativeDecimal Montant du mouvement BonusApres 0 1 decimal Bonus du joueur après évènement Info 0 1 string Informations complémentaires
Description Inscription Obligatoire, unique. Identifiant unique d’inscription. Un joueur s’inscrivant plusieurs fois à une même « Fantasy League » (i.e. multi-entrée), dispose d’un code Inscription différent pour chaque inscription. Tech Obligatoire, unique. Identifiant unique de la « Fantasy League ». Tous les évènements relatifs à une même « Fantasy League » disposent du même identifiant Tech Motif Obligatoire, unique. Chaque FAGAIN doit être motivé. Il s’agit d’un champ libre qui permet à l’opérateur d’expliquer le motif du gain intermédiaire. SoldeAvant
Optionnel, unique. Montant du seul compartiment solde du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus. SoldeMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment solde du compte joueur. SoldeApres
Optionnel, unique. Montant du seul compartiment solde du compte joueur après le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus. BonusAvant
Optionnel, unique. Montant du seul compartiment bonus du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir du solde. BonusMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment bonus du compte joueur. BonusApres
90/202

Optionnel, unique. Montant du seul compartiment bonus du compte joueur après le mouvement financier. Ce champ
n’est pas précisé dans le cas où le pari est réalisé à partir du solde.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.4).
91/202

II.6.1.d.5 Achat intermédiaire – FAACHAT
Présentation de l’évènement
L’opérateur peut proposer des options d’achats (bonus ou options) au cours d’une « Fantasy League » à l’aide d’un évènement FAACHAT. Le motif d’un achat est obligatoirement précisé dans le champ dédié.
Structure de l’enregistrement en format XML
FAACHAT
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Inscription 1 1 string Identifiant de l’inscription
Tech 1 1 string Identifiant de la « Fantasy League »
Motif 1 1 string Motif de l’évènement
SoldeAvant 0 1 decimal Solde du joueur avant évènement
SoldeMouvement 0 1 nonNegativeDecimal Montant du mouvement
SoldeApres 0 1 decimal Solde du joueur après évènement
BonusAvant 0 1 decimal Bonus du joueur avant évènement
BonusMouvement 0 1 nonNegativeDecimal Montant du mouvement
BonusApres 0 1 decimal Bonus du joueur après évènement
Info 0 1 string Informations complémentaires
Description
Inscription
Obligatoire, unique. Identifiant unique d’inscription. Un joueur s’inscrivant plusieurs fois à une même « Fantasy League » (i.e. multi-entrée), dispose d’un code Inscription différent pour chaque inscription.
Tech
Obligatoire, unique. Identifiant unique de la « Fantasy League ». Tous les évènements relatifs à une même « Fantasy
League » disposent du même identifiant Tech
Motif
Obligatoire, unique. Chaque FAACHAT doit être motivé. Il s’agit d’un champ libre qui permet à l’opérateur d’expliquer le motif de l’achat.
SoldeAvant
Optionnel, unique. Montant du seul compartiment solde du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus.
SoldeMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment solde du compte joueur.
SoldeApres
Optionnel, unique. Montant du seul compartiment solde du compte joueur après le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus.
BonusAvant
Optionnel, unique. Montant du seul compartiment bonus du compte joueur avant le mouvement financier. Ce champ
n’est pas précisé dans le cas où le pari est réalisé à partir du solde. BonusMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment bonus du compte joueur.
BonusApres
Optionnel, unique. Montant du seul compartiment bonus du compte joueur après le mouvement financier. Ce champ
n’est pas précisé dans le cas où le pari est réalisé à partir du solde.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.4).
92/202

II.6.1.d.6 Annulation d’une « Fantasy League » – FAANNUL
Présentation de l’évènement Cet évènement est enregistré à l’initiative du joueur ou de l’opérateur pour annuler une inscription à une « Fantasy League » ou de la « Fantasy League » elle-même et de tous les évènements qui lui sont liés. Il reflète le remboursement de l’inscription et des éventuelles options.
Si d’autres évènements financiers sont liés à cette inscription et doivent faire l’objet d’un ajustement, ceux-ci doivent être effectués à l’aide d’un évènement CPTEAJUSTOPE.
Remarques :
- Si l’annulation est à l’initiative de l’opérateur ou à la demande de l’ANJ, le FAANNUL est alors transmis immédiatement au coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
- Si l’annulation est demandée par le joueur la demande faisant office d’acquittement, le FAANNUL est transmis au coffre sans inclure la balise
Structure de l’enregistrement en format XML
FAANNUL Entité XML Min Max Type Description Entête (cf. section IV.4.4) Inscription 1 1 string Identifiant de l’inscription Tech 1 1 string Identifiant de la « Fantasy League » Motif 1 1 string Motif de l’évènement SoldeAvant 0 1 decimal Solde du joueur avant évènement SoldeMouvement 0 1 nonNegativeDecimal Montant du mouvement SoldeApres 0 1 decimal Solde du joueur après évènement BonusAvant 0 1 decimal Bonus du joueur avant évènement BonusMouvement 0 1 nonNegativeDecimal Montant du mouvement BonusApres 0 1 decimal Bonus du joueur après évènement Tel 0 1 Balise vide Précise si l’annulation a été effectuée par téléphone Info 0 1 string Informations complémentaires
Description Inscription Obligatoire, unique. Identifiant unique d’inscription. Un joueur s’inscrivant plusieurs fois à une même « Fantasy League » (i.e. multi-entrée), dispose d’un code Inscription différent pour chaque inscription. Tech Obligatoire, unique. Identifiant unique de la « Fantasy League ». Tous les évènements relatifs à une même « Fantasy League » disposent du même identifiant Tech Motif Obligatoire, unique. Chaque FAANNUL doit être motivé. Obligatoire, Unique. Ce champ permettra de préciser le motif de l’annulation, les valeurs possibles sont :
« NonConforme » lorsque la rencontre est non conforme à la liste sport ;
« MSE » lorsque que le match est sans enjeu ;
« RencontreAnnulee » lorsque que la rencontre est annulée ;
« Resultat » lorsque que la rencontre est annulée du fait du résultat ;
« NombreJoueurs » lorsque que le nombre de joueurs minimum de la fantasy league n’est pas atteint ;
« Joueur » lorsque la prise de jeu est annulée à l’initiative du joueur ;
« Autre » le champ info servira à préciser la nature exacte. SoldeAvant
93/202

Optionnel, unique. Montant du seul compartiment solde du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus. SoldeMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment solde du compte joueur. SoldeApres
Optionnel, unique. Montant du seul compartiment solde du compte joueur après le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir d’un bonus. BonusAvant
Optionnel, unique. Montant du seul compartiment bonus du compte joueur avant le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir du solde. BonusMouvement
Optionnel, unique. Montant du mouvement financier effectué depuis le seul compartiment bonus du compte joueur. BonusApres
Optionnel, unique. Montant du seul compartiment bonus du compte joueur après le mouvement financier. Ce champ n’est pas précisé dans le cas où le pari est réalisé à partir du solde. Tel
Optionnel, unique. Précise si l’annulation a été effectuée via un appel téléphonique ou un SMS (jeu sur compte sous droits exclusifs uniquement). Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.4.4).
94/202

II.6.2 Pari hippique
II.6.2.a Mise sur un pari – PAHIMISE
Présentation de l’évènement.
Le joueur parie sur une rencontre hippique.
Remarque :
Lors de la prise de jeu, si une partie de la mise est dédiée à un jeu complémentaire, comme par exemple de type cagnotte ou jackpot, deux évènements PAHIMISE sont envoyés au coffre. Le premier avec la mise correspondant à la prise de jeu principale et le second à celle du jeu annexe. Ces deux évènements ont des codes Tech différents mais présentent un code supplémentaire, TechJeu, permettant d’identifier de manière unique le jeu dans son ensemble.
Dans l’évènement correspondant à la prise de jeu annexe, la balise Jackpot sera présente.
A noter que dans le cas où il y aurait plusieurs jeux complémentaires, autant d’évènements PAHIMISE que de jeux supplémentaires devront être envoyés.
Structure de l’enregistrement en format XML
PAHIMISE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string-256 Code technique interne du pari
TechJeu 0 1 string Code technique interne du jeu (permettant de relier une ou plusieurs mises complémentaires à la mise principale) Jackpot 0 1 Balise vide Précise si la prise de jeu correspond à une participation à un jeu complémentaire
(cagnotte, jackpot…) Desc 1 64 Desc Description du pari
SoldeAvantMise 0 1 decimal Montant du compartiment solde avant le pari
Mise 0 1 nonNegativeDecimal Montant de la mise
SoldeApresMise 0 1 decimal Montant du compartiment solde après le pari
MiseAbond 0 1 nonNegativeDecimal Montant de l’abondement de mise
BonusAvantMise 0 1 decimal Montant du compartiment bonus avant le pari
BonusMouvement 0 1 nonNegativeDecimal Montant du bonus
BonusApresMise 0 1 decimal Montant du compartiment bonus après le pari
BonusNom 0 1 string Nom du bonus
Tel 0 1 Balise vide Précise si le pari a été pris par téléphone
Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne du coupon de pari. Ce code est utilisé par l’opérateur pour identifier le pari dans la plate-forme de jeu.
TechJeu
Optionnel, unique. Code technique interne du jeu. Ce code doit être renseigné lorsque dans la prise de jeu une partie de la mise est dédiée à un ou plusieurs jeux complémentaires, comme par exemple une cagnotte ou un jackpot. Ce code sera identique pour tous les évènements composant la prise de jeu du joueur.
Jackpot
Optionnel, unique. Précise si la mise correspond à la participation à un jeu complémentaire (comme une cagnotte ou un jackpot).
Desc
Obligatoire, multiple. Description du pari. Pour les paris ayant des mises sur plusieurs courses, ce champ est renseigné autant de fois qu’il y a de courses sélectionnées par le joueur.
95/202

SoldeAvantMise
Optionnel, unique. Montant du compartiment solde du compte joueur avant le pari. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou d’un bonus.
Mise
Optionnel, unique. Montant de la mise. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou d’un bonus.
SoldeApresMise
Optionnel, unique. Montant du compartiment solde du compte joueur après le pari. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou d’un bonus.
MiseAbond
Optionnel, unique. Montant de l’abondement de l’opérateur.
BonusAvantMise
Optionnel, unique. Montant du compartiment bonus du compte joueur avant le pari. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou du solde.
BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou du solde.
BonusApresMise
Optionnel, unique. Montant du compartiment bonus du compte joueur après le pari. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou du solde.
BonusNom
Optionnel, unique. Nom du bonus tel qu’affiché au joueur. Ce champ est optionnel dans le cas où le pari est réalisé à partir d’un abondement ou du solde.
Tel
Optionnel, unique. Précise si le pari a été pris par appel téléphonique ou par SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Structure de l’enregistrement en format XML
Desc
Entité XML Min Max Type Description DateHeure 1 1 date-aammjjhhmmss Date de la course
Hippodrome 1 1 string Nom de l’hippodrome
Pays 1 1 string-64 Pays de l’hippodrome
Reunion 1 1 integer Numéro de la réunion
CNom 1 1 string Nom de la course
CNum 1 1 integer Numéro de la course
Clair 1 1 string Libellé du pari affiché au joueur
PronoPH 1 1 PronoPH Pronostic
Description
DateHeure
Obligatoire, unique. Date et heure de la course.
Hippodrome
Obligatoire, unique. Hippodrome dans lequel se déroule la réunion. Ce champ fait l’objet d’une énumération disponible sur le site de l’ANJ.
Pays
Obligatoire, unique. Pays dans lequel se situe l’hippodrome.
Reunion
Obligatoire. Unique. Numéro de la réunion tel qu’affiché au joueur.
96/202

CNom
Obligatoire, unique. Nom de la course. Libellé du prix tel qu’affiché au joueur. Ce champ doit mis sous forme canonique :
la suppression des diacritiques indépendamment de la casse (accents aigus, graves et circonflexes, trémas et cédilles),
le passage à la casse supérieure,
la suppression des caractères hors de la classe de caractères [0-9A-Zˈ -].
CNum
Obligatoire. Unique. Numéro de la course dans la réunion.
Clair
Obligatoire, unique. Libellé du pari tel qu’il est affiché au joueur lors du pari.
PronoPH
Obligatoire, unique. Pronostic du joueur.
Structure de l’enregistrement en format XML
PronoPH
Entité XML Min Max Type Description Type 1 1 string-64 Type de pari
Base 1 64 string-64 Numéro(s) du(es) cheval(aux) de base
Champ 0 1 Balise vide Pari champ réduit ou total
Combinaison 0 1 Balise vide Pari en combinaison
Associes 0 64 string-64 Numéro(s) du(es) cheval(aux) associés
Tlo 0 1 Balise vide Sélection de l’option tous les ordres
MiseBase 1 1 nonNegativeDecimal Mise élémentaire
Nombre 1 1 integer Nombre de paris élémentaires
Coef 0 64 nonNegativeDecimal Coefficient multiplicateur du gain
Description
Type
Obligatoire, unique. Type de pari hippique. Ce champ est libre, toutefois l’opérateur doit conserver la même chaîne entre deux paris d’un même type.
Base
Obligatoire, multiple. Cheval figurant dans la sélection de base du joueur. Suivant le type de pari, l’ordre d’apparition des lignes peut avoir de l’importance.
Champ
Optionnel, unique. La présence de cette balise indique que le pari est effectué en champ partiel ou total. Les chevaux associés seront indiqués obligatoirement dans le champ Associes,
Combinaison
Optionnel, unique. La présence de cette balise indique que le pari effectué comprend plusieurs combinaisons (i.e que le pari correspond à plusieurs combinaisons de k des n chevaux de base ou associés sélectionnés avec k strictement inférieur à n. Autrement dit cette balise doit être transmise lorsque le nombre de chevaux de base ou associés excède le nombre de chevaux figurant dans un pari unitaire).
Associes
Optionnel, multiple. Cheval figurant dans la sélection champ réduit ou champ complet du joueur. Suivant le type de pari, l’ordre d’apparition des lignes aura de l’importance. En cas de champ total, l’ensemble des chevaux seront renseignés.
Tlo
Optionnel, unique. La présence de cette balise indique que la sélection du joueur comprend tous les ordres possibles.
MiseBase
Obligatoire, unique. Mise élémentaire du joueur. La mise totale associée à la prise de jeu est le produit de la mise élémentaire par le nombre de combinaisons du pari.
Nombre
Obligatoire, Unique. Nombre de paris élémentaires constituant le pari.
Coef
97/202

Optionnel, Multiple. Coefficient multiplicateur associé au gain éventuel du pari. Lorsqu’il est précisé, ce champ doit apparaître autant de fois qu’il y a de paris élémentaires constituant le pari, et l’ordre des coefficients doit respecter l’ordre des paris.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.5.1).
98/202

II.6.2.b Gain sur un pari – PAHIGAIN
Présentation de l’évènement
A l’issue du résultat d’une course hippique ayant fait l’objet de paris, l’opérateur calcule le rapport des paris, identifie les gagnants et le gain pour chacun d’entre eux.
Au moment du débouclage des paris, un évènement de gain PAHIGAIN est envoyé pour chaque pari gagnant.
Remarques
L’événement de gain fait suite à la promulgation d’un résultat, il est poussé immédiatement dans le coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
Structure de l’enregistrement en format XML
PAHIGAIN
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string-256 Code technique interne du pari
DateMise 1 1 date-aammjjhhmmss Date et heure de la mise
DateHeure 1 1 date-aammjjhhmmss Date et heure du résultat du pari SoldeAvantGain 0 1 Decimal Montant du compartiment solde avant le gain Gain 0 1 nonNegativeDecimal Montant du gain
SoldeApresGain 0 1 Decimal Montant du compartiment solde après le gain GainAbond 0 1 nonNegativeDecimal Montant de l’abondement de gain
BonusAvantGain 0 1 Decimal Montant du compartiment bonus avant le gain BonusMouvement 0 1 nonNegativeDecimal Montant du gain
BonusApresGain 0 1 Decimal Montant du compartiment bonus après le gain Info 0 1 string Complément d’information
Description
Tech
Obligatoire, unique. Code technique du pari gagné identique à celui utilisé lors de la mise sur le pari.
DateMise
Obligatoire, unique. Date et heure au format UTC de la mise associée au gain.
DateHeure
Obligatoire, unique. Date et heure au format UTC du résultat sur lequel portait la mise associée au gain.
SoldeAvantGain
Optionnel, unique. Montant du compartiment solde du compte joueur avant le gain.
Gain
Optionnel, unique. Montant du gain : hors abondement.
SoldeApresGain
Optionnel, unique. Montant du compartiment solde du compte joueur après le gain.
GainAbond
Optionnel, unique. Montant de l’abondement de gain.
BonusAvantGain
Optionnel, unique. Montant du compartiment bonus du compte joueur avant le gain.
BonusMouvement
Optionnel, unique. Montant du bonus.
BonusApresGain
Optionnel, unique. Montant du compartiment bonus du compte joueur après le gain.
99/202

Info
Optionnel, unique. Information complémentaire fournie au joueur, résultat gagnant et dans le cas des paris mutuels, montant de la masse des paris.
Des exemples illustratifs de l’évènement figurent trouvés en annexe (partie IV.5.2).
100/202

II.6.2.c Annulation d’un pari – PAHIANNUL
Présentation de l’évènement
Le pari est annulé par le joueur ou bien par l’opérateur, par exemple, si la ou une des courses sur laquelle le pari porte est annulée.
Remarques
- Si l’annulation est à l’initiative de l’opérateur (exemples : course hippique annulée, cheval non partant) elle est alors transmise immédiatement au coffre sans acquittement de la part du joueur, en incluant la balise dans l’entête.
- Si l’annulation est demandée par le joueur, la demande faisant office d’acquittement, l’événement est alors transmis au coffre sans inclure la balise
Structure de l’enregistrement en format XML
PAHIANNUL
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string-256 Code technique interne du pari annulé
DateMise 1 1 date-aammjjhhmmss Date et heure de la prise de pari
Motif 1 1 string-32 Motif de l’annulation
SoldeAvantRembours 0 1 decimal Montant du solde avant l’annulation
MontantRembours 0 1 nonNegativeDecimal Montant du remboursement
SoldeApresRembours 0 1 decimal Montant du solde après l’annulation
BonusAvant 0 1 Decimal Montant du compartiment bonus avant l’annulation BonusMouvement 0 1 nonNegativeDecimal Montant de l’annulation
BonusApres 0 1 Decimal Montant du compartiment bonus après l’annulation Tel 0 1 Précise si l’annulation a été effectuée via téléphone Info 0 1 string Complément d’information
Description
Tech
Obligatoire, unique. Code technique du pari annulé identique à celui utilisé lors de la mise sur le pari.
DateMise
Obligatoire, Unique. Date et heure au format UTC de la mise associée à l’annulation.
Motif
Obligatoire, Unique. Ce champ permettra de préciser le motif de l’annulation, les valeurs possibles sont :
« CourseAnnulee » lorsque que la course est annulée ;
« Resultat » lorsque qu’il n’y a aucun gagnant ;
« NonPartant » lorsque le cheval est non partant ;
« Joueur » lorsque le pari est annulé à l’initiative du joueur ;
« Autre » le champ Info servira à préciser la nature exacte de l’annulation.
SoldeAvantRembours
Optionnel, unique. Montant du compartiment solde du compte joueur avant l’annulation du pari.
MontantRembours
Optionnel, unique. Montant du remboursement.
SoldeApresRembours
Optionnel, unique. Montant du compartiment solde du compte joueur après l’annulation du pari.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant l’annulation.
BonusMouvement
101/202

Optionnel, unique. Montant de l’annulation.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après l’annulation.
Tel
Optionnel, unique. Précise si l’annulation a été effectuée via un appel téléphonique ou un SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Information complémentaire fournie au joueur, cause et conditions de l’annulation.
Un exemple illustratif de l’évènement figure en annexe (partie IV.5.3).
102/202

II.6.3 Poker
II.6.3.a Principe de fonctionnement
Chaque jeu de cercle obéit à un même principe général de fonctionnement même si des règles de jeu spécifiques s’appliquent. Ce principe se décompose en trois étapes donnant chacune lieu à génération d’un évènement spécifique :
Un joueur s’inscrit pour prendre part à un jeu de cercle selon des règles définies. (POINSCRIT)
Le joueur effectue une ou plusieurs parties. (POJEU)
Lorsque le jeu se termine, le participant retire ses gains éventuels sur son compte. (POBILAN)
D’autres évènements peuvent survenir au cours d’un jeu de cercle :
Selon les règles, au cours du jeu, le participant peut faire un achat en rapport avec celui-ci. (POACHAT)
Le participant, au cours du jeu, peut obtenir un gain intermédiaire crédité sans délai sur son compte. (POGAIN)
L’opérateur de jeu ou le participant peuvent abandonner un jeu de cercle en cours pour diverses raisons (POANNUL). Dans ce cas les sommes engagées sont remboursées selon les conditions prévues. L’utilisation d’un évènement CPTEAJUSTOPE en complément de POANNUL peut être nécessaire pour compenser les achats (POACHAT) ou gains (POGAIN) intermédiaires.
Le schéma ci-dessous présente sous forme d’automate ce principe de fonctionnement :
II.6.3.b Règles de jeu
Rappels Le décret 2016-1326 relatif aux catégories de jeux de cercle mentionnées au II de l’article 14 de la loi n°2010-476 du 12 mai 2010 modifiée relative à l’ouverture à la concurrence et à la régulation du secteur des jeux d’argent et de hasard en ligne décrit les règles du jeu de poker, définit les notions utilisées ci-dessous et énonce les versions et variantes de jeu autorisées en ligne.
L’objectif du jeu de poker est de remporter le pot, en ayant la meilleure main.
103/202

Il se joue en tours successifs pendant lesquels, à tour de rôle, les joueurs peuvent, en fonction de la variante, piocher une ou plusieurs cartes, défausser une ou plusieurs cartes, passer leur tour de parole, miser ou se coucher.
La partie se termine à la fin du dernier tour ou s’il n’y a plus qu’un joueur dans la partie. S’il y a plus d’un joueur, les mains sont classées les unes par rapport aux autres en fonction de la variante, les meilleures mains se partagent le pot.
Une main se compose des cartes en possession du joueur (cartes privatives) et éventuellement de cartes partagées (cartes communes). De plus, chaque carte peut être ouverte (visible de tous les joueurs) ou fermées (visible du seul propriétaire).
104/202

II.6.3.c Évènements
II.6.3.c.1 Inscription d’un participant à un jeu de cercle – POINSCRIT
Présentation de l’évènement
L’évènement POINSCRIT matérialise l’inscription à un jeu de cercle
Structure de l’enregistrement en format XML
POINSCRIT Balise XML Min Max Type Description Entête (cf. section II.2.1) Retransmission 0 1 boolean Attribut identifiant un évènement retransmis Test 0 1 boolean Attribut identifiant un compte de test Inscription 1 1 types:reference Identifiant unique d’inscription. Tech 1 1 types:reference Identifiant unique du jeu de cercle. Description 1 1 string Description du jeu de cercle. Format 1 1 cercle:format Description
du format du jeu de cercle SoldeAvant 0 1 decimal Montant du compartiment solde avant le
mouvement financier. SoldeMouvement 0 1 nonNegativeDecimal Valeur du mouvement financier SoldeApres 0 1 decimal Montant du compartiment solde après le
mouvement financier BonusAvant 0 1 decimal Montant du compartiment bonus avant le
mouvement financier BonusMouvement 0 1 nonNegativeDecimal Valeur du mouvement financier BonusApres 0 1 decimal Montant du compartiment bonus après le
mouvement financier Info 0 1 string Complément d’information
Description Retransmission Optionnel, Unique. Attribut indiquant que l’évènement est une nouvelle transmission d’un
évènement déjà envoyé. Test Optionnel, Unique. Attribut indiquant que l’évènement est un test. Inscription
Obligatoire, Unique. Identifiant unique d’inscription au jeu de cercle. Si un joueur effectue plusieurs inscriptions à un même jeu de cercle (ex : format multi-entrée), chacune dispose de son propre code Inscription. Tech
Obligatoire, Unique. Identifiant unique permettant d’identifier le jeu de cercle dans la plate-forme de jeu. Cette identifiant est commun à l’ensemble des joueurs. Description
Obligatoire, Unique. Ce champ permet à l’opérateur de décrire le jeu de cercle. Format
Obligatoire, Unique. Ce champ permet de décrire le format du jeu de cercle. La nomenclature suivante est attendue :
« CG » pour les jeux de cercle en cash-game. Lors d’une partie en cash-game les participants jouent avec des jetons à tout moment et directement convertibles en argent ;
« T[/d] pour les jeux de cercle en tournoi. Lors d’un tournoi les joueurs jouent à l’aide de jetons. Le classement à l’issue du tournoi détermine le ou les vainqueurs ainsi que les gains. Le paramètre code 'd’ peut prendre une ou plusieurs valeurs parmi les suivantes :
« A » pour les achats intermédiaires autorisés. (ex: «cave») ;
« G » pour les gains intermédiaires autorisés. (ex: «bounty») ;
105/202

« M » pour les tournois multi-entrées ;
« S » pour les satellites.
« TDV » pour les jeux de cercle en tournoi à dotation variable. Lorsque les gains potentiels d’un joueur ne sont pas uniquement liés à son classement (ex: coefficient multiplicateur aléatoire).
SoldeAvant
Optionnel, Unique. Montant du compartiment solde du compte joueur avant la prise de jeu. Ce champ est optionnel dans le cas où la prise de jeu serait réalisée à partir d’un bonus.
SoldeMouvement
Optionnel, Unique. Montant de la prise de jeu effectuée depuis le compartiment solde du compte joueur. Remarque : cette valeur n’est pas la valeur cumulée des mises effectuées depuis le compartiment solde et le compartiment bonus. Ce champ est optionnel, et serait absent dans le cas où la prise de jeu serait exclusivement réalisée à partir d’un bonus.
SoldeApres
Optionnel, Unique. Montant du compartiment solde du compte joueur après la prise de jeu. Ce champ est optionnel, et serait absent dans le cas où la prise de jeu serait exclusivement réalisée à partir d’un bonus.
BonusAvant
Optionnel, Unique. Montant du compartiment bonus du compte joueur avant la prise de jeu. Ce champ est optionnel dans le cas où le pari serait réalisé à partir du compartiment solde du compte joueur.
BonusMouvement
Optionnel, Unique. Montant du bonus. Ce champ est optionnel dans le cas où la prise de jeu serait réalisée à partir du compartiment solde du compte joueur.
BonusApres
Optionnel, Unique. Montant du compartiment bonus du compte joueur après la prise de jeu. Ce champ est optionnel dans le cas où la prise de jeu serait réalisée à partir du compartiment solde du compte joueur.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.6.1).
106/202

II.6.3.c.2 Déroulement d’une partie lors d’un jeu de cercle – POJEU
Présentation de l’évènement L’évènement POJEU décrit le déroulement d’une partie lors d’un jeu de cercle. Il peut s’agir d’un évènement associé à un joueur et ne restituant que son point de vue ou d’un évènement de synthèse restituant le déroulé de l’ensemble de la partie (avec l’activité de chaque joueur). Seuls des évènements du deuxième type sont attendus pour décrire des parties de poker. Pour cette raison et pour le poker, l’archivage des évènements POJEU ne nécessite pas d’acquittement préalable du joueur.

Chaque évènement POJEU dispose des codes Tech et Pool pour la traçabilité. Le code Inscription, lui aussi nécessaire aux opérations de contrôle, est précisé dans la liste des participants pour chacun d’entre eux s’il s’agit d’un évènement de synthèse.
Certains évènements (ex : POJEU) sont des évènements de synthèse qui regroupent les informations de jeu de plusieurs joueurs. Pour cette raison, les évènements de ce type sont directement enregistrés dans le coffre-fort sans acquittement. Ces évènements sont précisés dans la suite du document.
Structure de l’enregistrement en format XML
POJEU Balise XML Min Max Type Description Entête (cf. section II.2) Retransmission 0 1 boolean Attribut identifiant un évènement retransmît Test 0 1 boolean Attribut identifiant un compte de test Tech 1 1 types:reference Identifiant unique du jeu de cercle. Pool 1 1 Identifiant unique d’une partie dans un jeu types:reference de cercle. Participants 1 64 poker:player Liste des participants Regle 1 1 types:canonical Codification de la variante de jeu appliquée Description 1 1 string Description de la variante de jeu appliquée Info 0 1 string Informations complémentaires Jeu 1 1 cercle:Tour Déroulement de la partie du jeu
Description Retransmission Optionnel, unique. Attribut indiquant que l’évènement est une nouvelle transmission d’un évènement déjà envoyé. Test Optionnel, unique. Attribut indiquant que l’évènement est un test. Tech Obligatoire, unique. Identifiant unique permettant d’identifier le jeu de cercle dans la plate-forme de jeu. Cette identifiant est commun à l’ensemble des joueurs. Pool Obligatoire, unique. Identifiant unique permettant d’identifier une partie dans un jeu de cercle dans la plate-forme de jeu. Participants Obligatoire, multiple. Chaque participant est décrit à l’aide de l’élément Joueur détaillé pour chaque règle de jeu. Dans le cas d’un évènement de synthèse, au moins deux participants sont nécessaires. Chaque participant prenant part à la partie de poker en cours correspond à un élément XML décrit ci-dessous. Les participants sont listés dans le sous-élément de l’évènement . Regle Obligatoire, unique. Règle de jeu appliquée. Ce champ est normalisé et fait l’objet d’une codification. Ce code est précisé dans la nomenclature ANJ. Description
107/202

Optionnel, unique. Description de la variante de jeu appliquée
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Jeu Obligatoire, unique. Déroulement de la partie du jeu de cercle en cours à l’aide d’un ou plusieurs sous-éléments
.
Structure de l’enregistrement en format XML
Joueur
Balise XML Min Max Type Description IDOper 0 1 types:opId Identifiant de l’opérateur
Oper 0 1 string Nom de l’opérateur
Pays 0 1 string Pays de rattachement de l’opérateur
IDJoueur 1 1 string Identifiant du joueur
IPJoueur 1 1 types:publicIP Adresse IP du joueur
Siege 1 1 nonNegativeDecimal Numéro du siège.
Inscription 1 1 types:reference Identifiant unique d’inscription
Finance 1 1 poker:finance Informations financières relatives au joueur
Description
IDOper
Optionnel, unique. Numéro d’identification de l’opérateur fourni par l’ANJ. Ce champ est obligatoire pour les joueurs d’un opérateur agréé par l’ANJ.
Oper Optionnel, unique. Nom de l’opérateur tel qu’affiché au joueur. Ce champ est obligatoire si IDOper n’est pas présent.
Pays
Ce champ est obligatoire si Optionnel, unique. Pays de rattachement de l’opérateur au format ISO 3166-1 Alpha-2. IDOper n’est pas présent.
IDJoueur
Obligatoire, unique. Identifiant unique du joueur auprès de l’opérateur de jeu.
IPJoueur
Obligatoire, unique. Adresse IP du joueur telle que vue par la plate-forme de jeu. Il s’agit nécessairement d’une adresse IP publique.
Siege
Obligatoire, unique. Numéro du siège du joueur.
Inscription
Obligatoire, unique. Identifiant unique d’inscription au jeu de cercle.
Finance
Obligatoire, unique. Les informations financières du joueur attendues dans le sous-élément Finance sont décrites ci- dessous.
Structure de l’enregistrement en format XML
Finance
Balise XML Min Max Type Description
Net 1 1 xs:decimal Balance à l’issue de la partie.
Total 1 1 nonNegativeDecimal Total des mises engagées.
CaveAvant 1 1 nonNegativeDecimal Valeur de la cave au début de la partie.
CaveApres 1 1 nonNegativeDecimal Valeur de la cave à la fin de la partie.
Rake 0 1 nonNegativeDecimal Rake prélevé
108/202

Description Net
Obligatoire, unique. Ce champ renseigne la balance du joueur à l’issue de la partie. Total
Obligatoire, unique. Total des mises du joueur engagées pendant la partie. CaveAvant
Obligatoire, unique. Montant de la cave avant la partie. CaveApres
Obligatoire, unique. Montant de la cave après la partie. Rake Optionnel, unique. Montant du Rake prélevé sur les mises engagées pendant la partie.
Structure de l’enregistrement en format XML Tour Balise XML Min Max Type Description name 1 1 string Attribut indiquant le nom du tour Timestamp 1 1 date-aammjjhhmmss Date et heure du début du tour Action 1 poker:action Action de jeu Total 1 1 nonNegativeDecimal Total des mises engagées dans le tour
Description Name Obligatoire, unique. Attribut indiquant le nom du tour. Ce champ est unique au sein d’un même POJEU. Timestamp Obligatoire, unique. Date et heure au format UTC du début du tour à la seconde près. Action Obligatoire, multiple. Action de jeu au cours de la partie. Les actions de jeu possibles sont décrites dans les règles de
jeu ci-dessous. Ce champ doit comporter au moins une action de jeu par tour. Total Obligatoire, unique. Total des mises engagées par l’ensemble des joueurs dans le tour.
Description des actions Chaque élément XML correspond à une action possible au sein d’un sous-élément Tour dans l’évènement POJEU.

- Mise effectuée au cours d’une partie de Poker – 
Structure de l’enregistrement en format XML
Bet Balise XML Min Max Type Description Name 0 1 poker:betType Attribut indiquant la nature de la mise. Siege 1 1 nonNegativeInteger Numéro du siège du joueur Valeur 1 1 nonNegativeDecimal Valeur de la mise.
Description Name Optionnel, unique. Attribut indiquant la nature de la mise. Les valeurs autorisées sont
indiquées dans la liste suivante :
« ante » ;
« small blind » ;
« big blind » ;
109/202

« bring-in » ;
« bet » ;
« call » ;
« raise » ;
« allin ». Siege Obligatoire, unique. Numéro du siège du joueur effectuant l’action. Valeur Obligatoire, unique. Valeur de la mise correspondant à la somme ajoutée au pot lors de la mise.
- Distribuer ou piocher une carte – 
Structure de l’enregistrement en format XML
Draw Balise XML Min Max Type Description Ouverte 0 1 boolean Attribut indiquant si la carte est ouverte Commune 0 1 boolean Attribut indiquant si la carte est commune Siege 0 1 nonNegativeInteger Numéro du siège Valeur 1 1 nonNegativeInteger Valeur de la carte Board 0 1 nonNegativeInteger Identifiant du board (cartes communes)
Description Ouverte
Optionnel, unique. La présence de cet attribut indique que la carte est ouverte. Cette information est commune à tous les joueurs. Commune
Optionnel, unique. La présence de cet attribut indique que la carte est commune. Cette information est commune à tous les joueurs. Siege
Optionnel, unique. Numéro du siège du joueur possédant la carte. Ce champ est renseigné lorsque la carte n’est pas commune, il est absent lorsque la carte est commune. Valeur Obligatoire, unique. Valeur de la carte. Ce champ est codifié et prend les valeurs du tableau ci-dessous. Board
Optionnel, unique. Identifie le board d’appartenance d’une carte commune lorsque plusieurs boards coexistent.
- Parole – 
Structure de l’enregistrement en format XML
Check Balise XML Min Max Type Description Siege 1 1 nonNegativeInteger Numéro du siège
Description Siege Obligatoire, unique. Numéro du siège du joueur effectuant l’action « parole ».
- Se coucher – 
Structure de l’enregistrement en format XML
110/202

Fold Balise XML Min Max Type Description Siege 1 1 nonNegativeInteger Numéro du siège Reveal 0 1 boolean Révélation des cartes privatives
Description Siege Obligatoire, unique. Numéro du siège du joueur effectuant l’action « se coucher ». Reveal Optionnel, unique. Indique si les cartes privatives du joueur effectuant l’action « se coucher » sont révélées. Par défaut, en l’absence de ce champ, il est considéré que ces cartes ne sont pas montrées aux autres joueurs.
- Défausser une carte – 
Structure de l’enregistrement en format XML
Discard Balise XML Min Max Type Description Siege 0 1 nonNegativeInteger Numéro du siège Valeur 1 1 nonNegativeInteger Valeur de la carte
Description Siege Optionnel, unique. Numéro du siège du joueur possédant la carte. Ce champ est renseigné lorsque la carte n’est pas commune, il est absent lorsque la carte est commune. Valeur Obligatoire, unique. Valeur de la carte. Ce champ est codifié et prend les valeurs du tableau ci-dessous.
- Révéler une carte – 
Cette action est utilisée pour indiquer qu’une carte auparavant invisible de l’ensemble des joueurs a été révélée à ces derniers. Cette action est utilisée en fin de partie lorsque les joueurs révèlent leur main pour déterminer le gagnant.
Structure de l’enregistrement en format XML
Reveal Balise XML Min Max Type Description Siege 0 1 nonNegativeInteger Numéro du siège Valeur 1 1 nonNegativeInteger Valeur de la carte
Description Siege Optionnel, unique. Numéro du siège du joueur possédant la carte. Ce champ est renseigné lorsque la carte n’est pas commune, il est absent lorsque la carte est commune. Valeur Obligatoire, unique. Valeur de la carte. Ce champ est codifié et prend les valeurs du tableau ci-dessous.
Codification des cartes Une carte est codifiée à l’aide d’un entier pouvant prendre une valeur de 0 à 51 (inclus) en fonction de la couleur et de la valeur conformément au tableau ci-dessous :
Couleur Valeur faciale
111/202

2 3 4 5 6 7 8 9
Trèfle 0 4 8 12 16 20 24 28
Carreau 1 5 9 13 17 21 25 29
Cœur 2 6 10 14 18 22 26 30
Pique 3 7 11 15 19 23 27 31
Un exemple illustratif de l’évènement figure en annexe (partie IV.6.2).
10 V D R A
32 36 40 44 48
33 37 41 45 49
34 38 42 46 50
35 39 43 47 51
112/202

II.6.3.c.3 Bilan financier d’un jeu de cercle – POBILAN
Présentation de l’évènement
À l’issue d’un jeu de cercle, l’évènement POBILAN permet à l’opérateur d’informer des différents reversements dans les compartiments financiers d’un joueur en fonction de ses gains et/ou pertes. Si le joueur a perdu l’ensemble des sommes engagées, un POBILAN avec mouvement financier nul est généré pour indiquer la fin de la participation au jeu.
Structure de l’enregistrement en format XML
POBILAN Balise XML Min Max Type Description Entête (cf. section II.2.1) Retransmission 0 1 boolean Attribut identifiant un évènement retransmis Test 0 1 boolean Attribut identifiant un compte de test Inscription 1 1 types:reference Identifiant unique d’inscription. Tech 1 1 types:reference Identifiant unique du jeu de cercle. Classement 0 1 Integer Classement du joueur SoldeAvant 0 1 decimal Montant du compartiment solde avant le mouvement financier. SoldeMouvement 0 1 types: Valeur du mouvement financier nonNegativeDecimal SoldeApres 0 1 decimal Montant du compartiment solde après le mouvement financier BonusAvant 0 1 decimal Montant du compartiment bonus avant le mouvement financier BonusMouvement 0 1 types: Valeur du mouvement financier nonNegativeDecimal BonusApres 0 1 decimal Montant du compartiment bonus après le mouvement financier Info 0 1 string Complément d’information
Description Retransmission Optionnel, unique. Attribut indiquant que l’évènement est une nouvelle transmission d’un évènement. Test Optionnel, unique. Attribut indiquant que l’évènement est un test. Inscription Obligatoire, unique. Identifiant unique d’inscription au jeu de cercle. Tech Obligatoire, unique. Identifiant unique permettant d’identifier le jeu de cercle dans la plate-forme de jeu. Cette identifiant est commun à l’ensemble des joueurs. Classement Facultatif, unique. Classement final du joueur à la fin de la partie. Ce champ doit être obligatoirement renseigné pour les joueurs classés. En particulier, il doit impérativement être précisé lorsque le joueur finit à une place payée lors d’un tournoi. SoldeAvant Optionnel, unique. Montant du compartiment solde du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain serait réalisé à partir d’un bonus. SoldeMouvement Optionnel, unique. Montant du gain effectué depuis le compartiment solde du compte joueur. Ce champ est optionnel, et serait absent dans le cas où le gain serait exclusivement réalisé à partir d’un bonus.
113/202

SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après le gain. Ce champ est optionnel, et serait absent dans le cas où le gain serait exclusivement réalisé à partir d’un bonus.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain serait réalisé à partir du compartiment solde du compte joueur.
BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où le gain serait réalisée à partir du compartiment solde du compte joueur.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après le gain. Ce champ est optionnel dans le cas où le gain serait réalisé à partir du compartiment solde du compte joueur.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.6.3).
114/202

II.6.3.c.4 Achat en cours de jeu – POACHAT
Présentation de l’évènement
Il s’agit d’un achat lié au jeu de cercle lorsqu’elle est réalisée par le joueur. Cet évènement ne peut intervenir qu’entre un évènement POINSCRIT et un évènement POBILAN, si les règles du jeu le permettent.
L’évènement POACHAT est utilisé au Poker afin d’indiquer l’achat d’une cave en cours de jeu. L’évènement POACHAT ne nécessite pas d’indiquer la quantité de jetons achetés.
Structure de l’enregistrement en format XML
POACHAT Balise XML Min Max Type Description Entête (cf. section II.2.1) Retransmission 0 1 boolean Attribut identifiant un évènement retransmis Test 0 1 boolean Attribut identifiant un compte de test Inscription 1 1 types:reference Identifiant unique d’inscription. Tech 1 1 types:reference Identifiant unique du jeu de cercle. Description 1 1 string Description de l’opération SoldeAvant 0 1 decimal Montant du compartiment solde avant le mouvement financier. SoldeMouvement 0 1 types: Valeur du mouvement financier nonNegativeDecimal SoldeApres 0 1 decimal Montant du compartiment solde après le mouvement financier BonusAvant 0 1 decimal Montant du compartiment bonus avant le mouvement financier BonusMouvement 0 1 types: Valeur du mouvement financier nonNegativeDecimal BonusApres 0 1 decimal Montant du compartiment bonus après le mouvement financier Info 0 1 string Complément d’information
Description Retransmission
Optionnel, unique. Attribut indiquant que l’évènement est une nouvelle transmission d’un évènement déjà envoyé. Test
Optionnel, unique. Attribut indiquant que l’évènement est un test. Inscription Obligatoire, unique. Identifiant unique d’inscription au jeu de cercle. Tech Obligatoire, unique. Identifiant unique permettant d’identifier le jeu de cercle dans la plate-forme de jeu. Cette identifiant est commun à l’ensemble des joueurs. Description Obligatoire, unique. Champ libre permettant à l’opérateur d’expliquer le motif de l’achat. SoldeAvant
Optionnel, unique. Montant du compartiment solde du compte joueur avant l’achat. Ce champ est optionnel dans le cas où l’achat serait réalisé à partir d’un bonus. SoldeMouvement
Optionnel, unique. Montant de l’achat effectué depuis le compartiment solde du compte joueur. Ce champ est optionnel, et serait absent dans le cas où l’achat serait exclusivement réalisé à partir d’un bonus.
115/202

SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après l’achat. Ce champ est optionnel, et serait absent dans le cas où l’achat serait exclusivement réalisé à partir d’un bonus. BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant l’achat. Ce champ est optionnel dans le cas où l’achat serait réalisé à partir du compartiment solde du compte joueur. BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où l’achat serait réalisé à partir du compartiment solde du compte joueur. BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après l’achat. Ce champ est optionnel dans le cas où l’achat serait réalisé à partir du compartiment solde du compte joueur. Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.6.4).
116/202

II.6.3.c.5 Gain en cours de jeu – POGAIN
Présentation de l’évènement
Cet évènement constate une opération visant à créditer directement le compte d’un joueur sans attendre la fin du jeu en cours. Cet évènement ne peut intervenir qu’entre un évènement POINSCRIT et un évènement POBILAN, si les règles du jeu le permettent.
Structure de l’enregistrement en format XML
POGAIN
Balise XML Min Max Type Description
Entête (cf. section II.2.1) Retransmission 0 1 boolean Attribut identifiant un évènement retransmis Test 0 1 boolean Attribut identifiant un compte de test
Inscription 1 1 types:reference Identifiant unique d’inscription.
Tech 1 1 types:reference Identifiant unique du jeu de cercle.
Description 1 1 string Description de l’opération
SoldeAvant 0 1 decimal Montant du compartiment solde avant le
mouvement financier. SoldeMouvement 0 1 types: Valeur du mouvement financier nonNegativeDecimal SoldeApres 0 1 decimal Montant du compartiment solde après le
mouvement financier BonusAvant 0 1 decimal Montant du compartiment bonus avant le
mouvement financier BonusMouvement 0 1 types: Valeur du mouvement financier nonNegativeDecimal BonusApres 0 1 decimal Montant du compartiment bonus après le
mouvement financier Info 0 1 string Complément d’information
Description
Retransmission
Optionnel, Unique. Attribut indiquant que l’évènement est une nouvelle transmission d’un évènement déjà envoyé.
Test
Optionnel, Unique. Attribut indiquant que l’évènement est un test.
Inscription
Obligatoire, Unique. Identifiant unique d’inscription au jeu de cercle.
Tech
Obligatoire, Unique. Identifiant unique permettant d’identifier le jeu de cercle dans la plate-forme de jeu. Cette identifiant est commun à l’ensemble des joueurs.
Description
Obligatoire, Unique. Il s’agit d’un champ libre qui permet à l’opérateur d’expliquer le motif du gain.
SoldeAvant
Optionnel, Unique. Montant du compartiment solde du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain serait réalisé à partir d’un bonus.
SoldeMouvement
Optionnel, Unique. Montant du gain effectué depuis le compartiment solde du compte joueur. Ce champ est optionnel, et serait absent dans le cas où le gain serait exclusivement réalisé à partir d’un bonus.
SoldeApres
117/202

Optionnel, Unique. Montant du compartiment solde du compte joueur après le gain. Ce champ est optionnel, et serait absent dans le cas où le gain serait exclusivement réalisé à partir d’un bonus.
BonusAvant
Optionnel, Unique. Montant du compartiment bonus du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain serait réalisé à partir du compartiment solde du compte joueur.
BonusMouvement
Optionnel, Unique. Montant du bonus. Ce champ est optionnel dans le cas où le gain serait réalisé à partir du compartiment solde du compte joueur.
BonusApres
Optionnel, Unique. Montant du compartiment bonus du compte joueur après le gain. Ce champ est optionnel dans le cas où le gain serait réalisé à partir du compartiment solde du compte joueur.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.6.5).
118/202

II.6.3.c.6 Annulation d’une participation – POANNUL
Présentation de l’évènement
Cet évènement retrace l''annulation d’une inscription à un jeu de cercle et toutes les conséquences qui en découlent, notamment sur le plan financier.
Structure de l’enregistrement en format XML
POANNUL Balise XML Min Max Type Description Entête (cf. section II.2.1) Retransmission 0 1 boolean Attribut identifiant un évènement retransmît Test 0 1 boolean Attribut identifiant un compte de test Inscription 1 1 types:reference Identifiant unique d’inscription. Tech 1 1 types:reference Identifiant unique du jeu de cercle. Motif 1 1 string Motif de l’annulation SoldeAvant 0 1 decimal Montant du compartiment solde avant le
mouvement financier. SoldeMouvement 0 1 nonNegativeDecimal Valeur du mouvement financier SoldeApres 0 1 decimal Montant du compartiment solde après le
mouvement financier BonusAvant 0 1 decimal Montant du compartiment bonus avant le
mouvement financier BonusMouvement 0 1 nonNegativeDecimal Valeur du mouvement financier BonusApres 0 1 decimal Montant du compartiment bonus après le
mouvement financier Info 0 1 string Complément d’information
Description Retransmission Optionnel, Unique. Attribut indiquant que l’évènement est une nouvelle transmission d’un évènement déjà envoyé. Test Optionnel, Unique. Attribut indiquant que l’évènement est un test. Inscription Obligatoire, Unique. Identifiant unique d’inscription au jeu de cercle. Tech Obligatoire, Unique. Identifiant unique permettant d’identifier le jeu de cercle dans la plate-forme de jeu. Cette identifiant est commun à l’ensemble des joueurs. Motif Obligatoire, Unique. Précise le motif de l’annulation. Les valeurs possibles sont :
« NombreJoueurs » lorsque que le nombre de joueurs minimum de la table ou du tournoi n’est pas atteint ;
« Joueur » lorsque le joueur quitte la table ou le tournoi ;
« Deconnexion » lorsque le joueur subit une déconnexion ;
« Autre » le champ info servira à préciser la nature exacte. SoldeAvant Optionnel, Unique. Montant du compartiment solde du compte joueur avant l’annulation. Ce champ n’est pas rempli dans le cas où l’annulation serait réalisée à partir d’un bonus. SoldeMouvement Optionnel, Unique. Montant de l’annulation effectuée depuis le compartiment solde du compte joueur. Ce champ est absent dans le cas où l’annulation est exclusivement réalisée à partir d’un bonus.
119/202

SoldeApres
Optionnel, Unique. Montant du compartiment solde du compte joueur après l’annulation. Ce champ est absent dans le cas où l’annulation est exclusivement réalisée à partir d’un bonus.
BonusAvant
Optionnel, Unique. Montant du compartiment bonus du compte joueur avant l’annulation. Ce champ est absent dans le cas où l’annulation est réalisée à partir du compartiment solde du compte joueur.
BonusMouvement
Optionnel, Unique. Montant du bonus. Ce champ est absent dans le cas où l’annulation est réalisée à partir du compartiment solde du compte joueur.
BonusApres
Optionnel, Unique. Montant du compartiment bonus du compte joueur après l’annulation. Ce champ est absent dans le cas où l’annulation est réalisée à partir du compartiment solde du compte joueur.
Info
Optionnel, Unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.6.6).
120/202

II.6.4 Loterie
II.6.4.a Jeux de tirage
II.6.4.a.1 Mise sur un jeu de tirage – LOTIMISE
Présentation de l’évènement
Cet évènement constate le placement par un joueur d’une mise sur un jeu de tirage.
Lorsque le joueur effectue plusieurs prises de jeu lors d’une même mise à un jeu de tirage, autant d’évènements sont envoyés au coffre que de jeux élémentaires.
Remarques :
1. Lorsque le joueur souscrit à plusieurs tirages lors d’une même prise de jeu, un seul évènement LOTIMISE sera envoyé au coffre, celui-ci indiquant autant de champs que de tirages concernés par la prise de jeu.
2. Lors de la prise de jeu, si une partie de la mise est dédiée à un jeu complémentaire, comme par exemple une cagnotte ou un jackpot, deux évènements LOTIMISE sont envoyés au coffre. Le premier avec la mise correspondant à la prise de jeu principale et le second à celle du jeu annexe. Ces deux évènements ont des codes Tech différents mais présentent un code supplémentaire, TechJeu, permettant
d’identifier de manière unique le jeu dans son ensemble. Dans l’évènement correspondant à la prise de jeu annexe, la balise Jackpot sera présente.
A noter que dans le cas où il y aurait plusieurs jeux complémentaires, autant d’évènements LOTIMISE que de jeux supplémentaires devront être envoyés.
Pour les potentiels abonnements à durée illimitée, il sera demandé d’envoyer un évènement à chaque fois qu’il y aura un prélèvement à cet effet sur le compte joueur.
Structure de l’enregistrement en format XML
LOTIMISE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string Code technique interne de la prise de jeu TechJeu 0 1 string Code technique interne du jeu
(permettant de relier une ou plusieurs mises complémentaires à la mise principale) Jackpot 0 1 balise vide Précise si la prise de jeu correspond à une participation à un jeu complémentaire (cagnotte, jackpot…) Desc 1 1 Desc Description du jeu de tirage
Selection 1 1 Selection Sélection du joueur
SoldeAvant 0 1 decimal Montant du compartiment solde avant la prise de jeu SoldeMouvement 0 1 nonNegativeDecimal Montant de la prise de jeu
SoldeApres 0 1 decimal Montant du compartiment solde après la prise de jeu MiseAbond 0 1 nonNegativeDecimal Montant de l’abondement de la prise de jeu BonusAvant 0 1 decimal Montant du compartiment bonus avant la prise de jeu BonusMouvement 0 1 nonNegativeDecimal Montant du bonus
BonusApres 0 1 decimal Montant du compartiment bonus après la prise de jeu
121/202

BonusNom 0 1 string Nom du bonus
Tel 0 1 Balise vide Précise si le pari a été pris par téléphone Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme.
TechJeu
Optionnel, unique. Code technique interne du jeu. Ce code doit être renseigné lorsque dans la prise de jeu une partie de la mise est dédiée à un ou plusieurs jeux complémentaires, comme par exemple une cagnotte ou un jackpot. Ce code sera identique pour tous les évènements composant la prise de jeu du joueur.

Jackpot
Optionnel, unique. Champ précisant que la mise correspond à la participation à un jeu complémentaire (comme une cagnotte ou un jackpot).
Desc
Obligatoire, unique. Description du jeu de tirage.
Selection
Obligatoire, unique. Choix du joueur.
SoldeAvant
Optionnel, unique. Montant du compartiment solde du compte joueur avant la prise de jeu. Ce champ est obligatoire si le jeu est réalisé à partir du compte joueur. Il n’est pas rempli dans le cas où le jeu est réalisé à partir d’un abondement ou d’un bonus.
SoldeMouvement
Optionnel, unique. Montant de la mise. Ce champ est obligatoire si le jeu est réalisé à partir du compte joueur. Il n’est pas rempli dans le cas où le jeu est réalisé à partir d’un abondement ou d’un bonus.
SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après la prise de jeu. Ce champ est obligatoire si le jeu est réalisé à partir du compte joueur. Il n’est pas rempli dans le cas où le jeu est réalisé à partir d’un abondement ou d’un bonus.
MiseAbond
Optionnel, unique. Montant de l’abondement de l’opérateur.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant la prise de jeu. Ce champ est obligatoire lorsque le jeu est réalisé grâce à un bonus. Il n’est pas rempli si le jeu est réalisé à partir d’un abondement ou du solde.
BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ obligatoire lorsque le jeu est réalisé grâce à un bonus Il n’est pas rempli si le jeu est réalisé à partir d’un abondement ou du solde.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après la prise de jeu. Ce champ est obligatoire lorsque le jeu est réalisé grâce à un bonus. Il n’est pas rempli si le jeu est réalisé à partir d’un abondement ou du solde.
BonusNom
Optionnel, unique. Nom du bonus tel qu’affiché au joueur. Ce champ est obligatoire lorsque le jeu est réalisé grâce à un bonus. Il n’est pas rempli si le jeu est réalisé à partir d’un abondement ou du solde.
Tel
Optionnel, unique. Précise si le pari a été pris par appel téléphonique ou par SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Structure de l’enregistrement en format XML
122/202

Desc Entité XML Min Max Type Description Clair 1 1 string Nom du jeu de tirage Nom 1 1 string Nom technique du jeu de tirage Tirage 1 64 Tirage Description du tirage
Description Clair Obligatoire, unique. Nom complet du jeu tel qu’affiché au joueur. Nom Obligatoire, unique. Nom technique du jeu utilisé par l’opérateur. Tirage Obligatoire, multiple. Description du jeu du tirage. Ce champ est renseigné autant de fois qu’il y a de tirages souscrits par le joueur.
Structure de l’enregistrement en format XML
Tirage Entité XML Min Max Type Description DateHeure 1 1 date-aammjjhhmmss Date et heure du tirage IDTirage 1 1 String-64 Code technique interne du tirage
Description DateHeure Obligatoire, unique. Date et heure du tirage IDTirage Obligatoire, unique. Code technique interne du jeu de tirage. Ce code est utilisé par l’opérateur pour identifier le jeu de tirage dans sa plate-forme de jeu.
Structure de l’enregistrement en format XML Selection Entité XML Min Max Type Description Nombre 1 1 Integer Nombre de grilles sélectionnées Option 0 64 string Options sélectionnées par le joueur lors de sa prise de jeu IDGroupe 0 1 String-64 Code technique interne de la sélection partagée
Description Nombre Obligatoire, unique. Nombre de grilles sélectionnées par le joueur lors d’une prise de jeu. Option Optionnel, multiple. Options complémentaires sélectionnées par le joueur telles qu’elles lui sont affichées. IDGroupe Optionnel, unique. Code technique interne de la sélection. Ce code est utilisé par l’opérateur pour identifier une sélection dans la plate-forme de jeu lorsque celle-ci est partagée par plusieurs joueurs (cas d’une sélection de grille au Loto par exemple).
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.7.1).
123/202

II.6.4.a.2 Gain sur un jeu de tirage– LOTIGAIN
Présentation de l’évènement
A la fin de chaque jeu de tirage un évènement de gain LOTIGAIN est généré pour chaque mise gagnante afin d’établir un bilan financier.
Structure de l’enregistrement en format XML
LOTIGAIN
Entité XML Min Max Type Description
Entête (cf. section II.2) Tech 1 1 string Code technique interne de la prise de jeu DateMise 1 1 Date_aammjjhhmmss Date de la prise de jeu associée
SoldeAvant 0 1 decimal Montant du compartiment solde avant le gain SoldeMouvement 0 1 nonNegativeDecimal Montant du gain
SoldeApres 0 1 decimal Montant du compartiment solde après le gain GainAbond 0 1 nonNegativeDecimal Montant de l’abondement du gain
BonusAvant 0 1 decimal Montant du compartiment bonus avant le gain BonusMouvement 0 1 nonNegativeDecimal Montant du bonus
BonusApres 0 1 decimal Montant du compartiment bonus après le gain
Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme.
DateMise
Obligatoire, unique. Date au format UTC de la prise de jeu associée au gain.
SoldeAvant
Optionnel, unique. Montant du compartiment solde du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou d’un bonus.
SoldeMouvement
Optionnel, unique. Montant du gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou d’un bonus.
SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou d’un bonus.
GainAbond
Optionnel, unique. Montant de l’abondement du gain de l’opérateur.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou du solde.
BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou du solde.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou du solde.
124/202

Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.7.2).
125/202

II.6.4.a.3 Bilan sur un jeu de tirage– LOTIBILAN
Présentation de l’évènement
A la fin de chaque jeu de tirage un évènement de gain LOTIBILAN est généré pour chaque mise, afin d’établir un bilan et cela, même en l’absence de gain.
Structure de l’enregistrement en format XML
LOTIBILAN
Entité XML Min Max Type Description
Entête (cf. section II.2) Tech 1 1 string Code technique interne de la prise de jeu DateMise 1 1 Date_aammjjhhmmss Date de la prise de jeu associée
NombreChoix 0 1 Integer Nombre de choix du joueur
Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme.
DateMise
Obligatoire, unique. Date au format UTC de la prise de jeu associée à la prise de jeu.
NombreChoix
Optionnel, unique. Nombre de choix du joueur effectué au cours du jeu ayant un impact sur l’issue du résultat ou sur le montant du gain, comme par exemple le nombre de fois où le joueur a cliqué pour lancer des dés, révéler une case ou effectué un choix de type quitte ou double.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.7.3).
126/202

II.6.4.a.4 Annulation sur un jeu de tirage – LOTIANNUL
Présentation de l’évènement Cet évènement est enregistré à l’initiative du joueur ou de l’opérateur pour annuler une prise de jeu sur un jeu de tirage. Il reflète le remboursement de la prise de jeu et des éventuelles options. Structure de l’enregistrement en format XML LOTIANNUL Entité XML Min Max Type Description Entête (cf. section II.2) Tech 1 1 string Code technique interne de la prise de jeu DateMise 1 1 date_aammjjhhmmss Date de la prise de jeu associée Motif 1 1 String-32 Motif de l’annulation SoldeAvant 0 1 decimal Montant du compartiment solde avant l’annulation SoldeMouvement 0 1 nonNegativeDecimal Montant de l’annulation SoldeApres 0 1 decimal Montant du compartiment solde après l’annulation BonusAvant 0 1 decimal Montant du compartiment bonus avant l’annulation BonusMouvement 0 1 nonNegativeDecimal Montant du bonus BonusApres 0 1 decimal Montant du compartiment bonus après l’annulation Tel 0 1 Balise vide Précise si l’annulation a été effectuée via téléphone Info 0 1 string Informations complémentaires
Description Tech Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme. DateMise Obligatoire, unique. Date au format UTC de la prise de jeu associée à l’annulation. Motif Obligatoire, unique. Ce champ permettra de préciser le motif de l’annulation, les valeurs possibles sont :
« Tirage » lorsque que le tirage est annulé ;
« Joueur » lorsque la prise de jeu est annulée à l’initiative du joueur ;
« Autre » le champ info servira à préciser la nature exacte.
SoldeAvant Optionnel, unique. Montant du compartiment solde du compte joueur avant l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou d’un bonus. SoldeMouvement Optionnel, unique. Montant de l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou d’un bonus.
127/202

SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou d’un bonus.
BonusAvant
Optionnel, Unique. Montant du compartiment bonus du compte joueur avant l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou du solde.
BonusMouvement
Optionnel, Unique. Montant du bonus. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou du solde.
BonusApres
Optionnel, Unique. Montant du compartiment bonus du compte joueur après l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou du solde.
Tel
Optionnel, unique. Précise si l’annulation a été effectuée via un appel téléphonique ou un SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.7.4).
128/202

II.6.4.b Jeux instantanés
II.6.4.b.1 Mise sur un jeu instantané – LOJIMISE
Présentation de l’évènement.
Cet évènement est généré lorsque le joueur effectue une mise sur un jeu instantané.
Remarque :
Lors de la prise de jeu, si une partie de la mise est dédiée à un jeu complémentaire, comme par exemple une cagnotte ou un jackpot, deux évènements LOJIMISE sont envoyés au coffre. Le premier avec la mise correspondant à la prise de jeu principale et le second à celle du jeu annexe. Ces deux évènements ont des codes Tech différents mais présentent un code supplémentaire, TechJeu, permettant d’identifier de manière unique le jeu dans son ensemble. Dans l’évènement correspondant à la prise de jeu annexe, la balise Jackpot sera présente.
A noter que dans le cas où il y aurait plusieurs jeux complémentaires, autant d’évènements LOJIMISE qu’il y a de jeux supplémentaires devront être envoyés.
Structure de l’enregistrement en format XML
LOJIMISE
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string Code technique interne de la prise de jeu
TechJeu 0 1 string Code technique interne du jeu (permettant de relier une ou plusieurs mises complémentaires à la mise principale) Jackpot 0 1 Balise vide Précise si la prise de jeu correspond à une participation à un jeu complémentaire (cagnotte, jackpot…) Desc 1 1 Desc Description du jeu instantané
SoldeAvant 0 1 decimal Montant du compartiment solde avant la prise de jeu SoldeMouvement 0 1 nonNegativeDecimal Montant de la prise de jeu
SoldeApres 0 1 decimal Montant du compartiment solde après la prise de jeu MiseAbond 0 1 nonNegativeDecimal Montant de l’abondement de la prise de jeu
BonusAvant 0 1 decimal Montant du compartiment bonus avant la prise de jeu BonusMouvement 0 1 nonNegativeDecimal Montant du bonus
BonusApres 0 1 decimal Montant du compartiment bonus après la prise de jeu BonusNom 0 1 string Nom du bonus
Tel 0 1 Balise vide Précise si le pari a été pris par téléphone
Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa,plate-forme.
TechJeu
Optionnel, unique. Code technique interne du jeu. Ce code doit être renseigné lorsque dans la prise de jeu une partie de la mise est dédiée à un ou plusieurs jeux complémentaires, comme par exemple une cagnotte ou un jackpot. Ce code sera identique pour tous les évènements composant la prise de jeu du joueur.
Jackpot
Optionnel, unique. Précise si la mise correspond à la participation à un jeu complémentaire (comme une cagnotte ou un jackpot).
129/202

Desc
Obligatoire, unique. Description du jeu instantané.
SoldeAvant
Optionnel, unique. Montant du compartiment solde du compte joueur avant la prise de jeu. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou d’un bonus.
SoldeMouvement
Optionnel, unique. Montant de la mise. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou d’un bonus.
SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après la prise de jeu. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou d’un bonus.
Abond
Optionnel, unique. Montant de l’abondement de l’opérateur.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant la prise de jeu. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou du solde.
BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou du solde.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après la prise de jeu. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou du solde.
BonusNom
Optionnel, unique. Nom du bonus tel qu’affiché au joueur. Ce champ est optionnel dans le cas où le jeu est réalisé à partir d’un abondement ou du solde.
Tel
Optionnel, unique. Précise si le pari a été pris par appel téléphonique ou par SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Structure de l’enregistrement en format XML
Desc
Entité XML Min Max Type Description Clair 1 1 string Nom du jeu instantané
Nom 1 1 string Nom technique du jeu instantané
Option 0 64 string Options sélectionnées par le joueur lors de sa prise de jeu
Description
Clair
Obligatoire, unique. Nom du jeu tel qu’affiché au joueur.
Nom
Obligatoire, unique. Nom technique du jeu utilisé par l’opérateur.
Option
Optionnel, multiple. Options complémentaires sélectionnées par le joueur telles qu’elles lui sont affichées.
Des exemples illustratifs de l’évènement figurent en annexe (partie IV.7.5).
130/202

II.6.4.b.2 Gain sur un jeu instantané – LOJIGAIN
Présentation de l’évènement
A la fin de chaque jeu instantané un évènement de gain LOJIGAIN est envoyé pour chaque mise gagnante afin d’établir un bilan financier.
Structure de l’enregistrement en format XML
LOJIGAIN
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string Code technique interne de la prise de jeu DateMise 1 1 Date_aammjjhhmmss Date de la prise de jeu associée
SoldeAvant 0 1 decimal Montant du compartiment solde avant le gain SoldeMouvement 0 1 nonNegativeDecimal Montant du gain
SoldeApres 0 1 decimal Montant du compartiment solde après le gain GainAbond 0 1 nonNegativeDecimal Montant de l’abondement du gain
BonusAvant 0 1 decimal Montant du compartiment bonus avant le gain BonusMouvement 0 1 nonNegativeDecimal Montant du bonus
BonusApres 0 1 decimal Montant du compartiment bonus après le gain Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme.
DateMise
Obligatoire, unique. Date au format UTC de la prise de jeu associée au gain.
SoldeAvant
Optionnel, unique. Montant du compartiment solde du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou d’un bonus.
SoldeMouvement
Optionnel, unique. Montant du gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou d’un bonus.
SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou d’un bonus.
GainAbond
Optionnel, unique. Montant de l’abondement du gain de l’opérateur.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou du solde.
BonusMouvement
Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou du solde.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après le gain. Ce champ est optionnel dans le cas où le gain est réalisé à partir d’un abondement ou du solde.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
131/202

Des exemples illustratifs de l’évènement figurent en annexe (partie IV.7.6).
132/202

II.6.4.b.3 Bilan sur un jeu instantané – LOJIBILAN
Présentation de l’évènement
A la fin de chaque jeu de tirage un évènement de gain LOJIGAIN est envoyé pour chaque mise afin d’établir un bilan et cela, même en l’absence de gain.
Structure de l’enregistrement en format XML
LOJIBILAN
Entité XML Min Max Type Description
Entête (cf. section II.2.1) Tech 1 1 string Code technique interne de la prise de jeu DateMise 1 1 Date_aammjjhhmmss Date de la prise de jeu associée
NombreChoix 0 1 integer Nombre de choix du joueur
Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme.
DateMise
Obligatoire, unique. Date au format UTC de la prise de jeu associée au gain.
NombreChoix
Optionnel, unique. Nombre de choix que le joueur a effectué dans le jeu ayant un impact sur l’issue du résultat ou sur le montant du gain, comme par exemple le nombre de fois où le joueur a cliqué pour lancer des dés, révéler une casse ou effectué un choix de type quitte ou double. Ce champ est obligatoire quand un choix du joueur intervient dans la détermination du résultat.
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.7.7).
133/202

II.6.4.b.4 Annulation sur un jeu instantané – LOJIANNUL
Présentation de l’évènement
Cet évènement est généré à l’initiative du joueur ou de l’opérateur pour annuler une prise de jeu sur un jeu instantané. Il reflète le remboursement de la prise de jeu et des éventuelles options souscrites à cette occasion.
Structure de l’enregistrement en format XML
LOJIANNUL
Entité XML Min Max Type Description
Entête (cf. section II.2) Tech 1 1 string Code technique interne de la prise de jeu DateMise 1 1 Date_aammjjhhmmss Date de la prise de jeu associée
Motif 1 1 string-32 Motif de l’annulation
SoldeAvant 0 1 decimal Montant du compartiment solde avant l’annulation SoldeMouvement 0 1 nonNegativeDecimal Montant de l’annulation
SoldeApres 0 1 decimal Montant du compartiment solde après l’annulation BonusAvant 0 1 decimal Montant du compartiment bonus avant l’annulation BonusMouvement 0 1 nonNegativeDecimal Montant du bonus
BonusApres 0 1 decimal Montant du compartiment bonus après l’annulation Tel 0 1 Balise vide Précise si l’annulation a été effectuée par téléphone Info 0 1 string Informations complémentaires
Description
Tech
Obligatoire, unique. Code technique interne de la prise de jeu. Ce code est utilisé par l’opérateur pour identifier la prise de jeu dans sa plate-forme.
DateMise
Obligatoire, unique. Date au format UTC de la prise de jeu associée à l’annulation.
Motif
Obligatoire, unique. Ce champ permettra de préciser le motif de l’annulation, les valeurs possibles sont :
« Jeu » lorsque que le jeu instantané est annulé pour une raison inhérente au jeu en lui-même ;
« Joueur » lorsque la prise de jeu est annulée à l’initiative du joueur ;
« Autre » le champ Info servira à préciser la nature exacte de l’annulation.
SoldeAvant
Optionnel, unique. Montant du compartiment solde du compte joueur avant l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou d’un bonus.
SoldeMouvement
Optionnel, unique. Montant de l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou d’un bonus.
SoldeApres
Optionnel, unique. Montant du compartiment solde du compte joueur après l’annulation. Ce champ est optionnel dans le cas où l’annulation est réalisée à partir d’un abondement ou d’un bonus.
BonusAvant
Optionnel, unique. Montant du compartiment bonus du compte joueur avant l’annulation.
Ce champ est optionnel dans le cas où la mise initiale a été effectuée à partir d’un abondement ou du solde.
BonusMouvement
134/202

Optionnel, unique. Montant du bonus. Ce champ est optionnel dans le cas où la mise initiale a été effectuée à partir d’un abondement ou du solde.
BonusApres
Optionnel, unique. Montant du compartiment bonus du compte joueur après l’annulation. Ce champ est optionnel dans le cas où la mise initiale a été effectuée à partir d’un abondement ou du solde.
Tel
Optionnel, unique. Précise si l’annulation a été effectuée via un appel téléphonique ou un SMS (jeu sur compte sous droits exclusifs uniquement).
Info
Optionnel, unique. Informations complémentaires libres présentant un intérêt.
Un exemple illustratif de l’évènement figure en annexe (partie IV.7.8).
135/202

III Exigences techniques relatives aux données mises à la disposition de l’ANJ de façon périodique ou à la demande
Rappel des dispositions légales et réglementaires (extraits)

Loi n°2010-476 Article 38 I.-Un contrôle permanent de l’activité des opérateurs de jeux ou de paris en ligne agréés et de l’activité de l’opérateur titulaire de droits exclusifs pour son activité de jeux de loterie en ligne est réalisé par l’Autorité nationale des jeux […]. A cet effet, les opérateurs mettent à la disposition permanente de l’Autorité nationale des jeux des données […] II.-Un contrôle de l’activité des opérateurs titulaires de droits exclusifs au titre de leur activité en réseau physique de distribution est réalisé par l’Autorité nationale des jeux […] A cette fin, les opérateurs mettent à la disposition permanente de l’Autorité nationale des jeux des données: [… ] Article 42 : I. Pour l’accomplissement des missions qui lui sont confiées, l’Autorité nationale des jeux peut recueillir toutes les informations nécessaires auprès des ministres compétents, ainsi que des opérateurs de jeux ou de paris en ligne et des opérateurs titulaires de droits exclusifs et se faire communiquer tout document en la possession de ces opérateurs..[….] II.-Des fonctionnaires et agents habilités à cet effet par le directeur général de l’Autorité nationale des jeux procèdent, sous sa direction, aux enquêtes administratives nécessaires […] III.-Dans le cadre des enquêtes qu’ils conduisent, les fonctionnaires et agents mentionnés au premier alinéa du II peuvent demander aux opérateurs tout renseignement et se faire communiquer tout document utile quel qu’en soit le support et en prendre copie. […] Dans l’exercice de ces pouvoirs d’enquête, le secret professionnel ne peut leur être opposé par les opérateurs.[…] Décret n° 2010-518 Article 28 : Les données mentionnées à l’article 30 sont mises à la disposition de l’Autorité … :
1° Par l’accès permanent au support matériel d’archivage dont dispose l’autorité ;
2° Par la transmission périodique à l’autorité de données, exhaustives ou agrégées, extraites de la plate-forme de l’opérateur ;
3° A la suite d’une demande ponctuelle formulée par l’autorité.
Il ressort des dispositions législatives et réglementaires reprises ci-dessus qu’outre les données évoquées au II du présent document, l’Autorité peut demander aux opérateurs toute information qu’elle juge utile dans le cadre de ses missions et ce, selon plusieurs modalités. Afin de sécuriser les transmissions d’informations et de données dont certaines peuvent être nominatives ou comporter des éléments économiques dont la confidentialité doit être assurée, l’Autorité met à disposition de opérateurs et des certificateurs un serveur de dépôt dont les modalités de fonctionnement sont décrites ci-après.
III.1 Caractéristiques techniques générales du service
E_DATA_TGS_1 Le dépôt de données s’effectue selon plusieurs étapes : Etape 1 : authentification mutuelle de l’opérateur et de l’ANJ, par le biais de clefs publiques client et serveur ; Etape 2 : établissement d’un canal sécurisé entre l’autorité et l’opérateur, assurant authentification des parties, confidentialité et authenticité des données ; Etape 3 : transmission des données vers le serveur.
Etape 1 :
136/202

La clef publique GPG de l’ANJ, son empreinte, l’adresse IP, le nom de domaine pleinement qualifié du serveur de dépôt ainsi que l’empreinte cryptographique de sa clef SSH de ce serveur sont communiqués à l’opérateur par l’autorité à l’occasion de la réunion d’échange des paramètres cryptographiques (en complément de la clef de chiffrement des données stockées au niveau du coffre-fort électronique) suite à la délivrance de son premier agrément. Le protocole utilisé pour le dépôt de données est basé sur le protocole SFTP dont la couche de transport est SSH en version 2 exclusivement. L’authentification du déposant doit se faire par clé publique respectant des conditions de sécurité précisées par l’Autorité et susceptibles d’évoluer dans le temps. Les authentifications par mot de passe ou via une clé DSA ne sont pas autorisées.
E_DATA_TGS_2 : L’opérateur communique à l’ANJ la clé publique permettant d’authentifier ses connexions.
Celle-ci peut être remise :
- soit en main propre, inscrite sur support amovible ;
- soit par message électronique signé numériquement, et dont la signature numérique est reconnue par l’ensemble des destinataires ;
- soit par message électronique sans signature numérique. Dans ce cas, l’empreinte de la clé publique devra être transmise par un autre moyen de communication (exemple : téléphone, SMS, etc.). Par ailleurs, une vérification par liste noire de clés dites « faibles » est réalisée automatiquement lors de la phase d’authentification de l’opérateur : la clé utilisée ne doit pas être inscrite dans cette liste noire.
Etape 2 Le sous-système utilisé est celui de SFTP. Toutefois, le jeu de commandes est restreint afin d’offrir de meilleure garantie de sécurité des informations déposées : ainsi, un fichier ou un répertoire créé sur le serveur de dépôt ne peut être par la suite lu, supprimé ou même renommé. Les informations de connexion sont accessibles dans la rubrique « ressources techniques » sur le site de l’Autorité les suivantes : E_DATA_TGS_3 : L’opérateur communique à l’Autorité les adresses IP des clients de connexion au serveur de dépôt afin de garantir le filtrage et la traçabilité des accès. Le serveur de dépôt de l’ANJ dispose d’une clé RSA de 4096 bits. La valeur de la clé publique du serveur de dépôt ne change pas, sauf si une procédure exceptionnelle de changement de clé est réalisée par l’ANJ. L’opérateur s’assure donc que l’empreinte annoncée par le serveur de dépôt est strictement identique à celle indiquée.
E_DATA_TGS_4 : En cas de valeur incorrecte de l’empreinte de la clé publique, il est demandé d’interrompre les connexions vers le serveur de dépôt et de contacter l’ANJ à l’adresse fonctionnelle suivante : acquittement@anj.fr.
E_DATA_TGS_5 : Dans le cadre de cette procédure, les messages envoyés sont signés numériquement à l’aide des certificats de l’opérateur.
Etape 3 Chaque opérateur dispose d’une arborescence isolée sur le serveur de dépôt, dans laquelle il peut déposer les données et documents qui lui sont demandées par l’ANJ. E_DATA_TGS_6 : Les données transmises via le serveur de dépôt sont chiffrées à l’aide de la clé évoquée plus haut. L’empreinte de la clef publique PGP de l’Autorité au format GnuPG Party est accessible dans la rubrique « ressources techniques » sur le site de l’Autorité » Remarque : cette clé est différente de la clé utilisée pour le chiffrement du code source.
137/202

III.2 Format des données et conventions de nommage
III.2.1 Généralités
E_DATA_CNG_1 : L’opérateur dépose les éléments selon le format et la convention de nommage définis par les services de l’Autorité.
Dans tous les cas, : les seuls caractères autorisés sont les caractères alphabétiques en minuscule/majuscule ([a-z][A-Z]), les chiffres ([0-9]), le caractère point (« . ») et le caractère tiret (« - ») . En revanche, les caractères accentués ou encore le caractère « espace » sont proscrits ;
Pour être accepté, le nom d’un fichier déposé suit la nomenclature suivante :
----specificlabel>.[.gpg]
Avec :
- : chaine de caractère identifiant le service destinataire du fichier considéré. Valeurs possibles :
o SUPERVISION :
o CONTROLE :
o ENQUETES :
- : identifiant de l’opérateur. format : \d{4} ;
- : chaine de caractères décrivant la date du dépôt. format : \d{8} respectant le motif AAAAMMJJ. L’opérateur veillera à ce que cette date soit effectivement celle du dépôt du fichier.
- : numéro d’ordre du dépôt. Ce numéro est renseigné dans le cas où le dépôt d’un même fichier est répété plusieurs fois dans la même journée. Par défaut, ce numéro d’ordre a pour valeur « 01 ». format : \d{2} ;
- : chaine de caractère fournie par le demandeur.
: extension décrivant le format du ficher fourni.
- [.gpg] : dans le cas d’un fichier chiffré l’extension « .gpg » termine le nom du fichier considéré.
E_DATA_CNG_2 : Si des difficultés apparaissent lors du choix des valeurs à indiquer dans un quelconque de ces champs, pour l’Opérateur contacte l’ANJ qui lui indiquera quelles valeurs mentionner.
RG : Tout fichier ne répondant pas à ce nommage sera ignoré par les services.
En outre, sont précisés ci-après certains éléments relatifs d’une part aux données de supervision et d’autre part aux autres données et informations susceptibles d’être communiquées à l’autorité à sa demande.
III.2.2 Précisions
III.2.2.a Données dites de supervision
E_DATA_SUP_1 : La transmission des données dites de supervision, données agrégées dont l’envoi à l’Autorité est périodique respecte la convention de nommage suivante :
-SUPERVISION
-specificlabel>.
o : la fréquence du rapport de supervision avec les choix possibles suivants:
o J pour journalier,
o H pour hebdomadaire,
o M pour mensuel,
138/202

o et : la période correspondant au rapport de supervision. La date est au format YYYYMMDD (YYYY : année, MM : mois, DD : jour). La date de début et de fin sont identiques pour un rapport journalier ;
III.2.2.b Autres données
Le tableau ci-dessous précise la valeur -selon l’objet de la transmission
 – données ayant vocation en principe à être transmis via le support matériel d’archivage CONTROLE mais dont les circonstances nécessitent un nouvel envoi Autres données et informations dont la mise à disposition permanente de l’Autorité est SUIVI prévue par les textes informations susceptibles d’être demandées en application de l’article 42 de la loi du ENQUETE 12 mai 2010. demande d’homologation HOMOLOGATION demandes d’agrément ou de renouvellement AGREMENT
139/202

IV ANNEXES IV.1 Exemples relatifs à l’utilisation de la balise
Le tableau ci-dessous expose différents cas pour lesquels l’acquittement n’est pas demandé et d’autres pour lesquels l’action du joueur est nécessaire (l’action faisant office d’acquittement)
Cas pour lesquels les événements sont Evénements transmis au coffre à l’initiative de Evénements transmis au coffre suite à
l’opérateur sans acquittement du joueur – l’action du joueur (acquittement) utilisation de la balise
* Validation du formulaire d’inscription OUVINFOPERSO
* Acceptation des conditions générales OKCONDGENE
* Définition des modérateurs PREFCPTE
* Vérification des pièces d’identités par
CPTEIDENTITE l’opérateur
* Vérification de l’adresse par l’opérateur
* Saisi du code de confirmation CPTEADRESSE à partir d’un justificatif de domicile
* Changement de statut du compte OUVOKCONFIRME
* Le joueur n’a plus la possibilité
* Modification des coordonnées bancaires d’acquitter (exemple : compte clos) CPTEREF
* Correction de l’opérateur suite à la vérification des pièces
* Tentative de connexion au jeu ACCESREFUSE (exemples : compte clos, joueur auto- interdit)
* Le joueur n’a plus la possibilité
* Modification des données personnelles d’acquitter (exemple : compte clos) MODIFINFOPERSO
* Correction de l’opérateur suite à la vérification des pièces
* Demande d’autointerdiction AUTOINTERDICTION
* Clôture à l’initiative de l’opérateur
* Demande de clôture CLOTUREDEM (exemple : compte inactif depuis plus d’un an)
* Alimentation créditée après un délai de
* Alimentation immédiatement créditée CPTEALIM traitement (vérifications) sur le compte sur le solde du compte joueur joueur (date effective <> date demande)
* Abondement accordé à l’initiative de
* Abondement résultant immédiatement l’opérateur (exemple : récompense de d’une action du joueur (exemple : échange CPTEABOND l’activité du joueur) de points de fidélité contre un abondement)
* Le joueur n’a plus la possibilité
* Demande de retrait CPTERETRAIT d’acquitter (exemple : compte clos)
* Modérateur de retrait atteint
* Bonus accordé à l’initiative de
* Bonus résultant immédiatement d’une CPTEALIMOPE l’opérateur (exemple : récompense de action du joueur (exemple : échange de l’activité du joueur) points de fidélité contre un bonus)
* Ajustement à l’initiative de l’opérateur
CPTEAJUSTOPE (exemple : annulation de retrait)
140/202

Cas pour lesquels les événements sont Evénements transmis au coffre à l’initiative de
l’opérateur sans acquittement du joueur – utilisation de la balise
* Lot nature accordé à l’initiative de LOTNATURE l’opérateur (exemple : récompense de l’activité du joueur)
PASPMISE
* Promulgation du résultat PASPGAIN
* Annulation à l’initiative de l’opérateur (exemples : Abandon en cours d’un match PASPANNUL de tennis, demande de l’ARJEL pour « match sans enjeu »)
PAHIMISE
* Promulgation du résultat PAHIGAIN
* Annulation à l’initiative de l’opérateur PAHIANNUL
* Inscription automatique (exemple : POINSCRIT inscription directe suite à une victoire lors
d’un satellite)
* (re)Cave automatique POACHAT
* Jeu automatique (exemple : après POJEU déconnexion impromptue du joueur)
* Paiement du gain dès le résultat du POGAIN joueur connu
* Paiement d’un gain intermédiaire (type bounty)
* Le joueur est éjecté (exemples : après POBILAN une déconnexion, modérateur de temps de jeu atteint)
* Annulation à l’initiative de l’opérateur POANNUL (exemple : nombre de joueur minimum
requis non atteint)
FAINSCRIT
FAACHAT
FAJEU
* Promulgation d’un résultat FAGAIN intermédiaire
* Promulgation du résultat FABILAN
* Annulation à l’initiative de l’opérateur FAANNUL
LOTIMISE
Evénements transmis au coffre suite à l’action du joueur (acquittement)
* Lot nature résultant immédiatement d’une action du joueur (exemple : échange de points de fidélité contre un lot nature)
* Prise de jeu
* Cash-out
* Demande d’annulation
* Prise de jeu
* Demande d’annulation
* Inscription
* (re)Cave à l’initiative du joueur
* Action de jeu du joueur
* Le joueur quitte la table
* Demande d’annulation
* Inscription
* Achat d’option
* Validation de la sélection
* Demande d’annulation
* Prise de jeu
141/202

Cas pour lesquels les événements sont Evénements transmis au coffre à l’initiative de Evénements transmis au coffre suite à
l’opérateur sans acquittement du joueur – l’action du joueur (acquittement) utilisation de la balise
* Promulgation du résultat LOTIGAIN
* Promulgation du résultat LOTIBILAN
* Annulation à l’initiative de l’opérateur * Demande d’annulation LOTIANNUL
* Prise de jeu LOJIMISE
* Promulgation du résultat LOJIGAIN
* Promulgation du résultat LOJIBILAN
* Annulation à l’initiative de l’opérateur * Demande d’annulation LOJIANNUL
Certaines actions des joueurs peuvent entraîner l’envoi au coffre de plusieurs événements (exemple : une demande d’autointerdiction définitive sera à l’origine d’un événement AUTOINTERDICTION suivi immédiatement d’un événement CLOTUREDEM). Dans ce cas, puisque le joueur est à l’origine de l’action initiale, aucun des événements ne sera agrémenté de la balise
Exemple 1 : Entête sans la balise L’entête ci-dessous représente l’évènement de jeu 495018 de l’opérateur 4921 généré par le coffre 2. Le joueur 9G3912JF est connecté à la plate-forme de jeu depuis l’adresse 192.0.2.42 (adresse IP RFC 5735 retenue pour l’exemple). Cet évènement a été capté le 12 avril 2010 à 10:33:20 (UTC).
4921 100412103320 495018 9G3912JF 9853E488E24120BC18F9A650AED9CEE0FF72B09E 192.0.2.42 948JF95194NBJ2 2
Exemple 2 : Entête avec la balise
L’entête ci-dessous représente un l’évènement de jeu 5950 de l’opérateur 0042. Le joueur foobar75@domain.tld est connecté à la plate-forme de jeu depuis l’adresse 192.0.2.42. Cet évènement a été transmis à l’initiative de l’opérateur sans acquittement de la part du joueur le 12 avril 2010 à 10:33:20 (UTC). Le champ IDSession est renseigné avec une valeur standardisée « 0-sys » et le champ IPSession avec l’adresse IP privée de l’opérateur.
Conséquence pour l’opérateur : dans ce cas, les joueurs ne peuvent pas modifier leur adresse de messagerie électronique, car IDJoueur utilise cette information pour identifier les évènements de jeu. Il est donc important de spécifier un identifiant de joueur unique pour la plate-forme de jeu (ex : clef primaire de base de données).
0042 100412103320 5950 foobar75@domain.tld 9853E488E24120BC18F9A650AED9CEE0FF72B09E 192.168.1.1
0-sys
1
142/202

143/202

IV.2 Exemples relatifs aux évènements de fonctionnement du compte joueur
IV.2.1 Informations personnelles – OUVINFOPERSO
Dans l’exemple présenté ci-dessous, l’opérateur a fait le choix d’avoir des champs IDJoueur, Login (identique au champ Email) et Pseudo différents. Seul le champ IDJoueur permet d’identifier le joueur entre les évènements de jeu.
L’entité Prenom est multiple. La première entité contient le prénom désigné par le joueur comme étant son premier prénom du joueur. La seconde entité contient tous les autres prénoms, séparés par une espace (« Guillaume Jacques »).
L’empreinte du joueur, en vue d’une intégration à l’entête de l’évènement, est calculée sur la forme canonique suivante : « JEANPIERREDUPOND19791201NICE ».

4921
100412103320
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
jean-pierre.dupond@domain.tld
jd13
Dupond
Jean-pierre
Guillaume Jacques
M
19791201
Nice
06
France
254 traverse du roi de pique
13012
Marseille
France
0721242429
jean.dupond@domain.tld
IV.2.2 Acceptation des conditions générales du site – OKCONDGENE
Le joueur 9G3912JF accepte les clauses du règlement portant conditions générales de l’offre de jeux et de paris.
4921
100413121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
144/202

IV.2.3 Modérateurs et seuil de reversement – PREFCPTE
Le joueur décide de fixer le montant maximal de ses mises à 20 euros sur une période de sept jours pour son activité en paris sportifs, et à 10 euros pour son activité en paris hippiques. Il conditionne aussi le reversement automatique du compte joueur vers son compte de paiement lorsque son solde dépasse la somme de 10 euros pour ramener son solde à 10 euros.
4921
100412103320
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
10
10
20
PS
10
PH
100412103320
IV.2.4 Confirmation de l’identité du joueur – CPTEIDENTITE
L’opérateur a reçu une pièce d’identité du joueur 9G3912JF. Celle-ci concorde avec les informations déclarées par le joueur. L’opérateur valide l’identité du joueur.
4921
191113121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
PieceIdentite
IV.2.5 Confirmation de l’adresse – CPTEADRESSE
Exemple 1 L’opérateur a reçu et vérifié le justificatif de domicile du joueur 9G3912JF. L’évènement CPTEADRESSE est transmis au coffre (avec la balise dans l’entête) lorsque l’opérateur valide l’adresse du joueur.
4921
191113121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
145/202

146/202

Exemple 2 Le joueur 9G3912JF saisit le code d’activation envoyé par l’opérateur, l’évènement CPTEADRESSE est transmis au coffre sans la balise dans l’entête.
4921
191113121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
IV.2.6 Confirmation du compte – OUVOKCONFIRME
L’opérateur confirme le compte du joueur 9G3912JF.
4921
100413121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
IV.2.7 Références du compte de paiement – CPTEREF
Exemple 1 Le joueur a transmis à l’opérateur les références de son compte de paiement sous la forme d’un IBAN. . Le libellé associé au prestataire de service de paiement est lui-même déduit du code interbancaire et des ressources de l’ACPR. Le code interbancaire ainsi que le libellé sont renseignés par le capteur :
4512
150701055724
239899333
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638605
192.0.2.42
1
20041
LA BANQUE POSTALE
FR1420041010050500013M02606
147/202

Exemple 2 Le joueur saisit a transmis à l’opérateur les références de son compte de paiement sous la forme d’un identifiant défini par un prestataire de monnaie électronique. Le code interbancaire correspondant (12345) figure dans la liste des établissements de monnaie électronique publiée par l’ACPR. Le libellé associé au prestataire de service de paiement est lui-même déduit du code interbancaire et des ressources de l’ACPR. Le code interbancaire ainsi que le libellé sont renseignés par le capteur :
4512
150701055724
239899333
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638605
192.0.2.42
1
12345
monnaie electronique
identifiant@monnaie-electronique.fr
IV.2.8 Refus d’accès – ACCESREFUSE
Le joueur 9G3912JF a vu son accès refusé au site, car il n’a pas renvoyé les pièces justificatives dans les délais imposés.
4921
100413121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
Vous n’avez pas renvoyé vos justificatifs
DelaiIdentite

148/202

IV.2.9 Rectification des informations personnelles – MODIFINFOPERSO
Le joueur 9G3912JF modifie son pseudonyme en foobar.
4921
150412103320
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
jean-pierre.dupond@domain.tld
foobar
Dupond
Jean-pierre
Guillaume Jacques
M
19791201
Nice
06
France
254 traverse du roi de pique
13012
Marseille
France
0721242429
jean.dupond@domain.tld
IV.2.10 Déclaration d’auto-interdiction du joueur – AUTOINTERDICTION
Le joueur d’identifiant 9G3912JF s’interdit de jouer. L’interface du site lui propose de fixer soit une durée d’auto- interdiction, librement fixée ou à choisir dans une liste de durées prédéfinies, soit une date de fin d’auto-interdiction. Le joueur sélectionne la durée prédéfinie de 2 mois. Il effectue sa demande le 10 mars 2011 à 12h30 (UTC) : son auto- interdiction à prise en compte immédiate est donc effective jusqu’au 10 mai 2011 inclus.
4921
110310123004
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
110210123004
2
M
110511000000
149/202

IV.2.11 Déclaration de limitation du joueur – LIMITMISE
L’opérateur a choisi de limiter les mises du joueur d’identifiant 9G3912JF à 5€ par pari, dans le cadre de la lutte contre l’addiction. Cette limitation est prévue pour durer du 1er janvier 2021 au 31 mars de la même année.
4921
201231123004
495019
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
210101000000
210331235959
Limitation des mises à 5€ par pari
Lutte contre l’addiction
150/202

IV.2.12 Clôture du compte joueur – CLOTUREDEM
À la clôture de son compte, le solde du joueur est de 5.60 €.
4921
100413121030
495020
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.0.2.42
2
5.6
Joueur
IV.2.13 Alimentation du compte joueur – CPTEALIM
Le joueur réalise un versement à l’aide d’une carte bancaire. La demande est effectuée le 20 juin 2010 à 12h03 (UTC) (DateDemande). Le versement est effectif, après validation par la banque et prise en compte par la plate-forme de jeu, le 20 juin 2012 à 13h18 (UTC) (DateEffective). L’évènement est ici transmis immédiatement au coffre à la DateEffective sans acquittement de la part du joueur :
4921
120620131800
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
123456
120620120305
120620131800
15
20
35
VISA
CarteBancaire
IV.2.14 Retrait du compte joueur – CPTERETRAIT
Le joueur réalise un retrait de 2,50€ à partir du compartiment solde de son compte :
4921
100621121030
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
948JF95194NBJ2
192.168.0.3
2
123456
100621120930
25.5
51
25.5
151/202

25.5
IV.2.15 Abondement du compartiment solde – CPTEABOND
L’opérateur reverse un « RakeBack » à un joueur de poker au début de chaque mois. Le montant est calculé en fonction des sommes que le joueur a engagées le mois précédent et du profil « bronze » de ce dernier. Le profil est une offre de fidélisation interne à l’opérateur, dont le support matériel d’archivage n’enregistre pas le mode de comptage. L’abondement est transmis au coffre sans acquittement de la part du joueur (en incluant la balise dans l’entête) le 2 septembre 2010 à 18:34:02 (UTC). Le champ Info précise, par exemple, le taux de 10% de « RakeBack » appliqué au joueur.
4921
100902183402
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
123456
20.3
2.4
22.7
RakeBack mensuel profil bronze 10/100
RakeBack
IV.2.16 Abondement du compartiment bonus – CPTEALIMOPE
Exemple 1 L’opérateur reverse un bonus suite à un pari sportif gagné. L’abondement est transmis au coffre sans acquittement de la part du joueur (en incluant la balise dans l’entête) le 2 septembre 2010 à 18:34:02. Le champ BonusInfo précise l’origine du bonus.
4921
100902183402
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
123456
1
12
13
pari sportif L1J4 gagne
152/202

Exemple 2 Bonus constituant en un pari « gratuit » L’opérateur crédite un bonus au joueur pour effectuer un pari « gratuit ».
4921
100902183402
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
123456
1.14
1.5
2.64
Pari gratuit
IV.2.17 Attribution de lots en nature – LOTNATURE
L’opérateur attribue un lot nature au joueur en fonction de son activité sur son site.
4921
100902183402
495018
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
567894
tee-shirt
10
IV.2.18 Ajustement – CPTEAJUSTOPE
153/202

Exemple 1 : Ajustement d’une alimentation Cet exemple fait écho à l’exemple de la partie IV.2.13. L’alimentation du joueur a été refusée par la banque, l’opérateur retire donc le montant de l’alimentation du compte joueur.
Le solde du joueur est négatif après l’ajustement car le joueur a utilisé une partie de celui-ci depuis l’alimentation, Il ne peut donc effectuer aucune mise tant que son solde n’est pas positif.
4921
120621100100
495145
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
123456
Refus alimentation du 20/06/2012
Alimentation
10
20
-10
Exemple 2 : Ajustement d’un retrait Cet exemple fait écho à l’exemple de la partie IV.2.14. Le retrait du joueur n’a pas été crédité sur son compte bancaire, l’opérateur restitue le montant du retrait sur son compte joueur.
4921
100622121030
495145
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
2
123456
Refus retrait du 21/06/2010
Retrait
32
25.5
57.5
154/202

IV.3 Exemples relatifs aux évènements d’identification des points de vente permettant la prise de jeu sur compte
IV.3.1 Ouverture d’un point de vente à la prise de jeu sur compte – OUVPOINTDEVENTE
4921
100412103320
495018
2
157894
20211207
127 avenue de la dame de coeur
69008
Lyon
France
10
IV.3.2 Modification des informations relatives à un point de vente ouvert à la prise de jeu sur compte – MODIFPOINTDEVENTE
Le point de vente 157894 change de taille.
4921
150412103320
495018
2
157894
127 avenue de la dame de coeur
69008
Lyon
France
20
IV.3.3 Clôture d’un point de vente au jeu sur compte – CLOTUREPOINTDEVENTE
4921
100413121030
495020
2
457892

155/202

IV.4 Exemples relatifs aux évènements des paris sportifs
IV.4.1 Mise sur un pari – PASPMISE
Exemple 1 : pari simple.
Le joueur effectue un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea – Valence CF ». Le pari porte sur le résultat du match, et le joueur pronostique un match nul. La cote de ce pari est 3.40. La mise du joueur est 1.50 €. Le solde du joueur se porte à 47.33 €. La mise est effectuée à partir du compartiment solde du joueur.
L’espérance de gain calculée est : 1.50*3.40 = 5.10 €.
Il s’agit d’un match de la 6ème journée du groupe E de la Ligue des champions 2011-2012. Il est programmé le 6 décembre à 20h45 en France, soit 19h45 (UTC). L’ensemble de ces informations sont affichées au joueur lors de la prise du pari.
En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « UEFA Champions League », dont le code est « AB123 » ;
- le type de résultat « match nul (résultat d’un match) » a pour code « 123CD ».
Les champs Renc et Part sont renseignés sous forme canonique.
Il n’existe pas ici de discipline associée au sport.
Le pronostic comprend un pronostic élémentaire, qui porte sur un résultat d’égalité.
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
8ACEB0TV
S
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
123CD
NUL
3.40
1.50
47.33
1.50
45.83
Remarque : dans le cas d’un pari à handicap, pronostiquant, par exemple, la victoire de Chelsea avec un handicap de 1, le champ PronoSp pourra être considéré comme étant un pari spécial constitué de l’union entre les pronostics dépendants
156/202

« victoire (sur le résultat d’un match) » (code « 456AB ») et « écart entre les équipes
» (code « 789CD ») :
456AB
CHELSEA
789CD
Chelsea
Exemple 2 : pari simple multiple.
Le joueur effectue 3 paris simples dans un même coupon le 4 décembre 2011 à 10h17 (UTC) sur les rencontres « Chelsea
– Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ». Les paris simples portent sur le vainqueur de chaque rencontre.
La mise du joueur est spécifique à chacun des trois paris, et vaut respectivement 1.30 €, 1.40 € et finalement 1.50 €, soit une mise totale de 4.20 €.
Le coupon est scindé en 3 paris distincts, et sa validation produira donc 3 évènements PASPMISE distincts et successivement générés. Le solde du joueur initial, réel comme affiché, se porte à 47.33 €.
La mise est effectuée à partir du compartiment solde du joueur.
La première rencontre a été décrite dans le premier exemple. Il s’agit d’un match de la 6ème journée du groupe E de la Ligue des champions 2011-2012, programmé le 6 décembre à 20h45 en France, soit 19h45 (UTC). Le pronostic désigne CHELSEA comme vainqueur de la rencontre. La cote est 1.65, et la mise est de 1.30 €.
En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « UEFA Champions League », dont le code est « AB123 » ;
- le type de résultat « victoire (résultat d’un match) » a pour code « 456AB ».
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
8ACEB0TV
S
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
1.65
1.30
47.33
1.30
157/202

46.03
La seconde rencontre est un match de la 6ème journée du groupe F de la Ligue des champions 2011-2012, programmé le 6 décembre à 20h45 en France, soit 19h45 (UTC). Elle oppose Dortmund à Marseille. Le pronostic désigne DORTMUND comme vainqueur de la rencontre. La cote est 1.70, et la mise est de 1.40 €.
4512
111204101703
1903811
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
DRVKCAX9
S
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
456AB
DORTMUND
1.70
1.40
46.03
1.40
44.63
La troisième et dernière rencontre est également un match de la 6ème journée du groupe F de la Ligue des champions 2011-2012, programmé le 6 décembre à 20h45 en France, soit 19h45 (UTC). Elle oppose Olympiakos à Arsenal. Le pronostic désigne Olympiakos comme vainqueur de la rencontre. La cote est 1.95, et la mise est de 1.50 €.
4512
111204101703
1903814
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
JSL5WONA
S
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
5A1T-1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
158/202

OLYMPIAKOS
1.95
1.50
44.63
1.50
43.13
Exemple 3 : pari combiné (simple).
Le joueur effectue un pari combiné le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ». Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
La mise est effectuée à partir du compartiment solde du joueur.
La mise élémentaire affectée à chaque pronostic de résultat est de 0.50 €. La mise totale est donc de 1.50 € également, dans la mesure où il s’agit d’un combiné simple qui correspond à un seul pari.
Les cotes sont respectivement 1.65, 1.70 et 1.95. La cote totale est le produit de ces cotes, soit : 1.65*1.70*1.95 = 5.47.
L’espérance de gain est donc : (1.65*1.70*1.95) * 1.50 = 8.20 €.
En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « UEFA Champions League », dont le code est « AB123 » ;
- le type de résultat « victoire (résultat d’un match) » a pour code « 456AB ».
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
ABLSTJEK
C
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
1.65
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
159/202

MARSEILLE
456AB
DORTMUND
1.70
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
OLYMPIAKOS
1.95
0.50
47.33
1.50
45.83
Exemple 4a : pari combiné multiple.
Le joueur effectue un pari combiné le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ». Les pronostics de résultats portent sur le vainqueur de chaque rencontre et un pronostic de résultat supplémentaire concerne une égalité sur la rencontre « Chelsea – Valence CF ». En application du règlement de jeu, ce pronostic est non combinable avec le pronostic de résultat portant sur le vainqueur de la rencontre, et dédouble donc le pari combiné.
Ce pari combiné est donc un pari combiné multiple, et deux paris combinés sont envoyés au coffre.
La mise est effectuée à partir du compartiment solde du joueur.
La mise élémentaire affectée à chaque pari combiné est de 1.50 €. La mise totale est donc de 3.00 €, dans la mesure où il s’agit d’un combiné multiple qui correspond à deux paris :
pour le premier pari, les cotes sont respectivement de 1.65, 1.70 et 1.95. La cote totale du pari combiné correspondant est le produit de ces cotes, soit : 1.65*1.70*1.95 = 5.47 ;
pour le second pari, les cotes sont respectivement de 3.40, 1.70 et 1.95. La cote totale du pari combiné correspondant est le produit de ces cotes, soit : 3.40*1.70*1.95 = 11.27. L’espérance de gain maximale est celle du pari le plus intéressant, donc (3.40*1.70*1.95) * 1.50 = 16.91 €.
En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « UEFA Champions League », dont le code est « AB123 » ;
- le type de résultat « victoire (résultat d’un match) » a pour code « 456AB » ;
- le type de résultat « match nul (résultat d’un match) » a pour code « 123CD ».
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
160/202

ROPTNBVL
C
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
1.65
456AB
NUL
3.40
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
456AB
DORTMUND
1.70
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
OLYMPIAKOS
1.95
0.50
47.33
3.00
44.33
Exemple 4b : grille mutuelle / pari combiné simple.
Le joueur remplit une grille mutuelle le 4 décembre 2011 à 10h17 (UTC) sur les 5 rencontres « Chelsea – Valence CF », « Dortmund – Marseille », « Olympiakos – Arsenal », « Lorient – Lyon » et « Novare – Naples ».
161/202

Les pronostics de résultats portent sur le vainqueur de chaque rencontre et la possibilité d’égalité. Les pronostics sont non combinables (cas des lignes offrant des combinaisons doubles ou triples).
Dans un premier temps, le joueur associe un unique pronostic de résultat à chaque rencontre. Le pari combiné résultant est donc un pari combiné simple.
La rencontre « Lorient – Lyon » est une rencontre de la 17ème journée du championnat de France de Ligue 1. En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « Championnat de France de Ligue 1 », dont le code est « KYYIC ». La rencontre « Novare – Naples » est une rencontre de la 15ème journée (aller) du championnat d’Italie. En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « Championnats Européens (première ligue ou équivalent)», dont le code est « DEF12 ». La mention au championnat d’Italie apparaît uniquement dans la retranscription en clair de l’intitulé de la rencontre (remarque : avec utilisation d’un guillemet simple). En termes de codification des types de résultats :
- le type de résultat « victoire (résultat d’un match) » a pour code « 456AB » ;
- le type de résultat « match nul (résultat d’un match) » a pour code « 123CD ». La mise est effectuée à partir du compartiment solde du joueur.
La mise par pari est de 2 €. La mise totale est donc de 2 €, dans la mesure où un seul pari est effectué.
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
G2ZWODAQ
C
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
456AB
DORTMUND
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
162/202

1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
123CD
NUL
CHAMPIONNAT DE FRANCE LIGUE 1 – LORIENT – LYON
1234:565:43:96
ABC
KYYIC
H
111211200000
LORIENT
LYON
456AB
LORIENT
CHAMPIONNAT D’ITALIE – NOVARE – NAPLES
1234:565:43:95
ABC
DEF12
H
111211194500
NOVARE
NAPLES
456AB
NAPLES
2.00
47.33
2.00
45.33
Dans un second temps, le joueur associe plusieurs pronostics de résultats à chaque rencontre. Ces pronostics de résultats sont non combinables : le pari combiné résultant est donc un une grille mutuelle multiple.
La mise par pari est de 2 €. Le joueur effectue 3 pronostics de résultats sur la rencontre « Chelsea – Valence CF », 2 pronostics de résultats sur la rencontre « Lorient – Lyon », et 2 pronostics de résultats également sur la rencontre « Novara – Naples ».
Soit un total de 3 * 2 * 2 = 12 combinaisons.
La mise est effectuée à partir du compartiment solde du joueur. La mise totale est donc de 24 €, dans la mesure où 12 paris sont effectués.
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
163/202

AD5GVLCN
C
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
456AB
NUL
456AB
VALENCE CF
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
456AB
DORTMUND
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
NUL
CHAMPIONNAT DE FRANCE LIGUE 1 – LORIENT – LYON
1234:565:43:96
ABC
KYYIC
H
111211200000
LORIENT
LYON
456AB
LORIENT
456AB
NUL
164/202

CHAMPIONNAT D’ITALIE – NOVARE – NAPLES
1234:565:43:95
ABC
DEF12
H
111211194500
NOVARE
NAPLES
456AB
NOVARE
456AB
NAPLES
2.00
47.33
24.00
23.33
Exemple 5 : pari système (simple).
Le joueur effectue un pari système le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ».
Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
La mise est effectuée à partir du compartiment solde du joueur.
3 Le joueur sélectionne le pari système 2/3, qui correspond à (
), soit 3 combinaisons. La mise élémentaire est de 1.50 €. 2 La mise totale est donc de 4.50 €.
L’espérance de gain maximale vaut (1.65*1.70 + 1.65*1.95 + 1.70*1.95) * 1.50 = 14.01 €.
En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « UEFA Champions League », dont le code est « AB123 » ;
- le type de résultat « victoire (résultat d’un match) » a pour code « 456AB » ;
- le type de résultat « match nul (résultat d’un match) » a pour code « 123CD ».
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
9M4053QV
XY
2
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
165/202

H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
1.65
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
456AB
DORTMUND
1.70
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
OLYMPIAKOS
1.95
1.50
47.33
4.50
42.83
Exemple 6 : pari système complexe TRIXIE.
Le joueur effectue un pari système le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ».
Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
La mise est effectuée à partir du compartiment solde du joueur.
3 Le joueur sélectionne le pari système TRIXIE, qui correspond à 1 + (
) soit 4 combinaisons (1 pari combiné + 3 paris 2 système 2/3). La mise élémentaire est de 1.50 €. La mise totale est donc de 6 €.
L’espérance de gain maximale vaut (1.65*1.70*1.95 + 1.65*1.70 + 1.65*1.95 + 1.70*1.95) * 1.50 = 22.21 €.
En termes de codification :
- le sport (Sport) est donc le football, qui correspond au code « ABC » ;
- l’évènement (Evnt) est « UEFA Champions League », dont le code est « AB123 » ;
- le type de résultat « victoire (résultat d’un match) » a pour code « 456AB » ;
- le type de résultat « match nul (résultat d’un match) » a pour code « 123CD ».
166/202

En utilisant la formule « TRIXIE » :
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
CFUDIP4B
TRIXIE
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
1.65
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
456AB
DORTMUND
1.70
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
OLYMPIAKOS
1.95
1.50
47.33
6.00
41.33
Exemple 7 : pari système complexe YANKEE.
167/202

4 4 Le joueur sélectionne le pari système YANKEE, qui correspond à 1 + (
) + (
) soit 11 combinaisons (1 pari combiné + 4 3 2 paris système 3/4 + 6 paris système 2/4). La mise élémentaire est de 1.50 €. La mise totale est donc de 16.50 €.
La mise est effectuée à partir du compartiment solde du joueur.
L’espérance de gain maximale vaut (1.65*1.70*1.95*1.26 + 1.65*1.70*1.95 + 1.65*1.70*1.26 + 1.65*1.95*1.26 + 1.70*1.95*1.26 + 1.65*1.70 + 1.65*1.95+ 1.65*1.26 + 1.70*1.95 + 1.70*1.26 + 1.95*1.26) * 1.50 = 60.21 €.
Exemple 8 : pari spécial.
Le joueur effectue un pari spécial le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea -- Valence CF ». Le pari porte sur le résultat du match et sur la première équipe à marquer, qui sont deux pronostics dépendants. La cote de ce pari est 7.20. La mise du joueur est 1.50 €. La mise est effectuée à partir du compartiment solde du joueur.
L’espérance de gain calculée est : 1.50*7.20 = 10.80 €.
Il s’agit d’un match de la 6ème journée du groupe E de la Ligue des champions 2011-2012. Il est programmé le 6 décembre à 20h45 en France, soit 19h45 (UTC). L’ensemble de ces informations sont affichées au joueur lors de la prise du pari.
Le pronostic comprend un pronostic composé de deux choix.
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
8ACEB0TV
S
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
123CD
Vainqueur : Chelsea
345FG
Première équipe à marquer Valence
7.20
1.50
47.33
1.50
45.83
Exemple 9 : pari « gratuit ».
Cet exemple fait écho à l’exemple n°1 de la présente partie.
168/202

Le joueur effectue un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea – Valence CF ». Le pari porte sur le résultat du match, et le joueur pronostique un match nul. La cote de ce pari est de 3.40. Le joueur effectue un pari « gratuit » à partir d’un bonus attribué par l’opérateur.
Pour ces paris « gratuits », l’opérateur choisit de retirer la mise du gain éventuel, l’espérance de gain calculée est : 1.50*(3.40-1) = 3.60 €.
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
8ACEB0TV
S
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
123CD
NUL
3.40
1.50
47.33
1.50
45.83
pari gratuit
Exemple 10 : pari simple avec jackpot.
Le joueur effectue un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea -- Valence CF ». Le pari porte sur le résultat du match, et le joueur pronostique un match nul. La cote de ce pari est 3.40. La mise du joueur est 1.50 €. Le solde du joueur se porte à 47.33 €. La mise est effectuée à partir du compartiment solde du joueur. Lors de la prise de jeu le joueur sélectionne l’option jackpot qui permet d’éventuellement multiplier son gain par un facteur pouvant aller jusqu’à 10. Ce jeu complémentaire représente 10 % de sa mise.
L’espérance de gain calculée est : (1.50 * 0.90)*3.40*10 = 45.90 €.
Deux évènements sont envoyés au coffre, l’un pour la mise du joueur et l’autre pour la prise de jeu jackpot. Le champ
permet de renseigner le coefficient multiplicateur du gain éventuel.
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
8ACEB0TV
HTQS672BI
169/202

S
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
123CD
NUL
3.40
1.35
47.33
1.50
45.98
4512
111204101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
HYT42CDFH
HTQS672BI
S
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
123CD
NUL
3.40
0.15
45.98
0.15
45.83
Jackpot x10
IV.4.2 Gain sur un pari – PASPGAIN
Exemple 1 : gain sur pari simple.
Cet exemple fait écho à l’exemple n°1 de la partie IV.4.1.
170/202

Le joueur a effectué un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea – Valence CF ». Le pari a porté sur le résultat du match, et le joueur a pronostiqué un match nul.
Dans cet exemple, on suppose le pari gagnant.
La cote de ce pari est 3.40. La mise du joueur est 1.50 €. Le gain est : 1.50*3.40 = 5.10 €.
La rencontre s’est achevée le 06/12/2011 à 21h55 (UTC) et le gain correspondant a été généré par la plate-forme le même jour à 22h (UTC), il reprend le code Tech du coupon du pari :
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
8ACEB0TV
111204101703
111206215500
45.83
5.10
50.93
Exemple 2 : cashout sur pari simple.
Cet exemple fait écho à l’exemple n°1 de la partie IV.4.1.
Le joueur a effectué un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea – Valence CF ». Le pari a porté sur le résultat du match, et le joueur a pronostiqué un match nul.
Le 5 décembre 2011 à 12h42 (UTC) le joueur choisit de faire un cashout sur la totalité de la mise de son pari, l’opérateur le rachète à une cote de 1.62. Le gain du joueur est : 1.5*1.62 = 2.43
Comme le gain a été généré par le joueur la balise n’est pas inclue.
4512
111205124254
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
8ACEB0TV
111204101703
111205124254
1.5
1.62
45.83
2.43
48.26
Exemple 3 : pari combiné (simple).
171/202

Cet exemple fait écho à l’exemple n°3 de la partie IV.4.1.
Le joueur a effectué un pari combiné le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ». Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
La mise élémentaire affectée à chaque pronostic de résultat est de 1.50 €. Les cotes sont respectivement 1.65, 1.70 et 1.95. La cote totale est le produit de ces cotes, soit : 1.65*1.70*1.95 = 5.47.
Dans cet exemple, les 3 pronostics sont bons : on suppose donc le pari gagnant.
Le gain est donc : (1.65*1.70*1.95) * 1.50 = 8.20 €.
L’opérateur abonde le gain de 5.00 €. Le gain total se porte donc à 13.20 €.
Le gain a été généré par la plate-forme le 06/12/2011 à 22h (UTC) :
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
ABLSTJEK
111206220000
111206215500
45.83
8.20
59.03
5.00
Exemple 4 : pari combiné multiple.
Cet exemple fait écho à l’exemple n°4a de la partie IV.4.1.
Le joueur a effectué un pari combiné le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ». Les pronostics de résultats ont porté sur le vainqueur de chaque rencontre et un pronostic de résultat supplémentaire a concerné une égalité sur la rencontre « Chelsea – Valence CF ». Ce pari combiné est donc un pari combiné multiple.
La mise élémentaire affectée à chaque pari combiné est de 1.50 €. La mise totale est donc de 3.00 €, dans la mesure où il s’agit d’un combiné multiple qui correspond à deux paris :
pour le premier pari, les cotes sont respectivement de 1.65, 1.70 et 1.95. La cote totale du pari combiné correspondant est le produit de ces cotes, soit : 1.65*1.70*1.95 ;
pour le second pari, les cotes sont respectivement de 3.40, 1.70 et 1.95. La cote totale du pari combiné correspondant est le produit de ces cotes, soit : 3.40*1.70*1.95.
Dans cet exemple, on suppose que la rencontre « Chelsea – Valence CF » s’est achevée par un match nul. Le gain est donc calculé de la façon suivante : (3.40*1.70*1.95) * 1.50 = 16.91 €
Le gain a été généré par la plate-forme le 06/12/2011 à 22h (UTC).
172/202

4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
ROPTNBVL
111206220000
111206215500
45.83
16.91
62.74
Exemple 5 : grille / pari combiné simple.
Cet exemple fait écho au second scénario de l’exemple n°4b de la partie IV.4.1.
Le joueur a effectué un pari combiné le 4 décembre 2011 à 10h17 (UTC) sur les 5 rencontres « Chelsea – Valence CF », « Dortmund – Marseille », « Olympiakos – Arsenal », « Lorient – Lyon » et « Novare – Naples ».
Les pronostics peuvent porter sur le vainqueur de chaque rencontre ou la possibilité d’égalité, avec la possibilité de pronostics non combinables (cas des lignes offrant des combinaisons doubles ou triples).
Le joueur a associé plusieurs pronostics de résultats à chaque rencontre. Ces pronostics de résultats sont non combinables : le pari combiné résultant est donc un pari combiné multiple.
La mise par pari est de 2 €. Le joueur effectue 3 pronostics de résultats sur la rencontre « Chelsea – Valence CF », 2 pronostics de résultats sur la rencontre « Lorient – Lyon », et 2 pronostics de résultats également sur la rencontre « Novara – Naples ».
Soit un total de 3 * 2 * 2 = 12 combinaisons.
Seule une combinaison est, au mieux, gagnante.
Dans cet exemple, les paris gagnants sont :
« Chelsea – Valence CF » : « Chelsea » gagnant ;
« Dortmund – Marseille » : « Dortmund » gagnant ;
« Olympiakos – Arsenal » : match nul ;
« Lorient – Lyon » : match nul ;
« Novare – Naples » : « Naples » gagnant. Le gain correspond au gain théorique du pari, soit 250 euros. Le gain a été généré par la plate-forme le 06/12/2011 à 22h (UTC).
4512 111206220000 1903810 9G3912JF 9853E488E24120BC18F9A650AED9CEE0FF72B09E 0-sys 192.168.1.1 1
G2ZWODAQ 111204101700 111206215500 45.33
173/202

250.00 295.33
Exemple 6 : pari système (simple).
Cet exemple fait écho au second scénario de l’exemple n°5 de la partie IV.4.1.
Le joueur a effectué un pari système le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ».
Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
3 Le joueur a sélectionné le pari système 2/3, qui correspond à (
), soit 3 combinaisons. La mise élémentaire est de 1.50 €. 2
L’espérance de gain maximale vaut (1.65*1.70 + 1.65*1.95 * 1.70*1.95) * 1.50 = 14.01 €.
On suppose que seuls les pronostics sur les rencontres « Chelsea – Valence CF » et « Dortmund – Marseille » sont bons.
Le gain est celui du pari combiné sur ces deux rencontres, soit (1.65*1.70) * 1.50 = 4.20 €.
Le gain a été généré par la plate-forme le 06/12/2011 à 22h (UTC).
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
9M4053QV
111204101700
111206215500
45.83
4.20
50.03
Exemple 7 : pari système complexe TRIXIE.
Cet exemple fait écho au second scénario de l’exemple n°6 de la partie IV.4.1.
Le joueur a effectué un pari système le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ».
Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
3 Le joueur sélectionne le pari système TRIXIE, qui correspond à 1 + (
) soit 4 combinaisons (1 pari combiné + 3 paris 2 système 2/3). La mise élémentaire est de 1.50 €.
L’espérance de gain maximale vaut (1.65*1.70*1.95 + 1.65*1.70 + 1.65*1.95 * 1.70*1.95) * 1.50 = 22.21 €.
On suppose que seuls les pronostics sur les rencontres « Chelsea – Valence CF » et « Dortmund – Marseille » sont bons.
Le gain est celui du pari combiné sur ces deux rencontres, soit (1.65*1.70) * 1.50 = 4.20 € ;
174/202

4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
CFUDIP4B
111204101700
111206215500
45.83
4.20
50.03
Exemple 8 : gain sur pari « gratuit ».
Cet exemple fait écho à l’exemple n°9 de la partie IV.4.1 et l’exemple n°2 de la partie IV.4.3
Le joueur a effectué une mise de 1.50 € à une cote de 3.4. L’opérateur retire la mise du gain du joueur, le gain du joueur est donc mise*(cote-1) soit 3.6 €
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
CFUDIP4B
111204101700
111206215500
45.83
3.6
49.43
Pari gratuit
Exemple 9 : gain sur pari simple avec Jackpot.
Cet exemple fait écho à l’exemple n°10 de la partie IV.4.1.
Le joueur a effectué un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea – Valence CF ». Le pari a porté sur le résultat du match, et le joueur a pronostiqué un match nul. 10 % de la mise du joueur correspondait au jeu complémentaire Jackpot.
Dans cet exemple, on suppose le pari gagnant, avec un facteur multiplicatif lié au jackpot de 10.
La cote de ce pari est 3.40. La mise du joueur est 1.50 €, dont 1.35€ attribués à la mise principale. Le gain principal est : 1.35*3.40 = 4.59 €.
175/202

Le gain a été généré par la plate-forme le 06/12/2011 à 22h (UTC), il reprend le code Tech du coupon du pari, un second évènement sera généré avec le gain correspondant au jackpot.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
8ACEB0TV
111204101700
111206215500
45.83
4.59
50.42
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
HYT42CDFH
111204101700
111206215500
50.93
41.31
92.24
IV.4.3 Annulation d’un pari – PASPANNUL
Exemple 1 : Annulation d’un pari par l’opérateur Cet exemple fait écho à l’exemple n°1 de la partie IV.4.1. Le joueur effectue un pari simple le 4 décembre 2011 à 10h17 (UTC) sur le match « Chelsea – Valence CF ». La mise du joueur est 1.50 €.
L’équipe de Chelsea déclare forfait avant le début du match, les paris sur la rencontre sont donc annulés par l’opérateur. L’opérateur rembourse le joueur et envoie au coffre un évènement d’annulation avec la balise .
4512
111206173200
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
8ACEB0TV
111204101703
RencontreAnnulee
45.83
1.50
47.33
176/202

Exemple 2 : Modification d’un pari par le joueur Cet exemple fait écho à l’exemple n°3 de la partie IV.4.1.
Le joueur a effectué un pari combiné le 4 décembre 2011 à 10h17 (UTC) sur les 3 rencontres « Chelsea – Valence CF », « Dortmund – Marseille » et « Olympiakos – Arsenal ». Les pronostics de résultats portent sur le vainqueur de chaque rencontre.
Le joueur souhaite modifier son pronostic sur la rencontre « Dortmund – Marseille », il préfère parier sur l’équipe de Marseille plutôt que celle de Dortmund.
Pour effectuer la modification du pari dans le coffre, l’opérateur envoie un coffre un évènement d’annulation pour annuler la mise initiale et transmet un évènement PASPMISE avec le nouveau pari du joueur. Ces évènements sont transmis, au même instant, sans la balise car cette annulation intervient à l’initiative du joueur.
4512
111206183225
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638605
192.0.2.42
1
ABLSTJEK
111204101703
PariModifie
45.83
1.50
47.33
Modification de pari – Tech pari modifié RTJ541R42
4512
111206183225
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638605
192.0.2.42
1
RTJ541R42
C
UEFA CHAMPIONS LEAGUE – CHELSEA – VALENCE CF
1234:565:43:99
ABC
AB123
H
111206194500
CHELSEA
VALENCE CF
456AB
CHELSEA
1.65
UEFA CHAMPIONS LEAGUE – DORTMUND – MARSEILLE
1234:565:43:98
ABC
AB123
H
111206194500
DORTMUND
MARSEILLE
177/202

456AB
MARSEILLE
1.70
UEFA CHAMPIONS LEAGUE – OLYMPIAKOS – ARSENAL
1234:565:43:97
ABC
AB123
H
111206194500
OLYMPIAKOS
ARSENAL
456AB
OLYMPIAKOS
1.95
0.50
47.33
1.50
45.83
Modification de pari – Tech pari initial ABLSTJEK
IV.4.4 Cas particulier de la « Fantasy league »
Exemple 1 L’exemple suivant décrit le cas le plus simple d’une « Fantasy League » où le joueur s’inscrit, effectue sa sélection et obtient un gain. Seuls les trois évènements FAINSCRIT, FAJEU et FABILAN sont nécessaires. Pour plus de simplicité, cet exemple considère que le joueur n’effectue aucune autre opération de jeu afin d’avoir une continuité du solde et de la numérotation des évènements.
0099
1
160101100000
0000001337
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
Tournoi « Fantasy League » – Ligue des héros 2016 – Weekend
#1
ABC
DEFGH
IJK
LMNOP
2/0/0
1000.00
100.00
900.00
0099
1
160101101500
0000001338
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
178/202

ticket-0
FAN16-24E876
1
Coefficients standards
FDEE0DB0-DE6C-11E5-9F79-8CB05671DD9F
160101101500
Bruce Lawton
Capitaine
Clark Wayne
Défenseur
Barry Kent
Attaquant
Harley Allen
Attaquant remplaçant
Floyd Quinzel
Defenseur remplaçant
0099
1
160102150000
0000001339
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.168.1.1
0-sys
ticket-0
FAN16-24E876
42
215
900.00
500.00
1400.00
Exemple 2 L’exemple suivant montre comment la nouvelle composition d’un joueur, qui annule et remplace la précédente, doit être enregistrée dans le coffre.
179/202

0099
1
160101101500
0000001338
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
1
Coefficients standards
FDEE0DB0-DE6C-11E5-9F79-8CB05671DD9F
160101101500
Bruce Lawton
Capitaine
Clark Wayne
Défenseur
Barry Kent
Attaquant
Harley Allen
Attaquant remplaçant
Floyd Quinzel
Defenseur remplaçant
0099
1
160101150000
0000001339
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
1
Coefficients standards
FDEE0DB0-DE6C-11E5-9F79-8CB05671DD9F
160101150000
Douglas Etchinson
Capitaine
Clark Wayne
Défenseur
Barry Kent
Attaquant
Harley Allen
Attaquant remplaçant
180/202

Floyd Quinzel
Défenseur remplaçant
Exemple 3
L’exemple suivant montre le déroulé d’une « Fantasy League » permettant des achats et gains intermédiaires. Pour plus de simplicité, cet exemple considère que le joueur n’effectue aucune autre opération de jeu afin d’avoir une continuité du solde et de la numérotation des évènements.
0099
1
160101100000
0000001337
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
Tournoi « Fantasy League » – Ligue des héros 2016 – Weekend
#1
ABC
DEFGH
IJK
LMNOP
100/0/50/AG
1000.00
100.00
900.00
0099
1
160101100100
0000001338
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
Bonus score X2 pour le capitaine
900.00
20.00
880.00
0099
1
160101101500
0000001339
181/202

demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
1
Coefficients standards
FDEE0DB0-DE6C-11E5-9F79-8CB05671DD9F
160101101500
Bruce Lawton
Capitaine (Score X2)
Clark Wayne
Défenseur
Barry Kent
Attaquant
Harley Allen
Attaquant remplaçant
Floyd Quinzel
Defenseur remplaçant
0099
1
160101233000
0000001340
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.168.1.1
0-sys
ticket-0
FAN16-24E876
Bonus « 1er du classement »
880.00
100.00
980.00
0099
1
160102150000
0000001341
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.168.1.1
0-sys
ticket-0
FAN16-24E876
1
415
980.00
500.00
1480.00
182/202

Exemple 4 L’exemple suivant montre le processus d’annulation d’une inscription. Pour plus de simplicité, cet exemple considère que le joueur n’effectue aucune autre opération de jeu afin d’avoir une continuité du solde et de la numérotation des évènements.
0099
1
160101100000
0000001337
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
Tournoi « Fantasy League » – Ligue des héros 2016 – Weekend
#1
ABC
DEFGH
IJK
LMNOP
2/0/0
1000.00
100.00
900.00
0099
1
160101190000
0000001338
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
FAN16-24E876
RencontreAnnulee
900.00
100.00
1000.00
183/202

IV.5 Exemples relatifs aux évènements des paris hippiques
IV.5.1 Mise sur un pari – PAHIMISE
Exemple 1 : pari unique Le joueur effectue un pari sur le tiercé correspondant à la 3ème course de Vincennes le samedi 31 octobre 2019 (réunion 1, course 3). Son pronostic : le 5, le 10 et le 2. L’opérateur augmente la mise du joueur par un abondement du même montant.
4512
191030102530
1903700
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
10206000
192.0.2.42
1
12335652233
191031120000
Vincennes
France
1
Prix Constant Hervieu
3
Tiercé de la R1C3
tiercé
5
10
2
10
1
27.33
5
22.33
5
Exemple 2 : pari tous les ordres Le joueur effectue un pari sur le tiercé de la 3ème course de Vincennes le samedi 31 octobre 2019 (réunion 1, course 3). Il choisit les chevaux 5, 10 et 2 et il sélectionne l’option « tous les ordres » afin de prendre tous les ordres possibles en compte. Son pari est donc composé de 6 paris élémentaires avec les ordres suivants :
- 5, 10 et 2 ;
- 5, 2 et 10 ;
- 10, 5 et 2 ;
- 10, 2 et 5 ;
- 2, 5 et 10 ;
- 2, 10 et 5.
4512
191030102530
1903700
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
10206000
192.0.2.42
1
12335652233
184/202

191031120000
Vincennes
France
1
Prix Constant Hervieu
3
Tiercé de la R1C3
tiercé
5
10
2
1
6
27.33
6
21.33
5
Exemple 3 : pari combiné Le joueur effectue un pari sur le tiercé de la 3ème course de Vincennes le samedi 31 octobre 2019 (réunion 1, course 3). Il choisit les chevaux 5 et 10 en base et les chevaux 4, 7 et 2 en chevaux associés. Son pari est donc composé de 3 paris élémentaires avec les combinaisons suivantes :
- 5, 10 et 4 ;
- 5, 10 et 7 ;
- 5, 10 et 2.
4512
191030102530
1903700
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
10206000
192.0.2.42
1
12335652233
191031120000
Vincennes
France
1
Prix Constant Hervieu
3
tiercé 31/10/2019
tiercé
5
10
4
7
2
2
3
27.33
6
21.33
5
185/202

Exemple 4 : pari unique avec jackpot Le joueur effectue un pari sur le tiercé correspondant à la 3ème course de Vincennes le samedi 31 octobre 2019 (réunion 1, course 3) pour une mise totale de 5 €. Son pronostic : le 5, le 10 et le 2. Le joueur sélectionne le jeu jackpot qui permet de multiplier son gain. Ce jeu complémentaire correspond à 10 % de sa mise soit à 5€. Le champ permet de renseigner le coefficient multiplicateur du gain éventuel.
4512
191030102530
1903700
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
10206000
192.0.2.42
1
12335652233
7634425893
191031120000
Vincennes
France
1
Prix Constant Hervieu
3
tiercé 31/10/2019
tiercé
5
10
2
4.5
1
27.33
4.5
22.83
4512
191030102530
1903700
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
10206000
192.0.2.42
1
457269258921
7634425893
191031120000
Vincennes
France
1
Prix Constant Hervieu
3
tiercé 31/10/2019
tiercé
5
10
2
0.5
1
27.83
186/202

0.50
22.33
Jackpot x5
Exemple 5 : pari portant sur plusieurs courses
Le joueur effectue un pari spécial portant sur 3 courses différentes le samedi 31 octobre 2020. Son pronostic : le 5 gagne la première course, le 1 la seconde et le 9 la troisième. L’opérateur augmente la mise du joueur par un abondement du même montant.
4512
201030102530
1903700
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
10206000
192.0.2.42
1
12335615971
201031120000
Vincennes
France
1
Prix Constant Hervieu
3
SG R1C3 31/10/2019
Simple Gagnant
5
1
1
201031123000
Vincennes
France
1
Prix Laurent Sénéchal
4
SG R1C4 31/10/2019
SimpleGagnant
1
1
1
201031130000
Vincennes
France
1
Prix Emmanuelle Mercier
5
SG R1C5 31/10/2020
SimpleGagnant
9
1
1
27.33
187/202

3
24.33
IV.5.2 Gain sur un pari – PAHIGAIN
Exemple 1 gain simple Cet exemple fait écho à l’exemple 1 de la partie IV.5.1.
Le joueur gagne 17.28 €.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
12335652233
091030102530
111206215123
45.83
17.28
63.11
Exemple 2 gain avec jackpot Cet exemple fait écho à l’exemple 2 de la partie IV.5.1.
Le joueur gagne 17.28 € et son gain est multiplié par 5.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
12335652233
091030102530
111206215123
45.83
17.28
63.11
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
457269258921
188/202

091030102530
111206215123
63.11
69.12
132.23
IV.5.3 Annulation d’un pari – PAHIANNUL
Cet exemple fait écho à l’exemple de la partie IV.5.1.
La course est annulée, l’opérateur rembourse les gains du joueur.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
12335652233
091030102530
CourseAnnulee
45.83
5
55.83
189/202

IV.6 Exemples relatifs aux évènements du poker
IV.6.1 Inscription d’un participant à un jeu de cercle – POINSCRIT
Le joueur s’inscrit à un tournoi pour le jour même en utilisant le solde de son compte.
0099
1
160101000000
0000001337
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
NPT16
National Poker Tour 01 janvier 2016
T
1000.00
100.00
900.00
IV.6.2 Déroulement d’une partie lors d’un jeu de cercle – POJEU
Exemple d’une partie de poker enregistrée à l’aide d’un évènement POJEU.
0099
1
160101001000
0000001360
WW-94703142
1
0100
999-test-999
FR
2001:db8::1
7
inscript-0
-0.04
0.04
1.52
1.48
0100
000-test-001
2001:db8::2
8
inscript-1
-0.02
0.02
3.55
3.53
0100
190/202

000-test-002
2001:db8::3
10
inscript-2
-0.04
0.04
1.90
1.86
Hyper Poker (IT)
HP-0013232002234234
IT
2001:db8::4
2
inscript-3
-0.05
2.41
2.41
2.36
0.12
0100
123-test-456
2001:db8::5
3
inscript-4
-0.05
2.41
6.18
6.13
0.12
0100
325-test-667
2001:db8::6
5
inscript-5
-0.04
0.04
1.72
1.68
THNL
Texas Hold’Em No Limit (0.02-0.04)
160101000001
8
0.02
10
0.04
0.06
191/202

160101000001
2
32
2
26
3
33
3
38
5
14
5
23
7
10
7
19
8
16
8
13
10
5
10
8
2
0.04
3
0.04
5
0.04
7
0.04
8
10
192/202

0.16
160101000010
39
43
25
10
2
0.16
3
0.16
5
7
10
0.32
160101000020
44
2
0.28
3
0.28
0.56
160101000020
29
2
0.56
3
2.78
2
1.37
3.86
193/202

160101000030
2
32
2
26
3
33
3
38
IV.6.3 Bilan financier d’un jeu de cercle – POBILAN
Le joueur a participé à un tournoi et a remporté des gains à l’issue de celui-ci. La sortie d’un joueur d’une partie en cash- game utilise le même évènement pour re-créditer son compte.
0099
1
160101000000
0000001341
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
NPT16
2
980.00
500.00
1480.00
IV.6.4 Achat en cours de jeu – POACHAT
Le joueur réalise un achat en cours de jeu, dans cet exemple l’achat d’une cave, à l’aide du solde de son compte.
0099
1
160101000000
0000001338
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
NPT16
Achat de cave (100 jetons)
900.00
20.00
880.00
194/202

IV.6.5 Gain en cours de jeu – POGAIN
Le joueur réalise, en cours de jeu, un gain instantanément crédité sur son compte, dans cet exemple l’accomplissement d’une « bounty » sur un autre joueur.
0099
1
160101000000
0000001340
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
NPT16
Bonus bounty pour l’élimination de arjel-demo02.

880.00
100.00
980.00
IV.6.6 Annulation d’une participation – POANNUL
Le joueur s’est inscrit à un tournoi qui a été annulé, son inscription lui est remboursée.
0099
1
160101000000
0000001361
demo01
A94A8FE5CCB19BA61C4C0873D391E987982FBBD3
192.2.0.42
demo-session
ticket-0
NPT16
NombreJoueurs
900.00
100.00
1000.00
195/202

IV.7 Exemples relatifs aux évènements des jeux de loterie et instantanés
IV.7.1 Mise sur un jeu de tirage – LOTIMISE
Exemple 1 Bingo
Le joueur effectue une prise de jeu le 4 janvier 2020 à 10h17 (UTC) sur un bingo « spécial hiver ». Il choisit l’option « Joker ».
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
GTRH42REY
Special hiver
Bingo
200104102000
123456
1
joker
47.33
1.00
46.33
Exemple 2 Loterie
Le joueur effectue une prise de jeu le 4 janvier 2020 à 10h17 (UTC) sur un jeu de loterie. Le joueur sélectionne 2 grilles et choisit l’option « Joker + » et la sélection aléatoire des numéros.
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
GTRH42REY
loterie tirage vendredi
loterie 2020
200108102000
7892541
2
joker +
196/202

47.33
4
43.33
Exemple 3 Loterie avec une participation à un jackpot
Le joueur effectue une prise de jeu le 4 janvier 2020 à 10h17 (UTC) sur un jeu de loterie. Le joueur sélectionne 1 grille et choisit le jeu complémentaire « Jackpot » qui correspond à 10 % de la mise du joueur.
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
GTRH42REY
TREG53ZH
loterie tirage vendredi
loterie 2020
200108102000
7892541
1
43.33
1.8
41.53
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
HYTZVYRE5
TREG53ZH
jackpot tirage vendredi
jackpot 2020
200108102000
7892541
1
41.53
0.2
41.33
IV.7.2 Gain sur un jeu de tirage – LOTIGAIN
197/202

Exemple 1 : gain Cet exemple fait écho à l’exemple n°1 de la partie IV.7.1.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
45.83
1700
1745.83
Exemple 2 : gain avec jackpot
Cet exemple fait écho à l’exemple n°3 de la partie IV.7.1.
Le joueur a obtenu un gain de 10 000 € au loto. Outre ce gain il a remporté un jackpot de 40 000 €. Les deux gains sont renseignés dans deux évènements différents, chacun relié par le code Tech à sa mise correspondante.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
45.83
10000
10045.83
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
HYTZVYRE5
200104101703
10045.83
40000
50045.83
IV.7.3 Bilan sur un jeu de tirage – LOTIBILAN
Cet exemple fait écho à l’exemple n°1 de la partie IV.7.1.
198/202

4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
IV.7.4 Annulation sur un jeu de tirage – LOTIANNUL
Cet exemple fait écho à l’exemple n°1 de la partie IV.7.1.
Le tirage du Bingo a été annulé faute d’un nombre suffisant de joueur. L’opérateur envoie un évènement d’annulation au coffre.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
Tirage
45.83
1.00
46.83
IV.7.5 Mise sur un jeu instantané– LOJIMISE Exemple 1 : Prise de jeu
Le joueur effectue un jeu instantané de type action « spécial hiver ».
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
GTRH42REY
spécial hiver
hiver
47.33
1.00
46.33
Exemple 2 : Prise de jeu avec un jackpot
199/202

Le joueur effectue un jeu instantané de type action « spécial hiver » avec le jeu complémentaire « Jackpot ». 10 % de la mise du joueur est affecté au jeu complémentaire.
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
GTRH42REY
KUS382FV6
spécial hiver
hiver
47.33
0.90
46.43
4512
200104101703
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
638604
192.0.2.42
1
JOMTONU45
KUS382FV6
Jackpot
hiver
46.43
0.10
46.33
IV.7.6 Gain sur un jeu instantané– LOJIGAIN
Exemple 1 gain sans jackpot
Cet exemple fait écho à l’exemple n°1 de la partie IV.7.5.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
45.83
100
145.83
200/202

Exemple 2 gain avec jackpot Cet exemple fait écho à l’exemple n°2 de la partie IV.7.5.
Le joueur a obtenu un gain de 100 € à un jeu instantané. Outre ce gain il a remporté un jackpot de 500 €.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
45.83
100
145.83
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
JOMTONU45
200104101703
145.83
500
645.83
IV.7.7 Bilan sur un jeu instantané– LOJIBILAN
Cet exemple fait écho à l’exemple n°1 de la partie IV.7.5.
4512
111206220000
1903810
9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
0
IV.7.8 Annulation sur un jeu instantané– LOJIANNUL
Cet exemple fait écho à l’exemple n°1 de la partie IV.7.8.
4512
111206220000
1903810
201/202

9G3912JF
9853E488E24120BC18F9A650AED9CEE0FF72B09E
0-sys
192.168.1.1
1
GTRH42REY
200104101703
Jeu
45.83
1.00
46.83
202/202