GH GambleHub

AML pour crypto : chaînes et étiquettes

1) Pourquoi iGaming a besoin de onchain-AML

Les crypto-flux ouvrent une conversion et une vitesse élevées, mais comportent des risques de légalisation des revenus, de sanctions, de financement des actions interdites et de complicité dans le blanchiment. Onchein-AML complète KYC/KYB et fournit :
  • filtrage des adresses et des chaînes d'origine des fonds (source des fonds en ligne),
  • l'arrêt précoce des transferts à haut risque,
  • une base de données probantes pour les régulateurs/banques/fournisseurs.

2) Dictionnaire : étiquettes, clusters, chaînes

L'étiquette (label/tag) est l'attribut de l'adresse/du cluster : bourse, service, « marché de dark », « portefeuille multipoint », « pont », « mixer », « portefeuille de phishing », « sujet de sanction », etc.
Clustering - Association d'adresses appartenant à un seul sujet (heuristiques co-spend/change/temporal).
Chaîne (path/trace) - Ensemble de hops de la source à votre adresse/portefeuille indiquant les montants/parts des fonds « sales ».
KYT (Know Your Transaction) - Scoring d'une transaction/adresse/chaîne spécifique par des ensembles d'étiquettes et des caractéristiques comportementales.

3) Carte des risques par étiquette (échelle approximative)

CatégorieExemples d'étiquettesEffet sous-jacent sur le risque
Sanctions/SDN/interdictions de l'ÉtatAdresses sanctionnées, clusters associésHard-block (panne/escalade, SAR/STR)
Mixeurs/obfuscationMixers, chaines peel, pools coinjoin de mauvaise réputationHigh (hold, EDD, SoF, défaillance possible)
Marchés Dark/ransomware/piratageDarknet markets, ransomware, stolen fundsHigh (stop/escalade)
Les P2P/OTC à haut risqueSites P2P non qualifiés sans KYCMed-High (limites/hold, confirmation d'adresse)
Passerelles/passerelles anonymesPonts à risque élevé, privacy-orient. protocolesMed-High (contrôle complet, limites)
Services de jeux/jeuxÉtiquettes des opérateurs concurrents, « gambling pools »Contextual (RBA : pays/licence/SoF)
Grandes bourses/KUS-VASPTier-1 CEX, castodiansLow (avec voie propre et vérification)
💡 Important : marque ≠ sentence. La décision est prise par le moteur RBA en tenant compte du contexte (géo, montant, historique du client, réponse de voyage).

4) Modèles types de risque dans les chaînes

Peeling chain : longues conclusions linéaires en petites parties d'un grand pool « sale ».
Layering à travers les ponts et L2 : un itinéraire multiple rapide avec une tentative de casser la piste.
Rapid in-out : le dépôt → un retrait quasi instantané vers une nouvelle adresse de risque élevé.
Cluster-hopping : traversez de nombreux portefeuilles du même type sans aucun sens économique.
Mixer sandwich : entrée/sortie avec le « sandwich » des mixeurs.
Sanctions proximity : association des N-hop ≤ aux clusters de sanctions avec une part importante des fonds hérités.

5) Scoring KYT et caractéristiques (feature set)

Label risk score : poids par type d'étiquette (sanctions> mixer> high-risk P2P>...).
Proximity : distance (hop) et part de pollution (taint %) dans votre transaction.
Behavioral : durée de vie de l'adresse, fan-in/fan-out, périodicité transactionnelle, round-amounts, montants typiques.
Counterparty quality : KYC-VASR/échanges réglementés vs non identifiés.
Geo & time : régions à risque, « fenêtres temporelles » après l'incident (piratage/sanctions).
Entity graph : les liens du client avec les contreparties précédemment signalées dans votre système.

Sortie : score de risque agrégé 0-100 pour la transaction/adresse/chaîne.

6) Matrice de décision (RBA) pour l'entrée/sortie

La situationExemple de conditionsAction
Allow (Green)KYT ≤ T1, chaîne propre, KUS/adresse dans whitelistCréditer/payer, confirmations standard
Allow with limitsKYT ≤ T2, il y a de petits doutesLimite de montant/fréquence, plus de confirmations
Hold & VerifyKYT en « zone grise » ou taint %, proximitéHold, demande SoF/confirmation d'adresse, Travel Rule-Exchange
RejectSanctions/mélangeurs à haut risque/fonds volésPanne + cas de conformité, si nécessaire SAR/STR
EscalateRéessayer après l'échec, essayer de contournerEscalade des L2/L3, blocage et surveillance

7) Travel Rule + KYT : comment combiner

Faites un pré-KYT avant d'envoyer Travel Rule afin de ne pas partager de données sur des itinéraires apparemment interdits.
Si vous VASP↔VASP, enregistrez les messages IVMS101 avec le rapport KYT et le lien hash de la transaction.
Adresses non autorisées : preuve de possession (signature/micro-propriété), TCJ avant l'inscription, limites et revérification périodique du whitelist.

