Technische Abnahmekriterien für Sanktionsprüfungssoftware 2026
Diese Checkliste unterstützt Compliance-, Risiko-, Sicherheits- und Entwicklungsteams bei der technischen Abnahme eines Prüfablaufs 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, Validierungsergebnis und dokumentierte Feldzuordnung |
| Identitätsverknüpfung | Eine Anfrage bis zu Ergebnis und internem Fall verfolgen | Korrelationskennungen und Abrufpfad in beiden Systemen |
| Vertragsänderung | Dokumentierte Behandlung eines hinzugefügten, fehlenden oder ungültigen Felds testen | Vertragsversion, Testergebnis, Freigabe durch den Verantwortlichen und Änderungsmitteilung |
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? | Idempotenz- oder 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 prüfen, ob Analysten den Quelldatensatz, die Quellenkennung, den Listenstand oder das Veröffentlichungsdatum, den Übernahmezeitpunkt, Aliasse und relevante Identifikatoren abrufen oder exportieren können. Eine Quellenaktualisierung oder ein kontrolliertes Äquivalent testen: Was hat sich geändert, wann stand die Änderung dem Ablauf zur Verfügung und bleibt das Ereignis mit dem früheren Ergebnis und Fall verknüpft? Die Quellen- und Aktualisierungsnachweise der Organisation festlegen, statt pauschale Vollständigkeitsbehauptungen zu akzeptieren.
5. Audit-Rekonstruktion als Praxistest durchführen
Einen abgeschlossenen Testfall von einer unabhängigen Person ohne Hilfe der vorführenden Person rekonstruieren lassen. Sie sollte übermittelte Parteidaten und Absender, Prüflauf, Konfigurations- oder Richtlinienreferenz, Quellenstand, sichtbaren Ergebniskontext, Bearbeitungsschritte, Notizen, Eskalation, Entscheidung, Zeitstempel und spätere Änderungen feststellen können, die eine erneute Bearbeitung ausgelöst haben.
Bewahren Sie Export, API-Antworten, Screenshots und verwendeten Zugriffspfad auf. Wenn Nachweise über mehrere Systeme verteilt sind, dokumentieren Sie Korrelationskennungen und Aufbewahrungsverantwortlichkeiten. Nachweise für die Untersuchung einzelner Trefferhinweise behandelt der Leitfaden zur Dokumentation von Sanktionsprüfungen.
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 auf Anbieterseite feststellen und doppelte interne Verarbeitung verhindern |
| Beobachtetes Ergebnis | Prüfung offen, da Statusabfrage keine ausreichende Korrelation zeigte |
| Nachweisverantwortung | Integrationsverantwortlicher mit Compliance-Prüfung |
| Ablageort der Nachweise | Freigegebene Testablage und Verweis auf die Fallakte |
| 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 und Datenbetrieb prüfen
Das Zugriffsmodell praktisch testen, nicht nur einen Fragebogen ausfüllen. Prüfen, ob Rollen für Analysten, Freigeber, Administratoren, Integrationen und Auditoren nur vorgesehene Aktionen ausführen können. Die erforderlichen Nachweise zu Datenübertragung und -speicherung, Umgebungstrennung, Protokollen, Aufbewahrung, Löschung, Speicherort, Unterauftragsverarbeitern, Vorfallmeldung, Sicherung und Geschäftskontinuität vereinbaren. Richtlinien- oder rechtsraumspezifische Vorgaben sind eigene Kriterien, keine universellen Produktfunktionen.
7. Operative Belastbarkeit unter realistischer Last testen
Ein begrenztes Testvolumen für Batchgröße, parallele Anfragen, Spitzenzeiten und nachgelagerte Abhängigkeiten festlegen. Warteschlangen, Teilfehler, Überwachungssignale, Eskalation an den Support und Wiederherstellung beobachten, statt nur eine günstige Antwortzeit zu messen. Bedingungen, Ergebnisse, ungelöste Fehlerfälle, Verantwortliche und Verfahren für die Rücknahme von Änderungen oder die manuelle Fortführung festhalten. Klären, wie Vorfälle, Wartungsarbeiten und inkompatible Änderungen kommuniziert werden und welche Informationen nach der Wiederherstellung für den Ergebnisabgleich verfügbar sind.
8. Abnahmenachweise und offene Lücken dokumentieren
Je Kriterium Anforderung, Testdaten, Umgebung, erwartetes und tatsächliches Ergebnis, Ablageort der Nachweise, Analyst, Datum und Entscheidung dokumentieren. Eine unbelegte Antwort, nicht wiederholbare Demonstration oder ein Ergebnis außerhalb des vereinbarten Ablaufs bleibt bis zur Klärung eine offene Lücke. Das Nachweispaket bezieht sich auf die angegebenen Daten, die Konfiguration, den Quellenstand und die Integration zu diesem Zeitpunkt; relevante Tests nach wesentlichen Änderungen wiederholen.
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