Zwei Welten, ein Problem

Wenn in einem modernen Cloud-System ein Request 800 Millisekunden statt 200 braucht, löst das klassische Monitoring einen Alert aus: Latency threshold exceeded. Der Ingenieur sieht den Alert, öffnet ein Dashboard, findet die betroffene Metrik. Was er nicht sieht: warum der Request langsam war. War es die Datenbank? Ein DNS-Lookup? Ein Cold Start in einer Lambda-Funktion? Ein Upstream-Service, der unter Last steht?

Monitoring beantwortet die Frage: „Funktioniert mein System noch?“ — es erkennt bekannte Fehlerzustände. Observability beantwortet eine andere, weitergehende Frage: „Warum verhält sich mein System so?“ — auch bei Problemen, die vorher niemand antizipiert hat. Wichtig: Observability ersetzt Monitoring nicht, sondern ergänzt es um eine explorative Diagnoseebene.

Der Unterschied ist nicht akademisch. In der IT hat er darüber entschieden, ob Unternehmen bei Incidents stundenlang Logs durchsuchen oder in Minuten die Root Cause finden. In der Compliance könnte er darüber entscheiden, ob ein Institut mehr erkennt als nur das, wofür bereits Regeln existieren — oder ob es bei der Prüfung des Bekannten stehen bleibt.

Die drei Säulen — und ihre Compliance-Übersetzung

Observability in der IT ruht auf drei Säulen: Metrics (aggregierte Kennzahlen), Logs (einzelne Ereignisse mit Kontext) und Traces (die Verfolgung eines Requests durch alle Systemschichten). Zusammen ermöglichen sie explorative Analyse — man kann Fragen stellen, die bei der System-Konzeption noch gar nicht existierten.

Die Übersetzung in die Welt des Transaktionsmonitorings ist überraschend direkt — als Analogie, nicht als Eins-zu-eins-Entsprechung:

Die Parallele zeigt dennoch ein strukturelles Problem: Das klassische Transaktionsmonitoring operiert überwiegend auf der Metrics-Ebene — aggregierte Schwellwerte, Regelwerke, Typologien. Logs werden zwar gespeichert, aber in vielen Instituten selten explorativ ausgewertet. Und Traces — die systematische Verfolgung von Geldbewegungen durch Netzwerke — sind in der Breite der deutschen Bankenlandschaft noch die Ausnahme, nicht die Regel. Es gibt Institute, die bereits Netzwerkanalysen und ML-gestützte Ansätze einsetzen. Aber sie bilden nicht den Branchendurchschnitt.

Das Paradigmenproblem des regelbasierten TM

Ein regelbasiertes Transaktionsmonitoring-System fragt: „Matcht diese Transaktion ein bekanntes Muster?“ Structuring? Round-Tripping? Rapid Movement of Funds? Wenn ja: Alert. Wenn nein: weiter.

Das funktioniert — für bekannte Typologien. Es ist das Äquivalent eines Nagios-Checks in der IT: if cpu > 90% then alert. Zuverlässig, reproduzierbar, auditierbar. Und grundsätzlich blind gegenüber allem, was außerhalb der vordefinierten Regeln liegt.

In der IT hat man dieses Problem verstanden, als Microservice-Architekturen die Zahl möglicher Fehlermodi exponentiell erhöht haben. Ein Monolith hat vielleicht 20 bekannte Fehlerszenarien. Ein System aus 200 Microservices hat Tausende möglicher Interaktionspfade — und damit Fehlerszenarien, die niemand vorab antizipieren kann.

Financial Crime hat ein strukturell analoges Problem. Die Zahl der Geldwäsche-Typologien ist nicht endlich — sie wächst mit jeder neuen Technologie, jedem neuen Finanzprodukt, jeder neuen Jurisdiktion. Die FATF behandelt sowohl etablierte Typologien (Trade-Based Money Laundering, Structuring) als auch neuere Felder (Virtual Assets, DeFi) als relevante ML/TF-Risiken. Die Kreativität der Kriminellen entwickelt sich schneller als die Regelwerke der Compliance-Abteilungen — und genau das ist das Problem eines rein regelbasierten Ansatzes.

Graph Analytics als Distributed Tracing für Geldbewegungen

