· Yair Knijn
Même nom, humain différent : le faux positif que votre paramétrage a rendu impossible à lever
Un responsable de la criminalité financière hérite d'une configuration de screening qui correspond sur un seul champ : la chaîne de nom de la partie contre la chaîne de nom de la liste. Pas de date de naissance dans la comparaison, pas de nationalité, pas de numéro de passeport ou d'enregistrement. L'hypothèse intégrée dans cette conception est qu'un nom suffit à distinguer deux personnes. Pour quiconque s'appelle Mohammed Ali, Wang Wei ou Maria Garcia, ce n'est pas le cas.
Le résultat est une population de correspondances que vous ne pouvez pas trancher. Chaque résultat sur un nom courant arrive sur le bureau de l'analyste avec la même maigre preuve que le moteur avait : deux noms qui se ressemblent. Il n'y a rien dans le dossier pour orienter la décision vers un classement net ou vers une confirmation, donc tout ce que l'analyste écrit est une supposition déguisée en détermination.
Pourquoi la correspondance par nom seul est structurellement insolvable pour les noms courants
Le paramétrage ne résout pas ce problème, car le problème n'est pas le seuil. Vous pouvez définir une correspondance floue serrée et perdre les vraies désignations dont les noms sont translittérés de trois manières différentes. Vous pouvez la définir large et enterrer l'équipe. De toute façon, la pénurie fondamentale est la même : le seul champ discriminant est le champ qui ne discrimine pas. Un nom de famille courant加上 un prénom courant décrit des milliers de personnes vivantes et une personne sanctionnée, et le nom seul ne peut pas les séparer.
La diversité des conventions de nomination dans le monde aggravate cela, pas l'améliore. La translittération de l'arabe, du cyrillique ou du chinois multiplie les orthographes qu'un nom unique peut prendre, donc deux clients sans rapport résolvent régulièrement vers des chaînes quasi identiques. Votre match_score grimpe vers 100 sur une paire de personnes qui ne partagent rien sauf un système d'écriture.
Les discriminateurs qui réduisent les faux positifs : date de naissance, nationalité, numéros d'identité
Le groupe Wolfsberg cadre l'objectif comme l'augmentation de la part des alertes productives celle qui s'avèrent être réelles. Vous n'y parvenez pas en supprimant les faibles alertes après coup. Vous y parvenez en donnant au moteur plus qu'un nom à comparer, donc les faibles alertes n'atteignent jamais un humain en premier lieu.
- Date de naissance. Un individu listé né en 1962 ne correspond pas à votre client né en 1989, peu importe comment les noms s'alignent. Un champ élimine la plupart de la population de homonymes.
- Nationalité et lieu de naissance. Faciles à capturer lors de l'onboarding, et décisifs contre une entrée de liste liée à un autre pays.
- Numéros d'identité et d'enregistrement. Un numéro de passeport ou un numéro d'enregistrement d'entreprise est quasi unique. Quand il est présent des deux côtés, la question cesse d'être un jugement et devient une vérification.
Comment les entrées faibles forcent les équipes à sur-bloquer ou à valider automatiquement
Quand la seule preuve est deux noms similaires, un analyste a deux façons de survivre à la file, et les deux sont des échecs. Lesprudents sur-bloquent : ils escaladent ou retiennent tout ce qui score haut, ce qui gèle les polices légitimes et apprend à l'entreprise à voir la conformité comme le département qui casse les choses sans raison. Les rapides valident automatiquement : ils classent sur le motif, "ressemble à un autre résultat sur nom courant," et écrivent une justification d'une ligne qui ne survivrait pas trente secondes de questionnement réglementaire. Même entrée cassée, mécanisme d'adaptation opposé, aucun défendable.
C'est ici que le récent dossier d'application d'OFAC fait mal. Les pénalités en 2024 et 2025 ont frappé des entreprises dont les contrôles n'ont pas réussi à révéler la vraie propriété sanctionnée et l'exposition. Un classement que vous ne pouvez pas évidence est la même responsabilité qu'un résultat que vous avez manqué ; les deux viennent d'un dossier de cas qui ne montre pas pourquoi la décision était correcte.
Introduire des données de partie plus riches dans le screen pour que le score de correspondance signifie quelque chose
La solution est en amont du moteur. Capturez la date de naissance, la nationalité et au moins un identifiant au moment où vous prenez en charge la partie, puis transmettez ces champs dans la comparaison pour que le score reflète l'identité, pas l'orthographe. Une similarité de nom de 95 % qui diverge sur la date de naissance et la nationalité devrait se résoudre bas et se clearser elle-même. Une correspondance de nom de 95 % qui est également d'accord sur la date de naissance et le numéro de passeport devrait escalader durement. Lorsque les entrées portent ce signal, le match_score signifie enfin quelque chose, et vos autorisations et vos confirmations sont accompagnées des preuves.
InsureGuardAI est construit autour de ce principe : chaque espace de travail client filtre contre des identifiants secondaires, pas seulement des chaînes de noms, et conserve la réponse de correspondance brute et les champs discriminants dans le dossier de cas. Donc lorsque le régulateur vous demande pourquoi vous avez autorisé un homonyme courant, la réponse est un enregistrement montrant la date de naissance et la nationalité qui ont exclu le noms, pas une phrase qui commence par "nous avons supposé".