Wie Software zur Sanktionslistenprüfung funktioniert: Ein Praxisleitfaden

Software zur Sanktionslistenprüfung ist die Erkennungsschicht eines Trade-Compliance-Programms. Sie übernimmt Datensätze zu Geschäftspartnern aus den Vorsystemen, normalisiert die relevanten Felder und gleicht diese gegen die Einträge der Prüflisten ab. Wo ein Abgleich einen Ähnlichkeitswert über der eingestellten Schwelle ergibt, erzeugt die Software einen Treffer.

Dieser Artikel beschreibt, wie das System in der Praxis läuft. Er behandelt die Eingaben, die die Software übernimmt, die Matching-Algorithmen, die sie anwendet, die Listen, gegen die sie prüft, die Ausgaben, die sie erzeugt, und die Punkte, an denen das System aufhört. Die Beschreibung ist mechanisch, sie soll die arbeitenden Teile für Compliance-Verantwortliche sichtbar machen, die die regulatorischen Einsätze bereits kennen.

Das System hat zwei verschiedene Flächen. Die erste erzeugt Treffer. Die zweite muss auf sie reagieren. Die meiste Ingenieursarbeit ist in die erste geflossen.

Was Software zur Sanktionslistenprüfung tut

Software zur Sanktionslistenprüfung ist eine Namensabgleich-Engine, die gegen einen Satz von Sanktions- und Beobachtungslisten läuft. Die Software übernimmt Datensätze, die Geschäftspartner beschreiben (Kunden, Lieferanten, Spediteure, Geschäftspartner, wirtschaftlich Berechtigte), normalisiert die relevanten Felder und gleicht diese gegen die Einträge der Prüflisten ab. Wo ein Abgleich einen Ähnlichkeitswert über der eingestellten Schwelle ergibt, erzeugt das System einen Treffer.

Die Prüfung kann in mehreren Modi laufen. Im Echtzeitmodus fängt die Software eine Transaktion ab, während sie in einem Vorsystem entsteht (ein Auftrag in SAP S/4HANA, ein Onboarding-Ereignis in einem CRM), und entscheidet, ob die Transaktion weiterlaufen darf. Im Stapelmodus läuft die Software periodisch gegen die gesamte Geschäftspartnerliste und markiert jeden Datensatz, der seinen Status geändert hat. Im Ad-hoc-Modus startet ein Bearbeiter eine einzelne Abfrage gegen die Datenbank für eine punktuelle Prüfung.

Die meisten Produktivinstallationen kombinieren Stapel- und Echtzeitprüfung, wobei der Stapel die Stammdaten-Grundlinie abdeckt und die Echtzeit die Änderungen am Transaktionspunkt. Ein Unternehmen, das 25.000 Treffer im Monat über mehrere Tochtergesellschaften bearbeitet, fährt meist alle drei Modi gegen Geschäftspartnerstämme aus mehreren Geschäftssystemen.

Die Software erzeugt Treffer. Ein Treffer ist der Hinweis, dass ein möglicher Treffer erkannt wurde und eine menschliche Prüfung verlangt. Die Entscheidung, ob der Treffer echt ist, die Dokumentation der Begründung und der revisionssichere Nachweis des Ergebnisses liegen außerhalb der Ausgabe des Tools. Das gehört zur Trefferbearbeitung, das, was wir Sanctions Resolution nennen, und die sitzt nachgelagert.

Was Software zur Sanktionslistenprüfung abgleicht

Der Abgleich läuft über mehrere Felder, doch das primäre Feld ist fast immer der Name. Adresse, Land, Geburtsdatum (bei Personen), Entitätstyp und Kennungen wie Registernummern können einbezogen werden, wo sie vorliegen, doch in den meisten Produktivinstallationen trägt das Namensfeld den Abgleich und die übrigen Felder dienen als Filter oder Verstärker. Die Architektur erlaubt eine breitere Feldnutzung, wo die Daten verlässlich genug sind, um sich auf sie zu stützen.

Namen sind unsaubere Daten. Dieselbe juristische Person kann in den Quelldatensätzen als „Volkswagen AG“, „VW AG“, „Volkswagen Aktiengesellschaft“ oder mit diakritischen Zeichen, Transliterationsvarianten, Abkürzungen und Teilschreibweisen auftauchen. Die Sanktionslisten selbst enthalten Alias-Einträge, „auch bekannt als“-Varianten und historische Namen. Der Algorithmus muss diese Oberflächenunterschiede überbrücken und dabei „Volkswagen AG“ weiterhin von einer rechtlich anderen Entität unterscheiden, die zufällig Zeichen teilt.

