Leitstück 05 · AMLA · FinCrime-Architektur 2026

AMLA-RTS als State Machine

Die Grenze zwischen gelegentlicher Transaktion und Geschäftsbeziehung ist die unschärfste Linie der Geldwäschebekämpfung. Das EU-Single-Rulebook zwingt sie in ein Modell — und ein Modell mit Schwellen, Absicht und verbundenen Transaktionen ist eine Zustandsmaschine.

Wann wird aus einem Kunden eine Geschäftsbeziehung? Die meisten Systeme beantworten das einmal, beim Onboarding, mit einem Häkchen — und nie wieder. Das war schon immer fragwürdig, und mit der EU-Geldwäscheverordnung wird es untragbar. Denn diese Grenze entscheidet, ob die volle Sorgfaltspflicht greift, ob laufend überwacht wird, ob ein Vorgang als gelegentliche Transaktion durchrutscht oder als dauerhafte Beziehung erfasst werden muss. Eine Linie, an der so viel hängt, darf kein Bauchgefühl beim Kontoeröffnen sein. Sie muss ein Zustand sein, der sich nachvollziehbar ändert.

Genau dahin bewegt die AMLA das Recht. Mit den Regulatory Technical Standards nach Artikel 19(9) der AML-Verordnung (AMLR, Verordnung (EU) 2024/1624) operationalisiert die Behörde, woran man eine „Geschäftsbeziehung“, eine „gelegentliche Transaktion“ und „verbundene Transaktionen“ erkennt. Das sind keine begrifflichen Spitzfindigkeiten. Es sind Eintrittskriterien, Schwellen und Aggregationsregeln — also exakt die Bausteine, aus denen Ingenieure Zustandsmaschinen bauen.

Warum diese Grenze über alles entscheidet

Die AMLR knüpft die Sorgfaltspflichten an klar benannte Auslöser. Wird eine Geschäftsbeziehung begründet, ist die volle Kundensorgfaltspflicht (CDD) fällig — immer. Bei einer bloß gelegentlichen Transaktion greift sie erst ab einer Schwelle. Diese Schwelle ist mit dem neuen Rahmen gesunken: von vormals 15.000 € auf 10.000 €, ob als Einzeltransaktion oder als Summe verbundener Transaktionen. Für Bargeschäfte gelten eingeschränkte Pflichten bereits ab 3.000 €, und für einzelne Sektoren — etwa Geldtransfers oder Krypto-Dienstleister — sieht das Regelwerk niedrigere oder gar keine Schwellen vor.

Wer diese Grenze falsch zieht, scheitert in beide Richtungen. Zu früh oder zu breit erfasst, sammelt das Institut personenbezogene Daten ohne Rechtsgrundlage und verbrennt Kapazität an Vorgängen, die keine Beziehung sind. Zu spät oder zu eng erfasst, entgeht ihm genau die laufende Überwachung, deren Fehlen den Santander-Fall aus Leitstück 04 so teuer gemacht hat. Die richtige Linie ist nicht streng oder lax — sie ist nachvollziehbar gezogen.

Das Legacy-Muster: ein Häkchen beim Onboarding

In gewachsenen Systemen ist der Status „Geschäftsbeziehung“ meist ein boolesches Feld, gesetzt im Moment der Kontoeröffnung und danach unangetastet. Dieses Muster hat drei eingebaute Defekte. Es kennt keine Absicht: Der Kunde, der „nur einmal“ überweisen wollte und dann monatlich wiederkommt, bleibt formal eine Kette gelegentlicher Transaktionen. Es aggregiert nicht: Zehn Überweisungen zu je 1.500 € innerhalb einer Woche bleiben zehn harmlose Einzelvorgänge, obwohl ihre Summe die Schwelle längst überschreitet — das klassische Smurfing. Und es kann der Aufsicht nicht erklären, wann und warum aus dem Kunden eine Beziehung wurde, weil es nie einen Übergang gab, nur einen Anfangszustand.

Ein boolesches Feld kennt keine Geschichte. Es weiß, dass jemand Kunde ist — aber nicht, wann er es wurde, warum, und ob die Schwelle dazwischen je überschritten wurde.

