Leitstück 04 · FRAML · FinCrime-Architektur 2026

FRAML braucht gemeinsame Events, keine gemeinsame Abteilung

Fraud und AML konvergieren nicht durch Organigramme. Sie konvergieren über einen geteilten Ereignisstrom und sauber getrennte Bounded Contexts — sonst entsteht aus zwei Silos nur ein größeres.

Die übliche Antwort auf FRAML ist ein Reporting-Strich im Organigramm: Fraud- und Geldwäsche-Team wandern unter eine gemeinsame Leitung, bekommen ein gemeinsames Dashboard, vielleicht ein gemeinsames Tool — und gelten fortan als „konvergiert“. Das fühlt sich nach Fortschritt an und ist meist keiner. Zwei Teams unter einer Vizepräsidentin teilen sich eine Kostenstelle, nicht zwingend eine Wahrheit. Wer Fraud und AML wirklich zusammenführen will, muss tiefer ansetzen: nicht bei der Berichtslinie, sondern bei den Ereignissen, auf die beide schauen.

Denn Fraud und AML sehen längst dieselbe Wirklichkeit — eine Zahlung, ein Onboarding, ein neues Gerät, ein neuer Gegenpart — nur mit verschiedenen Fragen. Der Betrugsabwehr geht es um den unmittelbaren Schaden: Ist diese Transaktion in diesem Moment autorisiert und echt? Der Geldwäschebekämpfung geht es um das Muster über die Zeit: Fügt sich dieses Verhalten in eine Typologie, ein Netzwerk, einen Verdacht? Beide Fragen treffen denselben Vorgang. Konvergenz heißt, diesen Vorgang einmal sauber als Ereignis zu erfassen — und beide Kontexte daraus ihre je eigene Antwort ziehen zu lassen.

Warum Fraud und AML zusammenrücken

Der Druck zur Konvergenz ist real und kommt von mehreren Seiten zugleich. Echtzeitzahlungen verkürzen das Reaktionsfenster dramatisch: Unter der EU-Verordnung über Instant Payments (Verordnung (EU) 2024/886) müssen Zahlungsdienstleister im Euroraum seit dem 9. Oktober 2025 einen Abgleich von Empfängername und IBAN („Verification of Payee“) anbieten, und Überweisungen werden in Sekunden final. Was früher Tage Prüfzeit hatte, entscheidet sich jetzt vor der Autorisierung — klassisches Fraud-Terrain, aber mit unmittelbaren AML-Folgen, weil dieselben Sekunden auch das Zeitfenster für Mule-Netzwerke und Layering öffnen.

Hinzu kommen Online-Marktplätze, KI-gestützte Betrugsmaschen und Geldwäschetypologien, die Betrug und Wäsche verschmelzen: Der erbeutete Betrag aus einem Authorised-Push-Payment-Betrug wird im selben Atemzug über Mule-Konten weitergeleitet. Branchenerhebungen beziffern die kumulierten weltweiten Verluste durch Online-Zahlungsbetrug für die Jahre 2024 bis 2027 auf eine dreistellige Milliardenhöhe, mit Europa als erheblichem Anteil — die genaue Zahl variiert je Quelle, die Größenordnung nicht. Aufseher von FinCEN bis EBA erwarten die Zusammenführung zunehmend explizit, und sie fügt sich in den risikobasierten Ansatz der FATF. FRAML ist damit weniger Trend als Erwartung.

Echtzeitzahlung heißt: Das Betrugsfenster und das Geldwäschefenster fallen im ersten Moment zusammen. Wer sie organisatorisch trennt, trennt, was die Zahlung selbst nicht trennt.

Der Reflex „gemeinsame Abteilung“ — und warum er scheitert

Die Fusion der Teams scheitert nicht an bösem Willen, sondern an drei strukturellen Unterschieden, die ein Organigramm nicht auflöst.

Verschiedene Ontologien. Fraud und AML sprechen, wie in Leitstück 01 gezeigt, verschiedene Sprachen. „Risiko“ meint im Fraud-Kontext die Wahrscheinlichkeit einer nicht autorisierten Transaktion in diesem Moment; im AML-Kontext das Geldwäscherisiko einer Geschäftsbeziehung über die Zeit. Zwingt man beide unter ein gemeinsames Datenmodell, kollabieren diese Bedeutungen — und man verliert genau die Unterscheidung, die beide Disziplinen ausmacht.

