Falsch-Positiv-Hygiene beim Sanktions-Screening

Fragt man einen Compliance-Analysten, was an seinem Screening-Tool nicht stimmt, lautet die Antwort selten „wir übersehen Dinge." Fast immer heißt es: „Wir bekommen zu viele Alerts, und die meisten sind nichts." Diese Klage klingt nach einem Effizienzproblem. Tatsächlich ist es ein Risikoproblem: Die Sanktionshaftung nach OFAC ist strikt – Vorsatz und Kenntnis sind keine Verteidigung –, und ein Programm, das täglich Hunderte minderwertiger Alerts erzeugt, trainiert seine eigenen Analysten darauf, Fälle schnell abzuhaken – genau unter dieser Bedingung wird ein echter Treffer durchgewunken. Falsch-Positiv-Hygiene ist keine UX-Nettigkeit. Sie ist eine Kontrolle, die darüber entscheidet, ob die echten Treffer im Stapel tatsächlich erkannt werden.

Warum Falsch-Positive entstehen

Die meisten Falsch-Positiven lassen sich auf eine kleine Zahl von Grundursachen zurückführen, die sich gegenseitig verstärken:

• Häufige Namen. Namen in der Art von „Mohammed Ahmed" oder „John Smith" erzeugen Treffer gegen einen nennenswerten Anteil jeder Kundenbasis, unabhängig von einer tatsächlichen Verbindung zur sanktionierten Person.
• Transliterationsvarianz. Namen, die aus arabischer, kyrillischer oder chinesischer Schrift in lateinische Buchstaben übertragen wurden, haben mehrere gültige Romanisierungen – „Gaddafi," „Qaddafi" und „Kadhafi" sind derselbe Name. Ein Matching-Algorithmus, der auf Tippfehler in lateinischer Schrift abgestimmt ist, geht damit anders um als einer, der für schriftübergreifende Varianz gebaut wurde, und der falsche übersieht entweder die echte Variante oder behandelt jede Romanisierungswahl als Beinahe-Treffer gegen alles.
• Schwache oder fehlende Sekundäridentifikatoren. Ein Treffer, der allein auf dem Namen beruht – ohne Geburtsdatum, Staatsangehörigkeit oder nationale ID-Nummer zur Eingrenzung des Feldes –, kann die sanktionierte Person nicht von einer unbeteiligten Person unterscheiden, die zufällig denselben Namen trägt.
• Alias-Wildwuchs ohne Stärkesignal. Gelistete Entitäten führen häufig zehn oder mehr bekannte Aliasnamen – vollständige Namensvarianten, Einwort-Spitznamen, frühere Firmennamen. Wird ein dünner Einwort-AKA mit demselben Matching-Gewicht behandelt wie ein starker, eindeutiger Alias, erhöht das die Trefferzahl gegen jeden, dessen Name zufällig dieses Fragment enthält.

Der Zielkonflikt, unverblümt benannt

Jeder Hebel, der Falsch-Positive reduziert, hat auch die Fähigkeit, Falsch-Negative zu reduzieren, wenn er zu weit betätigt wird. Genau darin liegt die ganze Schwierigkeit dieses Problems: Ein Fuzzy-Matching-Schwellenwert, der so weit verschärft wird, dass er aufhört, „John Smith" gegen jeden Kunden namens John Smith zu markieren, ist zugleich ein Schwellenwert, der eine echte, knapp verfehlte Transliteration unmarkiert durchlassen kann. Auf eine ruhige Warteschlange zu optimieren und auf verteidigungsfähige Abdeckung zu optimieren sind nicht dasselbe Ziel, und ein Programm, das nur misst, dass „Alerts pro Tag" sinkt, hat keine Möglichkeit zu erkennen, welches der beiden Ziele es tatsächlich erreicht hat. Jede Anstrengung zur Reduzierung von Falsch-Positiven muss darlegen – und nachweisen können –, dass sich der Recall bei echten Treffern nicht verändert hat.

Konkrete Techniken

1. Nicht nur auf den Namen matchen. Die Änderung mit der größten Hebelwirkung ist es, jeden Identifikator zu nutzen, den eine Quelle tatsächlich veröffentlicht – Geburtsdatum, Geburtsort, Staatsangehörigkeit, Reisepass- oder nationale ID-Nummer, und bei Schiffen die IMO-Nummer, die weitaus trennschärfer ist als ein Schiffsname. Ein reiner Namensabgleich gegen einen häufigen Namen ist praktisch unbrauchbar; derselbe Name plus ein Geburtsdatum engt das Feld um Größenordnungen ein, und zwar in beide Richtungen – er entlastet unbeteiligte Namensvetter und erhöht die Konfidenz bei einem echten Treffer. Deshalb listet der Quellenkatalog genau auf, welche Identifikatoren jede Liste veröffentlicht: Zwei Quellen mit derselben nominellen Abdeckung können eine sehr unterschiedliche Matchbarkeit haben, je nachdem, welche Felder die herausgebende Behörde tatsächlich offenlegt.

