Technische Abnahmekriterien für Sanktionsprüfungssoftware 2026
Diese Checkliste dient Compliance-, Risiko-, Sicherheits- und Entwicklungsteams als technische Abnahme eines Screening-Ablaufs in ihrer eigenen Umgebung. Sie ist weder eine universelle regulatorische Checkliste noch eine Beschaffungsmatrix oder ein Leistungsversprechen eines Anbieters.
Für Anbietervergleich, Vertragsnachweise, Einführungsverantwortung und RFP nutzen Sie den Leitfaden zur Auswahl von Sanktionsprüfungssoftware. Detaillierte Testgestaltung und Kalibrierung behandelt der Leitfaden zur Reduzierung falsch positiver Treffer.
1. Abnahmeumfang vor der Demonstration festlegen
Halten Sie Parteien, Abläufe, Systeme, Rechtsräume und Quellen im Prüfbereich fest. Unterscheiden Sie Kundenaufnahme, Batch-Importe, API-Anfragen, laufende Überwachung sowie Zahlungs- oder Gegenparteiprozesse. Eine Demonstration im Browser beweist nicht, dass die Produktivintegration dieselben Felder übermittelt oder dieselben Nachweise erhält. Dokumentieren Sie je Ablauf Verantwortlichen, führendes System, erwartete Eingabe, Abnahmeergebnis und Übergabe an Prüfer.
2. API-Feldvertrag und Identitätsverknüpfung überprüfen
Fordern Sie den API-Vertrag an und testen Sie ihn mit Ihren Payloads. Klären Sie erforderliche und optionale Felder, Normalisierung, Ablehnung, Kürzung und die unveränderte Speicherung übermittelter Werte. Testen Sie Namen, Aliasse, Geburtsdaten, Adressen, Identifikatoren, Unternehmensnamen, Länderwerte sowie relevante Zeichen und Schriften.
Der Abnahmenachweis sollte enthalten:
- Request- und Response-Schema, Formate, Grenzen und Validierungsfehler.
- Stabile Kennungen für Anfrage, Ergebnis, Quelldatensatz und Fall, die mit internen Daten verknüpft werden können.
- Verhalten bei fehlenden, widersprüchlichen, doppelten oder nicht unterstützten Werten.
- Ob Arbeit synchron, in Warteschlange oder teilweise erfolgt und wie der Endstatus abrufbar ist.
- Versionierung und Änderungsmitteilungen für Felder, Endpunkte und Antwortsemantik.
Setzen Sie nicht voraus, dass ein Score, Status oder eine Kennung genau das bedeutet, was Ihr Ablauf benötigt. Halten Sie die dokumentierte Bedeutung fest und testen Sie das aufrufende System.
| Zu testende Anforderung | Praxistest | Aufzubewahrender Nachweis |
|---|---|---|
| Integrität der Eingabe | Repräsentativen Datensatz senden und übermittelte mit akzeptierten Feldern vergleichen | Anonymisierte Anfrage, Antwort und Feldzuordnung |
| Identitätsverknüpfung | Eine Anfrage bis zu Ergebnis und internem Fall verfolgen | Korrelationskennungen und Abrufpfad |
| Vertragsänderung | Dokumentierte Behandlung eines hinzugefügten, fehlenden oder ungültigen Felds testen | Vertragsversion, Ergebnis und Freigabe |
Der erwartete Nachweis ist kein bestimmter Feldname oder Endpunkt, sondern eine reproduzierbare Demonstration des Verhaltens, von dem Ihre Integration abhängt.
3. Fehler, Timeouts, Wiederholungen und Idempotenz testen
Führen Sie kontrollierte Tests für Netzunterbrechung, Client-Timeout, Dienstfehler, fehlerhafte Eingabe, Rate Limit, doppelte Übermittlung, verzögerten Abschluss und erneute Webhook-Zustellung durch. Fordern Sie Nachweise zu Fehlercodes, Wiederholungsregeln, Timeout-Grenzen, retry-after-Verhalten, Semantik von Idempotenzschlüsseln und dem Zustandsmodell asynchroner Arbeit an.
Klären Sie, was geschieht, wenn der Client keine Antwort erhält, die Anfrage aber angenommen wurde. Testen Sie, ob eine Wiederholung das ursprüngliche Ergebnis liefert, einen neuen Prüflauf erstellt oder einen ausdrücklichen Abgleich verlangt. Dokumentieren Sie, wer unbekannte Zustände untersucht, wo der maßgebliche Status abgerufen wird, wann Arbeit wiederholt werden darf und wie doppelte Ergebnisse erkannt werden.
| Szenario | Testfrage | Zu bewertender Nachweis |
|---|---|---|
| Client-Timeout nach Übermittlung | Kann das Team feststellen, ob die Anfrage angenommen wurde? | Vertragsvorgabe, Statusabfrage und Abgleichprotokoll |
| Teilweise abgeschlossener Batch | Sind erledigte und wiederherzustellende Einträge unterscheidbar? | Ergebnis je Eintrag, Fehlerdetail und Wiederholungsweg |
| Doppelte Anfrage | Vermeidet der dokumentierte Wiederholungsweg doppelte Arbeit? | Korrelationsnachweis und beobachtetes Ergebnis |
| Verspäteter oder wiederholter Webhook | Verarbeitet der Consumer die Nachricht sicher? | Zustellereignis, Consumer-Log und interner Endstatus |
Nutzen Sie die vom Anbieter dokumentierte Wiederholungszeit und Zustandssemantik als Testgrundlage. Können diese nicht belegt werden oder passen sie nicht zum Ablauf, bleibt dies eine offene Lücke statt einer erfundenen Wiederherstellungsregel.
4. Quellen, Versionen und Änderungen nachvollziehbar machen
Bei einem möglichen Treffer müssen Prüfer Quelldatensatz, Quellenidentifier, Listenstand oder Veröffentlichungsdatum, Übernahmezeitpunkt, Aliasse und relevante Identifikatoren abrufen oder exportieren können. Testen Sie eine Quellenaktualisierung oder ein kontrolliertes Äquivalent: Was hat sich geändert, wann stand die Änderung dem Ablauf zur Verfügung und bleibt das Ereignis mit früherem Ergebnis und Fall verknüpft? Definieren Sie die Quellen- und Aktualisierungsnachweise Ihrer Organisation, statt pauschale Vollständigkeitsbehauptungen zu akzeptieren.
5. Audit-Rekonstruktion als Praxistest durchführen
Lassen Sie einen abgeschlossenen Testfall von einer unabhängigen Person ohne Hilfe des Präsentierenden rekonstruieren. Sie sollte übermittelte Parteidaten und Sender, Prüflauf, Konfigurations- oder Policenreferenz, Quellenstand, sichtbaren Ergebniskontext, Bearbeitungsschritte, Notizen, Eskalation, Entscheidung, Zeitstempel und spätere Änderungen feststellen können.
Bewahren Sie Export, API-Antworten, Screenshots und verwendeten Zugriffspfad auf. Wenn Nachweise über mehrere Systeme verteilt sind, dokumentieren Sie Korrelationskennungen und Aufbewahrungsverantwortlichkeiten. Details pro Alert behandelt der Leitfaden zur Dokumentation von Sanktionsalert-Untersuchungen.
Beispiel für einen Abnahmenachweis
Das Beispiel ist illustrativ. Es beschreibt weder ein vorgeschriebenes Statusmodell noch API-Antworten oder Produktfunktionen.
| Feld | Illustrativer Eintrag |
|---|---|
| Abnahmegegenstand | Anfrage mit unbekanntem Client-Ergebnis wiederherstellen |
| Testreferenz | INT-REC-04 |
| Erwartetes Ergebnis | Endergebnis feststellen und doppelte interne Verarbeitung verhindern |
| Beobachtetes Ergebnis | Prüfung offen, da Statusabfrage keine ausreichende Korrelation zeigte |
| Nachweisverantwortung | Integrationsverantwortlicher mit Compliance-Prüfung |
| Entscheidung | Offene Lücke; Nachverfolgung vor Produktionsfreigabe |
Bestanden bedeutet: vereinbarter Test mit ausreichendem, abrufbarem Nachweis. Fehlgeschlagen bedeutet: beobachtetes Verhalten widerspricht dem Kriterium. Eine offene Lücke bedeutet, dass Ergebnis, Dokumentation, Zugriff oder Verantwortlichkeit fehlt und darf nicht als bestanden zählen. Bestimmen Sie einen Verantwortlichen für Anbieternachweise und einen internen Verantwortlichen für Annahme oder Ablehnung.
6. Zugriffe, Sicherheit, Datenbetrieb und Resilienz validieren
Testen Sie das Zugriffsmodell, nicht nur einen Fragebogen. Prüfen Sie, ob Rollen für Analysten, Freigeber, Administratoren, Integrationen und Auditoren nur vorgesehene Aktionen ausführen können. Vereinbaren Sie Nachweise zu Datenübertragung und -speicherung, Umgebungstrennung, Protokollen, Aufbewahrung, Löschung, Speicherort, Unterauftragsverarbeitern, Vorfallmeldung, Sicherung und Geschäftskontinuität.
Definieren Sie ein begrenztes Testvolumen für Batchgröße, parallele Anfragen, Spitzenzeiten und nachgelagerte Abhängigkeiten. Beobachten Sie Warteschlangen, Teilfehler, Monitoring-Signale, Eskalation und Wiederherstellung, statt nur eine günstige Antwortzeit zu messen. Halten Sie Bedingungen, Ergebnisse, offene Fehlermodi, Verantwortliche und manuelle Fortführung fest. Richtlinien- oder rechtsraumspezifische Vorgaben sind eigene Kriterien, keine universellen Produktfunktionen.
7. Abnahmenachweise und offene Lücken dokumentieren
Führen Sie je Kriterium Anforderung, Testdaten, Umgebung, erwartetes und tatsächliches Ergebnis, Ablageort der Evidenz, Prüfer, Datum und Entscheidung. Eine unbelegte Antwort, nicht wiederholbare Demonstration oder ein Ergebnis außerhalb des vereinbarten Ablaufs bleibt eine offene Lücke. Wiederholen Sie relevante Tests nach wesentlichen Änderungen an Integration, Ablauf, Quellenverarbeitung oder Konfiguration.
Halten Sie den Abnahmenachweis von der kommerziellen Entscheidung getrennt. Der Auswahlleitfaden strukturiert diese Entscheidung; der Nachweis soll technische Annahmen und ungeklärte Wiederherstellungswege sichtbar machen.
Möchten Sie die operative Eignung eines Sanktionsprüfungsablaufs bewerten? Entdecken Sie die Sanktionsprüfung von Checklynx und validieren Sie mit Ihrem Team Vertrag, Ablauf und Nachweispfad.
Weiterlesen: KI bei AML-Prüfungen