REER/listes de sanctions : dépistage

1) Pourquoi le dépistage RRE/sanctions dans iGaming

Le dépistage est le circuit de base de la conformité : empêche de travailler avec des personnes/organisations interdites et réduit le risque de sanctions réglementaires, de gel des canaux de paiement et de blocage des banques/PSP. Dans iGaming (MCC 7995), il complète la surveillance KYC/KYB et AML et affecte directement la disponibilité de l'infrastructure de paiement et la vitesse des retraits.

2) Sources et types de listes

Listes de sanctions : internationales (ONU), supranationales/régionales (UE, Royaume-Uni), nationales (OFAC des États-Unis, ainsi que registres locaux).
PEP (Politically Exposed Persons) : agents publics actifs/anciens + parents et personnes proches liées.
Adverse Media (médias négatifs) : enquêtes criminelles, fraude, corruption, etc. - une couche auxiliaire.
Interdictions de fait et embargo commercial : pays, secteurs, actifs.
Adresses cryptées avec des étiquettes de sanctions : bourses/portefeuilles/mixeurs, risque élevé selon KYT.

3) Quand et qui dépister (CUS/KWD/opérations)

KYC (physicien) : Lors de l'enregistrement (Tier 1), avant la première sortie, lors de la mise à niveau à Tier 2/3, lors du changement de nom/adresse/document, recadrage horaire.
KYB (juriste) : société, directeurs/officiers, UBO ; lors de l'onbording, des mises à jour de la structure, une fois sur 6-12 mois, le recadrage planifié.
Événements opérationnels : dépôts importants/conclusions (seuil-déclencheur), changement de géo/dispositif, augmentation du risque en AML.

4) Qualité des données et normalisation (avant les matchs)

Normalisation des NOM : registre, espaces, diacritique, translittération (GOST/ISO/règles nationales), formes alternatives (Aleksandr/Alexander).
Dates de naissance : formats 'DD/MM/YYYY'vs' YYYY-MM-DD ', erreur ± 1 jour (erreurs de documents).
Adresses : pays/régions dans les codifications ISO, annuaires urbains.
Entités : forme juridique (LLC/Ltd/AO), alias/anciens noms, numéros d'enregistrement.
Crypto : normalisation des adresses et des fournisseurs (bourses, castodians), réseau/chaîne.

5) Matching : Exact, flou et baisse des faux positifs

• Match exact par ID : passeport/reg. numéro, date/lieu de naissance, numéro d'immatriculation de l'entreprise.
• Fuzzy match (algorithmes de distance : Levenshtein, Jaro-Winkler) avec des seuils similaires.
• Alias/AKAs : comparaison par noms alternatifs, noms de jeune fille, latin/cyrillique.

• Exiger une correspondance pour un minimum de deux caractéristiques indépendantes (nom + date de naissance/nom + pays/numéro de document).
• Déduplication des alerts (consolidation des matchs par personne/société).
• Géofiltres et contexte (pays de naissance vs résidence actuelle).
• Listes blanches (allow-list) pour les « fausses correspondances » confirmées avec la période de contrôle (expiry).

6) Classification des alerts et priorité

Le seuil du match fuzzy est choisi par le marché/langue (pour le cyrillique - un peu plus haut, compte tenu de la translittération).

7) Processus de rhubarbe (flux de travail)

1. Enrichissement : tirer les données client/contrepartie (KYC/KYB, géo, paiements).
2. Vérification de la source : vérifiez l'entrée dans le registre/agrégateur (mise à jour, date de mise à jour).
3. Prise de décision : Approve (fausse correspondance), EDD/limites, Reject/Freeze.
4. Documentation : cause, champs de mappage utilisés, références aux sources, durée de validité de la solution (pour allow-list).
5. Communication : demande de documents/explications, respect de l'interdiction de tipping-off en SAR.

• Haute : ≤ 4 h (verrous critiques)
• Medium: ≤ 24 ч
• Low : ≤ 72 h

8) Rescrining et événements (event-driven)

Chaque jour : lancer automatiquement tous les profils/contreparties actifs.
On-demand : en cas de changement de nom/adresse/document/UBO/directeurs, en cas de grandes conclusions, en cas d'alertes AML.
Versioner les listes : enregistrez la date/version de la source dans les logs pour reproduire la solution dans un an.

