DORA for AI in the Financial Sector

What is DORA, and why does it affect AI in the financial sector?

The Digital Operational Resilience Act, DORA for short, formally Regulation (EU) 2022/2554, has been directly applicable since 17 January 2025 and creates, for the first time, an EU-wide uniform framework for the digital operational resilience of the financial sector. Under Art. 2 DORA it applies to 20 categories of financial entities, from credit institutions and insurers to investment firms, payment institutions and crypto-asset service providers. DORA bundles five pillars that were previously scattered across various supervisory requirements: ICT risk management (Art. 5-16), reporting of major ICT-related incidents (Art. 17-23), digital operational resilience testing including Threat-Led Penetration Testing (TLPT, Art. 24-27), management of ICT third-party risk including oversight of critical providers (Art. 28-44), and information sharing (Art. 45). Information sharing is voluntary. For AI systems, the first four pillars matter most.

The decisive lever for AI: the BaFin guidance document on ICT risks in the use of AI in financial entities of 18 December 2025 expressly anchors AI systems as a subset of "network and information systems" within the meaning of Art. 3(2) DORA. As a result, the full catalog of DORA obligations also applies to AI and AI Agent workloads, from data sourcing through model development and deployment to ongoing operation with drift monitoring and decommissioning. Anyone deploying an AI Agent productively in a bank or insurer is therefore building a regulated ICT system with all resilience, testing and third-party obligations.

The four mandatory DORA pillars in the context of AI Agents

ICT risk management (Art. 5-16). AI systems must be integrated into the institution-wide ICT risk management. The BaFin guidance document sets the lifecycle approach as the supervisory expectation: data sourcing → model development → deployment → ongoing operation with drift monitoring → decommissioning. Adversarial training and the monitoring of model drift are explicitly expected. The guidance document is formally non-binding, but in supervisory practice it materially reverses the burden of proof: anyone who does not follow it must, in BaFin examinations, document the equivalence of alternative measures.

Resilience testing (Art. 24-27). AI-supported systems fall under the obligation to regularly test digital operational resilience, up to Threat-Led Penetration Testing (TLPT) for significant institutions. For stochastic, LLM-based agents this is methodologically demanding, because classical testing procedures are designed for deterministic systems.

Incident reporting (Art. 17-23). Vendor-specific AI risks such as hallucinated regulatory citations, hallucinated customer portfolio data or model drift in productive scoring systems are considered material operational risks in the BFSI context. They are reportable only if, as ICT-related incidents, they meet the criteria of Art. 18 DORA and therefore qualify as major (Art. 19 DORA). The magnitude is considerable: in the first three quarters of 2025, 525 major ICT-related incidents were reported to BaFin, around 70% of them by credit institutions.

ICT third-party risk (Art. 28-44). This is the sharpest lever for AI, and the subject of the next section.

ICT third-party risk and the CTPP designation

AI in the financial sector today almost always runs on external infrastructure: hyperscaler clouds, external model and LLM providers or association data centers. This is precisely where DORA comes in: Art. 28-30 govern how financial entities manage their ICT third-party risk, Art. 31-44 the direct oversight of critical providers. On 18 November 2025, the European Supervisory Authorities (ESAs) designated for the first time 19 critical ICT third-party providers (CTPPs), according to the ESA list including AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix and Bloomberg. For each of these providers, one of the three authorities acts as Lead Overseer (EBA, EIOPA or ESMA). It can request information, conduct investigations and inspections, and issue recommendations (Art. 35 DORA). These recommendations are not binding: within 60 calendar days, the provider must state whether it will follow them or explain why it will not (Art. 42(1) DORA). If it does not respond in time or its explanation is deemed insufficient, the Lead Overseer discloses this publicly (Art. 42(2) DORA). As a measure of last resort, competent authorities can require financial entities to temporarily suspend use of the service and, where necessary, terminate the contract (Art. 42(6) DORA).

For banks and insurers on the deployer side, this has concrete consequences:

• Exit plans for critical or important functions must be sufficiently tested and reviewed periodically, not just documented (Art. 28(8) DORA).
• Concentration risk must be assessed before contracting (Art. 29 DORA, for critical or important functions); multi-cloud and exit-ready architectures gain weight as a result.
• AI Agent workloads on hyperscalers remain under additional supervisory observation.

The concentration risk is particularly visible in the DACH region: nearly every bank is reliant for AI workloads either on one of the designated hyperscalers or on association solutions. In Germany, Finanz Informatik (FI) for the savings banks and Atruvia AG for the cooperative banks (Volks- und Raiffeisenbanken) deliberately operate on-premise and sovereign AI stacks (including open-source models such as Mixtral/Llama in their own data centers). The S-KIPilot from FI was rolled out in version 6 in 2025 to around 60,000 savings bank workstations. These association structures are structurally strengthened by the DORA CTPP logic, as long as the designation and BaFin guidance document remain in their current rigor.

DORA Art. 30: The catalog of contractual clauses as a procurement filter

