Die AMLA wird oft als institutionelles Projekt erzählt: Frankfurt, neue Behörde, direkte Aufsicht, harmonisiertes Regelwerk. Das ist die Vorderseite. Die Rückseite ist technischer: AMLA übersetzt Geldwäscheprävention in Datenarchitektur.

Mit den Regulatory Technical Standards verschiebt sich AML von der juristischen Auslegung in den Maschinenraum. Die Frage lautet nicht mehr nur, ob ein Institut seine Kunden kennt. Die Frage lautet, ob es Kundenbeziehungen, digitale Zugangspunkte, Transaktionsfenster, Geräte- und Infrastruktursignale so modelliert, dass sie später gegenüber Aufsicht, Revision und Datenschutz erklärbar bleiben.

Konkret stehen zwei Sätze aus dem Konsultationsentwurf zu Artikel 19(9) AMLR im Zentrum. Artikel 2 macht registration providing ongoing access zum Kriterium für die Dauer einer Geschäftsbeziehung. Artikel 3 erlaubt es, Transaktionen über same digital infrastructure als verknüpft zu behandeln, sofern die Information dem Verpflichteten verfügbar ist.

Diese Trennung ist entscheidend. Die IP-Adresse macht keine Geschäftsbeziehung. Sie kann ein Linkage-Signal für verknüpfte Transaktionen sein. Der Architekturkonflikt entsteht genau zwischen diesen beiden Ebenen: digitale Registrierung auf der einen Seite, digitale Infrastruktur als Verbindungsspur auf der anderen.

Das Ende der weichen Prinzipien

Die EBA-Leitlinien ließen vielen Häusern Raum für Interpretation. Die AMLA-RTS gehen weiter. Sie operationalisieren, was bislang im Policy-Handbuch, in der Rechtsabteilung oder im Einzelfall verhandelt wurde.

Aus regulatorischen Begriffen werden Datenfelder. Geburtsort. Staatsangehörigkeiten. Adressstrukturen. Organigramme. Rollen in Unternehmensstrukturen. Kriterien für dauerhafte Kundenbeziehungen. Schwellen für gelegentliche Transaktionen. All das muss nicht nur beschrieben, sondern technisch erfasst, versioniert, geprüft, verknüpft und ausgewertet werden.

AMLA ist kein Formular-Update. AMLA ist ein Umbau des KYC-Datenmodells.

Die Falle der digitalen Registrierung

Besonders heikel ist die Grenze zwischen gelegentlicher Transaktion und dauerhafter Geschäftsbeziehung. In der analogen Welt war sie leichter zu erzählen: Ein Kunde kommt einmal an den Schalter oder er eröffnet ein Konto. Digitale Geschäftsmodelle funktionieren anders.

Ein Nutzer registriert sich in einer App, klickt sich durch ein Portal, legt ein Profil an, nutzt den Dienst einmal, kehrt Monate später zurück oder bricht den Prozess ab. Ist das schon eine Geschäftsbeziehung? Oder nur ein digitaler Vorraum?

Artikel 2 Absatz 1 formuliert knapp: Verpflichtete sollen die Nutzung von Online-Diensten durch Registrierung mit fortlaufendem Zugang als Kriterium für die Dauer berücksichtigen. Recital 7 begründet das damit, dass bereits Registrierung typischerweise eine gewisse Dauer der Leistungserbringung erwarten lässt.

Aus Aufsichtssicht ist das nachvollziehbar. Aus IT-Sicht ist es ein Minenfeld. Viele Systeme kennen nur grobe Zustände: Lead, registrierter Nutzer, verifizierter Kunde, aktiver Kunde. Für AMLA reicht das nicht mehr. Es braucht ein Customer-Lifecycle-Modell, das regulatorische Zustände von Marketing-, Produkt- und Authentifizierungszuständen trennt.

Sonst entsteht Overclassification: Menschen werden zu früh zu Kundenbeziehungen, Due-Diligence-Prozesse zu früh ausgelöst, Monitoring-Pflichten zu früh erweitert. Das klingt nach Vorsicht. In Wahrheit kann es ein Qualitätsproblem werden, weil Systeme in künstlich erzeugtem Risiko ersticken.