In der IT-Operations hat Distributed Tracing das Debugging verteilter Systeme revolutioniert. Statt einzelne Logs zu durchsuchen, verfolgt man einen Request durch alle Services — vom Eingang bis zur Antwort, über jede Zwischenstation.

Das konzeptionelle Äquivalent in der Financial-Crime-Welt ist Graph Analytics. Nicht die einzelne Transaktion ist verdächtig, sondern der Pfad über Knoten und Kanten: Wer schickt Geld an wen? Über welche Zwischenstationen? In welcher Jurisdiktion? Mit welchem zeitlichen Muster?

Wir haben das in unserer Panama-Paradox-Analyse konkret untersucht. In einer eigenen Auswertung der ICIJ Offshore Leaks Database (CSV-Export, Stand März 2026) haben wir die vollständigen Datensätze aller fünf Leaks — von den Offshore Leaks (2013) bis zu den Pandora Papers (2021) — in eine Neo4j-Graphdatenbank geladen. Die ICIJ selbst spricht offiziell von „more than 810,000 offshore entities“. Unsere Auswertung ergab im Detail rund 814.000 Entities, rund 770.000 Officers und rund 27.000 Intermediäre.

Was sichtbar wurde, war nicht durch einzelne Transaktionen erkennbar, sondern nur durch die Netzwerkstruktur: Community-Cluster, die auf koordiniertes Verhalten hindeuten. Intermediäre, die über mehrere Leaks hinweg identische Strukturen aufbauten. Und als eigene Analysehypothese: eine auffällige Häufung deutscher Officers mit Verbindungen zu maltesischen Service-Providern — wir nennen es die „Malta-Connection“. Ob diese Cluster tatsächlich illegales Verhalten abbilden, lässt sich aus den Offshore-Leaks-Daten allein nicht beweisen. Aber sie zeigen, welche Strukturen ein rein regelbasiertes System systematisch übersehen würde.

Die Erkenntnis ist dieselbe wie in der IT: Ohne Traces sieht man nur Symptome, keine Ursachen. Ein Alert „Überweisung über 9.999 EUR“ ist ein Symptom. Die Erkenntnis, dass derselbe Intermediär über drei Jurisdiktionen hinweg Dutzende Gesellschaften für denselben wirtschaftlich Berechtigten verwaltet, wäre eine Root-Cause-Hypothese — wobei „Root Cause“ in der AML-Welt schwieriger zu isolieren ist als in der IT, weil Kausalität, Intentionalität und wirtschaftliche Berechtigung oft nur probabilistisch erschließbar sind.

Mehrere hundert Datenpunkte und die Illusion der Vollständigkeit

Die AMLA hat mit ihren RTS-Entwürfen nach Art. 19(9) und Art. 28(1) der Verordnung (EU) 2024/1624 einen ambitionierten Versuch unternommen, die Datenbasis für Customer Due Diligence EU-weit zu harmonisieren. Im Umfeld der neuen EU-AML-Aufsichts- und CDD-Standards kursieren sehr umfangreiche Datenanforderungen: Je nach Konsultations- und Reporting-Kontext ist von mehreren hundert Datenpunkten pro Geschäftsbeziehung die Rede. Name, Adresse, Nationalität, Herkunft der Mittel, wirtschaftlich Berechtigter, PEP-Status, Risikoeinstufung — die Tendenz ist klar: umfassende, granulare Erfassung.

In der Sprache der IT ist das: mehr Metriken. Mehr Dashboards. Mehr Schwellwerte. Mehr Alerts. Es ist die instinktive Reaktion eines Systems, das auf Monitoring konditioniert ist: Wenn wir nicht genug sehen, müssen wir mehr messen.

Aber mehr Metriken sind nicht dasselbe wie bessere Observability. Mehrere hundert Datenpunkte über einen Kunden zu sammeln heißt nicht, sein Verhalten zu verstehen. Es heißt zunächst nur, dass man Felder in einer Datenbank gefüllt hat.

Die erste öffentliche Anhörung der AMLA am 24. März 2026 hat die Spannungsfelder dieses Ansatzes offengelegt. Im Konsultationsumfeld und in veröffentlichten Stellungnahmen verschiedener Sektoren — darunter Banken, Versicherungen, Rechtsberufe und auch Akteure aus dem Profifußball — wurde wiederholt vor übermäßiger Präskription und unverhältnismäßiger Belastung gewarnt. Der gemeinsame Nenner der Kritik: Der risikobasierte Ansatz drohe durch einheitliche Detailregelung ausgehöhlt zu werden.

