Wenn Journalisten die besseren AML-Werkzeuge haben

Aleph, OCCRPs Datenplattform, ist kein regulatorisches Allheilmittel. Aber sie legt eine unangenehme Wahrheit frei: Vieles, woran Banken in der Geldwäschebekämpfung leiden, ist kein Erkenntnisproblem. Es ist ein Architekturproblem — und nirgends wird das deutlicher als in der KYC-Kette.

In Amsterdam sitzt keine Bank, kein Compliance-Apparat und keine Regulierungsbehörde. Und doch betreibt das Organized Crime and Corruption Reporting Project — kurz OCCRP — von dort aus eine Plattform, die in Fachkreisen längst zu einer Art Schattenstandard für investigative Finanzrecherche geworden ist. Die Plattform heißt Aleph. In ihrer jüngsten Iteration, Aleph Pro, verarbeitet sie nach OCCRP-Angaben mehr als 4,4 Milliarden Entities.¹ OCCRP selbst beziffert die Wirkung seiner Ermittlungen auf über elf Milliarden Dollar an Geldstrafen und beschlagnahmten Vermögenswerten seit 2009.²

Das Bemerkenswerte an Aleph ist nicht, dass Journalisten ein nützliches Werkzeug gebaut haben. Das passiert. Bemerkenswert ist, dass eine Non-Profit-Organisation bei Datenmodell, Verknüpfungslogik und Rechercheergonomie oft näher an der operativen Wirklichkeit transnationaler Finanzkriminalität arbeitet als manche regulierte Großbank mit sechs- bis siebenstelligen Lizenzbudgets für AML-Software.

Wobei der Vergleich, das sei gleich gesagt, nur bedingt fair ist. OCCRP unterliegt keiner Regulierung, muss keine Kundendaten schützen, keine aufsichtlichen Nachweispflichten erfüllen und kann mit geleakten Datensätzen arbeiten, die für Institute tabu sind. Wer regulierte Compliance mit investigativem Journalismus gleichsetzt, vergleicht zwei Systeme mit grundverschiedenen rechtlichen und operativen Zwängen. Trotzdem lohnt der architektonische Vergleich. Nicht weil Banken Aleph übernehmen sollten, sondern weil die Designentscheidungen hinter Aleph die Schwächen gängiger Compliance-Architekturen in ungemütlicher Schärfe ausleuchten. Und nirgends wird das so deutlich wie im KYC-Prozess.

¹ OCCRP Annual Report 2024: „4.4B+ entities in OCCRP Aleph“. Die Zahl bezieht sich auf die gesamte OCCRP-Instanz, nicht auf einzelne Aleph-Pro-Deployments. ² OCCRP About-Seite, Zeitraum 2009–2024: „$11 billion+ in fines levied and monies seized“. Die Zurechnung umfasst Fälle, zu denen OCCRP-Recherchen beigetragen haben.

Aleph basiert auf FollowTheMoney (FtM), einer offenen Ontologie für investigative Daten. Personen, Unternehmen, Beteiligungsverhältnisse, Zahlungsströme — alles wird als typisiertes Entity mit multi-valued Properties modelliert. Das Schema exportiert nach CSV, Excel und Cypher, der Abfragesprache der Graphdatenbank Neo4j.³ Ein Journalist in Bukarest und ein Researcher in Nairobi arbeiten mit derselben Datenstruktur. Das klingt trivial. In der regulierten Welt ist es die Ausnahme.

Denn dort herrscht fragmentierte Vielfalt. Jeder Vendor — ob Actimize, Norkom, Fircosoft oder die diversen Eigenentwicklungen — definiert seine eigene Entity-Struktur. Wer migriert, verliert Kontext. Wer integriert, baut Mapping-Tabellen, die nach dem ersten Projektmanagerwechsel veralten. Interoperabilität, das erklärte Ziel der europäischen AML-Harmonisierung, findet auf der Datenmodellebene bislang kaum statt.

³ FollowTheMoney-Dokumentation, followthemoney.tech; Cypher- und CSV-Export belegt. ⁴ Vgl. GitHub: alephdata/followthemoney-compare. ⁵ OCCRP About-Seite: „1,000+ sources from 180+ countries“. Die Zahl bezieht sich auf Quellregister und Datensätze, nicht auf Aleph-Entities selbst. ⁶ OCCRP Aleph Pro FAQ, Juni 2025.

