AMLA: So geht die Datenbankprüfung vor sich

Ein Mann mit kurzen, grauen Haaren und einem leichten Bart lächelt in die Kamera. Er trägt ein hellblaues Hemd. Die AMLA wird in der Lage sein, Lücken im Audit-Log zu identifizieren und zu analysieren. — René Blaschke Manager bei cleversoft cleversoft

Die AMLA prüft keine Prozessdokumente. Sie greift direkt auf Datenbanken zu und sucht nach reproduzierbaren Entscheidungspfaden für jeden KYC-Fall. Wer die nicht liefern kann, muss unter Zeitdruck die Architektur umbauen – und vorher knallhart priorisieren.

von René Blaschke Managing Director, Financial Crime Prevention and Compliance Solutions bei cleversoft

Wenn die AMLA anklopft, zählt vor allem eins: Was steht in der Datenbank? Die Prüfer der Anti-Money Laundering Authority interessieren sich nicht für Dokumentationen oder Prüfberichte; sie brauchen vollständige und nachvollziehbare Datensätze. Nachträgliche Ergänzungen sind nicht zulässig.

Was jahrelang als pragmatisch gewachsene Architektur durchging, wird unter den Argusaugen der AMLA zum Haftungsrisiko.“

Auf dem Radar der Frankfurter Behörde werden fehlende Pflichtfelder, widersprüchliche Due-Diligence-Ergebnisse und mehrere Jahre alte Risikobewertungen in KYC-Datensätzen auftauchen, die ihr Dasein bisher in sauber voneinander getrennten Systemen fristeten. Transaktionsdaten in System A, der KYC-Status zum Zeitpunkt der Entscheidung in System B, der Output der AML-Engine in System C – unter der AMLR ein regulatorischer Alptraum.

Laut PwC EMEA AML Survey 2026 (Website) haben nur 25 Prozent der EU-Finanzinstitute überhaupt eine vollständige Folgenabschätzung durchgeführt. Die übrigen arbeiten mit einem Datenbestand, dessen tatsächliche Lückentiefe niemand gemessen hat.

AMLA prüft keine Prozesse, sondern Datenbanken

Autor: René Blaschke, cleversoft

René Blaschke, Managing Director und Mitgründer von cleversoft, steht im Fokus. Seine Expertise wird in der Diskussion um die AMLA und deren Fähigkeit, Lücken im Audit-Log zu identifizieren, hervorgehoben.

René Blaschke ist Managing Director und, zusammen mit Florian Clever, Gründer von cleversoft (Website). Während seines Studiums gründete René ein Finanzberatungsunternehmen für vermögende Privatkunden. Anschließend war er maßgeblich am Aufbau eines Emissionshauses für geschlossene Fonds (CEF) für eine mittelständische Finanzdienstleistungsgruppe beteiligt. Im Jahr 2011 gründete er cleversoft CRM Services. Innerhalb der cleversoft group verantwortet er die seit 2011 bestehende Sparte zur Finanzkriminalitätsbekämpfung – von der Produktentwicklung über Marketing, Vertrieb und Consulting bis hin zum Support. René bringt mehr als 20 Jahre Erfahrung in der Finanzdienstleistungsbranche und über 10 Jahre in der Entwicklung regulatorischer Softwarelösungen mit.

Institute müssen damit rechnen, dass die AMLA-Aufsicht weitaus mehr Wert auf den direkten Zugriff auf Daten sowie auf Rückverfolgbarkeitsprüfungen auf Datenbankebene anhand von Transaktions- und Kundendatensätzen legt. Stößt sie stattdessen auf einen Prüfpfad voller Lücken, wird die IT erklären müssen, warum keine durchgängigen Datensätze existieren.

Aus IT-Perspektive erstreckt sich die Prüflogik der AMLA über vier Systembereiche: Kunden-Onboarding inklusive Dokumentenerfassung und KYC, Risikoklassifizierung, laufende Überwachung – also Transaktionsmonitoring, Name-Screening gegen PEP-, Sanktions- und Watchlisten sowie Fallmanagement – und konzernweite Governance inklusive gruppeninterner Datenweitergabe und Konsistenz zwischen EU-Einheiten.

Hinzu kommt der Wandel von der zyklischen zur ereignisgesteuerten Überwachung. Wenn sich ein Risikoparameter ändert, muss die Neubewertung für diesen konkreten Fall sofort ausgelöst und entsprechend dokumentiert werden, anstatt sie auf den nächsten nächtlichen Batch-Lauf zu verschieben.

Bruchstellen in der Datenbankarchitektur

