Sanktions-Screening, das nicht mehr auf Schreibweisen anspringt

Sanktions-Screening produziert False Positives, weil es Zeichenketten abgleicht, keine Personen. Um das Trefferaufkommen zu senken, ohne echte Treffer zu verlieren, lösen Sie zuerst die Entität auf: Behalten Sie den Namensabgleich als bewusst großzügige Recall-Schicht bei und ranken Sie die Kandidaten dann nach Identifikatoren, Jurisdiktion und Eigentümerstruktur, bevor irgendein Alert bearbeitet wird. Der Namenstreffer startet den Prozess. Er sollte ihn nicht beenden.

Klassisches Screening vergleicht einen Namen in Ihrer Transaktion mit einem Namen auf einer Liste, bewertet die String-Distanz und löst einen Alert aus, wenn der Score eine Schwelle überschreitet. Es hat keine Ahnung, ob die beiden Namen zur selben realen Person oder demselben Unternehmen gehören. Also feuert es mit gleicher Zuversicht auf “Mohammed Ali”, den Boxer, den Kunden und den Spediteur in Karatschi. Entity Resolution behebt das, indem es zuerst fragt, wer die Partei tatsächlich ist, bevor es entscheidet, ob der Treffer relevant ist.

Diese Unterscheidung ist das ganze Spiel. Ein Name ist eine Zeichenkette. Eine Entität ist eine Person oder Organisation mit Geburtsdatum, Jurisdiktion, Passnummer, gemeldeter Anschrift und Eigentümerstruktur. Nur auf die Zeichenkette zu screenen bedeutet, dass Sie auf Schreibweisen abgleichen, und Schreibweisen sind billig. Zwei nicht verwandte Personen teilen sich ständig einen Namen. Eine sanktionierte Person und ein Rentner in Ohio können bei einem Namensvergleich zu 100 Prozent übereinstimmen und trotzdem nichts miteinander zu tun haben. Der Listeneintrag trägt weit mehr als nur einen Namen, und die meisten Screening-Systeme werfen all das beim Vergleichsschritt weg.

Die False-Positive-Steuer und woher sie kommt

Fragen Sie ein Sanktionsteam nach seiner Trefferquote, und die ehrlichen werden Ihnen sagen, dass die hohen Neunzigerprozente False Positives sind. Diese Zahl ist kein Tuning-Versagen. Sie ist strukturell, und sie hat drei Quellen.

• Reiner Namensvergleich. Der Abgleich bewertet “Ivan Petrov” gegen jeden Ivan Petrov auf der konsolidierten Liste, ohne die Felder für Geburtsdatum, Staatsangehörigkeit oder Identifikatoren zu nutzen, die die meisten davon in einem Schritt eliminieren würden.
• Schwellenwert-Theater. Teams scheuen sich, die Match-Schwelle anzuheben, weil ein übersehener True Positive ein regulatorisches Ereignis ist und ein False Positive nur Arbeit. Also bleibt die Schwelle niedrig, die Warteschlange läuft über, und Prüfer klären denselben harmlosen Namen hundertmal pro Woche.
• Listenhandhabung. Die 50-Prozent-Regel der OFAC bedeutet, dass Entitäten, die zu 50 Prozent oder mehr, in Summe, von einer oder mehreren gesperrten Parteien gehalten werden, selbst gesperrt sind, auch wenn sie namentlich nie auf der SDN-Liste auftauchen. Systeme, die nur die veröffentlichten Namen screenen, übersehen diese entweder ganz oder erzeugen, wenn jemand eine grobe Eigentümer-Expansion anflanscht, eine neue Flut schwacher Treffer.

Die Kosten liegen hier nicht nur in den Prüfstunden. Jeder False Positive, der einen Kunden erreicht, bedeutet eine gehaltene Zahlung oder ein beim Onboarding gesperrtes Konto und eine Beziehung, die Sie danach kitten müssen. Schlimmer noch: Eine Warteschlange, die zu 98 Prozent aus Rauschen besteht, trainiert Prüfer darauf, schnell abzuhaken, und genau das ist die Bedingung, unter der ein echter Treffer durchrutscht. Alert Fatigue ist ein Recall-Problem im Präzisions-Kostüm.

Erst die Entität auflösen, dann über den Treffer entscheiden

Unsere Methode stellt Entity Resolution vor die Bearbeitung. Der Namensabgleich läuft weiterhin und bleibt bewusst großzügig, denn er ist die Recall-Schicht, und seine Aufgabe ist es, niemals einen Kandidaten zu verwerfen, der echt sein könnte. Was sich ändert, ist alles, was der Kandidatenliste nachgelagert ist.

