You have been working on your DORA Register of Information for months. The data looks complete. Every template is filled.
You submit, wait, and then the feedback arrives: validation errors.
This has become a recurring outcome. The first DORA RoI submissions in April 2025 showed a clear pattern: registers that appeared complete internally failed once validated by the regulator. The 2024 dry run had already surfaced these issues, yet many organisations encountered them again during formal submission.
The reason is not hidden errors or last-minute mistakes. It is structural. Filling in templates is not the same as building a valid dataset.
The RoI templates collect information, but they do not enforce the rules that the European Supervisory Authorities apply during validation. As long as data is reviewed only within the templates, many problems remain invisible. They surface only when the data is checked as a connected whole.
I wrote previously about why the RoI is fundamentally a data problem rather than a compliance exercise. This post builds on that idea and examines the specific error scenarios that arise during regulatory validation of the Register of Information. What do regulators actually validate? Where do RoI submissions most often fail? And what can you do before submission to avoid repeated rework and regulatory back-and-forth?
To understand why apparently complete RoI submissions fail, you first need to understand how validation is actually applied.
How validation works
When you submit your Register of Information, it is not reviewed in one pass or by a single authority. Validation happens in two phases, each with multiple stages.
Phase 1: National Competent Authority
Your submission first goes to your national competent authority (NCA). The NCA validates it in three sequential stages, each of which must pass before the next begins:
Package validation: can the submission be opened and processed? File formats, encodings, naming conventions, and folder structure are checked. If anything is wrong, the submission is rejected before the data is ever examined.
Structural data validation: does the data conform to the RoI data model? Required fields, value formats, and identifiers are checked against the Implementing Technical Standards (ITS) and the validation rules published by the ESAs.
Business logic and consistency checks: is the data internally consistent? Records must follow logical sequences, conditional fields must be completed when their triggering conditions are met, and related records must make sense when read together.
Failure at any stage stops the process. Data that fails package validation is never structurally assessed. Data that fails structural validation is never checked for business logic.
Phase 2: ESA-level validation
Once the NCA is satisfied, the submission package is forwarded to the corresponding European Supervisory Authority. The ESA applies the same three validation stages, but based on their own interpretation of the ITS.
This is where an important complication arises. NCAs interpret the technical standards with some supervisory discretion. A submission that passes business logic and consistency checks at NCA level may still trigger issues at ESA level, because the two authorities do not necessarily assess edge cases the same way.
In practice, this means passing your national regulator does not guarantee acceptance by the ESAs. The two-phase structure creates a validation gap: internal readiness is judged first against national practice, but final acceptance depends on the ESA-level interpretation.
Where RoI submissions fail in practice
The validation stages above translate into recurring failure patterns. These are not isolated edge cases; they are systematic and foreseeable.
Formal failures during submission
Some submissions fail before the data is even examined.
Typical issues include:
Incorrect file formats
Naming deviations from the specification
Encoding problems
These are usually easy to fix once identified. The challenge is that they are often discovered only after submission, when timelines are already constrained.
Failures against the structural data model
The templates allow entries that do not conform to the data model; regulatory validation does not.
Incorrect formats: numeric fields, date fields, and coded values are validated strictly against the data model.
Invalid identifiers: broken LEIs, invalid functions or contract references are typical examples that slip through local reviews.
Missing mandatory fields: certain fields just cannot be blank and there are rules for how to fill them to indicate the absence of value. A common example is the use of placeholder dates such as “9999-12-31” in mandatory date fields to indicate that an event has not yet occurred.
Duplicate records: each record requires a unique identifier. Duplicates frequently arise when data is consolidated from multiple sources, even if the duplication is not obvious during template review.
Failures in relational integrity
These issues arise not from individual fields, but from how records relate to each other across tables. This is where many late-stage validation issues occur, and where the difference between templates and datasets is most pronounced.
The RoI is not a collection of independent tables. It is one connected dataset: contracts reference providers, assessments reference both contracts and providers, functions reference entities… These references must resolve correctly.
Common failures include:
References pointing to records that do not exist, often because parent records were not created before their dependents
Records being removed while downstream references still depend on them
The same identifier being reused for different concepts across tables
Failures in business logic and internal consistency
Even when formats and references are correct, submissions can fail consistency checks.
Examples include:
Gaps in ultimate parent undertaking relationships
Inconsistent contractual information, like providing the reason of termination for non-terminated contracts
Conditional fields left empty despite triggering conditions being met
These are typically data entry or review failures that were not visible within the templates themselves.
What effective RoI governance looks like before submission
The failures above share a common root cause. They arise from a gap between how data is prepared internally and how it is assessed externally.
Preventing them is not primarily about additional review cycles. It is about aligning internal data governance, ownership, and validation to the way the Register of Information is formally validated.
Before submission, organisations should be able to demonstrate, at a minimum:
Submission files match the specification exactly
No extraneous files are included
Export settings preserve formats and encodings
Header rows and identifiers remain unchanged
Reference data (such as LEIs) is valid
Mandatory fields are populated
Duplicate records are eliminated
All references resolve to existing records
Parent records exist before dependent records
Dates and related fields are logically consistent
Some of these checks can be performed manually. Many cannot be performed reliably at scale without treating the RoI as a connected dataset rather than a set of templates.
The underlying point is not perfection on the first submission. It is predictability. Validation failures are not arbitrary. They are the foreseeable result of how the Register of Information is structured and assessed.
Free DORA RoI Health Check
Validate your Register of Information for issues before submission. Browser-based, private, instant results.