An AI agent that initiates a payment against a ledger that cannot guarantee exactly-once execution will produce duplicate debits, phantom credits, and irrecoverable state corruption. This is not a risk to mitigate with retry logic. It is an architectural incompatibility between agentic transaction patterns and the isolation model most financial databases run on.
44% of finance teams have deployed agentic AI in production workflows as of 2026 (Forrester). The 50 largest banks announced more than 160 AI use cases in 2025. Agents are now initiating transactions, adjusting risk limits, triggering settlement workflows, and making compliance decisions in production environments. Most of them are operating against infrastructure designed for human-paced, single-submission transaction patterns.
The Exactly-Once Problem Under Agentic Load
A human initiating a payment through a UI creates a single, discrete event. There is intent, a confirmation step, and one submission. An agent operates differently. It retries on network timeouts without knowing whether the original request committed. It runs concurrent sub-workflows targeting the same accounts. It receives ambiguous signals: a 408 Request Timeout that masked a successful write, a 502 Bad Gateway that hid a partial execution, a 200 OK from an API gateway that never reached the database.
Traditional idempotency key patterns address part of this: include a unique token in every request and the server deduplicates on receipt. This works when key generation is deterministic and the agent is the sole source of that key. Both assumptions break under real agentic architectures.
When an agent crashes and restarts from a checkpoint, it may replay events with different ordering than the original execution. When two agents coordinate on a shared goal through a shared context window, both may initiate the same underlying transaction with independently generated keys. When a multi-step workflow times out at step 3 of 5, the resuming agent may not know which steps already committed and which did not.
The deeper structural problem: the idempotency check and the ledger write are not atomic. The sequence is check-then-write: verify the key is absent, then insert the transfer. Between step one and step two, another agent, another thread, or another retry may have already written a transfer for the same operation. Under READ COMMITTED isolation this window is invisible. Under REPEATABLE READ the check result may be stale by the time the write executes. Only SERIALIZABLE closes this gap, and SERIALIZABLE at concurrent agentic load is precisely where general-purpose databases hit their contention ceiling.
Race Conditions at Agent Throughput
A single human submits one payment per interaction. An agent processing 500 instructions per second may initiate hundreds of transactions against a shared settlement account within the same second. When 50 concurrent agents rebalance treasury positions across 200 currency pairs, each rebalance involves multi-leg transfers through a small number of aggregator accounts: the EUR settlement account touched by every EUR leg, the clearing suspense account touched by every outbound payment.
PostgreSQL serializes writes to contended rows. Under SERIALIZABLE isolation, conflict detection adds further overhead: when two transactions touch the same account in overlapping windows, one receives ERROR: could not serialize access due to concurrent update and must retry. At 50 concurrent agents each submitting 10 transactions per second to a shared settlement account, the retry rate under contention exceeds 60% within seconds. Each retry consumes a database round-trip, holds a connection, and contends for the same row again.
The degradation is non-linear. At 50 TPS with uniform account distribution, contention is negligible. At 500 TPS against a Zipfian account distribution, where the top 1% of accounts receive 30% of transfers, Amdahl's Law applies directly: if 10% of the workload is inherently serial due to hot-account contention, the theoretical maximum speedup from parallelization is 10x regardless of hardware. Add more connection pool capacity and the contention worsens: more threads competing for the same row lock.
Optimistic locking with version columns moves conflict detection to the application layer but does not eliminate the retry cost. Each conflict still produces a wasted write, a round-trip, and a re-submission. At agentic throughput the overhead is not incidental.
What Protocol-Level Deduplication Provides
Application-layer idempotency keys are insufficient for exactly-once guarantees when the check and the write are separate operations. The guarantee requires that deduplication be atomic with the ledger write. Both happen inside the same atomic boundary, not across an application-visible sequence.
A purpose-built settlement engine implements deduplication as a protocol constraint. Each transfer carries a 128-bit transfer ID. The engine rejects any transfer whose ID it has already processed before reaching storage, at the protocol level, before application code runs. The check and the write are not two operations in sequence. They are one operation: the transfer either commits with its ID recorded, or it is rejected outright. There is no window between them.
For agents that generate new transfer IDs on retry (which is the correct behavior: new attempt, new ID), the protocol provides the underlying safety property: no transfer ID executes more than once. The agent's retry policy and the engine's deduplication are orthogonal mechanisms. Together they provide exactly-once execution without requiring the agent to maintain perfectly consistent state across restarts.
Batch Processing and the Inverted Throughput Model
The throughput ceiling of row-level locking exists because concurrency and correctness are in tension: more concurrent writers means more conflicts, more retries, and more wasted work. The ceiling is a property of the locking model, not the hardware.
A batch-processing settlement engine inverts this relationship. Transfers are collected into batches, up to 8,190 operations per batch, and applied atomically in a single sequential pass. There is no concurrent access to individual account records within a batch: the batch is the unit of atomicity, and the batch executes serially. No conflicts. No retries. No serialization failures.
Under increasing agentic load, the throughput model improves: more concurrent agents means fuller batches. Fuller batches means better amortization of per-batch overhead (consensus round, WAL flush, storage I/O). At 1,000 agent-initiated transactions per second, the engine is more efficient than at 100, because batches approach their maximum fill factor. The relationship between load and throughput is monotonic up to the physical limits of memory bandwidth and disk I/O, not the non-linear degradation of a lock-based system.
The consistency model is strictly serializable by construction: transactions within a batch are applied in submission order, and no transaction can observe the partial state of another transaction in the same batch. The serial order is the batch order. There are no anomalies to prevent because there is no concurrency within the execution path.
DORA's Traceability Requirement Applied to Agents
DORA Article 11 requires "strict ICT-related incident management" including the ability to reconstruct the complete history of any ICT event. When an AI agent is an ICT system participating in financial operations, this requirement applies both to the agent and to the infrastructure it operates against.
For agentic systems, traceability means the agent's decision to initiate a transaction, the parameters it used, the execution path through the workflow, and the final outcome must all be recoverable from a single audit identifier. Application logs scattered across agent orchestration frameworks, workflow engines, and database tables do not satisfy this requirement if they cannot be correlated to a single transaction instance.
Durable execution provides this property architecturally. Every workflow step is journaled before execution. Each journal entry carries the workflow ID, the step number, the input, the output, and the timing. An auditor tracing an agent-initiated payment receives a single workflow ID and can reconstruct every step: the agent instruction, the AML screening call, the ledger debit, the clearing submission, and any compensation that followed. Not because logging was added as an afterthought. The execution model requires a journal to function, and the journal is the audit trail.
DORA Article 5 requires financial entities to manage ICT risk across "all ICT-supported business functions." When AI agents become ICT systems executing financial operations, their failure modes must be assessed and documented. The primary failure mode of an agentic system against a non-serializable ledger is partial state: a multi-step operation that commits some steps and not others without a deterministic recovery path. Partial state accumulates faster under agentic throughput than reconciliation cycles can clear it.
The EU AI Act Dimension
The EU AI Act, effective August 2024, classifies AI systems operating in the financial sector as high-risk under Annex III. High-risk AI systems require technical documentation under Article 11 describing the system's intended purpose, known performance limitations, and interaction with other technical systems.
When an AI agent interacts with a ledger, the ledger's behavior under concurrent agent load is part of that technical documentation. A ledger that produces serialization failures under concurrent AI load is a documented operational limitation. A ledger that produces duplicate transactions when agents retry is a documented defect. These must appear in the technical documentation and risk management records required by Art. 9.
The practical implication: deploying AI agents against financial infrastructure requires auditable architecture at both layers: the agent and the ledger. The agent must produce a complete, correlatable audit trail. The ledger must provide exactly-once execution guarantees that the agent's audit trail can reference. Neither layer can satisfy the regulatory requirement independently.
Trade-offs
Strict serializability has a performance cost. A strictly serializable system accepts fewer concurrent writers than an eventually consistent one, because it must enforce ordering guarantees that eventually consistent systems do not provide. For human-paced applications at 10 transactions per second, this cost is negligible. At agentic throughput, the cost depends on the execution model.
Row-level locking produces the worst-case performance under serializable isolation: high concurrency against hot accounts creates a retry storm. Batch processing eliminates the retry cost entirely, but it introduces a different constraint: all writes in a batch commit atomically, so individual write latency is bounded by batch collection time plus the atomic commit overhead. At 8,190 transfers per batch running at sub-millisecond commit latency, the per-transfer latency is well below 1ms. But the engine operates as a separate process and does not expose a SQL interface, which means existing SQL-based application code must be adapted to the engine's API.
Migration cost is real. For teams operating high-volume ledgers on PostgreSQL today, adapting to a purpose-built settlement engine is a multi-quarter project involving schema migration, query rewrites, and operational tooling changes. For teams building new systems, the decision is straightforward: the correct execution model is cheaper than retrofitting exactly-once guarantees onto an architecture that does not provide them natively.
Fernel Context
Fernel's ledger enforces strict serializability through batch processing, not row-level locking. Transfers are collected and applied atomically in a single sequential pass, with no concurrent access to individual account records within a batch. Each transfer carries a 128-bit transfer ID that the engine validates at the protocol level before storage. Deduplication is atomic with the write, not a separate check preceding it. The engine runs as an isolated process with its own memory space and validation. A bug in an AI agent's payment logic cannot corrupt the ledger: the engine rejects any transfer that violates its invariants, including transfers with duplicate IDs, transfers that would violate double-entry balance, and transfers that reference accounts belonging to different tenants.
Read more: The Ledger | Deterministic Settlement: Why Sub-Millisecond Latency Matters | Why General-Purpose Databases Fail at Financial OLTP
Sources:
- Forrester, Post-Money20/20 Europe 2026 Analysis, agentic AI adoption in financial services
- Money20/20 Europe 2026, 50 largest banks: 160+ AI use cases announced in 2025
- DORA, Regulation (EU) 2022/2554, Art. 5-6 (ICT Risk Management), Art. 11-12 (Response, Recovery, Traceability)
- EU AI Act, Regulation (EU) 2024/1689, Annex III (High-Risk AI Systems in Financial Services), Art. 9 (Risk Management System), Art. 11 (Technical Documentation)
- Amdahl, Gene M. "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67, 1967
- PostgreSQL documentation: Serializable Isolation and Serializable Snapshot Isolation (SSI), https://www.postgresql.org/docs/current/transaction-iso.html