— Essay —
PrivacyTech · RegTech · FRAML
Warum Privacy-Enhancing Technologies das stille Fundament der nächsten Generation von FRAML-Architektur werden — und warum Europas Banken das noch nicht verstanden haben.
Die niederländische Transactie Monitoring Nederland, kurz TMNL, war auf den ersten Blick eine bemerkenswerte Anomalie: fünf konkurrierende niederländische Banken, ein gemeinsames Monitoring-Vehikel, eine Aufsicht, die sehr genau hinsah. Es war nicht der reine Privacy-Beweisfall, als der es in manchen Präsentationen erscheint — Bürgerrechtsorganisationen halten den Datenfluss bis heute für rechtswidrig, eine niederländische Anwaltskanzlei hat den fünf Banken sogar potenzielle Strafbarkeit attestiert. Aber TMNL zeigte etwas Wichtigeres: Geldwäschebekämpfung scheitert nicht daran, dass Banken zu wenig Daten besitzen. Sie scheitert daran, dass die relevanten Muster an Institutsgrenzen zerschnitten werden.
Diese Einsicht wird die europäische Compliance-Architektur des kommenden Jahrzehnts prägen. Sie wird es aber langsamer tun, als die Regulierung es verlangt — und sehr viel langsamer, als die Vendor-Landschaft suggeriert.
Ein hartnäckiges Missverständnis
Das Klischee ist in Vorstandspräsentationen so verbreitet, dass es selten noch hinterfragt wird: Die DSGVO behindere die wirksame Bekämpfung von Geldwäsche, weil Datensparsamkeit und Zweckbindung mit den Aufbewahrungs- und Sorgfaltspflichten des Geldwäschegesetzes kollidierten. In der zugespitzten Variante: Europäische Banken kämpften mit gefesselten Händen gegen Kriminelle, die keine Datenschutzbeauftragten beschäftigen.
Diese Erzählung war nie ganz falsch, aber sie war immer auf einer einzigen Ebene formuliert — der Datenebene. Sie ging davon aus, dass Compliance bedeutet, möglichst viele Rohdaten an möglichst zentraler Stelle zu konzentrieren. Privacy bedeutete folglich, weniger Daten zu sammeln. Aus dieser Prämisse ergab sich der Konflikt mit logischer Notwendigkeit.
Die Prämisse ist überholt. Sie war es übrigens schon, als sie in den Branchenpapieren der frühen 2010er Jahre formuliert wurde, aber damals fehlte die Rechenleistung, um die Alternative ernsthaft zu betreiben. Heute fehlt sie nicht mehr.
Was sich verschoben hat
Privacy-Enhancing Technologies — ein etwas unhandlicher Sammelbegriff für eine Familie kryptographischer und statistischer Verfahren — verschieben die Frage von „Wer darf welche Daten sehen?“ zu „Welche Berechnung darf welches Ergebnis produzieren?“. Drei Techniken sind in der FRAML-Diskussion relevant.
Secure Multi-Party Computation erlaubt es mehreren Parteien, gemeinsam eine Funktion über ihre jeweils privaten Eingaben zu berechnen, ohne dass eine Partei die Eingaben der anderen erfährt. Im FRAML-Kontext bedeutet das: Zwei Banken können feststellen, ob ein Transaktionsmuster bei beiden auftritt, ohne die Transaktionen selbst auszutauschen. Federated Learning trainiert Modelle dezentral — jede Bank rechnet lokal, nur die Modellgewichte wandern. Homomorphe Verschlüsselung schließlich erlaubt Berechnungen direkt auf verschlüsselten Daten; sie ist die theoretisch eleganteste, praktisch aber langsamste der drei Methoden.
Privatsphäre wird zur Eigenschaft der Berechnung, nicht zur Eigenschaft der Datenhaltung.
Keine dieser Techniken ist neu. Neu ist, dass sie für klar begrenzte Workloads produktionsnah geworden sind. Das ist eine technische Aussage, keine kulturelle: Die Algorithmen funktionieren, die Bibliotheken sind dokumentiert, und für viele Matching-, Scoring- und Trainingsaufgaben reicht die Performance. Für bankweite Echtzeitüberwachung bleiben Latenz, Governance und Kosten anspruchsvoll. Was fehlt, ist nicht nur Rechenleistung, sondern institutionelle Bereitschaft.
Europa hat den Beweis schon erbracht
Dass Privacy in sensiblen Datenräumen ein Ermöglicher sein kann, ist kein FRAML-Wunschdenken. Europas belastbarste Beispiele kommen nur nicht aus der Geldwäschebekämpfung, sondern aus Gesundheit, amtlicher Statistik und öffentlicher Verwaltung. Genau deshalb sind sie relevant: Dort, wo Daten besonders sensibel und Akteure besonders misstrauisch sind, wurde Privacy nicht als Bremse behandelt, sondern als Infrastrukturbedingung für Zusammenarbeit.
Health · OpenSAFELY
OpenSAFELY brachte in der Pandemie Analysecode zu NHS-Daten, statt große Mengen pseudonymisierter Patientendaten aus sicheren Umgebungen herauszuziehen. Forscher sehen aggregierte Outputs, nicht frei zugängliche Patientendatensätze.
Statistik · Eurostat JOCONDE
JOCONDE steht für „Joint On-demand Computation with No Data Exchange“ und testet PETs im European Statistical System. Die Logik ist dieselbe wie bei FRAML: gemeinsame Berechnung, kein klassischer Austausch von Mikrodaten.
Public Sector · SVB/UWV/TNO
In den Niederlanden nutzen SVB, UWV und TNO Secure Multi-Party Computation, um Personen zu identifizieren, die möglicherweise Anspruch auf ergänzende Altersleistungen haben, ohne Verwaltungsdaten klassisch zusammenzuführen.
Public Health · Contact-Tracing-Apps
Die europäischen Corona-Warn-Apps zeigten, dass privacy-preserving Design Akzeptanz und Interoperabilität ermöglichen kann: dezentrale Proximity-Daten, grenzüberschreitender Gateway, keine zentrale Bewegungsdatenbank.
Für FRAML folgt daraus keine naive Übertragung. Gesundheitsdaten, Statistikdaten und Sozialverwaltungsdaten sind andere Datenräume als Zahlungsverkehr. Aber das Muster ist übertragbar: Privacy schafft Vertrauen, Vertrauen erlaubt Kooperation, Kooperation macht Muster sichtbar, die in isolierten Datensilos unsichtbar bleiben. TMNL war der Warnfall. OpenSAFELY, JOCONDE und die niederländischen MPC-Piloten sind die Bauanleitung.
Der regulatorische Rückenwind
Hier kommt die Anti-Money-Laundering Authority ins Spiel, die seit dem 1. Juli 2025 in einem Bürohaus an der Frankfurter Messe ihre Arbeit aufgenommen hat. Ihre Mitarbeiterzahl liegt bei rund 120 Ende 2025; bis Ende 2027 sollen es über 400 sein. Im Januar 2026 sind die AML-Mandate der Europäischen Bankenaufsicht auf die neue Behörde übergegangen.
Die AMLA wird oft als das, was sie offensichtlich ist, beschrieben: eine zentrale Aufsicht über bis zu vierzig hochriskante Institute, mit direkten Aufsichts-, Informations- und Vor-Ort-Befugnissen, die ab 2028 wirksam werden. Die Auswahl der direkt beaufsichtigten Institute soll 2027 erfolgen. Sie ist aber auch etwas weniger Offensichtliches — eine Infrastruktur. Die Anti-Money-Laundering Regulation, das sogenannte Single Rulebook, vereinheitlicht ab dem 10. Juli 2027 Schwellen, Sorgfaltspflichten, Risikologik und zentrale Definitionen; die Draft-RTS übersetzen diesen Rahmen in granulare Datenanforderungen.
Standardisierung ist die langweilige Schwester der Innovation — und ihre notwendige.
Die regulatorischen technischen Standards, die die AMLA im Dezember 2025 als Draft-RTS vorgelegt hat, enthalten ein standardisiertes Set granularer Datenpunkte für Risikoassessment- und Auswahlmethodik. Sie werden erst mit Annahme durch die Kommission unmittelbar gelten. Aber bereits in der Entwurfsfassung leisten sie etwas, was zuvor in 27 nationalen Umsetzungen nicht möglich war: einen sauberen semantischen Rahmen. Ohne den Rahmen kein TMNL für 27 Mitgliedstaaten. Ohne den Rahmen kein FIU.net, das mehr ist als ein E-Mail-Verteiler.
Warum gerade FRAML
Die Konvergenz von Fraud Prevention und Anti-Money Laundering, in der Branche unter dem Akronym FRAML zusammengefasst, gehört zu jenen Begriffen, die in jedem Vendor-Pitch auftauchen und in nur wenigen Banken tatsächlich umgesetzt sind. Der Grund ist banal: Fraud-Daten und AML-Daten leben in unterschiedlichen Systemen, unterschiedlichen Rechtsgrundlagen und unterschiedlichen Abteilungen. Sie zu verschmelzen, scheitert weniger an der Technik als an der Datenschutzfolgenabschätzung.
Genau hier wirken PETs verstärkend. Eine Bank, die ihre Fraud-Engine und ihre AML-Engine über homomorph verschlüsselte Zwischenstände kommunizieren lässt, kann ein konvergentes Risikobild erzeugen, ohne die zweckgebundene Trennung der Rohdaten aufzugeben. Das ist nicht bloß ein juristischer Trick. Es ist eine architektonische Aussage: Privatsphäre wird zur Eigenschaft der Berechnung, nicht zur Eigenschaft der Datenhaltung.
Die Konsequenz reicht weiter. Synthetische Daten, erzeugt unter Differential-Privacy-Garantien, erlauben das Vorvalidieren neuer Modelle ohne Produktionsdaten. Föderiertes Training erlaubt es, Layering-Muster über Banken hinweg zu lernen. Sanctions-Screening über homomorphe Suche erlaubt es, vertrauliche Listen gegen vertrauliche Bestände abzugleichen, ohne dass eine der Parteien die andere Seite sieht.
Jede dieser Anwendungen ist heute technisch möglich. Keine ist in den großen kontinentaleuropäischen Banken Standard.
Der amerikanische Vergleich
Es ist verlockend, das als europäische Trägheit zu lesen. Der Vergleich mit den Vereinigten Staaten relativiert das Bild. Section 314(b) des USA PATRIOT Act, umgesetzt im BSA-Regelwerk, erlaubt seit Jahrzehnten den freiwilligen Informationsaustausch zwischen Finanzinstituten unter einem ausdrücklichen Safe Harbor des FinCEN — auf einer Basis, die die meisten europäischen Datenschützer als problematisch einstufen würden. Die amerikanische Antwort auf das Sharing-Problem war breiter rechtlich; die europäische wird stärker technisch und prozedural abgesichert sein müssen.
Das ist keine schlechte Nachricht. Eine technische Antwort skaliert besser als eine rechtliche, weil sie nicht jedes Mal neu verhandelt werden muss. Sie ist aber teurer in der Anschaffung, und sie verlangt Kompetenzen, die in den meisten Compliance-Abteilungen heute nicht vorhanden sind.
Wo die Reibung bleibt
Es wäre unredlich, die verbleibenden Konflikte zu übergehen. Drei davon sind hartnäckig.
Die Aufbewahrungsfristen für AML-Daten — fünf Jahre nach § 8 GwG, fünf Jahre nach Art. 77 AMLR ab dem 10. Juli 2027, mit fallbezogener Verlängerung um maximal weitere fünf Jahre — stehen im Spannungsverhältnis zur Zweckbindung nach Artikel 5 der Datenschutz-Grundverordnung. Dieses Spannungsverhältnis ist gesetzlich austariert, aber operativ unscharf: Wann genau eine Verlängerung „im Einzelfall notwendig“ ist, wird in der Aufsichtspraxis erst noch ausgehandelt werden müssen.
Das Recht auf Löschung steht im Spannungsverhältnis zu Audit-Trail-Pflichten. Crypto-Shredding — das gezielte Vernichten von Schlüsseln, wodurch verschlüsselte Daten faktisch unzugänglich werden — ist eine elegante, aber operativ anspruchsvolle Lösung, deren Beherrschung in den meisten Banken erst noch erlernt werden muss.
Und schließlich stehen die Schutzrechte bei automatisierten Entscheidungen nach Artikel 22 DSGVO, flankiert durch AMLR Art. 76 und die seit August 2024 in Kraft befindliche, gestaffelt anwendbare KI-Verordnung, im Spannungsverhältnis zum statistischen Charakter moderner FRAML-Modelle. Auch hier hilft kein PET, sondern nur architektonische Disziplin: die Trennung von erklärbaren Entscheidungsstufen und nicht-erklärbaren Vorfilterungen.
Was zu erwarten ist
Die kommenden zwei Jahre werden, wenn die Akteure rational handeln, drei Entwicklungen sehen. Erstens werden die ersten europäischen Großbanken PET-basierte Pilotprojekte über Institutsgrenzen hinweg ankündigen — wahrscheinlich in den Niederlanden, in den nordischen Ländern und, mit einigem Abstand, in Deutschland. Zweitens werden die AMLA und die nationalen FIUs föderierte Analytics als implizite Erwartung in ihre Aufsichtspraxis einarbeiten, ohne sie zunächst explizit vorzuschreiben. Drittens werden Vendor-Stacks, die heute auf zentralisierte Datenhaltung optimiert sind, in Zulieferer für PET-Schichten zerfallen, und die Banken, die das früh genug erkennen, werden Verhandlungsmacht gewinnen.
Wer nichts tut, wird in fünf Jahren eine teurere Infrastruktur betreiben, die strukturell weniger leistet. Das ist kein moralisches Urteil, sondern eine architektonische Beobachtung. Die Banken, die heute glauben, sie könnten den Konflikt zwischen Datenschutz und Geldwäschebekämpfung durch Lobbyarbeit lösen, kämpfen gegen eine Wand, die längst eine Tür ist. Sie wissen nur noch nicht, wo der Griff ist.
Der Griff wird nicht in einer einzelnen Verordnung liegen und auch nicht in der nächsten Vendor-Demo. Er liegt in einer anderen Grundannahme: dass Finanzkriminalität nicht durch immer größere Datentöpfe besser verstanden wird, sondern durch präzisere Berechnungen über getrennte Datenräume. Das ist weniger spektakulär als ein zentraler Datenpool. Es ist aber näher an dem, was europäische Regulierung, Bankrealität und technische Machbarkeit tatsächlich zulassen.
Wer FRAML ernst nimmt, muss deshalb nicht Datenschutz gegen Geldwäschebekämpfung ausspielen. Er muss lernen, Kooperation so zu bauen, dass sie ohne pauschalen Klartextzugriff funktioniert. Das ist die fünfte Wand: nicht ein weiteres Hindernis im Raum, sondern die Stelle, an der die Architektur selbst zur Lösung wird.
Die operative Vertiefung zu diesem Essay findet sich im Field Guide „Privacy-preserving RegTech“: mit europäischen Präzedenzfällen, Money-Mule-Erkennung, APP-Fraud, Krypto-Off-Ramping, LLM-Copiloten, Governance-Fragen, Anbieterlandschaft und KPIs.