Der Reframe: eine Zustandsmaschine

Die Abgrenzung wird beherrschbar, sobald man sie als das modelliert, was sie ist: ein Objekt mit Zuständen und erlaubten Übergängen. Eine Kundeninteraktion beginnt im Zustand KEINE_BEZIEHUNG. Eine erste Transaktion führt sie in GELEGENTLICH. Von dort führen klar benannte, bewachte Übergänge nach GESCHÄFTSBEZIEHUNG — und jeder dieser Übergänge erzeugt ein Ereignis, das die Sorgfaltspflicht auslöst und im EvidencePackage (Leitstück 02) sowie auf dem geteilten Ereignisstrom (Leitstück 04) sichtbar wird.

Zwei Begriffe machen das Modell tragfähig. Der erste ist InteractionIntent — die Absicht hinter der Interaktion, sowohl die vom Kunden erklärte als auch die aus dem Verhalten abgeleitete. Wer eine dauerhafte Beziehung erklärt, ist ab der ersten Sekunde eine Geschäftsbeziehung, ganz ohne Schwelle. Der zweite ist das Schwellen-Ereignis — ausgelöst nicht von einer einzelnen Transaktion, sondern von der aggregierten Summe verbundener Transaktionen innerhalb eines Fensters.

Erklärte und abgeleitete Absicht

Der InteractionIntent hat zwei Quellen, und beide gehören ins Modell. Die erklärte Absicht stammt vom Kunden beim Onboarding: „eine einmalige Überweisung“ gegen „ein laufendes Konto“. Die abgeleitete Absicht entsteht aus dem Verhalten über die Zeit — und sie widerspricht der Erklärung oft. Die dritte wiederkehrende Überweisung an dieselbe Gegenstelle ist nicht mehr glaubhaft eine Kette gelegentlicher Transaktionen; sie ist eine Geschäftsbeziehung, die die ursprüngliche Erklärung verfehlt hat.

Ein belastbares Modell hält beide Werte und lässt die abgeleitete Absicht die erklärte überschreiben, wenn das Verhalten ihr widerspricht — protokolliert mit Grund. Genau hier trifft die Zustandsmaschine auf den Monitoring-Kontext aus Leitstück 04: Die Ableitung ist ein Verhaltenssignal, das als Ereignis hereinkommt und einen Übergang auslösen kann. Zugleich ist Vorsicht geboten, denn das Ableiten von Absicht aus Verhalten ist Profiling im datenschutzrechtlichen Sinn. Die Zweckbindung aus Leitstück 03 gilt fort: Die Ableitung dient der Sorgfaltspflicht, nicht beliebiger Weiterverwertung.

Verbundene Transaktionen: das Fenster gegen Smurfing

Der heikelste Teil der RTS ist die Definition „verbundener“ Transaktionen — denn an ihr entscheidet sich, ob die künstliche Zerlegung eines Betrags in viele kleine unter der Schwelle bleibt oder erkannt wird. „Verbunden“ ist selbst eine Modellierungsentscheidung: über welches Zeitfenster wird aggregiert, welche Merkmale (gleiche Parteien, gleicher Zweck, gleiche Gegenstelle) machen Transaktionen zu einer Einheit? Die Architektur muss diese Kriterien explizit halten — als konfigurierbares Aggregationsfenster, nicht als verstreute Wenn-Dann-Logik.

Python · Die Abgrenzung als bewachte Zustandsmaschinefrom dataclasses import dataclass, field
from datetime import datetime, timedelta, timezone
from enum import Enum

class RelState(Enum):
    NO_RELATIONSHIP = "no_relationship"
    OCCASIONAL      = "occasional"
    BUSINESS        = "business_relationship"  # volle CDD

class Intent(Enum):
    ONE_OFF = "one_off"
    ONGOING = "ongoing"      # erklärte Dauerhaftigkeit
    UNKNOWN = "unknown"

OCCASIONAL_THRESHOLD = 10_000     # € — AMLR Art. 19
LINK_WINDOW = timedelta(days=30)         # "verbunden": konfigurierbar (RTS)

@dataclass(frozen=True)
class Tx:
    at: datetime
    amount: float
    counterparty: str

