Sanktionsscreening-Software wechseln: Kontrollplan für die Migration

Dieser Leitfaden richtet sich an Organisationen, die bereits Software zur Sanktionsprüfung einsetzen und dieses System ersetzen oder wesentlich verändern. Geht es zunächst um die Produktauswahl, dient der Leitfaden Software für Sanktionsprüfungen auswählen als Ausgangspunkt.

Die Frage bei der Migration lautet anders:

Können wir von der bestehenden Kontrolle in den genehmigten Zielzustand wechseln, ohne Prüfgruppen, laufende Überwachung, Untersuchungskontext oder Nachweise zu verlieren?

Aufsichtsfeststellungen der FCA liefern Beispiele aus dem britischen Regulierungsumfeld: Historische Anbietereinstellungen können ohne ausreichende Prüfung fortbestehen, Übertragungen zwischen Systemen können Datenfehler verursachen und fehlgeschlagene Integrationen mit Altsystemen können dazu führen, dass Tätigkeiten ungeprüft bleiben.¹ Dies sind Aufsichtsfeststellungen, keine allgemeingültige Migrationsmethode.

Den Wechsel als Änderung der Kontrolle behandeln

Eine neue Plattform kann einen Proof of Concept bei der Beschaffung bestehen und nach der Einführung dennoch versagen. Gründe können falsch zugeordnete Felder, eine ausgelassene Prüfgruppe, unbeabsichtigt verändertes Abgleichsverhalten, verlorene Einträge der laufenden Überwachung oder nicht mehr rekonstruierbare frühere Entscheidungen sein. Die Migration muss daher Compliance-Kontrolle, Daten und Konfiguration, Betrieb und Nachweise sowie technische Kontinuität erfassen – nicht nur die Bereitstellung der Anwendung.

Für Unternehmen im Anwendungsbereich von FCA SYSC 8 verbleibt die Verantwortung nach den Auslagerungsregeln beim Unternehmen. Die Regeln behandeln außerdem Aufsicht, Zugriff, Kontinuität und Beendigung.² Dies ist ein abgegrenztes britisches Aufsichtsbeispiel, keine Regel für jede Organisation weltweit.

Den genehmigten Ist-Zustand erfassen

Vor der Planung der Übertragung ist zu dokumentieren, wie das bestehende System tatsächlich arbeitet. Der Ist-Zustand darf nicht allein aus dem Vertrag oder einer allgemeinen Anbieterbeschreibung abgeleitet werden.

Zu erfassen sind:

• anwendbarer rechtlicher und operativer Prüfumfang sowie genehmigte amtliche Quellen;
• Kunden, Unternehmen, Eigentümer, Gegenparteien und andere Prüfgruppen, die in die Kontrolle gelangen;
• Ereignisse bei Onboarding, Zahlungen, Änderungen und erneuten Prüfungen;
• dauerhafte Personen- oder Unternehmenskennungen und die dafür führenden Systeme;
• an die Prüfung übermittelte Felder und vor dem Abgleich angewandte Transformationen;
• Abgleichskonfiguration, Ausschlüsse und Entscheidungsstatus;
• Abhängigkeiten von API, Batch-Prüfung, Prüfportal, Warteschlangen und laufender Überwachung;
• aufbewahrte Nachweise zu Prüfläufen und Untersuchungen.

Wenn der zugrunde liegende Umfang selbst neu bewertet werden muss, hilft der Praxisleitfaden zur Sanktionsprüfung. Der vorliegende Migrationsleitfaden setzt voraus, dass eine benannte Stelle für diesen rechtlichen und operativen Umfang verantwortlich ist.

Die bestehende Kontrolle dem Zielzustand zuordnen

Jedes Element des Ist-Zustands braucht eine genehmigte Behandlung im Zielzustand. „Von beiden Anbietern unterstützt“ reicht nicht: Gleichlautende Bezeichnungen oder Schwellenwerte können zu unterschiedlichem Verhalten führen.

Stabile interne Kennungen sind wichtig. Eine veränderliche Namenszeichenfolge ist kein verlässlicher Verknüpfungsschlüssel für einen exportierten Datensatz, seinen Überwachungsstatus, frühere Entscheidungen und den Fallverlauf.

Alte Entscheidungen nicht ungeprüft übernehmen

Eine frühere Entscheidung zu einem falsch positiven Treffer oder ein Ausschluss beruhte auf bestimmten Quelldaten, Identifikatoren, Abgleichsregeln und Nachweisen des Analysten. Eine andere Prüfsoftware kann Datensätze anders zusammenführen, andere Identifikatoren anzeigen oder ein anderes Entscheidungsmodell verwenden.

