Register of Information in xBRL-CSV: stop submitting Excel
The Register of Information is the most concrete deliverable DORA asks of a financial entity, and the one most teams underestimate. The format is xBRL-CSV, not Excel. In the EBA dry-run for the April 2025 submission, around 94% of Excel-based files were rejected on technical grounds. Here's why, and how to produce one that actually validates.
What the Register of Information is
Article 28 of DORA requires every financial entity to maintain a comprehensive register of all contractual arrangements with ICT third-party service providers. The register lists who you contract with, what they do, where data is processed, whether the function is critical or important, what the substitutability looks like, who their sub-contractors are.
Once a year — by 30 April for most entities — this register is submitted to the national competent authority (Central Bank of Ireland, BaFin, AMF, AFM, and so on), in a structured machine-readable format defined by the European Supervisory Authorities. That format is xBRL-CSV.
Why Excel doesn't work
The EBA does not accept your spreadsheet. The reason is not bureaucratic stubbornness — it's that supervisors across 27 member states need to aggregate, query and cross-validate tens of thousands of registers. A spreadsheet is unreliable for this: free-text fields, ambiguous date formats, locale-specific decimal separators, merged cells, and no enforced relationships between rows.
xBRL-CSV solves these problems by anchoring every value to a formally defined concept in a taxonomy. The EBA publishes the taxonomy (currently version 4.0) as a set of XSD and XML schema files. Your data is then expressed as CSV tables that point at concepts in that taxonomy, packaged in a ZIP with a report metadata file.
xBRL-CSV is, despite the name, not a CSV file. It is a ZIP package containing several CSV tables, a JSON metadata file, and references to a remote taxonomy. Opening one in Excel will show you the raw rows but tell you nothing about whether it will validate.
What goes into a valid RoI
The EBA Implementing Technical Standard defines 15 templates (B_01.01 through B_07.01 in their numbering), each capturing a different aspect of the third-party landscape:
| Template | What it captures |
|---|---|
| B_01.01 | Entity maintaining the register, group structure, contact point. |
| B_02.01–B_02.03 | Contractual arrangements with ICT providers, including contract reference, currency, annual cost. |
| B_03.01–B_03.03 | ICT services covered by the contract, function supported, substitutability, criticality assessment. |
| B_04.01 | ICT third-party providers themselves — legal name, LEI, country, type of provider. |
| B_05.01–B_05.02 | ICT third-party providers signing the contract, relationships between providers (sub-outsourcing). |
| B_06.01 | Functions of the entity supported by ICT services, with criticality. |
| B_07.01 | Assessment of the ICT services supporting critical or important functions. |
Each row in each table is constrained by data types (LEI must be 20 characters, ISO country codes only, ISO 4217 currency codes, ISO 8601 dates), by enumerations (function types are from a fixed list), and by cross-table relationships (a contract in B_02 must reference a provider in B_04).
The two failure modes
Submissions get rejected for two distinct reasons:
1. Technical validation failure
Wrong file structure, broken cross-references, invalid data types, missing mandatory fields. The EBA uses the open-source Arelle XBRL processor against the official taxonomy. If your file doesn't pass Arelle, it doesn't reach a human. This is what killed most of the dry-run submissions — well-intentioned Excel exports that looked correct but failed the XBRL formula checks.
2. Substantive review
The file validates, but the supervisor flags inconsistencies: a critical function with no exit plan, a sub-outsourcing chain that hits a known unreliable provider, missing notification of a previously declared contract. This is the second wave and is handled in correspondence with the supervisor over the weeks after submission.
The minimum viable workflow
You do not need an enterprise XBRL suite to submit. A working process for a small entity:
- Maintain the data in something queryable — a database, a structured spreadsheet, a CSV per template. Source of truth should not be a Word document.
- Standardise the foreign keys. Every ICT provider gets a stable internal ID; every contract too. Cross-table links must use these IDs consistently.
- Validate the LEIs. The Legal Entity Identifier is mandatory for in-scope providers — look them up at gleif.org. A wrong or missing LEI is the most common technical failure.
- Generate the xBRL-CSV package using a converter that targets the EBA taxonomy 4.0. Open-source options exist; commercial ones too.
- Validate locally with Arelle before submission. The EBA taxonomy includes formula linkbases that catch most issues before you upload.
- Submit through your national competent authority's portal. The format is the same EU-wide; the portal is country-specific.
What vendors should expect from their financial customers
If you sell ICT services to a regulated entity, you will be asked for the data needed to populate their register. Common questions:
- Your LEI(or a written explanation if you don't have one — most vendors under €5M revenue do not).
- Country of head office and countries of service delivery.
- A short, structured service description that can be mapped to the EBA function taxonomy.
- Names of any sub-contractors involved in delivering the service.
- Confirmation of data processing locations and whether anything leaves the EEA.
Providing this as a pre-formatted document on your site (or in your DoraPilot workspace) saves hours of back-and-forth and shortens your customer's sales cycle.
References: EBA Implementing Technical Standard on the Register of Information under Article 28(9) of DORA, consolidated text of Regulation (EU) 2022/2554, Arelle open source XBRL processor (arelle.org), GLEIF Legal Entity Identifier system (gleif.org).