class CustomerInteraction:        # Aggregate Root + State Machine
    def __init__(self):
        self.state = RelState.NO_RELATIONSHIP
        self.intent = Intent.UNKNOWN
        self._window: list[Tx] = []
        self.events: list[dict] = []

    def declare_intent(self, intent: Intent):
        self.intent = intent
        if intent is Intent.ONGOING and self.state is not RelState.BUSINESS:
            self._become_business("erklärte Dauerhaftigkeit")  # ohne Schwelle

    def observe(self, tx: Tx):
        if self.state is RelState.NO_RELATIONSHIP:
            self.state = RelState.OCCASIONAL
        # verbundene Transaktionen im Fenster aggregieren
        self._window = [t for t in self._window if tx.at - t.at <= LINK_WINDOW]
        self._window.append(tx)
        linked_sum = sum(t.amount for t in self._window)
        if linked_sum >= OCCASIONAL_THRESHOLD and self.state is not RelState.BUSINESS:
            self._emit("ThresholdBreached", sum=linked_sum, count=len(self._window))
            self._become_business(f"Σ verbunden = {linked_sum:.0f} €")

    def _become_business(self, reason: str):
        self.state = RelState.BUSINESS
        self._emit("RelationshipEstablished", reason=reason)
        self._emit("CddTriggered", scope="full")   # speist EvidencePackage / Stream

    def _emit(self, name: str, **data):
        self.events.append({"event": name, "at": datetime.now(timezone.utc), **data})

Drei Eigenschaften machen diesen Code aufsichtsfest. Erstens gibt es keinen direkten Setter für state — der Zustand wechselt nur über bewachte Methoden, die ihre Bedingung prüfen und ein Ereignis hinterlassen (dieselbe Disziplin wie das Aggregate in Leitstück 02). Zweitens trägt jeder Übergang seinen Grund mit: „erklärte Dauerhaftigkeit“ oder „Σ verbunden = 10.800 €“. Drittens ist das Aggregationsfenster eine benannte Konstante, kein verstreuter Magic Value — wenn die finalen RTS das Fenster oder die Schwelle anders fassen, ändert sich genau eine Stelle.

Rückwirkung: wenn die Schwelle nachträglich fällt

Aggregation hat eine unbequeme Eigenschaft: Sie deckt erst im Nachhinein auf, dass eine Grenze überschritten wurde. Bei der sechsten Überweisung steht fest, dass die Summe der verbundenen Transaktionen die Schwelle reißt — aber die Beziehung begann nicht erst mit der sechsten. Was rückwirkend wahr wird, ist, dass die ganze Folge im Sinne der RTS verbunden war.

Die Zustandsmaschine muss diesen Doppelcharakter ehrlich abbilden. Sie datiert den Übergang auf den Moment der Erkennung — das Schwellen-Ereignis —, hält aber zugleich die beitragenden Transaktionen bis zum Fensterbeginn fest. Für die Aufsicht hat „seit wann ist das eine Geschäftsbeziehung?“ damit zwei redliche Antworten: seit wann das Muster bestand und seit wann das Institut es erkannt hat. Beide gehören ins Protokoll. Was die Architektur nicht tun darf, ist stilles Rückdatieren: Der Zustand wird nicht heimlich auf die erste Transaktion zurückgeschrieben, sondern der Erkennungszeitpunkt wird als eigenes Ereignis dokumentiert. Nur so bleibt nachvollziehbar, dass das System nicht im Nachhinein zurechtgelegt wurde — dieselbe Anforderung an Unveränderlichkeit wie beim Event Ledger aus Leitstück 03.

Wann die Beziehung endet

Eine vollständige Zustandsmaschine braucht einen Ausgang. Wird eine Geschäftsbeziehung beendet, geht sie nicht ins Nichts, sondern in einen Zustand BEENDET — und auch dieser Übergang trägt Folgen. Die Aufbewahrungspflichten überleben die Beziehung: Unterlagen und Belege bleiben über die gesetzliche Frist erhalten, auch wenn das Konto geschlossen ist. Eine Wiederaufnahme führt nicht zurück auf null, sondern erneut in den Lebenszyklus, mit dem Wissen aus der Historie.

