Leitstück 08 · Realtime · FinCrime-Architektur 2026

Project Hertha und Echtzeit-Governance

Wenn das Ermittlungsfenster von Tagen auf Millisekunden kollabiert, wird Echtzeitanalytik zu einem harten Governance-Risiko. Erkennen in Echtzeit zwingt zu Entscheiden in Echtzeit — und das ist keine Latenz-, sondern eine Verantwortungsfrage.

Die alte Geldwäschebekämpfung hatte Zeit. Eine Transaktion lief, das Monitoring schlug später an, ein Analyst prüfte über Tage, eine Verdachtsmeldung ging raus. Diese Großzügigkeit ist vorbei. Mit Sofortüberweisungen wird eine Zahlung in Sekunden final und unwiderruflich (Leitstück 04). Das Ermittlungsfenster schrumpft von Tagen auf den Moment vor der Autorisierung. Wer in dieser Welt noch „später prüfen“ sagt, prüft Geld, das längst weg ist.

Das BIS-Innovation-Hub-Projekt Hertha (London Centre, mit der Bank of England) hat untersucht, was Analytik in Echtzeit-Zahlungssystemen leisten kann — aufbauend auf Aurora und ausdrücklich mit einem Minimum an Datenpunkten. Auf einem synthetischen Datensatz von 1,8 Millionen Konten und 308 Millionen Transaktionen fand die Analyse auf Ebene des Zahlungssystems rund 12 % mehr illegale Konten als die Institute allein — und 26 % mehr bei neuartigen, bislang ungesehenen Mustern. Das Zahlungssystem selbst wird so zum Beobachtungspunkt. Doch genau hier beginnt das eigentliche Problem: Erkennen im Millisekundenfenster zwingt zu einer Entscheidung im Millisekundenfenster.

Der Kollaps des Fensters

Die klassische AML-Architektur ist nachgelagert gebaut. Sie beobachtet, was geschehen ist, erkennt Muster über die Zeit und meldet im Nachhinein. Sofortzahlung dreht diese Reihenfolge um: Die einzige wirksame Stelle, an der man eingreifen kann, liegt vor der Finalität — in einem Fenster, das nach der EU-Verordnung über Sofortüberweisungen in Sekunden gemessen wird. Hertha setzt deshalb an der Ebene des Zahlungssystems an, wo sich die koordinierten, kontoübergreifenden Muster zeigen, die im einzelnen Institut unsichtbar bleiben.

Hertha’s Befund: das Zahlungssystem als Beobachtungspunkt

Der Wert von Hertha liegt nicht nur in den Trefferzahlen, sondern in zwei strukturellen Einsichten. Erstens: Netzwerkmuster schlagen Einzelmerkmale. Die größten Gewinne entstehen bei komplexen Schemata über viele Konten und Institute hinweg — genau dort, wo das einzelne Institut blind ist. Zweitens: Das gelingt mit einem Minimum an Datenpunkten. Fortgeschrittene Modelle ziehen ihre Kraft aus Netzwerkstruktur, nicht aus der Anhäufung personenbezogener Daten — eine direkte Brücke zur Datenminimierung aus Leitstück 03 und zur föderierten Logik aus Leitstück 07.

Die Analytik wird besser, je früher sie sitzt — und gefährlicher, je früher sie handeln muss. Frühe Erkennung ist ein Geschenk; frühe Entscheidung ist eine Last.

Das Governance-Problem: drei Antworten, kein Zurück

Erkennt ein System eine verdächtige Zahlung im Autorisierungsfenster, hat es nur drei mögliche Antworten — und jede hat einen Preis, der durch die Finalität verschärft wird. Durchlassen bedeutet bei einem echten Fall: das Geld ist unwiderruflich weg. Halten kauft Sekunden für eine synchrone Prüfung, verzögert aber jede legitime Zahlung, die fälschlich gehalten wird. Blockieren verhindert den Schaden, trifft aber bei einem Fehlalarm sofort einen echten Kunden, der seine Miete nicht zahlen kann. Was früher ein Falsch-Positiv in einer Warteschlange war, ist jetzt ein abgelehnter Mensch in Echtzeit.