Verschiedene Zeithorizonte. Fraud entscheidet vor oder im Moment der Autorisierung, in Millisekunden. AML beobachtet Muster über Tage, Wochen, Monate. Ein gemeinsames System, das beiden Takten genügen soll, wird entweder für Echtzeit zu schwer oder für Mustererkennung zu kurzatmig. Die Zeithorizonte sind nicht verhandelbar; sie folgen aus der Sache.

Verschiedene Erfolgsmaße und Rechtsregime. Fraud misst sich an verhindertem Schaden, AML an der Qualität von Verdachtsmeldungen und der Wirksamkeit gegenüber der Aufsicht. Die Rechtsgrundlagen können sich unterscheiden, und damit auch, was mit den Daten zu welchem Zweck geschehen darf. Eine gemeinsame Abteilung mit gemischten Zwecken ist datenschutzrechtlich heikler, nicht einfacher.

Das gern zitierte Allheilmittel „Master Data Management“ — ein einheitlicher Satz an Kunden-, Konto- und Transaktionsstammdaten — ist notwendig, aber nicht hinreichend. Gemeinsame Datensätze sind noch keine gemeinsame Bedeutung. Ein einheitlicher Kundenstamm sagt nichts darüber, ob „verdächtig“ im Fraud- und im AML-Sinn dasselbe heißt. Die Integration muss eine Ebene höher ansetzen.

Was wirklich konvergiert: das Ereignis

Der Konvergenzpunkt ist nicht die Abteilung und nicht das Datenmodell, sondern das Ereignis. Eine Zahlung wird einmal initiiert, ein Konto einmal eröffnet, ein Gerät einmal beobachtet. Wenn diese Tatsachen als sauber typisierte, unveränderliche Events auf einem geteilten Strom liegen, können Fraud und AML denselben Strom abonnieren — und jeder projiziert ihn in sein eigenes Modell. Das ist die Antwort des Domain-Driven Design: eine gemeinsam verantwortete, veröffentlichte Sprache des Ereignisstroms — im DDD am ehesten eine Published Language mit einem klein gehaltenen, gemeinsam besessenen Schema-Kern —, aber getrennte Bounded Contexts dahinter.

Entscheidend ist die Richtung der Kopplung. Die Kontexte koppeln an die Ereignisse, nicht aneinander. Der Fraud-Kontext muss nicht wissen, wie der AML-Kontext „Structuring“ modelliert, und umgekehrt. Beide wissen nur, was ein PaymentInitiated-Event bedeutet — und dessen Bedeutung ist gemeinsam definiert, versioniert und getestet wie jede andere Sprache aus Leitstück 01.

Bounded Contexts sauber trennen

Die Versuchung, „weil es ja jetzt FRAML ist“, ein einziges großes Modell für beide Welten zu bauen, ist genau der Fehler, den die Event-Architektur vermeidet. Der Fraud-Kontext lebt in Millisekunden, dreht sich um Gerät, Geschwindigkeit, Sitzungsverhalten und Pre-Authorization-Entscheidungen. Der AML-Kontext lebt in Mustern über Zeit, dreht sich um Typologien, Netzwerke, wirtschaftlich Berechtigte und Verdachtsmeldungen. Würden sie ein Modell teilen, müsste jede Änderung an der einen Seite gegen die andere abgesichert werden — die Kopplung, die FRAML eigentlich auflösen soll, kehrte durch die Hintertür zurück.

Was beide teilen, ist allein die veröffentlichte Sprache des Ereignisstroms — und an jeder Kontextgrenze sitzt ein Anti-Corruption Layer (Leitstück 01), der das geteilte Event in das eigene Vokabular übersetzt. So bleibt jeder Kontext intern frei, sein Modell zu entwickeln, ohne den anderen zu brechen.

Python · Geteilter Ereignisstrom, getrennte Kontextefrom dataclasses import dataclass
from datetime import datetime, timezone

# ---- Shared Kernel: die veröffentlichte Sprache (gemeinsam besessen) ----
@dataclass(frozen=True)
class PaymentInitiated:
    event_id: str
    occurred_at: datetime
    payer_ref: str
    payee_ref: str
    amount: float
    channel: str          # z.B. "instant_sepa"
    declared_purpose: str # vom Kunden angegebener Zweck
    schema_version: str = "1.2"   # versioniert wie jede Sprache (LS 01)

