Financial services AI compliance under DORA
May 2, 2026
When your bank customer asks for your sub-processor list
You are a Dutch fintech, three years old, twenty-five people. You sell transaction monitoring (or fraud detection, or document AI for loan onboarding) into a Dutch bank. The bank's vendor management team produces the standard third-party request. They want every sub-processor in your stack listed, mapped to your Digital Operational Resilience Act register entries, with concentration analysis attached.
If your AI runs on a public AI API from a US provider, your list grows by at least two: the AI vendor and the AI vendor's hyperscaler. Both may be on the November 2025 designation list of Critical ICT Third-Party Providers. The bank's vendor management team will note the addition and forward it to their Critical ICT Third-Party register, where their regulator scrutinizes every entry.
This post is for the founder or chief technology officer at a Dutch fintech selling into a regulated financial entity (a bank, an insurer, an asset manager, a payments service provider) whose own customer's vendor management team has just asked for the third-party register update. It explains what the November 2025 Critical ICT Third-Party Provider designations actually changed, what the bank's regulator now expects, and how customer-environment deployment of AI keeps your bank customer's register short.
A definition first. The Digital Operational Resilience Act (commonly referenced as DORA) entered into force in January 2023 and became applicable in January 2025. It governs how financial entities in the European Union manage information and communication technology risk, including third-party risk. Article 28 sets the general principles for that risk management. Article 30 is the contractual heart: every contract with an information and communication technology third-party provider must include defined clauses on audit rights, incident-notification cooperation, exit assistance, and sub-contracting disclosure. The European Supervisory Authorities published a list of 19 designated Critical ICT Third-Party Providers in November 2025: providers whose failure could pose systemic risk to the European financial sector. Each financial entity's regulator can require enhanced reporting on every Critical ICT Third-Party Provider on the entity's register. DORA Article 30 draws the same vendor-responsibility line as the EU AI Act and GDPR Article 28: where your AI vendor responsibility ends.
"The smallest register is the strongest compliance posture."
How the November 2025 designations changed the conversation
The 19 designations were not a surprise to anyone tracking the regulation. The list includes the major hyperscalers (the European subsidiaries of the largest cloud computing companies), the major information and communication technology services firms, and a handful of software vendors operating critical financial infrastructure. The names matter less than the structural effect: every one of them, when added to a bank's third-party register, comes with enhanced regulatory scrutiny attached.
What the bank's regulator now expects from the bank
The bank, as a financial entity under DORA, must maintain a register of all information and communication technology third-party providers, classify each one by criticality, document concentration risk, and have an exit strategy for the critical ones. For each Critical ICT Third-Party Provider on the register, additional obligations apply: enhanced operational resilience testing, the right of the regulator to conduct on-site inspections, contractual clauses that grant the bank's regulator direct audit access, and reporting on contract changes within defined timelines.
In practice, this means the bank's vendor management team is under pressure from above to keep the Critical ICT Third-Party register short. Adding a new Critical ICT Third-Party Provider triggers paperwork, a regulatory disclosure, and a concentration-risk recalculation. Banks are not blocking new vendors that bring Critical ICT Third-Party Providers into their stack, but they are increasingly preferring vendors that do not.
What this means for the fintech selling into the bank
Fintechs have always been third-party providers to banks. DORA Article 30 made the contractual structure more explicit but the relationship is not new. What is new is that every sub-processor in the fintech's own stack appears on the bank's register one level removed. If your fintech's AI infrastructure depends on a public AI API from a US provider, the AI vendor and the AI vendor's hyperscaler both appear on the bank's register through your contract.
The fintech's own contract terms with the bank now matter more than they used to. The bank wants you to commit to advance notice on sub-contracting changes, to defined incident notification timelines that match Article 30's requirements, and to exit assistance clauses that survive contract termination. None of these are unreasonable. They are operationally heavier than the contracts most fintechs were signing in 2022.
The structural argument for customer-environment deployment
When the AI runs in the bank's own environment (their cloud account, their on-premises infrastructure), the AI is not a separate sub-processor for the bank in the way that a public AI API would be. The AI deployment is operationally an extension of the fintech's deployment, which is itself a sub-processor. The bank's Critical ICT Third-Party register grows by zero new entries because of the AI choice; the bank's hyperscaler relationship is unchanged.
deeplit® is not on the November 2025 designation list. Customer-environment deployment with deeplit® means the bank's register grows by at most one entry (your fintech), not three (your fintech, an AI vendor, an AI vendor's hyperscaler). The structural argument is independent of how good or bad any specific Critical ICT Third-Party Provider is at compliance. It is about the count of designated systemically important providers on the bank's register.
What to put in your data processing agreement with the bank
If you are signing a new contract with a Dutch (or German, or French) bank in 2026, four clauses are worth getting right beyond the standard Article 30 list:
Sub-processor disclosure cadence. The bank typically wants 30 days' advance notice on any change to your sub-processor list, with a right to object. Make sure your AI vendor (or your customer-environment deployment partner) commits to a notification process that lets you meet this clause.
Audit access scope. Article 30(2)(e) requires the contract to grant the bank unrestricted rights of access, inspection, and audit over the ICT third-party provider. They will want a flow-down audit right on your sub-processors. Customer-environment deployment makes this trivially demonstrable because the deployment is inside the bank's environment; the bank can audit it directly without invoking the flow-down clause.
Incident notification timing. DORA's incident-reporting framework (Articles 17 to 23) defines timelines for classifying and reporting major information and communication technology incidents to competent authorities; Article 30 requires the contract to oblige the ICT third-party provider to cooperate with that reporting. Your AI vendor's incident notification timing must be tighter than yours so that you can meet your timing to the bank.
Exit assistance and data return. The bank wants the right to terminate and have your sub-processors continue to operate during a transition period. Customer-environment deployment helps here too: the deployment continues to function on the bank's hardware after termination, so the transition is controlled by the bank's own timeline. The clause-by-clause walkthrough is in GDPR DPA template for AI.
The smallest register is the strongest compliance posture
Every Critical ICT Third-Party Provider on your bank customer's register is a question they have to answer to their regulator. Every additional designated provider in your stack is a question they have to answer because of you. The bank's vendor management team will not say this in the procurement conversation, but it shapes their preferences. The fintech that arrives with a stack containing zero additional Critical ICT Third-Party Providers is the easier conversation.
This is not the only argument that decides the deal. Pricing, fit, references, and the strength of the product matter more in absolute terms. But for a tied evaluation between two fintechs with similar products, the one whose AI choice does not add a Critical ICT Third-Party Provider to the bank's register has a structural advantage that compounds across multiple deals.
If you are eight to twelve weeks from a deal that just hit the third-party register conversation, book a deployment call. Bring the bank's vendor management requirements (the Article 30 clause list, the sub-contracting disclosure cadence, the audit access scope) and we will tell you whether deeplit® is the right call or whether one of the other architectural options serves you better.
If your bank end-customer's vendor management lead is the one asking, this post is written to be forwarded to them. The Critical ICT Third-Party register argument is theirs to use in their own concentration analysis.
Every Critical ICT Third-Party Provider on your bank customer's register is a question they have to answer to their regulator.
The smallest register is the strongest compliance posture.
Frequently asked questions
Is deeplit® a Critical ICT Third-Party Provider?
No. The November 2025 designation list contains 19 providers, predominantly hyperscalers and major information and communication technology services firms. deeplit® is not on the list and is not at the scale where designation would apply (the criteria include systemic importance and substitutability across multiple financial entities). Future designations are possible but not for a long time.
Does customer-environment deployment exempt the fintech from DORA Article 30 obligations?
No. The fintech's contract with the bank still includes Article 30 clauses. What changes is the count of additional Critical ICT Third-Party Providers introduced into the bank's stack through the fintech's contract. Customer-environment deployment with a non-designated vendor adds zero. A public AI API with a designated vendor adds two (the AI vendor and the hyperscaler).
What if the fintech's bank customer is in Germany or France?
The same structural analysis applies. German banks supervised by the Federal Financial Supervisory Authority (BaFin) and French banks supervised by Autorité de contrôle prudentiel et de résolution (ACPR) are subject to the same DORA framework. The Critical ICT Third-Party register is the same list across the European Union. The local regulator's enhanced supervision applies to the same providers.
How do we document the audit boundary in a DORA-compliant data processing agreement?
The audit boundary documentation in your data processing agreement with the bank should reference the customer-environment deployment pattern explicitly: the data path is inside the bank's environment, the bank's existing audit logging captures every action, the vendor's read access is time-bounded and re-grant-required for incident response. See where your AI vendor responsibility ends for the full clause-level structure.
