Sanktionsscreening-Software auswählen: Checkliste für Einkauf und Implementierung

Die Auswahl einer Sanktionsscreening-Software ist eine Entscheidung über Kontrollgestaltung und Implementierung – kein Wettbewerb darum, welcher Anbieter mit den meisten Listen oder der höchsten Trefferquote wirbt.

Dieser Leitfaden setzt voraus, dass Ihre Organisation bereits bestimmt hat, warum sie prüft und welche Beziehungen, Parteien und Ereignisse in den Anwendungsbereich fallen können. Den zugrunde liegenden rechtlichen Rahmen und den Screening-Prozess erläutert der Praxisleitfaden zum Sanktionsscreening. Hier geht es darum, ob ein Anbieter Ihre Anforderungen umsetzen, das Systemverhalten nachweisen und ein kontrolliertes Betriebsmodell unterstützen kann.

Die empfohlene Beschaffungsabfolge lautet:

Anforderungen definieren → Nachweise anfordern → repräsentative Fälle testen → operative Eignung bewerten → Verantwortlichkeiten vereinbaren → Implementierung freigeben → Änderungen überwachen.

Beginnen Sie mit Ihrem Sanktionsrahmen und Ihren Anwendungsfällen

Erstellen Sie vor der Produktbewertung eine anbieterunabhängige Anforderungsmatrix.

„Globale Abdeckung“ beantwortet diese Fragen nicht. Die FATF setzt internationale Standards; konkrete Sanktionspflichten ergeben sich hingegen aus den jeweils anwendbaren Rechtsinstrumenten und ihrer nationalen oder regionalen Umsetzung.¹ Der Käufer bleibt dafür verantwortlich, den zutreffenden rechtlichen und operativen Geltungsbereich festzulegen.

Herkunft der Sanktionsdaten und Änderungsverarbeitung prüfen

Ein Anbieter sollte zu jedem Datensatz die erlassende Behörde und die konkret abgebildete Quelle benennen können. Fordern Sie ein aktuelles Quellenverzeichnis, ursprüngliche Quellen-IDs, Links zur erlassenden Behörde, Normalisierungsregeln und ein Beispiel an, das einen Anbieterdatensatz bis zum amtlichen Eintrag zurückverfolgt.

Testen Sie den Umgang mit:

• Ergänzungen, Änderungen und Löschungen;
• Aliasnamen, Identifikatoren und Feldern, die durch eine Quellenaktualisierung hinzukommen;
• Verzögerungen bei der Datenübernahme und der Erkennung ausgefallener Quellen;
• Veröffentlichungs-, Wirksamkeits- und Verarbeitungszeitpunkten, sofern verfügbar;
• Wiederholung oder Nachbearbeitung nach einem Vorfall; und
• historischen Nachweisen darüber, welche Quellenversion verwendet wurde.

Checklynx kontrolliert diesen Lebenszyklus durchgängig. Das System erfasst Neuzugänge, Änderungen und Entfernungen, erkennt Änderungen an Aliasnamen, Identifikatoren und weiteren Quellfeldern, protokolliert die Quellenverarbeitung, prüft die Konsistenz zwischen kanonischen Datensätzen und dem Suchindex und unterstützt eine kontrollierte Wiederholung oder Reparatur. Veröffentlichungs- und Wirksamkeitsdaten werden gespeichert, sofern die herausgebende Stelle sie bereitstellt.

OFAC und die Vereinten Nationen veröffentlichen eigene Listendaten; die Europäische Kommission stellt offizielle Ressourcen zu EU-Sanktionen bereit.²³⁴ Ein normalisierter Datensatz des Anbieters kann diese Quellen leichter nutzbar machen, darf ihre Herkunft jedoch nicht verschleiern.

Lassen Sie Aussagen zur Aktualisierungsgeschwindigkeit durch eine dokumentierte Leistungszusage und einen reproduzierbaren Test belegen, der die Zeit von der amtlichen Veröffentlichung bis zur Verfügbarkeit der prüfbaren Daten misst.

Namen, Aliasnamen, Identifikatoren und Fuzzy Matching testen