# ---- Fraud Context: eigenes Modell, eigene Frage ----
class FraudContext:
    def on_payment(self, e: PaymentInitiated, bus):
        # Echtzeit: Gerät, Velocity, Pre-Auth — in Millisekunden
        risk = self._score_realtime(e)
        if risk > 0.9:
            # speist EIGENES Verdikt als neues Event zurück
            bus.publish(FraudSignalRaised(
                event_id=e.event_id, kind="push_payment_anomaly",
                confidence=risk, occurred_at=datetime.now(timezone.utc)))

# ---- AML Context: eigenes Modell, andere Frage, anderer Takt ----
class AmlContext:
    def on_payment(self, e: PaymentInitiated, store):
        # Muster über Zeit: Typologie, Netzwerk — kein Echtzeitzwang
        store.append_for_pattern_analysis(e)

    def on_fraud_signal(self, s, evidence):
        # konsumiert das Fraud-Verdikt als Claim MIT Provenienz (LS 02)
        evidence.add_claim(Claim(
            statement=f"Fraud-Signal {s.kind} auf Vorgang {s.event_id}",
            provenance=Provenance(source_id="fraud_ctx",
                                  retrieved_at=datetime.now(timezone.utc),
                                  method_ref="realtime_scorer_v4"),
            confidence=s.confidence))

Man beachte: Der AML-Kontext konsumiert das Fraud-Verdikt nicht als rohe Wahrheit, sondern als Claim mit Provenienz — exakt die Invariante aus Leitstück 02. Das Fraud-Signal ist für AML eine Beobachtung mit deklarierter Herkunft, nicht ein fertiger Verdacht. So bleibt die Beweiskette sauber, auch wenn sie über Kontextgrenzen hinweg verläuft. Der hier nur angedeutete bus ist in der Praxis ein Domain-Event-Dispatcher oder ein Message-Broker wie Kafka; entscheidend ist nicht das Produkt, sondern dass die Events typisiert, geordnet und für beide Kontexte konsumierbar sind.

Der Santander-Lehrsatz

Wie teuer die fehlende Verbindung ist, zeigt ein bekannter Fall. Die britische FCA verhängte am 8. Dezember 2022 gegen Santander UK ein Bußgeld von 107,7 Millionen Pfund wegen anhaltender Mängel in den Geldwäschekontrollen. Kern des Versagens: Die Bank überwachte nicht hinreichend, was Kunden als erwarteten Geschäftsumsatz angegeben hatten, gegen das, was tatsächlich über die Konten lief — bei mehr als einer halben Million Geschäftskunden. Über 298 Millionen Pfund flossen durch, bevor Konten geschlossen wurden; automatisierte Monitoring-Alerts und „rote Flaggen“ wurden zu spät bearbeitet.

Formal war dies ein AML-Kontrollfall, kein „FRAML-Fall“; die architektonische Lektion daraus gilt aber domänenübergreifend. Der entscheidende Punkt für FRAML: Die Diskrepanz zwischen deklariertem und tatsächlichem Geldfluss ist ein Signal, das in beide Welten zeigt. Es ist ein Onboarding-/Verhaltenssignal, wie es die Betrugsabwehr kennt — und zugleich ein klassischer Geldwäsche-Indikator. Das Versagen war nicht das Fehlen einer gemeinsamen Abteilung. Es war, dass diese Information nicht als Ereignis dort ankam, wo sie zu einem Verdacht hätte werden können. Eine Architektur, in der das declared_purpose-Feld eines PaymentInitiated-Events gegen das beobachtete Verhalten läuft und Abweichungen als Event an den AML-Kontext meldet, hätte genau diese Lücke geschlossen — ganz ohne Organigramm-Umbau.

Geldwäsche scheitert selten an fehlenden Daten. Sie gelingt, weil die richtigen Daten im falschen Kontext liegen und nie als Ereignis dorthin reisen, wo sie zum Verdacht werden.

Ein Migrationspfad ohne Big Bang