Die drei Schichten der Erkennung

Observability in der IT folgt einem Schichtenmodell: Die Infrastrukturschicht (Metriken), die Applikationsschicht (Logs) und die Geschäftsprozessschicht (Traces) ergänzen sich. Keine Schicht allein reicht aus.

Wir haben dieses Prinzip in unserem FinCrimeOS-Architekturkonzept auf die Compliance übertragen — als Drei-Schichten-Sicherheitsmodell. Die Grundidee: Die Verteidigung gegen Financial Crime sollte sich nicht auf eine einzige, öffentlich bekannte Erkennungsebene beschränken.

Der entscheidende Punkt ist die Informationsasymmetrie: Wer seine Geldwäschestrategie gegen öffentlich bekannte Regeln optimiert, optimiert bestenfalls gegen eine von drei Erkennungsebenen. Die föderative und die bankinterne Schicht bleiben für Außenstehende unsichtbar — vorausgesetzt, sie existieren. Für die meisten Institute ist das heute noch ein Architekturziel, kein Ist-Zustand.

Was die IT schon gelernt hat

Der Übergang von Monitoring zu Observability in der IT wurde durch konkrete Werkzeuge getrieben: OpenTelemetry als offener Standard für die Instrumentierung. Jaeger und Zipkin für Distributed Tracing. Grafana für die Korrelation von Metriken, Logs und Traces in einem Interface.

Die Compliance-Welt hat vergleichbare Bausteine — nutzt sie aber überwiegend nicht integriert. OpenSanctions als offene Sanktionsdatenbank. Neo4j für Graphanalysen. ElasticSearch für Volltextsuche über Adverse Media und regulatorische Texte. FastAPI als Integrationsschicht. Was fehlt, ist das Zusammenführen.

Mit dem Beyond-AI-Projekt demonstrieren wir, dass ein selbst gehosteter Sanctions Screener auf Basis von OpenSanctions, yente, ElasticSearch und Neo4j technisch machbar ist. Die Lizenzkosten dieser Open-Source-Komponenten liegen deutlich unter denen kommerzieller Screening-Plattformen. Allerdings: Die Gesamtkosten eines solchen Systems (Integration, Datenqualitätssicherung, Modellvalidierung, Betrieb, regulatorische Absicherung) sind damit nicht vollständig erfasst. Für den produktiven Einsatz in einem beaufsichtigten Institut wären zusätzlich Daten-Governance, Modellrisikomanagement, Betriebsprozesse, Validierung, Rezertifizierung und klare Verantwortlichkeiten unverzichtbar. Der Ansatz ist kein Ersatz für das Kernbankensystem, sondern eine zusätzliche Analyseebene: eine Observability-Schicht für Financial Crime.

Der Kulturwandel

Der schwierigste Teil des Übergangs von Monitoring zu Observability ist nicht die Technik. Es ist die Kultur.

In der IT mussten Teams lernen, dass „alle Dashboards sind grün“ nicht bedeutet, dass alles in Ordnung ist. Dass die Abwesenheit von Alerts nicht die Abwesenheit von Problemen beweist. Dass explorative Analyse — das Stellen von Fragen, die man vorher nicht kannte — ein Feature ist, kein Defizit.

In der Compliance ist die Ausgangslage ähnlich. „Kein Alert = kein Problem“ ist die implizite Logik vieler Transaktionsmonitoring-Systeme. Die regulatorische Prüfung fragt typischerweise: „Haben Ihre Regeln gegriffen?“ — seltener: „Hätten Sie auch das Unbekannte erkannt?“

Die Big-4-Beratungshäuser — deren Thought-Leadership-Qualität wir in einer eigenen Analyse systematisch untersucht haben — publizieren jährlich umfangreiche Studien über „AML Transformation“. Kaum eine davon stellt die Grundfrage: Messen wir die richtigen Dinge, oder messen wir nur mehr von den falschen?

Marktschau: Wer baut schon an der Observability-Schicht?

Der Paradigmenwechsel von Monitoring zu Observability ist nicht nur eine akademische These. Mehrere kommerzielle Plattformen bewegen sich bereits in diese Richtung — allerdings mit unterschiedlicher Tiefe und Ausprägung. Keine von ihnen ist eine vollständige „Observability-Plattform“ im IT-Sinn. Aber sie zeigen, wohin sich der Markt entwickelt.

