Comment fonctionnent les systèmes AML et KYC

1) Pourquoi AML et KYC sont nécessaires

KYC (Know Your Customer) confirme que le client est une personne réelle avec une identité et une adresse valides.

L'AML (Anti-Money Laundering) empêche le blanchiment d'argent, le financement du terrorisme et le contournement des sanctions.

Dans iGaming, c'est une condition de licence, une banque partenaire et des fournisseurs de paiement ; non-exécution = amendes, révocation de la licence et blocage des paiements.

2) Processus KYC : de l'onbording à l'admission à la caisse

Étapes KYC

1. Collecte de données : Nom, date de naissance, nationalité, adresse, document (passeport/ID), selfie/vidéo-liveness.

2. Vérification du document : MRZ/puce, anti-tampon, date d'expiration, mappage avec selfie.

3. Confirmation d'adresse (PoA) : compte de service/relevé bancaire ≤ 3-6 mois.

4. Sanctions et PEP : dépistage contre les listes de sanctions, les personnes politiquement importantes et les médias adverses.

5. Solution : pass/fail/demande de données supplémentaires ; enregistrement de la raison et des versions des politiques.

Mini-exemple de demande de vérification

json
POST /compliance/kyc/verify
{
"customerId": "c_1029",  "doc": {"type":"passport","country":"DE","number":"X1234567","expiry":"2030-04-01"},  "identity": {"firstName":"Alex","lastName":"K. ","dob":"1993-02-11"},  "address": {"line1":"Musterstr. 5","city":"Berlin","zip":"10115","country":"DE"},  "liveness": {"provider":"onfido","sessionId":"sess_9a7f"},  "consent": true
}

3) Sanctions, PEP et adverse media

Sanctions : coïncidence directe, coïncidences par alias, coïncidences secondaires (bénéficiaires).

PPE : postes actuels et anciens + membres de la famille/proches.

Adverse media : références négatives à la fraude, la corruption, la violence.

Solution : true/false/needs review avec priorité sur le type de correspondance et la fraîcheur de la source.

4) KYT pour les crypto-monnaies (Know Your Transaction)

Dépistage des adresses/transactions : mixeurs, clusters de darknet, portefeuilles de sanctions/bourse.

Trace de la source de fonds : chemin des pièces jusqu'à on-ramp/échange avec KYC.

Règles : bloc de grappes à haut risque ; l'exigence d'une adresse propre ; demande de cryptage SoF/SoW.

Exemple de résultat KYT

json
{
"address": "0x9a7f...2b1c",  "riskScore": 83,  "flags": ["mixer_proximity","sanctions_cluster_2hops"],  "recommendation": "deny_and_request_clean_address"
}

5) Scoring et niveaux de vérification (approche fondée sur les risques)

Score de risque initial (IRS) sur onbording : pays, mode de paiement, âge, RER/sanctions, appareil.

Ongoing Risk Score (ORS) dans la dynamique : volumes de dépôts/retraits, fréquence, modèles anormaux.

Niveaux :

Low - KYC de base, limites standard.
Medium - SoF/PoA supplémentaires, limites réduites.
High/EDD - package de documents avancé, examen manuel, limites réduites/pause.

6) SoF/SoW et affordability (dans le cadre de l'AML)

SoF (source de fonds) : salaire, entreprise, épargne, vente d'actifs, don/héritage, cryptage (avec une méthode nette).

SoW (source de richesse) : contexte plus général du revenu.

Affordability : correspond à l'intensité du jeu aux revenus ; en cas de non-conformité - limites/pause.

7) Surveillance des transactions (MC) et règles de comportement

Scripts types que le moteur TM attrape :

Dépôts fréquents et retraits instantanés (pass-through).
Écrasement des montants autour des seuils (structuration).
Croissance spectaculaire du tik moyen ; séances de nuit avec de grands tours.
Non-correspondance entre le titulaire et le compte.
Cryptage à partir de clusters « sales » ; beaucoup de nouvelles adresses sans histoire.

Événement pour TM

json
{
"event":"payment. deposit",  "ts":"2025-10-17T12:10:20Z",  "customerId":"c_1029",  "amount":"1000. 00",  "currency":"EUR",  "method":"card",  "country":"DE",  "device":"ios_app",  "traceId":"tr_55f",  "kvc":{"name_on_card_match":true}
}

8) Gestion des cas et enquête

Alert → Case → Decision : alert est fusionné en case ; les extraits/prufs de quai sont ajoutés ; les actions et versions des stratégies ('policyVer') sont enregistrées.

Solutions : approve/limit/request info/suspend/offboard.

