DORA and AI in Financial Services: The Next Frontier of Operational Resilience
The Invisible Intersection
Walk into any European bank's technology operations center and count the AI systems. Credit scoring models that assess millions of applications annually. Fraud detection engines that evaluate every card transaction in milliseconds. Anti-money laundering (AML) systems that flag suspicious patterns across billions of transactions. Customer service chatbots that handle routine inquiries. Risk models that price derivatives and calculate capital requirements. Algorithmic trading systems that execute orders in microseconds.
None of these are "AI projects" in the sense that a chief digital officer might present them. They are production ICT systems — integral to the institution's critical and important functions as defined in DORA Art. 3(22). When they fail, the institution's services degrade. When they produce incorrect outputs, customers are harmed and regulators take notice. When they are compromised, the consequences cascade through the financial system.
DORA, published in December 2022, does not contain the words "artificial intelligence," "machine learning," or "algorithm." It did not need to. DORA governs ICT systems — and AI in financial services runs on ICT systems. The regulatory coverage is implicit, comprehensive, and already enforceable.
Where DORA Meets AI: Article by Article
Art. 7: ICT Systems, Protocols, and Tools
Art. 7 requires financial entities to "use and maintain updated ICT systems, protocols and tools that are reliable, have sufficient capacity, and are technologically resilient." This applies to every AI system in production.
An AI model that produces unreliable outputs — a credit scoring model with degrading accuracy, a fraud detection system with increasing false negatives — violates the reliability requirement of Art. 7. The "sufficient capacity" requirement covers the computational infrastructure that AI systems depend on: GPU clusters, inference endpoints, training pipelines, and data processing systems.
| AI System | Art. 7 Reliability Requirement | Failure Mode |
|---|---|---|
| Credit scoring | Consistent, accurate, non-discriminatory outputs | Model drift, data poisoning, bias amplification |
| Fraud detection | Real-time processing with minimal false negatives | Threshold drift, adversarial evasion, training data lag |
| AML monitoring | Comprehensive pattern detection, low false positives | Alert fatigue from over-sensitivity, blind spots from under-training |
| Algorithmic trading | Predictable execution within defined parameters | Flash crash, unintended market manipulation, latency spikes |
| Chatbot / NLP | Accurate, safe, non-misleading responses | Hallucination, data leakage, prompt injection |
Art. 8: Identification and Classification
Art. 8(1) requires identification and classification of all ICT assets supporting business functions. AI systems are ICT assets. They must appear in the asset register with:
- Owner: Who is accountable for the model's performance and compliance?
- Criticality classification: Derived from the BIA — what happens if this model fails?
- Data classification: What data does the model ingest, process, and output?
- Dependencies: What infrastructure (GPUs, data pipelines, feature stores, third-party APIs) does it depend on?
- Lifecycle status: Training, validation, production, deprecated?
Most institutions maintain separate model inventories (for model risk management, often under SR 11-7 or equivalent frameworks) and ICT asset registers (for DORA). The gap between these inventories is a compliance risk. An AI model that appears in the model risk register but not in the ICT asset register is invisible to DORA governance. An AI model that appears in neither is a shadow AI system — the fastest-growing category of unmanaged ICT risk in financial services.
Art. 9: Protection and Prevention
Art. 9 requires ICT security policies covering "the security of data transfers, network and information systems' security, authentication and access control." For AI systems, this translates to:
- Data security: Training data must be classified, access-controlled, and integrity-verified. Poisoned training data produces compromised models.
- Model security: Models in production must be protected against tampering, extraction, and adversarial manipulation.
- Access control: Who can retrain, update, or modify model parameters? Who can access model outputs? Who can override model decisions?
- Inference security: API endpoints serving model predictions must be hardened against injection attacks, rate-limited, and monitored.
The Deepfake Threat: When AI Attacks AI
In 2025, Deutsche Bank's Hong Kong operations were targeted by a sophisticated deepfake attack. Criminals used AI-generated video and audio to impersonate a senior executive during a video call, convincing a finance team member to authorize a transfer of approximately EUR 120,000. The attack exploited two vulnerabilities simultaneously: the quality of modern deepfake technology and the human tendency to trust familiar faces and voices.
This incident — reported by multiple financial media outlets including Reuters — illustrates a new category of ICT risk that DORA's framework must address:
AI-powered social engineering. Traditional social engineering relies on email (phishing), phone calls (vishing), or physical presence (pretexting). Deepfake technology adds real-time video and audio synthesis, making impersonation attacks dramatically more convincing. Under DORA, a deepfake-enabled fraud is an ICT-related incident (Art. 17) because the attack vector is a technology capability — the AI system that generates the deepfake.
AI versus AI. As institutions deploy AI for fraud detection, adversaries deploy AI to evade detection. This creates an arms race where the reliability of AI defense systems (governed by Art. 7) must continuously evolve to counter AI-powered attacks. The testing requirements of Art. 24-25 must include adversarial testing scenarios that simulate AI-powered attack vectors.
Human trust boundaries. DORA's Art. 13 (learning and evolving) requires institutions to incorporate lessons from incidents into their risk frameworks. The deepfake lesson is that human verification — seeing a face, hearing a voice — is no longer a reliable authentication mechanism. Institutions must implement technical verification layers that AI deepfakes cannot defeat: multi-factor authentication, out-of-band verification, transaction limits, and maker-checker controls for high-value operations.
The Triple Compliance Challenge: DORA + AI Act + GDPR
Financial institutions deploying AI now face three overlapping regulatory frameworks:
| Requirement | DORA | EU AI Act | GDPR |
|---|---|---|---|
| Risk assessment | ICT risk management (Art. 6) | Fundamental rights impact assessment (Art. 27) | Data protection impact assessment (Art. 35) |
| Asset/system inventory | ICT asset register (Art. 8) | AI system registration (Art. 49) | Records of processing activities (Art. 30) |
| Testing | Resilience testing programme (Art. 24) | Conformity assessment (Art. 43) | — |
| Incident reporting | Competent authority (Art. 19) | Serious incident reporting (Art. 62) | Data breach notification (Art. 33-34) |
| Transparency | — | Explainability, human oversight (Art. 14) | Automated decision-making rights (Art. 22) |
| Data governance | Data classification (Art. 8(4)) | Training data quality (Art. 10) | Data minimization, purpose limitation (Art. 5) |
| Third-party management | Third-party ICT risk (Art. 28-44) | Provider obligations (Art. 25) | Processor requirements (Art. 28) |
| Board accountability | Management body (Art. 5(2)) | Senior management involvement | DPO designation (Art. 37) |
The overlap is substantial. An AI credit scoring model that processes personal data must simultaneously comply with DORA (as an ICT system supporting a critical function), the AI Act (as a high-risk AI system under Annex III), and GDPR (as a system that processes personal data for automated decision-making).
The efficient approach is to build a unified governance framework rather than three parallel compliance programmes:
Single asset inventory. Register AI systems once, with metadata that satisfies all three frameworks: ICT risk attributes (DORA), AI system classification (AI Act), and processing activity records (GDPR).
Integrated risk assessment. Conduct one assessment that covers ICT risk (DORA Art. 6), fundamental rights impact (AI Act Art. 27), and data protection impact (GDPR Art. 35). The inputs overlap significantly; the outputs serve different regulatory audiences.
Unified incident response. A single incident involving an AI system may trigger reporting under all three frameworks: DORA Art. 19 (if it meets ICT incident materiality thresholds), AI Act Art. 62 (if the AI system is high-risk and the incident is serious), and GDPR Art. 33 (if personal data is compromised). A unified incident classification and reporting process prevents duplication and missed deadlines.
What Supervisors Will Ask About AI
Based on supervisory signals from the ECB, ESMA, and ENISA's threat landscape analysis, examination focus on AI in financial services will intensify through 2027. The likely questions:
1. "Show me your AI systems in the ICT asset register." If AI models are not registered as ICT assets under Art. 8, the institution has an inventory gap. Supervisors know that financial institutions deploy dozens of AI/ML models; an asset register that shows none (or few) indicates classification failure.
2. "What is the criticality of your AI-powered fraud detection?" If fraud detection is integral to a critical function (payment processing, for example), the AI system inherits that criticality classification. It must be covered by the testing programme, subject to recovery planning, and included in third-party risk assessment if it uses external data or cloud-hosted inference.
3. "How do you test AI resilience?" Art. 24-25 testing requirements apply to AI systems. This includes not just infrastructure resilience (can the GPU cluster survive a failure?) but model resilience (how does the fraud detection model perform under adversarial inputs?) and data pipeline resilience (what happens when a critical data feed fails or delivers corrupted data?).
4. "What is your response plan for a deepfake attack?" Following the Deutsche Bank incident, supervisors will ask whether the institution has classified AI-powered social engineering as a risk, whether the incident response process covers deepfake scenarios, and whether staff training includes recognition of synthetic media.
The DORA-Native AI Governance Model
DORA's framework, despite not mentioning AI, provides a robust governance model for AI resilience:
| DORA Pillar | AI Governance Application |
|---|---|
| Pillar I: ICT Risk Management | AI systems in asset register, model risk as ICT risk, AI data governance |
| Pillar II: Incident Management | AI failure = ICT incident, deepfake attacks, model degradation events |
| Pillar III: Testing | Adversarial testing, model validation, data pipeline resilience |
| Pillar IV: Third-Party Risk | AI cloud providers (GPU-as-a-Service), pre-trained models, external data feeds |
| Pillar V: Information Sharing | AI-powered threat intelligence, shared indicators of deepfake attacks |
The argument is not that DORA needs to be amended for AI. The argument is that DORA's principles — know your systems, test your resilience, manage your dependencies, report your incidents, share your intelligence — apply to AI systems as naturally as they apply to databases and network infrastructure. The challenge is implementation: most institutions have not yet integrated their AI governance with their DORA compliance programme.
The institutions that do so first will be ahead of both the regulators and their competitors. The institutions that wait for explicit AI-specific regulatory guidance will discover that the guidance, when it arrives, looks remarkably like DORA's existing framework — applied to a technology they should have governed all along.
Key Takeaways
- DORA governs AI in financial services implicitly. AI systems are ICT systems (Art. 7). They must be in the asset register (Art. 8), protected (Art. 9), tested (Art. 24-25), and subject to incident management (Art. 17-23).
- The deepfake threat is real and growing. The Deutsche Bank incident (EUR 120K) demonstrated that AI-powered social engineering defeats human verification alone. Technical controls must supplement human judgment.
- Triple compliance (DORA + AI Act + GDPR) is the reality for AI in financial services. Build a unified governance framework, not three parallel programmes.
- Supervisors will ask about AI systems in the ICT asset register, their criticality classification, testing coverage, and deepfake response plans. Institutions that have not integrated AI into DORA governance will face pointed questions.
- DORA's five-pillar framework maps naturally to AI governance: risk management, incident management, resilience testing, third-party oversight, and information sharing.
- The efficient investment is to integrate AI governance into existing DORA structures rather than building separate AI compliance programmes. The regulatory convergence is directional.