Beim Entity Matching lohnt ein genauerer Blick. Alephs Cross-Referencing nutzt ein ML-Modell, das häufige Tokens — gängige Nachnamen, generische Firmenzusätze — automatisch heruntergewichtet und seltene Identifier heraufgewichtet. Das Ergebnis ist ein probabilistisches Matching, das Fuzzy-Varianten erkennt, ohne die Alert-Queue mit offensichtlichen Fehltreffern zu fluten. In vielen Screening-Systemen regulierter Institute geschieht das Gegenteil: Regelbasiertes Matching erzeugt hohe Alert-Volumina, die Analysten einzeln abarbeiten. Wie hoch der Anteil irrelevanter Treffer ausfällt, variiert je nach Institut und Kalibrierung — aber dass der Aufwand für manuelle Disposition ein zentraler Kostentreiber ist, bestreitet in der Branche kaum jemand.

Wer den Vergleich zwischen Aleph und regulierten Systemen als akademisch abtun möchte, sollte sich die KYC-Kette ansehen. Hier wird der architektonische Unterschied operativ spürbar.

Know Your Customer, in seiner klassischen Ausprägung, ist ein periodischer Prozess. Ein Kunde wird bei der Aufnahme der Geschäftsbeziehung geprüft. Danach wird er, je nach Risikoklassifizierung, alle ein bis drei Jahre erneut überprüft — der sogenannte KYC-Refresh. Zwischen den Prüfzyklen passiert, wenn man ehrlich ist, wenig Systematisches. Ändert sich die Beteiligungsstruktur eines Kunden, tritt ein neuer wirtschaftlich Berechtigter auf, wird eine Sanktion verhängt oder ein PEP-Status relevant, erfährt das Institut davon im besten Fall über das Transaktionsmonitoring, im schlechtesten Fall beim nächsten turnusmäßigen Review — Monate oder Jahre später.

Die Branche weiß, dass das nicht reicht. Das Schlagwort heißt perpetual KYC — pKYC: die Ablösung periodischer Prüfzyklen durch eine kontinuierliche, ereignisgesteuerte Überwachung der Geschäftsbeziehung. Im Prinzip überwacht das Institut nicht mehr zu festen Zeitpunkten, sondern reagiert auf relevante Veränderungen, sobald sie eintreten: eine neue Sanktionslistung, ein Wechsel im UBO-Geflecht, ein Adverse-Media-Treffer, eine Veränderung in der Transaktionsdynamik.

Im Prinzip. In der Praxis scheitert pKYC an denselben Architekturproblemen, die auch den Rest der AML-Kette plagen. Denn ereignisgesteuerte KYC-Überwachung setzt drei Dinge voraus: erstens ein Datenmodell, das Beziehungen zwischen Entities nativ abbilden kann — nicht als Zeilen in einer Tabelle, sondern als Graph. Zweitens einen Mechanismus, der Änderungen an einer Entity automatisch an alle verknüpften Entities propagiert. Drittens eine Datenbasis, die über den eigenen Kundenbestand hinausreicht und externe Quellen — Register, Sanktionslisten, PEP-Datenbanken, Adverse Media — kontinuierlich einbezieht.

Aleph erfüllt alle drei Voraussetzungen — nicht weil es als KYC-System gebaut wurde, sondern weil seine Architektur auf genau jene Prinzipien setzt, die pKYC technisch ermöglichen würden. FollowTheMoney modelliert Beziehungen als eigene Entities mit Zeitstempeln und Confidence-Bewertungen. Alephs Indexierung ist darauf ausgelegt, Veränderungen in den Quelldaten zu erkennen und nachzuverarbeiten. Und die Datenbasis umfasst über tausend externe Quellen, die regelmäßig aktualisiert werden.