In einer typischen Screening-Plattform laufen mehrere Matching-Verfahren parallel. Exakte Abgleiche fangen die saubersten Fälle. Phonetische Algorithmen (Soundex, Metaphone) fangen einige schrift- und ausspracheabhängige Varianten. Editierdistanz-Algorithmen (Levenshtein, Damerau-Levenshtein, Jaro-Winkler) bewerten die Zahl der Einfügungen, Löschungen und Vertauschungen, die nötig sind, um eine Zeichenkette in eine andere zu überführen.

Token-basierte Algorithmen vergleichen Zeichenketten als Mengen von Teilketten statt als einzelne Token. Transliterationstabellen überführen nichtlateinische Schriften (Arabisch, Chinesisch, Kyrillisch, Koreanisch) in eine vergleichbare lateinische Form, bevor bewertet wird. Die meisten Produktivplattformen fahren mehrere dieser Verfahren zusammen und verbinden die Werte zu einem zusammengesetzten Ähnlichkeitswert, der dann gegen die eingestellte Schwelle verglichen wird.

Gegen welche Sanktionslisten die Software prüft

Die Listen selbst stammen aus mehreren regulatorischen Quellen. Die EU-Konsolidierte Liste, geführt vom Europäischen Auswärtigen Dienst, bündelt restriktive Maßnahmen, die der Rat der Europäischen Union im Rahmen der Gemeinsamen Außen- und Sicherheitspolitik verhängt. Die von OFSI geführte UK Sanctions List bildet den eigenständigen britischen Sanktionsrahmen nach dem European Union (Withdrawal) Act ab.

Die SDN-Liste des US-OFAC erfasst Entitäten, die unter US-Primärsanktionen gelistet sind, neben den sektoralen und Nicht-SDN-Listen, die OFAC für engere Zwecke veröffentlicht. Die Konsolidierte Liste des UN-Sicherheitsrats erfasst Listungen unter UN-Resolutionen. Nationale zuständige Behörden wie das BAFA in Deutschland oder De Nederlandsche Bank in den Niederlanden veröffentlichen in manchen Fällen ergänzende Listen.

Über die offiziellen Sanktionslisten hinaus werden häufig auch Beobachtungslisten geprüft: Listen politisch exponierter Personen, Adverse-Media-Listen, interne Sperrlisten, sektorale oder branchenspezifische Beobachtungslisten. Die Mechanik des Abgleichs läuft über diese Listenarten identisch, mit Unterschieden in der Datenqualität und Schwellenanpassungen auf der Konfigurationsebene.

Sanktionslisten werden in uneinheitlichen Formaten veröffentlicht. OFAC veröffentlicht XML- und CSV-Exporte der SDN- und konsolidierten Listen, mit weitgehend stabilen, aber periodisch erweiterten Feldstrukturen. Die EU-Konsolidierte Liste wird vom Europäischen Auswärtigen Dienst in XML veröffentlicht. Die UK Sanctions List wird vom britischen Finanzministerium in CSV und XML veröffentlicht.

Die UN-Konsolidierte Liste wird vom UN-Sicherheitsrat in XML veröffentlicht. Listen nationaler zuständiger Behörden und sektorale Listen variieren im Format weiter. Die Software muss all das übernehmen, in eine interne Darstellung normalisieren und aktuell halten, während die Listen sich ändern. Die Update-Frequenz reicht von täglich bis ad hoc, und die operative Anforderung lautet, dass die Prüfung gegen die jeweils neueste verfügbare Version jeder Liste läuft, auf die sie sich stützt.

Wie das Schwellenwert-Tuning das Trefferaufkommen beeinflusst

Die Schwelle ist die Variable, die das Trefferaufkommen bestimmt. Eine Schwelle von 90 Prozent Ähnlichkeit erzeugt weit weniger Treffer als eine von 75 Prozent, und eine höhere Schwelle übersieht zugleich Treffer, bei denen die Schreibweise auf der Liste vom Datensatz des Geschäftspartners um mehr als 10 Prozent der Zeichenkette abweicht. Der Kompromiss liegt zwischen False Positives am unteren Ende der Schwelle und übersehenen Listungen am oberen.

Ein Unternehmen, das bei einer Schwelle von 90 Prozent 500 Treffer im Monat bearbeitet, landet bei 85 Prozent vielleicht bei 1.500 und bei 80 Prozent bei 4.000. Die genauen Zahlen hängen von den Eingaben ab, doch die Kurve ist am unteren Ende steil. False-Positive-Quoten von 80 Prozent oder mehr sind in handelsintensiven Unternehmen üblich, und die Reduktion von False Positives ist einer der größten operativen Hebel eines Compliance-Programms.