8) Processus : De l'alerte à la fermeture de la mallette

1. Alert KYT → auto-case dans le système.
2. Triage (L1) : affichage rapide des étiquettes/proximity, mappage avec le profil du client.
3. Enquêtes (L2) : suivi détaillé, vérification de la SoF/SoW, réponses de voyage, estimation de la « proportion de contamination ».
4. Solution : allow/partial release/hold/reject/escalate.
5. Documentation : journal de données, captures d'écran, rapports des fournisseurs (ID, timestamp, versions des étiquettes).
6. SAR/STR (si la loi l'exige).
7. Post-analyse : apprentissage des règles/modèles, mise à jour des seuils.

SLA repères : auto-triage ≤ 5-15 c p95 ; L2-review ≤ 2-4 h pour High ; mallettes normales ≤ 24 h

9) Comment réduire la fausse positive et ne pas étouffer la conversion

Normalisation contextuelle : les étiquettes « service gambling » ne sont pas égales au risque par défaut - tenez compte de la réponse licence/géo/Voyage.
Time-decay : réduire le poids des anciens événements de la chaîne (s'il n'y a pas d'incidents récents).
Whitelist adresses/échanges avec revérification périodique et seuils KYT.
Segments clients : bon profil historique → en dessous du seuil hold ; nouveau/High-risk → ci-dessus.
Feedback loop : déceler les résultats (TP/FP/FN), calibrer le scoring (courbes Brier/PR).
Communication claire : les raisons compréhensibles de hold et la liste de vérification des documents → moins de tickets et de controverses.

10) Données, vie privée et stockage

Minimisation de l'IPI : ne stocker que le nécessaire pour la LAM/déclaration ; Les étiquettes/rapports KYT sont en stockage isolé (PII Vault).
Cryptage au repos/transit, séparation des accès (RBAC, need-to-know).
Versioner les étiquettes : marquer la source et la version de la base/modèle au moment de la solution.
Retraite : selon la loi (souvent 5 ans et plus) ; auto-exportation et audit des suppressions.
DSR : processus d'accès/correction/suppression (le cas échéant).

11) Métriques et OKR

Conformité/risque

KYT hit % (par type d'étiquettes), Reject/Hold rate, SAR-conversion.
Sanctionsproximity incidents et temps de réaction.

Qualité/précision

Faux Positif %, Precision/Recall pour les cas à risque élevé, Time-to-Decision p95.

Business/UX

Taux d'approche après les filtres AML, Impact sur Time-to-Finality, Part release.
Proportion d'appels au sapport pour des raisons de LAM et temps moyen de clarification.

12) Anti-modèles

Ne compter que sur les listes noires sans analyse de chaîne et taint %.
Ignorer les ponts/L2 comme couche de « masquage ».
Auto-échecs sur n'importe quelle étiquette « mixer » sans tenir compte du contexte/fraction/temps.
L'absence de journalisation des versions des étiquettes et des sources de → ne peut pas protéger la solution.
Règles strictes sans RBA/Seuils → démolition de la conversion et de l'expérience VIP.
L'absence d'idempotence et d'anti-duplicate dans les webhooks KYT → les divergences et les doubles blocages.

13) Chèque de mise en œuvre (en bref)

  • Fournisseur (s) KYT : couverture réseau, précision des étiquettes, SLA, versions/sources.
  • Matrice des risques/seuils (T1/T2/T3), politique de proximité/taint % et temps-décay.
  • Intégration de Travel Rule (IVMS101) et politique unhosted (confirmation d'adresse).
  • RBA-движок: allow/limits/hold/reject/escalate + partial release.
  • Gestion des cas : rôles des L1/L2/L3, modèles SAR/STR, rapports pour les banques/régulateurs.
  • Whitelist/denylist avec TTL, carnet d'adresses clients, preuve de propriété.
  • Logi/versioning : source des étiquettes, version du modèle, solution timestamp.
  • Метрики: FP%, Time-to-Decision, SAR-conversion, Approval Rate post-AML.
  • Formation des équipes (Risque/Conformité/Soutien), Pleybooks de communication.
  • Je revois régulièrement les seuils et les rétrospectives des cas perdus/controversés.

14) Résumé

L'AML efficace pour la crypto dans iGaming n'est pas une « liste d'adresses magiques », mais un système : étiquettes et clusters + suivi de chaîne + KYT + solutions RBA intégrées avec Travel Rule et les processus SoF/EDD. Avec un bon calibrage, vous réduisez les risques réglementaires et de sanctions en maintenant la conversion et la vitesse de paiement à un niveau acceptable pour les entreprises et les partenaires.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.