Man sollte diesen Befund nicht überstrapazieren. Aleph ist nicht datenschutzkonform im Sinne der DSGVO, nicht revisionssicher im Sinne der MaRisk und nicht als Produktivsystem für die KYC-Pflichten nach GwG konzipiert. Maltego weist zu Recht darauf hin, dass die Daten unabhängig verifiziert werden müssen und keine eigenständige KYC-Lösung darstellen.⁷ Und die operativen Anforderungen an ein produktives pKYC-System — Audit Trail, Vier-Augen-Prinzip, regulatorische Berichtsfähigkeit, Mandantentrennung — gehen weit über das hinaus, was Aleph bietet oder bieten will.

Aber es bleibt ein aufschlussreicher Kontrast: Eine Journalisten-Plattform arbeitet seit Jahren mit denjenigen Architekturprinzipien — Graph-native Datenmodelle, ereignisbasierte Aktualisierung, Confidence-gewichtete Verknüpfung —, die die regulierte Welt als Zukunftsvision unter dem Label pKYC diskutiert. Der Unterschied besteht nicht in der Erkenntnis, was nötig wäre. Der Unterschied besteht darin, wer es gebaut hat.

⁷ Maltego Transform Hub, OCCRP Aleph Integration: Aleph-Daten sind keine eigenständige KYC-Lösung für regulierte Industrien.

Hier wird die Geschichte eigentümlich. OpenSanctions, die offene Sanktions- und PEP-Datenbank, die eine wachsende Zahl von Instituten als Ergänzung zu kommerziellen Listen nutzt, basiert nativ auf dem FollowTheMoney-Datenmodell. Jede Entity — Person, Unternehmen, Beteiligungsstruktur — ist ein FtM-Objekt mit Schema, Properties, Zeitstempeln und Datensatz-Referenzen. Auch yente, die Matching-API von OpenSanctions, erwartet und liefert FtM-Strukturen.⁸

Institute, die OpenSanctions oder yente-basierte Screening-Dienste konsumieren, arbeiten also mit FtM-Daten — häufig, ohne sich dessen bewusst zu sein. Was anschließend passiert, ist instruktiv: Die meisten Ingest-Pipelines transformieren das FtM-Entity in ein proprietäres Format. Die Graphstruktur wird aufgelöst. Metadaten über Datenherkunft und Zeitstempel verarmen. Was als verknüpftes Datenobjekt beginnt, endet als Zeile in einer relationalen Tabelle.

Nun hat diese Transformation Gründe, die man ernst nehmen muss. Datenschutz verlangt kontrollierte Datenhaltung, nicht assoziative Graphen. Aufsichtliche Prüfungen erwarten nachvollziehbare, dokumentierte Prozesse, keine dynamischen Knowledge Graphs, deren Zustand sich zwischen zwei Prüfzeitpunkten verändert. Und bestehende Core-Banking-Systeme sind nun einmal relational aufgebaut — man kann nicht jede Architektur über Nacht umbauen.

All das ist richtig, und ein ehrlicher Vergleich muss es berücksichtigen. Aber es bleibt ein bemerkenswerter Befund, dass das offene, investigative Ökosystem ein Datenmodell hervorgebracht hat, das für Verknüpfung und Kontexterhalt optimiert ist — während die regulierte Welt Modelle verbraucht, die für Kontrolle und Isolation optimiert sind. Beide Designprinzipien haben ihre Berechtigung. Die Frage, welches besser geeignet ist, transnationale Netzwerke zu erkennen, ist weniger eindeutig, als Puristen beider Seiten es gerne hätten — aber sie verdient eine ehrlichere Debatte, als sie bislang geführt wird.

⁸ OpenSanctions Technical Documentation: Entity-Struktur basiert auf FtM; vgl. opensanctions.org/docs/entities/.

Die AMLA, die neue EU-Anti-Geldwäsche-Behörde mit Sitz in Frankfurt, soll Harmonisierung bringen. Ihre Regulatory Technical Standards sollen sicherstellen, dass Institute europaweit nach vergleichbaren Maßstäben arbeiten. Die Entwürfe setzen eine erstaunliche Granularität voraus und implizieren eine weitgehende Vergleichbarkeit von Datenfeldern — von Identifikationsmerkmalen über UBO-Strukturen bis hin zu Risikobewertungen.⁹

