Opérations et conformité → Types de licences et exigences

Types de licences et exigences

1) Tableau des types de licences

• B2C (opérateur) : droit d'offrir des jeux aux utilisateurs finaux (casino, live, betting, poker, lotto, etc.).
• B2B (fournisseur) : droit de fournir une plateforme/contenu/services aux opérateurs (plateforme, jeux/RNG, studios en direct, paiements en tant que fournisseur technologique, hébergement).

• Casino/Slots, Live Casino, Sportsbook (fixed-odds, in-play), Poker (P2P), Bingo/Lottery, Fantasy/Skill-based.

• Propre licence (propriétaire opérateur/marque).
• White-Label (droit B2C via une licence de plateforme avec sous-licence/autorisation de marque).
• Skin/Brand Autorisation (connexion de marques supplémentaires à une licence existante).
• Modèle distribué (licence locale + infrastructure intersectorielle, miroirs/edge/localisation des données selon les normes).

2) Exigences : ce que demandent les régulateurs (cadre)

Juridique/Corporate

Bénéficiaires, structure de propriété, aucune sanction/casier judiciaire.
Présence locale (personne morale/représentant/responsable).
Contrats avec les fournisseurs (B2B), droits de contenu, hébergement/centre de données.

Finances

Capital minimum statutaire/réserves, garanties financières/garanties bancaires.
Comptes clients séparés/ségrégation de fonds, procédures anti-chargeback.
Rapports vérifiés, sources de fonds des bénéficiaires (SoF/SoW).

Technique (plateforme/infrastructure)

Architecture, logging/observabilité, redondance, DR/BCP.
Honnêteté des jeux : RNG/mathématiques, certification du contenu, contrôle des modifications de version.
Sécurité de l'information : cryptage at rest/in transit, IAM, journal d'actions admin.
Géo-restrictions/localisation des données, protection contre les bots et la fraude.

RG/KYC/AML

Âge/vérification de l'identité et de l'adresse, REER/sanctions, limites/auto-exclusion.
Surveillance des transactions et des comportements (velocity, SoF), procédures EDD.
Registres d'auto-exclusion/listes noires, formation du personnel.

Marketing/publicité/affiliations

Les disclaimeurs d'âge, l'interdiction des promesses « sans risque », la limitation des canaux/créneaux horaires.
KYB affiliations, bibliothèque créative, trace UTM/source de trafic.

Rapports et audit

Déchargement périodique/temps réel (GGR, cas RG, plaintes, AML/SAR).
Audits externes/internes : audits techniques, audits de jeux/RNG, audits de sécurité/vie privée.
Rapport d'incident (notifications SLA du régulateur/banques/joueurs).

3) Modèle de données « Registre des licences » (YAML)

yaml license_id: B2C-CASINO-<COUNTRY>-<NNN>
role: b2c      # b2c      b2b verticals: [casino, live, betting]
jurisdiction: <ISO-2>
holder: <legal_entity>
brands: [brandA, brandB]
local_presence: required  # required      optional      none valid_from: YYYY-MM-DD valid_to: YYYY-MM-DD financial_guarantee: {type: bank_guarantee, amount: <currency_amount>}
tech_requirements:
rng_cert: true siem_logs: true dr_rto: "30m"
data_localization: false rg_kyc_aml:
kyc_levels: [basic, address, edd]
self_exclusion: registry aml_ruleset: "v3. 1"
ads_affiliates:
disclaimers: [age, wagering_conditions]
restricted_channels: [tv_daytime]
reporting:
frequency: monthly formats: [csv, api]
realtime: [rg_cases]
contacts:
compliance_officer: email@domain mlro: aml@domain review_sla_days: 180 status: active

4) Cycle de vie des licences et obligations

4. 1. Demande de licence (Demande)

Pre-DD : structure, SoF/SoW, entreprise/agent local, contrats avec B2B.
Paquet technique : schéma architectural, sécurité, BCP/DR, processus de sortie/modification, loging/audit.
Contenu : RNG/mathématiques, liste des fournisseurs, intégration.
Politiques opérationnelles : RG/KYC/AML, incidents, publicité, plaintes.
Finances : capital/garantie, plan d'affaires, prévision des déclarations et des impôts.

4. 2. Phase opérationnelle (Post-grant)

Respect de la Politique/Controls-as-Code.
Rapports sur les horaires, tenue de registres (plaintes, cas AML/RG, incidents).
Accords de changement : versions, nouveaux fournisseurs, changement d'hébergement/centre de données, nouvelles méthodes de paiement.

4. 3. Renouvellement (Renewal)

Certificats de sécurité RNG mis à jour.
Audit pour la période, indicateurs RG/AML, statistiques des plaintes.
Preuve de viabilité financière/garantie.

4. 4. Modifications (Variation)

Ajout de vertical/marque, blanc-label/peau, migration de plateforme.
Avis de changement de bénéficiaires/directions.
Changements dans la politique de publicité et le réseau d'affiliation.

5) Matrice des obligations de rôle/verticale (exemple)

6) Chèque de candidature (Dossier de candidature)

Bloc d'entreprise

• Structure de propriété/bénéficiaires/SoF/SoW.
• Jurlitso/représentant local, pouvoirs des officiers.

Finances

• Rapport/plan audité.
• Garantie bancaire/assurance/dépôt.

Technique

