Filtrage des noms et des entités

Le filtrage des noms est le plus ancien contrôle des sanctions et celui que les autorités de supervision vérifient encore en premier. Il permet de déterminer si une personne désignée peut ouvrir un compte, recevoir un retrait ou figurer comme bénéficiaire dans un message Travel Rule. Mal effectué, il submerge les analystes d’alertes dénuées de sens ou laisse discrètement passer le nom qui compte ; cette leçon explique comment le mettre en place, le calibrer et en apporter la preuve.

Sources des listes et gestion des listes

La gestion des listes est le processus de bout en bout qui consiste à choisir, obtenir, charger et tenir à jour les listes utilisées par une entreprise pour le filtrage. Il s’appuie sur la décision relative aux régimes décrite dans la leçon Comment fonctionnent les sanctions :

• la Liste récapitulative du Conseil de sécurité des Nations Unies, publiée dans un format lisible par machine, avec un numéro de référence permanent pour chaque entrée ;
• les listes de tous les régimes autonomes appliqués par l’entreprise ;
• les listes internes : anciens clients dont la relation a pris fin pour des raisons liées aux sanctions, sociétés écrans connues et personnes ou entités que l’entreprise a décidé de ne pas servir.

Chaque chargement d’une liste est un événement contrôlé. L’entreprise devrait consigner la source de la liste, sa version ou son horodatage de publication, l’heure à laquelle elle a été chargée dans le système de filtrage, ainsi que le nombre d’entrées ajoutées, modifiées et supprimées. Comparer ces nombres à l’annonce du propre éditeur de la liste constitue un contrôle simple de son exhaustivité. Comme le GAFI attend un gel sans délai, le temps écoulé entre la publication d’une liste et le nouveau filtrage de l’ensemble de la clientèle devrait se compter en heures, et le temps mesuré devrait être communiqué à la direction.

Les données des listes nécessitent une attention particulière. Les entrées peuvent comporter plusieurs noms écrits dans différents alphabets, des dates de naissance partielles et des alias de qualité inégale. La liste de l’ONU désigne certains alias comme étant de faible qualité, et le Guide de Wolfsberg sur le filtrage des sanctions (2019) décrit les alias faibles comme des noms généraux ou génériques, tels que des surnoms et des acronymes courants, pour lesquels le filtrage « n’est pas attendu et n’est généralement pas productif ». Une décision documentée d’exclure les alias faibles ou de leur attribuer un poids moindre est un choix légitime de calibrage ; une décision non documentée constitue une lacune.

Données soumises au filtrage

Les bénéficiaires effectifs comptent autant que les titulaires de compte, car les règles de propriété et de contrôle peuvent rendre une entité interdite même si son propre nom ne présente aucun problème. Les données Travel Rule sont faciles à oublier : le nom du bénéficiaire dans un message entrant correspond à une partie avec laquelle l’entreprise traite et devrait faire l’objet d’un filtrage avant le crédit des fonds (voir la leçon Données et messagerie Travel Rule).

Préparation des propres données de l’entreprise

La qualité du filtrage dépend autant des données clients que des données des listes. De nombreux rapprochements manqués s’expliquent par la façon dont l’entreprise a initialement enregistré le nom. Les bonnes pratiques en matière de données de référence comprennent :

• des champs distincts pour les prénoms, le nom de famille et le nom complet tel qu’il est écrit, plutôt qu’un seul champ de texte libre ;
• le nom dans son alphabet d’origine ainsi que sa translittération latine telle qu’elle figure sur le document d’identité ;
• la date de naissance complète, la nationalité et les numéros de documents, saisis dans des champs structurés afin de pouvoir les comparer automatiquement aux identifiants figurant sur les listes ;
• pour les entités juridiques, la dénomination sociale, les noms commerciaux, les anciennes dénominations et le numéro d’immatriculation ;
• une règle selon laquelle chaque dossier doit être soumis au filtrage avant l’activation d’un compte, afin qu’un champ manquant ne permette pas à un client de contourner le système.

La normalisation avant le rapprochement élimine les éléments parasites qui réduiraient autrement les scores : conversion en une seule casse, suppression cohérente de la ponctuation et des signes diacritiques, uniformisation des suffixes juridiques tels que « Ltd » et « Limited », et suppression des titres de civilité. La même normalisation doit être appliquée aux données des listes et aux données clients, sans quoi la comparaison est déséquilibrée. Les modifications des règles de normalisation modifient le contrôle et doivent être testées et approuvées comme tout changement de seuil.

Rapprochement approximatif

Le rapprochement exact échoue parce que les noms ne sont pas des chaînes de caractères stables. Une même personne peut être enregistrée avec différentes orthographes, différents ordres de mots et différents alphabets. Le rapprochement approximatif évalue la proximité de deux noms au lieu d’exiger leur identité. Parmi les difficultés courantes :

• translittération : les noms issus des alphabets arabe, cyrillique, chinois, coréen ou d’autres systèmes d’écriture peuvent être rendus en lettres latines de nombreuses façons ; un système doit donc prévoir des variantes de translittération ou une comparaison phonétique ;
• ordre et structure des noms : nom de famille placé en premier ou en dernier, patronymes, noms de famille composés, particules et titres de civilité ;
• troncature et initiales : noms raccourcis par un champ de formulaire ou enregistrés avec des initiales ;
• alias : toute correspondance avec un alias répertorié compte, mais les alias faibles génèrent du bruit ;
• noms d’entités : suffixes juridiques, noms traduits et abréviations.

