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.

Sobald vergleichbare Anforderungen und Angebote vorliegen, hilft der Kostenvergleich für Sanktionsscreening-Software, Abrechnungseinheiten, enthaltene Leistungen und Implementierungskosten auf eine gemeinsame Grundlage zu bringen.

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 Prüfprozess 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.

Eigenentwicklung, Einkauf und Auslagerung eindeutig abgrenzen

Die Entscheidung zwischen Eigenentwicklung und Einkauf ist keine einfache Entweder-oder-Frage. Vor dem Vergleich der Betriebsmodelle sind vier Ebenen getrennt zu betrachten:

Die Modelle sollten präzise bezeichnet werden. Intern entwickelt bedeutet, dass die Organisation die Anwendung entwickelt und betreibt. Bei selbst betriebener Drittsoftware läuft lizenzierte Technologie in der Umgebung der Organisation. Einen gehosteten Anbieterdienst betreibt der Anbieter. Ein betreuter Analystendienst stellt Personal für klar definierte Prüfaufgaben bereit und ist nicht mit Software gleichzusetzen. Ein hybrides Modell kombiniert interne und externe Bestandteile.

Keine dieser Bezeichnungen belegt die Wirksamkeit der Kontrolle. Für jedes Modell sind Nachweise zu Datenherkunft, Abgleichsverhalten, Zugriffskontrolle, Verfügbarkeit, Fehlererkennung, Änderungsmanagement, Prüfqualität und Rekonstruktion von Entscheidungen anzufordern. Für eine Eigenentwicklung sollte derselbe Nachweisstandard gelten wie für ein Anbieterprodukt.

Für Unternehmen im Anwendungsbereich von FCA SYSC 8 beseitigt eine Auslagerung weder ihre aufsichtsrechtlichen Pflichten noch ihre Verantwortung für die ausgelagerte Tätigkeit.² Dies ist branchenspezifisches FCA-Material und kein allgemeingültiges Gesetz zur Auslagerung von Sanktionskontrollen. DORA regelt für erfasste Finanzunternehmen in der EU gesondert IKT-Risiken einschließlich Risiken durch IKT-Drittdienstleister. Es handelt sich um ein Rahmenwerk zur digitalen operationellen Resilienz, nicht um Sanktionsrecht.³

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

Lassen Sie Anbieter zeigen, wie sie Identitätsinformationen aus zusammengehörigen Datensätzen verschiedener Quellen nutzen, wenn ein einzelner Datensatz unvollständig ist. Testen Sie einen Fall, in dem eine Quelle kein Geburtsjahr enthält, zuverlässig verknüpfte Datensätze jedoch schon. Prüfen Sie, ob der gemeinsame Kontext irrelevante Kandidaten reduziert, ohne fehlende Angaben als Widerspruch zu behandeln.

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

Eine ausführliche Kalibrierungsmethode mit Testmatrix und Kennzahlen zum Prüfaufwand finden Sie im Leitfaden Falsch positive Treffer bei Sanktionsprüfungen reduzieren.

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 Prüfgruppe, Quelle oder Prüfablauf, 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 Prüfgruppen und Geschäftsabläufe abbilden

Kaufen Sie nicht isoliert mehrere Werkzeuge, bevor Sie festgelegt haben, an welchen Stellen die Sanktionsprüfung 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. Die Prüfung 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 Kundenprozesse 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.

Fallbearbeitung und Prüfnachweise bewerten

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;
• Prüfprofil, 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, erneut geprüfte Entscheidungen und die Änderungshistorie.

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. Die Checklynx-Seiten zu Fallmanagement und Prüfspur und Nachweisen beschreiben die relevanten Funktionen des Prüfprozesses.

Laufende Wiederholungsprüfungen und Änderungshinweise bewerten

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 jede Prüfgruppe. 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 Abläufe zur erneuten Prüfung; es sollte nicht als autonomes System 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;
• Plan für die Erstprüfung oder nachträgliche Bestandsprüfung, falls erforderlich;
• Genehmigung von Konfiguration und Zugriffsrechten;
• Regressionstests und dokumentierte Abnahmekriterien;
• parallele oder kontrollierte Einführung, soweit angemessen;
• Kapazitätsplanung für Warteschlangen sowie Eskalations- und Störungsverfahren;
• Abstimmung fehlgeschlagener oder ausgebliebener Prüfereignisse; und
• regelmäßige Überprüfung nach Änderungen an Quellen, Modell, Produkt oder Richtlinien.

Das OFAC Framework verbindet die Unterstützung durch die Leitung, Risikobewertung, interne Kontrollen, Tests und Nachbesserung als Bestandteile eines wirksamen Sanktions-Compliance-Programms.¹⁰ Das konkrete Modell für Zuständigkeiten und Aufsicht bleibt organisations- und regimespezifisch.