Für jede Entscheidungsklasse ist eine genehmigte Behandlung festzulegen: erneut prüfen, in einen gleichwertigen kontrollierten Status des Zielsystems übernehmen, als historischen Nachweis aufbewahren oder mit dokumentierter Begründung ausmustern. Die ausführliche Gestaltung von Ausschlüssen und Schwellenwerten behandelt der Leitfaden falsch positive Treffer bei Sanktionsprüfungen reduzieren.

Offene Untersuchungen benötigen eine klare Zuständigkeit. Ein Fall darf nicht verschwinden, weil das bestehende System keine neuen Aufgaben mehr annimmt, bevor das Zielsystem bereitsteht. Für jeden Fall ist festzulegen, ob er im alten System abgeschlossen, im neuen Prüfprozess neu angelegt oder nach dem genehmigten Nachweisplan mit Lesezugriff aufbewahrt wird.

Laufende Überwachung während der Umstellung sichern

Überwachte Prüfgruppe, dauerhafte Kennungen, aktivierte Quellen und letzter erfolgreicher Prüfzeitpunkt sind abzugleichen. Zu dokumentieren sind das letzte erfolgreiche Ereignis im bestehenden und das erste erfolgreiche Ereignis im Zielsystem. Quellenänderungen zwischen diesen Zeitpunkten müssen berücksichtigt werden. Außerdem ist festzulegen, wie fehlgeschlagene oder doppelte Datensätze abgestimmt werden und wer die Umstellung bei abweichenden Zahlen anhalten darf.

Laufende Überwachung ist eine Funktion des Zielzustands, kein Beleg für einen vollständigen Übergang.

Migrationsabnahme und unerklärte Unterschiede testen

Mit produktionsnahen Daten und bekannten erwarteten Fällen sind Quellen, Datenzuordnung, Abgleich, Weiterleitung, Einträge der laufenden Überwachung, Fehlerbehandlung und aufbewahrte Nachweise zu testen. Der Abschnitt zu Tests der produktiven Kontrolle erläutert den umfassenderen Prüfauftrag. Der Migrationsplan sollte sich auf Unterschiede zwischen altem und neuem System konzentrieren.

Ergebnisse sollten nach Klassen verglichen und nicht in einem einzigen allgemeinen Prozentsatz für „Genauigkeit“ verborgen werden:

• erwartete mögliche Treffer, die gefunden oder nicht erkannt wurden;
• unauffällige oder bekannte Nichttreffer, die neuen Prüfaufwand erzeugen;
• abgewiesene, gekürzte oder anders transformierte Datensätze;
• frühere Entscheidungen, die nicht mehr eindeutig anwendbar sind;
• überwachte Personen, Unternehmen oder Quellen, die in einem der beiden Systeme fehlen;
• Trefferhinweise und Fälle, die an die falsche Warteschlange geleitet werden;
• Nachweise, die sich nicht rekonstruieren lassen.

Ein Parallelbetrieb kann Unterschiede sichtbar machen, wenn er angemessen und technisch sinnvoll ist. Er ist jedoch nicht allgemein vorgeschrieben und benötigt keine willkürlich festgelegte Dauer. Unerklärte Abweichungen sind zu untersuchen; beide Systeme müssen nicht zwangsläufig identische Ergebnisse liefern.

Umstellung, Rückkehr zum Altsystem und Vorfälle steuern

Festzulegen sind die für die Abnahme zuständige Stelle, offene Ausnahmen, die Reihenfolge der Umstellung und der letzte Zeitpunkt, zu dem eine Rückkehr zum Altsystem noch sicher möglich ist. Für Integrationsfehler, Probleme mit Quelldatenströmen, abgewiesene Datensätze, Überwachungslücken, ausgefallene Warteschlangen und Nachweisprobleme sind Zuständigkeiten zu bestimmen.

Ein zweckmäßiger Umstellungsnachweis enthält:

• genehmigte Konfiguration und Quellenstand;
• abgestimmte Anzahl der Datensätze und Einträge der laufenden Überwachung;
• offene Ausnahmen und kompensierende Kontrollen;
• letzten Verarbeitungspunkt des bestehenden und ersten des Zielsystems;
• verantwortliche Freigabe, Zeitstempel und Kriterien für die Rückkehr zum Altsystem;
• Prüfungen nach der Umstellung und gegebenenfalls erforderliche Nachverarbeitung.

Eine unterbrechungsfreie Migration sollte nicht versprochen werden, wenn das tatsächliche Kontrollziel eine erkennbare und nachvollziehbar abgestimmte Kontinuität ist.

Das bestehende System schließen, ohne Nachweise zu verlieren