Quantexa — Öffentlich am stärksten graph- und kontextzentriert

Von den untersuchten Plattformen wirkt Quantexa in der öffentlichen Positionierung am stärksten graph- und kontextzentriert. Die 2016 in London gegründete Plattform (Series F, Bewertung laut Herstellerangaben ca. $2,6 Mrd.) setzt explizit auf Knowledge Graphs, Entity Resolution und kontextuelle Analyse. Die öffentliche Positionierung ist deutlich auf Entity Resolution, Netzwerke und Kontextanalyse ausgerichtet; zu den öffentlich genannten Kunden zählen u.a. HSBC und Standard Chartered.

Der entscheidende Unterschied zu klassischen TM-Systemen: Quantexa verbindet interne und externe Datenquellen zu einem kontextualisierten Graphmodell. Statt nur zu fragen, ob eine Transaktion eine Regel verletzt, macht die Plattform Beziehungen zwischen Entities sichtbar — inklusive Cross-Border-Strukturen, Shell-Company-Netzwerke und Intermediär-Cluster. Das ist konzeptionell das, was wir als „Traces“ bezeichnen. Laut Herstellerangaben nutzt HSBC die Plattform, um automatisiert Daten zu verknüpfen und Ermittlern eine 360°-Sicht auf Kunden und Gegenparteien zu geben.

Einschränkung: Öffentliche Nutzerberichte bemängeln hohe Lizenzkosten und Schwierigkeiten bei der Integration in bestehende IT-Landschaften. Für Landesbanken und Sparkassenverbünde mit gewachsener Infrastruktur ist das kein triviales Deployment.

SAS Anti-Money Laundering — Analytik-Schwergewicht mit Graph-Ansätzen

SAS AML ist seit über zwei Jahrzehnten im TM-Markt. Analystenberichte heben SAS regelmäßig in den Bereichen Analytical Modeling, Explainability und Workflow Automation hervor.

In Richtung Observability bewegt sich SAS durch die Integration von Network Analytics und Entity Network Generation — also Graph-basierter Beziehungsanalyse. Die SAS Financial Crimes Analytics Komponente erlaubt explorative Segmentierung via k-Means-Clustering, Drag-and-Drop-Datenpipelines und automatisierte ML-Modelloperationalisierung. Entscheidend: SAS betont Explainability — die Nachvollziehbarkeit von AI/ML-Entscheidungen gegenüber Prüfern und Aufsicht.

Einschränkung: Die SAS-Viya-Plattform (Nachfolger der klassischen 9.4-Architektur) gilt in Peer Reviews als komplex in der Wartung. SAS ist primär eine Analyse-Plattform — die Stärke liegt in der Analytik-Tiefe, nicht im sofort einsetzbaren, integrierten Compliance-Workflow.

IMTF Siron®One — Behavioral Clustering und Link Analysis

IMTF Siron®One kombiniert eine regelbasierte Engine mit ML-Modellen für Behavioral Clustering, Entity Deviation Scores und Transaction Deviation Scores. Die Link-Analysis-Komponente identifiziert gemeinsame Gegenparteien, Shell-Company-Strukturen und wirtschaftlich Berechtigte — und visualisiert sie im Case Manager. IMTF positioniert Siron®One sichtbar im Markt der hybrid AI-gestützten AFC-Plattformen, mit Fokus auf mittelgroße bis große Banken, Versicherer und Telekommunikationsanbieter.

Besonders relevant für die Observability-These: Siron®One verknüpft statische KYC-Daten, kontinuierliches Transaktionsmonitoring und dynamische Risiko-Scores zu einem persistenten Kundenprofil — einem „360°-View“, der über die einzelne Transaktion hinausgeht. GenAI wird für Adverse-Media-Zusammenfassungen und Entitäts-Identifikation eingesetzt. Die TBML-Funktionalität (Trade-Based Money Laundering) integriert OCR, Dokumentenmanagement und Sanctions Screening in einem Workflow.

Einschränkung: Die Graph-Kapazitäten sind vorhanden (Link Analysis), aber weniger tief als bei Quantexa. Es handelt sich um eine Beziehungsvisualisierung, nicht um eine vollwertige Knowledge-Graph-Plattform mit Entity Resolution über Millionen externer Datenpunkte.

