DORA Article 28: what a bank actually files on a fintech ICT provider.

DORA enforced January 2025. Every EU bank now needs a third-party ICT register and an evidence pack per provider. Here's the exact pack Coreal hands the bank for its DORA file — copyable as a baseline.

The 2025 boundary

DORA — the Digital Operational Resilience Act (Regulation (EU) 2022/2554) — became enforceable on 17 January 2025. For the first time, EU financial entities have a binding regulation, not a soft guideline, on how to manage their ICT third-party risk. The penalty floor is 2% of annual global turnover.

For a tier-1 EU bank, the practical consequence is simple: every ICT third party that touches a regulated function now needs a documented entry in the bank's outsourcing register, plus an evidence pack the regulator can read on demand. The bank's compliance team has not previously had to do this at this granularity. The fintech provider — us — has not previously had to provide this packaged. Both sides are figuring out the format in real time.

This essay shows what Coreal actually hands the bank for its DORA file. It is copyable. If your bank is using us as an ICT provider, treat what's below as the baseline you can replicate for the next vendor — and the next.

What Article 28 asks for

DORA Article 28 — General principles for ICT third-party services — has three operational asks of the bank, not the provider:

1. Maintain an information register of all contractual arrangements with ICT third parties (Art. 28(3))
2. Conduct an assessment before entering the arrangement (Art. 28(4))
3. Adopt a written policy on ICT third-party risk (Art. 28(2))

The bank does these three things. The provider supports the bank by giving it the inputs to fill them in. That's the asymmetry.

Article 28 also distinguishes between ICT services supporting critical or important functions (heavier obligations) and the rest. For a bank using Coreal's KYC orchestration, ledger, payment orchestration or BPM, we sit firmly on the critical-or-important side. So everything that follows assumes the heavier regime.

The evidence pack

The pack we hand the bank has eight artefacts. Three are organisational, three are technical, two are contractual.

Organisational (3)

1. ICT third-party identification card

A one-page document — the bank's outsourcing-register entry, pre-filled. It includes:

• Provider legal entity (registered office, UBO chain, regulator filings)
• Sub-providers (their legal entities, the chain)
• Function classification (Coreal services tied to critical-or-important functions per RTS on subcontracting)
• Location of services performed (data residency, country of operation)
• Substitutability assessment (where the bank could fall back if Coreal failed)

The "substitutability" line is the one most banks forget to ask for. EBA Guidelines on outsourcing arrangements (paragraph 75) require the bank to show that the function can be moved or insourced if the provider becomes unsustainable. The DORA RTS on subcontracting (in force from July 2024) extends this.

2. Concentration-risk note

A paragraph the bank can append to its own DORA Art. 29 concentration-risk analysis. We declare:

• What share of our customer base is in the bank's home country
• What share of our compute is in single cloud regions (the bank wants to know if our entire stack lives in one AWS region)
• Whether we host data in a single EU member state (we don't — multi-region active-active)

This is mostly for the bank's own diversification check. We provide the numbers so the bank doesn't have to ask under NDA.

3. Sub-provider chain & flow-down clauses

A two-page diagram showing every sub-provider in our chain — sponsor bank for EMI passporting, KYC vendor (Onfido / iProov), sanctions screening (Refinitiv / Dow Jones), cloud (AWS Frankfurt), data backups (separate AZ in Dublin). For each, we attach evidence that DORA flow-down clauses (Art. 30(2)(a–i)) propagate. The bank's lawyers love this — it saves them having to read all our sub-vendor contracts.

Technical (3)

4. ICT risk-management framework alignment statement

A 4-page document mapping our internal controls to DORA Art. 6 (ICT risk management framework). We show:

• Our internal ICT risk register (which we maintain anyway, because we operate as an EMI under similar EBA outsourcing rules)
• Our continuity and recovery time / point objectives (RTO/RPO) per service
• Our incident-classification taxonomy (Art. 18)
• Our threat-led penetration testing cadence (Art. 24 — TLPT scope; ours is annual)
• Our exit strategy from the bank (Art. 28(8))

The mapping table is the key bit. The bank's compliance team can take it and write their internal audit response in minutes, not days.

5. Operational continuity & exit plan

The exit plan is mandatory under Art. 28(8) and most providers don't ship one. Ours is concrete:

• Day 0 (terminate notice): Coreal continues operating at full SLA for the full notice period (typically 6–12 months for tier-1 critical services).
• Day 1–30 of notice: handover starts. Bank receives a replicated copy of the ledger, decision journal, customer records and a documented schema. We provide a named migration engineer dedicated to the bank's handover.
• Day 60: bank-side dry-run of fallback. Our team helps validate.
• Day 90–270: gradual cut-over. Bank can run dual-mode for as long as it needs.
• Day final: source code escrow (we do this from day one, not at termination) is released if requested.

We attach the named replacement providers we have already pre-qualified for the bank's likely fall-back scenarios.

6. Incident-reporting hookup

DORA Art. 19 requires the bank to report major ICT incidents to its national competent authority on a structured taxonomy and tight clock. The bank can't do that if the provider notifies it the same way every other vendor does — by email, eventually. We give the bank:

• An incident-classification mapping (our internal taxonomy → DORA's taxonomy)
• A pre-built webhook from our incident system to the bank's GRC tool (ServiceNow, OneTrust, Archer, or custom)
• Sample reports from real (anonymised) past incidents in our ledger of incidents

That last one is a credibility test. Most providers won't share past incidents. We do, on the principle that the bank's own past-incident inventory will be reviewed anyway, and a provider that hides its history is a worse partner.

Contractual (2)

7. The contract itself — DORA-compliant clauses

Our standard contract includes the clauses DORA Art. 30 requires for critical-or-important functions:

• Clear description of the service (Art. 30(2)(a))
• Locations of service performance and data storage (Art. 30(2)(b))
• Data protection and access provisions (Art. 30(2)(c))
• Service level descriptions, including KPIs and reporting (Art. 30(2)(d))
• Cooperation with competent authorities (Art. 30(2)(e))
• Termination rights, including for the bank's regulator (Art. 30(2)(f))
• Notice period (Art. 30(2)(g))
• Sub-outsourcing conditions (Art. 30(2)(h))
• Exit plan (Art. 30(2)(i))

For functions supporting critical-or-important functions, Art. 30(3) adds five more clauses (incident reporting, audit rights, security requirements, etc.). All present in our standard MSA.

8. Audit rights & access to information

Article 30(3)(d) requires the bank's regulator to be able to audit the provider. Our standard contract grants unrestricted on-site audit rights to the bank's competent authority (BaFin, ACPR, ČNB, etc.), with one month's notice. We do not charge for these audits. We also commit to participating in the EBA AMLA pooled-audit programme when it goes live (expected late 2026).

What the bank does with this

The bank's compliance officer takes the eight artefacts and:

1. Files the ICT third-party register entry (using artefact 1 as input)
2. Attaches the concentration-risk note to its Art. 29 analysis (artefact 2)
3. Maps the sub-provider chain into its own register (artefact 3)
4. Cross-references our risk-management alignment to its own framework (artefact 4)
5. Imports the exit plan into its outsourcing-arrangement file (artefact 5)
6. Configures the incident webhook to its GRC tool (artefact 6)
7. Reviews the contractual clauses against its DORA gap analysis (artefact 7)
8. Confirms audit rights with its internal audit function (artefact 8)

A bank that did not have a provider giving it this pack would spend roughly 60–80 person-hours of compliance + legal time per provider to assemble the equivalent. With our pack, it's 8–12 hours of review.

If the bank uses ten ICT third-parties supporting critical-or-important functions (typical for tier-1), that's a saving of 480–680 hours per year, every year, on this one part of the DORA file.

What the regulator actually reads

We've watched competent authorities review a bank's DORA file in practice. They are pragmatic. They check three things on the third-party side:

1. Is the register complete and accurate? They cross-reference declared providers against incident reports, SLA reports and customer-impact data. Holes get flagged.
2. Does the bank actually exercise its audit rights? A bank that has the audit-rights clause but has never exercised it gets a warning. Provider-side, we book one annual audit visit per top-3 bank, regardless of need, just so the right is exercised.
3. What's the exit plan, and is it tested? A paper exit plan with no dry-run is treated as no plan. Test the exit plan once a year. Our pack ships with the dry-run procedure already documented.

Banks that fail their DORA reviews fail on item 1 (incomplete register) or item 3 (untested exit). The provider can't help with audit-rights exercise — that's the bank's responsibility — but we ship the dry-run procedure for free.

What to ask your other ICT providers

Take this list. Send it to the rest of your ICT third-parties supporting critical-or-important functions. If a provider can't ship the equivalent pack within 30 days, that's a signal worth following up on. Possibly the provider is on the wrong side of DORA preparedness. Possibly the function isn't as critical as your map says — re-check. Possibly the provider is fine but the relationship needs maturity work.

We've spent the last 12 months building this pack for our own bank partners. We don't keep it scarce. The whole point of DORA Art. 28 is that the EU financial system gets better at supplier risk. Providers hoarding their own evidence don't help that. Banks getting better at asking for it do.

Wave-1, Wave-2, Wave-3 — and DORA

If you're using Coreal in production, the DORA pack updates per Wave:

• Wave-1 (modernised KYC orchestration): the pack ships at go-live, evidence-of-operation accumulates from week 1.
• Wave-2 (new products on Coreal ledger): the pack gets a new line per product. Card-to-card, FX, crypto-buy — each one is a service entry. The evidence pack updates automatically through the Minctrl pipeline.
• Wave-3 (gradual core demotion): the pack changes shape — Coreal moves from "supports a critical-or-important function" to "is the primary system of record for a defined customer-product slice". The bank's DORA file gets restructured. We help with the rewrite.

The Wave-1 field note covers the engineering sequence: Wave-1 in 90 days for a tier-1 CEE bank.

For the architectural framing of why we sit adjacent to your core, not in place of it, see the solutions page for banks.

Indicative — DORA's RTS and ITS suite is still expanding; member-state competent authorities are taking divergent positions on edge cases. Treat the above as our practical baseline; check it against your competent authority's published guidance. For a Wave-1 brief scoped to your specific core platform and outsourcing register, book a working session →