DORA and the AI Rulebook for Fintech

Why this pillar exists

Last month a head of audit at a regulated lender showed me four separate readiness trackers. One for DORA. One for the EU AI Act. One for the senior-manager regime. One for the card-data standard. Each had its own owner, its own spreadsheet, its own RAG status. Three of the four asked for an asset inventory. All four asked for incident reporting. None of them talked to each other.

She was not behind. She was doing the same work several times. That is the quiet tax of treating each regulation as its own island.

This pillar is the map I drew on her whiteboard that afternoon. It treats DORA as the operational-resilience spine, then folds the wider AI rulebook around it, so one control layer produces evidence a board, an auditor and a regulator all accept. The aim is not less rigour. It is to stop paying for the same rigour four times.

Key decisions ahead

If your firm is putting AI into regulated financial services, four rulebooks now point at the same machinery. Each one was written by a different body, in a different year, for a different worry. Together they decide whether you can ship.

The Digital Operational Resilience Act applies from 17 January 2025. It governs ICT risk for financial entities across the EU, and rests on four pillars that matter for AI. The first is ICT risk management: a governed framework that names your systems, dependencies and recovery posture. The second is incident management and reporting on regulated timelines. The third is digital operational-resilience testing, including threat-led penetration testing, often shortened to TLPT, for the firms in scope. The fourth is third-party risk, including a register of ICT providers and oversight of critical providers, the so-called CTPP regime.

AI counts as ICT under DORA. A model, an inference endpoint and a data pipeline are ICT assets in the same way a database is. An external model provider is an ICT third party in the same way a cloud host is. Most firms miss this, and it is why DORA is the spine of this pillar rather than a sibling to it.

The EU AI Act layers on top. It sorts systems into risk tiers: unacceptable, high, limited and minimal. Annex III names credit-scoring and creditworthiness assessment as high-risk, which puts a large slice of lending in scope. High-risk systems carry a risk-management system, data governance, technical documentation, logging, transparency, accuracy and resilience duties, and human oversight under Article 14. The Act phases in: prohibitions applied first in 2025, and the bulk of high-risk obligations land across 2026 and 2027.

The senior-manager and certification regime in the UK puts a named human on the hook for each of these. It pairs with the FCA and PRA operational-resilience rules, which ask firms to identify important business services and set impact tolerances, the maximum tolerable disruption before harm is done. PCI DSS sits underneath all of it whenever card data is in scope, and AI agents that touch payment flows pull the model into that scope.

So the board faces a sequence of decisions, and the order matters.

The first is scope. Which of your AI use cases are high-risk under the AI Act, which sit inside DORA’s important-business-service definitions, and which touch cardholder data? Get this wrong in either direction and you either over-control low-stakes tools or under-control the ones that can cause real harm. Scope is a judgement call, so write down the reasoning, not just the verdict.

The second is ownership. SM&CR forces a named person to own each control. AI blurs ownership because the model, the data, the prompt and the tool surface often sit with different teams. Someone has to hold the whole chain, with the authority to stop a system, not just the title that says they could.

The third is evidence. Each regime asks for proof. The expensive mistake is generating four sets of it. The disciplined move is generating one set, structured so each regime reads the parts it needs, produced as a by-product of running the control rather than a scramble before each audit.

The fourth is cadence. DORA wants resilience testing, with TLPT on a multi-year cycle for the larger firms. The AI Act wants ongoing monitoring of high-risk systems. SM&CR wants attestation. FCA and PRA want self-assessment against impact tolerances. PCI DSS wants annual validation. These can be one calendar with regime tags, where a single resilience exercise feeds more than one regulator’s expectation.

Get these four decisions right and the rest is execution. Get them wrong and you discover the gaps during an audit, which is the worst possible time and place.

Five dimensions

The work breaks into five dimensions. Each maps to a cluster article in this pillar, and each produces evidence more than one regime can use. Think of them as five columns of a single control register, not five projects.

Dimension 1 — ICT risk and resilience under DORA

DORA is the spine because resilience is the one thing every other regime assumes you already have. If your AI agent goes down mid-dispute, or a model provider you depend on has an outage, that is an operational-resilience event before it is anything else.