• Architecture, observation/loging/audit, CI/CD, gestion du changement.
• BCP/DR (RTO/RPO, protocoles de test), sécurité (cryptage, IAM, secrets).
• RNG/certification du contenu, contrôle des sorties de jeux.

Opérations/stratégies

• RG/KYC/AML, plaintes, incidents/reportages, sapport/SLA.
• Publicité/affiliations : règles, modèles, bibliothèque créative.

Rapports

• Formats de déchargement, fréquences, fichiers de test, personnes de contact.

7) Contrôle en vente : Policy-/Controls-as-Code

yaml control_id: RG-LIMIT-LOSS-DAILY scope: bets trigger: loss_today > limit_loss_daily actions:
- block: further_bets
- notify: player_template_rg_limit evidence:
fields: [loss_today, limit, messages_sent, ack]
overrides:
- country: <ISO>
set: {limit_loss_daily: <amount>, cool_off_hours: <N>}
owner: rg_officer review_sla_days: 180

yaml control_id: AML-VELOCITY-01 scope: deposits trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3 OR count_unique(payment_method,1h)>=3 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- notify: mlro evidence:
store: s3://evidence/aml-velocity/{player_id}/{ts}
owner: mlro

yaml policy_id: RELEASE-GATE-COMPLIANCE require:
- country_overrides_present: true
- report_schemas_valid: true
- rg_controls_enabled: true
- ads_templates_localized: true on_fail: block_release

8) Gestion des modifications sous licence (SOP, fragments)

SOP : Ajout d'une nouvelle marque (skin)

1. Vérifier les conditions de la licence (si l'autorisation de la marque est autorisée).
2. Enregistrer la marque/le domaine/la localisation/les marques d'âge.
3. Lier les politiques et les rapports RG/KYC/AML/Ads.
4. Tester les rapports (brand-split), activer le journal.
5. Aviser le régulateur/les banques (si nécessaire), fixer evidence.

SOP : Connexion d'un nouveau fournisseur de jeux

1. Vérifier le statut/les certificats du fournisseur dans le registre.
2. Aligner le set de contenu/vertical, configurer RNG/métriques/loging.
3. Mettre à jour les rapports (ID de jeu/fournisseur).
4. Sortir la version via policy-gate, assembler evidence.

9) RACI (fonctions)

10) Calendrier d'engagement (Calendrier de conformité, exemple)

Au quotidien : RG/AML monitoring, incident reportage sur les faits.
Hebdomadaire : rapports d'intégration des fournisseurs/paiements, vérification d'alertes-conformité.
Mensuellement : décharges réglementaires (GGR/bets/cas RG), rapprochements avec DWH.
Trimestriel : scans de sécurité, rapports des fournisseurs, revues des politiques/contrôles.
Semestre/année : renouvellement des certificats RNG/IB, vérification de l'efficacité des contrôles, renouvellement des licences/autorisations.

11) Anti-modèles

« La licence est là - les processus sont plus tard » : absence de Controls-as-Code, rapports et evidence.
Deux versions de la vérité : rapports Excel ≠ logs productifs.
L'absence de brand-split dans les données, un « tas commun » de métriques.
EDD manuel sans règlement/calendrier et journal.
Publicité via des affiliations sans KYB et une bibliothèque créative.
Aucun test DR/journal de changement pour RNG/jeux.

12) Métriques de maturité

Contrôles de couverture : ≥ 95 % des points critiques (inscription/dépôt/paris/retrait/bonus).
Reporting SLA : délais de déchargement ≥ 98 %, erreurs schématiques = 0.
Evidence completeness : ≥ 98 % des cas avec des paquets corrects.
RG/AML KPIs : proportion de cas évités/escaladés, Faux Positif ↓ QoQ.
TTR audit findings : fermeture ≤ 90 jours.
Examen des politiques SLA : révisions tardives = 0.

13) 30/60/90 - plan de mise en œuvre

• Créer un registre des licences et une taxonomie des exigences par rôle/vertical.
• Soulevez l'ensemble de base Controls-as-Code (RG/AML/reporting).
• Assembler des modèles de dossier d'application (corporatif/financier/opérationnel).
• Activer la conformité release-gate dans CI.

• Connectez les vitrines de rapport et automatisez les décharges (brand-split, country-split).
• Intégrer RG/KYC/AML dans le flow de produit ; lancez evidence-by-design.
• Effectuer le premier audit technique interne et le test DR/BCP sous licence RTO/RPO.

• Couvrir avec des contrôles ≥ 95 % des points critiques, Reporting SLA ≥ 98 %.
• Formaliser le RACI et le calendrier des engagements ; Lier le KPI à l'OKR des commandes.
• Préparer le paquet pour le renouvellement/variation de licence (variations de marques/verticales).

14) FAQ

Q : Que choisir : propre licence ou blanc-label ?
R : Votre licence est supérieure à SAREH/durée, mais le contrôle et l'évaluation de l'entreprise sont plus élevés. White-label - démarrage plus rapide, moins de flexibilité/évaluation, dépendance au propriétaire de la licence.

Q : Comment minimiser les risques de refus d'une demande ?
R : Forte capacité technique (sécurité/DR/observabilité), garanties financières, SoF/SoW transparents, processus RG/AML matures et « evidence-by-design ».

Q : Comment gérer les changements de fournisseurs/contenus ?
R : Via les procédures de variation : pré-négociation, contrôle des versions des jeux/RNG, reporting et journalisation des sorties.