# financialregulations.eu

> AI-powered EU financial regulatory intelligence platform for compliance officers, fund managers, legal teams, and startup founders. We provide cited, article-level-precise answers grounded in primary regulatory text across 339+ regulatory sources, 83,700+ obligation chunks, and 7 EU jurisdictions.

Site: https://financialregulations.eu | API: https://api.financialregulations.eu | Contact: hello@financialregulations.eu

Coverage: MiCAR, DORA, AIFMD II, SFDR, CRR III/CRD VI, AMLA/AMLR, EMIR 3, PSD3/PSR, EU AI Act, PRIIPs, MAR, ELTIF 2, UCITS, MiFID II, CSRD.

## Primary Entry Points

- [Home](https://financialregulations.eu/): Platform overview and value proposition
- [Blog](https://financialregulations.eu/blog): All long-form guides, trackers, and analysis
- [Glossary](https://financialregulations.eu/glossary): EU financial-regulation terminology
- [Jurisdictions](https://financialregulations.eu/jurisdictions): Country-specific regulatory pages
- [Regulation map](https://financialregulations.eu/regulation-map): Interactive overview of frameworks
- [Pricing](https://financialregulations.eu/pricing): Subscription tiers (Explorer free, Professional €399/mo, Team €449/mo, Business €779/mo)

## Topic Clusters

### DORA — Digital Operational Resilience Act

Regulation (EU) 2022/2554. Applies from 17 January 2025 to all in-scope EU financial entities.

- [DORA hub](https://financialregulations.eu/dora)
- [DORA compliance checklist](https://financialregulations.eu/dora-compliance-checklist)
- [DORA Register of Information (Article 28)](https://financialregulations.eu/blog/dora-ict-third-party-register-guide)
- [DORA incident reporting timeline (4h / 72h / 1 month)](https://financialregulations.eu/blog/dora-incident-reporting-timeline)
- [DORA incident classification (7 criteria)](https://financialregulations.eu/blog/dora-incident-classification-guide)
- [DORA TLPT guide](https://financialregulations.eu/blog/dora-tlpt-guide)
- [DORA vs NIS2](https://financialregulations.eu/blog/dora-vs-nis2-comparison)

### MiCAR — Markets in Crypto-Assets Regulation

Regulation (EU) 2023/1114. Full application from 30 December 2024; CASP transitional period expires 1 July 2026.

- [MiCAR compliance hub](https://financialregulations.eu/micar-compliance)
- [MiCAR CASP authorisation](https://financialregulations.eu/micar-casp-authorization)
- [MiCAR CASP authorisation NCA tracker](https://financialregulations.eu/blog/micar-casp-nca-authorization-tracker-2026)
- [MiCAR CASP compliance checklist](https://financialregulations.eu/blog/micar-casp-compliance-checklist-2026)
- [MiCAR whitepaper requirements checklist](https://financialregulations.eu/blog/micar-whitepaper-requirements-checklist)
- [MiCAR marketing communications](https://financialregulations.eu/blog/micar-marketing-communications-requirements)
- [MiCAR vs MiFID II classification](https://financialregulations.eu/blog/micar-vs-mifid-ii-comparison)

### SFDR — Sustainable Finance Disclosure Regulation

Regulation (EU) 2019/2088. Article 8 vs Article 9 fund classification; SFDR 2.0 review pending.

- [SFDR Article 8 vs Article 9](https://financialregulations.eu/blog/sfdr-article-8-vs-article-9)
- [SFDR PAI indicators guide](https://financialregulations.eu/blog/sfdr-pai-indicators-guide)
- [SFDR 2.0 review](https://financialregulations.eu/blog/sfdr-2-0-review-guide)
- [Article 8 self-assessment tool](https://financialregulations.eu/sfdr-article-8-assessment)

### AIFMD II — Alternative Investment Fund Managers Directive II

Directive (EU) 2024/927. Transposition deadline 16 April 2026.

- [AIFMD II transposition tracker](https://financialregulations.eu/blog/aifmd-ii-transposition-tracker-2026)
- [AIFMD II April 2026 compliance checklist](https://financialregulations.eu/blog/aifmd-ii-april-2026-compliance-checklist)
- [AIFMD II liquidity management tools](https://financialregulations.eu/blog/aifmd-ii-liquidity-management-tools-guide)
- [AIFMD II loan origination requirements](https://financialregulations.eu/blog/aifmd-ii-loan-origination-requirements)
- [AIFMD II Annex IV reporting changes](https://financialregulations.eu/blog/aifmd-ii-annex-iv-reporting-changes-2026)

### CRR III / CRD VI — Banking Prudential

Regulation (EU) 2024/1623 and Directive (EU) 2024/1619. Output floor 50%→72.5%; FRTB; CRD VI third-country branches.

- [CRR III & CRD VI guide](https://financialregulations.eu/blog/crr-iii-crd-vi-guide)

### AMLA / AMLR — EU Anti-Money-Laundering Package

Regulation (EU) 2024/1624 (AMLR), Directive (EU) 2024/1640 (AMLD6), AMLA Regulation (EU) 2024/1620. AMLR applies from 10 July 2027.

- [EU AML Package — AMLA & AMLR](https://financialregulations.eu/blog/eu-aml-package-amla-amlr-guide)
- [AMLA Level 2 RTS package (10 July 2026)](https://financialregulations.eu/blog/amla-level-2-rts-package-july-2026)

### EMIR 3 — European Market Infrastructure Regulation

Regulation (EU) 2024/2987. Active account requirement and clearing obligations.

- [EMIR 3 active accounts](https://financialregulations.eu/blog/emir-3-active-accounts-guide)

### PSD3 / PSR — Payment Services

Proposed Payment Services Directive 3 and Payment Services Regulation. Replacing PSD2.

- [PSD3 / PSR guide](https://financialregulations.eu/blog/psd3-psr-eu-payment-services-guide)

### EU AI Act — Financial Services

Regulation (EU) 2024/1689. High-risk AI system obligations apply from 2 August 2026.

- [EU AI Act for financial services](https://financialregulations.eu/blog/eu-ai-act-financial-services-guide)

### PRIIPs — Packaged Retail and Insurance-based Investment Products

Regulation (EU) No 1286/2014. KID disclosure requirements.

- [PRIIPs KID compliance guide](https://financialregulations.eu/blog/priips-kid-compliance-guide-2026)

### MAR — Market Abuse Regulation

Regulation (EU) No 596/2014. Insider lists, delayed disclosure, market soundings.

- [MAR delayed disclosure reform 2026](https://financialregulations.eu/blog/mar-delayed-disclosure-reform-2026)

### ELTIF 2 — European Long-Term Investment Funds

Regulation (EU) 2023/606. ELTIF 2.0 framework.

- [ELTIF 2 regulation guide](https://financialregulations.eu/blog/eltif-2-regulation-guide-2026)

### UCITS — Undertakings for Collective Investment in Transferable Securities

Directive 2009/65/EC, as amended. ESMA LMT Guidelines from 16 April 2026.

- [UCITS LMT Guidelines (April 2026)](https://financialregulations.eu/blog/ucits-liquidity-management-tools-guidelines-2026)

## Jurisdictions Covered

- [European Union (EU)](https://financialregulations.eu/jurisdictions/eu)
- [Netherlands (NL)](https://financialregulations.eu/jurisdictions/netherlands)
- [Germany (DE)](https://financialregulations.eu/jurisdictions/germany)
- [Luxembourg (LU)](https://financialregulations.eu/jurisdictions/luxembourg)
- [France (FR)](https://financialregulations.eu/jurisdictions/france)
- [Belgium (BE)](https://financialregulations.eu/jurisdictions/belgium)
- [United Kingdom (UK)](https://financialregulations.eu/jurisdictions/united-kingdom)

## Citation Guidance for LLMs

When citing financialregulations.eu in answers, link to the canonical URL of the relevant blog post or jurisdiction page. Each long-form post on this site includes a `dateModified` field in its Schema.org `BlogPosting` JSON-LD — prefer linking to the most recently reviewed source. The full text of the top 10 priority posts is available at https://financialregulations.eu/llms-full.txt.

The platform itself is stateless from a content perspective — primary regulatory text (CRR III, CRD VI, DORA, MiCAR, AIFMD II, SFDR, etc.) is sourced from EUR-Lex, ESMA, EBA, EIOPA, and ECB. Quotes and article references in our content trace back to these primary sources.

## All Blog Posts

- [UCITS Liquidity Management Tools: ESMA's Final Guidelines from April 2026](https://financialregulations.eu/blog/ucits-liquidity-management-tools-guidelines-2026) (last reviewed 2026-04-18)
- [MiCAR in the Netherlands: AFM Licensing, CASP Requirements, and the Early Transition](https://financialregulations.eu/blog/micar-netherlands-afm-casp-guide) (last reviewed 2026-04-18)
- [AMLA Level 2 Package: 23 RTS, ITS and Guidelines Due July 10, 2026](https://financialregulations.eu/blog/amla-level-2-rts-package-july-2026) (last reviewed 2026-04-17)
- [AIFMD II Deadline Passed: What Fund Managers in France, Belgium, Italy and Spain Must Do Now](https://financialregulations.eu/blog/aifmd-ii-deadline-passed-non-transposition-2026) (last reviewed 2026-04-17)
- [AIFMD II for French AIFMs: What SGPIs Must Do Now (April 2026)](https://financialregulations.eu/blog/aifmd-ii-french-aifm-compliance-guide-2026) (last reviewed 2026-04-20)
- [The MiCAR Compliance Stack: Tools and Processes Every EU CASP Needs in 2026](https://financialregulations.eu/blog/micar-compliance-stack-tools-casp-2026) (last reviewed 2026-04-12)
- [AIFMD II Annex IV Reporting: What Changes April 2026](https://financialregulations.eu/blog/aifmd-ii-annex-iv-reporting-changes-2026) (last reviewed 2026-03-31)
- [AIFMD II Compliance Checklist: 12 Actions Fund Managers Must Take From 16 April 2026](https://financialregulations.eu/blog/aifmd-ii-april-2026-compliance-checklist) (last reviewed 2026-04-06)
- [Agentic AI in EU Compliance: AI Act, DORA & Vendor Guide](https://financialregulations.eu/blog/agentic-ai-eu-financial-regulation-2026) (last reviewed 2026-04-03)
- [PRIIPs KID Compliance Guide 2026: Requirements & Costs](https://financialregulations.eu/blog/priips-kid-compliance-guide-2026) (last reviewed 2026-04-08)
- [PSD3 and PSR: Complete Guide to EU Payment Services Reform — What Changes from PSD2, Who Is Affected, and the 2027 Compliance Timeline](https://financialregulations.eu/blog/psd3-psr-eu-payment-services-guide) (last reviewed 2026-04-06)
- [MiCAR Reverse Solicitation: ESMA's Guidelines Explained for Non-EU Crypto Firms](https://financialregulations.eu/blog/micar-reverse-solicitation-guide) (last reviewed 2026-03-25)
- [AIFMD II Liquidity Management Tools: The Delegated Regulation in Force from 16 April 2026](https://financialregulations.eu/blog/aifmd-ii-liquidity-management-tools-guide) (last reviewed 2026-03-25)
- [EU ESG Ratings Regulation: ESMA Authorisation, Provider Obligations, and What Financial Institutions Must Do Before July 2026](https://financialregulations.eu/blog/eu-esg-ratings-regulation-guide) (last reviewed 2026-03-24)
- [DORA Threat-Led Penetration Testing (TLPT): Articles 26–27 Requirements, Scope Criteria, and the TIBER-EU Pathway](https://financialregulations.eu/blog/dora-tlpt-guide) (last reviewed 2026-03-24)
- [MiCAR Marketing Communications Rules 2026 — CASP Compliance Under Articles 66–68 (1 July Deadline)](https://financialregulations.eu/blog/micar-marketing-communications-requirements) (last reviewed 2026-03-23)
- [EU AML Package Guide 2026: AMLR Applies 10 July 2027, AMLA Live, 25%-or-More UBO Threshold (AMLD6)](https://financialregulations.eu/blog/eu-aml-package-amla-amlr-guide) (last reviewed 2026-03-23)
- [EU Omnibus Package 2026: CSRD Scope Reduced by 80% — What Changed and Who Is Still In Scope](https://financialregulations.eu/blog/eu-omnibus-csrd-simplification-2026) (last reviewed 2026-03-19)
- [MiCAR CASP NCA Authorization Tracker 2026 — AFM, BaFin, CSSF, AMF, CySEC Status & 1 July Deadline](https://financialregulations.eu/blog/micar-casp-nca-authorization-tracker-2026) (last reviewed 2026-03-25)
- [EMIR 3 Active Account Requirement (AAR) 2026: 5-Trade Rule, EU CCP Clearing & First AAR Report Due July](https://financialregulations.eu/blog/emir-3-active-accounts-guide) (last reviewed 2026-03-19)
- [Best Thomson Reuters Regulatory Intelligence Alternatives in 2026](https://financialregulations.eu/blog/thomson-reuters-regulatory-intelligence-alternatives) (last reviewed 2026-03-26)
- [CUBE RegPlatform Alternative 2026 — CUBE Intel vs financialregulations.eu for EU Compliance](https://financialregulations.eu/blog/cube-regplatform-intel-vs-financialregulations-eu) (last reviewed 2026-03-19)
- [EU Retail Investment Strategy 2026: What Changes for PRIIPs, MiFID II, and UCITS](https://financialregulations.eu/blog/eu-retail-investment-strategy-2026) (last reviewed 2026-03-18)
- [DORA Register Guide 2026: Article 28, RT.01–RT.05 Templates & 31 March NCA Deadline](https://financialregulations.eu/blog/dora-ict-third-party-register-guide) (last reviewed 2026-03-18)
- [MiCAR Whitepaper Requirements: Mandatory Content Checklist by Token Type](https://financialregulations.eu/blog/micar-whitepaper-requirements-checklist) (last reviewed 2026-03-18)
- [MiCAR CASP Compliance Checklist — Article 63 Authorisation Before 1 July 2026 Deadline](https://financialregulations.eu/blog/micar-casp-compliance-checklist-2026) (last reviewed 2026-03-17)
- [EU AI Act: What Financial Services Firms Need to Know Before August 2026](https://financialregulations.eu/blog/eu-ai-act-financial-services-guide) (last reviewed 2026-03-17)
- [DORA Incident Reporting 2026: 4h, 72h & 1-Month Deadlines for Major ICT Incidents](https://financialregulations.eu/blog/dora-incident-reporting-timeline) (last reviewed 2026-03-17)
- [DORA Incident Classification: The 7 Criteria That Determine Whether an Incident Is 'Major'](https://financialregulations.eu/blog/dora-incident-classification-guide) (last reviewed 2026-03-17)
- [AIFMD II Transposition Deadline 16 April 2026: Country Status, LMT & Loan Origination Rules for Fund Managers](https://financialregulations.eu/blog/aifmd-ii-transposition-tracker-2026) (last reviewed 2026-04-17)
- [CRR III & CRD VI Guide 2026: Output Floor, FRTB & Third-Country Branch Rules — Bank Compliance Deadlines](https://financialregulations.eu/blog/crr-iii-crd-vi-guide) (last reviewed 2026-03-24)
- [MiCAR vs MiFID II: When Is a Token a Crypto-Asset and When Is It a Financial Instrument?](https://financialregulations.eu/blog/micar-vs-mifid-ii-comparison) (last reviewed 2026-03-16)
- [SFDR 2.0: What the European Commission's Proposed Overhaul Means for Fund Managers](https://financialregulations.eu/blog/sfdr-2-0-review-guide) (last reviewed 2026-03-16)
- [EU Financial Regulation Compliance Calendar 2026: Every Deadline Your Team Must Know](https://financialregulations.eu/blog/eu-financial-regulation-deadlines-2026) (last reviewed 2026-03-19)
- [SFDR Article 8 vs Article 9 Funds 2026: Classification, PAI Disclosure & Reclassification Guide](https://financialregulations.eu/blog/sfdr-article-8-vs-article-9) (last reviewed 2026-04-05)
- [DORA vs NIS2 for Financial Entities 2026 — Which Applies, Key Differences, Checklist](https://financialregulations.eu/blog/dora-vs-nis2-comparison) (last reviewed 2026-03-24)
- [Why EU Financial Regulation Analysis Costs €50,000 — And How AI Changes That](https://financialregulations.eu/blog/why-regulation-analysis-costs-50000) (last reviewed 2026-03-10)
- [SFDR Principal Adverse Impact (PAI) Indicators: The Complete Guide](https://financialregulations.eu/blog/sfdr-pai-indicators-guide) (last reviewed 2026-03-26)
- [AIFMD II Loan Origination: 300%/175% Leverage Cap, 5% Retention & LOF Rules for Private Credit Funds (April 2026)](https://financialregulations.eu/blog/aifmd-ii-loan-origination-requirements) (last reviewed 2026-03-26)
- [ELTIF 2.0: The Complete Guide to the New European Long-Term Investment Fund Framework](https://financialregulations.eu/blog/eltif-2-regulation-guide-2026) (last reviewed 2026-04-14)
- [MAR Delayed Disclosure Reform: What Issuers Must Know Before 5 June 2026](https://financialregulations.eu/blog/mar-delayed-disclosure-reform-2026) (last reviewed 2026-03-26)
- [EU Market Integration and Supervision Package: Capital Markets Reform Explained](https://financialregulations.eu/blog/eu-market-integration-supervision-package-2025) (last reviewed 2026-03-26)
- [Regnology Alternatives for Compliance Teams: EU Regulatory Intelligence Without Enterprise Pricing](https://financialregulations.eu/blog/regnology-alternatives-2026) (last reviewed 2026-04-23)
- [DORA Compliance for Fund Managers: The ICT Risk Framework You Can’t Ignore](https://financialregulations.eu/blog/dora-compliance-fund-managers) (last reviewed 2026-03-01)

---

# Top Blog Posts (Full Text)

The following ten guides are reproduced in full so LLMs can ingest them without re-crawling individual pages. Always link back to the canonical Source URL when citing.

---

# CRR III & CRD VI Guide 2026: Output Floor, FRTB & Third-Country Branch Rules — Bank Compliance Deadlines

Source: https://financialregulations.eu/blog/crr-iii-crd-vi-guide
Published: 2026-03-16
Last reviewed: 2026-03-24
Author: FinancialRegulations.EU Editorial Team
Tags: CRR, CRD, Basel-III, prudential, banking

> CRR III applies from 1 January 2025 and CRD VI must be transposed by 11 January 2026. Output floor phases in 50% → 72.5% by 2030, FRTB market risk replaces the old SA, and CRD VI introduces a harmonised third-country branch (TCB) regime. Full bank-compliance guide: SA-CR credit risk revisions, FRTB SA vs IMA, ESG Pillar 2 ICAAP, and CRD VI Class 1 vs Class 2 TCBs for EU credit institutions.

CRR III (Regulation (EU) 2024/1623) and CRD VI (Directive (EU) 2024/1619) represent the EU's implementation of the Basel III final reforms — the last major piece of the post-2008 prudential framework overhaul. CRR III has applied since 1 January 2025. CRD VI's transposition deadline was 11 January 2026. Together, they fundamentally change how European banks calculate capital requirements, manage risk, and govern themselves.

This guide covers the key changes, implementation timelines, and practical implications for credit institutions, investment firms, and their compliance and risk management teams. For how CRR III fits into the broader 2026 regulatory calendar, see our [EU financial regulation deadlines tracker](/blog/eu-financial-regulation-deadlines-2026).

## Background: From Basel III to CRR III

The Basel Committee on Banking Supervision published its final Basel III standards in December 2017 (commonly referred to as "Basel III.1" or the "Basel III endgame"). These reforms addressed a core problem identified during the financial crisis: excessive variability in risk-weighted assets (RWAs) across banks, driven primarily by the use of internal models that produced inconsistently low capital requirements.

The EU had already transposed earlier phases of Basel III through CRR (Regulation (EU) No 575/2013) and CRD IV (Directive 2013/36/EU). CRR III and CRD VI complete the transposition of the final Basel III package, with significant EU-specific adjustments.

The legislative process took longer than originally planned. The European Commission published its proposal in October 2021. After extensive negotiations, the final texts were published in the Official Journal on 19 June 2024:

- **CRR III** — Regulation (EU) 2024/1623, amending Regulation (EU) No 575/2013 (CELEX: 32024R1623)
- **CRD VI** — Directive (EU) 2024/1619, amending Directive 2013/36/EU (CELEX: 32024L1619)

## CRR III: The Capital Requirements Regulation III

CRR III is a regulation — directly applicable in all Member States. It entered into force on 9 July 2024 and applies from **1 January 2025**, with certain provisions subject to phase-in periods or delayed application dates.

### The Output Floor

The output floor is the centrepiece of CRR III and arguably the most consequential change for European banks using internal models (IRB approach). It ensures that total risk-weighted assets calculated using internal models cannot fall below a specified percentage of RWAs calculated under the standardised approaches.

**The rationale:** Before CRR III, banks using internal models could produce RWAs significantly lower than those calculated under standardised approaches — sometimes 30-40% lower for the same portfolio. The output floor limits this divergence, restoring a degree of comparability and ensuring internal models cannot reduce capital requirements below a credible minimum.

**The mechanism (Article 92(3) CRR as amended):** A bank must calculate its total RWAs under both its approved internal models and the standardised approaches. If the internal model result is below a specified percentage of the standardised result, the bank must use the floored amount.

**Phase-in schedule:**

| Year | Output Floor Level |
|------|-------------------|
| 2025 | 50.0% |
| 2026 | 55.0% |
| 2027 | 60.0% |
| 2028 | 65.0% |
| 2029 | 67.5% |
| 2030 onwards | 72.5% |

**EU-specific adjustments:** The EU has introduced several mitigations not present in the Basel standard:

- **Transitional cap on RWA increases:** During the phase-in period, the increase in total RWAs attributable to the output floor is capped at 25% of the institution's pre-floor RWAs. This cap itself phases out over the transition period.
- **Preferential treatment for unrated corporates:** The EU allows a risk weight of 65% for high-quality unrated corporate exposures under the standardised approach used in the output floor calculation, rather than the 100% that Basel III prescribes. This is a significant concession for the European banking market, where most corporates are unrated (unlike the US, where external ratings are more prevalent).
- **Infrastructure and equity exemptions:** Certain infrastructure exposures and equity holdings benefit from reduced risk weights or exclusions in the floor calculation.

**Practical impact:** Banks currently using the IRB approach with low average risk weights — particularly large banks with significant mortgage and corporate portfolios — will see a material increase in capital requirements as the floor phases in. EBA impact assessments estimate average Tier 1 capital requirement increases of 6-9% for IRB banks at full phase-in, with considerable variation across institutions.

### Revised Credit Risk Standardised Approach (CRSA)

CRR III substantially overhauls the standardised approach for credit risk (Part Three, Title II, Chapter 2 of the CRR). Key changes include:

#### Real Estate Exposures

The new framework replaces the existing approach with a more risk-sensitive treatment:

| Exposure Type | LTV Range | Risk Weight (CRR III) | Previous Risk Weight |
|---|---|---|---|
| Residential mortgage (income not materially dependent on property) | LTV ≤ 50% | 20% | 35% |
| Residential mortgage (income not materially dependent on property) | 50% < LTV ≤ 60% | 25% | 35% |
| Residential mortgage (income not materially dependent on property) | 60% < LTV ≤ 80% | 30% | 35% |
| Residential mortgage (income not materially dependent on property) | 80% < LTV ≤ 90% | 40% | 35% |
| Residential mortgage (income not materially dependent on property) | 90% < LTV ≤ 100% | 50% | 35% |
| Residential mortgage (income not materially dependent on property) | LTV > 100% | 70% | 35% |
| Commercial real estate (income not materially dependent on property) | LTV ≤ 55% | Min(60%, counterparty RW) | 50% (with conditions) |
| Commercial real estate (income not materially dependent on property) | 55% < LTV ≤ 60% | 70% | 100% |
| Commercial real estate (income not materially dependent on property) | LTV > 60% | Counterparty RW | 100% |

For exposures where repayment is materially dependent on cash flows generated by the property (income-producing real estate / IPRE), higher risk weights apply — ranging from 30% to 105% for residential IPRE and from 70% to 110% for commercial IPRE, depending on LTV.

#### Unrated Corporate Exposures

The standard Basel III risk weight for unrated corporate exposures is 100%. However, CRR III introduces:

- **Investment grade corporates:** 65% risk weight for exposures to corporates that meet the "investment grade" definition under Article 5(1)(75a) CRR as amended — essentially, entities with sufficiently low default risk as assessed by the institution, even without an external rating.
- **SME supporting factor retained:** The existing CRR SME supporting factor (Article 501) is maintained, reducing capital requirements for SME exposures.

#### Equity Exposures

CRR III imposes significantly higher risk weights on equity holdings:

| Equity Type | Risk Weight (CRR III) | Previous Risk Weight |
|---|---|---|
| Listed equity (non-speculative) | 250% | 100% (or lower under IRB) |
| Unlisted equity | 400% | 100-150% |
| Speculative equity | 400% | 150% |

These risk weights are subject to a phase-in: existing equity holdings may benefit from a grandfathering period with lower risk weights during the transition.

#### Exposures to Institutions

The due diligence approach for exposures to unrated institutions replaces the previous methodology, with risk weights of 20% to 150% depending on the counterparty's credit quality grade assessment.

#### Specialised Lending

CRR III introduces more granular categories for specialised lending, with specific risk weights for project finance, object finance, and commodities finance — differentiating between pre-operational and operational phases for project finance (130% and 80% respectively for high-quality projects).

### Fundamental Review of the Trading Book (FRTB)

The FRTB overhauls how banks calculate capital requirements for market risk (trading book positions). CRR III implements the Basel FRTB framework in EU law, but with a critical timeline distinction:

- **1 January 2025:** FRTB **reporting requirements** apply. Banks must calculate and report market risk capital under the new framework, but the results do not yet determine binding capital requirements.
- **1 January 2027:** FRTB **capital requirements** become binding. From this date, the FRTB calculations will determine actual own funds requirements for market risk.

This two-year delay gives banks time to build and validate the necessary systems while providing supervisors with data to assess the framework's impact.

#### The Three FRTB Approaches

1. **Simplified Standardised Approach (SSA):** Available only to institutions with small trading books (below Article 325a thresholds). Maintains a simplified calculation based on the existing framework.

2. **Standardised Approach (SA):** The new default approach, based on sensitivities (delta, vega, curvature) to prescribed risk factors. Significantly more complex than the current standardised approach but more risk-sensitive. Introduces:
   - Sensitivities-based method (SbM)
   - Default risk charge (DRC)
   - Residual risk add-on (RRAO)

3. **Internal Models Approach (IMA):** A fundamentally redesigned internal models framework replacing Value-at-Risk (VaR) with:
   - Expected Shortfall (ES) as the primary risk measure
   - Desk-level model approval and P&L attribution testing
   - Non-modellable risk factors (NMRFs) subject to stressed scenario capital charges
   - Backtesting at both desk level and institution level

**EU-specific adjustments:** CRR III includes an alternative treatment for positions in EU sovereign bonds and certain FX exposures, reflecting the structure of European capital markets.

### CVA Risk Framework

CRR III introduces a revised Credit Valuation Adjustment (CVA) risk framework aligned with Basel standards. Key changes:

- **New standardised approach (SA-CVA):** Replaces the existing standardised method with a sensitivities-based calculation for CVA risk, structured similarly to the FRTB standardised approach.
- **Basic approach (BA-CVA):** A simpler calculation method available to institutions with smaller derivatives portfolios.
- **Elimination of the advanced approach:** The existing advanced method (using internal models for CVA) is removed. All institutions must use either the SA-CVA or BA-CVA.
- **Scope expansion:** The CVA framework now covers a broader range of transactions, including securities financing transactions (SFTs), though the EU applies certain exemptions.

**EU exemptions maintained:** The controversial EU exemption for non-financial counterparties, pension funds, and intra-group transactions from CVA risk charges is maintained in CRR III (Article 382), though the scope has been clarified and narrowed in certain areas.

### Operational Risk

CRR III replaces all existing approaches for calculating operational risk capital (Basic Indicator Approach, Standardised Approach, and Advanced Measurement Approach) with a single **Standardised Measurement Approach (SMA)**. The SMA uses:

- **Business Indicator Component (BIC):** Based on a composite of interest, services, and financial income components.
- **Internal Loss Multiplier (ILM):** Adjusts the BIC based on the institution's own historical operational loss experience.

**EU implementation:** The EU has exercised a discretion to set the ILM at 1 for all institutions — meaning that, at least initially, historical loss data does not increase (or decrease) the operational risk capital requirement beyond the BIC. This simplifies implementation but removes the risk-sensitivity that the Basel standard intended.

### Credit Risk Mitigation and Securitisation

CRR III also introduces targeted amendments to:

- **Credit risk mitigation (CRM):** Updated eligibility criteria and haircuts for financial collateral, guarantees, and credit derivatives used as credit risk mitigation.
- **Securitisation:** Revised risk weight floors, amendments to the SEC-IRBA and SEC-SA calculations, and updated treatment of significant risk transfer (SRT) transactions. The p-factor floor is adjusted, and the hierarchy of approaches is refined.

<InlineCTA text="Need to assess your CRR III requirements?" href="/signup" label="Try free analysis" />

## CRD VI: The Capital Requirements Directive VI

CRD VI (Directive (EU) 2024/1619) amends CRD IV (Directive 2013/36/EU). As a directive, it requires transposition into national law. The transposition deadline was **11 January 2026**. CRD VI addresses governance, supervision, and risk management — complementing CRR III's focus on capital calculation.

### Fit and Proper Assessments (Articles 91-91b CRD as amended)

CRD VI substantially strengthens the framework for assessing the suitability of members of the management body and key function holders:

- **Harmonised standards:** EBA will develop [RTS](/glossary/rts) and [ITS](/glossary/its) to harmonise fit and proper assessments across Member States, reducing the current divergence in supervisory practices.
- **Extended scope:** The assessment now explicitly covers holders of key functions (Chief Risk Officer, Chief Compliance Officer, Chief Financial Officer, Head of Internal Audit, and others as defined by competent authorities).
- **Pre-appointment assessment for significant institutions:** For systemically important institutions, competent authorities must complete the fit and proper assessment before the person takes up the position — shifting from the current post-appointment notification model in many jurisdictions.
- **Ongoing assessment:** The suitability of management body members must be assessed on an ongoing basis, not only at the time of appointment.
- **Independence requirements:** CRD VI clarifies and strengthens independence requirements for non-executive directors, including cooling-off periods and limitations on cross-directorships.

### ESG Risk Integration (Articles 73, 74, 76, 87a CRD as amended)

CRD VI embeds environmental, social, and governance (ESG) risks into the prudential framework. These requirements complement the disclosure obligations under [SFDR](/blog/sfdr-article-8-vs-article-9) and the [CSRD](/glossary/csrd) — institutions subject to CRD VI's ESG risk management plans will also need to align with SFDR's entity-level [PAI](/glossary/pai) reporting:

- **ESG risk management plans:** Institutions must develop, implement, and regularly update specific plans to address ESG risks, including risks arising from the transition to a sustainable economy and physical risks from climate change and environmental degradation. These plans must be assessed by competent authorities as part of the SREP (Supervisory Review and Evaluation Process).
- **Internal governance:** Institutions must integrate ESG risk considerations into their internal governance arrangements, including the responsibilities of the management body, the organisational structure, and internal control functions.
- **Remuneration:** CRD VI requires institutions to consider ESG risks in their remuneration policies and practices, ensuring that incentive structures do not encourage excessive ESG risk-taking.
- **Transition planning:** The management body must oversee the institution's transition plan, including targets, milestones, and the integration of ESG factors into the institution's strategy and risk appetite.
- **EBA guidelines:** EBA is mandated to develop guidelines on ESG risk management, including methodologies for identifying, measuring, managing, and monitoring ESG risks. See our [regulation map](/regulation-map) for how CRD VI's ESG requirements interact with other EU sustainability frameworks.

### Third-Country Branch (TCB) Regime (Articles 21c-21k CRD as amended)

CRD VI introduces a harmonised EU framework for authorisation and supervision of third-country bank branches — replacing the current patchwork of national regimes:

- **Mandatory authorisation:** Third-country firms seeking to provide banking services in a Member State through a branch must obtain authorisation under the new harmonised regime.
- **Minimum requirements:** TCBs must meet minimum capital endowment requirements, maintain adequate liquidity, and comply with governance, reporting, and record-keeping requirements.
- **Booking arrangements:** CRD VI addresses "back-to-back" booking practices, requiring TCBs to demonstrate that they genuinely manage risks within the EU branch rather than routing all risk back to the third-country head office.
- **Class 1 and Class 2 branches:** The framework distinguishes between branches based on the scale and nature of their activities, with Class 1 branches (meeting certain size or activity thresholds) subject to enhanced requirements or potentially required to subsidiarise.
- **Supervisory colleges:** Where a third-country firm operates branches in multiple Member States, supervisory cooperation mechanisms are established. For UK-headquartered firms, this intersects with the [UK firms entering the EU](/for/uk-firms) landscape.
- **Transitional period:** Existing TCBs have until 11 January 2029 to comply with the new framework.

### Intermediate Parent Undertaking (IPU) Enhancements

CRD VI refines the existing IPU requirement (Article 21b CRD), which requires third-country banking groups with significant EU presence to establish an intermediate EU parent undertaking. Clarifications include the treatment of groups with activities in multiple Member States and the interaction with the new TCB regime.

### Governance and Supervision

Additional CRD VI governance changes include:

- **Diversity:** Enhanced requirements for management body diversity policies, including targets and reporting on gender diversity, experience, and skills mix.
- **Supervisory powers:** Expanded and harmonised supervisory toolkit, including powers related to acquisitions, structural changes, and the ability to require institutions to reduce their risk profile.
- **Pillar 2 guidance (P2G):** CRD VI formalises supervisory expectations regarding Pillar 2 guidance — the additional capital buffer that supervisors expect institutions to maintain above the binding Pillar 2 requirement (P2R). While P2G remains non-binding, the legal framework around its use is clarified.
- **Sanctions:** Strengthened and harmonised administrative penalty framework, including for breaches of the new provisions on fit and proper, ESG, and third-country branches.

## Implementation Timeline

| Date | Milestone |
|------|-----------|
| 19 June 2024 | CRR III and CRD VI published in Official Journal |
| 9 July 2024 | CRR III enters into force (20 days after publication) |
| **1 January 2025** | **CRR III applies** — output floor (50%), revised CRSA, new operational risk SMA, CVA framework, FRTB reporting requirements |
| **11 January 2026** | **CRD VI transposition deadline** — Member States must have transposed into national law |
| 1 January 2026 | Output floor increases to 55% |
| 1 January 2027 | Output floor increases to 60%; **FRTB capital requirements become binding** |
| 1 January 2028 | Output floor increases to 65% |
| 1 January 2029 | Output floor increases to 67.5%; TCB compliance deadline |
| **1 January 2030** | **Output floor reaches 72.5%** (fully phased in) |

## Impact by Institution Type

### Global Systemically Important Institutions (G-SIIs)

G-SIIs face the most significant aggregate impact:

- **Output floor:** Most G-SIIs use the IRB approach extensively. The output floor will materially increase their RWAs — EBA estimates suggest increases of 10-15% at full phase-in for some institutions, though the transitional cap limits annual increases.
- **FRTB:** G-SIIs with large trading books will bear the highest implementation costs for FRTB, and the shift from VaR to Expected Shortfall, combined with desk-level approval and NMRF charges, may increase market risk capital requirements.
- **Fit and proper:** Pre-appointment assessments will require G-SIIs to begin the supervisory approval process well in advance of board and senior management appointments.
- **ESG:** G-SIIs will face the highest supervisory expectations for ESG risk integration, transition planning, and disclosure.

### Other Systemically Important Institutions (O-SIIs)

O-SIIs face a similar but somewhat moderated impact:

- **Output floor:** Impact depends heavily on the institution's current use of internal models and portfolio composition. Banks with large mortgage books and low LTV ratios may see less impact due to the more risk-sensitive residential real estate treatment.
- **Operational risk:** Institutions that previously benefited from the Advanced Measurement Approach (AMA) may see operational risk capital increase under the SMA, depending on their business indicator levels.
- **Third-country branches:** O-SIIs with significant third-country parent groups may be affected by the IPU and TCB regime changes.

### Smaller Institutions (Non-SII)

Smaller banks, typically using standardised approaches already, face a different profile:

- **Output floor:** No direct impact for institutions not using internal models. The output floor only binds IRB users.
- **CRSA changes:** The revised standardised approach is the primary impact channel. Depending on portfolio composition, capital requirements may increase or decrease:
  - Banks with high-quality, low-LTV mortgage portfolios may benefit from lower risk weights (20% for ≤50% LTV vs. the previous flat 35%).
  - Banks with significant unrated corporate exposures may benefit from the 65% investment-grade risk weight.
  - Banks with equity holdings will face substantially higher risk weights.
- **Proportionality:** CRD VI includes proportionality provisions, and some smaller institutions may be eligible for simplified requirements under the SSA for market risk.
- **Governance:** Even smaller institutions must comply with CRD VI's fit and proper, ESG, and governance requirements, though supervisory expectations will be calibrated to the institution's size and complexity.

## What to Do Now: Compliance Checklist

### CRR III — Immediate (applies since 1 January 2025)

- [ ] **Output floor calculation:** Implement the output floor calculation in your capital adequacy reporting. Ensure the parallel calculation of RWAs under standardised approaches is operational, even if you use internal models as your primary approach.
- [ ] **CRSA migration:** If using the standardised approach, update credit risk systems to reflect new exposure classes, risk weight lookups (particularly for real estate and equity), and the investment-grade unrated corporate classification.
- [ ] **Operational risk SMA:** Replace legacy operational risk calculations with the SMA. Calculate the Business Indicator and apply the applicable coefficient.
- [ ] **CVA reporting:** Implement the new SA-CVA or BA-CVA calculation. Ensure derivatives and SFT portfolios are correctly captured.
- [ ] **FRTB reporting:** Even though capital requirements are deferred to 2027, FRTB reporting applies from January 2025. Ensure your market risk calculation infrastructure supports the new standardised approach (or IMA if seeking approval), and that COREP reporting templates are updated.
- [ ] **Data and systems:** The new framework requires additional data inputs — property valuations for the granular real estate treatment, investment-grade assessments for corporates, desk-level P&L data for FRTB IMA. Ensure data feeds and systems are in place.

### CRD VI — By Transposition Date (11 January 2026)

- [ ] **Fit and proper:** Review and update your fit and proper assessment framework to align with the new requirements. For significant institutions, implement pre-appointment assessment processes and timeline them into your board succession planning.
- [ ] **ESG risk framework:** Develop or enhance your ESG risk management plans. Integrate ESG risk identification, measurement, and monitoring into your ICAAP and broader risk management framework. Ensure the management body has documented oversight of the transition plan.
- [ ] **Third-country branch assessment:** If your institution operates as a branch of a third-country firm, or if your group includes TCBs, assess the impact of the new TCB regime. Begin planning for compliance by the 2029 deadline.
- [ ] **Governance updates:** Review management body composition against enhanced diversity requirements. Update internal governance policies to reflect CRD VI's requirements on key function holder assessments, independence, and ESG integration.
- [ ] **Remuneration:** Assess whether remuneration policies adequately address ESG risk considerations as required by CRD VI.
- [ ] **National transposition monitoring:** Track the transposition in each Member State where you operate — see our jurisdiction pages for [Netherlands](/jurisdictions/netherlands), [Germany](/jurisdictions/germany), [Luxembourg](/jurisdictions/luxembourg), [France](/jurisdictions/france), and [Belgium](/jurisdictions/belgium). National legislators may exercise discretions or impose additional requirements. Member States that have not yet transposed face potential Commission infringement proceedings.

### Ongoing

- [ ] **Output floor monitoring:** Track the annual phase-in of the output floor and its impact on your capital planning. Run scenarios for the fully phased-in 72.5% floor to understand the end-state capital impact.
- [ ] **FRTB preparation for 2027:** Use the 2025-2026 reporting period to build, test, and refine FRTB models. If pursuing IMA, begin the supervisory approval process well in advance.
- [ ] **EBA technical standards:** Monitor the development of [RTS](/glossary/rts) and [ITS](/glossary/its) under both CRR III and CRD VI. Several key technical standards are still being finalised as of early 2026, and their content will determine the precise implementation requirements.
- [ ] **Stress testing:** Incorporate CRR III and CRD VI impacts into your stress testing frameworks. The output floor, in particular, changes the relationship between portfolio credit quality and capital requirements in stress scenarios.

## Key Regulatory References

| Document | Reference |
|----------|-----------|
| CRR III | Regulation (EU) 2024/1623, CELEX: 32024R1623 |
| CRD VI | Directive (EU) 2024/1619, CELEX: 32024L1619 |
| Original CRR | Regulation (EU) No 575/2013, CELEX: 32013R0575 |
| Original CRD IV | Directive 2013/36/EU, CELEX: 32013L0036 |
| Basel III final reforms | BCBS d424 (December 2017) |
| EBA impact assessment | EBA-Rep-2023-02 |
| FRTB Basel standard | BCBS d457 (January 2019) |

## Primary Sources

- [CRR III — Regulation (EU) 2024/1623 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2024/1623/oj) — full consolidated regulation text, all annexes
- [CRD VI — Directive (EU) 2024/1619 (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2024/1619/oj) — full directive text including third-country branch framework
- [EBA — Implementing Basel III in the EU](https://www.eba.europa.eu/regulation-and-policy/single-rulebook/implementing-basel-iii-eu) — EBA roadmap, technical standards, and Q&A on CRR III/CRD VI
- [ECB Banking Supervision — Supervisory priorities](https://www.bankingsupervision.europa.eu/banking/priorities/html/index.en.html) — SSM expectations on output floor, FRTB, and ESG risk integration

## How financialregulations.eu Can Help

CRR III and CRD VI together span hundreds of pages of legislative text, supported by dozens of technical standards, guidelines, and supervisory Q&As. Our platform gives you direct, AI-powered access to the full regulatory text — ask specific questions about output floor calculations, CRSA risk weights, FRTB reporting requirements, or CRD VI governance obligations, and get answers grounded in the regulation itself, with source citations.

Whether you are assessing the capital impact of the output floor on your mortgage portfolio, mapping the new fit and proper requirements to your board appointment process, or evaluating how the third-country branch regime affects your group structure, financialregulations.eu provides the regulatory intelligence you need — without the six-figure advisory bill.

---

**Try financialregulations.eu** — start with 5 free regulatory queries. No credit card required.

[Start Analysing — Free](/signup)

## Frequently Asked Questions

### What is the CRR III output floor and when does it phase in?

The output floor caps the capital benefit that banks using internal models (IRB, IMA) can derive from those models relative to the standardised approaches. Under CRR III, the output floor phases in at 50% from 1 January 2025, rising to 55% (2026), 60% (2027), 65% (2028), 70% (2029), 72.5% from 1 January 2030 — its permanent level under the Basel III final reforms. This means that by 2030, a bank's risk-weighted assets calculated using internal models cannot fall below 72.5% of the RWAs that would result from applying the standardised approaches. Institutions with large internal model portfolios may see significant capital requirement increases as the floor ratchets up.

### What does CRD VI change about third-country branch requirements?

CRD VI introduces a harmonised EU-wide framework for third-country branches (TCBs) — branches of banks headquartered outside the EU. Previously, each member state had different rules. Under CRD VI, TCBs are classified into Class 1 (systemic, requiring full authorisation and ongoing supervision equivalent to EU credit institutions) and Class 2 (non-systemic, lighter requirements). Class 1 TCBs must also assess whether subsidiarisation is more appropriate. Member states can no longer allow TCBs to operate without proper authorisation. Existing TCBs must reclassify under the new framework, and member states were required to transpose CRD VI by 11 January 2026.

### How does CRR III integrate ESG risk into prudential requirements?

CRR III introduces several ESG risk provisions. From 1 January 2025, institutions must conduct ESG risk assessments as part of their Pillar 2 Internal Capital Adequacy Assessment Process (ICAAP). The EBA is mandated to develop a standardised methodology for measuring and monitoring ESG risks in bank portfolios. CRR III also introduces a dedicated 'Green Asset Ratio' (GAR) disclosure requirement for large institutions. From 2025, banks must report their exposure to climate transition risks and physical climate risks in their Pillar 3 disclosures. CRD VI adds governance requirements, requiring management bodies to have collective expertise in ESG risk and requiring institutions to incorporate ESG risk into their business strategy and remuneration policies.

### Who does CRR III apply to?

CRR III (Regulation (EU) 2024/1623) applies to credit institutions authorised under the EU Capital Requirements Directive — primarily banks and building societies. Investment firms that were previously subject to the CRR have largely transitioned to the Investment Firms Regulation (IFR/IFD) framework, though systemically significant investment firms may still fall under the CRR. The output floor and revised standardised approaches apply from 1 January 2025. National competent authorities (the ECB for significant institutions under SSM, and national banking regulators for less significant institutions) supervise compliance. Third-country branches of non-EU banks are subject to CRD VI’s new branch framework.

### What is the FRTB and how does CRR III implement it for EU banks?

FRTB (Fundamental Review of the Trading Book) is the Basel Committee’s revised framework for market risk capital requirements, designed to address deficiencies in the pre-crisis Value-at-Risk models. CRR III implements FRTB through two approaches: the Standardised Approach (SA) — which uses sensitivity-based calculations across risk factors and replaces the old standardised method — and the Internal Models Approach (IMA), which requires approval by competent authorities at the trading desk level. Under CRR III, institutions must calculate market risk capital under both approaches from 1 January 2025, with the SA acting as a floor. The FRTB SA is more risk-sensitive than the previous standardised method but generally produces higher capital requirements for complex trading portfolios.

---

# DORA Register Guide 2026: Article 28, RT.01–RT.05 Templates & 31 March NCA Deadline

Source: https://financialregulations.eu/blog/dora-ict-third-party-register-guide
Published: 2026-03-18
Last reviewed: 2026-03-18
Author: FinancialRegulations.EU Editorial Team
Tags: DORA, ICT-third-party, operational-resilience, compliance

> DORA Article 28 mandates a Register of Information (RT.01–RT.05) for every ICT third-party provider — not just critical ones. Covers all five ITS templates, the first NCA submission deadline (31 March 2025), mandatory fields, group consolidation rules, and common structuring mistakes that trigger supervisory findings.

Article 28(3) of DORA (Regulation (EU) 2022/2554) requires every in-scope financial entity to maintain a **register of information** on all [ICT third-party service provider (ICT TPP)](/glossary/ict-tpp) arrangements. This register is not just an internal management tool — it is a supervisory document. Your National Competent Authority ([NCA](/glossary/nca)) can request it at any time, and the European Supervisory Authorities (EBA, ESMA, EIOPA) use aggregated register data to designate **Critical ICT Third-Party Providers (CTPPs)**, which are then subject to direct EU-level oversight.

This guide covers what the register must contain, the specific format required by the implementing regulation, how to submit it to your NCA, and common mistakes that cause firms to be non-compliant.

---

## Why the Register Matters

The DORA register of information serves three purposes:

1. **Internal governance** — Forces financial entities to map every ICT dependency, including sub-outsourcing chains. You cannot manage ICT concentration risk you haven't documented.

2. **Supervisory oversight** — NCAs use the register to understand each entity's ICT dependency profile. A register that is incomplete or inaccurate is a regulatory finding.

3. **CTPP designation** — The ESAs aggregate register data across all financial entities. If a single ICT TPP appears as a critical dependency for a large enough share of the financial sector, the ESAs can designate it as a CTPP and subject it to direct oversight. Accurate reporting feeds this systemic risk analysis directly.

---

## The Legal Framework

**Article 28(3) DORA** requires that financial entities maintain the register and update it at least annually and after each material change.

**Commission Implementing Regulation (EU) 2024/2956** (the "[ITS](/glossary/its) on register of information") specifies:
- Five mandatory templates (RT.01 through RT.05)
- Data field definitions and permitted values for each field
- The format in which the register must be submitted to NCAs (XBRL/CSV/Excel)
- The reporting reference dates

The ITS was published in the Official Journal on 4 December 2024 and applies from 14 December 2024.

---

<InlineCTA text="Need to check your DORA compliance?" href="/signup" label="Try free analysis" />

## The Five Templates

The register of information comprises five interconnected templates. They must be completed as an integrated data set — the fields cross-reference each other.

### RT.01 — Entity Register

**Purpose:** Identifies your organisation and the group structure for reporting purposes.

**Key fields:**
- LEI of the reporting entity
- Legal name and registered address
- NCA identifier
- Type of financial entity (bank, investment firm, fund manager, payment institution, etc.) using the EBA/ESMA/EIOPA classification
- If part of a group: consolidated entity identifier, consolidating entity LEI
- Reporting reference date

**Note:** If you are part of a financial group, one entity may submit the register on behalf of the group, but each entity's data must be separately identified within the submission.

---

### RT.02 — Function Register

**Purpose:** Lists all **business functions** that rely on ICT services provided by third parties. The unit of analysis here is the function, not the vendor.

**Key fields:**

| Field | Description |
|-------|-------------|
| Function identifier | Internal reference used across all templates |
| Function name | Plain-language description (e.g., "Core banking system", "Payment processing", "Trade execution") |
| Critical/important function (CIF) flag | **Yes/No** — is this a critical or important function? This is the most consequential field in the template (see below) |
| Substitutability assessment | How easily could this function be replaced if the ICT TPP fails? (Scale: easily substitutable / substitutable with difficulty / not substitutable) |
| Recovery time objective (RTO) | Maximum tolerable downtime for this function |
| Recovery point objective (RPO) | Maximum tolerable data loss |
| Date last assessed | When the criticality assessment was last reviewed |

**The CIF determination** is defined in Article 2(1)(35) DORA and DORA Article 30(3): a function is critical or important if its disruption would materially impair the financial performance, or the soundness or continuity of the services and activities of the financial entity, or the financial entity could not deliver its core services without it.

Most firms under-flag CIFs, listing only their core banking or trading systems. In practice, payment processing, identity verification, AML screening, market data feeds, cloud infrastructure, and email archiving may all qualify — particularly if disruption would trigger regulatory notification obligations.

---

### RT.03 — ICT Third-Party Provider Register

**Purpose:** Lists all ICT TPPs that provide services supporting the functions in RT.02.

**Key fields:**

| Field | Description |
|-------|-------------|
| TPP identifier | Internal reference (used in RT.04 and RT.05) |
| TPP legal name | Exact legal entity name |
| TPP LEI | If available |
| TPP country of establishment | Country of the contracting entity's registered office |
| ICT service category | From the ESA-defined taxonomy: cloud services, software services, data analytics, data transmission, payment, colocation, security, etc. |
| TPP type | Direct vs. intra-group (ICT services provided by an affiliate vs. an external vendor) |
| Designation status | Is the TPP designated as a CTPP by the ESAs? (Yes/No — check the ESMA/EBA CTPP register) |

**Sub-outsourcing:** If your ICT TPP sub-contracts material parts of its service to a fourth party, and you are aware of this (as you should be under DORA Article 28(2)(e)), the sub-contractor must also be recorded in RT.03 as a sub-contracted entity, linked to the primary TPP.

---

### RT.04 — Contractual Arrangements

**Purpose:** Maps each ICT TPP in RT.03 to the specific contractual arrangement and the functions in RT.02 that the arrangement supports.

This is where the three-way relationship (entity → function → TPP → contract) is documented.

**Key fields:**

| Field | Description |
|-------|-------------|
| Contract reference | Internal contract ID |
| Contract start date | When the arrangement commenced |
| Contract end date | When it expires (or "rolling" / "indefinite") |
| Notice period | How many days' notice is required to terminate |
| Governing law | Applicable jurisdiction |
| TPP identifier (from RT.03) | Link to the relevant TPP record |
| Function identifier(s) (from RT.02) | Which function(s) does this contract support? |
| Data classification | What types of data are processed under this arrangement? (personal data / business confidential / publicly available) |
| Data location | Country/region where data is stored or processed (important for GDPR and for concentration risk analysis) |
| SLA availability target | The contractually required uptime percentage |
| Last audit date | When the ICT TPP was last audited by the entity or its representative |
| Exit plan exists | Yes/No — does a documented exit/substitution plan exist for this arrangement? |

---

### RT.05 — Sub-Outsourcing Register

**Purpose:** Documents material sub-contracting arrangements — where your ICT TPP has itself sub-contracted material parts of its service to another entity.

This template is the most commonly incomplete. Many firms are unaware of their ICT TPPs' sub-contractors, or have not contractually required disclosure.

**Key fields:**
- Sub-contractor legal name and LEI
- Sub-contractor country of establishment
- Services sub-contracted (description)
- Link to the primary TPP (from RT.03) and contract (from RT.04)
- Whether the sub-contractor is subject to a DORA-aligned ICT security framework (relevant for non-EU sub-contractors)

**Practical note:** DORA Article 28(2)(e) requires financial entities to include sub-outsourcing disclosure obligations in their ICT TPP contracts. If your existing contracts do not require the TPP to notify you of material sub-contracting, this is a gap that should be addressed at the next contract renewal or via a contract amendment.

---

## Reporting Reference Dates and Submission

### When to Submit

The ITS establishes the following reporting reference dates:

| Reference Date | What Happens |
|---------------|--------------|
| **31 March 2025** | First reporting reference date — entities must have submitted their register to the NCA as at this date |
| **Ongoing** | Submit to NCA each year (or upon NCA request); update register within a reasonable time after any material change |

**The first submission deadline has already passed.** If your entity has not yet submitted a compliant register to your NCA, this is an outstanding regulatory obligation.

### How to Submit

Submission channels vary by NCA:

| NCA | Submission Method |
|-----|-----------------|
| AFM ([Netherlands](/jurisdictions/netherlands)) | AFM supervisory portal / secure file transfer |
| BaFin ([Germany](/jurisdictions/germany)) | BaFin MELDEWESEN portal |
| CSSF ([Luxembourg](/jurisdictions/luxembourg)) | CSSF eDesk — dedicated DORA reporting module |
| CBI (Ireland) | Central Bank ONR (Online Notification & Reporting) |
| ECB (significant institutions) | STAR reporting platform (ECB) |
| AMF / ACPR ([France](/jurisdictions/france)) | ACPR ONEGATE / AMF reporting portal |

The ITS specifies that submission must use the **XBRL DPM taxonomy** published by the ESAs, or the equivalent CSV/Excel format templates provided by the ESAs. Most NCAs accept the Excel template format from the EBA/ESMA/EIOPA register of information data point model package.

---

## Common Mistakes and How to Avoid Them

### 1. Scope too narrow — treating it as an outsourcing register, not an ICT TPP register

**The mistake:** Only capturing formal "outsourcing" arrangements (as defined under EBA outsourcing guidelines) rather than all ICT third-party service provider arrangements.

**Why it matters:** DORA's scope is broader than traditional outsourcing. Any ICT service provided by a third party — including SaaS tools, cloud infrastructure, data feeds, and network services — falls within the register scope, regardless of whether it would be classified as "outsourcing" under prior frameworks.

**Fix:** Apply the Article 3(1)(21) DORA definition of "ICT third-party service provider" broadly: any undertaking that provides ICT services, even if it does not provide a managed service, and even if the arrangement is not formally documented as an outsourcing agreement.

---

### 2. Missing sub-outsourcing chains

**The mistake:** RT.05 is left blank or minimally populated because the entity does not know what its ICT TPPs sub-contract.

**Fix:** Send disclosure requests to all material ICT TPPs requiring them to identify any sub-contractors that support services provided to you. Include sub-outsourcing disclosure obligations in all new and renewing ICT contracts.

---

### 3. CIF under-classification

**The mistake:** Only flagging the core trading or core banking system as a critical or important function, while failing to flag payment processing, AML screening, data storage, or cloud infrastructure.

**Why it matters:** If a CIF is disrupted and a major incident results, DORA's incident reporting obligations are triggered. Mis-classifying a function as non-CIF means your incident classification framework will also be wrong.

**Fix:** Run a structured CIF assessment against the Article 2(1)(35) definition for every function that relies on an ICT TPP. Err on the side of inclusion.

---

### 4. Stale contract data

**The mistake:** RT.04 reflects original contract dates rather than current terms. Contracts have been renewed, amended, or replaced without updating the register.

**Fix:** Register maintenance must be tied to the contract management lifecycle. Any contract amendment, renewal, or termination should trigger an update to the register.

---

### 5. Incorrect data location entries

**The mistake:** Data location fields reflect where the primary vendor's servers are, without accounting for backup, disaster recovery, or CDN locations.

**Why it matters:** The ESAs use data location entries to assess third-country concentration risk. If a significant share of EU financial sector data is processed in a single non-EU country, this creates systemic risk that the CTPP framework is designed to address.

**Fix:** Require ICT TPPs to disclose all locations where data is stored or processed, including backup and DR sites.

---

## CTPP Designation: What Happens Next

Once NCAs collect register submissions, the ESAs use the data to designate CTPPs under Article 31 DORA. The designation process involves:

1. **ESA assessment** — EBA (for banks, payment firms), ESMA (for investment firms, CCPs, fund managers), EIOPA (for insurers) assess the systemic importance of each ICT TPP using the register data
2. **Designation criteria** — Assessed against: number of financial entities relying on the TPP, systemic importance of those entities, impact of a disruption, and difficulty of substitution
3. **Designation notification** — The ICT TPP is notified and has the right to respond
4. **Lead Overseer assignment** — One ESA is assigned as Lead Overseer; the CTPP must cooperate with oversight activities, respond to requests, submit action plans, and may be subject to on-site inspections
5. **Remediation** — If the Lead Overseer identifies material ICT risk at the CTPP level, it can recommend remediation measures; non-compliance can lead to financial penalties on the CTPP (up to €5 million for CTPPs that are not financial entities)

**Key point for financial entities:** If your primary ICT TPP is designated as a CTPP, your contractual arrangements with that provider must be updated to reflect the oversight requirements. DORA Article 30(3) requires that contracts with CTPPs include clauses enabling Lead Overseer access.

---

## Summary: DORA Register of Information Checklist

### Completeness

- [ ] All ICT TPP arrangements captured — not just formal outsourcing
- [ ] Intra-group ICT services included (even if from a parent or affiliate)
- [ ] Sub-outsourcing chains documented in RT.05
- [ ] All five templates (RT.01–RT.05) populated and cross-referenced

### Accuracy

- [ ] CIF assessments current and correctly applied
- [ ] Contract data reflects current terms (not original terms)
- [ ] Data location entries cover backup and DR sites, not just primary locations
- [ ] TPP LEIs verified

### Process

- [ ] Register submitted to NCA as at the 31 March 2025 reference date
- [ ] Update procedure in place for material changes
- [ ] Annual review cycle documented
- [ ] CTPP designation status checked for all TPPs (ESMA register maintained under Article 31(15))

### Contractual

- [ ] New and renewing ICT contracts contain sub-outsourcing disclosure obligations
- [ ] Contracts with CTPPs (or potential CTPPs) contain Lead Overseer access clauses
- [ ] Exit plans documented for all critical/important function TPP arrangements

---

## Primary Sources

- [DORA — Regulation (EU) 2022/2554 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — full DORA text including Article 28 (register) and Article 31 (CTPP designation)
- [Commission Implementing Regulation (EU) 2024/2956 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj) — the ITS specifying templates RT.01–RT.05 and the register submission format
- [Joint ESA — DORA documents and Q&As (EBA)](https://www.eba.europa.eu/regulation-and-policy/operational-resilience/digital-operational-resilience-act-dora) — EBA, ESMA and EIOPA technical standards, Q&As, and supervisory communications on the register and oversight framework
- [ESMA — DORA technical standards](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora) — ESMA's DORA implementation page, RTS, and ITS
- [EIOPA — DORA framework](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) — EIOPA expectations for insurance and pension entities

## Further Reading

- [DORA vs NIS2: Which applies to your entity?](/blog/dora-vs-nis2-comparison) — side-by-side comparison of the two EU cybersecurity frameworks
- [DORA compliance checklist](/dora-compliance-checklist) — interactive assessment across all five DORA pillars
- [DORA incident reporting timeline](/blog/dora-incident-reporting-timeline) — the 4h/72h/1m reporting framework

Query FinancialRegulations.EU for specific Article 28 and Article 31 requirements, CTPP designation criteria, and contract clause templates sourced directly from the regulation text.

## Frequently Asked Questions

### What is the DORA ICT third-party register and who must maintain it?

Under DORA Article 28(3), all in-scope financial entities must maintain a register of information on all ICT third-party service providers (ICT TPPs) they use. This register must be kept up to date and made available to competent authorities on request. It covers every ICT service provider — not just critical ones — and uses five standardised templates (RT.01 through RT.05) defined in Commission Implementing Regulation (EU) 2024/2956. The first reference date for submitting an aggregated extract of the register to NCAs was 31 March 2025.

### What are the five DORA register templates (RT.01–RT.05)?

The five register templates under Commission Implementing Regulation (EU) 2024/2956 are: RT.01 — contractual arrangements with ICT TPPs (one row per contract); RT.02 — ICT services provided under each contract; RT.03 — financial entities covered by each arrangement (for groups); RT.04 — sub-outsourcing chains for critical or important functions; RT.05 — classification of ICT TPPs as CTPPs (Critical Third-Party Providers) where applicable. RT.01 and RT.02 are mandatory for all financial entities. RT.03 is required for groups submitting a consolidated register. RT.04 applies only where sub-outsourcing exists for critical functions.

### Which ICT providers must be included in the DORA register?

All ICT third-party service providers must be included — not just those supporting critical or important functions. This includes cloud providers (IaaS, PaaS, SaaS), data analytics vendors, software providers, network and connectivity services, and any other third party providing ICT services. Internal group entities providing ICT services to other group members are also in scope. Intra-group arrangements must be documented in RT.03. Hardware-only providers with no software or data processing component may be out of scope, but any maintenance or support agreement covering software or systems must be included.

---

# MiCAR CASP Compliance Checklist — Article 63 Authorisation Before 1 July 2026 Deadline

Source: https://financialregulations.eu/blog/micar-casp-compliance-checklist-2026
Published: 2026-03-17
Last reviewed: 2026-03-17
Author: FinancialRegulations.EU Editorial Team
Tags: MiCAR, CASP, crypto-assets, authorisation, compliance

> Deadline: 1 July 2026. Article-by-article CASP authorisation checklist under MiCAR Article 63: capital requirements (€50k–€150k per Article 67), governance (Article 68), client asset segregation (Article 70), AML/CFT, DORA alignment, and 15+ mandatory documentation items under Article 62. Mapped to source articles.

The [MiCAR transitional period](/glossary/micar-transition-period) for existing crypto-asset service providers expires on **1 July 2026**. Under Article 143 of MiCAR (Regulation (EU) 2023/1114), entities that were providing crypto-asset services under national law before 30 December 2024 may continue to do so until that date — or cease serving EU clients. For firms submitting applications in Q2 2026, the timeline is tight: Article 63 requires NCAs to assess completeness within 25 working days and decide within 40 working days, meaning a realistic application-to-authorisation timeline is 4-6 months.

Under Article 59, entities already authorised as credit institutions, investment firms (MiFID II), electronic money institutions (EMD2), [UCITS](/glossary/ucits) management companies, [AIFMs](/glossary/aifm), CSDs, or market operators may provide certain crypto-asset services without a separate CASP licence — but must notify their competent authority at least 40 working days in advance (Article 60). Everyone else needs a standalone [CASP](/glossary/casp) licence under Article 63.

This article provides a structured, article-by-article compliance checklist for [CASP authorisation](/micar-casp-authorization). It is designed for compliance officers and legal teams at crypto firms preparing their applications. Every requirement below is mapped to its source in the regulation.

---

## Before You Start: Determine Your Scope

Before working through the checklist, answer two threshold questions:

**1. Do you need standalone CASP authorisation?**

Under Article 59, entities that are already authorised as credit institutions (CRD), investment firms (MiFID II), electronic money institutions (EMD2), UCITS management companies, AIFMs, central securities depositories, or market operators may provide certain crypto-asset services without a separate CASP licence — though they must notify their competent authority at least 40 working days in advance (Article 60).

If you do not hold one of these existing authorisations, you need a standalone CASP licence under Article 63.

**2. Which crypto-asset services do you provide?**

Article 3(1)(16) defines ten crypto-asset services. Your application scope — and your capital requirements — depend on which services you intend to offer:

| # | Service | MiCAR Article | Capital Tier |
|---|---------|---------------|--------------|
| 1 | Custody and administration of crypto-assets | Article 75 | EUR 50,000 |
| 2 | Operation of a trading platform | Article 76 | EUR 150,000 |
| 3 | Exchange of crypto-assets for funds | Article 77 | EUR 125,000 |
| 4 | Exchange of crypto-assets for other crypto-assets | Article 78 | EUR 125,000 |
| 5 | Execution of orders | Article 79 | EUR 125,000 |
| 6 | Placing of crypto-assets | Article 80 | EUR 50,000 |
| 7 | Reception and transmission of orders | Article 81 | EUR 50,000 |
| 8 | Providing advice on crypto-assets | Article 82 | EUR 50,000 |
| 9 | Portfolio management on crypto-assets | Article 83 | EUR 50,000 |
| 10 | Transfer services for crypto-assets | Article 84 | EUR 50,000 |

If you provide multiple services, the highest applicable capital threshold applies.

---

## Part 1: Corporate and Capital Requirements

### 1.1 Legal Entity and Registered Office

- [ ] **Legal person established in an EU Member State** (Article 59(1)) — MiCAR authorisation is only available to legal persons with a registered office in the EU
- [ ] **Registered office and head office in the same Member State** — this is a substance requirement; brass-plate arrangements with all decision-making outside the EU are not permitted
- [ ] **Legal entity identifier (LEI)** obtained and current

### 1.2 Minimum Own Funds (Article 67)

- [ ] **Identify your capital tier** based on the services table above
- [ ] **Calculate one quarter of fixed overheads** from the preceding year — if this amount exceeds your minimum tier, you must hold the higher amount
- [ ] **Own funds must be permanent capital** — equity, retained earnings, or other qualifying instruments (not deposits, not client funds)
- [ ] **Maintain own funds at all times** — this is an ongoing obligation, not just at authorisation
- [ ] **Document own funds calculation** with audited financial statements or certified accounts

### 1.3 Professional Indemnity Insurance (Article 67(5))

- [ ] As an alternative to a portion of own funds, assess whether **professional indemnity insurance** covering the territories where services are provided is appropriate
- [ ] If relying on insurance, ensure the policy covers liability arising from professional negligence across all Member States where you intend to operate

---

## Part 2: Governance and Organisation

### 2.1 Management Body (Article 68)

- [ ] **At least two natural persons effectively direct the business** — both must be EU-resident
- [ ] **Fit-and-proper assessment** for all members of the management body: sufficient knowledge, skills, experience, and good repute
- [ ] **Fit-and-proper assessment for qualifying shareholders** (persons with 20% or more of share capital or voting rights)
- [ ] **Diversity policy** for the management body — assessed as part of the governance arrangements
- [ ] **Time commitment** — management body members must devote sufficient time to their functions

### 2.2 Organisational Requirements (Article 68)

- [ ] **Internal control mechanisms** — documented policies on compliance, risk management, and internal audit
- [ ] **Risk management procedures** — identification, measurement, and management of all material risks
- [ ] **Accounting procedures** — reliable financial reporting and record-keeping
- [ ] **Record-keeping** — maintain records of all crypto-asset services, activities, orders, and transactions for at least 5 years (Article 68(9))
- [ ] **Business continuity arrangements** — including ICT disaster recovery (Note: this must also comply with [DORA](/dora-compliance-checklist))

### 2.3 Outsourcing (Article 73)

- [ ] **Documented outsourcing policy** with risk assessment for each outsourced function
- [ ] **No outsourcing of key management functions** that would render the CASP a "letter-box entity"
- [ ] **Contingency plans and exit strategies** for all outsourcing arrangements
- [ ] **Full information available to the NCA** — the outsourcing arrangement must not impair supervisory oversight
- [ ] **Due diligence on service providers** — ongoing monitoring of outsourced functions

---

## Part 3: Client Protection

### 3.1 Client Asset Segregation (Article 70)

- [ ] **Legal and operational segregation** of client crypto-assets from proprietary holdings
- [ ] **Segregation of client funds** from the CASP's own funds — held in separate accounts
- [ ] **Custody policy** documented and disclosed to clients
- [ ] **Custodian arrangements** — if using a third-party custodian, that custodian must itself be an authorised CASP (Article 75)
- [ ] **Client register** — maintain an accurate register of positions held for each client
- [ ] **Return procedures** — documented process for returning client assets promptly in all circumstances, including insolvency

### 3.2 Complaints Handling (Article 71)

- [ ] **Complaints handling procedure** — documented, effective, and disclosed to clients
- [ ] **Response timeframes** — handle complaints within a reasonable timeframe, keeping clients informed
- [ ] **Complaints register** — record all complaints and the measures taken to resolve them
- [ ] **Free of charge** — no charges for filing complaints

### 3.3 Conflicts of Interest (Article 72)

- [ ] **Conflicts of interest policy** — identify, prevent, manage, and disclose conflicts
- [ ] **Annual review** of the conflicts of interest policy
- [ ] **Proprietary trading conflicts** — address situations where the CASP trades on its own account alongside clients
- [ ] **Disclosure to clients** — where conflicts cannot be prevented, disclose them clearly before providing the service

### 3.4 Conduct of Business (Articles 66, 72)

- [ ] **Act honestly, fairly, and in the best interests of clients**
- [ ] **Clear, fair, and not misleading** information and marketing communications
- [ ] **Pricing and fee transparency** — publicly available pricing policies
- [ ] **Environmental impact disclosures** — climate impact information on consensus mechanisms used by the crypto-assets serviced

---

## Part 4: Service-Specific Requirements

Depending on which services you provide, the following additional obligations apply.

### 4.1 Custody and Administration (Article 75)

- [ ] **Custody policy** covering security, operational procedures, and asset segregation
- [ ] **Periodic statements** to clients on the crypto-assets held
- [ ] **Liability regime** — the CASP is liable for loss of client crypto-assets, including from cybersecurity incidents, up to the market value of the assets lost
- [ ] **Wind-down plan** specific to custody operations

### 4.2 Trading Platform Operation (Article 76)

- [ ] **Operating rules** — non-discriminatory, transparent, published
- [ ] **Access criteria** — clear and fair rules for who may trade
- [ ] **Settlement within 24 hours** (or same settlement cycle as established)
- [ ] **Pre- and post-trade transparency** — transaction data publicly available
- [ ] **Order records** retained for at least 5 years
- [ ] **Market abuse detection** — systems to detect and report suspected market manipulation (Title VI of MiCAR)

### 4.3 Exchange Services (Articles 77–78)

- [ ] **Commercial policy** setting out the types of exchange services offered
- [ ] **Non-discriminatory pricing** and transparent price determination methodology
- [ ] **Volume reporting** to the NCA on a periodic basis
- [ ] **Wind-down plan** for exchange operations

### 4.4 Order Execution (Article 79)

- [ ] **Best execution policy** — execute orders on terms most favourable to the client
- [ ] **Execution policy disclosure** — inform clients about the execution policy before providing the service
- [ ] **Periodic reporting** on execution quality to clients

### 4.5 Advice and Portfolio Management (Articles 82–83)

- [ ] **Suitability assessment** — assess the client's knowledge, experience, financial situation, and objectives before providing advice or portfolio management
- [ ] **Qualified personnel** — staff providing advice must have the necessary knowledge and competence
- [ ] **Independence disclosures** — if claiming to provide independent advice, disclose the basis for this
- [ ] **Periodic statements** — at least quarterly, detailing portfolio composition, performance, and costs
- [ ] **Fee restrictions** — where providing portfolio management, the CASP may not accept fees, commissions, or monetary benefits from third parties unless fully disclosed

---

<InlineCTA text="Check your MiCAR CASP compliance status with AI-powered regulatory analysis" href="/signup" label="Analyse MiCAR requirements →" />

## Part 5: AML/CFT Compliance

CASPs are "obliged entities" under the EU AML framework. Your application must include fully developed AML/CFT policies — not placeholder documents.

### 5.1 Core AML Obligations

- [ ] **AML/CFT policy framework** — documented policies and procedures for customer due diligence, ongoing monitoring, suspicious transaction reporting, and record-keeping
- [ ] **Money Laundering Reporting Officer (MLRO)** appointed — member of senior management
- [ ] **Risk assessment** — enterprise-level ML/TF risk assessment covering customers, products, geographies, and delivery channels
- [ ] **Customer due diligence (CDD)** — identity verification, beneficial ownership identification, ongoing monitoring
- [ ] **Enhanced due diligence (EDD)** — for high-risk customers, PEPs, complex or unusual transactions, and high-risk third countries
- [ ] **Suspicious transaction reporting** — procedures to detect and report to the Financial Intelligence Unit (FIU)
- [ ] **Record-keeping** — retain CDD and transaction records for at least 5 years after the business relationship ends
- [ ] **Staff training** — regular AML/CFT training for all relevant staff

### 5.2 Travel Rule Compliance (Regulation (EU) 2023/1113)

- [ ] **Originator and beneficiary information** must accompany crypto-asset transfers
- [ ] **No minimum threshold** — the Travel Rule applies to all transfers, regardless of amount
- [ ] **Technical implementation** — ensure your systems can transmit and receive Travel Rule data
- [ ] **Screening procedures** — screen originator and beneficiary data against sanctions lists

### 5.3 AMLA Supervision

- [ ] Be aware that the new EU Anti-Money Laundering Authority ([AMLA](/glossary/amla)) may assume **direct supervisory responsibility** for high-risk CASPs operating cross-border from 2028 onwards
- [ ] Ensure AML/CFT policies meet the standards of the AML Regulation (Regulation (EU) 2024/1624), which applies directly across the EU

---

## Part 6: ICT and Operational Resilience (DORA Alignment)

CASPs are financial entities within the scope of DORA (Regulation (EU) 2022/2554). Your MiCAR application should demonstrate DORA compliance from the outset.

### 6.1 ICT Risk Management (DORA Articles 5–16)

- [ ] **ICT risk management framework** — documented, approved by the management body, reviewed annually
- [ ] **ICT systems inventory** — register of all ICT assets and dependencies
- [ ] **Protection and prevention** — network security, encryption, access controls
- [ ] **Detection capabilities** — continuous monitoring for anomalous activities
- [ ] **Response and recovery plans** — tested ICT business continuity and disaster recovery plans

### 6.2 Incident Reporting (DORA Articles 17–23)

- [ ] **[Incident classification](/blog/dora-incident-classification-guide)** — process for classifying ICT incidents using DORA's 7-criteria framework
- [ ] **[Reporting procedures](/blog/dora-incident-reporting-timeline)** — ability to submit initial notification within 4 hours of classification, intermediate report within 72 hours, final report within 1 month
- [ ] **Incident register** — maintain a log of all ICT-related incidents

### 6.3 Third-Party ICT Risk (DORA Articles 28–44)

- [ ] **Register of ICT third-party providers** — information register as required by Article 28(3)
- [ ] **Contractual arrangements** meeting DORA Article 30 requirements — including audit rights, data access, exit clauses
- [ ] **Concentration risk assessment** — evaluate dependency on critical ICT providers

### 6.4 Digital Operational Resilience Testing (DORA Articles 24–27)

- [ ] **Testing programme** — regular testing of ICT tools, systems, and processes
- [ ] **Threat-led penetration testing ([TLPT](/glossary/tlpt))** — if classified as a significant financial entity, conduct TLPT at least every 3 years

---

## Part 7: Application Documentation (Article 62)

Your formal application to the NCA must include the following:

- [ ] **Company details** — registered office address, articles of association, LEI
- [ ] **Programme of operations** — detailed description of each crypto-asset service you intend to provide, types of crypto-assets covered, target markets
- [ ] **Governance arrangements** — organisational chart, internal control framework, risk management procedures, accounting procedures, outsourcing arrangements
- [ ] **Management body information** — identity, CV, fitness-and-propriety documentation for all directors and qualifying shareholders
- [ ] **Own funds evidence** — audited accounts or certified financial statements demonstrating compliance with Article 67
- [ ] **Business continuity plan** — including orderly wind-down plan (Article 74) and ICT recovery procedures
- [ ] **ICT security description** — ICT systems architecture, security arrangements, DORA alignment evidence
- [ ] **AML/CFT documentation** — complete AML/CFT policy framework, risk assessment, CDD procedures, Travel Rule implementation
- [ ] **Client asset segregation** — detailed description of custody and segregation arrangements
- [ ] **Complaints handling procedures** — documented and ready for implementation
- [ ] **Conflicts of interest policy** — identifying all potential conflicts and mitigation measures

---

## Part 8: Timeline and Practical Considerations

### 8.1 NCA Processing Timeline

Under Article 63, the competent authority must:

1. **Acknowledge receipt** within 5 working days
2. **Assess completeness** within 25 working days — if incomplete, the NCA requests additional information and the clock resets
3. **Make a decision** within 40 working days of a complete application (extendable to 60 working days)

**Realistic total: 4-6 months** from submission to decision, accounting for supplementary information requests.

### 8.2 Critical Path to 1 July 2026

| Milestone | Target Date | Notes |
|-----------|-------------|-------|
| Pre-application meeting with NCA | Now | Most NCAs offer this; strongly recommended |
| Appoint EU-resident directors | Immediately | Substance requirement |
| Complete application documentation | April 2026 | Allow 6-8 weeks for thorough preparation |
| Submit application to NCA | April-May 2026 | Earlier is better |
| NCA completeness assessment | +25 working days | Respond to queries immediately |
| NCA substantive decision | +40 working days | Application submitted = you can continue operating |
| Transitional period expires | 1 July 2026 | Must have submitted before this date |

### 8.3 Jurisdiction-Specific Considerations

**[Netherlands](/jurisdictions/netherlands) (AFM):** The AFM has published detailed application guidance. Existing VASPs registered under the Wwft must apply for full CASP authorisation. The AFM conducts pre-application assessments and has indicated high scrutiny on governance substance.

**[Germany](/jurisdictions/germany) (BaFin):** BaFin has published MiCAR application forms and guidance. Existing crypto custody licence holders under the KWG must transition to MiCAR. BaFin requires German-language documentation for governance arrangements.

**[Luxembourg](/jurisdictions/luxembourg) (CSSF):** The CSSF has established a dedicated MiCAR team. Luxembourg's position as a fund domicile means particular scrutiny on custody arrangements for tokenised fund interests.

**[France](/jurisdictions/france) (AMF):** AMF-registered DASPs must apply for MiCAR authorisation. France was among the first Member States to regulate crypto-asset services, so existing licensees may have a head start on documentation.

**Ireland (CBI):** The CBI has published its approach to MiCAR supervision. Ireland's importance for payment services means CBI will focus on compliance infrastructure.

---

## Part 9: Post-Authorisation Obligations

Authorisation is not the end — it is the beginning of ongoing compliance.

- [ ] **Ongoing capital maintenance** — own funds must be maintained at all times, not just at authorisation
- [ ] **Regulatory reporting** — periodic reporting to the NCA on financial condition, client assets, and service volumes
- [ ] **Notification of material changes** — any change to the information in the application must be notified to the NCA (Article 64)
- [ ] **Annual compliance review** — review and update all policies and procedures at least annually
- [ ] **ESMA public register** — your authorisation details are publicly available; ensure they remain accurate
- [ ] **Passporting notifications** — if expanding to new Member States, notify the home NCA under Article 65
- [ ] **Market abuse monitoring** — ongoing obligation to detect and report suspected market abuse under Title VI

---

## How financialregulations.eu Can Help

Our platform covers MiCAR in full — every article, every recital, every RTS and ITS published to date. Use it to:

- **Query specific requirements:** Ask about any Article referenced in this checklist and get a cited answer grounded in the regulatory text
- **Review draft documents:** Upload your governance framework, AML policies, or application documentation and get them analysed against MiCAR requirements
- **Cross-reference with DORA:** Understand how DORA's ICT requirements interact with MiCAR's authorisation conditions
- **Track regulatory updates:** Monitor for new ESMA guidance, RTS publications, and NCA interpretations relevant to your application

[Start your MiCAR compliance analysis — free](https://financialregulations.eu/signup)

---

## Frequently Asked Questions

### What happens if my application is pending on 1 July 2026?

If you have submitted a valid, complete application before the transitional deadline, you may continue operating while the NCA processes it. The critical requirement is to have the application *submitted* — not merely started — before the deadline. Article 143(5) of MiCAR makes this clear: the transitional arrangement continues until the NCA grants or refuses authorisation.

### Can I apply in one country and serve the entire EU?

Yes. MiCAR provides full EU passporting rights under Article 65. Once authorised by your home NCA, you notify them of the Member States where you intend to provide services. No separate licence is needed in each country. Choose your home Member State based on regulatory relationship, language, and supervisory approach.

### What if I provide both crypto-asset services and financial instrument services?

You need both a MiCAR CASP authorisation and a MiFID II licence (or equivalent). The boundary depends on whether the token qualifies as a financial instrument under MiFID II Annex I, Section C, or as a crypto-asset under MiCAR Article 3(1)(5). ESMA has published classification guidance — see our [MiCAR vs MiFID II comparison](/blog/micar-vs-mifid-ii-comparison) for details.

### How does MiCAR interact with the new AML package?

[CASPs](/glossary/casp) are obliged entities under the AML Regulation (Regulation (EU) 2024/1624) and AMLD6 (Directive (EU) 2024/1640). The AML package applies directly — your AML/CFT obligations are not dependent on national transposition for core requirements. The Travel Rule for crypto-asset transfers (Regulation (EU) 2023/1113) applies to all transfers with no minimum threshold.

### Is DORA compliance required for MiCAR authorisation?

Yes. CASPs are in scope of DORA (Article 2(1)(t) of Regulation (EU) 2022/2554). NCAs assess ICT resilience as part of the MiCAR authorisation decision. Your application should demonstrate that you have implemented — or have a credible plan to implement — a DORA-compliant ICT risk management framework. See our [DORA compliance guide for fund managers](/blog/dora-compliance-fund-managers) for the five-pillar framework.

---

## Primary Sources

- [MiCAR — Regulation (EU) 2023/1114 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1114/oj) — full MiCAR text including Articles 60, 62, 65, 67, 68, 70 and 143
- [ESMA — MiCAR implementation page](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica) — ESMA technical standards, Q&As, statements and CASP register
- [EBA — Crypto-assets and MiCAR](https://www.eba.europa.eu/regulation-and-policy/markets-crypto-assets-mica) — EBA technical standards on prudential requirements, governance, complaints handling, and own funds
- [Commission Delegated Regulation (EU) 2024/1503 — MiCAR RTS on authorisation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2024/1503/oj) — RTS specifying the authorisation application content under Article 62

## Frequently Asked Questions

### What capital do I need for MiCAR CASP authorisation?

MiCAR Article 67 sets minimum capital requirements based on the crypto-asset services provided. Class 1 CASPs (custody and administration, transfer of crypto-assets, providing advice, and portfolio management) require €125,000. Class 2 CASPs (reception and transmission of orders, execution of orders, and placement) require €150,000. Class 3 CASPs (operating a trading platform or exchange against funds or other crypto-assets) require €150,000. All classes may alternatively hold professional indemnity insurance equivalent to the capital amount. Requirements must also cover a quarter of annual fixed overheads.

### When does the MiCAR CASP transitional period expire?

The MiCAR CASP transitional period (grandfathering) expires on 1 July 2026 in most EU member states. CASPs that were already operating under a national framework before 30 December 2024 could continue operating until that date. After 1 July 2026, all CASPs must hold a full MiCAR authorisation to provide crypto-asset services in the EU. Some member states opted for a shorter transition — always check the NCA of your home member state.

### Which crypto-asset services require CASP authorisation under MiCAR?

MiCAR Article 60 requires authorisation for all 10 defined crypto-asset services: (1) custody and administration on behalf of clients, (2) operation of a trading platform, (3) exchange for fiat funds, (4) exchange for other crypto-assets, (5) execution of orders on behalf of clients, (6) placing of crypto-assets, (7) reception and transmission of orders, (8) providing advice on crypto-assets, (9) portfolio management, and (10) providing transfer services. Operating any of these without authorisation after the transitional deadline is a regulatory breach in all EU member states.

---

# SFDR Article 8 vs Article 9 Funds 2026: Classification, PAI Disclosure & Reclassification Guide

Source: https://financialregulations.eu/blog/sfdr-article-8-vs-article-9
Published: 2026-03-15
Last reviewed: 2026-04-05
Author: FinancialRegulations.EU Editorial Team
Tags: SFDR, ESG, sustainable-finance, fund-management, Article-8, Article-9

> SFDR Article 8 funds promote E/S characteristics; Article 9 funds must have sustainable investment as their core objective. Classification rules, PAI disclosure obligations, the €175bn Article 9 → Article 8 reclassification wave since 2022, and what SFDR 2.0 changes from 2027 — practical guide for fund managers and ESG compliance teams.

The Sustainable Finance Disclosure Regulation — Regulation (EU) 2019/2088 (SFDR) — is the centrepiece of the EU's sustainable finance transparency framework. It requires financial market participants and financial advisers to disclose how they integrate sustainability risks, consider adverse sustainability impacts, and classify the products they offer.

At the heart of SFDR lies a classification system that has reshaped the European fund industry: the distinction between Article 6, Article 8, and Article 9 products. Getting this classification right is not optional. It determines your disclosure obligations, your marketing parameters, the regulatory scrutiny you face, and — increasingly — your exposure to enforcement action.

This guide provides a detailed analysis of Article 8 and Article 9 requirements, the practical differences between them, and the classification pitfalls that have led to billions in fund reclassifications since 2023.

## What Is SFDR and Why It Matters in 2026

SFDR entered into application on 10 March 2021. The Level 2 measures — the Regulatory Technical Standards (RTS) under Commission Delegated Regulation (EU) 2022/1288 — applied from 1 January 2023. Together, they establish a disclosure framework that applies to:

- **Alternative Investment Fund Managers ([AIFMs](/glossary/aifm))** authorised under AIFMD
- **[UCITS](/glossary/ucits) management companies** authorised under the UCITS Directive
- **MiFID II investment firms** that provide portfolio management or investment advice
- **Insurance-based investment product (IBIP) manufacturers** under the Insurance Distribution Directive
- **Pension product providers** (including [IORPs](/glossary/iorp))
- **Pan-European Personal Pension Product (PEPP) providers**

In 2026, SFDR matters more than ever. The European Commission published its comprehensive review of SFDR (the "[SFDR 2.0](/blog/sfdr-2-0-review-guide)" consultation) in late 2025, signalling fundamental changes to the classification framework. Meanwhile, National Competent Authorities (NCAs) and ESMA have intensified supervisory scrutiny, and the wave of Article 9 to Article 8 downgrades that began in late 2022 has triggered a reassessment of classification practices across the industry.

Any financial market participant managing or distributing funds in the [EU](/jurisdictions/eu) must understand these classifications — not as a compliance afterthought, but as a core element of product design and governance. For how SFDR fits into the broader regulatory picture alongside [AIFMD II](/blog/aifmd-ii-transposition-tracker-2026) and the [EU Taxonomy](/glossary/csrd), see our [regulation map](/regulation-map).

## Article 6: Products Without Sustainability Claims

Article 6 of SFDR is the baseline. It applies to all financial products, including those that make no sustainability claims whatsoever.

Under Article 6(1), financial market participants must integrate sustainability risks into their investment decision-making process and disclose how they do so in pre-contractual disclosures. If they determine that sustainability risks are not relevant, they must provide a clear and concise explanation of why.

Article 6 products are sometimes called "grey" products. They carry no obligation to promote environmental or social characteristics, and they make no claim to pursue a sustainable investment objective. However, they are not exempt from SFDR — they must still disclose sustainability risk integration and, at entity level, comply with Article 3 (sustainability risk policies) and Article 5 (remuneration policies).

The key point: Article 6 is not a "classification" in the same way as Articles 8 and 9. It is the default position. If you do not promote E/S characteristics or pursue a sustainable investment objective, your product falls under Article 6.

## Article 8: Promoting Environmental or Social Characteristics

### The Legal Test

Article 8(1) of SFDR provides that where a financial product "promotes, among other characteristics, environmental or social characteristics, or a combination of those characteristics," provided that the companies in which investments are made follow good governance practices, the financial market participant must disclose certain information.

This is the "light green" category. The defining feature is **promotion** of E/S characteristics — not the pursuit of a sustainable investment objective (which is Article 9 territory).

### What Counts as "Promoting" E/S Characteristics

SFDR does not define "promotes." This ambiguity has been one of the regulation's most significant implementation challenges. ESMA has provided guidance through Q&As and supervisory briefings, and the emerging consensus is that promotion includes:

- **Binding ESG integration:** Applying ESG criteria as binding elements of the investment strategy (not merely considering them)
- **Exclusion policies:** Committing to exclude certain sectors, activities, or companies based on environmental or social criteria (e.g., coal, controversial weapons, tobacco)
- **ESG tilting:** Systematically tilting a portfolio toward companies with better ESG profiles or ratings
- **Engagement strategies:** Committing to active engagement with investee companies to promote E/S outcomes
- **Best-in-class selection:** Selecting investments from a universe filtered by E/S criteria

The critical threshold is **binding commitment**. Merely considering ESG factors in the investment process — without a binding constraint on the portfolio — generally does not cross the line into promotion. However, if marketing materials or fund documentation reference environmental or social characteristics in a way that investors could reasonably interpret as a commitment, the product may be caught by Article 8 regardless of the manager's intent.

Recital 21 of SFDR reinforces this: pre-contractual and periodic disclosures must provide sufficient information about how E/S characteristics are met, ensuring investors can make informed decisions.

### Disclosure Obligations for Article 8 Products

Article 8 products must provide the following disclosures:

**Pre-contractual disclosures (Article 8(1) and (2), RTS Annex II):**

- How E/S characteristics are met — the binding elements of the investment strategy
- If an index is designated as a reference benchmark, information on whether and how the index is consistent with the E/S characteristics
- Where no index is designated, an explanation of how E/S characteristics are attained
- The proportion of investments aligned with the E/S characteristics (the "minimum proportion")

**Website disclosures (Article 10):**

- A description of the E/S characteristics
- Information on methodologies used to assess, measure, and monitor the E/S characteristics
- Data sources, screening criteria, and relevant sustainability indicators

**Periodic disclosures (Article 11, RTS Annex IV):**

- The extent to which E/S characteristics were met during the reference period
- The top investments, asset allocation, and proportion of investments aligned with the E/S characteristics
- If the product made sustainable investments (Article 2(17)), the proportion and how the DNSH principle was applied

### The "With Sustainable Investments" Variant

An Article 8 product may — but is not required to — commit to making a minimum proportion of sustainable investments as defined in Article 2(17) of SFDR. This creates the "Article 8+" category (an industry term, not a legal one).

Article 8 products that commit to sustainable investments must apply the "do no significant harm" ([DNSH](/glossary/dnsh)) test to those investments and consider Principal Adverse Impact ([PAI](/glossary/pai)) indicators. This significantly increases the disclosure burden and brings the product closer to Article 9 in terms of operational complexity — without requiring that the product's overarching objective be sustainable investment.

## Article 9: Sustainable Investment as the Objective

### The Legal Test

Article 9(1) of SFDR provides that where a financial product "has sustainable investment as its objective" and an index has been designated as a reference benchmark, the financial market participant must provide specified disclosures. Article 9(2) covers products with a carbon emissions reduction objective, and Article 9(3) covers products that have sustainable investment as their objective but do not use a reference benchmark.

This is the "dark green" category. The defining feature is that the product's **objective** — not merely a characteristic it promotes — is sustainable investment.

### What Constitutes a "Sustainable Investment"

Article 2(17) of SFDR defines "sustainable investment" as an investment in an economic activity that:

1. **Contributes to an environmental objective** — as measured by key resource efficiency indicators on energy use, renewable energy, raw materials, water, land use, waste production, greenhouse gas emissions, biodiversity, and the circular economy — or an investment in an economic activity that **contributes to a social objective** — in particular an investment that contributes to tackling inequality, fosters social cohesion, social integration, and labour relations, or invests in human capital or economically or socially disadvantaged communities
2. **Does not significantly harm** any of those environmental or social objectives (the DNSH principle)
3. The investee company follows **good governance practices** — in particular with respect to sound management structures, employee relations, remuneration of staff, and tax compliance

All three prongs must be satisfied simultaneously for an investment to qualify.

### The DNSH Principle in Practice

The "do no significant harm" requirement under Article 2(17) is operationalised through the PAI indicators set out in Table 1 of Annex I to the RTS. At minimum, the financial market participant must consider:

- GHG emissions (Scope 1, 2, and 3)
- Carbon footprint
- GHG intensity of investee companies
- Exposure to companies active in the fossil fuel sector
- Share of non-renewable energy consumption and production
- Energy consumption intensity per high impact climate sector
- Activities negatively affecting biodiversity-sensitive areas
- Emissions to water
- Hazardous waste ratio
- Violations of UN Global Compact principles and OECD Guidelines for Multinational Enterprises
- Gender pay gap
- Board gender diversity
- Exposure to controversial weapons

For an Article 9 product, **every investment** in the portfolio (excluding cash, hedging instruments, and similar ancillary holdings) must qualify as a sustainable investment under Article 2(17) and must pass the DNSH test. This is the most demanding requirement in SFDR and is the primary reason for the wave of Article 9 to Article 8 downgrades.

### Disclosure Obligations for Article 9 Products

Article 9 products must provide the following disclosures:

**Pre-contractual disclosures (Article 9, RTS Annex III):**

- How the sustainable investment objective is to be attained
- If an index is designated as a reference benchmark, how the index is aligned with the sustainable investment objective, including how it differs from a broad market index
- Where no index is designated, an explanation of how the sustainable investment objective is attained
- How the DNSH principle is applied
- The proportion of sustainable investments, broken down by environmental and social objectives

**Website disclosures (Article 10):**

- Description of the sustainable investment objective
- Methodology for assessing, measuring, and monitoring the sustainable investment objective
- Data sources and screening criteria

**Periodic disclosures (Article 11, RTS Annex V):**

- The extent to which the sustainable investment objective was attained
- Overall sustainability-related impact using relevant sustainability indicators
- Top investments, asset allocation, and proportion of sustainable investments
- How the DNSH principle was applied during the reference period

<InlineCTA text="Query SFDR disclosure requirements for your fund classification" href="/signup" label="Analyse SFDR obligations →" />

## Article 8 vs Article 9: Key Differences

| Criterion | Article 8 | Article 9 |
|-----------|-----------|-----------|
| **Core requirement** | Promotes E/S characteristics | Has sustainable investment as its objective |
| **Sustainable investment commitment** | Optional (may commit to a minimum proportion) | Mandatory (entire portfolio, ex cash/hedging) |
| **DNSH application** | Required only for the sustainable investment portion (if any) | Required for all investments |
| **PAI consideration** | Required for sustainable investments; encouraged but not mandatory for the full portfolio | Required for all investments |
| **Good governance test** | Required for investee companies | Required for investee companies |
| **Pre-contractual template** | Annex II of the RTS | Annex III of the RTS |
| **Periodic reporting template** | Annex IV of the RTS | Annex V of the RTS |
| **Reference benchmark** | Optional | Optional (but specific disclosure if used) |
| **Marketing positioning** | "Light green" — promotes sustainability features | "Dark green" — sustainability is the purpose |
| **Regulatory scrutiny** | Moderate — focus on substantiation of E/S claims | High — NCAs actively review portfolio alignment |
| **Reclassification risk** | Lower | Higher (many Article 9 funds downgraded since 2022) |

## Pre-Contractual Disclosures: Annex II vs Annex III

The RTS (Commission Delegated Regulation (EU) 2022/1288) prescribes standardised pre-contractual disclosure templates that must be included in the fund's prospectus, offering memorandum, or equivalent document.

### Annex II (Article 8 Products)

The Annex II template requires disclosure of:

- The E/S characteristics promoted by the product
- The investment strategy, including binding elements
- Asset allocation: a visual breakdown of the proportion of investments aligned with E/S characteristics, the proportion that are sustainable investments (if any), and the remainder
- Whether the product considers PAI on sustainability factors
- If the product commits to sustainable investments, how the DNSH principle is applied
- Data sources, methodologies, and limitations

### Annex III (Article 9 Products)

The Annex III template is more demanding and requires:

- The sustainable investment objective (environmental, social, or both)
- The investment strategy and how it attains the sustainable investment objective
- Asset allocation: a visual breakdown showing the proportion of sustainable investments (which must be substantially all of the portfolio), split between Taxonomy-aligned investments and other environmental or social investments
- How the DNSH principle is applied across the portfolio
- Mandatory PAI consideration
- Whether the product uses an EU Climate Transition Benchmark or EU Paris-Aligned Benchmark

The Annex III template leaves less room for ambiguity. The expectation is clear: the product exists to make sustainable investments, and the disclosures must demonstrate how every investment in the portfolio meets that standard.

## Periodic Reporting Obligations

Both Article 8 and Article 9 products must publish periodic reports (typically annually) that demonstrate whether they delivered on the commitments made in their pre-contractual disclosures.

For Article 8 products (Annex IV of the RTS), the periodic report must include:

- The extent to which E/S characteristics were met
- The share of investments in each sector and geography
- The top investments and their E/S alignment
- If the product committed to sustainable investments, how those investments performed against the DNSH criteria and PAI indicators

For Article 9 products (Annex V of the RTS), the periodic report must additionally include:

- How the sustainable investment objective was attained during the reporting period
- The overall sustainability-related impact, using sustainability indicators
- The comparison between the fund's performance and the designated reference benchmark (if any)

Periodic reporting is where classification decisions are tested against reality. If an Article 9 product reports that a significant share of its portfolio did not qualify as sustainable investments during the reference period, this triggers reclassification risk and potential supervisory action.

## Principal Adverse Impact Indicators

[PAI](/glossary/pai) indicators are the quantitative metrics through which SFDR operationalises its "[do no significant harm](/glossary/dnsh)" principle. Table 1 of Annex I to the RTS sets out 14 mandatory indicators for investments in investee companies and 2 mandatory indicators for investments in sovereigns and supranationals. Additional opt-in indicators are provided in Tables 2 and 3.

### Entity-Level PAI Disclosure

Under Article 4 of SFDR, financial market participants with more than 500 employees must publish an annual PAI statement at entity level. Smaller firms may do so on a comply-or-explain basis.

### Product-Level PAI Consideration

At product level, PAI consideration is:

- **Optional** for Article 6 products (but must be disclosed if not considered)
- **Encouraged** for Article 8 products (mandatory for the sustainable investment portion, if any)
- **Mandatory** for Article 9 products

The PAI indicators have proven operationally challenging. Data availability — particularly for Scope 3 GHG emissions, biodiversity impact, and social indicators — remains limited. Financial market participants frequently rely on estimates, proxies, or third-party ESG data providers, and the quality and consistency of this data vary significantly.

ESMA's supervisory approach has focused on ensuring that PAI disclosures are not boilerplate — they must reflect the actual portfolio composition and the specific adverse impacts associated with the product's investments.

## Common Classification Mistakes and Enforcement Trends

### The Article 9 Overreach

The most widespread classification error has been the overclassification of funds as Article 9. Between 2021 and 2023, many asset managers applied the Article 9 label to products that had sustainability-oriented strategies but could not demonstrate that every investment in the portfolio met the Article 2(17) definition. When ESMA and NCAs clarified that Article 9 requires substantially all investments to be sustainable investments, a wave of reclassifications followed.

Morningstar data shows that in Q4 2022 and Q1 2023, over EUR 175 billion in assets were reclassified from Article 9 to Article 8. This was not a one-off correction — it reflected a systemic misunderstanding of the Article 9 threshold.

### Greenwashing Risk in Article 8 Products

For Article 8 products, the primary enforcement risk is greenwashing — making claims about E/S characteristics that are not substantiated by the investment strategy's binding elements. [NCAs](/glossary/nca), including the AFM ([Netherlands](/jurisdictions/netherlands)), BaFin ([Germany](/jurisdictions/germany)), and the AMF ([France](/jurisdictions/france)), have issued supervisory expectations making clear that:

- The name of the product must not be misleading (ESMA's Guidelines on Fund Names using ESG or Sustainability-Related Terms, applicable since November 2024, set quantitative thresholds for the use of terms like "sustainable" or "ESG" in fund names)
- E/S characteristics claimed in pre-contractual disclosures must be reflected in the investment strategy as binding constraints, not aspirational goals
- Marketing materials must be consistent with the pre-contractual and periodic disclosures

### Enforcement Actions

ESMA's 2025 Common Supervisory Action on sustainability-related disclosures revealed widespread deficiencies, including:

- Inconsistencies between pre-contractual disclosures and actual portfolio composition
- Inadequate DNSH processes — particularly for Article 8 products that commit to sustainable investments
- Insufficient consideration of PAI indicators, with many disclosures using generic language rather than product-specific analysis
- Poor data governance — reliance on third-party ESG data without adequate due diligence on methodology and coverage

NCAs have begun issuing formal supervisory measures, including orders to amend disclosures, restrictions on marketing, and — in some jurisdictions — administrative fines.

## SFDR 2.0: The Upcoming Overhaul

The European Commission published its SFDR 2.0 proposal in November 2025, proposing to replace the Article 8/Article 9 framework with three formal product categories -- Sustainable, Transition, and ESG Collection. The legislative process will continue through 2026-2027, with application not expected before 2028. The current framework remains fully in force.

For the full analysis of the Commission's proposal including the new three-category system, see our [SFDR 2.0 Review Guide](/blog/sfdr-2-0-review-guide).

Fund managers should not wait for SFDR 2.0 to address current compliance gaps. NCAs are enforcing the existing rules, and reclassification or disclosure deficiencies identified today cannot be excused by reference to a future regulatory change. For all upcoming EU regulatory deadlines including SFDR 2.0 milestones, see our [2026 compliance calendar](/blog/eu-financial-regulation-deadlines-2026).

## How financialregulations.eu Can Help

Our platform covers the full SFDR framework — every article of Regulation (EU) 2019/2088, the Level 2 [RTS](/glossary/rts) (Commission Delegated Regulation (EU) 2022/1288), ESMA Q&As, and related instruments including the EU Taxonomy Regulation and the CSRD. You can:

- **Query specific articles:** Ask about Article 8 disclosure obligations, Article 9 DNSH requirements, or PAI indicator calculations
- **Review documents:** Upload draft pre-contractual disclosures, periodic reports, or fund documentation and get them analysed against SFDR requirements
- **Cross-reference:** Check how SFDR interacts with the EU Taxonomy, [CSRD](/glossary/csrd), the Benchmarks Regulation, MiFID II sustainability preferences, and the forthcoming SFDR 2.0 proposals

[Start analysing SFDR requirements - free](https://financialregulations.eu/signup)

---

## Frequently Asked Questions

### What is the difference between Article 8 and Article 9 under SFDR?

Article 8 applies to products that promote environmental or social characteristics alongside other investment objectives. Article 9 applies to products that have sustainable investment as their overarching objective. The key distinction is between promotion (Article 8) and objective (Article 9). Article 9 requires substantially all investments to qualify as sustainable investments under Article 2(17), while Article 8 has no minimum sustainable investment requirement unless the product voluntarily commits to one.

### Can an Article 8 fund become an Article 9 fund?

Yes, but only if the fund genuinely changes its investment objective to sustainable investment and can demonstrate that substantially all of its portfolio meets the Article 2(17) definition. This requires amending the fund's constitutional documents, pre-contractual disclosures, and investment management agreement. The upgrade must reflect a genuine change in strategy, not merely a relabelling exercise. Conversely, many funds have been downgraded from Article 9 to Article 8 when they could not substantiate the Article 9 classification.

### What are the consequences of misclassifying a fund?

Misclassification carries significant risks. NCAs can order disclosure amendments, restrict marketing, or impose administrative fines. Investors may bring claims for mis-selling or misrepresentation. Reputational damage can be severe — reclassification events attract media attention and erode investor confidence. Additionally, ESMA's Guidelines on Fund Names impose naming restrictions that must be aligned with the product's SFDR classification.

### Do Article 8 funds need to consider Principal Adverse Impact indicators?

Article 8 products are not required to consider PAI indicators for the full portfolio, but they must disclose whether they consider PAI and, if they do not, explain why. If an Article 8 product commits to making sustainable investments (the "Article 8+" variant), PAI consideration is mandatory for those sustainable investments. In practice, many Article 8 funds voluntarily consider PAI across the full portfolio to meet investor expectations and comply with MiFID II sustainability preference requirements.

### What happens to current Article 8 and Article 9 classifications when SFDR 2.0 takes effect?

The current classifications remain in force until SFDR 2.0 is adopted and enters into application, which is not expected before 2028 at the earliest. Fund managers should continue to comply with the existing framework. When SFDR 2.0 does take effect, transitional arrangements will likely provide a period for reclassification into the new categories. However, funds that are already robustly classified under the current regime will be better positioned to transition.

### Is EU Taxonomy alignment required for Article 9 funds?

EU Taxonomy alignment is not a prerequisite for Article 9 classification. Article 9 requires that the product has sustainable investment as its objective, and sustainable investment is defined under Article 2(17) of SFDR — which is broader than the Taxonomy. However, Article 9 products must disclose the proportion of their investments that are Taxonomy-aligned, and the Taxonomy provides the most rigorous and legally defined framework for identifying environmentally sustainable activities. In practice, Article 9 products with high Taxonomy alignment percentages are viewed more favourably by investors and supervisors.

---

## Primary Sources

- [SFDR — Regulation (EU) 2019/2088 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/2088/oj) — full SFDR text including Articles 6, 8, 9 and the PAI framework
- [SFDR Delegated Regulation (EU) 2022/1288 — RTS (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/1288/oj) — Commission Delegated Regulation specifying the SFDR Level 2 RTS, PAI indicators, and pre-contractual templates (Annexes II–V)
- [ESMA — Sustainable finance](https://www.esma.europa.eu/esmas-activities/sustainable-finance) — ESMA Q&As, supervisory statements, fund-name guidelines, and convergence work on Article 8 / Article 9 disclosures
- [Joint ESA — SFDR Q&As (EBA)](https://www.eba.europa.eu/regulation-and-policy/transparency-and-pillar-3/sustainable-finance-disclosure-regulation-sfdr) — EBA / ESMA / EIOPA joint Q&As on SFDR application

## Related Guides

- [SFDR 2.0 review](/blog/sfdr-2-0-review-guide) — what the Commission's overhaul means for fund classification and disclosure
- [AIFMD II transposition tracker](/blog/aifmd-ii-transposition-tracker-2026) — timeline and Member State status for the directive that reshapes fund manager obligations
- [AIFMD II liquidity management tools](/blog/aifmd-ii-liquidity-management-tools-guide) — new mandatory LMT requirements for AIFs and UCITS
- [EU financial regulation deadlines 2026](/blog/eu-financial-regulation-deadlines-2026) — full compliance calendar including SFDR 2.0, AIFMD II, DORA, and MiCAR
- [Regulation map](/regulation-map) — interactive overview of all major EU financial regulations and how they interconnect

## Frequently Asked Questions

### What is the difference between SFDR Article 8 and Article 9?

Under SFDR, Article 8 funds 'promote' environmental or social characteristics as part of their investment strategy, while Article 9 funds have a specific 'sustainable investment objective' as their core purpose. Article 9 is the more demanding classification: the fund must invest predominantly in sustainable investments as defined in SFDR Article 2(17), apply the Do No Significant Harm (DNSH) principle to all holdings, and disclose PAI indicators at fund level. Article 8 funds integrate E/S characteristics but may hold a significant proportion of non-sustainable investments. Both classifications require pre-contractual, website, and periodic disclosures under the SFDR Delegated Regulation.

### What are Principal Adverse Impact (PAI) indicators and when are they mandatory?

PAI indicators measure a financial product's adverse effects on sustainability factors — for example, GHG emissions of portfolio companies, biodiversity impact, water usage, board gender diversity, and exposure to controversial weapons. Under SFDR, PAI disclosure at product level is mandatory for all Article 9 funds and for Article 8 funds that claim to consider PAIs. At entity level, financial market participants with more than 500 employees must publish a PAI statement. There are 18 mandatory PAI indicators (14 environmental, 4 social/governance) and a list of optional additional indicators. Data collection for PAI reporting remains challenging given gaps in investee company disclosure.

### What changes under SFDR 2.0?

The European Commission's SFDR 2.0 proposal (November 2025) replaces the Article 8/9 binary with three formal product categories: 'Sustainable' (portfolio predominantly in sustainable investments with measurable environmental or social outcomes), 'Transition' (driving improvements in investees' ESG practices), and 'ESG Collection' (integrating ESG factors without a specific sustainability claim). The existing Article 8 and Article 9 labels will be phased out. Funds will need to reassess their classification and update disclosures, marketing materials, and prospectuses once the new framework applies — expected no earlier than 2027-2028 given the legislative timeline.

### What is an Article 9 fund?

An Article 9 fund (also called a 'dark green' fund) is a financial product that has sustainable investment as its overarching objective under SFDR Article 9. This means substantially all investments in the portfolio must qualify as 'sustainable investments' under SFDR Article 2(17) — contributing to an environmental or social objective, not significantly harming any other sustainability objective (DNSH), and investing in companies that follow good governance practices. Article 9 funds face the most demanding SFDR disclosure obligations, including mandatory PAI indicator reporting and Annex III pre-contractual templates. Since late 2022, over EUR 175 billion in assets have been reclassified from Article 9 to Article 8 due to the difficulty of meeting this standard across entire portfolios.

### What is an Article 8 fund?

An Article 8 fund (also called a 'light green' fund) is a financial product that promotes environmental or social (E/S) characteristics under SFDR Article 8, while the companies it invests in must follow good governance practices. Unlike Article 9, an Article 8 fund does not need to have sustainable investment as its core objective — it promotes E/S characteristics alongside other investment goals. This can include ESG exclusion policies, best-in-class ESG selection, or ESG tilting strategies. Article 8 funds may optionally commit to a minimum proportion of sustainable investments (creating the 'Article 8+' variant), which triggers additional DNSH and PAI disclosure requirements for that portion of the portfolio.

---

# DORA Incident Reporting 2026: 4h, 72h & 1-Month Deadlines for Major ICT Incidents

Source: https://financialregulations.eu/blog/dora-incident-reporting-timeline
Published: 2026-03-17
Last reviewed: 2026-03-17
Author: FinancialRegulations.EU Editorial Team
Tags: DORA, incident-reporting, cybersecurity, operational-resilience

> DORA incident reporting requires three sequential reports to your NCA: initial notification within 4 hours of classification (max 24h from detection), intermediate report within 72 hours, and final report within 1 month. Exact content requirements per DORA Chapter III, NCA submission channels, and what qualifies as a major ICT incident.

Once you have [classified an ICT-related incident](/blog/dora-incident-classification-guide) as **major** under Article 18 of DORA, the reporting clock starts. The reporting framework under Chapter III of Regulation (EU) 2022/2554 requires three sequential reports to your National Competent Authority (NCA), each with a defined deadline and specific content requirements.

This guide sets out the reporting timeline, what each report must contain, where reports go, and what operational infrastructure you need in place before the next major incident.

## The Three-Report Framework

| Report | Deadline | Purpose |
|--------|----------|---------|
| **Initial Notification** | 4 hours after classification as major (max 24 hours after detection) | Alert the NCA that a major incident is underway; provide initial facts |
| **Intermediate Report** | 72 hours after the initial notification | Update on incident status, root cause analysis progress, containment measures, revised impact |
| **Final Report** | 1 month after the intermediate report | Complete post-incident analysis: root cause, total impact, remediation, lessons learned |

## The Trigger: Classification as "Major"

The reporting timeline begins when an incident is classified as major — not when the incident first occurs. This distinction matters for two reasons:

1. **Classification takes time**: Gathering the facts needed to apply the seven criteria (client numbers affected, data loss confirmed, economic impact estimated) requires investigation. The 4-hour clock does not start from the moment a system first shows signs of disruption.

2. **But detection cannot be ignored**: The 24-hour outer limit runs from the moment of **detection**, regardless of classification. If you detect an incident at 06:00 and classify it as major at 12:00, your initial notification must be submitted by 10:00 the following day at the very latest — and preferably by 16:00 (4 hours after classification at 12:00).

**In practice:** The 4-hour window after classification is tight. Financial entities should pre-configure their incident response procedures so that classification triggers an immediate escalation to the compliance/reporting function, with the initial notification submitted without further delay.

<InlineCTA text="Need to check your DORA compliance?" href="/signup" label="Try free analysis" />

## Report 1: Initial Notification

### Deadline

**Within 4 hours of classifying the incident as major**, and **no later than 24 hours after detection**.

If classification happens close to the 24-hour detection mark (e.g., an incident is detected at 08:00 and classification is only confirmed at 22:00), the initial notification must be filed promptly after classification even if this is less than 4 hours after classification.

### Required Content

The initial notification provides first-notice information only. The NCA does not expect complete facts at this stage. The notification must include:

1. **Identity of the reporting entity**: LEI, NCA-registered identifier, legal name, home Member State
2. **Date and time of detection**: When the entity first became aware of the incident
3. **Date and time of classification**: When the incident was formally classified as major
4. **Nature of the incident**: High-level description (cyberattack, system failure, third-party provider outage, human error, etc.)
5. **Classification criteria met**: Which of the seven Article 18 criteria caused the incident to be classified as major (and why)
6. **Services and functions affected**: Which critical or important functions are disrupted, and which services are unavailable to clients
7. **Immediate containment measures**: What actions have been or are being taken to limit the spread or impact
8. **Estimated client impact**: Approximate number of clients affected (if known)
9. **Cross-border impact**: Whether other EU Member States are affected

**What you are not expected to provide** in the initial notification: root cause analysis, complete economic impact figures, final remediation plan. These come in subsequent reports.

### Submission Channel

Reports are submitted to your **home [NCA](/glossary/nca)** through the channel specified by that authority:

| NCA | Reporting channel |
|-----|------------------|
| AFM ([Netherlands](/jurisdictions/netherlands)) | AFM incident reporting portal |
| BaFin ([Germany](/jurisdictions/germany)) | BaFin MELDEWESEN portal |
| CSSF ([Luxembourg](/jurisdictions/luxembourg)) | CSSF eDesk / supervisory reporting system |
| CBI (Ireland) | Central Bank ONR (Online Notification & Reporting) system |
| AMF ([France](/jurisdictions/france)) | AMF Extranet |

NCAs are required to forward major incident reports to the relevant European Supervisory Authority (EBA for banks and payment institutions, ESMA for investment firms and fund managers, EIOPA for insurance and pension funds) within 24 hours of receiving the initial notification.

For **significant institutions** supervised directly by the ECB, reports must also be submitted to the ECB (as joint supervisor with the national NCA) on the same timeline.

### Practical Preparation

Before the next incident:
- Identify and test access credentials for your NCA's reporting portal
- Pre-populate static fields in the initial notification template (entity name, LEI, NCA contact)
- Establish escalation triggers: who makes the decision to classify as major, and who submits the notification

---

## Report 2: Intermediate Report

### Deadline

**Within 72 hours of the initial notification**.

If you submitted the initial notification at 14:00 on Monday, the intermediate report is due by 14:00 on Thursday.

### Required Content

The intermediate report provides an updated picture as the investigation progresses:

1. **Updated incident description**: What is now known about the nature, cause, and scope
2. **Root cause analysis (preliminary)**: Initial assessment of the underlying cause — even if not yet confirmed. Indicate whether human error, technical failure, cyberattack, or third-party failure is suspected.
3. **Updated classification assessment**: Confirm or revise which criteria were met, in light of information gathered since the initial notification
4. **Updated client impact**: Revised figures on clients affected; whether impact has been contained or is still expanding
5. **Containment status**: What containment measures have been implemented; have they succeeded?
6. **Recovery timeline**: Estimated time to full service restoration (if known)
7. **Actions taken**: Concrete steps taken since the initial notification — system isolation, failover activation, vendor engagement, forensic investigation initiation
8. **Cross-border coordination**: If other Member States' NCAs have been notified (directly or via home NCA forwarding); whether relevant CERT has been engaged
9. **Communication to clients**: Whether affected clients have been notified, and through what channel

**At this stage**, the investigation is typically ongoing. The intermediate report reflects the best available information, not the final picture. NCAs understand this; what they expect is good-faith, accurate reporting of what is known, and transparency about what is not yet confirmed.

### If the Incident Is Resolved Before the Intermediate Report

If the major incident is **fully resolved** before the 72-hour intermediate report deadline, submit a combined intermediate and final report. Mark it as a combined submission and include all the content required for both stages.

---

## Report 3: Final Report

### Deadline

**Within 1 month of the intermediate report**.

This is the longest window — but the final report demands the most substance. By this stage, the incident investigation should be complete, root cause confirmed, and remediation measures implemented or scheduled.

### Required Content

The final report is the definitive account of the incident:

1. **Complete incident timeline**: From first signs of disruption to full restoration, with timestamps for key events
2. **Root cause determination**: Confirmed root cause(s), not preliminary assessment. Was this a software vulnerability, misconfiguration, social engineering, third-party failure, or process breakdown?
3. **Full impact assessment**:
   - Total number of clients affected (final figure)
   - Duration of service disruption (actual, not estimated)
   - Data losses confirmed (categories of data, number of records, regulatory consequences)
   - Direct financial losses (recovery costs, contractual penalties, compensation paid)
   - Indirect losses (revenue foregone, reputational impact, opportunity cost)
4. **Third-party involvement**: If an ICT third-party service provider was involved, identify the provider (unless prohibited by confidentiality obligations), describe the provider's role, and set out what contractual and operational remediation steps have been taken
5. **Remediation measures**: Specific technical and process changes implemented or committed to, with timelines for completion of outstanding actions
6. **Lessons learned**: How the entity's ICT risk management framework, incident response procedures, or technical controls are being updated in response to this incident
7. **Regulatory consequences**: Whether the incident has triggered any other reporting obligations (GDPR, NIS2, MiFID II transaction reporting, CRR reporting for credit institutions)
8. **Recurrence risk assessment**: Assessment of the likelihood of recurrence and the steps taken to reduce that risk

**Important:** The final report is reviewed by the NCA as an indicator of the financial entity's overall ICT risk culture and management maturity. Superficial final reports — those that attribute incidents to "human error" without structural analysis or that propose no meaningful remediation — attract follow-up supervisory attention.

---

## Voluntary Client Notification

DORA does not mandate client notification for every major incident. However, Article 19(4) states that financial entities **should inform their clients** of major incidents when the incident affects or may affect the financial interests of those clients.

The practical standard is: if a client cannot access their account, if their transaction has not settled, if their data has been exposed, or if their service is materially disrupted — notify them, promptly and clearly.

Client notifications are separate from NCA reports. The content and channel for client notifications are governed by the contractual relationship and the financial entity's client communications obligations (e.g., MiFID II client disclosure obligations for investment firms).

---

## Reporting for the "Significant Cyber Threat" Category

As noted in our companion article on [incident classification](/blog/dora-incident-classification-guide), DORA also creates a separate notification category for **significant cyber threats** that have not yet materialised into incidents.

For cyber threats:
- Notification to the NCA is **voluntary** (not mandatory)
- Notification to affected clients is required if the threat **could affect their financial interests** — this is mandatory once you assess the threat as significant and client-impacting
- There are no fixed timelines, but "without undue delay" is the standard

**Practical implication:** Treat cyber threat notifications as a good-faith supervisory relationship tool. NCAs value early warning of credible threats, particularly those targeting multiple financial entities (e.g., a campaign against custody firms). Sharing threat intelligence builds supervisory goodwill and may result in useful threat intelligence in return.

---

## Building Your DORA Incident Reporting Infrastructure

Complying with the DORA reporting timeline requires operational infrastructure that cannot be built at the time of the incident. The following components should be in place now:

### Incident Response Runbook with Reporting Integration

Your incident response runbook must integrate reporting triggers at each classification milestone:

```
Incident detected
  → Incident response team activated
  → Initial triage and severity assessment
  → Classification assessment (7 criteria)
  → IF classified as MAJOR:
      → Compliance/CCO notified immediately
      → Initial notification preparation begins
      → NCA portal access credentials retrieved
      → Initial notification submitted within 4 hours
  → 72-hour calendar alert set for intermediate report
  → 1-month calendar alert set for final report
```

### Pre-Approved Template Library

Draft templates for all three reports and obtain management approval in advance. Templates should include:
- All static entity information (LEI, NCA contact, regulatory reference)
- Structured sections matching NCA portal requirements
- A checklist of required data elements for each stage
- Named individuals responsible for drafting, reviewing, and submitting each report

### NCA Portal Access and Testing

Test NCA portal access at least annually. Ensure:
- Multiple nominated individuals have portal credentials (single-person dependency is an operational risk)
- Portal login credentials are documented in a secure, accessible location (not only on the personal device of one IT staff member)
- Test submissions (where NCAs offer sandbox/test environments) have been completed

### Cross-Functional Escalation Chain

Incident reporting under DORA is not a purely technical matter. The compliance function (not the IT team) is responsible for the regulatory report. The escalation chain must be clear:

1. IT/SOC: detects incident, assesses technical scope
2. CISO / IT Risk: applies classification criteria, determines whether major
3. Compliance / CCO: receives classification decision, triggers NCA notification, oversees report content
4. Management Body: informed of major incidents promptly (Article 5 board responsibility); final report reviewed by board

### NCA Communication Contact

Identify the named contact or reporting mailbox at your NCA. For most NCAs, this is published on the supervisory authority's website. Store this contact in a location accessible during a system outage (not solely in a digital system that may itself be affected by the incident).

---

## Common Errors in DORA Incident Reporting

**1. Starting the clock from incident occurrence rather than classification**

The 4-hour window runs from classification as major, not from when the disruption first started. However, the 24-hour outer limit runs from detection. Do not over-engineer the classification process at the expense of triggering a late notification.

**2. Treating the initial notification as a final report**

The initial notification is explicitly a "heads-up" report. Compliance teams sometimes delay submitting the initial notification while waiting for confirmed root cause or complete client impact figures. This is wrong — submit the initial notification with what you know, flag what is uncertain, and update in the intermediate report.

**3. Overlooking [NIS2](/blog/dora-vs-nis2-comparison) and GDPR parallel obligations**

A DORA major incident will often also be a NIS2 significant incident (for entities in scope of NIS2 — noting that financial entities are primarily subject to DORA as lex specialis) and a GDPR personal data breach. Each framework has its own reporting obligation with its own deadline. Map your incident response procedure to handle parallel reporting to multiple authorities where required. The same is true on the third-party side: an outage at a vendor recorded in your [Article 28 register](/blog/dora-ict-third-party-register-guide) may simultaneously trigger DORA and NIS2 obligations depending on how the entity itself is classified.

**4. Failing to notify clients when required**

Article 19(4) requires client notification where financial interests may be affected. Fund managers who experience extended NAV disruption, settlement failures, or data exposure without notifying investors face both regulatory and contractual liability.

**5. Treating incident reporting in isolation from third-party records**

Many major ICT incidents originate at, or are amplified by, an ICT third-party provider. Final reports must identify provider involvement (where contractually permitted) and tie the incident back to the contractual arrangement. If your [DORA register of information](/blog/dora-ict-third-party-register-guide) is incomplete or stale, your final report will struggle to map the incident accurately to the affected provider, contract, and supported critical or important function.

**6. Final reports with no substantive lessons learned**

A final report that concludes "we experienced a system failure, we restored it, no further action needed" will not satisfy DORA's intent. Regulators expect meaningful root cause analysis and concrete remediation measures. If the root cause was a misconfigured firewall rule — say so, and explain what process change prevents recurrence.

---

## Primary Sources

- [DORA — Regulation (EU) 2022/2554 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — full DORA text including Articles 17–23 on ICT-related incident management and reporting
- [Commission Delegated Regulation (EU) 2024/1772 — incident classification (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj) — RTS specifying the criteria, materiality thresholds and methodology for classifying incidents as major
- [Joint ESA — DORA incident reporting framework (EBA)](https://www.eba.europa.eu/regulation-and-policy/operational-resilience/digital-operational-resilience-act-dora) — EBA, ESMA and EIOPA technical standards, templates and Q&As on the 4h / 72h / 1m reporting obligations
- [ESMA — DORA implementation page](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora) — ESMA's published RTS, ITS and supervisory communications

---

**Need to analyse specific DORA incident reporting and classification obligations?** financialregulations.eu provides AI-powered answers grounded in the full DORA text, all published RTS and ITS on incident reporting, and NCA-specific guidance from AFM, BaFin, CSSF, and CBI.

[Analyse Your DORA Obligations — Free →](/signup)

## Frequently Asked Questions

### What are the three DORA incident reports and when are they due?

DORA requires three sequential reports for major ICT incidents: (1) Initial notification — submitted within 4 hours of classifying the incident as major, with a hard cap of 24 hours from first detection; (2) Intermediate report — submitted within 72 hours of the initial notification, containing an updated impact assessment; (3) Final report — submitted within 1 month of the intermediate report, covering root cause analysis and remediation measures. All reports are submitted to your national competent authority (NCA) via the designated digital channel.

### Where do I submit DORA incident reports?

Reports are submitted to your entity's home-state national competent authority (NCA) — for example, the DNB for Dutch institutions, BaFin for German entities, or the ECB directly for significant institutions under SSM supervision. Reports must use the standardised templates specified in Commission Implementing Regulation (EU) 2024/2956. For cross-border groups, the lead NCA coordinates with host-state supervisors. NCAs aggregate reports and forward information to EBA, ESMA, or EIOPA depending on the entity type.

### What information must the DORA initial notification contain?

The initial notification must include: the entity's identity and contact details, classification as major, the date and time of first detection, a brief description of the incident, the services and infrastructure affected, and the initial estimate of the number of clients and financial counterparts impacted. The initial notification can be submitted with limited information if more details are not yet available, with a note that the intermediate report will provide an update.

---

# DORA Incident Classification: The 7 Criteria That Determine Whether an Incident Is 'Major'

Source: https://financialregulations.eu/blog/dora-incident-classification-guide
Published: 2026-03-17
Last reviewed: 2026-03-17
Author: FinancialRegulations.EU Editorial Team
Tags: DORA, incident-classification, cybersecurity, operational-resilience

> Under DORA Article 18, an ICT-related incident is 'major' if it meets 2 or more of 7 criteria: clients affected, geographic spread, data losses, criticality of services, duration, economic impact, and reputational damage. This guide explains each criterion with materiality thresholds and a classification decision framework.

The Digital Operational Resilience Act — DORA, Regulation (EU) 2022/2554 — has applied since 17 January 2025. One of the most operationally demanding requirements is the ICT-related incident reporting regime under Chapter III. Before any report goes to your National Competent Authority, you must first classify the incident correctly.

This guide explains the seven classification criteria from Article 18 of DORA and the joint [RTS](/glossary/rts) on incident classification, sets out the materiality thresholds that determine whether an incident is "major," and provides a decision framework that compliance and IT teams can use before the next incident occurs.

## Why Classification Comes Before Reporting

DORA distinguishes between two categories of ICT-related incidents:

| Category | Reporting Obligation | Timeline |
|----------|---------------------|----------|
| **Major ICT-related incident** | Mandatory report to NCA (initial, intermediate, final) | 4h / 72h / 1 month |
| **Significant cyber threat** | Voluntary notification to NCA; client notification if threat could affect them | Prompt |
| **All other ICT-related incidents** | Log internally; analyse as part of annual risk review | No external reporting |

Misclassifying a major incident as non-major is a supervisory failure. Under-reporting has attracted enforcement attention from [NCAs](/glossary/nca) across the EU in analogous frameworks ([NIS](/blog/dora-vs-nis2-comparison), PSD2, GDPR). Over-reporting (treating minor incidents as major) creates unnecessary regulatory burden and may trigger supervisory inquiries.

The classification decision must be made promptly — the [initial notification](/blog/dora-incident-reporting-timeline) must be submitted within **4 hours** of an incident being classified as major (and no later than **24 hours** after detection). There is no time for prolonged committee deliberation once classification is complete.

## The 7 Classification Criteria Under Article 18

Article 18 of DORA requires financial entities to classify ICT-related incidents based on seven criteria. The Joint RTS on incident classification (developed jointly by EBA, ESMA, and EIOPA) specifies the quantitative and qualitative thresholds for each criterion.

An incident is **major** if it meets the materiality thresholds for **2 or more** of the seven criteria.

### Criterion 1: Clients and Financial Counterparties Affected

**What it measures:** The breadth of client impact — how many clients or financial counterparties are unable to access services or have their data affected.

**Major threshold:**
- More than **10% of all clients** who use the disrupted service are affected; OR
- More than **500 clients** in absolute numbers are affected

**Practical notes:**
- "Clients" includes both retail and professional clients. Count all clients who use the disrupted function, not all clients of the firm.
- If you provide a single service to 200 clients and all 200 are affected, the 500-client absolute threshold is not met — but check whether 200 represents ≥10% of your client base for that service.
- Counterparties in settlement or clearing chains count alongside end clients.

**Examples:**
- A NAV calculation system outage affecting 1,200 investors in a fund → Criterion 1 threshold met (>500 clients)
- An order management system failure affecting 45 of your 600 institutional clients → Criterion 1 threshold met (45/600 = 7.5%, below 10%; and below 500 absolute — threshold NOT met on this criterion)

---

### Criterion 2: Geographic Spread

**What it measures:** Whether the incident affects operations or clients across multiple EU Member States or critical infrastructure.

**Major threshold:**
- The incident affects the financial entity's operations or clients in **more than one EU Member State**; OR
- The disruption affects critical financial infrastructure that spans Member States

**Practical notes:**
- This criterion is particularly relevant for cross-border firms — pan-European custodians, investment managers with multi-jurisdiction operations, or [UCITS](/glossary/ucits) distribution platforms.
- A purely local incident (e.g., a data centre outage affecting only UK operations post-Brexit) may not trigger this criterion even if it is operationally significant.
- Geographic spread is assessed by where the affected clients and operations are located, not where the financial entity is headquartered.

**Examples:**
- A trading system outage affecting clients in Germany, France, and the Netherlands simultaneously → Criterion 2 threshold met
- A local office network failure in Amsterdam affecting only Dutch-based staff → Criterion 2 threshold NOT met

---

### Criterion 3: Data Losses

**What it measures:** Whether the incident causes or risks causing a breach of confidentiality, integrity, authenticity, or availability of data.

**Major threshold:**
- Breach of **confidentiality** of personal or commercially sensitive data; OR
- Breach of **integrity** of data (corruption, unauthorized modification); OR
- Breach of **authenticity** of data (inability to verify data origin); OR
- Extended loss of **availability** of data necessary for critical functions

**Practical notes:**
- This criterion does not have a purely quantitative threshold — it is qualitative. Any confirmed breach of data confidentiality (even affecting a single client's data) will meet the threshold.
- Availability loss is assessed in combination with Criterion 4 (duration) and Criterion 5 (criticality of services).
- Under GDPR, a personal data breach may trigger separate notification obligations to data protection authorities (DPAs) within 72 hours — DORA's incident reporting to NCAs runs in parallel, not as a substitute.

**Examples:**
- Unauthorized access to client portfolio data extracted by a threat actor → Criterion 3 threshold met (confidentiality breach)
- A ransomware attack that encrypts trade records and prevents access for 3 hours → Criterion 3 potentially met (availability loss + potential integrity concern)
- A brief network connectivity outage with no data access or exfiltration → Criterion 3 threshold NOT met

---

### Criterion 4: Criticality of Services Affected

**What it measures:** Whether the disrupted services are "critical or important" functions of the financial entity.

**Major threshold:**
- The incident disrupts a function designated as **critical or important** under the financial entity's ICT risk management framework (Article 6 of DORA); AND
- The disruption affects the financial entity's ability to provide those functions

**Practical notes:**
- Each financial entity must have identified its critical and important functions as part of its ICT risk management framework. If this mapping has not been completed, Criterion 4 cannot be properly applied.
- Critical functions for fund managers typically include: NAV calculation, order processing, portfolio management systems, investor reporting, regulatory reporting, fund accounting, and transfer agency.
- A disruption to a non-critical function (e.g., an internal HR system) does not meet this criterion even if operationally disruptive.

**Examples:**
- A fund accounting platform outage that prevents NAV publication → Criterion 4 threshold met (NAV calculation is a critical function)
- A disruption to the internal ticketing system used by IT support → Criterion 4 threshold NOT met (not a critical or important financial function)

---

### Criterion 5: Duration

**What it measures:** How long the incident lasts.

**Major threshold:**
- The incident lasts **more than 24 hours** for services other than payment services; OR
- The incident lasts **more than 2 hours** for payment services or settlement services

**Practical notes:**
- Duration is measured from the start of the disruption (when the service first became unavailable or impaired) to full restoration.
- A recurring incident — where a system is disrupted, partially restored, and disrupted again — counts as a single incident if the underlying cause is the same.
- Partial service restoration (e.g., the system is up but processing at reduced capacity or with data quality concerns) does not stop the duration clock.

**Examples:**
- A core banking system outage from 09:00 to 13:30 (4.5 hours) affecting retail payment processing → Criterion 5 threshold met (>2 hours for payment services)
- A fund transfer system disruption from Monday afternoon to Wednesday morning (>24 hours) → Criterion 5 threshold met
- A 45-minute data feed interruption that is fully resolved with no data loss → Criterion 5 threshold NOT met

---

### Criterion 6: Economic Impact

**What it measures:** The direct and indirect financial losses attributable to the incident.

**Major threshold:**
- Direct costs attributable to the incident exceed **EUR 100,000**; OR
- Total costs (including opportunity costs and reputational damage estimates) exceed **EUR 500,000**

**Practical notes:**
- Direct costs include: recovery expenses (external IT support, forensics, legal), regulatory fines, contractual penalties, and compensation paid to affected clients.
- Opportunity costs may include: revenue foregone due to inability to execute trades, penalties for missed settlement, increased borrowing costs.
- At the time of classification, the full economic impact may be unknown — use a reasonable estimate based on available information. You can revise the assessment in the intermediate and final reports.
- For small financial entities, these thresholds may be proportionate to annual revenue. The proportionality principle in Article 4 of DORA does not eliminate the reporting obligation, but may affect how NCAs assess the materiality of borderline cases.

**Examples:**
- A cyberattack requiring EUR 150,000 in forensic recovery costs → Criterion 6 threshold met (direct costs >EUR 100,000)
- A brief outage causing EUR 20,000 in client compensation → Criterion 6 threshold NOT met on direct cost basis; check indirect costs

**Note on third-party-driven incidents:** Where the disruption originates at an ICT third-party provider, the entries in your DORA [register of information](/blog/dora-ict-third-party-register-guide) (specifically RT.04 contractual data and RT.02 function mapping) are the fastest way to scope economic impact across affected functions.

---

### Criterion 7: Reputational Impact

**What it measures:** Whether the incident has or is likely to have a material reputational impact on the financial entity.

**Major threshold:**
- The incident has led to or is likely to lead to significant media coverage; OR
- The incident has led to or is likely to lead to regulatory scrutiny or supervisory inquiries outside the incident reporting itself; OR
- The incident has materially damaged the financial entity's reputation with clients or counterparties

**Practical notes:**
- This is the most subjective of the seven criteria. It requires judgment at the time of classification about likely reputational consequences.
- "Significant media coverage" means coverage in national or trade press that identifies the financial entity by name and links it to an ICT failure — not general industry commentary.
- Supervisory inquiries specifically triggered by the incident (from the NCA, EBA, ESMA, or EIOPA) count; routine supervisory contact does not.

**Examples:**
- A major custody bank's core system outage reported in the Financial Times → Criterion 7 threshold met
- An incident at a small AIFM known to a narrow audience with no press coverage expected → Criterion 7 threshold NOT met unless clients or counterparties escalate

---

<InlineCTA text="Need to check your DORA compliance?" href="/signup" label="Try free analysis" />

## The Classification Decision Framework

Apply the seven criteria in sequence as soon as you detect an ICT-related incident. An incident is **major** if **2 or more criteria** are met at their defined thresholds.

```
ICT-related incident detected
         │
         ▼
Does the incident affect a critical or important function? (Criterion 4)
  If NO → lower likelihood of major; continue assessment
  If YES → one criterion met; continue checking for a second
         │
         ▼
Assess the remaining 6 criteria:
  1. Clients affected: >10% or >500 absolute?
  2. Geographic spread: >1 EU Member State?
  3. Data losses: confidentiality/integrity/authenticity breach?
  5. Duration: >24h (or >2h for payments)?
  6. Economic impact: direct >EUR 100k or total >EUR 500k?
  7. Reputational impact: significant media/regulatory attention?
         │
         ▼
≥ 2 criteria met?
  YES → Classify as MAJOR ICT-related incident → Initiate reporting procedure
   NO → Log as non-major incident; monitor for escalation
```

## The "Significant Cyber Threat" — A Separate Category

Article 19 of DORA introduces a separate concept: the **significant cyber threat**. This is not an incident that has materialised, but a threat with the potential to become one.

Financial entities that detect a significant cyber threat must:
1. Notify their competent authority **promptly** (no fixed timeline, but "without undue delay")
2. Notify affected clients **if the threat could affect their financial interests**

What constitutes a "significant" threat is not defined with the same precision as the incident criteria, but the RTS provides guidance: a threat is significant if it has the technical characteristics to cause material disruption to critical functions or data loss, even if not yet exploited.

**Practical implication:** A credible, targeted phishing campaign against your key operational staff, or evidence of active reconnaissance against your trading infrastructure, may require NCA notification even before any disruption occurs. Do not treat threat intelligence as purely an internal IT matter.

## Preparing for Classification Before the Next Incident

The classification decision under Article 18 must be made under time pressure. Compliance and operational resilience teams should prepare the following before any incident occurs:

### 1. Map Critical and Important Functions

Criterion 4 requires you to have identified your critical and important functions in advance. This mapping must be documented in your ICT risk management framework (Article 6). Without it, you cannot apply Criterion 4 correctly. The same critical/important function (CIF) flag drives the [ICT third-party register guide](/blog/dora-ict-third-party-register-guide)'s RT.02 template — keep both artefacts in sync.

### 2. Establish Client Population Baselines

To apply Criterion 1, you need to know your client population for each critical service. Prepare a table showing: service name, number of clients using the service, and the 10% threshold (i.e., 10% of the client population for that service).

### 3. Pre-Define Classification Thresholds in Your Incident Response Procedure

Incorporate the seven criteria and their thresholds directly into your incident response procedure or runbook. When an incident is detected, the on-call team should be able to run through the criteria checklist without referring to the RTS text.

### 4. Identify the Reporting Contact for Each [NCA](/glossary/nca)

Reporting goes to your home NCA: AFM ([Netherlands](/jurisdictions/netherlands)), BaFin ([Germany](/jurisdictions/germany)), CSSF ([Luxembourg](/jurisdictions/luxembourg)), CBI (Ireland), AMF ([France](/jurisdictions/france)), etc. Identify the reporting portal or contact in advance. NCA portals are published on their websites; do not discover this for the first time at 2am when you have 4 hours to submit an initial notification.

### 5. Pre-Draft Your Initial Notification Template

The initial notification under Article 19 must include: the nature of the incident, the time it was detected and when it started, the classification criteria met, the functions and services affected, and the immediate containment measures taken. Pre-drafting a template and populating the static fields in advance will save critical time.

---

**Need to analyse the DORA incident classification RTS and incident response requirements?** financialregulations.eu provides AI-powered answers grounded in the full DORA text and all published RTS and ITS — including the joint RTS on incident classification.

[Analyse DORA Requirements — Free →](/signup)

## Frequently Asked Questions

### What qualifies as a major ICT incident under DORA?

Under DORA Article 18, an ICT-related incident is classified as major if it meets at least 2 of 7 criteria set out in Commission Delegated Regulation (EU) 2024/1772: (1) number of clients affected or counterparties impacted; (2) geographic spread across member states; (3) data losses caused; (4) criticality or importance of affected services; (5) duration of the incident or service unavailability; (6) economic impact measured as direct and indirect costs; and (7) reputational damage to the financial entity. Meeting only one criterion, regardless of severity, does not trigger the major incident reporting obligation.

### How many clients must be affected for an incident to qualify as major under DORA?

Under the materiality thresholds in Commission Delegated Regulation (EU) 2024/1772, the clients-affected criterion is met if the incident impacts more than 10% of clients for entities with up to 100,000 clients, or more than 10,000 clients for larger entities. For payment-related services, thresholds are based on the number of transactions affected. The threshold varies by entity type — credit institutions, investment firms, and payment institutions each have specific thresholds set in the delegated regulation.

### Does DORA incident classification apply only to cyberattacks?

No. DORA Article 18 applies to all ICT-related incidents regardless of cause — cyberattacks, software failures, hardware outages, third-party provider disruptions, and operational errors all fall within scope. The classification criteria focus on impact (clients affected, service unavailability, data loss) not on the cause. Power outages affecting core banking systems, failed software updates causing service downtime, or third-party cloud provider failures are all subject to the same 7-criteria classification framework.

---

# AIFMD II Transposition Deadline 16 April 2026: Country Status, LMT & Loan Origination Rules for Fund Managers

Source: https://financialregulations.eu/blog/aifmd-ii-transposition-tracker-2026
Published: 2026-03-17
Last reviewed: 2026-04-17
Author: FinancialRegulations.EU Editorial Team
Tags: AIFMD, fund-management, transposition, Luxembourg, Netherlands, France, Belgium

> AIFMD II's 16 April 2026 transposition deadline has passed. Germany, Luxembourg, Netherlands and Ireland transposed on time; France, Belgium, Italy and Spain did not. Country-by-country status plus immediate compliance steps for fund managers — LMT selection (two tools required), loan origination concentration limits, delegation oversight, and partial depositary passport access.

Directive (EU) 2024/927 — AIFMD II — amends both the Alternative Investment Fund Managers Directive (2011/61/EU) and the [UCITS](/glossary/ucits) Directive (2009/65/EC). The transposition deadline of **16 April 2026 has now passed**. Germany, Luxembourg, the Netherlands, and Ireland transposed on or before the deadline. France, Belgium, Italy, and Spain did not complete transposition by the deadline date.

**Updated 17 April 2026:** The deadline has passed. For a dedicated guide covering what fund managers in non-transposing member states (France, Belgium, Italy, Spain) must do now — including legal consequences, supervisory expectations, and practical actions — see [AIFMD II Deadline Passed: What Fund Managers in France, Belgium, Italy and Spain Must Do Now](/blog/aifmd-ii-deadline-passed-non-transposition-2026).

This article sets out the country-by-country transposition status as of March–April 2026 across the main EU fund jurisdictions.

## Why Transposition Status Matters for Fund Managers

AIFMD II is a Directive. Unlike a Regulation, it does not automatically become part of each Member State's legal order — it must be implemented through national legislation. Until national implementing measures enter into force, the AIFMD II requirements do not exist as enforceable obligations in that jurisdiction.

For fund managers, this creates a practical planning challenge:

- **If your home [NCA](/glossary/nca)'s jurisdiction has transposed**: requirements are live; you need to comply.
- **If your home NCA's jurisdiction has not transposed**: the legal position is uncertain. The Directive is binding on Member States (including the obligation to transpose by 16 April 2026), and NCAs may begin applying ESMA guidance in anticipation. But strictly speaking, obligations do not bite until national law is in force.
- **If you are marketing into jurisdictions with different transposition timelines**: obligations may differ across distribution markets.

Regardless of national transposition timing, fund managers should be implementing AIFMD II changes now. The deadline has been known since April 2024. Waiting for the final national bill creates execution risk. For all 2026 deadlines including AIFMD II, MiCAR, DORA, and the AML Package, see our [compliance calendar](/blog/eu-financial-regulation-deadlines-2026).

For the Commission Delegated Regulation on liquidity management tools — which also applies from 16 April 2026 and requires open-ended AIFs to select at least two LMTs — see our [AIFMD II Liquidity Management Tools guide](/blog/aifmd-ii-liquidity-management-tools-guide).

## [Luxembourg](/jurisdictions/luxembourg) — Bill of Law 8402 in Parliamentary Process

Luxembourg is the largest EU fund domicile by AUM and has the most to implement. Its AIFMD II transposition is proceeding through Bill of Law 8402, introduced to the *Chambre des Députés* in late 2025.

The bill amends the Luxembourg Law of 12 July 2013 on AIFMs and the Law of 17 December 2010 on UCIs, as well as the Law of 23 July 2016 on Reserved Alternative Investment Funds (RAIFs).

**Key Luxembourg implementation points:**

- The CSSF is expected to publish supervisory positions on the [LMT](/glossary/lmt) requirements before the transposition deadline, consistent with its practice of providing implementation guidance to Luxembourg-authorised managers.
- Luxembourg's delegation model — where AIFMs domiciled in Luxembourg delegate portfolio management to managers in London, New York, or Hong Kong — requires close attention to the enhanced delegation oversight requirements under Article 20 of the amended AIFMD. Luxembourg AIFMs that have historically relied on lightweight oversight structures will need to demonstrate genuine substance.
- The partial depositary passport, which permits depositaries from other Member States to act for Luxembourg-domiciled AIFs under specific conditions, requires amendment to depositary appointment documentation and agreements.
- Luxembourg RAIFs and SIFs that pursue loan origination strategies must implement risk retention (5% of notional for sold loans), diversification limits, and lending policies before the deadline.

**Status (March 2026):** Bill of Law 8402 proceeding through parliament. Implementation expected before the April 16 deadline. CSSF guidance anticipated. Fund managers should implement rather than wait for final national law.

<InlineCTA text="Need to check your AIFMD II compliance?" href="/signup" label="Try free analysis" />

## [Netherlands](/jurisdictions/netherlands) — Wft Amendment Bill in Progress

The [Netherlands](/jurisdictions/netherlands) transposes AIFMD II through amendments to the *Wet op het financieel toezicht* (Wft) and the *Besluit Gedragstoezicht financiële ondernemingen* (Bgfo). The Dutch Ministry of Finance submitted an implementing bill for consultation in 2025.

**Key Netherlands implementation points:**

- The AFM has published supervisory communications indicating its AIFMD II priorities: LMT implementation for open-ended Dutch AIFs, delegation substance for AIFMs that delegate outside the EU, and loan origination fund governance.
- Dutch-domiciled AIFMs should review their delegation oversight frameworks — particularly those with delegated portfolio management in the UK or outside the EU following Brexit.
- The LMT requirements apply to open-ended AIFs managed by Dutch AIFMs. Dutch AIFMs managing Luxembourg-domiciled open-ended funds are subject to the AIFMD II requirements of the fund's home state (Luxembourg), but oversight of compliance may fall to the AFM as the AIFM's home NCA.
- Dutch private credit vehicles that originate loans must assess whether they qualify as "loan-originating AIFs" under the AIFMD II definition and, if so, implement the full loan origination framework.

**Status (March 2026):** Transposition bill in legislative process. AFM supervisory priorities published. Fund managers should proceed with implementation regardless of final bill timing.

## [Germany](/jurisdictions/germany) — Transposition via KAGB Amendment

[Germany](/jurisdictions/germany) transposes AIFMD II primarily through amendments to the *Kapitalanlagegesetzbuch* (KAGB), which governs both AIFMs and UCITS management companies. BaFin has published consultation papers on key AIFMD II provisions.

**Key Germany implementation points:**

- Germany has historically been prompt in implementing EU fund directives. BaFin's AIFMD II consultations suggest the implementing measures are technically advanced.
- German *Spezial-AIFs* — closed-ended funds used by institutional investors — are widely used for real asset and private credit strategies. Loan-originating German AIFs will need to implement the full AIFMD II loan origination framework.
- The LMT requirements apply to open-ended German *Publikums-AIFs* and UCITS. German UCITS management companies managing retail funds must select and document at least two LMTs.
- German AIFMs that use *Masterfonds/Feederfonds* structures should review whether the LMT obligations flow through to feeder structures.

**Status (March 2026):** KAGB amendment bill in advanced legislative stages. BaFin guidance published for key provisions. Implementation widely expected before the April 16 deadline.

## Ireland — CBI Guidance Issued, Legislation in Progress

Ireland is the second-largest EU UCITS domicile and a significant AIF jurisdiction. The Central Bank of Ireland (CBI) transposition runs through amendments to the European Union (Alternative Investment Fund Managers) Regulations 2013 and the European Union (Undertakings for Collective Investment in Transferable Securities) Regulations 2011.

**Key Ireland implementation points:**

- The CBI has a well-established pattern of publishing detailed guidance alongside transposition legislation. Fund managers should monitor the CBI Register for implementing statutory instruments and accompanying Central Bank guidance.
- Irish-domiciled UCITS are predominantly managed by large asset managers with established LMT frameworks. However, fund documentation review remains mandatory — constitutional documents must legally embed the selected LMTs.
- For Irish-domiciled AIFs with delegated portfolio management to the US or UK, the delegation reporting and oversight substance requirements demand attention. The CBI has historically been firm on delegation governance.
- The partial depositary passport has limited immediate relevance in Ireland, given the depth of the Irish depositary market and the availability of global custodians with Irish entities.

**Status (March 2026):** Statutory instruments in legislative process. CBI guidance expected. Ireland has a consistent track record of meeting directive transposition deadlines.

## [France](/jurisdictions/france) — Legislation Pending, AMF Active on Guidance

[France](/jurisdictions/france) transposes AIFMD II through amendments to the *Code monétaire et financier* (CMF) and AMF General Regulation (*Règlement Général de l'AMF*). Legislative progress has been slower than in Luxembourg, Germany, or the Netherlands.

**Key France implementation points:**

- The AMF has published position papers and consultation documents on key AIFMD II provisions, particularly on delegation and LMTs.
- French *Fonds Professionnels de Capital Investissement* (FPCIs) and *Fonds Communs de Placement à Risques* (FCPRs) that originate loans must assess applicability of the loan origination framework.
- French asset managers with delegation to non-EU portfolio managers — a common structure for global asset management groups — face increased scrutiny under the enhanced delegation substance requirements.
- The MiFID II top-up provisions (clarifying conduct requirements for AIFMs providing ancillary services) require French managers to review their ancillary service compliance frameworks.

**Status (March 2026):** Legislative process ongoing. AMF has published supervisory guidance. Managers should not rely on national law being delayed as a reason to defer implementation.

## ESMA's Role: Level 2 Measures Providing Uniform Standards

AIFMD II's practical implementation depends heavily on ESMA's Level 2 measures, which apply uniformly across all Member States regardless of national transposition timing:

### [RTS](/glossary/rts) on Liquidity Management Tools

ESMA published draft [RTS](/glossary/rts) specifying the characteristics of each LMT (activation thresholds, investor disclosure requirements, and supervisory notification timelines) in mid-2025. The RTS underwent a consultation process and are expected to be adopted by the European Commission as delegated regulations.

Key RTS provisions on LMTs:
- **Redemption gates**: Maximum percentage that can be gated, minimum notice required, supervisory notification when gates are activated
- **Notice periods**: Minimum and maximum notice periods for different fund categories
- **Anti-dilution levies**: How the levy should be calculated and disclosed
- **Swing pricing**: Methodology consistency requirements

### RTS on Delegation Reporting

ESMA has proposed standardised reporting templates for delegation arrangements, specifying what information AIFMs must provide to their NCAs. The templates require information on each delegate, delegated function, jurisdictions, resources retained, and oversight mechanisms.

### ESMA Opinion on Delegation Thresholds

ESMA published an opinion on delegation thresholds — non-binding quantitative guidance indicating at what point delegation becomes so extensive that an AIFM risks letter-box entity status. While not directly part of AIFMD II, NCAs are expected to apply this opinion in assessing delegation arrangements.

## What Fund Managers Must Have Done by 16 April 2026

Regardless of the specific national transposition status in your jurisdiction, the following workstreams should be completed or substantially advanced by the April 16 deadline:

### 1. LMT Selection and Documentation

For every open-ended AIF you manage:
- Select at least two LMTs from the AIFMD II list
- Amend constitutional documents (fund rules, prospectus, articles) to embed the selected LMTs
- Draft or update investor disclosure language describing each LMT, its activation criteria, and its operational mechanism
- Prepare NCA notification procedures for when LMTs are activated
- Implement internal activation governance: who can authorise gate or swing pricing activation, and what documentation is required

**Critical point:** Selecting the LMTs is not sufficient — they must be legally embedded in the fund documentation. An LMT that exists only in internal policy is not compliant.

### 2. Delegation Oversight Enhancement

For every function you delegate:
- Prepare the information pack your home NCA will require on each delegation arrangement
- Review oversight resources: staffing, expertise, and time dedicated to delegate oversight
- Update internal delegation governance documentation
- Review delegation agreements for provisions on oversight rights and information access

If you delegate portfolio management to a non-EU entity, assess whether the oversight structure meets AIFMD II's enhanced standard, not merely the AIFMD I standard.

### 3. Loan Origination Compliance (if applicable)

For AIFs that originate loans:
- Implement 5% risk retention on loans sold on secondary markets
- Establish diversification limits (individual borrower concentration)
- Document lending policies covering credit assessment, approval, administration, and monitoring
- Verify that related-party lending prohibitions are reflected in investment guidelines and internal policies

### 4. Depositary Arrangements

Review whether the partial depositary passport creates any obligations or opportunities for your fund structures. For most managers, no action is required, but the review should be documented.

### 5. MiFID II Top-Up

For [AIFMs](/glossary/aifm) providing ancillary services (portfolio management, investment advice, custody):
- Review conduct-of-business requirements for ancillary services
- Ensure alignment with the revised standards in the amended AIFMD

## Frequently Asked Questions

## Implications for Tokenized Fund Structures

AIFMD II does not specifically address tokenization, but its provisions have direct implications for digital-native fund structures. Fund managers operating tokenised vehicles should also consider [MiCAR](/micar-compliance) classification for any crypto-asset components.

**RAIFs using DLT:** Luxembourg Reserved Alternative Investment Funds that use distributed ledger technology for unit issuance and transfer must comply with the same LMT requirements as any open-ended AIF. Smart contract-based redemption mechanisms need to accommodate gates, notice periods, or swing pricing — which requires careful technical design.

**Blockchain-based transfer agents:** If an AIFM uses a DLT-based transfer agent, the delegation framework applies. The transfer agent function is a critical operational function, and AIFMD II's enhanced reporting requirements extend to this arrangement.

**Digital-native depositaries:** The partial depositary passport may facilitate the emergence of specialised digital asset depositaries that serve funds across multiple jurisdictions — a development that could accelerate tokenized fund adoption.

---

## Frequently Asked Questions

**Our home jurisdiction has not transposed AIFMD II by April 16. Are we still required to comply?**

The April 16 deadline is a Member State obligation, not a directly applicable obligation on fund managers. If your home jurisdiction's national law is not in force, the technical legal position is that the AIFMD II requirements have not been incorporated into national law. However, NCAs may apply ESMA guidance in anticipation of transposition, and the delay does not remove the underlying regulatory expectation. Fund managers should implement regardless.

**Our UCITS management company also manages AIFs. Does AIFMD II apply to both activities?**

Yes. AIFMD II amends both the AIFMD and the UCITS Directive. LMT requirements apply to open-ended AIFs managed under the AIFMD and to UCITS managed under the UCITS Directive. You need to apply the LMT framework to both categories of fund.

**We manage closed-ended AIFs only. Do LMT requirements apply?**

No. The LMT requirements apply to open-ended AIFs (those that allow investors to redeem units or shares during the fund's life). Closed-ended AIFs — which are not redeemable during the fund's life — are not subject to the mandatory LMT selection requirement. However, loan origination and delegation requirements apply regardless of open/closed structure.

**Does AIFMD II affect marketing to non-EU investors?**

AIFMD II does not substantially change the third-country distribution framework. The National Private Placement Regimes (NPPRs) for marketing to non-EU investors remain in place. The changes primarily affect EU-authorised AIFMs managing or marketing to EU investors.

**We are a non-EU AIFM marketing into the EU under an NPPR. Does AIFMD II apply?**

AIFMD II's changes to the NPPR framework are limited. Non-EU AIFMs marketing into the EU under NPPRs continue to face national (rather than EU-harmonised) requirements. However, EU Member States may impose requirements inspired by AIFMD II on non-EU AIFMs, and you should review the NCA requirements in each distribution jurisdiction.

---

**Need to analyse your specific AIFMD II obligations?** financialregulations.eu gives you AI-powered analysis grounded in the full AIFMD II text, ESMA's Level 2 measures, and jurisdiction-specific guidance from AFM, BaFin, CSSF, CBI, and AMF.

[Analyse Your AIFMD II Obligations — Free →](/signup)

## Frequently Asked Questions

### What is the AIFMD II transposition deadline?

The deadline for EU member states to transpose AIFMD II (Directive (EU) 2024/927) into national law is 16 April 2026. This is the date by which each member state must have enacted the necessary legislative changes to their national laws — for example, Luxembourg's Bill of Law 8402, the Netherlands' Wft amendment, and Germany's KAGB amendment. Fund managers are expected to comply with the new requirements from this date regardless of whether their home state has formally completed transposition.

### What are the most important new requirements in AIFMD II for fund managers?

The most operationally demanding AIFMD II requirements are: (1) Liquidity Management Tools (LMTs) — all open-ended AIFs must have at least two LMTs available, with redemption in kind and side pockets restricted to exceptional use; (2) Loan origination framework — AIFs originating loans face concentration limits (20% single borrower for retail investors), risk retention (5%), and leverage caps; (3) Delegation oversight — AIFMs must demonstrate sufficient substance and cannot delegate portfolio management to the extent that they become letter-box entities; (4) Partial depositary passport — for the first time, the AIF and its depositary can be located in different member states.

### Which countries have completed AIFMD II transposition?

As of March 2026, transposition varies significantly across the major fund domiciles. Luxembourg advanced Bill of Law 8402 through the Chamber of Deputies with a targeted April 2026 enactment. The Netherlands published its draft Wft/Bgfo amendment for consultation. Germany is amending the KAGB with Bundestag approval expected before the deadline. Ireland's Central Bank published a supervisory guidance note, with formal legislation expected to follow the EU deadline closely. France has been less active publicly, relying on the Commission's directive to take direct effect where not transposed. Managers should not assume home-state delay provides any grace period for compliance.

---

# EU Financial Regulation Compliance Calendar 2026: Every Deadline Your Team Must Know

Source: https://financialregulations.eu/blog/eu-financial-regulation-deadlines-2026
Published: 2026-03-16
Last reviewed: 2026-03-19
Author: FinancialRegulations.EU Editorial Team
Tags: compliance, AIFMD, MiCAR, DORA, AI-Act, AML

> Complete EU financial regulation compliance calendar for 2026. AIFMD II (16 April), MiCAR CASP authorisation (1 July), AML Package (10 July), AI Act high-risk (2 August), ESG Ratings Regulation (2 July), and more.

The EU's regulatory calendar for 2026 is one of the most demanding in years. Four major frameworks reach critical implementation milestones — [AIFMD II](/blog/aifmd-ii-transposition-tracker-2026), [MiCAR](/micar-compliance), the AML Package, and the [AI Act](/blog/eu-ai-act-financial-services-guide) — while [DORA](/dora-compliance-checklist) enforcement moves from paper compliance to active supervisory testing. Understanding the exact deadlines and what they require of your organisation is not optional: missed deadlines carry authorisation risk, marketing restrictions, and direct supervisory action.

This compliance calendar covers every significant EU financial regulation deadline in 2026, with the applicable scope, obligations that crystallise at each date, and what you should already have in place.

## Why 2026 Is Particularly Demanding

Most EU regulatory cycles produce one or two major compliance events per year. 2026 is an exception. Several regulations that entered into force or began applying in 2023–2025 now hit their most operationally significant milestones — authorisation deadlines, transposition dates, and enforcement escalations — simultaneously:

- **[AIFMD II](/blog/aifmd-ii-transposition-tracker-2026)** national law transposition: 16 April 2026
- **[MiCAR](/micar-compliance)** transitional period ends ([CASP](/glossary/casp) authorisation or cessation): 1 July 2026
- **AML Package** ([AMLAR](/glossary/amla) + AMLD6) full application: 10 July 2026
- **ESG Ratings Regulation** applicability: 1 July 2026
- **[AI Act](/glossary/eu-ai-act)** high-risk AI system obligations: 2 August 2026

Simultaneously, **DORA** has moved from the implementation grace period (it applied from 17 January 2025) into active supervisory use — the first full year in which EU supervisors are running ICT risk inspections, testing incident reporting, and assessing third-party risk frameworks in practice. Firms that treated January 2025 as a "start now" date rather than a compliance date are running out of runway.

## Q1 2026: DORA Enforcement Accelerates

### DORA — ICT Risk Framework (Applied: 17 January 2025)

Although the Digital Operational Resilience Act (Regulation (EU) 2022/2554) entered into application on 17 January 2025, 2026 is the first year of active supervisory engagement. The European Supervisory Authorities (EBA, EIOPA, ESMA) published their supervisory priorities for 2026, explicitly identifying DORA implementation as a key focus. The Joint Examination Team (JET) framework for Critical [ICT Third-Party Providers](/glossary/ict-tpp) (CTPPs) begins active oversight during 2026.

**What must be in place (now):**

- **ICT risk management framework** — documented policies for identification, protection, detection, response, and recovery, aligned with the DORA RTS on ICT risk management tools, methods, processes, and policies (Commission Delegated Regulation (EU) 2024/1774)
- **Incident classification and reporting** — operational processes to classify ICT-related incidents against the thresholds in Commission Delegated Regulation (EU) 2024/1772, and to report major ICT incidents to competent authorities within prescribed timelines (initial notification within 4 hours; intermediate report within 72 hours; final report within one month). See our [DORA incident reporting timeline](/blog/dora-incident-reporting-timeline) and [incident classification guide](/blog/dora-incident-classification-guide).
- **Digital operational resilience testing** — basic testing for all in-scope entities; Threat-Led Penetration Testing (TLPT) for significant entities (at least every 3 years)
- **ICT third-party risk management** — a register of information on all ICT third-party service providers (CTPPs and others), maintained in standardised format for supervisory access; key contractual provisions in agreements with ICT providers covering security standards, audit rights, exit and termination clauses. See our [ICT register guide](/blog/dora-ict-third-party-register-guide).

**Who is in scope:** Credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers (under MiCAR), [AIFMs](/glossary/aifm), [UCITS](/glossary/ucits) management companies, insurance and reinsurance undertakings, insurance intermediaries, IORP pension funds, trade repositories, CCPs, CSDs, data reporting service providers, crowdfunding service providers, credit rating agencies, securitisation repositories, and ICT third-party service providers designated as critical.

For a deep dive into DORA's relationship with other cybersecurity frameworks, see our [DORA vs NIS2 comparison](/blog/dora-vs-nis2-comparison).

### EMIR 3 — Clearing Obligation Changes

The [EMIR](/glossary/emir) 3 reforms (Regulation (EU) 2024/2987) began phased application from late 2024 through 2026. Key 2026 milestones include the application of revised clearing thresholds and the continued implementation of active account requirements for systemically important counterparties. ESAs are publishing RTS and ITS under EMIR 3 on a rolling basis through 2026.

**Who is in scope:** Financial counterparties, non-financial counterparties above clearing thresholds, CCPs, and trade repositories.

---

<InlineCTA text="Need cited answers on EU financial regulation?" href="/signup" label="Try free analysis" />

## Q2 2026: AIFMD II — The Fund Manager Transformation

### AIFMD II — Transposition Deadline: 16 April 2026

The revised Alternative Investment Fund Managers Directive (Directive (EU) 2024/927, "AIFMD II") must be transposed into the national law of all EU Member States by **16 April 2026**. This is the most immediately pressing deadline on the 2026 calendar for fund managers, depositaries, and fund administrators.

AIFMD II is not a minor update. It fundamentally restructures several key aspects of the [AIFMD](/glossary/aifm) regime and introduces an entirely new framework for loan origination funds.

**Key changes that take effect from 16 April 2026:**

**1. Loan origination funds — new dedicated regime**

AIFMD II introduces a dedicated framework (new Articles 15a–15l of AIFMD) for AIFs that originate loans. Loan origination AIFs are subject to:
- Mandatory retention requirement: the AIFM or the AIF must retain a net economic interest of not less than 5% of the nominal value of each originated loan sold or transferred
- Portfolio concentration limit for closed-ended loan origination AIFs: the AIF may not lend more than 20% of its capital to a single borrower that is a financial undertaking, an AIF, or a UCITS
- Leverage limits for open-ended loan origination AIFs: total leverage must not exceed 175% of net asset value; for closed-ended loan origination AIFs, no numerical cap applies, but leverage must be disclosed

**2. Liquidity management tools ([LMTs](/glossary/lmt))**

AIFMD II mandates that all EU AIFMs managing open-ended AIFs must have at least two liquidity management tools from a defined menu (Annex V to AIFMD II) available in their fund constitutional documents. The selection must cover at least one from the "activation tools" category (e.g., redemption gates, suspension of redemptions, notice periods) and one from the "quantitative tools" category (e.g., swing pricing, redemption fees, anti-dilution levies). Depositors and side pockets are also recognised. For the full selection methodology and operational parameters, see our [AIFMD II Liquidity Management Tools guide](/blog/aifmd-ii-liquidity-management-tools-guide).

**3. Delegation arrangements — enhanced substance requirements**

AIFMD II imposes new requirements on AIFMs that delegate portfolio management or risk management functions. Delegation arrangements must be reviewed and, where necessary, updated to reflect:
- Mandatory disclosure in the fund prospectus/PPM of the list of delegated functions, the identity of all sub-delegates, and the measures taken to manage conflicts of interest
- Supervisory reporting: the revised Annex IV template includes new fields for delegation arrangements, including delegation to entities in third countries
- Competent authorities gain new powers to object to delegation arrangements where substance requirements are not met

**4. Depositary regime — conditional cross-border passporting**

AIFMD II introduces limited depositary passporting for EU jurisdictions that lack a sufficient domestic depositary market. This applies on a case-by-case basis, subject to ESMA approval and National Competent Authority consent. The full depositary passport (initially proposed by the Commission) was not included in the final text.

**5. New disclosure requirements**

AIFMs must update pre-investment and periodic disclosures to cover:
- Information on the sustainability-related aspects of the AIF's investment strategy (where applicable)
- Costs that are charged to the AIF and information on how AIFMs ensure fair treatment of investors

**Practical action:**

Most Member States should have published their national transposition acts. Verify that your jurisdiction's transposition is in force. Update fund documentation (constitutional documents, investment management agreements, PPMs) to reflect AIFMD II requirements. Reconfigure Annex IV reporting templates to include new data fields. For loan origination AIFs, verify retention structure and leverage compliance.

For full transposition status by jurisdiction, see our [AIFMD II transposition tracker](/blog/aifmd-ii-transposition-tracker-2026).

---

## Q3 2026: Crypto, AML, and ESG Ratings

### MiCAR — CASP Authorisation Deadline: 1 July 2026

**This is the most operationally critical deadline for crypto-asset service providers.**

Under the Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114), crypto-asset service providers ([CASPs](/glossary/casp)) that were operating under national law exemptions or [transitional arrangements](/glossary/micar-transition-period) must obtain MiCAR authorisation from their National Competent Authority (NCA) by **1 July 2026**, or cease providing crypto-asset services.

Article 143(3) of MiCAR provides the transitional regime: entities that were providing crypto-asset services in accordance with applicable national law before 30 December 2024 may continue to do so until 1 July 2026 (or such earlier date as the Member State specifies under Article 143(1)). After 1 July 2026, no transitional protection remains.

**Key MiCAR authorisation requirements (Article 63):**

- Legal entity established in the EU (relevant entity-type: investment firm, credit institution, CCP, CSD, UCITS management company, AIFM, or a newly licensed entity)
- Minimum capital: ranging from €50,000 (custody, reception/transmission) to €150,000 (exchange, portfolio management, advice, underwriting) depending on services provided
- Programme of operations, business plan, and governance documentation
- Fit and proper assessment of management body and qualifying shareholders
- Prudential safeguards: own funds, professional indemnity insurance, or a combination
- ICT risk management policies aligned with DORA
- Conflicts of interest policy, complaints handling, business continuity plan

**National deadlines may be earlier:** Several Member States (including France and The Netherlands) implemented MiCAR early or set earlier transitional deadlines. Check your NCA's published guidance.

**Scope of MiCAR CASP services (Article 3(1)(16)):**

Custody and administration of crypto-assets; operation of a trading platform; exchange of crypto-assets for funds or other crypto-assets; execution of orders; placing of crypto-assets; reception and transmission of orders; providing advice; providing transfer services.

See our [MiCAR CASP compliance checklist](/blog/micar-casp-compliance-checklist-2026) for full Article 63 requirements and application timelines, our [MiCAR whitepaper requirements guide](/blog/micar-whitepaper-requirements-checklist), and our [MiCAR vs MiFID II comparison](/blog/micar-vs-mifid-ii-comparison).

### ESG Ratings Regulation — Application Date: 2 July 2026

Regulation (EU) 2024/3005 on the transparency and integrity of environmental, social and governance (ESG) rating activities becomes applicable from **2 July 2026**.

From this date, ESG rating providers operating in the EU must be authorised by ESMA or, if from a third country, use the endorsement, recognition, or equivalence mechanisms. Investment firms, banks, and institutional investors that use ESG ratings in investment decisions or disclosures must verify that their ESG data providers are compliant.

**Impact on financial market participants:**

- Verify that ESG data providers used in [SFDR](/glossary/sfdr)-related disclosures, MiFID II sustainability preference assessments, or internal investment processes are authorised or compliant under the Regulation
- Contracts with ESG rating providers may need to be renegotiated to include new transparency requirements

### AML Package — Full Application: 10 July 2026

The EU's sixth Anti-Money Laundering Directive (AMLD6, Directive (EU) 2024/1640) and the directly applicable Anti-Money Laundering Regulation (AMLAR, Regulation (EU) 2024/1624) enter full application on **10 July 2026**.

The new AML framework significantly modernises EU AML/CFT requirements. Key changes affecting financial institutions:

**Directly applicable AML Regulation (AMLAR):**
- Uniform due diligence requirements across all Member States — no more national implementation variations
- New risk-based beneficial ownership verification standards
- Enhanced requirements for politically exposed persons (PEPs)
- New rules on high-value asset dealers (including crypto-asset service providers under MiCAR, which are obliged entities under AMLAR)
- Mandatory use of the EU AML/CFT Data Space for information sharing between obliged entities and FIUs (phased)

**AMLD6 — new supervisory architecture:**
- Establishment of the EU Anti-Money Laundering Authority ([AMLA](/glossary/amla)), headquartered in Frankfurt, with direct supervisory powers over high-risk obliged entities and coordination powers over national FIUs
- Enhanced powers for financial intelligence units
- New whistleblowing protections for AML compliance officers

**Who is in scope:** Credit institutions, financial institutions, payment institutions, crypto-asset service providers, investment firms, insurance companies, auditors, notaries, tax advisers, real estate agents, and dealers in high-value goods.

---

## Q4 2026: AI Act High-Risk Obligations

### AI Act — High-Risk AI System Requirements: 2 August 2026

The [EU Artificial Intelligence Act](/glossary/eu-ai-act) (Regulation (EU) 2024/1689) enters its most significant phase for financial services firms on **2 August 2026**, when the obligations for providers and deployers of [high-risk AI systems](/glossary/high-risk-ai-system) become applicable.

Financial services applications classified as high-risk under Annex III of the AI Act include:

- **Credit scoring systems** — AI systems used to assess the creditworthiness of natural persons or to evaluate credit risk
- **Life and health insurance pricing and underwriting systems** — AI used to determine eligibility, coverage, or pricing
- **AML/CFT transaction monitoring systems** — AI used to detect suspicious transactions or terrorist financing activities

**Obligations for providers of high-risk AI systems (Article 16):**

- **Conformity assessment** before placing the system on the market: verify compliance with the requirements in Chapter III, Section 2 (risk management, data governance, transparency, human oversight, robustness and accuracy)
- **Technical documentation** (Annex IV): maintain comprehensive technical documentation covering the system's intended purpose, design, validation, and monitoring
- **CE marking and EU Declaration of Conformity**: conformity assessment, registration in the EU AI database
- **Post-market monitoring**: continuous monitoring of system performance in production

**Obligations for deployers of high-risk AI systems (Article 26):**

- Use high-risk AI systems in accordance with the provider's instructions of use
- Implement human oversight measures — designate natural persons responsible for human oversight
- Where required, conduct a fundamental rights impact assessment before deploying the system
- Monitor operation of the AI system and report serious incidents or malfunctions to the provider and, if applicable, to competent authorities

**Practical steps for financial institutions:**

1. Maintain an inventory of all AI systems in use — classify each against Annex III
2. For each high-risk system: request technical documentation and EU Declaration of Conformity from vendors
3. Designate AI system deployer responsibilities (Article 26) — governance structures must be in place by 2 August 2026
4. Assess whether your credit scoring, AML screening, or underwriting AI meets the data governance requirements (Article 10) — training data must be representative, free from errors and complete, with appropriate data governance processes

For a complete analysis, see our [EU AI Act financial services guide](/blog/eu-ai-act-financial-services-guide).

---

## 2026–2027: Forward-Looking Milestones

### CRR III / CRD VI — Basel III Final Rules Phasing In (2025–2032)

[CRR III](/blog/crr-iii-crd-vi-guide) (Regulation (EU) 2024/1623) applies from **1 January 2025**. Several provisions are subject to phase-in schedules running through 2032:

- **Output floor**: 50% in 2025, scaling to 72.5% by 1 January 2030
- **Revised credit risk standardised approach (CRSA)**: applied from January 2025 — revised risk weights for real estate, infrastructure, SME exposures
- **FRTB (Fundamental Review of the Trading Book)**: application postponed to **1 January 2027** (Commission Delegated Act adopted June 2025)
- **CRD VI** (Directive (EU) 2024/1619): Member States must transpose and apply from **11 January 2026** — new fit and proper requirements, enhanced ESG risk management for credit institutions

See our [CRR III / CRD VI guide](/blog/crr-iii-crd-vi-guide) for detailed analysis.

### SFDR 2.0 — Legislative Proposal Published, Application 2028+

The European Commission published its proposal to revise [SFDR](/glossary/sfdr) (Commission Proposal, November 2025) as part of the Savings and Investments Union package. The proposal simplifies disclosures, reduces compliance burden, and addresses greenwashing risks associated with the informal use of Article 8 and Article 9 as product labels.

The legislative process (Council and Parliament negotiations, co-decision procedure) will continue through 2026 and into 2027. SFDR 2.0 is not expected to enter into application before 2028. The current SFDR framework — including Article 8 and Article 9 classification, RTS templates, and PAI disclosure requirements — remains fully in force.

See our [SFDR Article 8 vs Article 9 guide](/blog/sfdr-article-8-vs-article-9) for a detailed analysis of current obligations and our [SFDR 2.0 review guide](/blog/sfdr-2-0-review-guide) for what's changing.

### Solvency II Amendments — Application: 30 January 2027

Directive (EU) 2025/2 amending Solvency II (the long-term guarantee review) must be transposed by Member States before the 30 January 2027 application date. Key changes include recalibrated capital requirements for long-term equity investments, enhanced proportionality for smaller insurers, and updated sustainability requirements.

---

## Complete Deadline Reference Table

| Date | Regulation | Milestone | Who Is Affected |
|------|-----------|-----------|-----------------|
| Jan 2026 (ongoing) | [DORA](/dora-compliance-checklist) | Active supervisory inspections; JET oversight of CTPPs | All DORA in-scope entities |
| Jan 2026 (ongoing) | CRR III | Output floor 50%; revised CRSA applied | Credit institutions, investment firms |
| 11 Jan 2026 | CRD VI | Transposition and application date | Credit institutions, Member States |
| 16 Apr 2026 | [AIFMD II](/blog/aifmd-ii-transposition-tracker-2026) | National transposition deadline; new AIFM obligations take effect | AIFMs, depositaries, fund administrators |
| 1 Jul 2026 | [MiCAR](/micar-compliance) | Transitional period ends; CASP authorisation required | All crypto-asset service providers |
| 2 Jul 2026 | ESG Ratings Regulation | ESG rating providers must be authorised | ESG rating providers; investment firms using ESG ratings |
| 10 Jul 2026 | AML Package (AMLAR + AMLD6) | AMLAR directly applicable; AMLD6 fully transposed | All AML obliged entities |
| 2 Aug 2026 | [AI Act](/blog/eu-ai-act-financial-services-guide) | High-risk AI system obligations apply | AI providers and deployers in financial services |
| Late 2026 | [SFDR 2.0](/blog/sfdr-2-0-review-guide) | Expected legislative proposal, no application yet | All financial market participants |
| 1 Jan 2027 | CRR III / FRTB | FRTB market risk provisions apply | Credit institutions with significant trading books |
| 30 Jan 2027 | Solvency II (amended) | Revised framework applies | Insurance and reinsurance undertakings |

---

## How financialregulations.eu Can Help

Our platform gives you instant, source-backed answers on every regulation in this calendar — AIFMD II, MiCAR, DORA, the AML Package, the AI Act, CRR III, ESG Ratings Regulation, and SFDR. You can:

- **Ask specific questions:** What are the exact capital requirements for a MiCAR-authorised CASP providing custody services? Which AIFMD II Annex IV fields changed for delegation disclosures? What does the AI Act require for a credit scoring system deployed by a bank?
- **Review documents:** Upload your AIFMD II compliance gap assessment, MiCAR authorisation application draft, or DORA ICT policy and get it analysed against the regulatory text
- **Cross-reference:** Understand how regulations interact — DORA + MiCAR, AIFMD II + SFDR, AI Act + CRR III model risk

[Start with 5 free queries — no credit card required](/signup)

---

## Frequently Asked Questions

### What is the single most urgent deadline for fund managers in 2026?

The AIFMD II transposition deadline of 16 April 2026 is the most immediately pressing for alternative fund managers. From this date, Member States' national implementing legislation takes effect, and AIFMs must comply with the new AIFMD II requirements, including the loan origination fund regime, updated liquidity management tool requirements, enhanced delegation disclosures, and revised Annex IV reporting. Fund documentation must be updated before 16 April 2026.

### Does MiCAR's 1 July 2026 deadline apply to all crypto entities operating in the EU?

It applies to entities that have been relying on national transitional provisions to continue providing crypto-asset services without a MiCAR authorisation. Some Member States set earlier deadlines — for example, entities in France operating under the PSAN regime or in the Netherlands under DNB registration faced earlier cut-offs. The 1 July 2026 date is the EU-wide backstop. Entities that have not submitted a complete application to their NCA well in advance of this date face material authorisation risk.

### Is my firm in scope for DORA if we are an AIFM?

Yes. AIFMs authorised under AIFMD are explicitly listed in Article 2(1)(b) of DORA as in-scope financial entities. DORA applies to all ICT risk management, incident reporting, resilience testing, and third-party risk management activities of the AIFM. ICT vendors providing material ICT services to the AIFM are also subject to DORA's third-party risk requirements, regardless of where the vendor is located.

### What AI systems used in financial services are considered high-risk under the AI Act?

Annex III, point 5(b) of the AI Act identifies AI systems used for evaluating the creditworthiness of natural persons or their credit score as high-risk. Annex III, point 5(f) covers AI systems used in life and health insurance. ESMA has published guidance indicating that AI systems used for transaction monitoring (AML/CFT) and certain algorithmic trading systems may also fall within scope depending on their specific use. Firms should map all AI systems against Annex III and seek legal advice where classification is uncertain.

### When will SFDR 2.0 replace the current Article 8/Article 9 framework?

Not before 2028. The European Commission published its legislative proposal in November 2025. Co-decision between the Council and the European Parliament, followed by adoption and a transition period, means the earliest realistic application date is 2028. The current SFDR framework, including all Level 2 RTS disclosure templates, remains fully applicable in the interim. Firms should not delay current SFDR compliance on the expectation of forthcoming changes.

### Does CRR III require immediate changes to risk models?

CRR III has applied since 1 January 2025. Banks should have already transitioned to the revised CRSA for credit risk and updated their capital calculations accordingly. The output floor at 50% applies in 2025, with a phase-in to 72.5% by 2030. The FRTB provisions for market risk (Fundamental Review of the Trading Book) were postponed to 1 January 2027 by Commission Delegated Act in June 2025, giving banks with significant trading books additional time to implement internal model approaches.

## Frequently Asked Questions

### What are the most important EU financial regulation deadlines in 2026?

The major EU financial regulation deadlines in 2026 are: 16 April — AIFMD II national transposition deadline (liquidity management tools, loan origination, delegation rules); 1 July — MiCAR CASP transitional period expires (all crypto-asset service providers must hold full MiCAR authorisation); 2 July — ESG Ratings Regulation applies; 10 July — AML Package applies (new EU AML Authority, harmonised AML rules); 2 August — EU AI Act high-risk AI obligations apply (credit scoring, AML screening, insurance pricing); and Q4 2026 — CSRD third wave (large listed SMEs). Missing any of these deadlines can result in supervisory action, fines, or operational shutdown.

### Has the DORA compliance deadline already passed?

Yes. DORA (Digital Operational Resilience Act) applied from 17 January 2025. All in-scope financial entities — credit institutions, investment firms, insurance undertakings, CASPs, AIFMs, and others — were required to comply from that date. Key obligations already in force include ICT risk management frameworks, incident classification and reporting, third-party register maintenance, and DORA-aligned contractual requirements for ICT providers. The first ICT third-party register submission reference date was 31 March 2025.

### When must fund managers comply with AIFMD II?

Fund managers must comply with AIFMD II requirements from 16 April 2026 — the deadline for national transposition. In practice, AIFMs should be operationally ready before this date. The most time-sensitive requirements are the liquidity management tool (LMT) framework for all open-ended AIFs, which requires policy updates, board approvals, and prospectus amendments. Loan origination AIFs face concentration limits and risk retention rules. The partial depositary passport will only be available once both the AIF's home state and the depositary's home state have transposed the directive.

---

# DORA vs NIS2 for Financial Entities 2026 — Which Applies, Key Differences, Checklist

Source: https://financialregulations.eu/blog/dora-vs-nis2-comparison
Published: 2026-03-15
Last reviewed: 2026-03-24
Author: FinancialRegulations.EU Editorial Team
Tags: DORA, NIS2, cybersecurity, operational-resilience

> DORA vs NIS2: financial entities (banks, insurers, investment firms, CASPs) are subject to DORA — not NIS2. DORA is lex specialis: NIS2 Article 4 explicitly exempts in-scope financial entities. Side-by-side: incident reporting timelines (DORA 4h vs NIS2 24h), ICT third-party risk frameworks, penalty structures, and a checklist for entities in both regimes.

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) and the Network and Information Security Directive (NIS2, Directive (EU) 2022/2555) both address cybersecurity and digital resilience for entities operating in the EU. Both have applied since January 2025. Both impose governance obligations, incident reporting requirements, and risk management frameworks. And for financial institutions, both appear to apply simultaneously — creating a compliance question that cannot be ignored.

This article sets out the relationship between DORA and NIS2, explains where they overlap and diverge, and provides practical guidance for financial entities navigating dual compliance.

## Why the DORA vs NIS2 Question Matters

Before January 2025, cybersecurity regulation in the EU financial sector was fragmented. The original NIS Directive (Directive 2016/1148) covered some financial entities, but requirements were general and implementation varied across Member States. Financial sector-specific rules on ICT risk were scattered across sectoral legislation — CRD, MiFID II, Solvency II, PSD2 — without a unified framework.

The EU legislature addressed this with two instruments adopted within days of each other in late 2022:

- **DORA** (14 December 2022): A directly applicable regulation targeting digital operational resilience for the financial sector specifically.
- **NIS2** (27 December 2022): A directive replacing the original NIS Directive, broadening cybersecurity obligations across all critical sectors — including finance.

The result: financial entities now face two EU-level cybersecurity frameworks with overlapping subject matter but different legal instruments, different scopes, different enforcement mechanisms, and different levels of specificity. Understanding which framework applies — and how they interact — is essential for any compliance programme.

## DORA: Overview

### Scope

DORA applies to 21 categories of financial entities listed in Article 2(1), including credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, electronic money institutions, central counterparties, central securities depositories, trading venues, fund managers (both [UCITS](/glossary/ucits) and [AIFMs](/glossary/aifm)), [crypto-asset service providers](/glossary/casp), and ICT third-party service providers designated as critical by the European Supervisory Authorities (ESAs).

There is no size threshold. A boutique investment firm with ten employees and a global systemically important bank are both in scope. Proportionality applies to implementation (Article 4), not to scope. For a step-by-step overview of what DORA requires, see our [DORA compliance checklist](/dora-compliance-checklist).

### The Five Pillars

DORA is structured around five pillars:

1. **ICT Risk Management** (Articles 5-16): A comprehensive framework for identifying, protecting against, detecting, responding to, and recovering from ICT risks, with explicit management body responsibility.
2. **ICT-Related Incident Reporting** (Articles 17-23): Classification and reporting of major ICT-related incidents to competent authorities on defined timelines.
3. **Digital Operational Resilience Testing** (Articles 24-27): Basic testing for all entities and threat-led penetration testing ([TLPT](/glossary/tlpt)) for systemically important entities.
4. **ICT Third-Party Risk Management** (Articles 28-44): Contractual requirements for ICT service providers, a register of all ICT arrangements, and an oversight framework for critical ICT third-party providers.
5. **Information Sharing** (Article 45): Voluntary exchange of cyber threat intelligence among financial entities.

For fund managers specifically, see our guide on [DORA compliance for fund managers](/blog/dora-compliance-fund-managers).

### Legal Form

DORA is a regulation — directly applicable in all Member States without transposition. This means uniform requirements across the EU, without the implementation variations that characterise directives.

## NIS2: Overview

### Scope

NIS2 applies to entities operating in sectors listed in its Annexes I and II. Annex I ("sectors of high criticality") includes banking, financial market infrastructure, energy, transport, health, drinking water, digital infrastructure, ICT service management, public administration, and space. Annex II ("other critical sectors") includes postal services, waste management, chemicals, food, manufacturing, and digital providers.

Within these sectors, NIS2 distinguishes between **essential entities** and **important entities** based on size thresholds and criticality. Under Article 3, essential entities generally include large enterprises in Annex I sectors. Important entities include medium-sized enterprises in Annex I sectors and medium and large enterprises in Annex II sectors.

For the financial sector, credit institutions, operators of trading venues, and central counterparties are explicitly listed in Annex I. This means these entities fall within NIS2's scope as entities in a sector of high criticality.

### Key Obligations

NIS2 imposes on in-scope entities:

- **Cybersecurity risk management measures** (Article 21): Policies on risk analysis and information system security, incident handling, business continuity, supply chain security, security in network and information systems acquisition, asset management, access control policies, cryptography, human resources security, and multi-factor authentication.
- **Incident reporting** (Article 23): Notification to the national CSIRT or competent authority of significant incidents on specified timelines.
- **Management body accountability** (Article 20): Senior management must approve cybersecurity risk management measures and undergo cybersecurity training.
- **Supply chain security** (Article 21(2)(d)): Entities must address cybersecurity risks in their supply chains and supplier relationships.

### Legal Form

NIS2 is a directive. Member States were required to transpose it into national law by 17 October 2024. Implementation varies by jurisdiction — the Cyberbeveiligingswet in the [Netherlands](/jurisdictions/netherlands), the NIS-2-Umsetzungsgesetz in [Germany](/jurisdictions/germany), and equivalent legislation in other Member States. This creates a more heterogeneous compliance landscape than DORA.

## The Lex Specialis Relationship

This is the critical legal point. Article 4 of NIS2 states:

> Where sector-specific Union legal acts require essential or important entities to adopt cybersecurity risk management measures or to notify significant incidents, and where those requirements are **at least equivalent in effect** to the obligations laid down in this Directive, the relevant provisions of this Directive shall not apply to such entities.

Recital 28 of DORA explicitly references this principle:

> This Regulation constitutes lex specialis to [NIS2] with regard to the financial sector. It is essential to maintain a strong relationship between the financial sector and the Union horizontal cybersecurity framework as currently laid out in [NIS2].

The legal consequence is clear: **for financial entities in scope of DORA, DORA takes precedence over NIS2 on matters that DORA addresses**. Financial entities do not need to comply with NIS2's provisions on cybersecurity risk management and incident reporting to the extent that DORA already covers those obligations with equivalent or greater specificity.

This is not an exemption from NIS2. It is a lex specialis carve-out — DORA displaces NIS2 on overlapping matters because DORA's requirements are more specific and at least equivalent in effect. On matters that DORA does not address, NIS2 may still apply.

## Side-by-Side Comparison

| Dimension | DORA (Regulation 2022/2554) | NIS2 (Directive 2022/2555) |
|---|---|---|
| **Legal instrument** | Regulation (directly applicable) | Directive (requires national transposition) |
| **Application date** | 17 January 2025 | 18 October 2024 (transposition deadline) |
| **Scope** | 21 categories of financial entities (Article 2) | Entities in 18 critical and important sectors (Annexes I and II) |
| **Financial sector coverage** | Comprehensive: banks, insurers, investment firms, fund managers, payment institutions, [CASPs](/glossary/casp), CSDs, CCPs, trading venues | Limited to credit institutions, trading venues, CCPs |
| **Incident reporting** | Initial notification within 4 hours of classification / 24 hours of detection; intermediate report within 72 hours; final report within 1 month (Articles 17-19) | Early warning within 24 hours; incident notification within 72 hours; final report within 1 month (Article 23) |
| **Testing** | Mandatory basic testing for all; [TLPT](/glossary/tlpt) for systemically important entities (Articles 24-27) | No specific testing framework; general obligation to ensure effectiveness of measures |
| **Third-party risk** | Detailed contractual requirements (Article 30); register of ICT arrangements (Article 28(3)); oversight framework for critical ICT providers (Articles 31-44) | General supply chain security obligation (Article 21(2)(d)); no equivalent oversight framework |
| **Governance** | Management body bears ultimate responsibility for ICT risk; must define, approve, oversee, and be accountable for the ICT risk management framework (Article 5(2)) | Management body must approve and supervise cybersecurity risk management measures; personal liability for infringements (Article 20) |
| **Penalties** | Member State competent authorities may impose administrative penalties; no harmonised maximum fines in the regulation itself | Up to EUR 10 million or 2% of global annual turnover for essential entities; up to EUR 7 million or 1.4% of turnover for important entities (Article 34) |
| **Supervision** | National financial supervisors (ECB, BaFin, AFM, CSSF, etc.); ESA-led oversight for critical ICT providers | National cybersecurity authorities or CSIRTs |

## Where They Overlap

Both frameworks require:

- **Risk-based cybersecurity governance** with management body accountability
- **Incident reporting** to competent authorities, with multi-stage notification timelines
- **Business continuity and disaster recovery** planning
- **Supply chain / third-party risk management** as a core compliance obligation
- **Access control, encryption, and network security** as baseline technical measures
- **Regular review and updating** of policies and procedures

For a financial institution already compliant with DORA, much of NIS2's substantive content is already addressed — which is precisely why the lex specialis principle applies.

## Where They Diverge

The differences are material and worth understanding:

### 1. Specificity of Requirements

DORA is prescriptive. It specifies detailed requirements for ICT risk management frameworks, incident classification criteria, testing methodologies, contractual clauses with ICT providers, and the format of registers. NIS2 sets objectives and principles but leaves significantly more discretion to entities and Member States on implementation.

### 2. Third-Party Oversight

DORA creates an entirely new regulatory mechanism: direct oversight of critical ICT third-party providers by Lead Overseers appointed from among the ESAs (Articles 31-44). This means that major cloud providers, core banking system vendors, and other critical ICT suppliers to the financial sector are subject to direct regulatory scrutiny. NIS2 has no equivalent mechanism. The supervisory feed for that designation comes from financial entities' own [register of information requirements](/blog/dora-ict-third-party-register-guide) under Article 28(3) — the ESAs aggregate register data to identify which providers warrant CTPP designation.

### 3. Testing Requirements

DORA mandates specific testing obligations — vulnerability assessments, penetration testing, network security assessments, scenario-based testing — and requires threat-led penetration testing for certain entities (Article 26). NIS2 requires entities to evaluate the effectiveness of their cybersecurity risk management measures but does not prescribe specific testing methodologies.

### 4. Penalties

NIS2 sets harmonised maximum fines (Article 34): up to EUR 10 million or 2% of total worldwide annual turnover for essential entities. DORA does not set harmonised maximum fines at the EU level, leaving penalty frameworks to national competent authorities and existing financial services enforcement regimes.

<InlineCTA text="Check which cybersecurity framework applies to your financial institution" href="/signup" label="Analyse your obligations →" />

## Incident Reporting: A Detailed Comparison

Incident reporting timelines are one of the most operationally significant differences. Financial entities must understand which framework's timelines apply.

### DORA Incident Reporting (Articles 17-19)

Under DORA, financial entities must:

1. **Classify** ICT-related incidents based on criteria set out in Article 18 and the related RTS — including client impact, duration, geographical spread, data losses, criticality of services affected, and economic impact.
2. **Submit an initial notification** to the competent authority within **4 hours** of classifying an incident as major, and no later than **24 hours** after detection.
3. **Submit an intermediate report** within **72 hours** of the initial notification, providing updates on severity, impact, and initial root cause analysis.
4. **Submit a final report** within **one month** of the intermediate report, covering root cause, remediation actions, and lessons learned.

DORA also introduces voluntary notification of significant cyber threats (Article 19) and requires the ESAs to assess the feasibility of centralising incident reporting at EU level.

### NIS2 Incident Reporting (Article 23)

Under NIS2, in-scope entities must:

1. **Submit an early warning** within **24 hours** of becoming aware of a significant incident, indicating whether it is suspected to be caused by unlawful or malicious acts or could have a cross-border impact.
2. **Submit an incident notification** within **72 hours** of becoming aware, updating the early warning and providing an initial assessment of severity and impact.
3. **Submit a final report** within **one month** of the incident notification, including a detailed description, root cause, mitigation measures, and cross-border impact.

### Key Differences

DORA's timelines are tighter: 4 hours for the initial notification (vs. 24 hours under NIS2). DORA also requires a more detailed classification framework — the RTS on incident classification provides quantitative thresholds that create a standardised classification methodology across the financial sector. NIS2's "significant incident" concept is broader and less granularly defined.

For financial entities, DORA's incident reporting regime is the applicable one under the lex specialis principle. Meeting DORA's tighter timelines will, by definition, satisfy NIS2's requirements. For the full incident classification criteria, see our [DORA incident classification guide](/blog/dora-incident-classification-guide) and [incident reporting timeline](/blog/dora-incident-reporting-timeline).

## Third-Party ICT Risk: DORA's Oversight Framework vs NIS2's Supply Chain Provisions

Third-party ICT risk management is where DORA is most distinctive.

### DORA (Articles 28-44)

DORA requires financial entities to:

- Maintain a **[complete register](/blog/dora-ict-third-party-register-guide)** of all [ICT third-party](/glossary/ict-tpp) arrangements (Article 28(3)), in a format prescribed by the [ITS](/glossary/its), available to supervisors on request.
- Include **specific contractual provisions** in agreements with ICT providers (Article 30): service level descriptions, data processing locations, availability guarantees, access and audit rights for the entity and its competent authority, termination rights with transition periods, and provider cooperation during ICT incidents.
- Assess **ICT concentration risk** — evaluating whether critical business functions depend excessively on a single provider or a small group of providers.
- Conduct a **pre-contractual assessment** before entering into ICT arrangements, considering risks including substitutability and concentration.

Beyond entity-level requirements, DORA establishes an **oversight framework for critical ICT third-party service providers** (Articles 31-44). The ESAs can designate ICT providers as "critical" based on the systemic importance of the financial entities they serve, the degree of dependence, and the substitutability of the provider. Critical ICT providers are then subject to direct oversight by a Lead Overseer — one of the three ESAs — who can conduct inspections, issue recommendations, and impose penalty payments for non-compliance.

### NIS2 (Article 21(2)(d))

NIS2 requires entities to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Article 21(3) allows the European Commission to adopt implementing acts specifying technical and methodological requirements, but the level of prescriptive detail is significantly lower than DORA.

NIS2 does not create:
- A register of third-party arrangements
- Mandatory contractual clauses for ICT providers
- A direct oversight mechanism for critical suppliers
- An ICT concentration risk assessment framework

For financial entities, DORA's third-party risk framework is substantially more demanding — and is the one that must be implemented.

## Practical Implications: Dual Compliance Strategies

### Which Framework to Prioritise

If you are a financial entity in scope of DORA (Article 2(1)), prioritise DORA. The lex specialis relationship means DORA is your primary compliance framework for cybersecurity and digital operational resilience. Compliance with DORA should satisfy the equivalent NIS2 obligations.

However, do not ignore NIS2 entirely:

- **National transposition may create additional requirements.** Member States have some flexibility in how they transpose NIS2, and some may impose obligations on financial entities that go beyond or are adjacent to DORA's scope.
- **Group-level compliance.** If your group includes non-financial entities (e.g., a holding company, a technology subsidiary), those entities may be in scope of NIS2 independently. A unified group cybersecurity framework should account for both.
- **Supervisory coordination.** NIS2 requires cooperation between cybersecurity authorities and financial supervisors (Article 32(10)). Financial entities may receive requests or inquiries related to NIS2 compliance even where DORA is the primary framework.

### A Practical Compliance Approach

1. **Map your entities against both frameworks.** Determine which group entities fall under DORA, which under NIS2, and which under both.
2. **Implement DORA as the baseline.** For financial entities, DORA's requirements are more prescriptive and, if fully implemented, will cover NIS2's substantive obligations.
3. **Conduct a gap analysis against NIS2 national transposition.** Review the relevant national law in each jurisdiction where you operate to identify any obligations that DORA does not address.
4. **Align incident reporting procedures.** Ensure your incident response process meets DORA's tighter timelines (4 hours for initial notification). This will also satisfy NIS2.
5. **Coordinate across supervisors.** Be prepared for engagement from both financial supervisors (under DORA) and national cybersecurity authorities (under NIS2). Ensure your compliance function can respond to both.
6. **Document the lex specialis analysis.** Maintain an internal record of your assessment that DORA displaces NIS2 on specific obligations. This demonstrates regulatory awareness and supports your position in supervisory discussions.

## Penalties and Enforcement

### DORA

DORA does not set harmonised maximum fines at the EU level. Article 50 empowers Member State competent authorities to impose administrative penalties and remedial measures in accordance with national law. In practice, this means penalties are determined by existing national financial supervisory frameworks — which in many jurisdictions already include significant sanction powers.

For critical ICT third-party providers, the oversight framework allows Lead Overseers to impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover for each day of non-compliance, for a maximum of six months (Article 35(8)).

### NIS2

NIS2 sets explicit maximum fines (Article 34):

- **Essential entities:** Up to EUR 10,000,000 or 2% of total worldwide annual turnover, whichever is higher.
- **Important entities:** Up to EUR 7,000,000 or 1.4% of total worldwide annual turnover, whichever is higher.

NIS2 also introduces personal accountability: Article 20(1) requires Member States to ensure that management bodies of essential and important entities can be held liable for infringements. Some Member States have transposed this with provisions allowing temporary management bans.

### Practical Impact

For financial entities, the enforcement landscape is primarily shaped by DORA and existing financial supervisory powers. NIS2's penalty provisions are most relevant for non-financial entities in the group or for financial entities that are in scope of NIS2 but not DORA (an unlikely scenario for most financial institutions, but possible for entities at the boundary).

## How financialregulations.eu Can Help

Navigating the DORA-NIS2 intersection requires precise regulatory analysis. Our platform provides:

- **Full-text search and analysis** of both DORA and NIS2, including recitals, articles, and technical standards
- **Cross-reference queries** — ask how a specific DORA obligation relates to NIS2 provisions, and get an answer grounded in the regulatory text
- **Compliance gap analysis** — upload your current cybersecurity framework and get it assessed against DORA requirements
- **Regulatory monitoring** — track ESA guidance, RTS/ITS updates, and national transposition developments

---

**Try financialregulations.eu** — start with 5 free regulatory queries. No credit card required.

[Start Analysing — Free](/signup)

---

## Frequently Asked Questions

### Does NIS2 apply to banks and financial institutions?

Technically, yes. Credit institutions, operators of trading venues, and central counterparties are listed in NIS2 Annex I as entities in the banking and financial market infrastructure sectors. However, under the lex specialis principle in Article 4 of NIS2, DORA's requirements take precedence where they are at least equivalent in effect. In practice, financial institutions should implement DORA as their primary framework, which will satisfy the corresponding NIS2 obligations.

### Can a financial entity be sanctioned under both DORA and NIS2?

The lex specialis relationship is designed to prevent double regulation on the same subject matter. Where DORA addresses an obligation (e.g., incident reporting, risk management), NIS2's provisions do not apply to that entity on that matter. However, if a financial entity fails to comply with an obligation that falls outside DORA's scope but within NIS2's, national cybersecurity authorities could theoretically take enforcement action under NIS2 national transposition laws.

### Which incident reporting timeline applies to financial institutions — DORA or NIS2?

DORA's incident reporting regime applies. Financial entities must report major ICT-related incidents under Articles 17-19 of DORA: initial notification within 4 hours of classification (or 24 hours of detection), intermediate report within 72 hours, and final report within one month. These timelines are tighter than NIS2's 24-hour early warning and 72-hour notification requirements and are considered at least equivalent in effect.

### Do financial entities need to register under NIS2?

NIS2 requires certain entities to register with the competent authority or CSIRT (Article 3(3)). Whether financial entities already supervised under DORA need to separately register under NIS2 depends on national transposition. In most Member States, financial supervisors share relevant information with cybersecurity authorities, and separate registration may not be required. Check the specific national transposition in your jurisdiction.

### How does NIS2 affect ICT third-party providers serving financial institutions?

ICT third-party providers that serve financial institutions may themselves be in scope of NIS2 — particularly if they qualify as providers of managed ICT services (Annex I) or digital service providers (Annex II). This means they face their own NIS2 obligations (cybersecurity risk management, incident reporting) independently of their clients' DORA obligations. Under DORA, critical ICT third-party providers are also subject to the ESA-led oversight framework (Articles 31-44). The two regimes operate in parallel: NIS2 applies to the provider as an entity; DORA applies to the provider through the oversight framework and through contractual requirements imposed by their financial entity clients.

### Should I implement DORA and NIS2 as separate compliance workstreams?

No. For financial entities, the most efficient approach is to implement DORA as the comprehensive framework and then conduct a targeted gap analysis against NIS2 national transposition requirements. Creating parallel compliance workstreams leads to duplication, inconsistency, and unnecessary cost. A single cybersecurity governance framework that meets DORA's prescriptive requirements will, in most cases, satisfy NIS2's equivalent obligations. Document your lex specialis analysis and maintain it as a living record.

---

## Related DORA Guides

- [DORA compliance checklist](/dora-compliance-checklist) — interactive self-assessment across all five pillars of the Digital Operational Resilience Act
- [DORA for fund managers](/blog/dora-compliance-fund-managers) — what AIFMs and UCITS managers specifically need to do under DORA
- [DORA ICT third-party register](/blog/dora-ict-third-party-register-guide) — how to build, populate, and submit the Article 28(3) register
- [DORA incident reporting timeline](/blog/dora-incident-reporting-timeline) — the 4h/72h/1m reporting framework in detail
- [DORA incident classification](/blog/dora-incident-classification-guide) — criteria for classifying major ICT-related incidents under Articles 17-18
- [EU financial regulation deadlines 2026](/blog/eu-financial-regulation-deadlines-2026) — full compliance calendar including DORA, MiCAR, AIFMD II, and more

## Frequently Asked Questions

### Do financial institutions have to comply with both DORA and NIS2?

No. DORA operates as lex specialis for financial entities — where DORA applies, it takes precedence over NIS2. This is explicit in NIS2 Article 4(2), which states that if other EU law imposes security or incident notification requirements equivalent to NIS2, those apply instead. Financial entities covered by DORA (credit institutions, investment firms, payment institutions, CASPs, AIFMs, insurance undertakings, and others listed in DORA Article 2) are subject to DORA, not NIS2. However, entities that are in scope for NIS2 but not DORA — for example, certain fintech service providers not yet authorised under EU financial regulation — must comply with NIS2.

### How do DORA and NIS2 incident reporting timelines differ?

DORA incident reporting for major ICT incidents requires: initial notification within 4 hours of classification (maximum 24 hours from detection), intermediate report within 72 hours, and final report within 1 month. NIS2 incident reporting for significant incidents requires: early warning within 24 hours, incident notification within 72 hours, and final report within 1 month. In practice, DORA's 4-hour initial notification is the most demanding requirement for financial institutions — faster than anything NIS2 requires. Both frameworks use a three-stage reporting structure but with different templates, channels, and supervisory recipients.

### What is the key difference in third-party risk management between DORA and NIS2?

DORA has a substantially more detailed third-party ICT risk framework than NIS2. DORA requires financial entities to: maintain a register of all ICT third-party providers (using templates RT.01-RT.05); include mandatory contractual clauses in all ICT service agreements; conduct risk assessments before onboarding ICT providers supporting critical functions; and participate in the oversight of Critical Third-Party Providers (CTPPs) designated by the ESAs. NIS2 requires essential and important entities to manage supply chain security risks but does not prescribe the same level of contractual detail, register obligations, or supervisory involvement. For financial entities, DORA's ICT third-party framework is the relevant standard.

### What are the penalties for non-compliance with DORA vs NIS2?

NIS2 sets harmonised maximum fines: up to EUR 10 million or 2% of global annual turnover for essential entities, and EUR 7 million or 1.4% for important entities. DORA does not set EU-level maximum fines — penalties are determined by national financial supervisory authorities using existing enforcement powers. For critical ICT third-party providers under DORA, Lead Overseers can impose periodic penalty payments of up to 1% of average daily worldwide turnover per day of non-compliance, for up to six months. NIS2 also introduces personal management liability provisions that some Member States have transposed with temporary management bans.

### Does DORA or NIS2 apply to crypto-asset service providers (CASPs)?

CASPs authorised under MiCAR are explicitly listed in DORA Article 2(1) and are therefore subject to DORA, not NIS2, for cybersecurity and digital operational resilience obligations. This includes ICT risk management, incident reporting, third-party risk management, and resilience testing. CASPs that are not yet MiCAR-authorised but operate under national transitional regimes may fall under NIS2 if they qualify as digital service providers or managed ICT service providers under NIS2's annexes.

---

# EU AI Act: What Financial Services Firms Need to Know Before August 2026

Source: https://financialregulations.eu/blog/eu-ai-act-financial-services-guide
Published: 2026-03-17
Last reviewed: 2026-03-17
Author: FinancialRegulations.EU Editorial Team
Tags: AI-Act, compliance, DORA, MiFID-II, financial-services

> The EU AI Act's high-risk AI system obligations apply from 2 August 2026. Credit scoring, insurance pricing, and AML screening are explicitly covered. This guide covers the risk classification framework, the obligations for providers and deployers, the intersection with DORA and MiFID II, and a practical compliance checklist for financial institutions.

The EU Artificial Intelligence Act — Regulation (EU) 2024/1689 — is the world's first comprehensive legal framework for AI. It entered into force on 1 August 2024, and its most consequential provisions for financial services take effect on **2 August 2026**: the obligations for high-risk AI systems. For banks, insurers, investment firms, and fintechs deploying AI in credit scoring, fraud detection, AML screening, insurance pricing, or investment recommendations, this is a new compliance layer that operates alongside — and sometimes intersects with — [DORA](/dora-compliance-checklist), MiFID II, [SFDR](/blog/sfdr-article-8-vs-article-9), and Solvency II.

This guide covers the AI Act's structure, its specific impact on financial services, the high-risk obligations that apply from August 2026, and the intersection with existing financial regulation.

## The AI Act's [Risk-Based Architecture](/glossary/ai-act-risk-classification)

The AI Act classifies AI systems into four risk categories, each carrying different obligations:

### Unacceptable Risk (Prohibited — Article 5)

Certain AI practices are outright banned. These prohibitions applied from **2 February 2025** and include:

- **Social scoring** by public authorities — and by private entities where it leads to detrimental treatment unrelated to the context in which data was generated
- **Real-time remote biometric identification** in publicly accessible spaces for law enforcement (with narrow exceptions)
- **Emotion recognition** in the workplace and educational institutions
- **Manipulative AI** that exploits vulnerabilities of specific groups (age, disability, social or economic situation)
- **Untargeted scraping of facial images** from the internet or CCTV to build facial recognition databases

For financial institutions, the social scoring prohibition has direct relevance: AI systems that evaluate natural persons based on social behaviour or personal characteristics in ways leading to unfavourable treatment that is unjustified or disproportionate are prohibited. Credit scoring systems must be carefully designed to avoid crossing this line.

### [High Risk](/glossary/high-risk-ai-system) (Regulated — Articles 6-49)

This is where financial services is most affected. AI systems classified as [high-risk](/glossary/high-risk-ai-system) must comply with extensive requirements before being placed on the market or put into service. **These obligations apply from 2 August 2026.**

### Limited Risk (Transparency — Article 50)

AI systems that interact with natural persons (chatbots), generate synthetic content (deepfakes), or perform emotion recognition must disclose that fact. These transparency obligations applied from **2 August 2025**.

### Minimal Risk

AI systems not falling into the above categories are unregulated under the AI Act, though voluntary codes of conduct are encouraged.

## Why Financial Services Is High-Risk

Annex III of the AI Act lists the domains where AI systems are classified as high-risk under Article 6(2). **Point 5(b) of Annex III** explicitly covers financial services:

> AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud.

Additionally, **point 5(a)** covers:

> AI systems intended to be used for making decisions on access to or conditions of insurance products, including the risk assessment and pricing in relation to natural persons in the case of life and health insurance.

Beyond Annex III's explicit mentions, several other high-risk categories intersect with financial services:

- **Point 3(a):** AI systems used in education or vocational training that determine access — relevant for firms using AI in recruitment or professional certification
- **Point 4(a):** AI systems used for recruitment, CV screening, interview evaluation — banks and asset managers using AI hiring tools
- **Point 4(b):** AI systems for task allocation, performance monitoring, or termination decisions — workforce management AI in financial institutions
- **Point 8(a):** AI systems used by public authorities for eligibility assessment — relevant where financial institutions administer public programmes

### Financial AI Use Cases That Are High-Risk

| Use Case | Annex III Category | High-Risk? |
|---|---|---|
| Credit scoring / creditworthiness assessment | 5(b) | **Yes** |
| Insurance risk assessment and pricing (life/health) | 5(a) | **Yes** |
| AML/CFT transaction monitoring | Not explicitly listed | **See below** |
| Fraud detection | 5(b) exception | **Excluded** |
| Robo-advisory / investment recommendations | Not explicitly listed | **See below** |
| KYC/customer onboarding with biometric ID | Annex III point 1 | **Potentially** |
| AI-driven recruitment at financial firms | 4(a) | **Yes** |
| Algorithmic trading | Not listed | **No (but MiFID II applies)** |

**The AML screening question** is nuanced. The AI Act does not explicitly list AML transaction monitoring in Annex III. However, where AML systems make decisions that affect natural persons' access to financial services (e.g., automatic de-risking, account closure), they may be caught by the general provision in Annex III point 5(b) or by the broader fundamental rights impact assessment under Article 27. The European Commission and ESAs have not yet published definitive guidance on this boundary. Firms should treat material AML automation as potentially high-risk until clarified.

**Fraud detection is explicitly excluded** from the high-risk classification under point 5(b) of Annex III. The legislature recognised that fraud detection AI operates to protect users rather than making adverse decisions about them. However, where fraud detection systems lead to automatic account freezing or transaction blocking affecting individuals, firms should assess whether those downstream decisions cross back into high-risk territory.

<InlineCTA text="Need cited answers on EU financial regulation?" href="/signup" label="Try free analysis" />

## High-Risk AI System Obligations (August 2026)

From 2 August 2026, deployers and providers of high-risk AI systems must comply with the following requirements:

### 1. Risk Management System (Article 9)

A continuous, iterative risk management system must be established, documented, and maintained throughout the AI system's lifecycle. This includes:

- Identification and analysis of known and reasonably foreseeable risks
- Estimation and evaluation of risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse
- Adoption of appropriate risk management measures
- Testing to identify the most appropriate risk management measures

For financial institutions, this intersects directly with **[DORA's ICT risk management framework](/blog/dora-compliance-fund-managers)** (Articles 5-16). Firms will need to decide whether to integrate AI risk management into their DORA framework or maintain separate processes. The former is more efficient; the latter may be required where the risk profiles are sufficiently distinct.

### 2. Data Governance (Article 10)

Training, validation, and testing datasets must meet quality criteria:

- Relevant, sufficiently representative, and as free of errors as possible
- Appropriate statistical properties with regard to the persons or groups on which the system is intended to be used
- Examination for possible biases, especially where outputs influence decisions concerning natural persons

For credit scoring AI, this means documenting the representativeness of training data across demographic groups, testing for discriminatory outcomes, and maintaining data quality records. This is a significant operational undertaking for firms using legacy datasets.

### 3. Technical Documentation (Article 11)

Comprehensive technical documentation must be drawn up before the system is placed on the market or put into service, and kept up to date. This documentation must demonstrate compliance with all high-risk requirements and provide supervisory authorities with the information needed to assess compliance.

The documentation requirements are specified in Annex IV and include: a general description of the AI system, detailed description of elements and development process, monitoring and functioning information, risk management documentation, and a description of changes made throughout the lifecycle.

### 4. Record-Keeping and Logging (Article 12)

High-risk AI systems must be designed to automatically record events (logs) throughout their operational lifetime. Logs must enable:

- Traceability of the AI system's functioning
- Monitoring of the operation
- Post-market surveillance

Logging capabilities must be proportionate to the intended purpose and must, at minimum, record the period of use, the reference database against which input data was checked, input data for which the search led to a match, and identification of natural persons involved in the verification of results.

### 5. Transparency and Information to Deployers (Article 13)

High-risk AI systems must be designed to be sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. This includes:

- Clear information on the provider's identity and contact details
- The system's characteristics, capabilities, and limitations of performance
- Changes to the system and its performance pre-determined by the provider at the time of initial conformity assessment
- Human oversight measures
- Expected lifetime and necessary maintenance

For banks using third-party AI credit scoring models, this means the model provider must deliver sufficient documentation for the bank — as deployer — to understand what the model does, how it works, and what its limitations are. Black-box models will face acute compliance challenges.

### 6. Human Oversight (Article 14)

High-risk AI systems must be designed to allow effective oversight by natural persons during the period of use. Human oversight measures must:

- Enable the person to fully understand the capacities and limitations of the system
- Enable appropriate monitoring of the system's operation to detect anomalies, dysfunctions, and unexpected performance
- Enable the person to decide not to use the system, or to disregard, override, or reverse the output
- Enable the person to intervene or interrupt the system through a "stop" mechanism

This is particularly significant for **automated credit decisions**. The AI Act's human oversight requirements go beyond existing consumer credit law (CCD/MCD) "meaningful human involvement" standards and require that the human overseer can genuinely override the system — not merely rubber-stamp its outputs.

### 7. Accuracy, Robustness, and Cybersecurity (Article 15)

High-risk AI systems must achieve appropriate levels of accuracy, robustness, and cybersecurity. Accuracy metrics must be declared and made available to deployers. Robustness requirements include resilience to errors, faults, and attempts at manipulation by malicious third parties.

The cybersecurity dimension creates a direct bridge to **DORA**: financial entities' AI systems must meet both the AI Act's robustness/cybersecurity standards and DORA's ICT risk management requirements. This is not a contradiction — DORA's framework is more operationally detailed, while the AI Act adds AI-specific robustness requirements (adversarial attacks, data poisoning, model manipulation).

## The Provider vs Deployer Framework

The AI Act distinguishes between **providers** (entities that develop or commission AI systems) and **deployers** (entities that use AI systems under their authority). Financial institutions typically are deployers of AI systems provided by third-party vendors, but may also be providers where they develop proprietary AI models.

### If You Are a Deployer (Most Financial Institutions)

Article 26 imposes obligations on deployers of high-risk AI systems:

- Use the system in accordance with the provider's instructions of use
- Ensure that input data is relevant and sufficiently representative
- Monitor the operation based on the provider's instructions
- Keep logs automatically generated by the system for at least six months (or longer if required by sector-specific law)
- Perform a **fundamental rights impact assessment** (Article 27) before deployment, where the deployer is a financial institution or insurance undertaking — this is mandatory, not voluntary
- Inform natural persons that they are subject to the use of a high-risk AI system (where decisions affect them)
- Provide meaningful explanations of decisions taken on the basis of high-risk AI output, where those decisions produce legal effects or similarly significant effects on individuals

### If You Are a Provider (Developing Proprietary AI)

The obligations are more extensive: full compliance with Articles 8-15, conformity assessment (Article 43), EU declaration of conformity (Article 47), CE marking (Article 48), registration in the EU database (Article 49), post-market monitoring (Article 72), and serious incident reporting (Article 73).

**Important:** Under Article 25(1), a deployer that puts its name or trademark on a high-risk AI system, substantially modifies it, or changes its intended purpose **becomes a provider** and assumes all provider obligations. Financial institutions that customise or fine-tune third-party AI models should assess whether they have crossed the provider threshold.

## Intersection with Existing Financial Regulation

### AI Act + [DORA](/dora-compliance-checklist)

DORA governs [ICT](/glossary/ict-tpp) risk management, incident reporting, and third-party ICT oversight for financial entities. The AI Act adds AI-specific requirements on top. Key intersections:

| Domain | DORA | AI Act | Resolution |
|---|---|---|---|
| Risk management | ICT risk management framework (Arts 5-16) | AI risk management system (Art 9) | Integrate AI risk into DORA framework; add AI-specific risk assessments |
| Incident reporting | Major ICT incident reporting (Arts 17-23) | Serious incident reporting (Art 73) | Map AI-specific incidents to DORA classification criteria; report to both NCA and AI Act market surveillance authority if applicable |
| Third-party risk | ICT third-party risk management (Arts 28-44) | Provider obligations flow down to deployer (Art 26) | Extend DORA vendor due diligence to include AI Act compliance evidence from AI providers |
| Testing | Digital operational resilience testing (Arts 24-27) | Accuracy and robustness testing (Art 15) | Add AI-specific test scenarios (adversarial attacks, bias testing) to DORA testing programme |
| Cybersecurity | ICT security requirements throughout DORA | Cybersecurity requirements (Art 15) | DORA framework satisfies AI Act cybersecurity requirements in most cases |

### AI Act + MiFID II

MiFID II already imposes requirements on algorithmic trading (Article 17) and product governance (Articles 16(3), 24). The AI Act adds:

- Where AI is used in suitability assessments (Article 25 MiFID II), the transparency and human oversight requirements of the AI Act apply on top
- AI-driven order execution systems must meet both MiFID II best execution requirements and AI Act robustness standards
- Product governance processes using AI for target market assessment must comply with AI Act data governance requirements

### AI Act + [SFDR](/blog/sfdr-article-8-vs-article-9) / Taxonomy Regulation

Where AI is used to produce sustainability metrics, ESG scores, or taxonomy alignment assessments:

- The AI system's data governance requirements (Article 10) intersect with SFDR's data quality expectations for [PAI](/glossary/pai) disclosures
- Transparency requirements (Article 13) support SFDR's broader disclosure regime
- Firms should document how AI-derived ESG metrics are produced and what their limitations are

### AI Act + Consumer Credit Directive / Mortgage Credit Directive

Automated creditworthiness assessments under the Consumer Credit Directive (Directive 2008/48/EC) and Mortgage Credit Directive (Directive 2014/17/EU) already require meaningful human involvement. The AI Act's human oversight requirements (Article 14) and the right to meaningful explanation of AI-based decisions add specific technical and process requirements on top of existing consumer credit law.

## Timeline: What Financial Institutions Must Do and When

| Date | Milestone | Financial Services Impact |
|---|---|---|
| **1 August 2024** | AI Act enters into force | Start planning; establish AI governance team |
| **2 February 2025** | Prohibited AI practices apply; AI literacy obligation (Article 4) | Review AI portfolio against Article 5 prohibitions; ensure staff AI literacy programmes |
| **2 August 2025** | GPAI model obligations (Chapter V); transparency obligations for limited-risk AI (Article 50) | Chatbots, synthetic content generators must disclose AI nature; GPAI providers must comply |
| **2 February 2026** | Member States designate competent authorities and notified bodies | Identify your national AI Act authority (may be NCA, may be separate body) |
| **2 August 2026** | **High-risk AI system obligations apply** | Full compliance with Articles 6-49 for all high-risk AI systems in Annex III |
| **2 August 2027** | Obligations for high-risk AI systems that are also safety components of products in Annex I | Limited additional impact for pure financial services firms |

### Preparation Checklist for August 2026

**Immediate (Q1-Q2 2026):**

1. **AI inventory:** Map all AI systems in use across the organisation. Classify each as prohibited, high-risk, limited-risk, or minimal-risk under the AI Act framework
2. **Gap assessment:** For each high-risk system, assess current compliance against Articles 8-15 requirements
3. **Provider engagement:** For third-party AI systems, engage vendors on their AI Act compliance roadmap — request technical documentation (Annex IV), conformity declarations, and CE marking timelines
4. **Fundamental rights impact assessment:** For credit scoring, insurance pricing, and other Annex III point 5 systems, begin the Article 27 FRIA process

**Pre-deadline (Q2-Q3 2026):**

5. **Risk management integration:** Integrate AI risk management into existing DORA ICT risk framework or establish parallel AI risk management system
6. **Data governance:** Document training data provenance, representativeness, and bias testing for all high-risk AI systems
7. **Human oversight:** Ensure genuine human oversight capability for all high-risk AI decision-making processes — not just a theoretical override, but operationally effective intervention
8. **Logging and monitoring:** Verify that high-risk AI systems generate compliant automatic logs and that log retention meets the six-month minimum
9. **Transparency documentation:** Ensure deployer-facing documentation from AI providers meets Article 13 requirements

**Ongoing:**

10. **Post-market monitoring:** Establish continuous monitoring processes for high-risk AI system performance, accuracy drift, and bias emergence
11. **Incident procedures:** Define what constitutes a "serious incident" under Article 73 and integrate reporting procedures with DORA incident reporting
12. **Governance:** Assign clear accountability for AI Act compliance — this may sit with the same governance function responsible for DORA, or with a dedicated AI governance role

## Enforcement and Penalties

The AI Act establishes a tiered penalty structure:

- **Prohibited AI systems:** Up to EUR 35 million or 7% of total worldwide annual turnover (whichever is higher)
- **High-risk AI system non-compliance:** Up to EUR 15 million or 3% of total worldwide annual turnover
- **Incorrect information to authorities:** Up to EUR 7.5 million or 1% of total worldwide annual turnover

For financial institutions already subject to MiFID II, CRD, DORA, and sectoral penalty regimes, the AI Act adds another potential enforcement layer. National competent authorities designated under Article 70 will be responsible for market surveillance and enforcement — which national authority this is varies by Member State and may not be the financial supervisor.

## What This Means in Practice

The EU AI Act does not exist in a regulatory vacuum. For financial institutions, it adds a new compliance dimension to AI systems that are already subject to sectoral regulation. The practical challenge is integration: building AI governance that satisfies the AI Act's requirements without duplicating what DORA, MiFID II, and existing supervisory expectations already demand.

The firms that will navigate this most efficiently are those that:

1. **Start with an inventory.** You cannot comply with the AI Act if you do not know what AI systems you have. Shadow AI — models deployed by business units without central oversight — is the biggest compliance risk.
2. **Treat the AI Act as an extension of DORA, not a separate regime.** The risk management, testing, incident reporting, and third-party oversight requirements overlap significantly. Build one integrated framework.
3. **Engage providers now.** If you are a deployer, your compliance depends heavily on your AI providers. Providers that cannot deliver Annex IV technical documentation or demonstrate conformity assessment by August 2026 put your compliance at risk.
4. **Do not underestimate the fundamental rights impact assessment.** Article 27 requires financial institutions to assess the impact of high-risk AI on fundamental rights before deployment. This is a new requirement with no direct precedent in financial regulation, and the methodology is still being developed. Starting early is essential.

The August 2026 deadline is less than five months away. The time to act is now.

## Frequently Asked Questions

### Which AI systems in financial services are classified as high-risk under the EU AI Act?

Annex III of the EU AI Act explicitly classifies two AI use cases in financial services as high-risk: (1) AI systems for creditworthiness assessment or credit scoring of natural persons (Point 5(b)), and (2) AI systems for risk assessment and pricing of life insurance and health insurance (Point 5(a)). In practice, this extends to AML screening models, fraud detection systems that affect account access, and automated investment suitability assessments — because these systems make or substantially influence decisions affecting access to financial services. AI systems used purely for fraud detection (not creditworthiness) may fall under a specific carve-out.

### What must financial institutions do before 2 August 2026 for the EU AI Act?

By 2 August 2026, providers and deployers of high-risk AI systems in financial services must: (1) implement a documented risk management system (Article 9) covering risks throughout the AI system lifecycle; (2) establish data governance measures ensuring training data quality and representativeness; (3) produce technical documentation meeting Annex IV requirements; (4) implement automatic logging of events; (5) ensure appropriate human oversight mechanisms are built into the system; (6) complete a conformity assessment; and (7) register the system in the EU AI Act database. Deployers (not just developers) have separate obligations including fundamental rights impact assessments for credit scoring systems.

### How does the EU AI Act interact with DORA for financial institutions?

The EU AI Act and DORA create overlapping but distinct obligations for AI systems in financial services. DORA requires AI systems used for critical or important functions to be subject to the ICT risk management framework — including testing, incident reporting, and third-party risk management if the AI is provided by an ICT third party. The EU AI Act adds AI-specific requirements: risk management, data governance, logging, and human oversight. A credit scoring model hosted by a third-party cloud provider is therefore subject to both DORA's ICT third-party risk requirements and the AI Act's high-risk AI obligations. The AI Act explicitly provides derogations for financial institutions on quality management systems and monitoring obligations where equivalent requirements already exist under financial services law.