Das Matching sollte anhand der Personen, Unternehmen, Schriftsysteme und Datenqualität bewertet werden, die in Ihren eigenen Arbeitsabläufen vorkommen. Erstellen Sie einen kontrollierten Datensatz mit folgenden Testklassen:

OFAC beschreibt die eigene unscharfe Suche als Werkzeug zum Auffinden möglicher Treffer, nicht zur abschließenden Entscheidung.⁶ CySEC verwendete bei thematischen Prüfungen von Screening-Systemen der in ihren Aufsichtsbereich fallenden Unternehmen sowohl Kontroll- als auch manipulierte Datensätze, darunter Schreibfehler und veränderte oder fehlende Angaben.⁷

Der Proof of Concept sollte die geprüfte Konfiguration festhalten und erkennen lassen, weshalb ein Kandidat ausgegeben wurde. Eine einzelne prozentuale „Genauigkeits“-Angabe ist ohne Datensatz, Ground Truth, Schwellenwert, Grundgesamtheit und Berechnungsmethode nicht aussagekräftig.

Konfiguration, Ausschlüsse und False-Positive-Kontrollen bewerten

Es gibt keinen universell richtigen Schwellenwert. Das OFAC Compliance Framework verlangt, dass für interne Kontrollen eingesetzte Technologie angemessen zum Risikoprofil und Compliance-Bedarf der Organisation ausgewählt und kalibriert sowie regelmäßig getestet wird.⁸

Lassen Sie Anbieter Folgendes demonstrieren:

• Konfiguration nach Population, Quelle oder Arbeitsablauf, sofern unterstützt;
• Historie, Berechtigungen, Genehmigung und Rücknahme von Schwellenwertänderungen;
• Auswirkungen von Schwellenwertänderungen auf erwartete Kandidaten und Prüfvolumen;
• Prüferentscheidungen und erforderliche Begründungen;
• den exakten Geltungsbereich eines Ausschlusses oder einer Entscheidung zu wiederkehrenden Treffern; und
• die Aufhebung solcher Entscheidungen, wenn sich Quellen- oder Kundendaten ändern.

Ein Ausschluss sollte bedeuten, dass ein bestimmter Kandidat unter definierten Tatsachen geklärt wurde. Er darf nicht zur dauerhaften Behauptung werden, ein Kunde oder Name könne niemals sanktioniert werden.

Eigentum und Kontrolle vom Namensabgleich trennen

Ein unauffälliges Ergebnis beim Abgleich eines Unternehmensnamens belegt nicht, dass ein nicht gelistetes Unternehmen außerhalb sämtlicher Sanktionsbeschränkungen liegt. Eigentum und Kontrolle hängen vom anwendbaren Sanktionsregime und den Tatsachen ab.

OFAC behandelt ein Unternehmen als blockiert, wenn blockierte Personen direkt oder indirekt zusammen mindestens 50 % daran halten – auch wenn das Unternehmen nicht separat gelistet ist.⁹ Britische und EU-Ansätze müssen anhand ihrer jeweils anwendbaren Rechtsvorschriften und amtlichen Leitlinien bewertet werden; die OFAC-Regel ist keine globale Formel.¹⁰¹¹

Fragen Sie im Beschaffungsprozess, ob das System:

• eine bereits festgestellte Eigentümerstruktur aus vorgelagerten KYB- oder Kundendatensätzen übernehmen kann;
• direkte und indirekte Beziehungen sowie relevante Beteiligungsquoten darstellen kann;
• identifizierte wirtschaftlich Berechtigte und Kontrollpersonen mit Screening-Ergebnissen verknüpfen kann;
• den Eigentumspfad und die verwendeten Quellennachweise aufbewahrt;
• jurisdiktionsspezifische Regeln unterstützt, ohne die Berechnung zu verbergen; und
• unklare Kontrollfragen an qualifizierte Prüfer weiterleiten kann.

Das Screening eines bereits identifizierten wirtschaftlich Berechtigten ist nicht dasselbe wie dessen Ermittlung oder Verifizierung. Siehe Screening von UBOs und verbundenen Parteien sowie Sanktionsrechtliches Eigentum und Kontrolle zu diesen grundlegenden Abgrenzungen.

