Kapitel I

Warum der Big Bang in AML fast immer scheitert

In der Softwarewelt klingt die Versuchung regelmäßig verführerisch: Das alte System ist zu kompliziert, zu langsam, zu teuer, zu unflexibel. Also ersetzt man es einfach durch eine moderne Plattform. In beaufsichtigten AML-Landschaften ist genau das oft die teuerste Form der Selbsttäuschung.

Denn Geldwäscheprävention hängt selten an einem einzigen System. Sie hängt an Kernbank, Zahlungsverkehr, KYC-Stammdaten, Screening, Referenzdaten, Fallmanagement, Reporting, Data Warehouse, Fileschnittstellen, Excel-Schattenprozessen und oft auch an einem externen Vendor, dessen Produkt zwar „integriert“ heißt, intern aber selbst aus mehreren historischen Schichten besteht. Wer hier einen Big Bang plant, plant nicht Modernisierung. Er plant Parallelblindheit mit Budgetfreigabe.

Das Problem ist nicht nur technisch. Es ist politisch, regulatorisch und operativ. Alte AML-Strecken haben über Jahre Sonderlogiken, Ausnahmebehandlungen, manuelle Kontrollen und implizites Wissen eingelagert. Nicht selten gilt: Das System ist veraltet, aber die Organisation hat gelernt, um seine Defizite herum zu arbeiten. Genau deshalb scheitern Komplettablösungen so häufig nicht an der Architektur, sondern an der Reibung mit dem Betrieb.

Kapitel II

Das Strangler-Fig-Pattern: Beobachtbarkeit vor Ersetzung

Aus der Softwaremodernisierung ist ein Prinzip bekannt, das für AML-Landschaften erstaunlich gut passt: das Strangler-Fig-Pattern. Die Idee ist einfach. Ein altes System wird nicht in einem Schlag ersetzt. Stattdessen wächst schrittweise eine neue Hülle um den Bestand. Einzelne Funktionen werden herausgelöst, gespiegelt, entkoppelt und nach und nach übernommen, bis der alte Kern nur noch dort verbleibt, wo er kurzfristig nicht ersetzbar ist.

Für AML-Observability heißt das: Nicht zuerst die Detection Engine austauschen. Nicht zuerst das Fallmanagement neu schreiben. Nicht zuerst den Kernbankanschluss neu bauen. Sondern zuerst eine Beobachtungsschicht um das Bestandssystem legen. Eine Schicht, die noch nichts kaputtmacht, aber bereits erklärt, was im Bestand wirklich passiert.

Diese Schicht besteht typischerweise nicht aus einer großen Plattform, sondern aus mehreren pragmatischen Bausteinen: event mirrors, shadow pipelines, read-only lineage, impact maps, surrogate ids und einem observability sidecar, das fachliche, datenbezogene und technische Spuren korrelierbar macht.

Kapitel III

Mirror first – aber Spiegeln ist kein Gratisprojekt

Der erste Fehler vieler Modernisierungsinitiativen ist, zu früh in den Schreibpfad einzugreifen. Genau das sollte man vermeiden. Wer in regulierten AML-Landschaften früh produktive Logik umbaut, erzeugt sofort Validierungs-, Audit- und Betriebsrisiken. Die bessere Anfangsbewegung lautet daher: Mirror first, mutate later.

Das bedeutet konkret: Transaktionsereignisse, Screening-Ergebnisse, Fallstatus, Referenzdatenupdates, Jobläufe und Schnittstellenzustände werden zunächst gespiegelt, nicht verändert. Aus dem Bestand wird ein beobachtbarer Schatten gebaut. Noch keine neue Entscheidung, noch kein neues Routing, noch kein neues Produktivverhalten. Aber bereits eine neue Sicht.

Diese Sicht ist allerdings nicht kostenlos. Gerade in geschlossenen Vendor-Systemen sind Shadow Pipelines selten bloß eine technische Fingerübung. Sie brauchen proprietäre Konnektoren, Exportpfade, Reconciliation-Logik, Fehlerbehandlung und oft ein eigenes Monitoring. Mit anderen Worten: Auch der Schatten wirft operative Schatten.

Kapitel IV

Vendor-Lock-in: Oft lässt sich zuerst nur die Umgebung stranglen

Architekturfolien tun gerne so, als könne man ein Altsystem Stück für Stück chirurgisch aufschneiden. In der Realität vieler Banken verhindert genau das der bestehende Vertrag. Nicht wenige AML-Anbieter liefern monolithische SaaS- oder Blackbox-Modelle, in denen sich einzelne Fähigkeiten technisch oder lizenzrechtlich kaum isolieren lassen.