Wichtig ist die Unterscheidung, die ein boolesches Feld gar nicht treffen kann: Ruhend ist nicht beendet. Ein dormantes Konto ohne Aktivität ist keine geschlossene Beziehung — es bleibt überwachungsrelevant, und ein plötzliches Wiederaufleben ist selbst ein Signal. Die Zustandsmaschine hält diese Fälle auseinander, weil an ihnen unterschiedliche Pflichten hängen. Wer „Kunde ja/nein“ speichert, verliert genau diese Differenzierung — und mit ihr die Fähigkeit, fortbestehende Pflichten korrekt zu bedienen.

Was die Zustandsmaschine für die Aufsicht leistet

Die AMLA prüft nicht mehr nur, ob ein Verfahren existiert, sondern ob es im Einzelfall nachvollziehbar gewirkt hat (Leitstück 02). Auf die Frage „Seit wann ist das eine Geschäftsbeziehung, und warum?“ antwortet ein boolesches Feld mit Schweigen. Eine Zustandsmaschine antwortet mit einem Zeitstempel, einem Übergang und einem Grund — und mit dem Schwellen-Ereignis, das die Aggregation verbundener Transaktionen belegt. Aus der unschärfsten Linie der Compliance wird so ein prüfbarer Vorgang.

Damit schließt sich der Bogen zu den vorherigen Stücken. Die Sprache aus Leitstück 01 hat „Geschäftsbeziehung“ als Zustand mit Eintrittskriterium definiert; hier wird dieser Zustand technisch. Das Aggregate aus Leitstück 02 hält den Vorgang konsistent; die Zustandsmaschine ist sein Lebenszyklus. Und der Ereignisstrom aus Leitstück 04 transportiert die ausgelösten CDD-Ereignisse dorthin, wo Fraud, Monitoring und Reporting sie brauchen.

Ein durchgespielter Fall

Ein Kunde wird angelegt und erklärt eine einmalige Überweisung — der Intent steht auf ONE_OFF, die erste Transaktion bringt den Zustand auf GELEGENTLICH. Über drei Wochen folgen sechs Überweisungen zu je rund 1.800 € an dieselbe Gegenstelle. Die Transaktionen eins bis fünf wandern ins Aggregationsfenster; ihre Summe bleibt unter 10.000 €, jede einzelne ist unauffällig. Bei der sechsten erreicht die Summe der verbundenen Transaktionen 10.800 € — das Modell erzeugt ein ThresholdBreached-Ereignis mit Summe und Anzahl, wechselt in GESCHÄFTSBEZIEHUNG und feuert RelationshipEstablished mit dem Grund „Σ verbunden = 10.800 €“ sowie CddTriggered mit vollem Umfang.

Diese Ereignisse fließen als Claim mit Provenienz in das EvidencePackage (Leitstück 02) und auf den geteilten Strom, wo Monitoring und Fraud sie sehen (Leitstück 04). Fragt die Aufsicht ein Jahr später, lautet die Antwort nicht „Häkchen war gesetzt“, sondern: erkannt bei Transaktion sechs am Datum X, weil die verbundene Summe die Schwelle überschritt, gestützt auf die fünf beitragenden Transaktionen zurück bis zum Fensterbeginn am Datum Y. Hätte derselbe Kunde beim Onboarding stattdessen eine dauerhafte Nutzung erklärt, wäre declare_intent(ONGOING) sofort in die Geschäftsbeziehung gesprungen — ganz ohne Schwelle, ganz ohne Wartezeit. Derselbe Endzustand, zwei verschiedene, jeweils dokumentierte Wege.

Kernsätze

Die Zustandsmaschine ordnet, ob und wann eine Beziehung entsteht. Doch sobald aus Transaktionen Netzwerke werden — verbundene Parteien, Gegenstellen, wirtschaftlich Berechtigte —, reicht der Zustand eines einzelnen Kunden nicht mehr. Dann braucht es den Graphen. Warum eine Kante allein nichts beweist, klärt Leitstück 06: Der Graph beweist nichts.

Markiert: AMLA · AMLR · RegTech Architecture · KYC · Domain-Driven Design · Architektur