Der häufigste Einwand gegen diese Architektur ist nicht konzeptioneller, sondern praktischer Natur: „Wir haben zwei gewachsene Plattformen, ein Fraud-Engine-Monolith und ein AML-System mit zehn Jahren Regelwerk — wir können nicht einfach alles neu bauen.“ Müssen sie auch nicht. Der Weg zum geteilten Strom ist evolutionär, nicht revolutionär.

Schritt eins ist rein additiv: Die bestehenden Systeme bleiben, wie sie sind, beginnen aber, ihre fachlichen Tatsachen als Events auf einen gemeinsamen Strom zu veröffentlichen — zunächst ohne dass jemand sie konsumiert. Eine Zahlung, die ohnehin verarbeitet wird, emittiert zusätzlich ein PaymentInitiated. Das ändert am Verhalten der Altsysteme nichts, schafft aber die Faktenbasis. Schritt zwei führt die ersten Konsumenten ein: Der AML-Kontext abonniert ausgewählte Fraud-Events, der Fraud-Kontext ausgewählte AML-Verdikte — jeweils über einen Anti-Corruption Layer, der die fremde Sprache in die eigene übersetzt. Erst Schritt drei verlagert Logik nach und nach aus den Monolithen in die sauber geschnittenen Kontexte; was nicht gewandert ist, bleibt vorerst, wo es ist.

Das ist im Kern das Strangler-Fig-Muster: Der neue Aufbau wächst um den alten herum, bis dieser nur noch das Wenige hält, das sich nicht zu migrieren lohnt. Der entscheidende Vorteil für ein reguliertes Institut ist, dass jeder Schritt für sich auditierbar und reversibel ist. Es gibt keinen Stichtag, an dem die Geldwäscheüberwachung „umgeschaltet“ wird — ein Risiko, das weder die Aufsicht noch ein Vorstand gern trägt. Stattdessen wächst die Konvergenz dort zuerst, wo der geteilte Strom den größten Nutzen bringt: an den domänenübergreifenden Signalen wie dem deklarierten-gegen-tatsächlichen Geldfluss, an dem der Santander-Fall scheiterte.

Governance des geteilten Stroms

Ein geteilter Ereignisstrom verlagert die eigentliche Arbeit auf seine Sprache — und die braucht Eigentümerschaft. Das Schema der Events ist die veröffentlichte Sprache aus Leitstück 01: Es gehört keinem der beiden Kontexte allein, sondern wird gemeinsam verantwortet, versioniert und mit Tests abgesichert. Ein schema_version-Feld ist kein Beiwerk, sondern die Voraussetzung dafür, dass der Fraud-Kontext sein Modell ändern kann, ohne den AML-Kontext stillschweigend zu brechen. Operativ heißt das: Eine Schema Registry erzwingt die Kompatibilität der Versionen, und jeder Kontext führt seine eigenen Consumer Offsets — so liest Fraud in Echtzeit und AML im eigenen Takt denselben Strom, ohne sich gegenseitig auszubremsen.

Zweitens ist der Strom selbst auditpflichtig. Welcher Kontext welches Event wann konsumiert und welches Verdikt er zurückspeist, gehört in das append-only Event Ledger aus Leitstück 03 — sonst lässt sich später nicht rekonstruieren, warum ein Vorgang in dem einen Kontext eskalierte und im anderen nicht. Und drittens ist die Zweckbindung scharf zu halten: Ein Event, das im Fraud-Kontext zur Schadensabwehr erhoben wurde, darf im AML-Kontext nur verarbeitet werden, soweit die Rechtsgrundlage das trägt. Geteilte Events sind kein Freibrief, alles für alles zu nutzen — die Datenminimierung aus Leitstück 03 gilt über Kontextgrenzen hinweg fort.

Kernsätze

Damit steht die Integrationslogik des Operating Models: geteilte Ereignisse, getrennte Kontexte, eine Beweiskette, die über Grenzen hinweg sauber bleibt. Sobald aber Echtzeitzahlungen das Fenster auf Millisekunden zusammenschrumpfen lassen, wird aus dieser Architektur eine harte Governance-Frage — das Thema von Leitstück 08: Project Hertha und Echtzeit-Governance. Zuvor aber zeigt Leitstück 05, wie die Grenze zwischen gelegentlicher Transaktion und Geschäftsbeziehung selbst zur Zustandsmaschine wird.

Markiert: FRAML · Fraud · AML · RegTech Architecture · Domain-Driven Design · Instant Payments · Architektur