Das ist keine Nebensächlichkeit, sondern eine strategische Grenze. Wo der Vendor keine Hooks, keine verwertbaren Exporte, keine brauchbaren Eventströme und keine belastbaren Metadaten liefert, lässt sich die Kernfunktion zunächst oft gar nicht stranglen. Strangeln lässt sich dann nur die Umgebung: Datenversorgung, Freshness, Reconciliation, Priorisierung, Kontextanreicherung, Case-Transparenz, Impact-Mapping.

Das klingt defensiv, ist aber in Wahrheit oft der realistischere Weg. Nicht jedes Strangler-Programm beginnt damit, die Blackbox zu zerschneiden. Manche beginnen damit, ihr Umfeld so gut zu instrumentieren, dass die Blackbox ihre strategische Unangreifbarkeit verliert.

Kapitel V

Surrogat-IDs: notwendig, aber niemals die Wahrheit

Moderne Architekturfolien tun oft so, als wäre die Welt bereits sauber instrumentiert. In der Realität der Banken ist das selten der Fall. Zwischen Mainframe, Vendor-System, Dateiübergabe und manuellem Fallmanagement existiert häufig keine durchgehende trace_id. Wer darauf wartet, bleibt blind.

Genau deshalb braucht die Legacy-Bank zunächst Surrogat-Identitäten. Also technische Hilfskonstrukte, die Korrelation ermöglichen, obwohl die Architektur sie ursprünglich nicht vorgesehen hat: job_run_id, file_delivery_id, batch_cycle_id, screening_snapshot_id, case_transition_id.

Aber genau hier liegt die nächste Falle: Diese IDs dürfen nie so behandelt werden, als seien sie echte End-to-End-Identitäten. Wer auf Basis von Zeitstempel, Betrag oder Dateibezug Korrelationen baut, baut keine ontologische Wahrheit. Er baut eine beobachtende Näherung. Und diese Näherung kann falsch liegen.

Genau deshalb braucht jede Sidecar-Korrelation idealerweise ein eigenes Vertrauensniveau: high, medium oder low. Sonst halluziniert das neue Observability-System Zusammenhänge, die fachlich nie existiert haben. Der Unterschied ist nicht semantisch, sondern operativ. Wer mit falscher Sicherheit korreliert, baut keine Transparenz. Er baut nur ein neues Risiko.

Kapitel VI

Read-only heute, aufsichtlich irrelevant morgen? Eher nicht.

Ein großer Vorteil des Sidecar-Ansatzes liegt darin, dass er anfangs den Schreibpfad nicht verändert. Solange die produktive Entscheidungslogik im Altbestand verbleibt, ist der Einstieg organisatorisch und regulatorisch meist leichter vermittelbar. Spiegeln heißt zunächst noch nicht Steuern.

Genau daraus sollte man jedoch keine falsche Sicherheit ableiten. Ein System, das „nur beobachtet“, kann mit wachsender Relevanz sehr schnell prüfungs- und governance-relevant werden. Spätestens dann, wenn Observability-Daten in Priorisierung, Routing, manuelle Kontrollhandlungen oder Managemententscheidungen einfließen, ist das Sidecar nicht mehr bloß ein unschuldiger Beifahrer.

Die praktische Folge ist klar: Der read-only-Charakter macht den Einstieg leichter. Er macht das Sidecar aber nicht dauerhaft aufsichtlich irrelevant. Je näher die neue Sicht an operative Steuerung, Priorisierung oder Kontrollhandlungen rückt, desto stärker wachsen Nachvollziehbarkeit, Dokumentationspflicht und Governance-Anforderungen.

Kapitel VII

Was man zuerst stranglen sollte: Fähigkeiten, nicht Systeme

Ein zentrales Missverständnis besteht darin, Systeme stranglen zu wollen. In Wirklichkeit sollte man zuerst Fähigkeiten stranglen. Nicht „das AML-System“ wird ersetzt, sondern einzelne Beobachtungs- und Entscheidungsfunktionen rund um das AML-System.

Die operative Logik dahinter ist einfach: Zuerst strangelt man die Stellen, an denen Blindheit entsteht. Nicht zwingend die Stellen, die architektonisch am hässlichsten aussehen. Und dort, wo Vendor-Lock-in das Herauslösen verhindert, strangelt man zunächst nicht die Kernfunktion selbst, sondern die blinden Zonen um sie herum.

Kapitel VIII

Die zwei ökonomischen Wahrheiten: Doppelkosten und Latenz

