AMLA Decoded: Die 7 Dokumente, die jeder RegTech Engineer jetzt lesen muss
Die EU-Geldwaeschebehoerde hat ihre Bibliothek geoeffnet. Wir haben jeden relevanten PDF-Download analysiert und sagen euch, was fuer eure Systeme, APIs und Datenmodelle wirklich zaehlt – und was nur Polit-Prosa ist.
Seit Februar 2026 veroeffentlicht die Anti-Money Laundering Authority (AMLA) in Frankfurt am Main im Wochentakt technische Standards, Konsultationspapiere und Strategiedokumente. Fuer RegTech-Teams ist das kein Buerokratie-Rauschen – es ist der Bauplan fuer die naechste Generation eurer Compliance-Infrastruktur. Wer jetzt nicht liest, baut ab Juli 2027 am falschen System.
AMLA ist seit dem 1. Januar 2026 finanziell autonom und hat keine Zeit zu verlieren. Bis zum 10. Juli 2026 muss die Behoerde der EU-Kommission rund 80 technische Standards (RTS und ITS) vorlegen. Parallel laeuft die Datenerhebung, mit der die 40 Finanzinstitute fuer die Direktaufsicht ab 2028 ausgewaehlt werden. Fuer RegTech Engineers bedeutet das: Eure CDD-Engines, Transaction-Monitoring-Pipelines und Risk-Scoring-Modelle muessen sich an konkreten, neuen Spezifikationen messen lassen.
Wir haben die oeffentlich zugaengliche AMLA-Dokumentenbibliothek durchgearbeitet und die Downloads nach Relevanz fuer technische Teams priorisiert. Hier sind die sieben Dokumente, die auf euren Sprint-Backlog gehoeren – mit konkreten Hinweisen, was sie fuer euren Code bedeuten.
Die Konsultationsfrist fuer den CDD-RTS (Art. 28) laeuft bis zum 8. Mai 2026. Wer als RegTech-Anbieter Einfluss auf die finale Spezifikation nehmen will, muss sich jetzt mit dem Draft auseinandersetzen. Das Fenster ist kurz.
Die AMLA-Bibliothek: 7 Must-Reads, priorisiert
Das ist das Dokument. Artikel 12(7) definiert die Methodik, nach der AMLA die 40 hoechst-risikobehafteten Finanzinstitute in der EU fuer die Direktaufsicht ab 2028 auswaehlt. Der RTS legt fest, wie „Inherent Risk“ (Geschaeftsaktivitaeten, Kundenprofile, Geografie) und „Residual Risk“ (Qualitaet der AML-Kontrollen) quantitativ bewertet werden.
Entscheidend: Hohes inhaerendes Risiko allein fuehrt nicht zur Auswahl. Erst wenn die AML/CFT-Kontrollen nicht proportional zum Geschaeftsrisiko sind, schlaegt der Algorithmus an. Das ist exakt die Logik, die euer Risk-Scoring-Modul abbilden muss.
Dieses Dokument definiert die Risiko-Taxonomie, die kuenftig EU-weit einheitlich gilt. Wenn euer Produkt Risk Assessments automatisiert, muesst ihr die AMLA-Risikofaktoren (Geografie, Kundentyp, Produktkategorie, Transaktionsmuster) als First-Class-Citizens in eurem Datenmodell abbilden. Der RTS gibt euch die exakten Kategorien und Gewichtungslogiken. Eure risk_score()-Funktion muss diese Taxonomie sprechen – sonst wird euer Output fuer Aufsichtsbehoerden wertlos.
Artikel 28(1) ist das Herzstueck der neuen AML-Verordnung fuer den operativen Betrieb. Der Draft RTS spezifiziert im Detail, welche Informationen bei Standard-CDD, vereinfachter CDD (SDD) und verstaerkter CDD (EDD) erhoben werden muessen. Er definiert ausserdem, welche „reliable and independent sources“ fuer die Identitaetsverifikation akzeptabel sind – inklusive Anforderungen an elektronische Identifikation.
Besonders brisant: Der RTS legt fest, unter welchen Bedingungen E-Geld-Instrumente von bestimmten CDD-Massnahmen befreit werden koennen. Fuer jeden RegTech-Anbieter im Zahlungsverkehr ein direkter Eingriff in die Produktlogik.
Euer Onboarding-Flow, eure KYC-API und eure Datenbank-Schemata werden sich aendern muessen. Der RTS definiert exakt welche Felder bei welchem CDD-Level Pflicht sind. Wenn euer System heute zwischen „standard“ und „enhanced“ unterscheidet, bekommt ihr jetzt die EU-weite Spezifikation dafuer. Denkt an: neue enum-Werte fuer Verifikationsquellen, zusaetzliche Pflichtfelder fuer wirtschaftlich Berechtigte, risikobasierte Trigger fuer EDD-Eskalation. Das ist eure API-Spec fuer 2027.
Dieses Papier definiert das harmonisierte Enforcement-Framework der EU. Der RTS spezifiziert Indikatoren zur Klassifizierung der Schwere von Verstoessen in vier Kategorien, Kriterien fuer die Festlegung von Bussgeldern (bis zu 10% des Jahresumsatzes oder 10 Mio. Euro) und die Methodik fuer periodische Strafzahlungen.
Das Ziel: Derselbe Verstoss soll in allen Mitgliedstaaten gleich bewertet werden. Schluss mit dem regulatorischen Flickenteppich, bei dem eine schwache CDD-Implementierung in Land A toleriert und in Land B sanktioniert wurde.
Wenn ihr Compliance-Dashboards oder Regulatory-Reporting-Tools baut, muesst ihr die vier Schweregrad-Kategorien in eurem System abbilden. Eure Kunden werden fragen: „Wie hoch ist unser regulatorisches Risiko bei diesem Gap?“ Die Antwort liegt in diesem Dokument. Ausserdem: Die Methodik fuer Strafzahlungen enthaelt Berechnungsformeln, die ihr direkt in ein penalty_calculator-Modul uebersetzen koennt – das ist ein konkretes Feature fuer euer Produkt.
AMLA sammelt gerade Daten von Finanzinstituten in der gesamten EU, um ihre Risikobewertungsmodelle zu testen und zu kalibrieren. Stichtag ist der 31. Dezember 2025, Referenzjahr das Kalenderjahr 2025. Die Interpretative Note erklaert die Datenvorlagen, Definitionen und Meldepflichten dieser Uebung.
Warum brisant: Diese Uebung entscheidet faktisch, welche 40 Institute ab 2028 unter Direktaufsicht stehen. Die Datenfelder, die AMLA hier abfragt, zeigen, wonach der Algorithmus sucht.
Die Datenvorlagen sind ein Vorgeschmack auf kuenftige Reporting-Pflichten. Wenn ihr Regulatory-Reporting-Pipelines baut, seht ihr hier die Feldstruktur, die AMLA fuer maschinenlesbare Meldungen erwartet. Die Definitionen – z.B. wie „cross-border activity“ oder „high-risk jurisdiction exposure“ operationalisiert werden – sind direkt uebersetzbar in WHERE-Clauses eurer Daten-Extraktionen.
Ein kompaktes Erklaerdokument, das die gesamte Aufsichtsarchitektur von AMLA zusammenfasst: Welche Entitaeten fallen unter Direktaufsicht? Wie funktioniert die Zusammenarbeit mit nationalen Behoerden? Was passiert beim Uebergang? Der Explainer ist die Landkarte, die ihr braucht, bevor ihr in die technischen Details der RTS eintaucht.
Versteht die Aufsichtsarchitektur, bevor ihr baut. Dieses Dokument klaert, ob euer Kunde an AMLA direkt oder an die nationale Aufsicht meldet – und das bestimmt, welche API-Endpoints, welche Meldeformate und welche Fristen ihr implementieren muesst. Ein System, das die Dualitaet „AMLA-direkt vs. nationale Aufsicht“ nicht abbilden kann, hat ein Architekturproblem.
Das SPD ist AMLAs strategischer Masterplan. Es definiert drei Arbeitsbereiche: Aufsichtsprozesse (10 Mandate), Risikoverstaendnis und Compliance-Massnahmen der Verpflichteten (8 Mandate) und FIU-Kooperation (5 Mandate). Dazu kommt das zentrale AML/CFT-Datenbanksystem, das ab 2027 aufsichtliche Informationen aus allen Mitgliedstaaten buendelt.
Das SPD ist eure Produkt-Roadmap-Inspiration. Es zeigt, welche Guidelines AMLA in Q3 2026 zu Transaction Monitoring und Business-Wide Risk Assessments veroeffentlichen wird. Die zentrale AML/CFT-Datenbank eroeffnet Integrations-Chancen. Wenn AMLA eine standardisierte Datenbasis aufbaut, wird es APIs oder zumindest definierte Dateiformate geben. Fruehzeitig darauf vorbereiten heisst: Wettbewerbsvorteil.
Annex XI zum SPD ist die Masterliste aller geplanten technischen Standards und Guidelines. Rund 80 Instrumente sind aufgefuehrt – mit Rechtsgrundlage, geplantem Veroeffentlichungsdatum und Konsultationszeitraum. Das ist kein Lesedokument, sondern ein Nachschlagewerk, das ihr griffbereit haben solltet.
Druckt euch das aus und haengt es ans Whiteboard. Annex XI zeigt, wann welcher Standard kommt – das bestimmt eure Sprint-Planung fuer die naechsten 18 Monate. Ob Transaction Monitoring Guidelines (Q3 2026), Group-Wide Policy RTS (Juli 2026) oder Beneficial Ownership Standards – hier steht, wann ihr mit Spezifikationsaenderungen rechnen muesst. Das ist euer regulatorisches CHANGELOG.
Die Timeline: Was wann kommt
AMLA arbeitet unter enormem Zeitdruck. Hier die Schluesseldaten, die euer Produkt-Team kennen muss:
Alle 7 Dokumente auf einen Blick
| Prioritaet | Dokument | RegTech-Impact | Deadline |
|---|---|---|---|
| Kritisch | RTS Art. 12(7) – Auswahlmethodik | Risk-Scoring-Datenmodell | Final (Dez. 2025) |
| Kritisch | Draft RTS Art. 28(1) – CDD | KYC-API, Onboarding-Flow | Konsultation bis 8.5.26 |
| Kritisch | Draft RTS Art. 53(10) – Sanktionen | Penalty Calculator, Dashboard | Konsultation beendet |
| Hoch | Interpretative Note – Calibration | Reporting-Schemata, ETL | Datenerhebung laeuft |
| Hoch | Explainer: Direct Supervision | Routing-Logik, Architektur | – |
| Strategisch | SPD 2026–2028 + Explainer | Produkt-Roadmap | – |
| Essentiell | Annex XI – RTS/ITS/GL Planung | Sprint-Planung, Monitoring | – |
Was das fuer euren Tech Stack bedeutet
Die AMLA-Dokumente sind kein abstraktes Policy-Material. Sie haben direkte Auswirkungen auf konkrete technische Entscheidungen, die RegTech-Teams in den naechsten 12–18 Monaten treffen muessen.
Datenmodell & Schema-Migration
Der CDD-RTS (Art. 28) wird neue Pflichtfelder fuer die Kundenidentifikation einfuehren. Wer heute ein starres Schema hat, braucht eine Migrationsstrategie. Die Empfehlung: Baut euer Datenmodell jetzt schon flexibel genug, um zusaetzliche Verifikationsquellen und CDD-Level-spezifische Felder aufzunehmen. Die Draft-Spezifikation liegt vor – nutzt sie als Preview fuer eure Schema-Evolution.
Risk Scoring & Explainability
AMLA fuehrt eine einheitliche Risiko-Taxonomie ein. Eure Scoring-Modelle muessen nicht nur die richtigen Ergebnisse liefern, sondern auch erklaerbar sein. Der RTS Art. 12(7) gibt die Faktoren vor – eure AI-/ML-Modelle muessen diese Faktoren als nachvollziehbare Inputs verwenden. „Explainable AI“ ist nicht mehr optional, sondern regulatorische Erwartung.
Transaction Monitoring
Die fuer Q3 2026 angekuendigten Guidelines werden definieren, was „effektives“ Monitoring bedeutet. Erwartet wird: risikobasierte Kalibrierung statt statischer Schwellenwerte, nachvollziehbare Alert-Logik und durchgehende Audit-Trails. Legacy-Regelwerke mit hunderten unkalibrierter Szenarien werden nicht bestehen. Investiert in praezise, risikobasierte Monitoring-Konfigurationen, die Alert-Volumen senken und gleichzeitig Erkennungsraten erhoehen.
Reporting & Integration
Die zentrale AML/CFT-Datenbank (operativ ab 2027) wird standardisierte Dateiformate und wahrscheinlich API-Schnittstellen fuer den Datenaustausch zwischen AMLA und nationalen Behoerden definieren. Fruehe Vorbereitung auf diese Formate verschafft Wettbewerbsvorteile. Die Datenvorlagen aus der Testing & Calibration Exercise (Dokument #4) sind der erste Hinweis auf die erwartete Struktur.
Nutzt die verbleibende Konsultationsphase aktiv. AMLA nimmt Feedback ernst, und als Technologie-Anbieter koennt ihr auf praktische Implementierungshuerdene hinweisen, die Jurist:innen uebersehen. Reicht eure Stellungnahme zum CDD-RTS bis zum 8. Mai 2026 ein – und dokumentiert es. Es zeigt euren Kunden, dass ihr den regulatorischen Prozess nicht nur beobachtet, sondern mitgestaltet.
Fazit: Lesen ist der billigste Compliance-Move
Die AMLA-Bibliothek ist keine trockene Lektuere fuer Policy-Nerds. Fuer RegTech Engineers sind diese sieben Dokumente Produktspezifikationen – geschrieben von der Behoerde, die ab 2028 entscheidet, ob eure Software den regulatorischen Anforderungen genuegt.
Die gute Nachricht: Alles liegt offen. AMLA veroeffentlicht Entwuerfe, nimmt Feedback an und gibt euch 18 Monate Vorlaufzeit. Die schlechte Nachricht: 18 Monate sind fuer eine Schema-Migration, ein neues Scoring-Modell und angepasste Monitoring-Regeln verdammt knapp. Fangt mit Dokument #1 und #2 an. Heute.
Setzt euch einen Kalender-Reminder fuer den 8. Mai 2026 (Ende CDD-Konsultation), 10. Juli 2026 (Deadline finale RTS) und Q3 2026 (Transaction Monitoring Guidelines). Diese drei Daten bestimmen, wann eure naechsten Spezifikations-Updates kommen. Bookmark: amla.europa.eu/policy/public-consultations
Quellen: Alle Dokumente stammen von amla.europa.eu. Ergaenzende Analysen: Freshfields, Protiviti, Fintech Global, Silent Eight. Stand: 5. April 2026.