Linked Transactions und das Problem schwacher Signale

Noch brisanter wird es bei verknüpften Transaktionen. Artikel 3 Absatz 1 zählt nicht nur Transaktionen derselben natürlichen oder juristischen Person auf. Hinzu kommen Familienmitglieder, Geschäftspartner, Kunden, die operating in concert handeln, gemeinsame Mutterunternehmen, gemeinsame Intermediäre und die Nutzung derselben digitalen Infrastruktur.

Recital 13 macht klar, was damit gemeint sein kann: dieselbe IP-Adresse, derselbe Device-Identifier, dieselbe Geolokation. Der Zweck ist offen benannt: komplexere Umgehung der CDD-Schwellen, etwa viele Zahlungen knapp unterhalb der Schwelle von vielen Zahlern an viele Empfänger.

Regulatorisch ist das konsequent. Es ist die Antwort auf strukturiertes Smurfing über mehrere Gegenparteien. Aus IT-Sicht steckt darin trotzdem eine Architekturfalle.

Denn viele dieser Signale sind schwach. Eine IP-Adresse beweist keine gemeinsame Kontrolle. Ein Device kann geteilt werden. Eine Geolokation aus einem öffentlichen WLAN sagt wenig über Personen. Ein Händlerterminal verbindet Kunden, die sich nie begegnet sind.

False Positives sind dann kein Betriebsproblem mehr. Sie sind das Ergebnis einer falschen Ontologie.

Auch operating in concert ist enger zu lesen, als der Begriff vermuten lässt. Gemeint sind Kunden, die gemeinsam erscheinen oder sich vor oder während der Transaktion koordinieren. Das ist eine Beobachtung im Prozess, kein abstraktes Datenmuster aus dem Nachhinein.

Datenschutz ist kein Randthema

Wer IP-Adressen, Gerätekennungen, digitale Zugangsmuster, Familienbeziehungen oder Infrastrukturmerkmale über Zeitfenster aggregiert, baut Bewegungs- und Beziehungskarten. Diese Karten können für AML nützlich sein. Sie können aber auch unverhältnismäßig, intransparent oder zweckentfremdet werden.

Der entscheidende Satz lautet: Nur weil ein Signal technisch verfügbar ist, ist es noch nicht legitim nutzbar.

Recital 11 des Art.-19(9)-Entwurfs grenzt die Pflicht ein: Kriterien wie digitale Infrastruktur gelten nur auf Basis verfügbarer Information. Hat der Verpflichtete keinen Zugang und muss er keinen Zugang haben, muss er die Information nicht allein für diese RTS vom Kunden beschaffen. Recital 21 des Art.-28(1)-Entwurfs ist anders gelagert: Bereits vorhandene KYC-, Audit- oder Gruppeninformationen sollen vor Doppelerhebung geprüft werden.

Beides ist Entlastung. Beides ist aber auch eine Falle. Denn Verfügbarkeit ist kein neutraler Zustand. Sie ist eine Architekturentscheidung. Wer Daten nutzt, muss die Nutzung erklären. Wer Daten nicht nutzt, muss die Nichtnutzung erklären. Wer sie im Konzern besitzt, aber im Linkage-Prozess nicht erreicht, muss die eigene Datenarchitektur erklären.

Von Monitoring zu Observability

Der Ausweg liegt nicht in noch mehr Schwellenwerten. Klassisches Transaktionsmonitoring fragt: Wann löst ein Ereignis einen Alert aus?

AML Observability fragt mehr. Woher kam das Signal? Wie wurde es transformiert? Welche Regel hat es berührt? Welche Annahme steckt in der Aggregation? Welche Daten wurden bewusst nicht genutzt? Welche Entscheidung wurde getroffen? Und lässt sich diese Kette später rekonstruieren?

Monitoring sieht das Ereignis. Observability rekonstruiert die Ursache. Genau hier liegt die redaktionelle Pointe: AMLA macht AML-Systeme erklärungspflichtig.