Alle Screening-Populationen und Arbeitsabläufe abbilden

Kaufen Sie nicht isoliert mehrere Werkzeuge, bevor Sie festgelegt haben, an welchen Stellen Screening in die Geschäftsprozesse eingebunden wird.

Der richtige Umfang der zu prüfenden Parteien hängt von den anwendbaren Pflichten, Produkten, der Risikobewertung und den internen Richtlinien ab. Das Screening von Transaktionsparteien unterscheidet sich zudem vom verhaltensbasierten Transaktionsmonitoring, das nach ungewöhnlichen Aktivitätsmustern sucht.

Anforderungen an API, Batch und Integration bewerten

Die Entwicklung sollte den aktuellen Vertrag bewerten, nicht nur ein Codebeispiel auf einer kommerziellen Seite.

Checklynx dokumentiert direkte, Batch-, Transaktions- und Kunden-Workflows in der aktuellen Entwicklerdokumentation. Die Seite zur Echtzeit-Screening-API erläutert den kommerziellen Arbeitsablauf; für aktuelle Vertragsdetails ist die Entwicklerdokumentation maßgeblich. Leiten Sie aus dem bloßen Vorhandensein einer API keine undokumentierte Sandbox, keinen Durchsatz und kein Servicelevel ab.

Fallmanagement und Audit-Nachweise prüfen

Eine überzeugende Demonstration sollte von der Kandidatenerstellung bis zur Entscheidung reichen und nicht bei einer API-Antwort enden.

Fragen Sie, ob ein anderer qualifizierter Prüfer später Folgendes rekonstruieren kann:

• die übermittelten Suchdaten und den Kunden- oder Transaktionskontext;
• den Quelldatensatz sowie die zu diesem Zeitpunkt verfügbaren Aliasnamen und Identifikatoren;
• Screening-Profil, Konfiguration und Zeitstempel;
• übereinstimmende und widersprüchliche Nachweise;
• Prüfer, Begründung, Notizen, Anhänge und Eskalation;
• ursprüngliches Ergebnis, abschließende Entscheidung und nachgelagerte Maßnahme; und
• spätere Änderungen, wiederaufgenommene Entscheidungen und Audit-Historie.

Aussagen zu Aufbewahrung, Hosting, Unveränderbarkeit, Verschlüsselung und Zertifizierungen benötigen gesonderte aktuelle Nachweise. Produktdemonstrationen sollten durch Vertrags- und Sicherheitsprüfungen ergänzt werden. Siehe Checklynx Fallmanagement und Audit-Trail und Nachweise für die relevanten Workflow-Funktionen.

Laufendes Re-Screening und Änderungsalarme prüfen

Fragen Sie genau, was eine neue Prüfung auslöst: eine Änderung der Sanktionsquelle, eine Aktualisierung von Kunden- oder Eigentumsdaten, ein definiertes Prüfereignis, ein richtlinienbasierter Rhythmus oder ein anderer Auslöser. Testen Sie anschließend, was mit früheren False-Positive-Entscheidungen und offenen Fällen geschieht.

Es gibt keinen universellen Rhythmus für jede Organisation und Population. Der Käufer sollte die Auslöser anhand der anwendbaren Anforderungen und seines Kontrolldesigns festlegen und anschließend prüfen, ob das Produkt sie umsetzen und nachweisen kann. Checklynx laufendes Monitoring unterstützt konfigurierte Re-Screening-Workflows; es sollte nicht als autonome Engine für verhaltensbasiertes Transaktionsmonitoring beschrieben werden.

Vor der Freigabe einen Proof of Concept durchführen

Vereinbaren Sie Datensatz, erwartete Ergebnisse und Abnahmekriterien, bevor die Anbieter die Ergebnisse sehen. So sinkt das Risiko, den Benchmark nachträglich anzupassen.