Auf dem Papier ist das ambitioniert. In der Praxis stößt Harmonisierung an eine Grenze, die weder die AMLA noch die begleitende Verordnung adressiert: Es gibt kein gemeinsames Datenmodell. Jedes Institut modelliert seine Kunden, Transaktionen und Risikobewertungen anders. Jeder Vendor strukturiert seine Alerts und KYC-Dossiers anders. Standards lassen sich definieren — solange die Datenmodelle darunter nicht kompatibel sind, bleibt Harmonisierung ein Dokumentationsversprechen.

FollowTheMoney ist keine fertige Lösung für dieses Problem. Es wurde für investigativen Journalismus entwickelt, nicht für KYC-Prozesse mit ihren spezifischen Anforderungen an Datenschutz, Revisionssicherheit und aufsichtliche Nachweisführung. Aber das Designprinzip — eine offene, typisierte, graphfähige Ontologie mit klaren Schema-Definitionen — ist als Denkmodell für die Harmonisierungsdebatte relevanter, als die Branche bislang zugestehen mag.

Aleph Pro macht die Diskussion noch interessanter: Die Plattform führt Confidence-Labels auf Verbindungen ein — also eine quantifizierte Einschätzung, wie belastbar die Beziehung zwischen zwei Entities ist. Für erfahrene Compliance-Praktiker ist das eine Selbstverständlichkeit: Ein PEP-Match auf einen häufigen Namen hat nicht dasselbe Gewicht wie ein Volltreffer mit übereinstimmendem Geburtsdatum, Adresse und Nationalität. Aber die meisten Screening-Systeme bilden diesen Unterschied nicht systematisch ab. Der Alert ist binär: ausgelöst oder nicht. Für KYC-Refresh und pKYC ist das eine besonders teure Schwäche, weil jeder binäre Alert einen manuellen Review-Zyklus auslöst — genau den Prozess, den pKYC eigentlich automatisieren soll.

⁹ Vgl. AMLA-RTS-Konsultationsunterlagen; die EBA hat den institutionellen Rahmen für die RTS-Entwicklung an die AMLA übergeben.

Etwas verschiebt sich — nicht dramatisch, aber beständig. Die Grenzen zwischen investigativem Journalismus und regulierter Compliance verwischen an den technischen Rändern. Aleph Pro wird kommerziell: SaaS ab Mitte 2026, Enterprise-Tier mit On-Premise-Deployment, direkter Outreach an bestehende Instanzbetreiber. Über 60 Organisationen weltweit betrieben eigene Aleph-Instanzen; sie werden nun auf den neuen Stack migriert.¹⁰ Das ist kein Nischenwerkzeug mehr. Das ist Infrastruktur mit Geschäftsmodell.

OpenSanctions gewinnt in der regulierten Welt kontinuierlich an Akzeptanz. FollowTheMoney exportiert nach Cypher, der Sprache von Neo4j — jener Graphdatenbank, die in der Finanzindustrie zunehmend für Fraud Detection und Netzwerkanalyse eingesetzt wird. Die pKYC-Debatte erzeugt Nachfrage nach genau den Architekturprinzipien, die das Open-Source-Ökosystem seit Jahren vorlegt. Die Werkzeuge konvergieren. Die Frage ist, ob die Nachfrage folgt.

Bislang deutet wenig darauf hin, dass die etablierten Akteure sich bewegen. Die Vendor-Verträge laufen. Die Refresh-Zyklen ticken. Die manuellen Reviews stapeln sich. Und in Amsterdam wird derweil die nächste Milliarde Entities indexiert.

Das ist keine Anklage. Es ist eine Bestandsaufnahme. Und die fällt nüchtern betrachtet so aus: Die regulierte Finanzwelt hat ein Architekturproblem, das sich mit Lizenzbudgets allein nicht lösen lässt — und das durch die pKYC-Anforderungen schärfer wird, nicht milder. Das Open-Source-Ökosystem zeigt, wie offene Datenmodelle, probabilistisches Matching und graphbasierte Analyse zusammenspielen können. Die regulierte Welt kennt diese Werkzeuge. Ob sie von ihnen lernt oder weiter in die Verlängerung bestehender Verträge investiert, ist keine technische Frage. Es ist eine Frage institutioneller Trägheit — und irgendwann, unvermeidlich, eine Frage an die Aufseher.

¹⁰ OCCRP Aleph Pro FAQ: „more than 60 organizations around the world are running their own instances“.