Warum agentische KI Ledger ohne Serialisierbarkeit nicht toleriert
Ein KI-Agent, der eine Zahlung gegen ein Ledger initiiert, das eine exakt-einmalige Ausführung nicht garantieren kann, erzeugt doppelte Belastungen, Phantomgutschriften und irreparable Zustandskorruption. Dies ist kein Risiko, das sich mit Retry-Logik abmildern lässt. Es ist eine architektonische Inkompatibilität zwischen agentischen Transaktionsmustern und dem Isolationsmodell, auf dem die meisten Finanzdatenbanken laufen.
44 % der Finanzteams hatten agentische KI in Produktivworkflows bis 2026 im Einsatz (Forrester). Die 50 größten Banken kündigten 2025 mehr als 160 KI-Anwendungsfälle an. Agenten initiieren nun Transaktionen, passen Risikolimits an, lösen Settlement-Workflows aus und treffen Compliance-Entscheidungen in Produktionsumgebungen. Die meisten operieren gegen Infrastruktur, die für menschlich getaktete, einzeln eingereichte Transaktionsmuster entwickelt wurde.
Das Exactly-Once-Problem unter agentischer Last
Ein Mensch, der über eine Benutzeroberfläche eine Zahlung initiiert, erzeugt ein einzelnes, diskretes Ereignis. Es gibt Absicht, einen Bestätigungsschritt und eine Einreichung. Ein Agent operiert anders. Er wiederholt bei Netzwerk-Timeouts, ohne zu wissen, ob die ursprüngliche Anfrage committet wurde. Er führt gleichzeitige Sub-Workflows aus, die auf dieselben Konten abzielen. Er erhält mehrdeutige Signale: ein 408 Request Timeout, das einen erfolgreichen Write verschleierte, ein 502 Bad Gateway, das eine partielle Ausführung verbarg, ein 200 OK von einem API-Gateway, das die Datenbank nie erreichte.
Klassische Idempotenzschlüssel adressieren einen Teil davon: ein eindeutiges Token in jeder Anfrage, und der Server dedupliziert beim Empfang. Das funktioniert, wenn die Schlüsselgenerierung deterministisch ist und der Agent die alleinige Quelle dieses Schlüssels bleibt. Beide Annahmen brechen unter realen agentischen Architekturen zusammen.
Wenn ein Agent abstürzt und von einem Checkpoint neu startet, kann er Ereignisse in anderer Reihenfolge als die ursprüngliche Ausführung wiederholen. Wenn zwei Agenten über ein gemeinsames Kontextfenster auf ein gemeinsames Ziel koordinieren, können beide dieselbe zugrundeliegende Transaktion mit unabhängig generierten Schlüsseln initiieren. Wenn ein mehrstufiger Workflow bei Schritt 3 von 5 ein Timeout erfährt, weiß der wiederaufgesetzte Agent möglicherweise nicht, welche Schritte bereits committet wurden und welche nicht.
Das tiefere strukturelle Problem: die Idempotenzprüfung und der Ledger-Write sind nicht atomar. Die Sequenz ist Check-then-Write: prüfe, ob der Schlüssel fehlt, dann füge die Überweisung ein. Zwischen Schritt eins und Schritt zwei kann ein anderer Agent, ein anderer Thread oder ein anderer Retry bereits eine Überweisung für dieselbe Operation geschrieben haben. Unter READ COMMITTED ist dieses Fenster unsichtbar. Unter REPEATABLE READ kann das Prüfergebnis veraltet sein, wenn der Write ausgeführt wird. Nur SERIALIZABLE schließt diese Lücke, und SERIALIZABLE unter gleichzeitiger agentischer Last ist exakt der Punkt, an dem Allzweckdatenbanken ihre Kontentionsobergrenze erreichen.
Race Conditions bei Agentendurchsatz
Ein einzelner Mensch reicht eine Zahlung pro Interaktion ein. Ein Agent, der 500 Anweisungen pro Sekunde verarbeitet, kann hunderte Transaktionen gegen ein gemeinsames Settlement-Konto innerhalb derselben Sekunde initiieren. Wenn 50 gleichzeitige Agenten Treasury-Positionen über 200 Währungspaare umbalancieren, beinhaltet jede Umbalancierung mehrbeinige Überweisungen über eine kleine Zahl von Aggregatorkonten: das EUR-Settlement-Konto, das von jedem EUR-Bein berührt wird, das Clearing-Suspense-Konto, das von jeder ausgehenden Zahlung berührt wird.
PostgreSQL serialisiert Writes auf umkämpfte Zeilen. Unter SERIALIZABLE-Isolierung fügt die Konflikterkennung weiteren Overhead hinzu: wenn zwei Transaktionen dasselbe Konto in überlappenden Fenstern berühren, erhält eine ERROR: could not serialize access due to concurrent update und muss wiederholen. Bei 50 gleichzeitigen Agenten, die jeweils 10 Transaktionen pro Sekunde an ein gemeinsames Settlement-Konto einreichen, übersteigt die Retry-Rate unter Kontention innerhalb von Sekunden 60 %. Jeder Retry verbraucht einen Datenbank-Roundtrip, hält eine Verbindung und konkurriert erneut um dieselbe Zeilensperre.
Die Degradation ist nicht-linear. Bei 50 TPS mit gleichmäßiger Kontenverteilung ist die Kontention vernachlässigbar. Bei 500 TPS gegen eine Zipfsche Kontenverteilung, bei der die obersten 1 % der Konten 30 % der Überweisungen empfangen, greift Amdahls Gesetz direkt: wenn 10 % der Workload inhärent serial aufgrund von Hot-Account-Kontention ist, ist die theoretische maximale Beschleunigung durch Parallelisierung 10x, unabhängig von der Hardware. Mehr Connection-Pool-Kapazität verschärft die Kontention: mehr Threads, die um dieselbe Zeilensperre konkurrieren.
Optimistisches Locking mit Versionspalten verlagert die Konflikterkennung in die Applikationsschicht, eliminiert aber nicht die Retry-Kosten. Jeder Konflikt produziert weiterhin einen verbrauchten Write, einen Roundtrip und eine erneute Einreichung. Bei agentischem Durchsatz ist dieser Overhead nicht marginal.
Was protokollbasierte Deduplizierung bietet
Applikationsschicht-Idempotenzschlüssel sind für Exactly-Once-Garantien unzureichend, wenn Prüfung und Write separate Operationen sind. Die Garantie erfordert, dass die Deduplizierung atomar mit dem Ledger-Write erfolgt. Beides geschieht innerhalb derselben atomaren Grenze, nicht über eine für die Anwendung sichtbare Sequenz.
Eine zweckgebaute Settlement-Engine implementiert Deduplizierung als Protokollzwang. Jede Überweisung trägt eine 128-Bit-Transfer-ID. Die Engine lehnt jede Überweisung ab, deren ID sie bereits verarbeitet hat, bevor sie den Speicher erreicht: auf Protokollebene, bevor Anwendungscode läuft. Prüfung und Write sind keine zwei Operationen in Sequenz. Sie sind eine Operation: die Überweisung committet mit ihrer ID aufgezeichnet, oder sie wird direkt abgelehnt. Es gibt kein Fenster zwischen ihnen.
Für Agenten, die bei Retry neue Transfer-IDs generieren (was das korrekte Verhalten ist: neuer Versuch, neue ID), bietet das Protokoll die zugrundeliegende Sicherheitseigenschaft: keine Transfer-ID wird mehr als einmal ausgeführt. Die Retry-Policy des Agents und die Deduplizierung der Engine sind orthogonale Mechanismen. Zusammen bieten sie Exactly-Once-Ausführung, ohne dass der Agent einen perfekt konsistenten Zustand über Neustarts hinweg aufrechterhalten muss.
Batch-Verarbeitung und das invertierte Durchsatzmodell
Die Durchsatzobergrenze der Zeilensperre existiert, weil Nebenläufigkeit und Korrektheit im Widerstreit stehen: mehr gleichzeitige Writer bedeuten mehr Konflikte, mehr Retries und mehr verbrauchte Arbeit. Die Obergrenze ist eine Eigenschaft des Sperrmodells, nicht der Hardware.
Eine Batch-verarbeitende Settlement-Engine kehrt dieses Verhältnis um. Überweisungen werden zu Batches gesammelt, bis zu 8.190 Operationen pro Batch, und atomar in einem einzelnen sequenziellen Durchlauf angewendet. Es gibt keinen gleichzeitigen Zugriff auf einzelne Kontensätze innerhalb eines Batches: der Batch ist die Einheit der Atomarität, und der Batch führt seriell aus. Keine Konflikte. Keine Retries. Keine Serialisierungsfehler.
Unter steigender agentischer Last verbessert sich das Durchsatzmodell: mehr gleichzeitige Agenten bedeuten vollere Batches. Vollere Batches bedeuten bessere Amortisierung des Batch-Overheads (Consensus-Runde, WAL-Flush, Storage-I/O). Bei 1.000 agenteninitiierten Transaktionen pro Sekunde ist die Engine effizienter als bei 100, weil Batches ihre maximale Füllrate annähern. Das Verhältnis zwischen Last und Durchsatz ist monoton bis zu den physikalischen Grenzen von Memory-Bandbreite und Disk-I/O, nicht die nicht-lineare Degradation eines sperrbasierten Systems.
Das Konsistenzmodell ist konstruktiv streng serialisierbar: Transaktionen innerhalb eines Batches werden in Einreichungsreihenfolge angewendet, und keine Transaktion kann den Teilzustand einer anderen Transaktion im selben Batch beobachten. Die Serialreihenfolge ist die Batch-Reihenfolge. Es gibt keine Anomalien zu verhindern, weil es im Ausführungspfad keine Nebenläufigkeit gibt.
DORAs Nachverfolgbarkeitsanforderung angewandt auf Agenten
DORA Artikel 11 verlangt „strenges ICT-bezogenes Vorfalmanagement" einschließlich der Fähigkeit, die vollständige Historie jedes ICT-Ereignisses zu rekonstruieren. Wenn ein KI-Agent ein ICT-System ist, das an Finanzoperationen teilnimmt, gilt diese Anforderung sowohl für den Agenten als auch für die Infrastruktur, gegen die er operiert.
Für agentische Systeme bedeutet Nachverfolgbarkeit, dass die Entscheidung des Agenten, eine Transaktion zu initiieren, die verwendeten Parameter, der Ausführungspfad durch den Workflow und das Endergebnis alle von einem einzigen Audit-Identifier wiederherstellbar sein müssen. Anwendungslogs, die über Agentenorchestrierungsframeworks, Workflow-Engines und Datenbanktabellen verstreut sind, erfüllen diese Anforderung nicht, wenn sie nicht auf eine einzelne Transaktionsinstanz korreliert werden können.
Durable Execution bietet diese Eigenschaft architektonisch. Jeder Workflow-Schritt wird vor der Ausführung in ein Journal geschrieben. Jeder Journaleintrag trägt die Workflow-ID, die Schrittnummer, den Input, den Output und das Timing. Ein Prüfer, der eine agenteninitiierte Zahlung nachverfolgt, erhält eine einzelne Workflow-ID und kann jeden Schritt rekonstruieren: die Agentenanweisung, den AML-Screening-Aufruf, die Ledger-Belastung, die Clearing-Einreichung und jegliche Kompensation, die folgte. Nicht, weil Logging nachträglich hinzugefügt wurde. Das Ausführungsmodell erfordert ein Journal, um zu funktionieren, und das Journal ist der Audit-Trail.
DORA Artikel 5 verlangt von Finanzinstituten, ICT-Risiken über „alle ICT-gestützten Geschäftsfunktionen" hinweg zu managen. Wenn KI-Agenten zu ICT-Systemen werden, die Finanzoperationen ausführen, müssen ihre Fehlermodi bewertet und dokumentiert werden. Der primäre Fehlermodus eines agentischen Systems gegen ein nicht-serialisierbares Ledger ist partieller Zustand: eine mehrstufige Operation, die einige Schritte committet und andere nicht, ohne deterministischen Wiederherstellungspfad. Partieller Zustand akkumuliert sich unter agentischem Durchsatz schneller, als Abstimmungszyklen ihn beseitigen können.
Die EU-KI-Verordnungsdimension
Die EU-KI-Verordnung, gültig seit August 2024, klassifiziert KI-Systeme im Finanzsektor als hochriskant unter Anhang III. Hochriskante KI-Systeme erfordern technische Dokumentation unter Artikel 11, die den beabsichtigten Zweck des Systems, bekannte Leistungsbegrenzungen und die Interaktion mit anderen technischen Systemen beschreibt.
Wenn ein KI-Agent mit einem Ledger interagiert, ist das Verhalten des Ledgers unter gleichzeitiger agentischer Last Teil dieser technischen Dokumentation. Ein Ledger, der Serialisierungsfehler unter gleichzeitiger KI-Last produziert, ist eine dokumentierte operative Begrenzung. Ein Ledger, der doppelte Transaktionen produziert, wenn Agenten retryen, ist ein dokumentierter Defekt. Diese müssen in der technischen Dokumentation und den Risikomanagementunterlagen erscheinen, die Art. 9 verlangt.
Die praktische Implikation: der Einsatz von KI-Agenten gegen Finanzinfrastruktur erfordert prüfbare Architektur auf beiden Ebenen: dem Agenten und dem Ledger. Der Agent muss einen vollständigen, korrelierbaren Audit-Trail produzieren. Das Ledger muss Exactly-Once-Ausführungsgarantien bieten, auf die sich der Audit-Trail des Agenten beziehen kann. Keine Ebene kann die regulatorische Anforderung unabhängig erfüllen.
Trade-offs
Strikte Serialisierbarkeit hat Leistungskosten. Ein streng serialisierbares System akzeptiert weniger gleichzeitige Writer als ein eventual-konsistentes, weil es Ordnungsgarantien erzwingen muss, die eventual-konsistente Systeme nicht bieten. Für menschlich getaktete Anwendungen bei 10 Transaktionen pro Sekunde sind diese Kosten vernachlässigbar. Bei agentischem Durchsatz hängen die Kosten vom Ausführungsmodell ab.
Zeilensperren produzieren den schlechtesten Fall unter serialisierbarer Isolierung: hohe Nebenläufigkeit gegen Hot-Accounts erzeugt einen Retry-Sturm. Batch-Verarbeitung eliminiert die Retry-Kosten vollständig, führt aber eine andere Begrenzung ein: alle Writes in einem Batch committen atomar, also ist die individuelle Write-Latenz begrenzt durch Batch-Sammelzeit plus atomaren Commit-Overhead. Bei 8.190 Überweisungen pro Batch bei sub-Millisekunden-Commit-Latenz liegt die pro-Überweisung-Latenz weit unter 1 ms. Aber die Engine läuft als separater Prozess und bietet keine SQL-Schnittstelle, was bedeutet, dass bestehender SQL-basierter Anwendungscode an die API der Engine angepasst werden muss.
Migrationskosten sind real. Für Teams, die heute Hochvolumen-Ledger auf PostgreSQL betreiben, ist die Anpassung an eine zweckgebaute Settlement-Engine ein mehrquartaliges Projekt mit Schema-Migration, Query-Rewrites und operativen Tooling-Änderungen. Für Teams, die neue Systeme bauen, ist die Entscheidung unkompliziert: das korrekte Ausführungsmodell ist billiger als das nachträgliche Anpassen von Exactly-Once-Garantien an eine Architektur, die sie nicht nativ bietet.
Fernel Context
Fernels Ledger erzwingt strikte Serialisierbarkeit durch Batch-Verarbeitung, nicht durch Zeilensperren. Überweisungen werden gesammelt und atomar in einem einzelnen sequenziellen Durchlauf angewendet, ohne gleichzeitigen Zugriff auf einzelne Kontensätze innerhalb eines Batches. Jede Überweisung trägt eine 128-Bit-Transfer-ID, die die Engine auf Protokollebene vor dem Speicher validiert. Deduplizierung ist atomar mit dem Write, keine separate Prüfung, die ihm vorausgeht. Die Engine läuft als isolierter Prozess mit eigenem Memory-Space und eigener Validierung. Ein Bug in der Zahlungslogik eines KI-Agenten kann das Ledger nicht korrumpieren: die Engine lehnt jede Überweisung ab, die ihre Invarianten verletzt, einschließlich Überweisungen mit doppelten IDs, Überweisungen, die die Bilanz des Doppelten Buchhaltens verletzen würden, und Überweisungen, die Konten verschiedener Mandanten referenzieren.
Weiterlesen: Das Ledger | Deterministisches Settlement: Warum Sub-Millisekunden-Latenz wichtig ist | Warum Allzweckdatenbanken bei Finanz-OLTP scheitern
Quellen:
- Forrester, Post-Money20/20 Europe 2026 Analysis, agentische KI-Adoption im Finanzdienstleistungssektor
- Money20/20 Europe 2026, 50 größte Banken: 160+ KI-Anwendungsfälle 2025 angekündigt
- DORA, Verordnung (EU) 2022/2554, Art. 5-6 (ICT-Risikomanagement), Art. 11-12 (Reaktion, Wiederherstellung, Nachverfolgbarkeit)
- EU-KI-Verordnung, Verordnung (EU) 2024/1689, Anhang III (Hochriskante KI-Systeme im Finanzsektor), Art. 9 (Risikomanagementsystem), Art. 11 (Technische Dokumentation)
- Amdahl, Gene M. „Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67, 1967
- PostgreSQL-Dokumentation: Serializable Isolation und Serializable Snapshot Isolation (SSI), https://www.postgresql.org/docs/current/transaction-iso.html