Reichen die Signale, die ich sehe, um den Zustand zu erschließen, den ich nicht sehe?

Der Begriff stammt nicht aus dem DevOps-Jargon, sondern aus der Regelungstechnik. Rudolf Kálmán formulierte 1960 eine Eigenschaft dynamischer Systeme, die den theoretischen Kern liefert:

Ein System heißt beobachtbar, wenn sich sein innerer Zustand aus endlich vielen Beobachtungen seiner Ausgänge in endlicher Zeit eindeutig rekonstruieren lässt. — Kálmán, 1960

Das klingt abstrakt, trifft aber den Kern. Die entscheidende Frage ist nicht „habe ich genug Logs?“, sondern: reichen die beobachteten Ausgänge aus, um den unbeobachteten Zustand zu erschließen? Alles weitere — Logs, Metrics, Traces, Dashboards — sind Konsequenzen dieser Frage, nicht ihre Ersetzung.

Monitoring versus Observability

Beide Begriffe werden oft synonym verwendet. Sie sind es nicht. Der Unterschied entscheidet, ob man auf Zwischenfälle reagieren oder sie verstehen kann.

Die drei Säulen

Operationalisiert wird Observability in der Praxis klassisch über drei Signaltypen. Sie sind keine vollständige Taxonomie moderner Observability, aber sie bilden die Basis. Keiner reicht allein — die Verschneidung macht den Unterschied.

Der Klassiker: Warum hat gerade dieser Kunde abgebrochen?

Der E-Commerce-Stack ist das Lehrbuchbeispiel für Observability, weil er drei Eigenschaften kombiniert, die das Konzept scharf machen: viele verteilte Services, hoher Transaktionsdurchsatz, und ein direkt messbares Business-Outcome (Conversion).

Eine Bestellung wandert durch 12 bis 20 Services — Katalog, Warenkorb, Preis, Tax, Inventory, Fraud-Check, Payment-Gateway, Confirmation, Notification, Fulfillment. Jeder Service hat eigene Latenz, eigene Fehlerrate, eigene Abhängigkeiten.

Monitoring zeigt dir: conversion_rate ist gestern von 3,4 % auf 2,9 % gefallen. Das ist ein Alarm, keine Erklärung. Observability erlaubt dir zu fragen, ohne Code zu deployen:

• Welche Kombination aus region × payment_method × build_hash × device_type korreliert mit dem Drop?
• Gibt es einen Retry-Sturm zwischen inventory und pricing, der einen Timeout im Gateway erzeugt?
• Welche Nutzer haben einen Fraud-Challenge gesehen und nicht fortgesetzt?

Der letzte Punkt ist unser Übergang. Die Frage „hat ein Fraud-Check einen echten Käufer vertrieben?“ ist nicht trennbar von der Frage „hat er einen Betrüger erfolgreich abgehalten?“. Beide Fragen teilen denselben Zustandsraum — denselben User, dieselbe Session, dieselbe Transaktion.

Wenn der Fraud-Alert von gestern der Money-Mule-Fall von morgen ist.

FRAML — Fraud & Anti-Money Laundering — ist die Einsicht, dass Fraud und Geldwäscheprävention organisatorisch und regulatorisch unterschiedlich gerahmt sind, datenfachlich aber stark überlappen. Beide Domänen operieren auf demselben Substrat: Konten, Sessions, Transaktionen, Gegenparteien, Netzwerke.

Die typische Operationsrealität in einer mittleren Bank:

Die beiden Systeme sprechen in der Regel nicht miteinander. Der Fraud-Score einer Überweisung ist der AML-Analystin vier Wochen später nicht mehr verfügbar — oder er ist es, aber nicht im selben Zustandsraum abfragbar. Das ist ein Observability-Defekt, kein Regel-Defekt.

Der typische Fall, retrospektiv betrachtet