Bei einer Eigenentwicklung muss der Käufer die erforderlichen Nachweise selbst erbringen. Bei selbst betriebener Drittsoftware, gehosteten, verwalteten oder hybriden Modellen ist festzulegen, wer jede Kontrolle bereitstellt, wer sie testet und wer das Ergebnis abnimmt. Ein Vertrag kann Aufgaben zuweisen; er belegt allein jedoch nicht die Wirksamkeit der Kontrolle.

Modell anhand bedingter Eignungsfaktoren auswählen

Es gibt kein allgemeingültig bestes Modell. Die Optionen sind anhand der Bedingungen zu vergleichen, die die Organisation belegen kann:

Sobald vergleichbare Architekturen und Angebote vorliegen, kann der Leitfaden zu den Kosten von Sanktionsscreening-Software genutzt werden. Aus der Modellbezeichnung allein dürfen keine Aussagen zu Kosten, Lieferzeit, Personalbedarf, Genauigkeit oder einer Rentabilitätsschwelle nach Volumen abgeleitet werden.

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, zu prüfenden Parteien und Prüfzeitpunkte 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 Prüfablauf zwischen möglichen Treffern, falsch positiven Treffern sowie bestätigten und ungeklärten Ergebnissen?

Beziehungen und Arbeitsabläufe

• Können übermittelte Eigentumsdaten und Angaben zu verbundenen Parteien mit dem Kunden verknüpft bleiben?
• Vermeidet das Produkt, UBO-Screening als automatische UBO-Ermittlung darzustellen?
• Kann es Kunden-, Portfolio- und Transaktionsparteienprozesse unterstützen, ohne sie gleichzusetzen?
• Können Fragen zu Eigentum und Kontrolle nach den Vorgaben der jeweiligen Rechtsordnung 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 Zuordnung zwischen Geschäftsprozess und Prüfung zu verlieren?
• Können Analysten die vollständige Anfrage, das Quellenergebnis, die Prüfung und den Ausgang rekonstruieren?
• Sind Auslöser für laufende Wiederholungsprüfungen und der Umgang mit früheren Entscheidungen definiert?

Tests und Zuständigkeiten

• 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 Verantwortliche für die Kontrolle, Genehmigungsrechte, Störungsbehebung und die Überwachung von Anbieteränderungen festgelegt?
• Kann die Organisation erklären, warum die gewählte Konfiguration zu ihren eigenen Risiko- und Prozessanforderungen passt?

Wo Checklynx unterstützt

Checklynx kann Sanktionsprüfungen für Kunden, Bestände und Transaktionsparteien sowie konfigurierte Wiederholungsprüfungen unterstützen. Ergebnisse lassen sich mit der Fallbearbeitung verbinden; Nachweise zu Prüfungen und Entscheidungen bleiben erhalten. Checklynx stellt dafür die technische Infrastruktur und Fallbearbeitung bereit. 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, zu prüfenden Parteien, Daten, Abgleichsanforderungen, 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 die Abdeckung erwarteter Treffer, den Prüfaufwand, die Nachvollziehbarkeit, den Prüfablauf, die Integration und die Rekonstruierbarkeit getrennt.

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

Nein. Eine höhere Sensitivität kann mehr Varianten finden, aber auch den Prüfaufwand erhöhen. Die Einstellung sollte anhand des Risikoprofils und der Daten Ihrer Organisation kalibriert und getestet werden, 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.

Sollte Sanktionsscreening intern entwickelt oder bei einem Anbieter eingekauft werden?

Das hängt vom rechtlichen und operativen Geltungsbereich der Organisation, ihren internen Fähigkeiten, Vorgaben für Daten und Hosting, dem erforderlichen Anpassungsgrad, ihrem Modell für Ausfallsicherheit und ihrer Fähigkeit zur vollständigen Nachweisführung ab. Software, Sanktionsdaten, Prüfbetrieb und rechtliche Verantwortung sollten getrennt verglichen werden, statt Eigenentwicklung und Einkauf als einfache Entweder-oder-Entscheidung zu behandeln.

Wird mit dem Kauf von Sanktionsscreening-Software die Compliance-Verantwortung ausgelagert?

Nein. Ein Anbieter kann Technologie, Daten und vereinbarte operative Unterstützung bereitstellen. Der Käufer bleibt jedoch dafür verantwortlich, den anwendbaren Geltungsbereich festzulegen, die Kontrolle zu genehmigen und autorisierte rechtliche oder geschäftsbezogene Entscheidungen zu treffen. Für bestimmte regulierte Unternehmen können zusätzliche Auslagerungsvorgaben gelten.