Why DORA registers get rejected
A register can be entirely correct on substance and still bounce at submission. The reasons are almost always technical — and almost always avoidable if you know where to look.
In short — A DORA register is almost never rejected on substance — it fails on technicalities: a non-ISO date, a non-conforming country or DPM value, an invalid or lapsed LEI, a missing mandatory template, non-UTF-8 encoding, or an inconsistency between the interlinked templates. At the EU dry run in 2024, only about 6.5% of registers passed first time (ESAs).
Rejections are technical, not substantive
The supervisor doesn't reject your register because your ICT risk management is weak. It rejects the file because it doesn't parse cleanly against the EBA taxonomy and the xBRL-CSV rules. The data may be perfectly true — but if it's coded the wrong way, the submission fails.
The register isn't judged only on what you say, but on the exact way you code it.
The common rejection causes
YYYY-MM-DD).France instead of FR).The single biggest cause: cross-template consistency
The 15 templates are linked by foreign keys. An arrangement reference, a provider code or a function identifier used in one template must exist in the template that defines it. When it doesn't, the whole register is inconsistent — even though each template looks fine on its own. This is where most registers fail.
How to avoid them
- use ISO dates and UTF-8 throughout;
- verify every LEI on GLEIF (status
ISSUED, notLAPSED); - map free-text fields to the correct DPM closed-list codes;
- check that every cross-template reference resolves to an existing record;
- validate the whole package before you submit, not at the portal.
See exactly what would be rejected — before you submit
DoraReady checks your register against the EBA's 116 validation rules, explains line by line what would cause a rejection and how to fix it, then generates the xBRL-CSV package. Everything runs in your browser: your data never leaves your machine.
Run the free diagnostic