The mechanism is the ICT risk-management framework knitting four artefacts together. You need an ICT asset inventory that includes your models, inference endpoints and data pipelines, not just servers. You need a third-party register that names every external model provider as the ICT dependency it is, with the contractual terms DORA expects: audit rights, exit plans and sub-outsourcing transparency. You need resilience testing that includes failure of an AI component, rising to TLPT for the firms in scope. And you need a recovery plan tied to an impact tolerance: if the model provider is unreachable for four hours, what does the customer see, and is that within the disruption we said we could tolerate?

Picture a regulated lender running an AI dispute-triage agent on a third-party model. Its ICT register listed the application and the cloud region but not the model provider. We added the provider as a critical third party, mapped the agent to the important business service it supports, and set an impact tolerance: dispute handling must degrade, never stop, for up to four hours. Then we pulled the model in a controlled test. The first run failed in eleven minutes, because there was no fallback to a rules-based queue. The fix was a fallback, not a finding. The test surfaced the gap before a regulator could.

Most fintech ICT registers I review list the database, the payment processor and the cloud region. They rarely list the model. That single omission is where DORA readiness and AI readiness first meet, and where most firms have a gap they have not yet noticed.

What good looks like is specific. Every model and inference endpoint appears in the ICT inventory. Every external model provider sits in the third-party register with audit rights and a documented exit. Each AI system maps to an important business service with a stated impact tolerance. And the firm has rehearsed an AI-component failure, with a recovery time it can name.

The board question here is direct. If a core AI dependency fails, how long until customers feel it, and how long until we recover? If you cannot answer in minutes and hours, you have a DORA gap and an AI gap at the same time.

Dimension 2 — Incident reporting that covers AI failure modes

DORA mandates incident classification and reporting on regulated timelines. A major ICT-related incident triggers an initial notification, then an intermediate report, then a final report once the root cause is known. The AI Act adds its own serious-incident reporting for high-risk systems. SM&CR expects the accountable manager to know, and to know in time to act.

The mechanism that ties these together is a shared severity taxonomy. DORA classifies major incidents against criteria such as clients affected, data lost, duration and spread. Map your internal severity scale to those criteria once, so a Sev-1 already carries its DORA classification rather than waiting for a manual judgement under time pressure.

The trap is that AI failures do not always look like classic incidents. A model that quietly drifts and starts mis-classifying disputes is not an outage. A prompt-injection that makes an agent leak one customer’s data to another is not a server crash. Your incident taxonomy has to recognise these as reportable events, or your reporting will be technically clean and substantively blind.

Consider an AI-forward financial services provider whose agent began approving a rising share of edge-case refunds after a silent model update upstream. No alarm fired, because nothing was down. Drift surfaced only when finance queried the refund line three weeks later. We rebuilt the triggers so the desk would catch it on day one. An approval-rate shift past a control limit pages the analyst, who classifies it against the DORA criteria. Because the system was high-risk, the same ticket opens an AI Act serious-incident check.

So you extend the existing incident process rather than build a new one. The same triage desk, the same severity scale, the same clock. You add AI-specific triggers: model drift past a threshold, a confirmed prompt-injection, an output-guard failure that released data, a third-party model outage. Each maps to a DORA classification and, where relevant, to an AI Act serious-incident report.

What good looks like is a tabletop you can pass cold. Inject a drift scenario and a data-leak scenario with no warning, and watch the desk classify, clock and route both without reaching for a new runbook. If the AI failure flows through the same machine as a database outage, you have one process and two regulatory outputs. The alternative is two desks watching the same logs, slower and more likely to miss the event that matters.

Dimension 3 — EU AI Act readiness for fintech

The AI Act classifies systems into four tiers. A handful of uses are prohibited outright. Annex III lists the high-risk cases, and for fintech credit-scoring and creditworthiness assessment land squarely there. Fraud detection, customer-facing assistants and automated triage may or may not be high-risk, depending on how they are used. Below that sit limited-risk systems, which mainly carry transparency duties, and minimal-risk systems, which are largely unconstrained.

High-risk classification brings obligations: a risk-management system, data-governance controls, technical documentation, record-keeping, transparency to users, human oversight under Article 14, and accuracy and resilience requirements. Read that list next to DORA and you will notice the overlap. Risk management, logging and resilience appear in both. The AI Act simply asks you to apply them to the model specifically, and the high-risk provisions bite harder across 2026 and 2027.