DORA Art. 30 prescribes binding contractual content for ICT third parties and thereby turns vendor selection for AI into a hard compliance gate. Mandatory items include, among others, audit rights, exit clauses, sub-processor controls, service level descriptions with quantitative and qualitative performance targets and the specification of the locations where data is processed (Art. 30(2)(b) and 30(3)(a) DORA). Art. 30(3) requires audit rights, exit strategies and precise performance targets for ICT services supporting critical or important functions. With established hyperscalers, these clauses are part of the standard text today; with young AI startups they are a frequent procurement blocker.

DORA Art. 30 does not stand alone. In AI tenders from banks and insurers, further benchmarks come into play:

The BSI Test Criteria Catalogue for AI Systems in Finance (provisional version June 2025, complete version 2.0 June 2026) comprises almost 100 test criteria across ten topic areas, including security and robustness, transparency, fairness, data quality and governance. Experience shows that evidence of BSI AIC4, ISO 42001, SOC 2 or ISO 27001 improves AI vendors' chances in BFSI tenders.

DORA obligations for AI Agents in banks and insurers

Six risk areas are sector-specific for AI Agents in the financial sector and must be observed beyond DORA, they appear only at the margins in horizontal AI compliance:

1. Model risk management. MaRisk AT 4.3.5 has, since the 2023/2024 amendments, been explicitly applicable also to AI/ML models and requires lifecycle documentation, independent validation, backtesting and periodic review. The BaFin guidance document additionally expects adversarial training documentation and model drift monitoring.
2. Explainability in credit decisions. Under Art. 22 GDPR, credit decisions with legal effect may be based solely on automated processing only by way of exception, and the data subject then has the right to human intervention, to express their point of view and to contest the decision (Art. 22(3) GDPR). On top of this comes the classification of credit scoring as high-risk AI under AI Act Annex III point 5(b), whose obligations apply from 2 December 2027 under the Digital Omnibus. In Germany, Sections 505a and 505b BGB additionally require a creditworthiness assessment before consumer loans. Taken together, the GDPR and the AI Act mean that a responsible person must be able to name the driving factors. End-to-end LLM credit scoring is thereby practically excluded; AI remains in triage and explanation roles.
3. Audit trail completeness. For supervisory special examinations (BaFin special audit, FINMA on-site inspection, OeNB examination), every inference must be logged in an audit-proof manner, including prompt, context, retrieval sources, model version and output.
4. Latency requirements. Trading compliance requires <10 ms, fraud detection <1 s. LLM agents in the hot path are rarely feasible.
5. Data residency. In DE and AT, supervisors increasingly emphasize EU or national residency for AI training and inference data; in Switzerland, banking secrecy (Art. 47 BankG) practically requires CH data storage for customer data.
6. Concentration risk through the CTPP designation (see above).

As a consequence, in 2026 fully autonomous credit decisions and fully autonomous multi-agent trading workflows are not in productive operation. Standard, by contrast, are Tier 1 customer-service agents, fraud detection, AML/KYC triage and regulatory reporting, throughout with human-in-the-loop wherever decisions produce legal effect.

DACH relevance: Three tracks instead of one line

DORA shapes Germany and Austria directly as part of the EU acquis; Switzerland adopts it sectorally and autonomously. This leads to a three-track compliance that institutions operating across DACH must observe:

A FINMA survey from April 2025 covering around 400 institutions shows the adoption level: about 50% of Swiss banks and insurers already use AI or are developing applications, a further 25% plan to deploy within three years; on average around 5 applications are productive and around 9 in development. 91% of AI-using institutions deploy generative AI. The FINMA supervisory notice preceded the BaFin guidance document by exactly twelve months, but is not fully congruent with it, FINMA requires, for instance, central AI inventories with risk classification and fallback solutions.

The Austrian regulatory gap is ambivalent: it creates leeway, but increases uncertainty during on-site inspections, because expectations are not codified ex ante. A central AI service point was established in 2024 at RTR-GmbH, for advice, not for sectoral supervision.

Outlook and practical note

The regulatory goalposts are moving: things to watch include further versions of the BaFin guidance document and its interpretation in special examinations, possible concretizations by FINMA beyond AM 08/2024, and an expected formal AI guideline from the FMA Austria. It is also open whether the first recommendations of the Lead Overseers to the CTPPs will actually move DACH institutions toward genuine multi-cloud or whether it will remain with symbolic exit plans.

For practice, the following applies: anyone deploying AI productively in the financial sector in 2026 should treat the BaFin guidance document as an internal norm (even where the FMA does not yet have its own guideline), operationalize the DORA incident reporting channel and TLPT, use the BSI Test Criteria Catalogue Finance as a vendor filter and think of AI from the outset as an ICT system with full lifecycle management. The compliance share in regulated DACH industries typically accounts for 30-50% of the implementation effort, this is both a risk and a competitive advantage.

Informational, not legal advice. Status of the underlying sources: May 2026, individual details updated in October 2026; provisional deadlines and announced guidelines are to be regarded as movable.