The Register of Information is the most data-intensive requirement under DORA. It is also the one that most entities struggle with. In the ESA dry run exercise, only 6.5% of submissions passed all validation checks. In France, only 39% of submissions could be processed at the European level.
This guide explains what the register requires, what goes wrong, and how to prepare for the 2026 submission.
What the Register of Information is
Article 28(3) of DORA requires every in-scope financial entity to maintain a register of all contractual arrangements for ICT services provided by third-party providers. This register must be kept up to date, available at entity, sub-consolidated, and consolidated levels, and submitted annually to your NCA.
The format is defined by Commission Implementing Regulation (EU) 2024/2956, commonly called the ITS. It specifies 15 interconnected templates with approximately 200 data fields, submitted as xBRL-CSV files.
This is not a spreadsheet you fill in once. It is a structured dataset that maps every ICT service arrangement to the providers delivering it, the business functions it supports, the entities consuming it, and the sub-contracting chains behind it.
The 15 templates
The register is organised into 8 groups:
Group 1 — Entity identification- B_01.01 — The entity maintaining the register. LEI, name, type, country, competent authority.
- B_01.02 — Entities within scope. For groups: all subsidiaries and their hierarchy. Each entity links to its direct parent via LEI.
- B_01.03 — Branches. Linked to the head office in B_01.02.
- B_02.01 — General information. This is the central hub of the register. Every contract has a unique reference number, type (standalone, master agreement, or sub-arrangement), start and end dates, governing law, and notice period.
- B_02.02 — Specific information. Maps contracts to the ICT services delivered, data storage and processing locations, and data sensitivity classification. Fields 0130, 0150, and 0160 are mandatory and use closed drop-down values from the EBA taxonomy.
- B_02.03 — Intra-group contractual arrangements.
- B_03.01 — Financial entity signatories.
- B_03.02 — ICT provider signatories.
- B_03.03 — Entities signing intra-group agreements.
- B_04.01 — Entities consuming ICT services, including from internal providers.
- B_05.01 — Provider master list. Every direct provider, internal provider, sub-contractor, and ultimate parent company. This is the single source of truth for provider identification (LEI or EUID).
- B_05.02 — ICT service chain. Ranks providers by their position in the sub-outsourcing chain for each service.
- B_06.01 — Function identification. Each function is a unique combination of entity, licensed activity, and function name. The critical/important classification here cascades throughout the register.
- B_07.01 — Assessments of ICT services supporting critical or important functions. Substitutability, last audit date, exit plan status, recovery capability, disruption impact, alternative provider availability.
- B_99.01 — Entity-specific definitions.
All 15 templates are linked by contract reference numbers, entity LEIs, provider identifiers, function identifiers, and ICT service types. B_02.01 is the hub. A contract that exists in B_02.01 without a corresponding service in B_02.02 is an orphan record and fails validation.
What must be included
- All ICT service agreements — not just those supporting critical functions. Every contract with an ICT third-party provider is in scope.
- Critical/important functions: the full sub-outsourcing chain (all tiers) must be documented.
- Non-critical functions: only the direct provider is required.
- Intra-group arrangements are in scope.
- Non-EU providers serving EU financial entities are in scope.
The validation rules
The EBA applies three layers of validation.
Layer 1 — Technical integration
This is the gatekeeper. It checks the ZIP package naming, xBRL-CSV structure, folder layout, and UTF-8 encoding. If this fails, the submission is rejected immediately.
The ZIP must contain a root folder matching the ZIP filename exactly, with two subfolders: reports/ and META-INF/. The parameters.csv file must use the rs: prefix before the entity LEI.
Layer 2 — Data Point Model validation
Checks unique identifier formatting, field types (integer fields reject floating-point values; dates must be YYYY-MM-DD), and coded values (must match EBA taxonomy codes, not free text).
Layer 3 — Business checks
Relational integrity across templates, LEI validation against the GLEIF database, conditional field logic, and logical consistency. A provider referenced in B_02.01 must exist in B_05.01. A function referenced in B_02.02 must exist in B_06.01.
The dry run results
The ESA dry run in 2024 tested 1,039 financial entities across Europe:
- 92 submissions failed Layer 1 immediately (bad file structure)
- Of the 947 accepted for analysis, only 6.5% passed all 116 checks
- 50% of the remaining registers failed fewer than 5 checks
- 86% of all errors were missing mandatory information
- Most common failure: missing identification codes for ICT providers and their parent undertakings
- Second most common: invalid LEI codes
- Third most common: free text in fields that require EBA coded values
The errors that keep failing
Based on EBA observations from the 2025 reporting cycle and NCA feedback:
Error 807 — Foreign key violation. A reference in one template points to a record that does not exist in another. This is the most structurally damaging error because it means your templates are not linked correctly. It causes rejection. Error 805 — Primary key missing. A required unique identifier is absent. Causes rejection. Error 808 — Filing indicators wrong. Every filing indicator must be set totrue. Wrong case or missing values cause rejection.
Error 720 — Non-DORA files in submission. Extra files or incorrectly named files in the ZIP. Causes rejection.
Error 306 — Not UTF-8 encoded. Editing CSV files in Excel on Windows often changes the encoding. Causes rejection.
Error 305 — Numeric field contains text. Empty mandatory numeric fields or fields with currency symbols. Flagged.
LEI validation failures (VR_71, VR_23, VR_12, VR_77). Invalid LEI format, LEI not found in GLEIF database, or lapsed LEI status. Flagged in 2025 — expected to cause rejection in 2026 as NCAs tighten checks.
What NCAs are saying about failures
France — ACPR
84% of entities submitted via OneGate, but only 39% of those could be processed at the European level. Contributing factors: a tight timeline and validation rules that were modified during the submission period. The ACPR took an educational approach in 2025 but has stated it will intensify monitoring in 2026.
Germany — BaFin
46% of German financial entities named the Register of Information as the hardest DORA requirement (Deloitte research). Compliance costs are estimated at EUR 2–5 million per institution. BaFin provided an Excel template for smaller entities, but it is Windows-only, macro-dependent, and reaches its limits with large data volumes. BaFin also flagged a double reporting burden: ICT services for critical functions often also qualify as material outsourcing under existing regulations (KWG/VAG/ZAG).
Netherlands — DNB
The first submission round in April 2025 was accepted with issues. Institutions had until late May to resolve all unsatisfied validation results and resubmit. DNB accepts both xBRL-CSV and a standardised Excel format (which DNB converts internally). For 2026, the deadline is earlier (20 March) and expectations are higher.
Luxembourg — CSSF
The CSSF opened its 2026 submission window on 11 February — the earliest in Europe. It explicitly warned that validation checks in 2026 apply to more data fields than in 2025. A register that was accepted last year may be rejected this year. The CSSF recommends submitting early to allow time for error correction before the 31 March deadline.
Ireland — Central Bank of Ireland
The CBI published the most detailed error guide of any NCA: "Guide to Addressing DORA Register EBA Feedback File Errors." Key warnings:
- Do not edit CSV templates in Excel — it auto-corrupts date formats and encoding
- Use a text editor (Notepad or equivalent) for CSV edits
- Ensure the
rs:prefix appears before the LEI inparameters.csv - No currency symbols in CSV fields
- Warnings that pass the CBI may still fail at the EBA level — the two authorities do not always assess edge cases the same way
Sweden — Finansinspektionen
FI required the first submission in March 2025 and issued technical guidance in May after entities struggled with group-wide data consolidation and scoping what counts as an "ICT service." FI has a test submission environment available through its FIDAC portal.
Denmark — Danish FSA
The Danish FSA has transitioned from the FIONA reporting system to a new e-Reg system specifically because FIONA cannot handle xBRL-CSV format. The RoI is one of the first reports in the new system, which means entities need to register for access and familiarise themselves with a new portal.
2026 submission deadlines
| Country | NCA | Deadline | Portal |
|---|---|---|---|
| Luxembourg | CSSF | 11 Feb – 31 Mar | eDesk |
| Sweden | FI | 28 Feb | FIDAC |
| Norway | Finanstilsynet | 13 Mar | eReg |
| Germany | BaFin | 9–30 Mar | MVP |
| Netherlands | DNB | 20 Mar | MyDNB |
| Netherlands | AFM | 22 Mar | AFM portal |
| Ireland | CBI | 2–31 Mar | CBI portal |
| Denmark | Danish FSA | 31 Mar | e-Reg |
| Finland | FIN-FSA | 31 Mar | FIN-FSA portal |
| France | ACPR | Apr (TBC) | OneGate |
| ESAs | EBA/ESMA/EIOPA | NCAs to ESAs by 31 Mar | Euclid |
Reference date for all 2026 submissions: 31 December 2025.
The 10 most common mistakes
- Editing CSV files in Excel. Excel changes date formats (DD/MM/YYYY instead of YYYY-MM-DD), strips leading zeros, and corrupts UTF-8 encoding. Use a text editor or a dedicated conversion tool.
- Free text in coded fields. Fields like ICT service type, data sensitivity, and country must use EBA taxonomy codes or ISO standards. "Germany" fails; "DE" passes.
- Inconsistent contract reference numbers. The contract reference in B_02.01 must match exactly in B_02.02, B_03.01, B_03.02, and B_04.01. A single typo creates orphan records.
- Invalid LEIs. Every entity and provider needs a valid, active LEI checked against the GLEIF database. Lapsed LEIs were tolerated in 2025 — expect stricter enforcement in 2026. If a provider has both an EUID and LEI, both must be reported.
- Missing sub-outsourcing chains. For every ICT service supporting a critical or important function, you must document the full chain of sub-contractors in B_05.02. Most entities only report the direct provider.
- Orphan records. A contract in B_02.01 without a service in B_02.02, or a function in B_06.01 not referenced by any contract. Cross-table integrity is checked automatically.
- Classifying everything as non-critical. If no functions are marked critical or important, it will not withstand supervisory scrutiny. The classification in B_06.01 must reflect your actual business impact assessment.
- Floating-point values in integer fields. The value 200.5 is rejected. Use 200 or 201.
- Missing filing indicators. Every filing indicator must be
true. Wrong case (True,TRUE) or missing values cause rejection.
- Treating it as a one-time exercise. The register must be maintained continuously and updated whenever arrangements change. The annual submission is a snapshot, but the underlying data must be current.
How to prepare for the 2026 submission
Now (immediately):- If you submitted in 2025, review the validation feedback you received. Fix every flagged item, not just the rejections.
- Validate all LEIs against gleif.org. Renew any that have lapsed.
- Review your function classification in B_06.01. Is the critical/important designation defensible?
- Collect updated contract and provider information. Contact rank-1 suppliers for sub-contractor data.
- Reconcile contract reference numbers across all templates.
- Run an internal cross-table consistency check before converting to xBRL-CSV.
- Convert to xBRL-CSV format and run validation. Several NCAs offer test environments (Sweden's FIDAC, Luxembourg's eDesk).
- Submit early. Every NCA recommends this — you will have time to fix errors before the hard deadline.
- Monitor for NCA feedback. Some NCAs (DNB, CBI) provide a correction window.
- Note that a submission passing your NCA may still fail at the ESA level. The two-tier process means you may receive additional feedback after the NCA deadline.
Tools
- DORA GRC Platform — Register of Information with EBA 85-rule validation engine, automated cross-table integrity checks, and xBRL-CSV export
- Free DORA Gap Analysis — assess your compliance maturity in 3 minutes
- DORA Compliance Checklist Template — 95 items across all five pillars
- What Financial Supervisors Are Targeting in DORA Audits — country-by-country NCA supervision priorities for 2026