The mechanism is a classification register that records the verdict and the reasoning behind it. Build a row for every AI use case with its risk tier, the Annex III basis if high-risk, its legal basis for processing, and its named owner. The reasoning matters because tiering is contestable, and a regulator who disagrees with your label will ask how you reached it.

Take a UK consumer finance platform that had quietly waved its affordability model through as a mere analytics tool. On the Annex III reading it was creditworthiness assessment, so the light-touch label was wrong. Reclassifying it pulled in documentation, logging and a human-oversight design the team had skipped. Catching it during readiness cost a fortnight. Catching it during supervision would have meant a finding on a system that decides who gets credit.

So classify honestly and early, and be conservative where harm to a customer is plausible. A wrongly cautious high-risk classification costs you some extra documentation. A wrongly waved-through one costs you a finding, and possibly a customer.

Human oversight deserves a specific word, because it is where good intentions go to die. Article 14 is not satisfied by a person who could intervene in theory. It wants someone with the access, the information and the authority to stop the system, who is actually looking and can understand the output well enough to challenge it. Design that role into the workflow, give them a real off switch, and write down who they are. What good looks like is an oversight operator who has used the off switch in a drill, with a log that proves it. That connects straight to the next dimension.

Dimension 4 — SM&CR accountability for AI

The senior-manager and certification regime in the UK asks a question AI makes awkward: who is responsible? For a database, the answer is usually clear. For an AI agent, responsibility is smeared across the data team, the model team, the platform team and the product owner.

The regime does not accept a smear. A senior manager holds the function under a statement of responsibilities, and the duty of responsibility means they must take reasonable steps to prevent a breach in their area. This dovetails with the FCA and PRA rules, where a named executive owns the firm’s important business services and their impact tolerances. So the decision is not whether to name someone. It is who, and how you give them a fair chance of discharging the duty.

The mechanism is an information supply line, not a job title. The accountable manager needs three feeds. They need the AI use-case register, so they know what exists. They need the model-risk and control evidence, so they know it is controlled. They need the incident feed, so they know when it breaks. Give them those three and the attestation is grounded in fact. Withhold them and it is a signature on trust, which is exactly what the regime is designed to prevent.

I watched this go wrong at a regulated digital payments business where the named manager for an AI service had no standing access to its incident log. The control existed on paper. When an output-guard failure leaked one customer’s data into another’s session, the manager learned of it from a complaint, not the desk. The reasonable-steps question wrote itself. The fix was a weekly control pack and a real-time feed into the manager’s queue, so next time the answer to what they knew and when was on the record before anyone asked.

What good looks like is a manager who, asked at random, can produce their register rows, their latest control evidence and their open AI incidents without leaving the room. This is the dimension boards underrate. They treat accountability as a name in a document. The regulator treats it as a working relationship between a person and a set of controls. The difference shows up the first time something goes wrong and someone asks the accountable manager what they knew and when.

Dimension 5 — Four-regime control mapping

The fifth dimension is the one that pays for the other four. It is the crosswalk: a single control set, each control tagged with the regimes it satisfies. The discipline behind it is plain. Evidence one control, answer four regimes.

The insight is that the regimes overlap far more than they diverge. An asset inventory serves DORA and the AI Act. Incident reporting serves DORA, the AI Act and SM&CR. Logging serves all four. Access control serves PCI DSS and DORA. Lay the controls in rows and the regimes in columns, and most rows carry two or three ticks, a few four.

The mechanism is to write each shared control to the strictest applicable standard, then tag it rather than clone it. Take logging. PCI DSS wants audit trails for cardholder-data access with defined retention. DORA wants ICT event logs that support incident reconstruction. The AI Act wants record-keeping over a high-risk system’s lifetime. SM&CR wants the accountable manager to see the trail. Build one logging standard that meets the toughest of those on retention, integrity, coverage and access, and a single control answers all four.

Where a regime asks for something genuinely unique, you add that control and tag it once. PCI DSS segmentation around the card-data environment is its own row; an AI Act conformity assessment is another. Those stay single-tagged, and that is fine. The point is not to force every control to be shared, but to stop rebuilding the ones that already are.