Das Strangler-Fig-Pattern wird in Architekturtexten gern als pragmatisch und risikoarm beschrieben. Beides stimmt. Was seltener offen ausgesprochen wird: Es ist in der Übergangsphase fast immer auch teurer.

Denn für eine Zeit lang bezahlt das Institut doppelt. Es bezahlt weiter für den Altbestand, seine Wartung, seine Verträge und seine Sonderprozesse. Und es bezahlt zusätzlich für Spiegelung, Sidecar, Datenhaltung, Observability-Stack und neue Governance. Das ist kein Schönheitsfehler. Es ist der Preis dafür, Fehlschläge und Blindheit nicht ebenfalls mitzubestellen.

Hinzu kommt ein zweites, oft verdrängtes Problem: Latenz. Für viele AML-Anwendungsfälle ist verzögerte Sicht bereits ein Fortschritt. Für echte Echtzeitfälle ist sie nur ein Zwischenschritt. Wenn eine Shadow Pipeline Sekunden hinter der produktiven Entscheidung läuft, ist das für nachgelagerte Transparenz wertvoll – für Inline-Kontrolle aber zu spät.

Kapitel IX

Was nicht ins Compliance-Cockpit gehört

Eine der größten Gefahren jeder Observability-Strategie ist, dass sie eine neue Alarmhölle erzeugt. Wenn jede Schemaänderung, jede kleine Latenz, jeder Nullwert-Ausreißer und jede kurzfristige API-Degradation direkt im Compliance-Cockpit landet, wird aus Data Observability nur eine zweite Variante des alten Alert-Problems.

Genau deshalb muss die Schnittstelle zwischen Data/IT-Observability und Compliance radikal gefiltert werden. Im Compliance-Büro sollte nicht sichtbar werden, was technisch interessant ist. Sichtbar werden sollte nur, was fachliche Wirkung entfaltet.

Kapitel X

Die eigentliche Hürde ist das Organigramm

Technik kann Sicht erzeugen. Sie löst aber nicht automatisch das Problem der Zuständigkeit. Genau hier scheitern viele Programme. Data Governance meldet einen Qualitätsvorfall. IT meldet eine Degradation. Compliance meldet einen Rückgang von Treffern. Und jeder Bereich betrachtet die Sache zunächst als Problem der jeweils anderen Seite.

Für eine funktionierende Strangler-Strategie braucht es deshalb nicht nur Sidecars und Observability-Stacks, sondern ein gemeinsames Betriebsmodell für den fachlichen Wirkvorfall. Nicht: „Wem gehört der Server?“ Sondern: „Wer trägt Verantwortung dafür, dass das Institut noch belastbar sieht?“

Ein realistisches Minimalmodell besteht aus drei verpflichtenden Rollen:

Die operative Folge daraus ist unangenehm, aber notwendig: Einige Incidents dürfen nicht mehr nur nach Teamgrenzen geführt werden, sondern nach Wirkungsklassen. Ein verspäteter Referenzdatenfeed, der Screening-Ergebnisse verzerrt, ist dann nicht bloß ein Data-Issue. Er ist ein fachlicher Vertrauensvorfall mit technischem Ursprung.

Kapitel XI

Eine realistische Roadmap für die Altbank

Wie könnte ein Institut nun vorgehen, ohne in Großprogrammromantik oder technische Selbstüberforderung zu kippen? Die Antwort ist unspektakulär und deshalb plausibel: nicht Systeme komplett ablösen, sondern Sichtbarkeit schrittweise vor die Ersetzung ziehen.

Der strategische Vorteil dieser Roadmap liegt auf der Hand: Das Institut reduziert Blindheit, bevor es Architektur ersetzt. Es baut Vertrauen in die Modernisierung auf, bevor es produktive Kernpfade neu schreibt. Und es schafft einen Zustand, in dem zukünftige Ablösungen auf Beobachtung statt auf Hoffnung beruhen.

Kapitel XII

Fazit: Nicht erst modern, dann sichtbar – sondern erst sichtbar, dann modern

Das Strangler-Fig-Pattern ist für AML-Observability deshalb so attraktiv, weil es nicht den perfekten Zielzustand voraussetzt. Es setzt nur voraus, dass ein Institut bereit ist, sich dem Bestand nicht länger mit Scham, sondern mit instrumentierter Neugier zu nähern.

Die eigentliche Modernisierung beginnt dann nicht mit einer neuen Plattform. Sie beginnt mit einer neuen Sicht auf die alte. Nicht der Monolith muss zuerst verschwinden. Zuerst muss die Blindheit verschwinden.