1. Beziehen Sie erwartete Kandidaten, echte Nichttreffer, manipulierte Varianten und mehrdeutige Datensätze ein.
2. Verwenden Sie die in der Produktion vorkommenden Schriftsysteme – darunter kyrillische, arabische und thailändische Schrift sowie weitere relevante Systeme – und testen Sie Suchen in Originalschrift und Transliteration.
3. Testen Sie verschiedene Schwellenwerte und berichten Sie Kandidatenabdeckung und Prüfvolumen getrennt.
4. Klären Sie ausgewählte Kandidaten und testen Sie Geltungsbereich und Aufhebung von Entscheidungen zu wiederkehrenden Treffern.
5. Testen Sie – soweit die Umgebung es zulässt – Ergänzung, Änderung und Entfernung von Quelldaten.
6. Prüfen Sie API-Fehler, Batch-Teilfehler, Wiederholungsversuche, Korrelation und Ereignis-Deduplizierung.
7. Rekonstruieren Sie einen abgeschlossenen Fall ausschließlich anhand der aufbewahrten Nachweise.
8. Dokumentieren Sie Konfiguration, Datensatzversion, erwartetes Ergebnis, tatsächliches Ergebnis und Beobachtung des Prüfers.

Implementierung und operative Verantwortung planen

Der Softwarekauf schließt die Kontrolle nicht ab. Benennen Sie vor dem Produktivbetrieb verantwortliche Stellen für rechtlichen Geltungsbereich, Quellenauswahl, Datenzuordnung, Konfiguration, Integration, Prüfbetrieb, Tests, Lieferantenmanagement und Änderungsgenehmigung.

Eine praktische Einführung sollte Folgendes umfassen:

• genehmigte Anforderungen und Quellenmatrix;
• produktionsnahe Datenzuordnung und Validierung;
• Ausgangs- oder Backfill-Plan, falls erforderlich;
• Genehmigung von Konfiguration und Zugriffsrechten;
• Regressionstests und dokumentierte Abnahmekriterien;
• parallele oder kontrollierte Einführung, soweit angemessen;
• Kapazitätsplanung für Warteschlangen, Eskalations- und Incident-Verfahren;
• Abstimmung fehlgeschlagener oder ausgebliebener Screening-Ereignisse; und
• regelmäßige Überprüfung nach Änderungen an Quellen, Modell, Produkt oder Richtlinien.

Das OFAC Framework verbindet Management Commitment, Risikobewertung, interne Kontrollen, Tests und Nachbesserung als Bestandteile eines wirksamen Sanktions-Compliance-Programms.⁸ Das konkrete Governance-Modell bleibt organisations- und regimespezifisch.

Käufercheckliste für Sanktionsscreening-Software

Verwenden Sie diese Fragen in einer Ausschreibung oder Beschaffungsarbeitsmappe.

Daten und rechtlicher Geltungsbereich

• Haben wir die für uns geltenden Behörden, Quellen, Populationen und Screening-Zeitpunkte dokumentiert?
• Kann der Anbieter jeden Datensatz bis zur erlassenden Behörde und Quellen-ID zurückverfolgen?
• Kann er Ergänzungen, Änderungen, Löschungen und die Behandlung fehlgeschlagener Datenübernahmen demonstrieren?
• Verwendet er die aktuelle UK Sanctions List anstelle der eingestellten OFSI Consolidated List?

Matching und Entscheidungen

• Haben wir Namen und Aliasnamen in allen relevanten Schriftsystemen, jeweils in Originalschrift und Transliteration, gemeinsam mit Identifikatoren getestet?
• Können Prüfer nachvollziehen, warum ein Kandidat zurückgegeben wurde?
• Werden Schwellenwerte, Berechtigungen und Änderungen versioniert und genehmigt?
• Sind Ausschlüsse eingegrenzt, belegt und werden sie aufgehoben, wenn sich relevante Tatsachen ändern?
• Unterscheidet der Arbeitsablauf zwischen Kandidaten, False Positives, bestätigten und ungeklärten Ergebnissen?

Beziehungen und Arbeitsabläufe

• Können übermittelte Eigentums- und Related-Party-Daten mit dem Kunden verknüpft bleiben?
• Vermeidet das Produkt, UBO-Screening als automatische UBO-Ermittlung darzustellen?
• Kann es Kunden-, Portfolio- und Transaktionsparteien-Workflows unterstützen, ohne sie gleichzusetzen?
• Können Fragen zu Eigentum und Kontrolle nach jurisdiktionsspezifischen Richtlinien eskaliert werden?