Für jedes Kandidatenpaar stellen wir den Kontext zusammen, den ein menschlicher Analyst tatsächlich prüfen würde, und berechnen ihn als Features:

• Übereinstimmung der Identifikatoren. Stimmt das Geburtsdatum überein oder fällt es in einen plausiblen Bereich? Passen Pass-, Personalausweis- oder Steuernummern zusammen? Ein einziger starker Identifikator-Treffer ist mehr wert als jeder Namens-Score.
• Jurisdiktion und Geografie. Eine Partei, die Euro zwischen zwei deutschen Konten überweist und gegen einen SDN-Eintrag abgeglichen wird, dessen einzige bekannte Anschriften in Pjöngjang liegen, ist etwas anderes als eine mit überlappender Geografie.
• Namensstruktur, nicht nur Distanz. Transliterationsvarianten, Patronyme, Firmensuffixe und Wortumstellungen werden mit einer Logik behandelt, die weiß, dass es sich um dasselbe Phänomen handelt, statt mit einem rohen Levenshtein-Score, der “Al-Rashid Trading LLC” und “Rashid Al Trading Limited” für weit voneinander entfernt hält.
• Eigentümergraph. Für das Screening von Entitäten die aufgelöste Eigentümerstruktur, von der die 50-Prozent-Regel abhängt, sodass die abgeleiteten gesperrten Entitäten vollwertige Kandidaten sind und kein nachträglicher Einfall.

Diese Features speisen ein Modell, das Kandidaten rankt und routet, und hier zahlt sich Disziplin aus. Das Evaluierungsset wird aus Ihren eigenen bearbeiteten Alerts aufgebaut, mit Point-in-Time-Korrektheit, sodass ein Treffer gegen die Liste und die Parteidaten so bewertet wird, wie sie am Transaktionsdatum existierten. Backtesting gegen eine aktuelle Liste, die seither geändert wurde, ist Leakage, und es wird Ihre Zahlen schmeicheln, bis zu dem Tag, an dem ein echter Fall geprüft wird. Halten Sie ein Held-out-Set bestätigter True Positives bereit und überwachen Sie den Recall darauf, als wäre er die einzige Kennzahl, die existiert, denn für einen Regulator ist er das nahezu.

Was “Treffer reduzieren” nicht bedeuten darf

Es gibt eine falsche Version dieses Projekts, und sie lässt sich leicht aus Versehen bauen. Sie sieht aus wie ein Modell, das niedrig bewertete Alerts stillschweigend unterdrückt, um die Warteschlange zu verkleinern. Das ist keine Risikoreduktion. Das ist, Ihre False-Negative-Rate an einen Ort zu verschieben, an dem Sie sie nicht sehen können.

Die Version, die ein Audit übersteht, führt eine lückenlose Spur. Jeder Kandidat, den der Namensabgleich erzeugt hat, wird aufbewahrt. Jedes Feature, das in das Ranking eingeflossen ist, wird gespeichert. Wenn das System einen Alert zur automatischen Schließung routet, wird der Grund in einer Sprache protokolliert, die ein Prüfer und ein Aufseher lesen können: Identifikatoren widersprachen sich, Jurisdiktion unvereinbar, aufgelöst zu einer aus einer früheren Prüfung bekannten freigegebenen Entität. Ein Prüfer kann jeden automatisch geschlossenen Alert zurückholen und überstimmen, und diese Overrides werden zu neuen Labels, die den nächsten Evaluierungszyklus speisen.

Zwei operative Punkte entscheiden, ob das über die Zeit trägt. Erstens: Lineage. Wenn die konsolidierte Liste aktualisiert wird, was sie ständig tut, screenen Sie die betroffene Population neu und können exakt nachweisen, welche Version der Liste welche Entscheidung erzeugt hat. Zweitens: Drift. Die Verteilungen der Match-Scores verschieben sich, wenn sich Ihr Kundenstamm und Ihre Zahlungskorridore ändern, und eine Schwelle, die letztes Quartal richtig war, kann still verfallen. Überwachen Sie die Score-Verteilungen und die Auto-Close-Rate und behandeln Sie eine plötzliche Verschiebung in einer der beiden als Vorfall, statt als etwas, das man sich ansieht, wenn zum Quartalsende Zeit frei wird.

Auf diese Weise umgesetzt, sinkt das Trefferaufkommen, weil das System aufhört, verschiedene Personen zu verwechseln, die sich einen Namen teilen, nicht weil es gelernt hat wegzusehen. Prüfer verbringen ihre Stunden mit den Kandidaten, bei denen die Identität wirklich mehrdeutig ist, und das ist der einzige Ort, an dem sich ihr Urteilsvermögen je zu bezahlen lohnte.