Choosing a converter for your DORA Register of Information
The AFM accepts the Register of Information only as xBRL-CSV, so most filers need a converter. The AFM does not recommend any provider, but it does say what to look for. This page turns that advice into a checklist and says, point by point, what we do.
What the AFM advises
The AFM is neutral: it names no provider and notes that both paid and free open-source tools exist. It gives five points to check (AFM (opens in a new tab); AFM Q&A, March 2026 (opens in a new tab)):
- The converter produces xBRL-CSV, not iXBRL.
- It supports the EBA taxonomy.
- The file meets the EBA's requirements; the EBA publishes examples.
- It runs proper data-quality checks straight away.
- You know what the provider does with your data.
The checklist
Use these questions with any converter, including ours.
| AFM point | Ask the provider | What DORA Convert does |
|---|---|---|
| xBRL-CSV, not iXBRL | Does it produce a ZIP with report.json, parameters.csv, FilingIndicators.csv and one CSV per template? |
Builds exactly that package, named to the AFM's convention, with one folder of the same name inside. |
| EBA taxonomy | Which taxonomy release and DORA module does it target? | report.json points to the DORA module of the EBA taxonomy. The converter shows the ruleset it validates against. |
| EBA requirements | Does it check the package against the EBA's reception and CSV checks before you upload? | Checks the package after building it and withholds it if a check fails. See what we check. |
| Data-quality checks straight away | Does it check your data before building the package, and tell you which cell to fix? | Validates the workbook first: fields, value lists, links between templates, the EBA's active business rules and FAQ clarifications. Each finding names the template, field and row. |
| What happens to your data | Where is the data processed, how long is it kept, and who can see it? | Workbooks are processed for the validation job and not stored in a database. The package is a temporary download. Our privacy statement and data processing agreement set out the terms. |
Converter or package validator
A package validator checks an xBRL-CSV package that already exists. It is useful, but it answers a different question from a converter that checks your data first.
| Package validator | DORA Convert | |
|---|---|---|
| Starting point | A finished xBRL-CSV package | Your Excel workbook, on our template |
| Builds the package | No | Yes |
| Findings point to | Rows and columns in the CSV files | The template, field and row in Excel, with a fix |
| Links between templates (error 807) | Where the package is checked against the data model | Before the package is built |
| Checks the package itself | Yes | Yes, after building it |
The most common reason the EBA rejects a register is a broken link between templates (error 807). The AFM advises checking that before upload, and says tooling can help (AFM Q&A, March 2026 (opens in a new tab)).
What no converter can promise
- Acceptance. The European supervisory authorities validate and accept the register; the AFM checks only the reporting entity's LEI and the file name. No converter can guarantee that the EBA accepts a package.
- Every feedback code. EBA feedback can cite rule codes the EBA has not published. Nobody can check those in advance.
- Your content choices. Which contracts, providers and functions belong in the register is your decision. The AFM notes that the definition of ICT services is broad.
Where we fall short
We'd rather you know before you buy.
- We read workbooks built on our Excel template. A register kept in another layout must first be copied into it.
- We check EUIDs by structure only. The EBA checks them against BRIS, which has no public lookup.
- One access code covers one reporting entity. A group that files separate registers for several entities needs a code for each.
- We build the package; you submit it in the AFM Portal yourself.
If the AFM rejects a package built here, you get one free rebuild. See pricing.