Der Wert der retrospektiven FRAML-Observability liegt nicht im Alarmieren, sondern im Entdecken von Typologien, die niemand spezifiziert hat. Regeln fangen, was man kennt. Der Graph fängt, was man hätte wissen können.

Nachbetrachtung ist nicht Langsamkeit. Nachbetrachtung ist der einzige Zeithorizont, in dem neue Typologien entstehen — denn sie entstehen in der Differenz zwischen dem, was die Regel feuerte, und dem, was tatsächlich geschah.

Entscheiden in 300 Millisekunden — ohne das Fundament zu verlieren.

Realtime-FRAML bedeutet: bei jeder Transaktion, jedem Login, jeder Kontoeröffnung eine frühe Risikoentscheidung — approve, challenge, block, hold for review — binnen Millisekunden. Für AML heißt das nicht automatisierte Verdachtsmeldung, sondern frühere Risikosteuerung, Priorisierung und kontrollierte Review-Entscheidungen. Das ist der Zustand, in den viele Banken wollen. Und es ist der Zustand, in den die wenigsten sauber gelangen.

Die technische Zutatenliste ist heute relativ konsolidiert: ein Feature Store mit Online-Serving, ein ML-Modell mit erklärbarer Ausgabe (SHAP, Counterfactuals), ein Regel-Overlay für hart-regulatorische Fälle (Sanktionen, Embargos), ein Graph-Service für Peer- und Cluster-Features. Kubernetes, Kafka, gRPC. Das ist selten der schwierigste Teil.

Das Problem ist: jedes dieser Artefakte hat stille Annahmen, die nur in der Nachbetrachtung sichtbar werden. Ein Feature driftet. Ein Modell wird für ein Segment systematisch falsch. Eine Regel erzeugt False-Positive-Kaskaden in einer neuen Geo, die niemand getestet hat. Ohne retrospektive Observability weiß man das nicht — man merkt es nur, wenn die Revision fragt oder die BaFin schreibt.

Die Reihenfolge zählt

Das ist der Punkt, an dem die ganze Kette zusammenschnappt. Observability ist nicht die letzte Stufe — sie ist die erste. Wer direkt auf „KI-gestütztes Realtime-Decisioning“ zielt, ohne die Zustandsraum-Lesbarkeit hergestellt zu haben, baut ein System, das im besten Fall funktioniert und im schlechtesten Fall nicht erklärbar ausfällt.

First make the system legible. Then govern it. Then make it smarter.

Was in diese Rechnung eingeht — und was bewusst nicht.

Die Modellrechnung folgt einem vollkostenbasierten TCO-Modell über fünf Jahre, gerechnet in realen Euro zum Basisjahr, mit impliziter Gehalts- und Lizenzinflation von ≈ 3 % p. a. Der Ansatz orientiert sich an Beobachtungen aus vergleichbaren mid-cap-Instituten und an Referenzwerten aus europäischen AML-Reformabschätzungen. Die Zahlen sind keine Vendor-Kalkulation, sondern ein bewusst transparentes Entscheidungsmodell.

Beide Ansätze werden gegen dieselbe regulatorische Grundlast gerechnet (AMLR, erwartete AMLA-RTS, DORA, MaRisk sowie verbleibende BAIT-Anwendungsfälle je Institutstyp) — das heißt, die regulatorischen Mindest­anforderungen sind in beiden Fällen bedient. Der Vergleich fragt, was es an Aufwand und Nebenwirkung kostet, diese Mindest­anforderungen zu erfüllen.

Klassisch — Fraud-Silo und AML-Silo parallel, regelbasiert, Batch-dominant.

Der Status-quo-Pfad. Zwei getrennte Organisations­einheiten, zwei Vendor-Plattformen, überwiegend regelbasierte Detektion, Nachbetrachtung als Excel- und Case-Management-Arbeit. Realtime nur auf dem Fraud-Pfad, AML strikt Batch.