9) Intégration avec KYB/KYC/AML/Payments

KYC/KYB : dépistage au moment de l'onbordage et à toute mise à niveau du niveau.
Surveillance AML : le dépistage positif augmente la priorité des alertes (voir Rapid In-Out, Structuring).
Payments Orchestrator : Holds/limites automatiques à haute altitude ; routage vers des méthodes « sécurisées ».
KYT/Travel Rule : risques de sanctions sur les adresses cryptées, échange d'attributs entre VASP (le cas échéant).

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

Minimisation : ne stockez que les champs utilisés pour la solution ; masquer les numéros de documents.
Cryptage et accès : KMS/HSM, RBAC, journal des appels ; interdiction des décharges en dehors des canaux protégés.
Retraite : stockage des solutions/logs selon la réglementation (souvent 5 + ans).
Vérification de l'empreinte : qui/quand/quoi a comparé, quelle version de la liste, quel résultat.

11) Métriques et qualité du processus

Précision et vitesse

Precision/Recall par marquage manuel (sample), proportion de faux positifs (FP).
SLA hit rate (High/Med/Low), temps moyen avant la décision (p50/p95).

Opérations

Proportion de recréations avec changement d'état, taux de mise à jour des listes.
Nombre d'alerts par 1k onbordings/par 1k clients actifs.
Coût unitaire d'une mallette.

Risque/entreprise

Nombre de cas Stop (sanctions) et paiements évités.
Corrélation du « dépistage positif » avec les incidents AML, charjbecks.

12) Choix du fournisseur et architecture

• Couverture : listes internationales + locales (sources officielles), taux de rafraîchissement.
• Qualité des matchs : seuils personnalisables, support des translittérations, alias, fuzzy.
• Performances : API latence, SLA uptime, mode batch pour le recadrage.
• Confidentialité/conformité : DPIA, localisation des données, journaux, certificats.
• Fonctions : gestion de cas, allow/deny-lists, versioning des sources, web hooks.

• Service de dépistage (microservice) + cache de résultats « à chaud ».
• Files d'attente pour le recadrage par lots (tâches nocturnes).
• Système de cas pour rhubarbe manuel, avec intégration dans KYC/KYB/AML.

13) Matrice des solutions (exemple)

14) Anti-modèles

C'est une avalanche de FP.
L'absence de translittération/alias est un laissez-passer de matchs réels.
Pas d'allow-list avec expiration - la commande se noie dans les FP répétés.
C'est rare - il n'y a pas de nouvelles inscriptions.
Il n'y a pas de journal des versions des listes - les solutions ne peuvent pas être protégées lors de l'audit.
Le message au client sur le SAR (tipping-off) est une violation grave.

15) Chèque de mise en œuvre

• Sources : Listes internationales, régionales et locales + agrégateur.
• Normalisation des données (nom/date/adresse/organisation/crypto), translittérations et alias.
• Stratégie de match : exact + fuzzy avec seuils personnalisables et géocontext.
• Processus de jalousie : rôles, SLA (4h/24h/72h), modèles de solutions et de communications.
• Allow/deny-lists avec expectation et audit.
• Récitation quotidienne + événements à la demande ; le versionage des sources.
• Intégrations : KYC/KYB/AML, KYT/Travel Rule, Payments Orchestrator (holds/limits).
• Données/vie privée : cryptage, RBAC, revues, rétentions.
• Métriques de qualité et QA-sempling régulier ; réduction du PF par des expériences ciblées.
• Plan de continuité (fournisseur fallback, dégradation de l'API).

16) Résumé

Le dépistage efficace des RER/sanctions n'est pas seulement « percer sur les listes ». Il s'agit de données normalisées, d'effets flexibles + fuzzy matching, d'un processus de rhubarbe contrôlé avec des priorités et des SLA, d'un recadrage quotidien et d'une intégration avec AML/KYC/KYB/KYT. Ce circuit minimise les faux positifs, attrape les risques réels, protège les rails de paiement et accélère les conclusions légitimes - ce qui permet une monétisation durable.