Eine vertretbare, wenn auch umstrittene Position lautet: Schwellenwert-Tuning tauscht jenseits eines bestimmten Punktes False-Positive-Reduktion gegen Erkennungsrobustheit, auf eine Weise, die die meisten Programme nicht messen. Die Instrumentierung, um Erkennungsrobustheit zu messen, ist schwerer zu bauen als die, um False-Positive-Mengen zu messen. Das Volumen ist jeden Tag in der Trefferwarteschlange sichtbar. Erkennungsversagen wird nur in den seltenen Fällen sichtbar, in denen eine gelistete Entität durchrutschte und von einer nachgelagerten Kontrolle, einem Audit oder einer behördlichen Maßnahme gefangen wurde.

Programme justieren auf das, was sie sehen, und was sie sehen, ist Volumen. Das Ergebnis ist eine stetige Drift zu Schwellen, die die Trefferlast minimieren und dabei nach und nach die Fähigkeit des Programms aushöhlen, Listungen zu fangen, die außerhalb der sich verengenden Komfortzone des Algorithmus liegen.

Wie die Software aus den Vorsystemen liest

Die Daten, aus denen die Software liest, sind selten so sauber, wie die Abgleichlogik annimmt. Geschäftspartnerdaten liegen in ERP-Systemen, CRM-Systemen, Lieferantenmanagementsystemen, Onboarding-Strecken und Handelsfinanzierungssystemen. Jedes bringt seine eigene Feldstruktur mit, eigene Konventionen für Firmenzusätze, eigene Adressfeldbehandlung und eigene Datenqualitätshistorie.

Ein Unternehmen, das 25.000 Treffer im Monat über mehrere Tochtergesellschaften bearbeitet, prüft meist gegen einen Geschäftspartnerstamm, der aus mehreren Vorsystemen zusammengesetzt ist, jedes mit anderen Feldlayouts und unterschiedlichem Alter der letzten Datenaktualisierung. Die Software nimmt alles an und führt den Abgleich trotzdem durch. Wo Daten auf Feldebene unvollständig sind (kein Land, kein Entitätstyp, keine Registernummer), fällt der Abgleich auf das Namensfeld allein zurück.

Dieser Rückfall ist die Situation mit den höchsten False-Positive-Quoten. Das Namensfeld allein trägt die wenigste Information und die kleinste unterscheidende Fläche. Mehr Datenfelder zur Prüfzeit in den Abgleich zu nehmen (eine bestätigte Jurisdiktion, ein bestätigter Entitätstyp, eine Registernummer) würde das Mengenprofil erheblich verschieben, weil der Algorithmus viele Kandidaten ausschließen könnte, die dem Namen nach ähnlich aussehen, sich aber in anderen Eingabevariablen unterscheiden.

Der Grund, warum die meisten Produktivinstallationen nicht so arbeiten, liegt in der Ökonomie der Vorsysteme. Die ERP-Integration, die saubere Felddaten neben dem Namen liefern müsste, war teurer als Schwellenwert-Tuning, also wurde Schwellenwert-Tuning zum Weg des geringsten operativen Widerstands. Der Markt könnte sich in diese Richtung bewegen, je größer das Mengenproblem wird, doch der Weg ist in der Breite noch nicht etabliert.

Was Software zur Sanktionslistenprüfung ausgibt

Die primäre Ausgabe ist der Treffer. Ein Treffer enthält meist den abgeglichenen Datensatz von der Geschäftspartnerseite, den abgeglichenen Eintrag von der Listenseite, den Ähnlichkeitswert, den oder die Algorithmen, die den Treffer erzeugten, und Metadaten, die den Prüflauf und das Quellsystem benennen.

Je reicher die Treffernutzlast, desto schneller kann der Analyst triagieren. Manche Plattformen zeigen den Ähnlichkeitswert und die Algorithmusspur; andere zeigen nur das abgeglichene Namenspaar und einen binären Treffer-Indikator. Der Unterschied entscheidet, ob der Analyst ein klares False Positive in Sekunden erkennt oder den Treffer von Grund auf neu rekonstruieren muss.

Neben einzelnen Treffern erzeugt die Software operative Kennzahlen: Trefferaufkommen pro Periode, Treffer pro Liste, False-Positive-Quoten über die Zeit und Indikatoren zur Warteschlangentiefe. Diese Kennzahlen treiben die Gespräche über Schwellenwert-Tuning, die Compliance-Teams mit ihrem Anbieter führen. Sie treiben auch die Bewertungskriterien, die Einkaufsteams anlegen, wenn sie Anbieter gegeneinander prüfen.

