Leitstück 07 · PETs · FinCrime-Architektur 2026

Project Aurora und die kryptografische Enklave

Föderierte Geldwäscheerkennung braucht keine zentrale Rohdatenhalde, sondern Compute Boundaries und auditierbare Information-Sharing-Events. Geteilt wird die Rechnung und das Ergebnis — nicht der Datensatz.

Geldwäsche versteckt sich zwischen den Instituten. Jede Bank sieht nur ihren Ausschnitt: ein Konto, eine Überweisung, eine Hälfte einer Kette, deren andere Hälfte bei einem Wettbewerber in einer anderen Jurisdiktion liegt. Das Silo ist nicht das Versagen der Banken — es ist der beste Verbündete des Geldwäschers. Der naheliegende Reflex, „dann legt doch alle Daten zusammen“, ist zugleich rechtlich unmöglich und architektonisch falsch. Datenschutz, Bankgeheimnis und Jurisdiktionsgrenzen verbieten die zentrale Halde, und selbst wenn sie erlaubt wäre, schüfe sie ein einziges, katastrophales Angriffsziel.

Das BIS-Innovation-Hub-Projekt Aurora hat gezeigt, dass der Reflex auch unnötig ist. In einem Proof of Concept (Nordic Centre, gemeinsam mit Lucinity) wurde anhand synthetischer, grenzüberschreitender Zahlungsdaten getestet, ob kollaborative Analyse mit Privacy-Enhancing Technologies (PETs) besser erkennt als der siloierte, regelbasierte Status quo. Das Ergebnis: potenziell bis zu dreimal mehr erkannte komplexe Geldwäsche und bis zu 80 % weniger Falsch-Positive — ohne dass ein Institut seine Rohdaten herausgibt. Die Einheit des Teilens ist nicht der Datensatz. Sie ist die Berechnung und ihr Ergebnis.

Warum die zentrale Halde scheitert

Die Idee einer gemeinsamen Datenplattform — ein Utility, in das alle Banken ihre Transaktionen kippen — taucht in jeder FinCrime-Strategie irgendwann auf. Sie scheitert an vier harten Wänden zugleich. Erstens am Datenschutz: Personenbezogene Zahlungsdaten quer durch die Branche zu poolen, hat in der EU keine tragfähige Rechtsgrundlage. Zweitens am Bankgeheimnis und an sektorspezifischen Vertraulichkeitspflichten. Drittens an der Jurisdiktion: Grenzüberschreitende Rohdatenflüsse stoßen auf widersprüchliche nationale Regime. Und viertens am Konzentrationsrisiko: Eine zentrale Halde aller Finanzbeziehungen wäre das wertvollste Einbruchsziel, das je gebaut wurde.

Die zentrale Datenhalde löst das Silo-Problem, indem sie ein schlimmeres schafft: einen einzigen Ort, an dem alles zugleich schiefgehen kann.

Aurora’s Befund: Kollaboration ohne Preisgabe

Project Aurora trennt zwei Dinge, die in der Halden-Idee verschmelzen: den Nutzen der Zusammenarbeit und die Preisgabe der Daten. Der Nutzen ist real — Geldwäschenetze werden über Institutsgrenzen hinweg deutlich besser sichtbar als im Silo. Die Preisgabe ist vermeidbar — Privacy-Enhancing Technologies erlauben es, gemeinsam zu rechnen, ohne dass jemand seinen Rohbestand offenlegt. Aurora hat dafür mehrere kollaborative Ansätze (Collaborative Analysis and Learning) durchgespielt, darunter Federated Learning auf grenzüberschreitender Ebene als dezentrale Variante.

Der Reframe: Compute Boundary statt Datentransfer

Die architektonische Konsequenz ist ein Wechsel der Richtung. Statt die Daten zur Berechnung zu bringen, bringt man die Berechnung zu den Daten. Jedes Institut hält seinen Bestand hinter einer Compute Boundary — einer Grenze, die Rohdaten niemals verlassen. Was die Grenze überschreitet, ist nie der Datensatz, sondern eines von dreien: ein Modell-Update (Federated Learning), ein verschlüsseltes Zwischenergebnis (SMPC/HE) oder eine schmale Antwort wie „Treffer / kein Treffer“ (Private Set Intersection). Die Compute Boundary ist das Gegenstück zum Bounded Context aus Leitstück 04 — nur zieht sie ihre Linie nicht um eine Bedeutung, sondern um einen Datenbestand.

Wann welches Muster?