Eines der Kernprobleme ist die fehlende referenzielle Integrität über Systemgrenzen hinweg. Ohne einen gemeinsamen, stabilen Identifier, der eine Risikobewertung eindeutig mit dem KYC-Status, dem Transaktionskontext und der exakt angewendeten Regelversion zum Entscheidungszeitpunkt verknüpft, lässt sich kein reproduzierbarer Entscheidungspfad aufbauen. Nachträgliche Konsolidierung per ETL-Job, Best-Effort-Matching oder manuelle Abstimmungen erfüllen die Anforderungen nicht. Erst recht nicht, wenn der historische Datenstand zum Zeitpunkt der Entscheidung nicht erhalten geblieben ist.

Hinzu kommt die veraltete Batch-Verarbeitung. Nächtliche Läufe liefern zwar aggregierte Ergebnisse, aber keine nachprüfbare Aufzeichnung einzelner Entscheidungen. Zeitstempel auf Zeilenebene fehlen, Regelversionen werden nicht protokolliert und der Datenstand zum Zeitpunkt der Verarbeitung lässt sich später nicht rekonstruieren. Kommen dann noch proprietäre Datenformate und fehlende Schnittstellenstandards zwischen Altsystemen und modernen AML-Plattformen hinzu, wird jede Integration zur maßgeschneiderten Übersetzungsarbeit.

Erst messen, dann sanieren

Vor diesem Hintergrund sollte die IT drei Dinge angehen:

Erst den Ist-Zustand ermitteln, dann die Anpassungen priorisieren und im letzten Schritt die Architektur umstellen.“

Andernfalls besteht die Gefahr, dass das Sanierungsprojekt Ressourcen in Bereichen verbrennt, die im ersten Prüfungszyklus womöglich gar keine Rolle spielen.

Der einzig sinnvolle Ausgangspunkt ist eine systematische Datenprofilierung aller AML-relevanten Datenspeicher: fehlende Pflichtfelder, Duplikate, veraltete Zeitstempel, widersprüchliche Einträge über Systemgrenzen hinweg. Der technische Einstieg ist in der Regel SQL-basiert: Konsistenzprüfungen gegen definierte Pflichtfeldkataloge, Abgleich zwischen AML-Engine-Output und Quelldaten, Integritätsprüfungen über alle beteiligten Systeme. Data-Lineage-Tools machen systemübergreifende Datenflüsse sichtbar und lokalisieren die Bruchstellen, an denen Entscheidungskontext verloren geht oder Zeitstempel inkonsistent werden.

Das Ergebnis ist eine Backlog-Karte mit klarer Risikogewichtung: Hochrisikokunden und aktive Geschäftsbeziehungen haben Vorrang, Altbestände mit niedrigen Risikoprofilen folgen danach.

Wie sieht ein AMLA-fähiges Datenmodell aus?

Sind Bestand, Lücken und Priorisierung klar, folgt die Arbeit an der Architektur. Das Ziel ist ein einheitliches Kundenlebenszyklusmodell: eine durchgängige Datenbasis, in der KYC-Status, Risikoscore und Transaktionskontext zum exakten Entscheidungszeitpunkt als zusammenhängende Einheit verknüpft sind. Alle AML-relevanten Daten gehören in ein konsistentes, versioniertes Modell, das jeden Zustandswechsel nachvollziehbar macht.

Der technisch sauberste Weg ist ein unveränderliches Append-only Audit-Log: keine Aktualisierungen, keine Löschungen, nur neue Einträge. Jeder Eintrag referenziert die Regelversion, die die Entscheidung ausgelöst hat, die vollständige Datenbasis sowie hochauflösende, monotone Zeitstempel.

Die Schnittstellenstrategie folgt dem gleichen Prinzip: API-first statt Batch. Echtzeit-Synchronisation zwischen KYC-System und AML-Engine ersetzt den nächtlichen Lauf. Jede risikorelevante Änderung an einem Kundendatensatz löst eine sofortige Neubewertung aus und schreibt das Ergebnis mit vollständigem Kontext ins Audit-Log. Proprietäre Punkt-zu-Punkt-Integrationen weichen standardisierten APIs mit explizitem Datenstand zum Zeitpunkt der Übergabe.

Straffer Zeitplan mit wenig Spielraum

Die AMLA macht keine Ausnahmen: Wenn die Datenbank Entscheidungspfade nicht reproduzieren kann, helfen auch keine Richtlinienhefte und Prozessdokumentationen. Doch ein Umbau dieser Größenordnung lässt sich nicht in wenigen Wochen erledigen. Erst recht nicht, wenn ein vollständiges Dateninventar fehlt.

Da die AMLR am 10. Juli 2027 in Kraft tritt und die AMLA ab 2028 die direkte Aufsicht übernimmt, brauchen betroffene Institute jetzt einen Umsetzungsplan.“

Die Reihenfolge für IT-Teams ist klar: Datenprofilierung starten, Backlogs nach regulatorischem Risiko gewichten, Architekturentscheidungen treffen und mit dem Umbau starten – bevor der Prüfer die erste Anfrage stellt. René Blaschke, cleversoft