Automatisierung der Sorgfaltspflichten: Architektur für jurisdiktionsbewusste CDD

---

Irgendwo in Ihrer Codebasis gibt es ein If-Statement, das entscheidet, wie gründlich ein Kunde verifiziert wird. Es prüft das Land. Es prüft die Risikostufe. Es ruft einen Provider auf. Wenn der Regulator in Spanien die Regeln für verstärkte Sorgfaltspflichten ändert, modifiziert ein Entwickler das If-Statement, schreibt einen Test, deployt und hofft, dass kein anderer Zweig betroffen wurde.

So funktionieren die meisten CDD-Implementierungen. Es ist auch der Grund, warum die Expansion in eine neue Jurisdiktion Monate statt Tage dauert: Die Compliance-Logik ist in Code eingebettet, nicht als Konfiguration ausgedrückt. Jedes neue Land erfordert Entwicklungsarbeit. Jede Regeländerung erfordert einen Release-Zyklus. Jedes Audit erfordert einen Entwickler, der erklärt, was der Code tut, weil der MLRO ihn nicht direkt lesen kann.

Das Hard-Coded-CDD-Problem

Das Muster ist wiedererkennbar:

if country == "DE" and risk_level == "high":
    require_enhanced_document_verification()
elif country == "ES" and risk_level == "medium":
    require_standard_address_verification()
elif country == "DE" and risk_level == "low":
    require_basic_identity_check()

Über die Codebasis verstreut. Jeder Zweig ist eine Compliance-Regel, kodiert als Anwendungslogik. Die Probleme kumulieren:

• Eine Jurisdiktion hinzufügen bedeutet Code modifizieren. Österreich erfordert eine andere Adressverifizierungstiefe als Deutschland. Die Schweiz hat andere Dokumentationsanforderungen als beide. Jede Ergänzung ist eine Codeänderung, ein Testzyklus, ein Deployment.
• Eine Regel ändern bedeutet Code modifizieren. Der MLRO entscheidet, dass Hochrisiko-Kunden in Spanien nun verstärkte Dokumentenverifizierung statt Standard erfordern. Diese Entscheidung wandert durch ein Ticket, wartet im Sprint-Backlog, wird von einem Entwickler implementiert, der den regulatorischen Kontext möglicherweise nicht vollständig versteht, und wird im nächsten Release ausgeliefert.
• Die Regeln auditieren bedeutet Code lesen. Wenn der Regulator fragt „welche Sorgfaltspflichten führen Sie für Hochrisiko-Kunden in Deutschland durch?", erfordert die Antwort einen Entwickler, der Codepfade nachverfolgt und Verzweigungslogik erklärt. Das Compliance-Team kann nicht unabhängig verifizieren, was das System tut.

Das Policy-Modell

Eine CDD-Policy ist ein Datensatz, kein Codezweig. Sie hat vier Dimensionen:

Ein Policy-Datensatz sagt: „Für Jurisdiktion X, bei Risikostufe Y, führe Prüfungstyp Z mit Tiefe W durch." Das System speichert diese als Daten, abfragbar, versionierbar, von Nicht-Entwicklern auditierbar.

Beispiel-Policy-Set:

Auflösungslogik: Wenn eine CDD-Prüfung ausgelöst wird, sucht das System zuerst nach einer jurisdiktionsspezifischen Policy. Wenn keine existiert, fällt es auf GLOBAL zurück. Das bedeutet: Launch in einem neuen Land mit null Konfiguration, die GLOBAL-Policies gelten automatisch. Dann länderspezifische Overrides hinzufügen, wenn das Compliance-Team bereit ist.

Die Fallback-Kette:

Neues Land, Tag eins: GLOBAL-Policies gelten. Keine Codeänderung. Kein Deployment. Der MLRO fügt jurisdiktionsspezifische Overrides über das Admin-Interface hinzu, wenn lokale Regulierungen andere Tiefen erfordern.

Policy-Lifecycle

Policies sind nicht statisch. Sie entwickeln sich, wenn sich Regulierungen ändern und wenn das Compliance-Team seinen Risikoappetit verfeinert. Der Lifecycle muss auditierbar sein:

Entwurf → Aktiv → Archiviert.

Nur eine aktive Policy kann pro Jurisdiktion × Risikostufe × Prüfungstyp-Kombination existieren. Die Aktivierung einer neuen Policy archiviert die vorherige automatisch. Die archivierte Policy bleibt in der Datenbank, immutable, abfragbar, mit Zeitstempel. Ein Auditor kann rekonstruieren, welche Policy für eine bestimmte Prüfung zu einem beliebigen Zeitpunkt galt.