Auffällig ist die Stabilität: die Jahreskosten kriechen mit der Inflation, aber die Struktur bleibt. Das ist das Versprechen des Silo-Modells — berechenbar, wenig Disruption, wenig Projektrisiko. Der Preis dafür ist sichtbar in den beiden letzten Zeilen: über 26 Mio € in fünf Jahren gehen in nicht-erkannten Fraud und in Kunden, die wegen False Positives abwandern. Diese Kosten stehen in keiner Vendor-Rechnung — sie sind trotzdem real.

FRAML Observability — gemeinsamer Zustandsraum, Graph-basiert, für Nachbetrachtung und Realtime geeignet.

Der Transformationspfad. Fraud und AML auf einem gemeinsamen Graph- und Feature-Fundament, Vendor-Parallelbetrieb in den Jahren 1–2, vollständige Ablösung ab Jahr 3. Weniger Operations-FTE durch Automation, aber höhere Engineering-FTE. Initial höhere Projekt- und Infra-Kosten, strukturell niedrigere Opportunitätsverluste.

Die Struktur ist invertiert. Jahr 1 ist spürbar teurer als im Silo-Modell — 29,3 Mio € gegen 22,1 Mio € — getrieben durch Projekt­kosten und Vendor-Parallelbetrieb. Ab Jahr 3 schneidet B unterhalb von A durch und läuft in einen Steady State, der etwa 40 % günstiger ist als der Silo-Endzustand. Das ist die klassische J-Kurve einer Plattform­investition.

Die J-Kurve sichtbar gemacht.

Was diese Rechnung kippen lässt.

Jede TCO-Rechnung steht und fällt mit ihren Annahmen. Die folgende Tabelle zeigt, wie robust der Vorteil von Ansatz B gegenüber typischen Gegenwind­szenarien ist — und wo er tatsächlich brüchig wird.

Der Vorteil von B ist am verwundbarsten gegenüber Projekt­überziehung und nicht eintretenden Opportunitäts­effekten. Wenn beide Risiken voll durchschlagen, neutralisiert sich der 5-Jahres-Vorteil. Aber: genau diese beiden Risiken sind managbar — durch gestufte Roadmap, klare Success-Kriterien pro Stufe und konservative Modellierung der Nutzeneffekte. Projektrisiko ist ein Lieferrisiko, kein Strukturrisiko.

Umgekehrt ist der Vorteil von A strukturell verwundbar: eine einzelne SREP-Feststellung oder eine ernsthafte AMLA-Prüfung kann die 5-Jahres-Rechnung um niedrige bis mittlere zweistellige Mio-Beträge verteuern, und zwar ohne Vorwarnung, weil Silo-Systeme die Schwachstelle, die bemängelt wird, gar nicht sehen.

Es geht nicht um 19 Millionen. Es geht um die Art, wie das System altert.

Der nominale 5-Jahres-Vorteil von ≈ 19 Mio € ist für ein Institut dieser Größe relevant, aber nicht überwältigend. Er allein trägt die Transformations­entscheidung nicht — jeder CFO kann das Projekt­risiko dagegenstellen, und jeder COO weiß, dass Silo-Betrieb der Pfad des geringsten politischen Widerstands ist.

Die eigentliche Differenz liegt woanders. Ansatz A altert linear: jede neue regulatorische Anforderung, jede neue Typologie, jede neue Sanktionslisten­struktur erzeugt proportionalen Mehraufwand, weil sie in zwei Silos parallel verarbeitet werden muss. Ansatz B altert degressiv: neue Anforderungen werden im gemeinsamen Zustandsraum einmal modelliert und wirken in beiden Domänen.

In der Sprache der vorangegangenen Analyse: Ansatz A kauft Monitoring. Ansatz B kauft Observability. Der Preis­unterschied nach fünf Jahren ist fiskalisch nachweisbar. Der Fähigkeits­unterschied ist es im Zehnjahresblick — und er wird in einer Welt, in der Typologien, Sanktionen und Aufsichtserwartungen schneller driften als Vendor-Release-Zyklen, der eigentlich bestimmende Faktor sein.