Compliance
DORA and FINMA on AI: third-party risk and governance for financial institutions
Short answer
For EU financial entities, DORA has applied since 17 January 2025, and an AI provider reached by API is an ICT third-party service provider: register it, contract for it and plan your exit. In Switzerland, FINMA Guidance 08/2024 expects an AI inventory, risk classification, data quality, testing and explainability. Masking client data before prompts leave reduces both risks.
A bank's operations team in Frankfurt wants an LLM to classify incoming payment exceptions. Its sister entity in Geneva wants the same thing for client correspondence. Both will call the same model over an API. In Frankfurt that's a DORA question about an ICT third-party provider. In Geneva it's a FINMA question about governing an AI application. Neither regulator wrote a rule called 'ChatGPT', and both expect you to have thought about it anyway.
What does DORA require when you use an AI provider?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025 to banks, insurers, investment firms, payment institutions and most other EU financial entities. It has five pillars: ICT risk management, incident reporting, resilience testing, ICT third-party risk and information sharing. AI use touches all of them, but third-party risk is where it bites first.
An AI model provider you call over an API delivers a digital service through ICT systems, which makes it an ICT third-party service provider in DORA's terms. So does a masking gateway in front of it. That brings a set of concrete duties:
| DORA article | Duty | What it means for an AI provider |
|---|---|---|
| Art. 28(2) | A strategy on ICT third-party risk, owned by the management body | AI providers belong in it, not in a side policy |
| Art. 28(3) | A register of information on all ICT third-party contracts | Each AI provider and each tool in front of it gets an entry |
| Art. 28(4) | Assessment before contracting: risks, due diligence, conflicts of interest | Look at data location, retention, sub-processors and security |
| Art. 28(8) | Exit strategies for services supporting critical or important functions | Know which model you'd switch to and how fast |
| Art. 29 | Assessment of ICT concentration risk | Several business lines on one model provider is concentration |
| Art. 30 | Key contractual provisions: service description, data locations, data protection, access, termination | Consumer AI terms rarely meet these. Enterprise contracts may |
| Art. 17 to 23 | Classifying and reporting major ICT-related incidents | A provider outage or data exposure may be reportable |
Whether the AI use supports a critical or important function decides how heavy this gets. A drafting aid for marketing usually doesn't. A model that classifies payment exceptions or helps with credit decisions may well. Decide that per use case and write the reasoning down.
What does FINMA Guidance 08/2024 expect?
Switzerland has no AI-specific financial market law. On 18 December 2024, FINMA published Guidance 08/2024 on governance and risk management when using artificial intelligence, which sets out what it observed in supervision and what it expects, based on existing technology-neutral rules. FINMA sees AI risks mainly as operational risks, especially model risks such as unstable or incorrect results, bias and poor explainability, plus IT and cyber risks, third-party dependency, and legal and reputational risks.
The guidance covers seven areas. It also notes what FINMA found lacking: institutions focused on data protection more than model risk, some couldn't tell whether third-party products contained AI, and inventories were often incomplete.
- Governance: clear responsibility and accountability for AI, with roles defined across development, use and oversight.
- Inventory and risk classification: a central inventory of AI applications, including bought-in and outsourced ones, each with a risk rating.
- Data quality: rules for the completeness, correctness and integrity of data used by AI.
- Tests and ongoing monitoring: checks on performance and drift, before and during use.
- Documentation: enough to understand purpose, data, model choice and limits.
- Explainability: results that can be understood and challenged, especially where they feed decisions about clients.
- Independent review: for material applications, a review by people who didn't build them.
FINMA guidance sits on top of existing rules: Circular 2023/1 on operational risks and resilience, outsourcing requirements, the revised FADP and banking secrecy. For data in prompts, the Swiss nFADP page covers the data protection side.
How do DORA and FINMA overlap for cross-border groups?
DORA applies to EU entities. FINMA supervises Swiss ones. A group with a bank in Frankfurt and another in Geneva answers to both, and the cheapest way through is one AI inventory that serves both regimes. The DORA register of information wants the contract view: provider, service, data locations, criticality. FINMA wants the application view: purpose, risk rating, owner, testing. The same row can carry both if you design it that way from the start.
The data rules differ more than the governance ones. EU entities work under the GDPR, Swiss entities under the revised FADP and banking secrecy, and client-identifying data often may not leave a Swiss bank at all. That's an argument for a masking policy per environment: the Swiss entity can block where the EU entity masks, while both share the same gateway, the same audit trail and the same approval flow for rule changes.
DORA and FINMA requirements, what Maskflare does, and what stays your job
| Requirement | What Maskflare does | What stays your job |
|---|---|---|
| AI inventory (FINMA) and register of information (DORA Art. 28(3)) | The console shows which providers, gateway keys, devices and MCP servers send AI traffic, including shadow use through the desktop agent | Own the inventory and the register, and assign owners |
| Risk classification (FINMA) | Nothing. That's a judgment about each use case | Rate each application and review it |
| Data protection and client data | Masks client-identifying data before the provider sees it; Exact Data Match for your client list | Decide what may leave the bank at all under banking secrecy |
| Contracts (DORA Art. 30) | Itself an ICT third party to register and contract with; EU-hosted by default, on-premises for enterprise | Negotiate Art. 30 terms with Maskflare and each AI provider |
| Exit and concentration (DORA Art. 28(8), 29) | One gateway in front of nine providers, so switching models is a base URL change | Test the exit and decide on fallbacks |
| Change governance | Four-eyes approval of rule changes, environments for development, staging and production | Define who approves what |
| Data quality, testing, explainability (FINMA) | Nothing for the model itself | Test, monitor and document the AI application |
| Evidence for audit and supervision | Audit export up to 366 days, signed webhooks; no prompts stored | Bring it together for internal audit and the supervisor |
A practical checklist for financial institutions
- Build the AI inventory from traffic, not from a survey. Survey answers miss browser and desktop use.
- Record every AI provider and every tool in front of it in your DORA register of information.
- Decide per use case whether it supports a critical or important function, and apply the matching contract and exit standard.
- Rate each AI application for risk under FINMA's guidance, with an owner and a review date.
- Mask client-identifying data before prompts leave, and load client lists into Exact Data Match.
- Put rule changes under four-eyes approval so the control itself is governed.
- Plan for concentration: know which second model provider you'd use and test the switch.
What masking doesn't cover
Masking addresses the data side: what reaches the provider. It doesn't make a model's output correct, explainable or unbiased, which is where FINMA put much of its emphasis. It doesn't replace the resilience testing and incident reporting DORA asks for. Maskflare itself is an ICT dependency with its own failure modes. The desktop agent fails closed by default, so plan for what happens when it's unavailable. Maskflare's SOC 2 Type II and ISO 27001 audits are in progress, which your third-party due diligence should note.
Frequently asked questions
Is an AI model provider an ICT third-party service provider under DORA?
When you call it as a digital service over ICT systems, as with an LLM API, it generally is. It then belongs in your register of information, and contracts for critical or important functions need the provisions of Article 30.
When did DORA start to apply?
On 17 January 2025. The register of information follows the templates in Commission Implementing Regulation (EU) 2024/2956.
Is FINMA Guidance 08/2024 binding?
FINMA guidance explains how FINMA applies existing law and what it expects in supervision. It creates no new rules, but institutions should expect supervisors to measure them against it.
What does FINMA expect in an AI inventory?
A central, complete inventory of AI applications, including those inside third-party products, each with a risk classification, an owner and the documentation needed to understand it.
Does Maskflare count as a third party under DORA?
Yes. It's an ICT service, so register it and contract for it like any other. Hosting is EU by default, and on-premises deployment is available for enterprise if you prefer to run it yourself.
About the author
Articles on GDPR, the EU AI Act and sector rules, written by the people at Maskflare who answer customers' data protection questions. They're general information, not legal advice; we cite the regulator or the provider's own terms wherever we can.