Opérations et conformité → AML Politique et contrôle des transactions

Politique AML et contrôle des transactions

1) Objectif et domaine d'action

L'objectif de la politique AML est d'empêcher l'utilisation de la plate-forme pour blanchir des fonds et financer le terrorisme en minimisant les faux positifs et la charge opérationnelle. La politique s'applique à tout le cycle de vie du joueur : inscription → dépôts → jeux/transferts → retraits ; ainsi que sur les affiliés, les fournisseurs et les partenaires de paiement.

2) Principes (risk-based & evidence-by-design)

1. Approche fondée sur les risques (RBA) : les contrôles et les seuils dépendent du profil de risque (pays, méthode de paiement, comportement, montants).
2. Layered Controls : combinaison de CUS/Sanctions/RRE, d'analyse comportementale et d'enquêtes manuelles.
3. Evidence-by-Design : chaque solution a des artefacts : sources de données, captures d'écran, logs, rapports exportés.
4. Privacy-first : minimisation du PDn, masquage, accès par rôle, politique de rétention contrôlée.
5. Explainability : les règles et les modèles sont interprétables ; pour ML - fiches/importance/exemple de cas.
6. Continuous Improvement : Personnalisation des seuils, rétroaction de MLRO et rétro sur les mallettes.

3) Rôles et responsabilités

MLRO (Money Laundering Reporting Officer) : propriétaire du processus AML, décisions finales sur le SAR/STR, communication avec les régulateurs/banques.
AML Ops : enquêtes, communications avec les acteurs/banques, contrôle des cas SLA.
Data/BI & Risk Analytics : support des règles/modèles, surveillance de la qualité de la détection.
Paiements/Ops : respect des limites et procédures de hold/reverse, traçage des transactions.
Sécurité/DPO : protection des données, accès, incidents de confidentialité.

4) Le modèle de risque du joueur et des segments

• Géo/IP/résidence, document et méthode KYC.
• Méthodes de dépôt/retrait, multiplicité des instruments de paiement.
• Activité : montants, fréquence, vis/losanges, sessions nocturnes, corrélation avec d'autres comptes.
• Appareils/fingerprint, intersections IP/appareils/détails de paiement.

Segments : Low/Medium/High/Prohibited.
Moteur de routage : Low - vérifications simplifiées ; High - EDD/hold/restrictions.

5) KYC, sanctions et PEP

Tiered KYC : « KYC1 (identité) → KYC2 (adresse) → EDD (dop. documents/SoF) ».
Sanctions/REER : vérification lors de l'enregistrement, à des seuils significatifs de dépôts/retraits et lorsque les détails changent.
SoF/SoW : par déclenchement (tours élevés, incohérence de profil, VIP).
Rétention : conservation des documents conformément aux exigences de la juridiction ; accès par vault/contrôle d'émission.

6) Contrôle des transactions (règles et signaux)

• Velocity : épines rapides de dépôts/retraits ; une série de petits dépôts → un retrait majeur.
• Multi-instrument : beaucoup de cartes/portefeuilles différents en une courte période.
• Source/Destination mismatch : dépôt d'un outil, retrait à un autre.
• Circularité : reconstitution → taux minimaux/blanchiment de bonus → retrait.
• Split/Structuring : écraser les montants sous les seuils.
• Affiliate abuse : afflux anormal du canal + modèles types d'abus.
• Device/IP risk : changements de périphériques/proxy/ASN à haut risque.

• Une vis irréaliste sur une faible dispersion, les paris d'un « partenaire de contenu » avec des plaintes, les jeux avec un minimum de risque pour le chiffre d'affaires.

7) Controls-as-Code (fragments)

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8) Modèles et règles : Partager

Rules-first au départ (rapide, explicable) + ML pour la hiérarchisation (gradient boosting/logreg/fiches récupérables).
Champion/Challenger : comparaison des seuils actuels avec les nouveaux modèles à l'ombre.
Drift-monitoring : contrôle du cisaillement de la fiche, de la proportion de drapeaux/hold, FPR/TPR.
Explainability : SHAP/feature importance, cas de référence.

9) SOP (fragments)

SOP : Triage de déclenchement AML

1. Vérifiez la carte du joueur (géo, KYC, risque, historique).
2. Vérifier les sources de données (logs de paiement/jeux, communications par périphérique).
3. Adopter la décision « clear/ request_info/hold/EDD/SAR ».
4. Enregistrer les actions dans le système de cas et mettre à jour l'état.
5. Communication avec le joueur (modèle, délais de réponse).
6. Révision du seuil/règle (s'il y a beaucoup de FPs).

SOP : Demande EDD/SoF

1. Demande de documents (relevés/salaires/impôts).
2. Comparer les montants/fréquences/sources avec le comportement sur la plate-forme.
3. Mettre à jour le profil de risque, supprimer/confirmer les restrictions.
4. Enregistrer evidence et décision (signature MLRO).

SOP : Dépôt SAR/STR

1. Recueillir des données factuelles (temps, montants, liens, tests).
2. Vérifier les deadlines et les formats de juridiction/banque.
3. Fournir le SAR/STR, fixer l'ID/heure/canal.
4. Mettre à jour les statuts internes et les restrictions de compte.
5. Follow-up avant la fermeture/instructions du régulateur/de la banque.

10) Communications avec les joueurs et les partenaires