Das ist bei regulatorischer Prüfung relevant. Die Frage ist nicht „was sind Ihre aktuellen CDD-Policies?" Sondern „welche Policy galt, als Sie Kunde X am 15. März ongeboardet haben?" Wenn Policies Codezweige sind, erfordert die Antwort Git-Archäologie. Wenn Policies versionierte Datensätze sind, ist die Antwort eine Datenbankabfrage.

Provider-Abstraktion

Die Policy definiert was geprüft werden soll. Das Provider-Interface definiert wie.

Eine CDD-Prüfung für Adressverifizierung kann von Loqate (Adressvalidierungs-API), Google Places (Geocoding), einer manuellen Dokumentenprüfung oder einer Kombination erfüllt werden. Die Policy sagt „verifiziere die Adresse mit Verstärkter Tiefe." Die Provider-Implementierung sagt „rufe Loqate auf, gleiche mit dem Postregister ab, markiere Diskrepanzen zur manuellen Überprüfung."

Die Trennung ist relevant, wenn Provider wechseln. Der Wechsel von Provider A zu Provider B ist eine Konfigurationsänderung in der Provider-Schicht. Keine Policy-Änderung. Keine Codeänderung in der CDD-Engine. Prüfungstyp und Tiefe bleiben gleich, nur der Erfüllungsmechanismus ändert sich.

Das ist dasselbe Muster wie bei KYC-Verifizierung: Das System braucht Identitätsverifizierung. Ob Identomat, Onfido oder Jumio es erfüllt, ist eine Konfigurationsentscheidung. Der Onboarding-Flow weiß nicht und kümmert sich nicht darum, welcher Provider aktiv ist.

Jurisdiktionsprofile

Jede Jurisdiktion trägt mehr als CDD-Policy-Overrides. Sie trägt die regulatorischen Parameter, die den Betrieb beeinflussen:

Die Geschäftstage-Berechnung verwendet den Feiertagskalender der Jurisdiktion. „5 Geschäftstage" in Deutschland ist etwas anderes als „5 Geschäftstage" in Spanien wegen unterschiedlicher Feiertage. Die Haltefrist für SEPA R-Transaktionen, die Frist für den Abschluss von CDD-Prüfungen, die Bearbeitungszeit für regulatorische Reports, alle hängen vom korrekten Kalender ab.

Audit-Trail

Jede CDD-Prüfung wird als immutabler Datensatz aufgezeichnet:

• Policy-Version, die galt
• Prüfungstyp und Tiefe
• Verwendeter Provider
• Ergebnis (bestanden, nicht bestanden, manuelle Überprüfung)
• Zeitstempel (erstellt, abgeschlossen)
• Prüfer (bei manueller Eskalation)

Der Prüfungsdatensatz ist auf Datenbankebene löschgeschützt (ein Trigger verhindert DELETE-Operationen auf der Audit-Tabelle). Korrekturen sind neue Datensätze, keine Updates bestehender. Die vollständige Historie bleibt erhalten.

Der Pfad eines Auditors: Kunde → CDD-Prüfungen → für jede Prüfung: welche Policy war aktiv, welche Tiefe wurde angewandt, welcher Provider hat sie erfüllt, was war das Ergebnis, wer hat geprüft (wenn manuell). Alles aus strukturierten, abfragbaren Daten. Kein Code-Lesen erforderlich.

Operative Auswirkungen

Marktexpansion ohne Engineering. Neue Jurisdiktion? Die GLOBAL-Fallback-Policies gelten sofort. Länderspezifische Overrides werden vom Compliance-Team über das Admin-Interface hinzugefügt. Kein Entwickler im Prozess.

Regeländerungen ohne Deployments. Der MLRO aktualisiert einen Policy-Datensatz. Die neue Policy gilt ab der nächsten Prüfung. Die alte Policy wird archiviert. Der Audit-Trail erfasst beide Versionen und den Übergangszeitstempel.

Bereitschaft für regulatorische Prüfung. Jede Prüfung ist auf eine spezifische Policy-Version rückverfolgbar. Jede Policy-Änderung ist mit Zeitstempel und Zuordnung versehen. Das Compliance-Team kann Regulierer-Fragen direkt beantworten, ohne Engineering-Support.

Provider-Flexibilität. KYC-Provider-Vertrag läuft aus? Wechsel zu einem neuen Provider durch Konfiguration. Die CDD-Policies, das Was, bleiben unverändert. Nur das Wie ändert sich.

---

Weiterlesen: Compliance-Infrastruktur | Sicherheit & Compliance

---

Quellen:

• AMLD5, Richtlinie 2018/843, Art. 13 (Sorgfaltspflichten gegenüber Kunden)
• AMLD6, Richtlinie 2024/1640, Art. 16-18 (Risikobasierter Ansatz für CDD)
• GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern), 10-jährige Aufbewahrung
• HGB §257, Aufbewahrungsfristen für kaufmännische Unterlagen