Integration und Betrieb

• Wurden API-, Batch-, Ereignis- und Abrufsemantiken anhand der aktuellen Dokumentation geprüft?
• Sind Grenzen, Testumgebungen, Wiederholungsversuche und Leistungszusagen dokumentiert statt nur angenommen?
• Können Fehler abgestimmt werden, ohne die Korrelation zwischen Geschäftsprozess und Screening zu verlieren?
• Können Analysten die vollständige Anfrage, das Quellenergebnis, die Prüfung und den Ausgang rekonstruieren?
• Sind Auslöser für laufendes Re-Screening und das Verhalten früherer Entscheidungen definiert?

Tests und Governance

• Wurden POC-Datensatz und Bewertungsmethode vorab vereinbart?
• Haben wir Kandidatenabdeckung und Prüfaufwand getrennt gemessen?
• Haben wir Datenänderungen, Fehler, Regression und historische Rekonstruktion getestet?
• Sind Kontrollverantwortliche, Genehmigungsrechte, Incident Response und Überwachung von Anbieteränderungen zugewiesen?
• Kann die Organisation erklären, warum die gewählte Konfiguration zu ihren eigenen Risiko- und Workflow-Anforderungen passt?

Wo Checklynx unterstützt

Checklynx kann Sanktionsscreening in Kunden-, Batch-, Transaktions- und konfigurierten Re-Screening-Workflows unterstützen, Ergebnisse mit der Fallprüfung verbinden und Nachweise zu Screening und Prüferentscheidungen aufbewahren. Seine Rolle besteht darin, Screening- und Workflow-Infrastruktur bereitzustellen; der Kunde definiert die anwendbaren Quellen, Parteien, Richtlinien, Einstellungen und abschließenden rechtlichen oder geschäftsbezogenen Entscheidungen.

Häufig gestellte Fragen

Was ist die wichtigste Funktion einer Sanktionsscreening-Software?

Es gibt keine universell wichtigste Einzelfunktion. Der Dienst muss zu den anwendbaren Quellen, Populationen, Daten, Matching-Anforderungen, Prüfprozessen, Integrationen und Nachweisanforderungen der Organisation passen.

Wie sollten Anbieter von Sanktionsscreening verglichen werden?

Vergleichen Sie dokumentierte Funktionen und führen Sie einen kontrollierten Proof of Concept mit repräsentativen Daten und vorab vereinbarten Ergebnissen durch. Bewerten Sie Kandidatenabdeckung, Arbeitsaufwand der Analysten, Erklärbarkeit, Arbeitsablauf, Integration und Rekonstruierbarkeit getrennt.

Ist Fuzzy Matching mit höherer Sensitivität immer besser?

Nein. Eine höhere Sensitivität kann mehr Varianten zurückgeben, aber auch den Prüfaufwand erhöhen. Kalibrieren und testen Sie die Einstellung anhand des Risikoprofils und der Daten Ihrer Organisation, statt einen universellen Schwellenwert zu wählen.

Löst Sanktionsscreening-Software Fragen zu Eigentum und Kontrolle?

Nicht allein durch Namensabgleich. Eigentum und Kontrolle erfordern ausreichende Beziehungsdaten und eine Analyse nach dem anwendbaren Sanktionsregime. Software kann Darstellung, Berechnung, Nachweis und Weiterleitung unterstützen; Funktionsumfang und rechtlicher Rahmen müssen jedoch geprüft werden.

Bedeutet ein Sanktionskandidat, dass der Kunde sanktioniert ist?

Nein. Ein Kandidat weist auf eine mögliche Ähnlichkeit mit einem Quelldatensatz hin. Identität, Eigentum und Kontrolle sowie die anwendbare rechtliche Wirkung bedürfen weiterhin einer angemessenen Prüfung.

Ist laufendes Sanktionsscreening dasselbe wie Transaktionsmonitoring?

Nein. Re-Screening prüft Parteien erneut, nachdem sich Quellen, Profile oder Richtlinien geändert haben. Verhaltensbasiertes Transaktionsmonitoring bewertet Aktivitätsmuster. Die Kontrollen können Informationen austauschen, sind aber nicht austauschbar.