2. Aliasnamen nach unterschiedlicher Stärke behandeln, nicht als eine undifferenzierte Liste. Eine alternative Schreibweise des vollständigen rechtlichen Namens und ein Einwort-Spitzname sind nicht gleich aussagekräftig. Programme, die jeden AKA identisch bewerten, erben die Falsch-Positiv-Rate ihres schwächsten Alias. Wo eine Quelle zwischen starken und schwachen Aliasnamen unterscheidet, sollte diese Unterscheidung in die Matching-Logik übernommen werden, statt sie einzuebnen.

3. Einen für Schrift und Sprache geeigneten Matching-Algorithmus verwenden, nicht eine allgemeine Edit-Distance-Funktion. Kyrillische und arabische Transliterationsvarianz ist ein bekanntes, begrenztes Problem – phonetisches und transliterationsbewusstes Matching bewältigt es deutlich besser als rohe String-Edit-Distance-Schwellenwerte, die auf Tippfehler in lateinischem Text abgestimmt sind. Ein einziger globaler Schwellenwert, einheitlich über alle Namensherkünfte angewendet, ist eine häufige und vermeidbare Quelle für beide Fehlerarten zugleich.

4. Bearbeitungshistorie nachverfolgen – ohne das Screening jemals zu unterdrücken. Wenn ein Analyst einen Treffer für einen bestimmten Kunden als „geprüft, kein Treffer" abschließt, vermeidet die Dokumentation dieser Feststellung, dass derselbe geringwertige Alert in jedem Screening-Zyklus erneut aufgerollt wird. Entscheidend ist hier die Disziplin: Das reduziert wiederkehrendes Rauschen bei einem dokumentierten Nicht-Treffer, nicht das zugrunde liegende Screening. Die Liste wird weiterhin jedes Mal geprüft; es sinken lediglich die Alert-Fatigue-Kosten einer bereits geklärten Feststellung. Einen Namen stillschweigend von künftigem Screening auszuschließen, ist eine grundlegend andere, weitaus riskantere Entscheidung und darf niemals ein Nebeneffekt der Rauschreduzierung sein.

5. Quellherkunft nutzen, um Analysten bei der Triage zu unterstützen, nicht nur zur nachträglichen Prüfung. Zu wissen, von welcher Behörde, welchem Programm und welcher Liste ein Treffer stammt, erlaubt einem Prüfer, die Plausibilität schnell einzuschätzen – ein Treffer gegen ein Sanktionsprogramm der Demokratischen Republik Kongo bei einem Kunden ohne afrikanischen Geschäftsbezug hat andere Vorannahmen als ein Treffer gegen eine OFAC-Russland-Programm-Listung bei einem Kunden mit russischen Geschäftspartnern. Das ist ein direkter, praktischer Nutzen derselben Quellentransparenz-Haltung, die auch unserem Datenkatalog zugrunde liegt: Provenienz ist nicht nur für die Prüfspur da, sie ist ein Triage-Signal im jeweiligen Moment.

Der regulatorische Hintergrund

OFACs eigenes Framework for Compliance Commitments behandelt Screening-Qualität – Abdeckung, Aktualität, Kalibrierung des Fuzzy-Matching und die Auflösung der Eigentumsketten der 50 Percent Rule – als dokumentierte Kontrolle, nach der Prüfer suchen, nicht als internes Implementierungsdetail, das dem Ermessen des Anbieters überlassen bleibt. Ein Programm, das nicht erklären kann, warum seine Match-Schwellenwerte so gesetzt sind, wie sie sind, und das nicht zeigen kann, dass eine Falsch-Positiv-Reduzierung nicht auf Kosten des Recalls ging, hat keine verteidigungsfähige Kontrolle – es hat lediglich eine kürzere Warteschlange.

Wo Sie Ihr eigenes Matching überprüfen können

Durchsuchen Sie den Quellenkatalog, um zu sehen, welche Identifikatoren und Alias-Strukturen jede Liste tatsächlich veröffentlicht, durchsuchen Sie den vollständigen Korpus, um die tatsächliche Alias-Dichte und Identifikator-Abdeckung Datensatz für Datensatz zu sehen, und werfen Sie einen Blick in unsere AML/CFT-Jurisdiktionsleitfäden, um zu erfahren, wie jeder Regulator die Erwartungen an die Screening-Qualität in seiner eigenen aufsichtsrechtlichen Sprache formuliert.