Der entscheidende Verlust ist der Mensch in der Schleife. Die ganze Architektur dieses Dossiers — vom EvidencePackage (02) bis zur agentischen Spur (03) — beruht darauf, dass die abschließende Entscheidung ein Gesicht trägt. Im Sekundenfenster ist für einen menschlichen Prüfer schlicht keine Zeit. Die Verantwortung verschwindet damit aber nicht; sie verschiebt sich.

Der Reframe: gestufte, vorab verantwortete Entscheidung

Die Lösung ist nicht, den Menschen ins Millisekundenfenster zu zwingen, sondern seine Verantwortung nach vorne zu verlegen — in die Policy. Eine Echtzeit-Entscheidung wird nicht ad hoc getroffen, sondern nach einer vorab genehmigten, dokumentierten Regel, die nach drei Achsen staffelt: Konfidenz des Signals, Umkehrbarkeit der Folge und Schaden eines Fehlers. Niedriges Risiko läuft automatisch durch. Mittleres Risiko wird für wenige Sekunden gehalten und synchron geprüft. Hohes, hochkonfidentes Risiko — etwa ein Sanktionstreffer — wird hart blockiert. Und alles dazwischen, was sich im Fenster nicht entscheiden lässt, läuft mit erhöhtem Monitoring durch, statt einen Unschuldigen zu treffen.

Python · Gestufte Echtzeit-Entscheidung innerhalb des Finality-Fenstersfrom dataclasses import dataclass
from datetime import datetime, timezone
from enum import Enum

class Action(Enum):
    ALLOW = "allow"; HOLD = "hold"; MONITOR = "monitor"; BLOCK = "block"

@dataclass(frozen=True)
class DecisionRecord:        # auch eine Maschinenentscheidung trägt ein Gesicht:
    action: Action            # die der Policy, vorab vom Menschen verantwortet
    reason: str
    confidence: float
    policy_version: str       # welche genehmigte Regel hat entschieden
    at: datetime

def decide(score: float, *, sanctions_hit: bool, reversible: bool,
           policy_version: str) -> DecisionRecord:
    now = datetime.now(timezone.utc)
    def rec(a, why): return DecisionRecord(a, why, score, policy_version, now)

    if sanctions_hit:                       # hart, unabhängig vom Score
        return rec(Action.BLOCK, "sanctions_match")
    if score >= 0.95:                      # hohe Konfidenz → blockieren
        return rec(Action.BLOCK, "very_high_risk")
    if score >= 0.80 and reversible:        # halten nur, wenn umkehrbar
        return rec(Action.HOLD, "synchronous_review")
    if score >= 0.50:                      # unklar → durchlassen + beobachten
        return rec(Action.MONITOR, "pass_with_monitoring")
    return rec(Action.ALLOW, "low_risk")        # Default: nicht den Unschuldigen treffen

Drei Dinge sind an dieser Policy entscheidend. Sie blockiert nur bei hoher Konfidenz oder hartem Treffer — der Default schützt den unschuldigen Kunden, nicht den Prozess. Sie hält nur, was umkehrbar ist. Und sie erzeugt für jeden Ausgang einen Decision Record mit der Version der Regel, die entschieden hat. Genau das macht die Maschinenentscheidung verantwortbar: Nicht ein Mensch hat im Moment entschieden, aber ein Mensch hat die Regel verantwortet, nach der entschieden wurde — und diese Regel ist versioniert, geprüft und im Ledger aus Leitstück 03 nachvollziehbar.

Wer verantwortet einen automatischen Block?

Die unbequemste Frage der Echtzeit-Governance lautet: Wenn eine Maschine in 200 Millisekunden die Zahlung eines unbescholtenen Kunden blockiert — wer hat das zu verantworten? Die ehrliche Antwort verlagert die Verantwortung in die Zeit. Verantwortet wird nicht die einzelne Aktion, sondern die Policy: ihre Schwellen, ihre Logik, ihre Genehmigung. Die menschliche Entscheidung aus Leitstück 02 verschwindet nicht, sie wandert vom Einzelfall zur Regel — und damit in die Pflicht, diese Regel sorgfältig zu kalibrieren, regelmäßig gegen ihre Fehlerraten zu prüfen und Grenzfälle nachgelagert in einer Review Queue (Leitstück 09) menschlich nachzubearbeiten.