Häufig liegen die Resolution-Nachweise außerhalb der Ausgabe der Software. Das Tool zeigt an, dass ein Treffer existiert. Die Schlüsse, die ein Analyst zieht, die Belege, die diese Schlüsse stützen, und die Form, in der eine Behörde drei Jahre später die Dokumentation sieht, werden größtenteils außerhalb der Plattform zusammengesetzt. Die meisten Programme bauen den Resolution-Nachweis über Screenshots, Tabellen und Fallmanagement-Tools, die nie für Sanktionsarbeit entworfen wurden.

Wo das Tool aufhört

Das Tool hört beim Treffer auf. Die Arbeit nach dem Treffer ist Untersuchung, Entscheidung und Dokumentation, und diese Arbeit läuft auf Menschen, Browsern, Registern und Netzlaufwerken statt auf der Plattform selbst. Der Untersuchungsablauf ist im handelsintensiven Industriesektor weitgehend manuell.

Ein klares False Positive kostet drei bis sieben Minuten in der Freigabe. Ein unklarer Treffer dreißig Minuten bis eine Stunde, manchmal länger. Bei einem vollkostenbasierten Analystensatz von 45 Euro pro Stunde und einem Volumen von 3.000 Treffern im Monat bei einer False-Positive-Quote von 80 Prozent liegt der monatliche Zeitaufwand zwischen 200 und 400 Analystenstunden.

Die Plattform spielte ihren Teil bei der Erkennung des Treffers. Die 200 bis 400 Stunden laufen auf Ressourcen, die außerhalb der Plattform liegen.

Die Prüfungssicherheit sitzt an derselben Stelle. Der Prüfer richtet den Blick darauf, was das Team zu einem Treffer schloss, warum dieser Schluss fiel und auf welchen Belegen. Laut OFACs Übersicht der jüngsten Maßnahmen verzeichnete die Behörde 2023 Vergleiche und Strafen über rund 1,5 Milliarden US-Dollar, und die Maßnahmen, die nichtfinanzielle Industrieunternehmen betreffen, sind über die letzten drei Jahre gewachsen.

Die in diesen Maßnahmen genannten Strafen folgen häufiger Versäumnissen in der Resolution-Qualität als Erkennungsversagen: schlechte Dokumentation, inkonsistente Entscheidungslogik, fehlende Eskalationswege und Lücken zwischen dem, was untersucht wurde, und dem, was sich auf behördliche Anforderung rekonstruieren ließ.

Wie ein Screening-Programm in der Praxis läuft

Das Bild über die meisten handelsintensiven Industrieunternehmen hinweg ist beständig. Die Plattform ist ausgereift: ein Anbieterprodukt, konfiguriert gegen die großen Sanktionslisten und einen Satz interner Beobachtungslisten, im Stapel- und Echtzeitmodus laufend gegen Geschäftspartnerstämme aus mehreren Vorsystemen. Die Schwelle ist über die Zeit justiert worden, oft über mehrere Zyklen anbietergeführter Anpassung, und erzeugt ein stabiles monatliches Trefferaufkommen, gegen das das Team zu besetzen gelernt hat.

Die False-Positive-Quoten laufen hoch. Das Team hat Protokolle für die häufigsten False-Positive-Muster etabliert und gibt diese schnell frei. Die übrigen Treffer (die unklaren) binden den Großteil der Untersuchungszeit pro Treffer und erzeugen den Großteil der Varianz in der Untersuchungsqualität über das Team hinweg.

Die Untersuchungsarbeit läuft auf Analysten. Analysten öffnen Treffer im Tool, lesen das abgeglichene Namenspaar, verlassen dann das Tool und setzen den Rest der Untersuchung in anderen Systemen zusammen. Handelsregisterportale, Nachrichtensuchen, interne Sperrlistenprüfungen, Behördenveröffentlichungen für Listungsdetails, gelegentliche Abfragen in kostenpflichtigen Datenbanken für Eigentümerstrukturen.

Die Untersuchung erzeugt eine Entscheidung und eine Fallnotiz. Die Fallnotiz wird in dem Fallmanagementsystem festgehalten, das das Programm nutzt, sei es das mitgelieferte Modul des Tools, eine separate Compliance-Plattform, ein Ticketsystem oder ein Netzlaufwerk. Die Dokumentationsqualität schwankt über diese Kanäle erheblich.

Die Erkennungsschicht ist heute der reifste Teil des Trade-Compliance-Technologiestapels. Die verbleibende Schwankung in der Qualität der Compliance-Programme sitzt in der Resolution-Schicht, und dort konzentriert sich das meiste Audit-Risiko und der meiste operative Aufwand. Das Tool erzeugt den Treffer. Was mit diesem Treffer geschieht, bestimmt, wie das Compliance-Programm unter behördlicher Prüfung aussieht, und dieser Teil läuft auf Menschen, manuellem Zusammentragen von Kontext und Fallnotizen, verstreut über die Systeme, die das Programm zusammengestückelt hat.