Les algorithmes combinent des mesures de distance d’édition, des codes phonétiques et des comparaisons de jetons pour calculer un score. Le score ne devrait jamais décider à lui seul. Les identifiants secondaires, tels que la date de naissance, la nationalité, le lieu de naissance, les numéros de documents d’identité et les numéros d’immatriculation, permettent de distinguer une véritable correspondance d’un homonyme. Les dates de naissance partielles sont courantes dans les listes : une entrée peut n’indiquer qu’une année, une année « vers » laquelle la personne serait née, ou plusieurs dates possibles. Un client né cette année-là est cohérent avec l’entrée ; un client né plusieurs décennies plus tard ne l’est pas.

Filtrage à l’entrée en relation et nouveau filtrage

Le filtrage à l’entrée en relation empêche une personne désignée d’entrer dans le système. Le nouveau filtrage permet de maintenir la conformité de la clientèle lorsque les listes et les données changent. Trois déclencheurs sont nécessaires :

1. Modification d’une liste : chaque ajout ou modification est soumis au filtrage sur l’ensemble de la clientèle, généralement à l’aide d’un fichier différentiel, le jour même.
2. Modification des données d’un client : un nouveau nom, une nouvelle nationalité, une nouvelle adresse ou un nouveau bénéficiaire effectif déclenche le filtrage du dossier modifié.
3. Nouveau filtrage complet périodique : une exécution complète permet de détecter tout ce que les fichiers différentiels ont manqué, par exemple une modification des règles de rapprochement ou un échec de chargement.

Une entreprise qui ne filtre qu’à l’entrée en relation ne détectera pas les clients désignés après leur arrivée, ce qui constitue l’un des manquements les plus souvent cités dans les mesures coercitives rendues publiques.

Calibrage des seuils : faux positifs et faux négatifs

Chaque score de correspondance est comparé à un seuil. Un seuil plus bas détecte davantage de variantes et génère plus d’alertes ; un seuil plus élevé réduit le bruit, mais augmente le risque de passer à côté d’une correspondance.

Comme un faux négatif peut constituer une infraction, les seuils devraient être définis par des tests, et non en fonction du volume de réclamations. Une bonne pratique consiste à faire passer dans la configuration de production un fichier de test contenant des noms préétablis, notamment des variantes de translittération, des noms dont l’ordre a été modifié, des fautes de frappe et des alias d’entrées réelles des listes, puis à mesurer combien de noms le système détecte à différents seuils. L’échantillonnage sous le seuil, en demandant aux analystes d’examiner un échantillon aléatoire de paires presque correspondantes, montre ce qui échappe au système. Les orientations de Wolfsberg préconisent un calibrage avant le déploiement et de manière continue, avec des tests indépendants étayés par des indicateurs.

Résolution des alertes et documentation

Lorsqu’un analyste résout une alerte, il compare les données du client à l’entrée de la liste, identifiant par identifiant, et consigne une décision : faux positif, correspondance possible nécessitant une escalade, ou correspondance confirmée. Les correspondances confirmées et possibles sont transmises au responsable des sanctions, et les correspondances confirmées déclenchent les mesures de gel, de blocage et de signalement. Un dossier pourrait ressembler à ceci :

{
  "alert_id": "SAN-2026-004417",
  "list_source": "UN Consolidated List",
  "list_version": "2026-10-27T18:05Z",
  "list_ref": "QDi.xxx",
  "customer_id": "C-88213",
  "match_score": 0.91,
  "matched_field": "alias",
  "comparison": {"name": "partial", "dob": "customer 1994 vs listed circa 1961",
                 "nationality": "different", "document": "no listed number"},
  "decision": "false_positive",
  "rationale": "Shared surname only; DOB 33 years apart; nationality differs",
  "analyst": "A-117", "reviewed_by": "A-042",
  "closed_at": "2026-10-28T09:14Z"
}

Le dossier indique la version de la liste, ce qui permet à un auditeur de reproduire les données vues par le système ; il compare chaque identifiant au lieu de se contenter de dire « ce n’est pas la même personne » ; et il fait état d’un deuxième réviseur, ce que de nombreuses entreprises exigent pour les correspondances confirmées et pour un échantillon de faux positifs. La référence de la liste est tronquée ici, car il s’agit d’un exemple fictif.

Les faux positifs répétés concernant le même client peuvent être supprimés au moyen d’une entrée dans une liste d’exemption, mais uniquement pour cette paire client-entrée, avec un motif, une approbation et une date d’expiration ou de révision. Si l’entrée de la liste change, l’exemption doit expirer automatiquement.

Points clés pour l’examen : la gestion des listes et la preuve de chaque chargement (source, version, horodatages, nombres) ; le nouveau filtrage de l’ensemble de la clientèle dans les heures suivant une modification de liste ; les données à filtrer, y compris celles des bénéficiaires effectifs et les noms des donneurs d’ordre et des bénéficiaires Travel Rule ; les difficultés du rapprochement approximatif (translittération, ordre des noms, alias, alias faibles) et le rôle des identifiants secondaires, notamment des dates de naissance partielles ; les trois déclencheurs du nouveau filtrage ; la différence entre faux positifs et faux négatifs et le calibrage au moyen de fichiers de test contenant des noms préétablis et d’un échantillonnage sous le seuil ; les éléments que doit contenir un dossier d’alerte complet ; le contrôle des listes d’exemption.