Ton : neutre et factuel, sans révéler les règles/modèles internes.
Échéancier : ETA clair à répondre, rappels, fixation en tiquet.
Partenaires de paiement : synchronisation hold/reverse, échange case-ID, canal AML unique.

11) Intégrations et données

Payments Gateway : statuts de transaction, méthode et détails, retours, chargeback.
Game Platform : rotation/vis/sessions/dispersion, anomalies.
Device Graph : fingerprint/communications périphériques/sessions/IP.
KYC/PEP/Santé : Présélection de fournisseurs sur les événements et les horaires.
Gestion de cas : statuts, SLA, journal des solutions, packaging SAR/STR.

12) Indicateurs de qualité (KPI/OKR)

• TPR/Recall Selon les attachés-cases confirmés, FPR (les drapeaux faux) ↓ QoQ.
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Case Priorisation Accuracy (les N % supérieurs donnent M % des découvertes).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (médiane).
• SAR/STR SLA (dépôt ≤ délais), retours/chargeback après mesures AML ↓.
• Model/Rule Drift - dans les couloirs autorisés.

• Pertes de frod/blanchiment de ↓, heures de fonctionnement/case ↓.
• Expérience de joueur : plaintes contre les processus AML, NPS sur les joueurs honnêtes.

13) Howernance et sécurité

Politiques d'accès : seuls les AML/MLRO voient des champs sensibles ; audits de lecture.
Rappel : durée de conservation des dossiers/documents ; nettoyage automatique.
Journal : toutes les actions sur les cases et les modifications de règles/modèles.
Contrôle double : les changements critiques de règles/seuils nécessitent 2 confirmations.
Tests en CI : syntaxe des règles, conflit des seuils, scénarios de régression.

14) Chèques-feuilles

• Les données des transactions/jeux/appareils ont été vérifiées.
• Méthodes de dépôt/retrait comparées.
• Les sanctions/RER/geo ont été vérifiées.
• Le type de solution correct ('clear/hold/EDD/SAR') a été sélectionné.
• Enregistré ETA et communication au joueur.

• Temps et montants complets, liens avec d'autres comptes.
• Artefacts de confirmation (contrôles/logs/extraits).
• Le format et le canal correspondent à la demande.
• Statuts internes et restrictions mises à jour.
• Contrôle des instructions ultérieures.

• Le seuil/fenêtre temporelle est justifié.
• Il y a une évaluation FP/TP, l'effet d'entreprise.
• La surveillance de la dérive et de l'autotest est configurée.
• Mise à jour du playbook du triage.
• Réalisé par la revue MLRO/Compliance.

15) Anti-modèles

Seuils universels « pour tous les pays » sans RBA.
Hold sans ETA/communication, cas « suspendus ».
Modèle ML sans explication et journal de version.
Déchargement manuel/SAR sans modèles d'évidence et contrôle des délais.
Manque de communication depozit↔vyvod, faible intégration avec les paiements.
Il n'y a pas de rétro régulier sur les faux positifs.

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

• Approuver la politique AML, les rôles (MLRO/AML Ops) et la matrice RBA.
• Exécutez le Controls-as-Code de base (velocity, src/dst mismatch, gaming pattern).
• Activer KYC tiers + sanctions/RER, créer des modèles SOP (triage/EDD/SAR).
• Entrez le stockage evidence et la stratégie de rétention.

• Connectez l'agrégateur de risque, le routage automatique des cas et les rapports SLA.
• Exécutez champion/challenger pour les seuils et l'assistant de priorité ML.
• Intégrer payments/game/device graphe dans un profil de joueur unique.
• Former les commandes, déboguer les modèles de communication, activer les tests automatiques des règles.

• Réduire le FPR ≥ 20 % sans perte de Recall ; Réduire le Time-to-Triage de ≥ 30 %.
• Atteindre SLA SAR/STR = 100 % à temps ; fermer toutes les cases « en dépôt ».
• Effectuer un audit interne de la conception et de l'efficacité des contrôles ; fixer l'OKR pour le trimestre suivant.

17) FAQ

Q : Comment équilibrer la sécurité et l'UX ?
A : Routage RBA : pour le low-risk - auto-nettoyage, pour le medium - requêtes légères, pour le high - EDD/hold. ETA et communications transparentes.

Q : Que faire des VIP et des limites élevées ?
R : EDD obligatoire, révision périodique du SoF/comportement, conclusion rigide liée (source-to-source), limites supplémentaires.

Q : Quand aller à la banque/régulateur ?
A : Pour les drapeaux rouges confirmés/suspicions selon les délais de juridiction ; après consultation du MLRO et fixation de l'evidence.