Vor Vertragsende ist zu bestätigen, welche Daten in welchem Format, bis wann und mit welchen Metadaten exportiert werden können. Der Zugriff auf historische Prüfläufe, Fälle, Anlagen und Begründungen ist nach der operativen Umstellung zu testen.

Die Aufbewahrung richtet sich nach den anwendbaren rechtlichen, regulatorischen, vertraglichen und internen Vorgaben. Es gibt keine allgemeingültige Aufbewahrungsfrist für Sanktionsprüfungen. Zu dokumentieren sind der künftige Speicherort der Nachweise, die zugriffsberechtigten Personen, die Unterstützung offener Untersuchungen sowie die vertraglich erforderlichen Nachweise über Löschung oder Rückgabe.

Der Leitfaden zur Untersuchung von Sanktionstreffern erläutert die Nachweise, die einen möglichen Treffer mit Identität, Eigentums- und Kontrollanalyse und abschließender Maßnahme verbinden. Die Migration muss diese Trennung bewahren; der Import einer bloßen Statusbezeichnung reicht nicht.

Wo Checklynx unterstützt

Nach der Festlegung von Zielzustand und Abnahmekriterien ist zu prüfen, ob die Sanktionsprüfung mit Checklynx zum genehmigten Migrationsplan passt. Checklynx unterstützt Prüfungen über Portal, CSV-Batch und Echtzeit-API sowie konfigurierte laufende Überwachung, Fallprüfung und Prüfnachweise.

Checklynx bietet Migrationsplanung und Unterstützung bei der Umsetzung ohne zusätzliche Kosten. Der Leistungsumfang wird anhand des bestehenden Systems, der verfügbaren Exporte, der erforderlichen Integrationen und des vereinbarten Implementierungsplans festgelegt.

Diese Funktionen bedeuten nicht, dass Checklynx jeden Export des bestehenden Systems automatisch konvertiert, das Verhalten einer anderen Prüfsoftware nachbildet, jeden historischen Fall importiert oder eine unterbrechungsfreie Migration garantiert. Der Kunde bleibt für Prüfumfang, Datenzuordnung, Abnahme, rechtliche Analyse und Entscheidungen der zuständigen Stelle verantwortlich.

Häufig gestellte Fragen

Wie unterscheidet sich der Wechsel der Sanktionsscreening-Software von der Anbieterauswahl?

Bei der Auswahl wird das künftige Produkt definiert und bewertet. Die Migration steuert den Übergang von einem bestehenden Produktivsystem zum genehmigten Ziel, ohne Prüfgruppen, laufende Überwachung, Entscheidungen oder Nachweise zu verlieren. Beide Aufgaben sollten miteinander verknüpft sein, sich aber nicht inhaltlich wiederholen.

Sollten altes und neues Sanktionsscreening-System parallel betrieben werden?

Ein Parallelbetrieb kann sinnvoll sein, wenn er angemessen ist und die Ergebnisse sachgerecht abgestimmt werden können. Er ist keine allgemeingültige regulatorische Pflicht. Bei nicht gleichwertigen Prüfverfahren sind identische Ergebnisse nicht zu erwarten. Zweck, Abnahmekriterien, Zuständigkeit für Ausnahmen und Abbruchbedingung sind festzulegen.

Können frühere Entscheidungen zu falsch positiven Treffern in das neue System übernommen werden?

Möglicherweise, wenn das Zielsystem einen gleichwertigen kontrollierten Status unterstützt und die Entscheidung anhand der relevanten Quelle, Identitätsnachweise und des Abgleichskontexts weiterhin vertretbar ist. Ausschlüsse dürfen nicht ungeprüft kopiert werden. Jede Klasse ist nach einer genehmigten Regel erneut zu prüfen, zu übernehmen, zu archivieren oder auszumustern.

Was geschieht bei der Migration mit offenen Sanktionstrefferhinweisen?

Jeder offene Trefferhinweis oder Fall benötigt vor der Umstellung ein Ziel: Abschluss im bestehenden System, Neuanlage im Zielsystem, soweit unterstützt, oder Aufbewahrung mit kontrolliertem Zugriff und klarer Zuständigkeit. Das Verzeichnis ist nach der Migration abzugleichen.

Bestätigt eine erfolgreiche Migration die Wirksamkeit des Sanktionsprogramms?

Nein. Die Migrationsabnahme kann zeigen, dass festgelegte Prüfgruppen, Quellen, Integrationen und Prozesse wie vorgesehen übertragen wurden. Sie belegt weder Identität noch Eigentum oder Kontrolle, rechtlichen Anknüpfungspunkt, Genehmigung, Meldung oder jede abschließende Sanktionsentscheidung.