Das hat eine unmittelbare Konsequenz für die Aufsicht. Die AMLA prüft Wirksamkeit, nicht Aktivität (Leitstück 02) — und Wirksamkeit heißt im Echtzeitkontext: Hält die Policy die Balance zwischen verhindertem Schaden und getroffenen Unschuldigen? Diese Frage lässt sich nur beantworten, wenn jede Echtzeit-Entscheidung als Decision Record vorliegt und sich daraus die Fehlerraten beider Richtungen berechnen lassen. Ohne diese Spur ist eine Echtzeit-Blockade nicht Governance, sondern Glücksspiel mit dem Konto des Kunden.

Grenzen — und die Versuchung der Geschwindigkeit

Hertha selbst weist auf die Grenzen hin: Die Ergebnisse stammen aus synthetischen Daten, und eine produktive Einführung wirft komplexe praktische, rechtliche und regulatorische Fragen auf. Die größte Versuchung ist, die gewonnene Geschwindigkeit in Härte zu übersetzen — mehr blockieren, weil man es jetzt kann. Das ist der falsche Schluss. Echtzeit-Erkennung erhöht den Wert des Beobachtens und des Haltens weit mehr als den des Blockierens, weil der Schaden eines Echtzeit-Fehlalarms ungleich höher ist als der einer nachträglichen Prüfung. Die reife Antwort auf ein kollabiertes Fenster ist nicht der schnellere Hammer, sondern die feinere Staffelung.

Ein durchgespielter Echtzeit-Lauf

Drei Zahlungen treffen im selben Sekundenbruchteil auf das Entscheidungstor. Die erste: ein Empfänger steht auf einer Sanktionsliste — sanctions_hit ist wahr, die Policy gibt sofort BLOCK mit Grund „sanctions_match“ aus, unabhängig vom Score, und schreibt einen Decision Record. Hier ist Härte richtig, weil die Konfidenz hart ist.

Die zweite: ein Score von 0,86 auf einer ungewöhnlichen, aber umkehrbaren Überweisung. Die Policy entscheidet HOLD — drei Sekunden Aufschub für eine synchrone Prüfung, kein endgültiger Stopp. Löst die Prüfung den Verdacht auf, läuft die Zahlung doch noch durch; jeder Schritt liegt als Decision Record vor. Der Kunde merkt eine kurze Verzögerung, kein abgelehntes Konto. Die dritte: ein Score von 0,6 auf einem neuartigen Muster, wie es Hertha besonders gut findet, aber mit zu wenig Konfidenz für einen Eingriff. Die Policy wählt MONITOR — durchlassen, aber mit erhöhter Spur, sodass das Muster in die nachgelagerte Analyse und ins Training zurückfließt.

Drei Zahlungen, drei verschiedene, jeweils begründete und protokollierte Ausgänge — und nur eine echte Blockade, dort wo sie hingehört. Genau das ist der Unterschied zwischen Echtzeit-Governance und Echtzeit-Willkür: nicht die Fähigkeit, schnell zu stoppen, sondern die Disziplin, gestuft und belegbar zu handeln. Hätte ein binärer Schalter alle drei nach demselben Schwellenwert behandelt, wäre entweder ein Sanktionsfall durchgelaufen oder ein unschuldiger Kunde blockiert worden.

Kernsätze

Die Echtzeit-Policy entscheidet im Moment und schiebt die Grenzfälle in eine nachgelagerte Prüfung. Doch wenn diese Prüfung selbst von Agenten unterstützt wird — mit Retrieval, Bewertung und Vorschlägen —, stellt sich die Frage, wie man der Maschine bei der Beweisarbeit traut. Das ist Leitstück 09: Die Agentic Audit Pipeline.

Markiert: Realtime · Instant Payments · RegTech Architecture · Governance · Project Hertha · BIS · Architektur