Fünf Fälle, drei Ebenen, eine Kette
Zwischen 2012 und 2024 haben Aufsichtsbehörden weltweit Bußgelder in Höhe von mehr als neun Milliarden Dollar gegen fünf Banken verhängt — wegen Versagens bei Geldwäscheprävention und Sanktions-Compliance. In jedem einzelnen Fall lautete die öffentliche Diagnose: Compliance hat versagt. Und in jedem Fall war diese Diagnose richtig — und zugleich nutzlos. Denn sie beantwortet nicht die Frage, die für die Verhinderung des nächsten Versagens zählt: Wo genau in der Kette von Geschäftsprozess über Datenhaltung bis IT-Infrastruktur ist das Problem entstanden? Und warum hat es sich unerkannt durch alle Schichten propagiert?
Ein kürzlich in diesem Journal erschienener Beitrag argumentierte, dass echte AML-Observability drei Qualitätsebenen kausal verbinden muss: Business Quality (was erkennen wir?), Data Quality (auf welcher Datenbasis?) und IT Service Quality (mit welcher technischen Integrität?). Die These war überzeugend. Was fehlte, war ein formales Modell, das diese kausale Verbindung implementierbar macht.
Dieses Modell existiert. Es heißt OBASHI — Ownership, Business process, Application, System, Hardware, Infrastructure — und es wurde ursprünglich in der ITIL-Welt entwickelt, um vertikale Abhängigkeiten zwischen Geschäftsprozessen und IT-Assets zu formalisieren. Für AML-Observability braucht es zwei Erweiterungen: eine Datenschicht zwischen Business und Application, und — wie sich bei der Rückschau auf die fünf Fälle zeigt — eine Human-Capability-Ebene oberhalb des Business-Prozesses, die Befähigung, Kapazität und Kontrollpflichten der handelnden Personen formalisiert.
Die Methode: Wir legen die OBASHI-Kette über fünf reale Enforcement Actions und zeigen für jeden Fall, welche fehlende Kante im Abhängigkeitsgraphen das Versagen ermöglicht hat. Nicht als nachträgliche Schuldzuweisung, sondern als Blaupause für eine Observability-Architektur, die diese Fälle strukturell verhindert hätte.
TD Banks Transaction-Monitoring-System wurde zwischen 2014 und 2022 nicht aktualisiert. Keine neuen Szenarien, keine Regelanpassungen, keine Modellvalidierung. In dieser Zeit blieben 92 Prozent aller Transaktionen — ein Volumen von 18,3 Billionen Dollar — unüberwacht. Fentanyl-Netzwerke und Terrorfinanzierung nutzten die Bank als Kanal. Die Strafe: die höchste, die FinCEN je gegen ein Kreditinstitut verhängt hat.
Die Alert-Zahlen sahen stabil aus. Das Management interpretierte die Konstanz als Zeichen funktionierender Kontrollen. In Wahrheit war die Stabilität ein Artefakt eines eingefrorenen Regelwerks: Wer keine neuen Szenarien hinzufügt, generiert keine neuen Alerts. Die Backlog-Queues wuchsen, doch das Management entschied sich, sie «schrittweise abzubauen» statt die Ursache zu beheben.
Die Kunden-Risikodaten waren unvollständig und veraltet. Transaktionsklassifikationen entsprachen nicht mehr den aktuellen Typologien. Aber es gab kein Data-Quality-Monitoring, das die Drift zwischen Modell-Annahmen und realer Datenverteilung gemessen hätte. Die Daten waren technisch vorhanden — sie waren nur fachlich wertlos geworden.
Die Systeme liefen. Uptime: grün. API-Responses: im SLA. Kein Incident-Ticket, kein Ausfall. Aber die Applikation war seit 2014 auf demselben Softwarestand. Ein technisch gesundes System, das fachlich blind war — exakt das Szenario, das als «technisch up, fachlich blind» in die AML-Literatur eingehen sollte.
-[:CONSUMES]-> (:Dataset {name: „Customer Risk Ratings“})
-[:CHECKED_BY]-> (:DataQualityRule {dimension: „FRESHNESS“}) ← EXISTIERTE NICHT
-[:USES]-> (:Application {version: „2014.x“})
-[:HAS_SLO]-> (:SLO {metric: „rule_version_currency“}) ← EXISTIERTE NICHT
-[:RUNS_ON]-> (:System {status: „HEALTHY“}) ← das Einzige, was gemessen wurde
Eine prozessnahe SLO auf der Applikationsschicht — nicht «ist das System up?», sondern «wann wurde das letzte Regelwerk-Update deployed?» — hätte den Stillstand ab Tag eins sichtbar gemacht. Eine Freshness-Rule auf dem Customer-Risk-Dataset hätte die Daten-Drift erkannt. Beides zusammen hätte die Business-Ebene alarmiert, bevor 92 % der Transaktionen im Blindflug durchliefen.
Danske Banks estnische Filiale wickelte zwischen 2007 und 2015 rund 200 Milliarden Euro an verdächtigen Transaktionen ab. Nichtresidente Kunden aus Russland und der ehemaligen Sowjetunion nutzten die Filiale als Durchlaufstation. Die Kopenhagener Zentrale hatte weder Echtzeit-Zugriff auf die Transaktionsdaten noch funktionierende Kontrollen über die estnische IT-Infrastruktur.
Kopenhagen sah die konsolidierten Zahlen — aggregiert, geglättet, quartalsweise. Tallinn sah den operativen Alltag — manuell, unkontrolliert, ohne automatisierte AML-Prüfung. Das Reporting lief an die lokale Geschäftsleitung, nicht an den Chief Compliance Officer. Es gab keine gemeinsame Sicht auf die Risikoprozesse.
Die Kundendokumentation lag auf Estnisch und Russisch vor. Die Sanktionslisten-Prüfung der Zentrale lief auf lateinischen Zeichensätzen. Transliteration? Nicht implementiert. Ein russischer Kundenname in kyrillischer Schrift wurde vom zentralen Screening schlicht nicht gefunden. Die Daten existierten — aber in einem Format, das das System nicht verarbeiten konnte.
Die estnische Filiale betrieb ein eigenes Legacy-System, vollständig isoliert von Kopenhagen. Kein gemeinsamer Datenkanal, kein API-Link, kein Echtzeit-Feed. Die Zentrale konnte die estnischen Transaktionsdaten nicht abfragen, selbst wenn sie gewollt hätte.
-[:OWNS]-> (:AMLProcess {name: „Group Sanctions Screening“})
-[:CONSUMES]-> (:Dataset {name: „Estonian Customer Data“}) ← KEIN FEED
-[:USES]-> (:Application {name: „HQ Screening Engine“})
(:Application {name: „Tallinn Legacy System“}) ← INSELKNOTEN, keine Verbindung zum HQ-Graph
Eine Vollständigkeitsprüfung auf dem Graphen — «hat jeder AMLProcess, der einem zentralen Owner gehört, einen durchgängigen Pfad bis zur Infrastruktur?» — hätte die estnische Isolation als fehlende Kante erkannt. Nicht als Compliance-Verstoß, sondern als Strukturbruch im Graph. Das ist einfacher zu finden als ein Compliance-Versagen, und es ist automatisierbar.
Commerzbanks Transaction-Monitoring-Software hatte 40 Hochrisiko-Länder nicht konfiguriert. 1.110 Hochrisiko-Kunden waren nicht in die Monitoring-Datenbank eingetragen. Die Bank wickelte Transaktionen mit Iran (22 Mio. Dollar, 959 Einzeltransaktionen), Sudan (78,3 Mio. Dollar) und weiteren sanktionierten Entitäten ab — teilweise durch aktives «Wire Stripping», also das Entfernen von Sanktions-Identifiern aus Zahlungsnachrichten.
Die Screening-Engine lief und produzierte Alerts. Die Zahlen sahen normal aus. Aber die Engine prüfte nur gegen eine unvollständige Länderliste. Die fehlenden 40 Länder generierten naturgemäß null Alerts — ein Nullwert, den die Business-Ebene nicht von «kein Risiko» unterscheiden konnte.
Die Referenzdaten — Länderliste, Hochrisiko-Kundenliste — waren unvollständig. Aber es gab keinen Abgleich zwischen der regulatorischen Erwartung und dem tatsächlichen Konfigurationsstand. Die Daten waren nicht falsch. Sie fehlten. Und fehlende Daten erzeugen keine Fehler-Alerts.
Technisch funktionierte alles einwandfrei. Die Software verarbeitete Transaktionen, prüfte gegen die hinterlegte Liste, erzeugte Alerts für Treffer. Dass die Liste unvollständig war, ist kein IT-Problem — es ist ein Konfigurationsproblem an der Grenze zwischen Daten und Applikation. Kein SLO hätte angeschlagen.
-[:CONSUMES]-> (:Dataset {name: „Country Risk Configuration“})
-[:CHECKED_BY]-> (:DataQualityRule {dimension: „COMPLETENESS“,
threshold: „FATF + EU = 68 Länder“, actual: „28“}) ← EXISTIERTE NICHT
Eine Completeness-Rule auf dem Referenzdaten-Dataset, die automatisch prüft, ob die konfigurierte Länderliste alle regulatorisch geforderten Jurisdiktionen abdeckt. Nicht als jährlicher Audit, sondern als kontinuierlicher Check bei jeder Listenaktualisierung. Im Graph wäre der fehlende Abdeckungsgrad als FAIL sofort sichtbar gewesen.
ING versagte über Jahre «strukturell und dauerhaft» bei der Geldwäscheprävention. Beneficial Owners wurden nicht geprüft, offensichtliche Red Flags nicht untersucht. Die Monitoring-Systeme erzeugten Alerts — aber über 90 Prozent waren False Positives, und die tatsächlich kritischen Alerts gingen im Rauschen unter.
Die Analysten bearbeiteten täglich Hunderte Alerts, von denen über 90 % irrelevant waren. Die Entscheidungsqualität erodierte nicht wegen fehlender Regeln, sondern wegen eines Signal-Rausch-Verhältnisses, das menschliche Analyse unmöglich machte. Alert Fatigue ist kein Ressourcenproblem. Es ist ein Systemproblem.
Die Ursache lag im Kundenstamm: unvollständige Daten, fehlende Beneficial-Ownership-Informationen, inkonsistente Schreibweisen. Das System matchte «Jan de Vries» gegen «J. de Vries» gegen «Jan DeVries» — drei Records, drei Alerts, drei Analysten-Minuten für dasselbe Nicht-Ergebnis. Entity Resolution war nicht implementiert.
Onboarding-System und Transaction Monitoring waren nicht integriert. Wenn die KYC-Abteilung einen Kunden als Low-Risk klassifizierte, erreichte diese Information das Monitoring nicht in Echtzeit. Die Systeme waren technisch stabil — aber fachlich isoliert.
-[:USES_IDENTITY_GRAPH]-> (:IdentityGraph {resolution_strategy: „NONE“})
-[:CONSUMES]-> (:Dataset {name: „Customer Master Data“})
-[:CHECKED_BY]-> (:DataQualityRule {dimension: „UNIQUENESS“,
threshold: „<2%“, actual: „34%“}) ← EXISTIERTE NICHT
-[:HAS_SLO]-> (:SLO {metric: „false_positive_rate“, target: „<70%“, actual: „92%“}) ← KEIN SLO
Zwei Mechanismen: Erstens eine Uniqueness-Rule auf dem Kundenstamm. Zweitens ein Business-SLO auf dem Prozess selbst — nicht «wie viele Alerts erzeugen wir?» (Vanity-Metrik), sondern «wie hoch ist die False-Positive-Rate?» (Qualitäts-Metrik). Die OBASHI-Kette verbindet beides kausal: Die Duplikat-Rate im Kundenstamm treibt die False-Positive-Rate. Das eine ist ein Ressourcenproblem. Das andere ist ein lösbares Datenproblem.
Die Federal Reserve verhängte 2023 eine Strafe von 186 Millionen Dollar gegen die Deutsche Bank — darunter 46,2 Millionen direkt wegen der Correspondent-Banking-Beziehung mit Danske Bank Estland. Die Deutsche Bank hatte zwischen 2007 und 2015 mehr als 267 Milliarden Dollar für Danske Estland gecleard, ohne angemessene Due-Diligence-Prüfung. Parallel waren die OFAC-Filter lückenhaft: Transaktionen mit Iran, Libyen und Syrien passierten ungehindert.
Correspondent Banking und allgemeine AML-Überwachung unterlagen getrennten Risikobewertungen. Die Frage «welches Risiko importieren wir, wenn wir für diese Korrespondenzbank clearen?» war prozessual nicht mit «funktioniert unser Sanctions-Screening?» verknüpft. Zwei Prozesse, die fachlich zusammengehören, blieben organisatorisch und technisch getrennt.
Die Bank hatte Risikodaten über Danske. Sie hatte Transaktionsdaten aus dem Clearing. Aber die Verknüpfung — «die Transaktionen, die wir für Danske clearen, zeigen Muster, die zu den bekannten Risiken passen» — fehlte. Die Daten lagen in verschiedenen Systemen, unter verschiedenen Identifiern, ohne gemeinsame Lineage.
OFAC-Screening für eigene Transaktionen und Monitoring für Correspondent-Banking-Flows liefen auf unterschiedlichen Systemen mit unterschiedlichen Regelwerken. Das Correspondent-Banking-System blieb zwischen 2015 und 2023 im Wesentlichen unverändert — trotz einer expliziten Anweisung der Federal Reserve von 2015.
-[:USES]-> (:Application {name: „OFAC Filter“})
-[:CONSUMES_DATA_FROM]-> (:Application {name: „Correspondent Banking“}) ← KANTE FEHLTE
(:AMLProcess {name: „Correspondent Due Diligence“})
-[:DEPENDS_ON_FEED]-> (:DataFeed {source: „Risk Ratings“, target: „TM Engine“}) ← FEED EXISTIERTE NICHT
Ein Graph-basierter Vollständigkeitscheck: «Für jede Correspondent-Banking-Beziehung mit Risk-Rating ≥ HIGH — existiert ein DataFeed vom Risk-Rating-System zum Transaction-Monitoring-System?» Diese Frage ist als Cypher-Query in einer Sekunde beantwortbar. Sie wurde acht Jahre lang nicht gestellt.
Das Muster
Man muss die fünf Fälle nebeneinanderlegen, um das Muster zu sehen. In jedem Fall wurde die Strafe auf der Business-Ebene verhängt: «Monitoring versagt», «KYC-Versagen», «Alert Fatigue». Aber die Ursache lag in keinem Fall auf der Business-Ebene.
| Fall | Strafe | Offizielle Diagnose | Tatsächliche Wurzel |
|---|---|---|---|
| TD Bank | $3,1 Mrd. | «Monitoring versagt» | IT: 8 Jahre kein Deployment. Data: Risikodaten veraltet |
| Danske Estland | $2,4 Mrd. | «KYC-Versagen» | IT: Kein Feed Tallinn → Kopenhagen. Data: Transliteration fehlt |
| Commerzbank | $1,45 Mrd. | «Sanctions-Verstoß» | Data: 40 Länder in Config fehlend. IT: Kein Vollständigkeitscheck |
| ING | €775 Mio. | «Alert Fatigue» | Data: 34 % Duplikate, keine Entity Resolution |
| Deutsche Bank | $186 Mio. | «Correspondent Banking» | Data: Kein Link Risk-Rating → TM. IT: Systeme nicht integriert |
Die Business-Ebene war in jedem Fall das Symptom, nicht die Ursache. Die kausale Kette zwischen den Ebenen war nirgendwo formalisiert.
Keiner dieser Fälle wäre durch besseres Monitoring auf einer einzelnen Ebene verhindert worden. TD Bank hätte ein IT-SLO gebraucht, das nicht Uptime misst, sondern Regelwerk-Aktualität. Danske hätte eine Vollständigkeitsprüfung auf dem Abhängigkeitsgraphen gebraucht. Commerzbank eine Completeness-Rule auf den Referenzdaten. ING eine Uniqueness-Rule auf dem Kundenstamm. Deutsche Bank eine Kante im Graphen, die zwei Prozesse verbindet, die fachlich zusammengehören.
Was all diese Fälle brauchten — und was keiner hatte — war eine formale Struktur, in der Cross-Layer-Abhängigkeiten als Kanten existieren: prüfbar, traversierbar, automatisierbar. Aber die Analyse wäre unvollständig, wenn sie hier enden würde. Denn in mindestens drei der fünf Fälle lag die eigentliche Ursache nicht in einem fehlenden Daten-Feed oder einem veralteten System. Sie lag bei den Menschen, die entschieden haben, es dabei zu belassen.
Der Faktor Mensch: Die fehlende vierte Ebene
Bei TD Bank entschied das Management, den Alert-Backlog «schrittweise abzubauen» statt die Systemursache zu beheben. Bei der Commerzbank entfernten Mitarbeiter aktiv Sanktions-Identifier aus Zahlungsnachrichten — sogenanntes Wire Stripping. Bei Danske Bank Estland ignorierten lokale Führungskräfte Warnungen von Korrespondenzbanken und internen Whistleblowern. In jedem dieser Fälle war das technische System nicht allein das Problem. Es war der Mensch, der entschied, das System nicht zu korrigieren — oder es bewusst zu umgehen.
Das klassische OBASHI-Modell kennt eine «Ownership»-Ebene, behandelt sie aber als administrativen Zuordnungsknoten: Wer ist verantwortlich? Für AML-Observability reicht das nicht. Die Ownership-Ebene muss zu einer operativen Human-Capability-Schicht werden, die drei Dimensionen formalisiert: Befähigung (hat die Person das Wissen?), Kapazität (hat sie die Zeit?) und Kontrollpflicht (wird ihre Entscheidung gegengeprüft?).
Neue Knoten im Graph
Properties: name, department, alerts_per_day, capacity_limit,
avg_time_to_resolve, headcount
(:StaffMember)
Properties: employee_id, name, certifications[],
last_training_date, caseload_current
(:Training)
Properties: training_id, topic, valid_until, regulatory_basis
(:ApprovalGate)
Properties: gate_id, change_type, requires_dual_control,
approving_unit, last_triggered_at
Neue Beziehungen
(:AMLProcess) -[:ASSIGNED_TO]-> (:Role)
(:Role) -[:FILLED_BY]-> (:StaffMember)
// Ist die Person befähigt?
(:StaffMember) -[:HAS_COMPLETED]-> (:Training)
(:AMLProcess) -[:REQUIRES_TRAINING]-> (:Training)
// Vier-Augen-Prinzip: Wer kontrolliert Änderungen?
(:DataQualityRule) -[:CHANGE_REQUIRES]-> (:ApprovalGate)
(:Application) -[:CONFIG_CHANGE_REQUIRES]-> (:ApprovalGate)
(:ApprovalGate) -[:APPROVED_BY]-> (:Role {department: „Risk“})
Rückbindung an die fünf Fälle
Die Human-Capability-Ebene ist kein theoretisches Add-on. Sie erklärt den Rest, den die technische Analyse offen lässt:
| Fall | Technische Wurzel | Menschliche Wurzel | Fehlender Graph-Knoten |
|---|---|---|---|
| TD Bank | 8 Jahre kein Deployment | Management entschied aktiv, den Stillstand zu tolerieren | (:ApprovalGate) für Regelwerk-Freeze fehlte |
| Danske | Kein Feed Tallinn → HQ | Lokale Führung ignorierte Whistleblower und Korrespondenzbank-Warnungen | (:Role) mit Eskalationspflicht an HQ-Compliance fehlte |
| Commerzbank | 40 Länder in Config fehlend | Mitarbeiter betrieben aktives Wire Stripping | (:ApprovalGate) für Sanctions-Config-Änderungen fehlte |
| ING | 34 % Duplikate, keine Entity Resolution | Analysten bei 90 % False Positives chronisch überlastet | (:Role) mit capacity_limit vs. alerts_per_day fehlte |
| Deutsche Bank | Kein Link Risk-Rating → TM | Federal-Reserve-Anweisung von 2015 nicht umgesetzt | (:Training) + Eskalationsgate für Consent-Order-Tracking fehlte |
Ein perfektes IT-System nutzt nichts, wenn der Mensch entscheidet, es acht Jahre lang nicht zu aktualisieren. IT Integrity + Data Quality + Human Capability = Business Quality.
Drei Mechanismen greifen ineinander. Capacity Monitoring: Der ING-Fall zeigt, dass die Kante zwischen Role und AMLProcess eine Belastungsgrenze hat. Wenn ein Analyst 500 Alerts pro Tag bearbeiten muss und die Kapazitätsgrenze bei 200 liegt, ist die Kante überlastet — und das erklärt, warum selbst ein technisch gesundes System keine verwertbaren Ergebnisse liefert. Das ist kein Ressourcenproblem, das man mit Headcount löst. Es ist ein messbarer Engpass im Graphen, der auf ein Datenproblem eine Ebene tiefer zeigt.
Training als Vorbedingung: Ein StaffMember ist nur dann operativ mit einem kritischen Prozess verbunden, wenn eine gültige :HAS_COMPLETED-Kante zu dem geforderten Training existiert. Fehlt die Kante oder ist die Zertifizierung abgelaufen, ist der Prozess de facto unterbesetzt — auch wenn die Stelle formal besetzt ist. Im Danske-Fall hätte ein solcher Check gezeigt, dass in Tallinn kein einziger Mitarbeiter für das zentrale Screening zertifiziert war.
Vier-Augen-Prinzip als Graph-Kante: Der Commerzbank-Fall zeigt am drastischsten, was passiert, wenn Konfigurationsänderungen an Screening-Systemen ohne unabhängige Gegenprüfung möglich sind. Ein ApprovalGate-Knoten formalisiert die Anforderung: Jede Änderung an einer DataQualityRule, jede Anpassung einer Länderliste, jedes Abschalten eines Filters braucht eine :APPROVED_BY-Kante zu einer unabhängigen Risk-Unit. Fehlt diese Kante, existiert eine unkontrollierte Abkürzung im Graphen — und der Structural Blindness Detector schlägt Alarm.
Eine Query für alle fünf Fälle — jetzt mit dem Faktor Mensch
Der Structural Blindness Detector wird um zwei Human-Capability-Checks erweitert. Die ersten vier Prüfungen fangen technische und datenseitige Lücken. Die letzten zwei fangen menschliche Risikofaktoren: Überlastung und fehlende Kontrollpflichten.
MATCH (proc:AMLProcess {criticality: ‚CRITICAL‘})
-[:CONSUMES]->(ds:Dataset)
WHERE NOT (ds)-[:CHECKED_BY]->(:DataQualityRule)
RETURN proc.name, ds.name, ‚NO_DQ_RULES‘ AS gap_type
UNION
// 2. Prozesse ohne prozessnahe SLOs (ING)
MATCH (proc:AMLProcess {criticality: ‚CRITICAL‘})
WHERE NOT (proc)-[:HAS_SLO]->(:SLO)
RETURN proc.name, null, ‚NO_BUSINESS_SLO‘ AS gap_type
UNION
// 3. DataFeeds ohne Anbindung (Danske)
MATCH (proc:AMLProcess)-[:DEPENDS_ON_FEED]->(feed:DataFeed)
WHERE NOT (feed)-[:DELIVERED_BY]->(:Application)
RETURN proc.name, feed.feed_id, ‚ORPHAN_FEED‘ AS gap_type
UNION
// 4. Applikationen ohne aktuelles Deployment (TD Bank)
MATCH (proc:AMLProcess)-[:USES]->(app:Application)
WHERE app.last_deploy_at < datetime() – duration(‚P365D‘)
RETURN proc.name, app.name, ‚STALE_APPLICATION‘ AS gap_type
UNION
// 5. NEU — Überlastete Rollen (ING Alert Fatigue)
MATCH (proc:AMLProcess)-[:ASSIGNED_TO]->(role:Role)
WHERE role.alerts_per_day > role.capacity_limit
RETURN proc.name, role.name, ‚HUMAN_OVERLOAD‘ AS gap_type
UNION
// 6. NEU — Config-Änderungen ohne Vier-Augen-Kontrolle (Commerzbank)
MATCH (ds:Dataset)<-[:CONSUMES]-(:AMLProcess {criticality: ‚CRITICAL‘})
WHERE NOT (ds)-[:CHANGE_REQUIRES]->(:ApprovalGate)
RETURN ds.name, null, ‚NO_DUAL_CONTROL‘ AS gap_type
Sechs Prüfungen, vier Ebenen. Bei TD Bank schlägt Check 4 und 5 an (veraltete Applikation, Management-Entscheidung ohne Gate). Bei Danske Check 3 (verwaister Feed). Bei Commerzbank Check 1 und 6 (fehlende DQ-Rules, fehlende Vier-Augen-Kontrolle für die Länderliste). Bei ING Check 2 und 5 (kein Business-SLO, überlastete Analysten). Bei Deutsche Bank Check 3 und 4 (fehlender Cross-Prozess-Feed, veraltetes System). Nicht Jahre danach in einem Enforcement-Order, sondern täglich, automatisiert, als Teil des Compliance-Cockpits.
Was folgt
OBASHI ist kein neues Framework. Es ist ein Werkzeug aus der ITIL-Welt, das in der AML-Compliance bisher nicht eingesetzt wurde — zu Unrecht, wie diese fünf Fälle zeigen. Zwei Erweiterungen machen es für den regulierten Finanzkontext tauglich: eine Datenschicht zwischen Business und Application (Dataset, DataFeed, IdentityGraph, DataQualityRule) und eine Human-Capability-Schicht oberhalb des Business-Prozesses (Role, StaffMember, Training, ApprovalGate). Beide Schichten fehlen im klassischen OBASHI. Und beide fehlen in den Compliance-Architekturen, die diese Strafen verursacht haben.
Die vollständige Kausalformel lautet damit: IT Integrity + Data Quality + Human Capability = Business Quality. Ein Graph, der nur die ersten beiden Terme abbildet, ist besser als keiner — aber er erklärt nicht, warum TD Bank acht Jahre lang ein System betrieb, das nachweislich blind war. Er erklärt nicht, warum Commerzbank-Mitarbeiter aktiv Sanktions-Identifier aus Zahlungsnachrichten entfernten. Und er erklärt nicht, warum ING-Analysten in einem Meer von False Positives ertranken, obwohl die Lösung ein Datenproblem war, kein Ressourcenproblem.
Die nächsten Schritte sind konkret: Ein Neo4j-Schema, das die erweiterte OBASHI-Kette über alle vier Ebenen implementiert. Ein Structural Blindness Detector, der täglich prüft, ob die Abhängigkeitsketten vollständig sind — inklusive der menschlichen Kontrollpfade. Und eine offene Frage, die jede Organisation für sich beantworten muss: Wer pflegt diesen Graphen? Wer ist der Owner des Abhängigkeitsmodells selbst?
Neun Milliarden Dollar Bußgelder sind ein starkes Argument dafür, dass der bisherige Ansatz nicht funktioniert. Nicht, weil die Institute keine Compliance-Abteilungen hatten. Nicht, weil sie keine IT-Systeme betrieben. Sondern weil niemand die Kette formalisiert hat, die von der menschlichen Entscheidung über den Business-Prozess und die Datenqualität bis zur Infrastruktur reicht. OBASHI, erweitert um den Faktor Mensch, formalisiert diese Kette. Die fünf Fälle zeigen, dass sie gebraucht wird.