„PETs“ ist kein einzelnes Werkzeug, sondern eine Familie mit unterschiedlichen Stärken — und die Architekturentscheidung liegt darin, das richtige Muster zur Frage zu wählen. Drei Grundformen genügen für die meisten FinCrime-Fälle. Federated Learning passt, wenn man ein gemeinsames Erkennungsmodell trainieren will, ohne Trainingsdaten zu teilen: Das Modell reist reihum zu den Beständen, lernt lokal und gibt nur Gewichts-Updates zurück. Secure Multi-Party Computation und homomorphe Verschlüsselung passen, wenn mehrere Parteien eine gemeinsame Kennzahl berechnen wollen — etwa das aggregierte Risiko einer Gegenstelle über Institute hinweg —, ohne ihre Einzelwerte zu zeigen. Private Set Intersection passt für die schmalste, häufigste Frage: „Kennt ihr diese Entität auch als auffällig?“

Die Wahl ist immer ein Tausch zwischen Aussagekraft, Rechenkosten und Vertrauensannahmen. PSI ist billig und liefert wenig; SMPC liefert viel und kostet viel. Eine reife föderierte Architektur kombiniert sie: PSI als schneller Vorfilter, der teure SMPC-Analysen nur dort auslöst, wo ein gemeinsamer Treffer überhaupt existiert. So bleibt die kryptografische Schwerarbeit auf die wenigen Fälle beschränkt, die sie rechtfertigen.

Information-Sharing-Events: was die Grenze überschreitet, ist auditpflichtig

Eine Compute Boundary verschiebt die Audit-Frage. Sie lautet nicht mehr „Sind Daten abgeflossen?“, sondern „War der geteilte Rechenvorgang zulässig — und ist er protokolliert?“. Jeder grenzüberschreitende Austausch wird zu einem Information-Sharing-Event: Wer hat mit wem welche Berechnung auf welcher Rechtsgrundlage zu welchem Zweck angestoßen, und welches Ergebnis kam zurück? Diese Events gehören in dasselbe append-only Ledger wie die agentischen Tool-Calls aus Leitstück 03 — denn auch hier gilt: nicht das fertige Ergebnis ist der Beweis der Rechtmäßigkeit, sondern die lückenlose Spur, wie es zustande kam.

Python · Föderierte Abfrage über eine Compute Boundary (PSI), protokolliertfrom dataclasses import dataclass
from datetime import datetime, timezone

@dataclass(frozen=True)
class SharingEvent:
    initiator: str          # anfragendes Institut
    responder: str          # antwortende Compute Boundary
    computation: str        # z.B. "psi_highrisk_overlap"
    legal_basis: str        # Rechtsgrundlage / Partnerschaft
    purpose: str            # Zweckbindung (vgl. Leitstück 03)
    result_digest: str      # Hash des Resultats — nicht die Daten
    at: datetime

class ComputeBoundary:
    """Hält den Rohbestand. Rohdaten verlassen die Grenze NIE."""
    def __init__(self, name, high_risk_set, ledger):
        self._name = name
        self._high_risk = set(high_risk_set)   # bleibt privat
        self._ledger = ledger

    def psi_overlap(self, initiator, hashed_query: set, *, legal_basis, purpose):
        # Private Set Intersection: nur die Schnittmenge, keine Mengen
        overlap = hashed_query & {_h(x) for x in self._high_risk}
        evt = SharingEvent(initiator, self._name, "psi_highrisk_overlap",
                           legal_basis, purpose, _digest(overlap),
                           datetime.now(timezone.utc))
        self._ledger.append(evt)            # auditierbares Sharing-Event
        return overlap                       # nur Treffer, kein Rohdatensatz

def _h(x): import hashlib; return hashlib.sha256(str(x).encode()).hexdigest()
def _digest(s): return _h(sorted(s))

Die Pointe des Codes: Die Methode gibt eine Schnittmenge zurück, nie den Bestand, aus dem sie stammt. Bank A erfährt, dass eine ihrer Gegenstellen auch in Bank Bs Hochrisiko-Menge auftaucht — ohne diese Menge je zu sehen. Und jeder solche Abgleich hinterlässt ein Sharing-Event mit Rechtsgrundlage, Zweck und Ergebnis-Hash. Aus „Daten geteilt“ wird „Frage zulässig gestellt, Antwort minimal, Vorgang belegt“.

Das Bedrohungsmodell: Neugier und Kollusion

Föderierte Architektur verschiebt das Risiko, sie beseitigt es nicht. Der Angreifer ist hier nicht der Außenstehende, sondern der Teilnehmer: ein neugieriges Institut, das aus den Antworten mehr herauslesen will, als ihm zusteht, oder zwei Parteien, die sich absprechen, um eine dritte zu enttarnen. Eine einzelne PSI-Antwort verrät wenig — aber viele gezielte Abfragen können in Summe rekonstruieren, was die einzelne Antwort schützen sollte. Das ist kein hypothetisches Risiko, sondern die zentrale Schwäche jedes kollaborativen Systems.

