Die Datenbrille
Lineage als Architektur, nicht als Tool
Am 9. Februar 2026 eröffnete die AMLA in Frankfurt eine öffentliche Konsultation zu einem Dokument, das in der Compliance-Welt nur mäßige Aufmerksamkeit erhielt: der Draft des Regulatory Technical Standard zu Customer Due Diligence nach Art. 28(1) AMLR. Die Konsultation lief bis zum 8. Mai 2026.
Auf den ersten Blick las sich der Entwurf wie regulatorische Routinearbeit. Auf den zweiten Blick war es ein Datenmodell-Test. Welche Felder müssen in welcher Form erhoben, verifiziert, historisiert und über Systemgrenzen hinweg konsistent gehalten werden?
Die Frage, woher die Werte kommen, durch welche Transformationen sie gelaufen sind und ob sie zwischen verschiedenen Systemen konsistent sind, ist deutlich schwerer zu beantworten. Das ist nicht das Versagen einzelner Häuser — das ist eine strukturelle Information über den Reifegrad einer Industrie.
Was die Datenbrille sieht
Wer aus der Welt der Datenarchitektur kommt, liest die RTS-Entwürfe anders als ein Compliance-Officer. Wo der Compliance-Officer Pflichten zur Identifikation und Verifikation liest, liest der Datenarchitekt eine Spezifikation.
Drei Eigenschaften der RTS-Anforderungen
1. Feldebenen-präzise — Konkrete Auflistung: Vornamen, Nachnamen, Geburtsdaten, Geburtsorte, Staatsangehörigkeiten (Plural!), Adressen, Identifikationsdokumente, Verifikationsquellen.
2. Versionsensitiv — Eine Verifikation von 2023 ist nicht dieselbe wie eine von 2027, weil sich akzeptable Quellen geändert haben können.
3. Audit-orientiert — Nicht nur was erhoben wird, sondern es muss gezeigt werden können, dass es erhoben wurde.
Das Wort, das diese drei Eigenschaften zusammenbringt, lautet Lineage.
Eine kleine Geschichte über Lineage
Lineage beschreibt die Fähigkeit eines Systems, für jeden seiner Outputs nachzuvollziehen, woher die Daten stammen, durch welche Transformationen sie gelaufen sind, und wer für jeden Schritt verantwortlich war.
Eine typische deutsche mittelgroße Bank hält erfahrungsgemäß zwischen 60 und 120 Anwendungen vor, die Kundendaten halten oder verarbeiten. Sie betreibt typischerweise 5 bis 15 verschiedene Datenintegrations-Patterns — von täglichen Batch-ETL-Jobs über CDC-Streams bis zu Punkt-zu-Punkt-Schnittstellen aus den 1990ern.
Wer gefragt wird, woher das Feld „Geburtsort“ im Transaktionsmonitoring-System stammt, beantwortet die Frage typischerweise mit einer Mischung aus Vermutung, Erfahrung und Telefonaten. Diese Mischung wird ab Juli 2027 nicht mehr ausreichen.
Data Lineage Flow: Feld „Geburtsort“
Interaktive Darstellung — Datenfluss durch Banksysteme mit Transformationsknoten
Was die RTS auf Feldebene fordert
Natürliche Person — Staatsangehörigkeiten (Plural): Die Migration von einer 1:1-Relation auf 1:n ist eine Datenmodelländerung. Sie betrifft alle nachgelagerten Systeme — Sanktionsscreening, PEP-Screening, Transaktionsmonitoring, FIU-Reporting.
Verifikation — „Erheben“ vs. „Verifizieren“: In vielen Systemen landen beide Schritte im selben Datenbankfeld, ohne Unterscheidung von Quelle und Bestätigung.
Transparenzregister: Zulässige Quelle der Identifikation, aber für sich genommen keine hinreichende Verifikationsquelle. Wer heute ein automatisiertes UBO-Lookup als verifiziert kennzeichnet, kennzeichnet falsch.
Die deutsche Banklandschaft, in Zahlen
Methodik-Kasten Die hier zitierten Zahlen sind eine Watchdog-Modellrechnung für ein hypothetisches mittelgroßes deutsches Institut. Annahmen: Bestand in der Größenordnung mittelgroßer Universalbanken, erweiterte AMLR-PEP-Definition (inkl. Kommunalfunktionsträger ab 50.000 Einwohnern), durchschnittliche PEP-nahe Beziehungen nach FATF-Definition, branchenübliche Effort-Schätzungen, jährliche Änderungsquote auf Basis kommunaler Wahlturnusse. Die Zahlen sind als Plausibilisierung der operativen Größenordnung zu lesen, nicht als belastbare Zielmarke.
Die operative Frage, die jeder seriöse Wirtschaftsprüfer ab 2028 stellen wird: Können Sie diese Zahlen Feld für Feld belegen?
Eine Rolle, die im Stellenmarkt fehlt
Der Engpass des kommenden Jahrzehnts wird nicht der Compliance-Officer sein. Der Engpass wird der FinCrime Data Steward sein — eine Rolle, die in deutschen Bank-Stellenmärkten heute kaum unter dieser Bezeichnung auftaucht.
Profil: FinCrime Data Steward
Übersetzt zwischen Compliance und Datenarchitektur. Kennt die fachliche Bedeutung der RTS-Anforderungen, bildet sie in Datenmodelle ab, definiert Qualitätsregeln, dokumentiert Lineage, koordiniert Quellsystem-Änderungen mit abhängigen Systemen. Versteht Master-Data-Management, Data-Vault-Modellierung und Data-Lineage-Tools — und gleichzeitig, warum eine Bürgermeisterin einer Stadt mit 50.100 Einwohnern eine PEP ist und eine mit 49.000 noch nicht.
Diese Doppel-Qualifikation ist auf dem deutschen Markt heute selten. Wer in seinem Haus heute zwei oder drei solche Profile aufbaut, verschafft sich einen Vorsprung, den der Markt nicht wird einholen können.
Die Sequenzfrage
Es ist verlockend, eine Tool-Empfehlung abzugeben. Welcher Lineage-Anbieter? Welche Master-Data-Plattform? Welches Workflow-System? Diese Fragen sind nicht trivial — aber sie sind nicht der Anfang.
Der Anfang ist: Versteht das Haus, welche Daten es heute hat, woher sie kommen, und wer für sie verantwortlich ist? Diese Frage zu beantworten erfordert kein Tool. Sie erfordert eine ehrliche Bestandsaufnahme — und sie wird die Voraussetzung dafür sein, dass alle weiteren Investitionen überhaupt sinnvoll dimensioniert werden können.
