Financial AI agents operating under DORA, the EU AI Act, and GDPR need infrastructure that supports operational resilience, traceability, and reliable transaction processing. In practice, the following six database capabilities help organizations support those regulatory and operational objectives:
append-only audit storage enforced at the storage layer
per-agent identity attribution on every write
strong read consistency across nodes
storage-layer idempotency
support for rollback and compensating transactions
enforced data residency
If you can’t demonstrate each of these to a compliance supervisor today using existing records, rather than an engineering project, that’s the gap to close before deployment.
DORA (the Digital Operational Resilience Act) entered full application in January 2025. Its ICT risk management obligations are already in force and contain obligations for financial companies that may impact databases.Although the EU AI Act's Annex III timeline was extended under the Digital Omnibus on AI, those changes don’t alter what your database must do before deployment. However, many fintech teams building AI agents have not mapped these requirements onto the infrastructure that they’re already running. For these teams, DORA compliance and broader agentic AI compliance aren’t simply governance exercises. They determine whether an agent can move from controlled testing into a production financial environment without creating audit, availability, or transaction-integrity risks.
When a compliance supervisor examines your system, the question isn’t whether your agent made good decisions: It’s whether you can prove what it did. Every decision must trace back to the inputs behind it, every action has to tie to a specific agent session rather than a shared service account, and every record has to survive in a form that cannot be quietly changed after the fact. Those requirements expose three common failures:
the evidence gap, where logs capture outputs but not the information behind them
the attribution gap, where actions can’t be tied to a specific agent identity and session
the state gap, where agents act on stale data
Those problems don't live in your model. They live in your database.
What audit records support DORA and EU AI Act compliance? 
DORA focuses on operational resilience for critical ICT systems, while the EU AI Act introduces logging and record-keeping obligations for high-risk AI systems. Together, those requirements make comprehensive audit records an architectural requirement for many financial AI agents.
A customer-facing financial AI agent is several regulated components at once:
an ICT (Information and Communications Technology) system under DORA
a high-risk AI system under the EU AI Act if it touches credit decisioning
a processor of personal data under GDPR
What do traditional audit logs capture?
Traditional financial audit trails capture transaction records: who did what, when, against which account, and with what outcome. A loan officer approves an application, and the system logs the approval, the reason code, and the timestamp. If a regulator asks for detailed information, you pull the record. That model works for human decisions, but it does not satisfy what regulators expect for AI agent decisions.
What do regulators require instead?
An AI audit trail is a chronological record of an AI system’s inputs, decisions, actions, authorizations, and outcomes. For an AI agent, that record must make each action reconstructable and attributable to a specific identity and session.
EU AI Act Article 12 requires high-risk AI systems to support automatic event logging throughout their lifecycle at a level sufficient for appropriate traceability. For financial AI agents, organizations may need richer contextual records to reconstruct decisions, investigate incidents, and demonstrate how an outcome occurred.
AI agents introduce an additional operational challenge. Traditional identity and access management links actions to human users, but agents often run under service accounts or shared credentials. To investigate incidents, reconstruct decisions, and satisfy applicable regulatory obligations, organizations need records that identify which agent acted, what input it received, what decision logic it applied, and who or what authorized it.
So the audit log is not a table of outputs; it’s an append-only record that captures, for each agent action:
The agent identifier and session ID
The input data the agent received at the time of the decision
The version ID of any reference data in effect (for example, which OFAC sanctions list version was active)
The reasoning chain: what the agent queried, what it retrieved, and what it concluded at each step
The action taken and its outcome
Whether human review or override occurred, and by whom
A millisecond-precision timestamp that supports accurate incident reconstruction, classification, and regulatory reporting under DORA
Illustrative AI agent audit record showing how database architecture can support DORA operational resilience and EU AI Act traceability objectives.
Here’s what the evidence gap looks like in practice:
A regulator asks to see the reasoning chain behind one agent decision: a flagged transaction, a declined account action, a compliance escalation.
The team pulls the logs and finds timestamps and the agent's final output.
What’s missing is the input the agent was working from at the moment of decision, the fraud score that shaped the outcome, and the version of the policy document in effect at the time. Reconstructing that chain takes days and pulls in systems that were never designed to talk to each other. The supervisor notes the gap. Nothing was wrong with the agent's decision; what failed was the system that was supposed to record it.
Why must immutability be enforced at the storage layer?
Most teams reading this article already have a logging system. The question is whether it captures the complete reasoning chain, not just the final output, in a form that’s immediately available during an examination. In a mutable database, existing records can be updated or deleted after they are written. That makes audit evidence harder to trust because regulators must be able to verify that audit records have not been altered. For systems that need tamper-evident audit records, enforcing immutability at the storage layer is generally more reliable than relying solely on application code, which can be bypassed.
This is an architecture safeguard, not merely a coding convention. Application-layer conventions can be bypassed; storage-layer immutability cannot.
Why is reference data versioning important?
An agent that screens transactions against a sanctions list has to record which version of that list was in effect at the time of screening, not just that a list was consulted. That is a decision about how your database stores and versions reference data; you can’t add it retroactively without reconstructing your entire audit history.
Why does eventual consistency fail AI agents?
Why do AI agents need deterministic transactions?
AI agents need deterministic transactions because financial systems require every committed transaction to produce one correct, consistent outcome. IMF Note 2026/004 (Davidovic and Tourpe, "How Agentic AI Will Reshape Payments") names the central tension of agentic financial systems: probabilistic AI behavior running against the deterministic requirements of payment infrastructure. The paper's own conclusion is that settlement should stay deterministic and rules-bound while AI sits at the intent and authorization layers above it. This is the exact separation that a strongly consistent database enables.
Payment infrastructure has always required deterministic outcomes: A payment either settles or it doesn’t, and a balance is either sufficient or it isn’t, regardless of which replica serves the read.
AI agents make probabilistic decisions, but the financial actions they trigger must still be deterministic. The database between those layers has to guarantee that consistency on every transaction.
Illustration of the audit information an AI agent action may generate to support traceability, decision reconstruction, and regulatory reporting.
How does eventual consistency break AI agent transactions?
In a distributed database with eventual consistency, there’s a window between when a write commits on one node and when it becomes visible to reads on others. For most applications the window is harmless; a dashboard that’s a few seconds stale doesn’t bother anyone. For an AI agent, that same window is a failure mode.
An agent reads state, decides, acts, then reads again to verify. If the second read hasn’t caught up to the first action yet, the agent sees a mismatch and re-plans. This compounds with multiple agents: Agent A reads a customer balance and starts a transaction; Agent B reads from the same path before A's write lands and starts a second transaction against the same balance. The window that was invisible to human users becomes a race condition between agents.
Illustration of how concurrent AI agent sessions acting on stale data can produce conflicting transactions that require investigation and reconciliation.
In financial services, that race condition is a double-spend or a duplicate credit with regulatory consequences, not a cosmetic defect. Strongly consistent transaction processing is the requirement; stale reads and conflicting writes produce duplicate charges and incorrect balances that you then have to explain to both customers and auditors.
Why do AI agents need idempotency?
Idempotency means that repeating the same operation produces the same result without creating an additional side effect. AI agents need this guarantee because they automatically retry operations when a request times out or fails mid-execution.
Each transaction request should therefore carry a unique idempotency key that allows the database to recognize and reject duplicate processing. Without storage-layer enforcement, a retry can create a second debit, a second notification, a second call to an external compliance system. Financial systems require that reprocessing the same event does not create duplicate records or inconsistent results, which means every transaction request should carry a unique identifier and the database should enforce deduplication on it. This is an infrastructure requirement, not an application design choice, because application-layer deduplication tends to fail under concurrent load.
How do AI agents recover from partial workflow failures?
AI agents recover from partial workflow failures by reversing completed work when a later step fails. The standard way to do this is through compensating transactions.
When an agent's workflow spans several steps with external dependencies (check fraud score, update record, send notification, file report), a failure at step four leaves the system in an intermediate state. A payment that debits one account and credits another across two operations can’t rely on a simple rollback if the network drops between them: The debit may have committed while the credit did not, and retrying the original transaction does not cleanly fix it.
The agent doesn’t crash. It produces output, incomplete and inconsistent, but output nonetheless, so the engineer sees a completed request in the logs and the error only surfaces in reconciliation hours or days later.
The saga pattern is a method for managing multi-step transactions, by assigning each completed step a compensating transaction that can reverse its effect if a later step fails. This gives the database an explicit recovery path when a workflow can’t be rolled back as one atomic transaction. Without it, recovery depends on manual reconciliation, which increases operational cost while making recovery more difficult to audit, document, and verify. Which DORA obligations can affect database architecture?
Timeline illustrating key DORA and EU AI Act milestones alongside the database capabilities that support operational resilience, traceability, and regulatory compliance.
Many DORA programs focused on cloud providers, legacy infrastructure, and critical ICT third parties, leaving AI models outside ICT asset inventories, incident-classification criteria, and resilience-testing scope. The following five areas show how DORA obligations and related architectural considerations can affect financial institutions deploying AI agents.
1. ICT asset inventory and criticality classification (DORA Chapter II, ICT risk management, Articles 5 to 16; asset identification and classification under Article 8 – visit all referenced DORA articles here). Your database is an ICT asset, so it must appear in your asset inventory, classified by criticality. For a database serving a customer-facing agent, that classification is almost certainly critical, which brings defined recovery time and recovery point objectives under Articles 11 and 12. Those objectives should be validated through annual testing of ICT business continuity and recovery plans, alongside the broader digital operational resilience testing programme described later in this section. . The common failure is that the database is already in the inventory, but its criticality has never been updated to reflect the agent workload now running on top of it.
2. DORA incident notification timelines (Article 19). If an agent contributes to a major incident, the logs needed to investigate, classify, and report it must be available immediately. Under DORA, incident reporting obligations begin once an organization becomes aware of an incident and continue through the classification and reporting process, including the initial notification required after a major incident is classified. A database that requires engineering work to reconstruct agent activity makes meeting those timelines significantly more difficult because the required evidence should already exist.
3. Third-party AI risk and the ICT register (Chapter V, with the register under Article 28(3)). If a third-party model powers your agent, that provider is an ICT third-party service provider under DORA. You need contractual audit rights over the provider's ICT risk management and evidence of pre-engagement due diligence, and you have to maintain a register of these relationships under Article 28(3), not a flat vendor list. When a regulator asks for evidence of third-party oversight, that information should be complete, current, and readily available. Many organizations maintain it as structured system records rather than static spreadsheets because those records are easier to audit, maintain, and retrieve over time. The Financial Stability Board's November 2024 report on AI in finance flags third-party AI concentration as a systemic risk, the firm-level version of which DORA's Article 29 concentration assessment addresses directly.
4. Resilience testing that reflects production conditions (Articles 24 to 25 for all entities; Articles 26 to 27 for designated entities). Every in-scope entity must run a digital operational resilience testing program under Articles 24 and 25, and that testing has to reflect how the system actually runs. As an engineering practice, AI agent databases should also be evaluated under production-like data volumes and concurrency, because reduced-scale tests may not expose failures that appear at agent speed. A subset of larger or systemically important entities, designated by their competent authority, owe a further obligation: threat-led penetration testing (TLPT) under Articles 26 and 27, run against live production systems at least every three years and governed by the TLPT regulatory technical standards that took effect on July 8, 2025. Even where DORA does not require production-scale testing, AI agent workloads are most effectively evaluated under production-like data volumes and concurrency because those conditions expose failure modes that smaller test environments may never reveal.
5. Data residency and third-party ICT risk (GDPR for data protection; DORA Chapter V for third-party ICT risk management). GDPR regulates cross-border transfers of personal data, and many organizations choose regional hosting as part of their broader data-protection and risk-management strategy. For multi-region deployments, enforcing residency policies at the storage layer is generally more reliable than relying on application routing, which can be misconfigured or bypassed.
DORA separately requires financial entities to assess and manage risks associated with critical ICT third-party providers, including concentration risk, contractual arrangements, and exit strategies. For AI agent deployments, that means understanding how dependencies on database providers could affect resilience, documenting recovery approaches, and validating failover procedures so regional disruptions don’t unnecessarily interrupt critical services.
How do concurrent agent sessions create database failures?
Strong consistency solves one class of problems, but production deployments introduce another: scale. A customer-facing agent runs hundreds of concurrent sessions, each following the same loop of read, decide, write, and verify. At that scale, three additional failure modes emerge.
Context divergence. At production scale, the eventual-consistency problem becomes one of concurrency. Hundreds of agent sessions can read different versions of the same data before recent writes become visible across the cluster, causing them to make conflicting decisions. In a dispute-resolution workflow, for example, two agents may approve incompatible actions on the same account.
Hotspot contention. Agent sessions concentrate their writes on a few tables: audit logs, customer records, agent state. Under high concurrency those tables become bottlenecks, and write delays compound across hundreds of sessions. The delay is itself a compliance problem: sessions that should finish in under a second start taking three, and the audit trail shows gaps a supervisor will ask you to explain.
Read amplification. Each session reads from several sources at once: customer profile, transaction history, fraud signals, policy documents. At human scale those reads are occasional; at agent scale they are continuous and concurrent, putting sustained read pressure on the same tables that are absorbing writes. Payment gateways at peak and gaming platforms during traffic spikes face the same pattern and handle it the same way: horizontal distribution with strong consistency, not a single-leader bottleneck that becomes a shared point of failure under load.
Illustrative reference architecture showing how AI agents, database capabilities, third-party ICT services, and governance controls work together to support operational resilience, traceability, and regulatory compliance.
The pre-deployment database checklist
The three gaps map to the capabilities below. Rows 1, 2, and 7 support evidence, attribution, and incident reporting. Rows 3 and 4 support transaction correctness, while Rows 5, 6, and 8 address recovery, data governance, third-party resilience, and production-scale operation. Treat the checklist as an architecture audit rather than a list of direct regulatory mandates. Together, these eight database properties help prepare AI agents for deployment in regulated environments. Before any agent goes live, you should be able to answer “yes” to each one:
Related
Banking resilience at global scale with Distributed SQL — How Fortune 500 financial services companies use distributed SQL to grow their business, eliminate risk, optimize costs, and ensure an ideal customer experience.
How can you test whether your database is deployment-ready?
You can test whether your database is deployment-ready by verifying that each relevant capability is implemented, tested, and supported by appropriate evidence.
For each row, ask one question: “Can your organization demonstrate or test this capability today without first launching an engineering project?” Where the answer is no, that’s the gap to close before deployment.
What kind of database satisfies all of this?
These properties point to a class of database, not a single product. Append-only and attributable writes, strong consistency across nodes, storage-layer idempotency, compensating transactions, and enforced residency are, taken together, what a distributed SQL database is built to provide: ACID transactions and serializable consistency across a horizontally distributed cluster, so the strong guarantees hold at the scale and concurrency agent workloads create.
A single-leader database patched with application-layer conventions can satisfy any one of these in isolation. Holding all of them at once, under agent load, is the hard part, and the checklist is how you test for it before you commit.
What does this mean for your deployment timeline?
The practical implication is that database architecture must be in place before deployment, because these capabilities cannot be added immediately before a regulatory examination.
DORA is in force now, intensifying through 2026, with no pending deferral. The EU AI Act's Annex III high-risk obligations carried an original August 2, 2026 date, which the May 2026 Digital Omnibus agreement moved to December 2, 2027 by Regulation (EU) 2026/1744, which entered into force on July 27, 2026.
For deployers of high-risk systems that fail their obligations, the penalty under Article 99(4) is up to EUR 15 million or 3% of worldwide annual turnover; the higher EUR 35 million or 7% ceiling under Article 99(3) applies to violations of the Article 5 prohibited practices. The top tier does not typically apply to fintech AI deployments that are classified as high-risk under Annex III rather than as prohibited practices under Article 5. Whichever date governs, the build cycle is the real constraint, because none of the database properties above can be retrofitted on the eve of an examination.
The database question usually arrives late. Teams spend their time on model selection, prompt design, user experience, and evaluation, and the database is assumed to be solved because it was already there. But an agent that makes excellent decisions on infrastructure that can’t satisfy these requirements is not deployable in a regulated environment.
The checklist is a minimum, not a guarantee of compliance with DORA, the EU AI Act, or any other framework. What it establishes is the set of infrastructure conditions. Start there.
Two CockroachDB resources go deeper on these specific problems. The payments system architecture guide covers the distributed transaction model, idempotency guarantees, and the consistency behavior described in the eventual-consistency section, including the failure patterns that emerge when agent retries meet a stale read. The distributed transactions documentation covers the saga-pattern implementation that keeps partial workflow failures from turning into unlogged reconciliation incidents.
The patterns discussed in this article come from real deployments in payments fraud detection, credit decisioning, and customer-service operations in regulated banking. If you’re weighing where your current database stands against the checklist, you can explore how CockroachDB handles financial workloads at cockroachlabs.com/get-started. And if your questions go beyond what either reference covers, you can reach me directly on LinkedIn.
Props: Thank you to Cockroach Labs' David Bressler for review of this article.
Quentin Packard is VP of Americas Sales at Cockroach Labs, where he works with engineering and infrastructure leaders building production-grade agentic AI systems. He previously helped build Splunk’s observability business and has worked across infrastructure automation, secrets management, and real-time data governance at HashiCorp and early stage startups. His writing draws on direct conversations with enterprise teams navigating AI and data architecture in production.
Sources
DORA (Regulation (EU) 2022/2554) and technical standards
uDORA, Regulation (EU) 2022/2554. Asset identification (Article 8), incident reporting (Articles 17 to 23, with timelines in Article 19), third-party risk and the register of information (Articles 28 to 30), concentration risk (Article 29), and resilience testing (Articles 24 to 27). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Commission Delegated Regulation (EU) 2024/1772: regulatory technical standards on the criteria for classifying ICT-related incidents as major. https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj
Regulatory technical standards on the content and time limits for reporting major ICT-related incidents (Commission Delegated Regulation (EU) 2025/301). https://eur-lex.europa.eu/eli/reg_del/2025/301/oj
Commission Delegated Regulation (EU) 2025/1190: regulatory technical standards on threat-led penetration testing (TLPT), applicable from 8 July 2025. https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj
TIBER-EU framework, European Central Bank (the threat-intelligence-based red-teaming framework DORA's TLPT is aligned with). https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
European Securities and Markets Authority, Digital Operational Resilience Act: supervisory activities. https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora
Financial-sector AI risk
Financial Stability Board. "The Financial Stability Implications of Artificial Intelligence." November 2024. https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/
Financial Stability Board. "Monitoring Adoption of Artificial Intelligence and Related Vulnerabilities in the Financial Sector." October 2025. https://www.fsb.org/2025/10/monitoring-adoption-of-artificial-intelligence-and-related-vulnerabilities-in-the-financial-sector/
United States
New York State Department of Financial Services. Cybersecurity Guidance for AI: Part 500 Industry Letter, October 2024. https://www.dfs.ny.gov
PCI DSS v4.0, Requirement 10 (logging and monitoring of access to system components and cardholder data). PCI Security Standards Council.