Die Gegenmittel sind dieselben Schichten, die schon Leitstück 03 für agentische Workflows verlangt hat — nur über Institutsgrenzen hinweg. Eine Query-Policy begrenzt, wer wie oft welche Abfrage stellen darf; ein Differential-Privacy-Budget verwaltet das kumulierte Auskunftsrisiko und verweigert weitere Antworten, wenn es erschöpft ist; und das Sharing-Ledger macht ungewöhnliche Abfragemuster überhaupt erst sichtbar. Privatsphäre in der Föderation ist damit keine Eigenschaft eines Algorithmus, sondern eine Eigenschaft des Betriebs: Sie entsteht aus Policy, Budget und Protokoll zusammen.

Anschluss an den europäischen Rahmen

Föderierte Erkennung ist kein rein technisches Thema; sie braucht eine Erlaubnis. Der EU-AML-Rahmen öffnet den Informationsaustausch zwischen Verpflichteten in Partnerschaften unter Bedingungen, und auf Behördenseite existiert mit FIU.net längst eine Infrastruktur für den Austausch zwischen zentralen Meldestellen. PETs sind das Mittel, diese rechtlich eng gesteckten Spielräume technisch sauber auszufüllen: Sie machen aus „wir dürfen nur unter Auflagen teilen“ ein „wir teilen nur das Nötige, nachweisbar und minimal“. Die Compute Boundary ist damit nicht nur Datenschutz-Architektur, sondern die technische Form der Datenminimierung aus Leitstück 03 — über Institutsgrenzen hinweg.

Auch der Graph aus Leitstück 06 profitiert. Eine über PSI gewonnene Übereinstimmung ist eine Kante mit klarer Provenienz — „gemeinsamer Hochrisiko-Treffer, Quelle: föderierter Abgleich, Sharing-Event #…“ — und mit der ehrlichen Confidence, die ein privatsphärewahrendes Verfahren zulässt. Föderierte Erkennung liefert also nicht nur mehr Signale, sondern Signale, die ihre Herkunft schon mitbringen.

Ein durchgespielter grenzüberschreitender Fall

Eine Mule-Kette ist über zwei Institute in zwei Jurisdiktionen verteilt: Bank A in der EU sieht den Eingang aus einem Authorised-Push-Payment-Betrug, Bank B im Ausland sieht die Weiterleitung über drei Konten. Jede Bank für sich sieht nur eine harmlose Hälfte. Im Silo bleibt die Kette unsichtbar; in einer zentralen Halde wäre sie sichtbar, aber rechtlich nie zustande gekommen.

Föderiert läuft es anders. Bank A stellt über die Compute Boundary eine PSI-Abfrage: Taucht die fragliche Gegenstelle auch in Bank Bs Hochrisiko-Menge auf? Die Antwort ist ein schmales „ja“ — kein Konto, kein Name, kein Betrag wechselt die Grenze, und ein Sharing-Event hält Rechtsgrundlage, Zweck und Ergebnis-Hash fest. Der Treffer rechtfertigt nun eine teurere, eng begrenzte SMPC-Analyse des gemeinsamen Musters, ebenfalls protokolliert. Was am Ende in Bank As EvidencePackage (Leitstück 02) landet, ist kein Rohdatensatz aus Bank B, sondern eine Kante mit sauberer Provenienz: „gemeinsamer Hochrisiko-Treffer, Quelle föderierter Abgleich, Sharing-Event #…, Confidence des Verfahrens“.

Aus vier Wänden — Datenschutz, Bankgeheimnis, Jurisdiktion, Konzentrationsrisiko — ist so keine Sackgasse mehr geworden, sondern ein gangbarer, belegbarer Weg. Die Kette wird sichtbar, ohne dass jemand seinen Bestand preisgibt, und der Befund trägt seine Rechtmäßigkeit von Anfang an mit sich.

Kernsätze

Die föderierte Architektur löst das Wo der Erkennung — verteilt, privatsphärewahrend, belegt. Sie sagt aber noch nichts über das Wann. Wenn Zahlungen in Sekunden final werden und das Ermittlungsfenster von Tagen auf Millisekunden schrumpft, wird aus der Analyse ein Echtzeit-Governance-Problem. Das ist Leitstück 08: Project Hertha und Echtzeit-Governance.

Markiert: PETs · Privacy · RegTech Architecture · AML · Project Aurora · BIS · Architektur