This is where the lender from my opening story ended up. Four spreadsheets became one register with a regime column, and her team stopped doing the asset inventory three times. What good looks like is a register where you can pull any shared control and watch two or three regulators read the same row without complaint, the unique controls few and clearly marked. The auditors got a cleaner story, because the controls were demonstrably consistent across regimes rather than reinvented for each.

How to know if you’re getting it right

You can feel readiness, but boards want signals they can put on a dashboard. Here are six that tell you the four-regime control layer is real rather than aspirational.

Your asset inventory includes your models and inference endpoints, not only your servers and databases. If a regulator asked you to list your critical ICT dependencies and the model provider was not on the list, you are not DORA-ready and not AI-Act-ready in the same breath.

Your incident process fires on AI-specific events. Run a tabletop where a model drifts or an agent leaks data, and watch whether the desk classifies and clocks it the way it would a database outage. If the AI failure falls through the taxonomy, your reporting is blind where it most needs to see.

Every AI use case has a named accountable manager who can produce, on request, the register row, the control evidence and the recent incidents for their system. Ask the named person directly. If they have to go and find out, the accountability is nominal.

Your controls carry regime tags and your evidence is generated once. Pull any control and ask which regimes it satisfies. If the answer is a confident two or three, the crosswalk is working. If each regime has its own copy of the same control, you are paying the tax.

Your testing calendar is one calendar with tags, not four. Resilience testing, AI monitoring, attestation and card-data validation appear as scheduled items with regime labels, not as four disconnected programmes that happen to overlap by accident.

Your high-risk AI classifications were made conservatively and reviewed by someone outside the building team. Self-assessed risk tiers drift optimistic. An honest classification, challenged by a second pair of eyes and recorded with its Annex III reasoning, is the difference between a defensible position and a finding waiting to happen.

Your important business services have stated impact tolerances, and the AI systems that support them are mapped to those services. Ask what the firm can tolerate if the dispute agent or the affordability model stops. A number in hours, tested once, says the resilience work has met the AI estate. A blank says it has not.

If six or seven of these are true, your control layer is genuine and your next audit is a reading exercise rather than a scramble. If only one or two are true, you have the common shape: four projects, four spreadsheets, and gaps between them no one owns.

Next steps

If you are starting from four separate trackers, here is a week of work that turns them into one spine.

On day one, build the use-case register. List every AI system in or near production. For each, record what it does, what data it touches, whether card data is in scope, and a first-pass AI Act risk tier. This single list is the foundation every regime reads from.

On day two, find the model in your ICT asset inventory. If it is not there, add it, along with every external model provider and inference host as a named third-party dependency. This closes the first and most common DORA gap.

On day three, extend your incident taxonomy. Add the AI-specific triggers: drift past threshold, confirmed prompt-injection, output-guard data release, model-provider outage. Map each to a DORA classification and an AI Act serious-incident test. Do not build a new desk; teach the existing one new shapes.

On day four, assign accountability. For each high-risk use case, name the senior manager who holds it, and confirm they can reach the register, the control evidence and the incident feed. Where they cannot, that is a real gap, and finding it now is the point.

On day five, start the crosswalk. Take ten controls you already run and add a regime column. Tag each one DORA, AI Act, SM&CR or PCI DSS as applicable, and for the shared ones note which standard is strictest, because that is the one you write to. You will see the overlap immediately, and which two or three controls are genuinely regime-unique.

The order is not arbitrary. The register comes first because everything else reads from it. The inventory and incident work come next because most regimes share them. Accountability follows, because a named manager needs something real to be accountable for. The crosswalk comes last, because it only pays off once the underlying controls exist to be tagged.

By the end of the week you have a single register, a single incident process, named owners and the first ten rows of a crosswalk. That is a defensible baseline you can take to a risk committee, and it is the spine the rest of the work hangs from. It will not be complete. It will be honest, sequenced and auditable, which is a far stronger place to negotiate from than four trackers no one trusts.

If your firm is in scope of more than one of these regimes, and almost every EU-facing fintech is, the cost of doing them separately is not just money. It is the gaps between the projects, which are exactly where audits land. A senior practitioner who has built this control layer before can save you the months it takes to learn the overlaps by trial and error.