GFT Smaragd — Der deutsche Herausforderer

GFT Smaragd ist im DACH-Raum besonders relevant: Laut GFT-Geschäftsbericht hat eine deutsche Tier-1-Bank die Smaragd Compliance Suite 2025 als zentrale TM-Plattform gewählt. GFT Technologies (Stuttgart) positioniert Smaragd als AI-powered Compliance Suite mit No-Code-Szenariobuilder, Sandbox-Umgebung für Regelwerkstests, Smart Parsing und Echtzeit-Monitoring für Instant Payments und Korrespondenzbanken.

Smaragd ist in der Observability-Einordnung die klassischste der vier Plattformen: stark in regelbasiertem TM mit AI-Augmentation für False-Positive-Reduktion und Risk Scoring. Die Außendarstellung betont „AI-powered compliance“ und Szenario-Management stärker als explorative Netzwerkanalyse oder Graph-basierte Entity Resolution. Für den deutschen Sparkassen- und Landesbanken-Verbund ist Smaragd dennoch eine realistische Option — weil Compliance-Regelwerke, BaFin-Anforderungen und DSGVO-Konformität im Produktdesign verankert sind.

Einschränkung: Die öffentlich verfügbare Dokumentation zeigt keine explizite Knowledge-Graph- oder Entity-Resolution-Schicht. Smaragd ist primär eine Monitoring-Plattform mit AI-Ergänzung — der Schritt zur Observability-Plattform steht noch aus.

Einordnung: Vom Monitoring zur Observability

✓✓✓ = Kernkompetenz · ✓✓ = Solide Fähigkeit · ✓ = Vorhanden, aber nicht Differenzierungsmerkmal · — = Nicht erkennbar in öffentlicher Dokumentation
Hinweis: Diese Matrix ist eine redaktionelle Einordnung auf Basis öffentlich verfügbarer Produktinformationen. Sie ersetzt keinen Proof of Concept, keine RFI/RFP-Bewertung und keinen Architekturtest im Institut.

Nicht vertieft betrachtet, aber ebenfalls relevant: Oracle Financial Services Compliance Studio und NICE Actimize heben in ihrer öffentlichen Positionierung ebenfalls graph-, entity- oder AI-gestützte Erkennungskomponenten hervor. NICE Actimize gehört ebenfalls zu den etablierten, entity-zentrierten Plattformen im Segment. Eine Vertiefung dieser Plattformen wäre lohnend, sprengt aber den Rahmen dieses Beitrags.

Was auffällt: Die Graph-Tiefe — das Äquivalent von Distributed Tracing in unserer Analogie — ist das Differenzierungsmerkmal mit der größten Varianz. Quantexa hat sie zur Kernkompetenz gemacht. SAS und IMTF bieten sie als Ergänzung. GFT Smaragd setzt den Schwerpunkt (noch) anderswo. Für Institute, die über regelbasiertes Monitoring hinauswollen, ist die Frage der Graph-Fähigkeit das entscheidende Auswahlkriterium — nicht die Zahl der vorkonfigurierten Szenarien.

Fazit: Von „Matcht das?“ zu „Was passiert hier?“

Die erste Frage ist notwendig. Sie erfüllt regulatorische Mindestanforderungen, sie ist auditierbar, sie ist erklärbar. Aber sie ist nicht hinreichend. Wer nur fragt, ob eine Regel matcht, wird nie das finden, wofür es noch keine Regel gibt.

Die zweite Frage ist schwieriger. Sie erfordert andere Werkzeuge (Graphdatenbanken statt nur relationale Systeme), andere Methoden (explorative Netzwerkanalyse statt nur regelbasierte Prüfung) und andere Kompetenzen (Data Engineers und Graph-Analysten neben Compliance-Juristen — nicht statt ihrer).

Und sie erfordert eine andere regulatorische Haltung: Nicht mehr Datenpunkte sammeln, sondern die vorhandenen besser vernetzen. Nicht Hunderte Felder pro Kunde, sondern die Beziehungen zwischen Kunden, Transaktionen und Intermediären sichtbar machen. Nicht mehr Regeln schreiben, sondern die Fähigkeit aufbauen, Fragen zu stellen, die noch niemand formuliert hat.