Escalade : sur un officier de conformité/avocat ; le journal des actions est inchangé (WORM).

SAR/STR : rapport suspect au régulateur selon la loi locale.

9) Stockage de données, vie privée, sécurité

Isolation PII : stockage séparé et clés d'accès, minimisation des champs.

Rétention : stockage N ans (par juridiction), après - élimination sûre.

Accès : RBAC/ABAC, journal d'accès, cryptage (KMS/HSM).

Droits de la personne concernée : accès/rectification/limitation du traitement autre que la rétractation obligatoire par AML.

10) Métriques et SLO AML/KYC

KYC pass-rate / time-to-verify (p50/p95).

Alert precision/recall (qualité des règles TM).

Heure de fermeture des mallettes (MTTC), proportion des mallettes avec EDD.

Taux de SAR/STR et proportion d'incidents confirmés.

KYT coverage (quel pourcentage de cryptodéposites ont été dépistés).

Interventions liées à l'affiliation (combien de limites/pauses).

11) Modèles architecturaux de Complaens

La couche Complaens est un module distinct avec sa propre API et stockage.

Événements : 'kyc. started/passed/failed`, `aml. alert/opened/closed`, `payment. deposit/withdrawal`, `kyd. address_screened`.

Idempotence : tous les webhooks et solutions sont avec 'decisionId', la répétition du traitement ne change pas le total.

Versioner les stratégies : chaque calcul stocke 'policyVer', 'dataVer', 'modelVer' (s'il y a un ML).

12) Exemples de décisions (politiques → actions)

json
{
"decisionId":"dec_7f3",  "customerId":"c_1029",  "policy":"aml_v3. 6",  "riskScore":72,  "action":"limit_and_request_sof",  "limits":{"deposit_daily":"200. 00","withdrawal_daily":"0. 00"},  "explanation":["rapid_deposits","new_wallet","country_risk_medium"],  "ttl_days":30
}

13) Le rôle de ML/AI et les limites

Utilisation des cases : hiérarchisation des alertes, anomalie des schémas comportementaux, classement des cases.

Guardrails : explication, pas de discrimination, homme dans le circuit ; les règles ont priorité sur les modèles pour les sanctions/PEP/EDD.

14) Anti-modèles (ce qui brise la conformité)

Même ensemble de contrôles pour tous les pays/méthodes (sans approche fondée sur les risques).

Mélange OLTP de l'argent et des loges de complis dans une seule OBD.

L'absence d'idempotence sur les webhooks de caisse est une double solution.

« Boîte noire » ML sans explication ni audit.

Il n'y a pas de journal des versions des politiques et des motifs des décisions.

Il n'y a pas d'archive WORM et de contrôle d'accès aux documents.

Ignorer KYT pour la crypta et l'incohérence du nom du payeur.

15) Chèque de lancement/audit AML&KYC

Processus

Les politiques de KYC/AML/EDD/Affordability avec 'policyVer' et EOL sont décrites.
Règlement SAR/STR, escalade et interaction avec le régulateur/la banque.

Technologie

Module de complement séparé : API, vitrines, archives WORM.
Événements et webhooks idempotent ; "traceId'de bout en bout.

KYC/KYT

Les fournisseurs KYC (liveness, doc-scan) sont intégrés ; Le flux PoA est clair.
KYT est connecté pour toutes les opérations cryptées ; listes d'arrêt et « adresses propres ».

Surveillance

Règles TM et signaux ML ; dashboards SLO/qualité alert.
QA des cas : réévaluation sélective, formation de l'équipe.

La vie privée

Isolation PII, cryptage, accès par rôle, rétention, RGPD/normes locales.

16) Mémo au joueur (comment passer KYC/AML plus vite)

Préparez des photos claires des documents et un nouveau Proof of Address.

Utilisez vos propres cartes/portefeuilles ; le nom doit correspondre.

Pour les sommes importantes - gardez vos relevés et SoF à l'avance.

Pour la crypte, traduisez à partir d'une adresse propre, enregistrez Tx-hash et le rapport il-ramp/bourse.

Les systèmes AML/KYC ne sont pas une formalité, mais un circuit de travail de protection de l'opérateur et des joueurs. Il se fonde sur la vérification de l'identité et de l'adresse, les contrôles de sanctions/RER, la surveillance des transactions, le KIT pour la crypta, la gestion des cas et les rapports documentés. Techniquement, c'est un module séparé avec des événements, des solutions idempotentes, des archives WORM et une vie privée stricte. Cette approche réduit les risques réglementaires et de paiement, accélère les paiements légaux et maintient un jeu responsable.