DORA Register of Information: the validations that fail most.

The layers a register is tested against

A register passes through several independent tests, and knowing which one produced an error saves a great deal of time. The package structure is checked first: the metadata file, the set of files it declares, and their correspondence to the taxonomy. Then each field is tested for data type, length and allowed values. Only then are the rules that span templates applied — the ones that check whether the fifteen templates describe a coherent set of arrangements.

An error in the last layer will often point at a template that is itself perfectly valid. The row is fine; the row it refers to is missing.

Referential integrity failures

These dominate. The templates in Commission Implementing Regulation (EU) 2024/2956 are linked by keys, so every reference has to resolve.

• A service row pointing at an arrangement that is not in the register. Usually a contract that was descoped part-way through the build, with its service rows never removed.
• An arrangement with no party rows. The arrangement exists but nothing records which entity signed it or which entities use the service.
• A function reference that does not resolve. Function identifiers renumbered part-way through the criticality assessment, with the mapping rows not reissued.
• A subcontractor pointing at a provider that is absent. The chain was captured from the provider’s own documentation without adding the intermediate entity.

The tell is that the same underlying mistake surfaces as several unrelated-looking errors, because one broken key breaks every reference to it.

Coded values and identifiers

Coded fields do not accept free text. Country and currency codes come from the ISO lists, legal entity identifiers are twenty characters and structurally checkable, and service types come from the supervisory taxonomy.

The correct answer to “none of the service types fit” is to select the closest taxonomy value and record the reasoning internally — not to invent a value.

Cardinality and duplicate keys

Where more than one value is valid for a data element, the completion instructions require an additional row rather than a combined value. That rule creates its own failure mode: added rows must not duplicate key values, and every added row must be complete rather than carrying only the changed field. Registers assembled by copying a row and blanking the columns that stayed the same fail here consistently.

The opposite error is equally common — several distinct services collapsed into one row because the contract is one document. The contractual arrangement is the unit for the arrangement templates; the individual ICT service is the unit for the service templates.

Supply-chain completeness

Subcontractors supporting a critical or important function have to be recorded with their rank in the chain. Two failure patterns recur. The first is a chain that stops at the first subcontractor because that is as far as the provider’s disclosure went. The second is a chain recorded at the wrong rank, because an entity that sits between two others was omitted, which shifts everything after it.

Both are contract-management problems that surface as validation errors. If the arrangement does not oblige the provider to disclose its own supply chain, the register cannot be completed from the reporting team’s own records.

Consolidation scope mismatches

Registers at sub-consolidated and consolidated level are tested for internal consistency of their perimeter. The usual failure is an entity that appears as a party to an arrangement while sitting outside the consolidation scope the register declares, or an arrangement included at group level that no in-scope entity uses. Both mean the entity perimeter and the arrangement population were assembled from different sources.

Official sources

Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.

1. Commission Implementing Regulation (EU) 2024/2956, in particular the general requirements for the templates and the data format requirementEUR-Lex · Implementing Regulation · template structure, one value per element, additional rows
2. Regulation (EU) 2022/2554 (DORA), Article 28(3)EUR-Lex · Regulation · the obligation the register satisfies
3. European Banking Authority — frequently asked questions on the reporting of registers of information, and the accompanying data modelEBA · interpretation of the completion instructions · consult the current release

Questions, answered

Why does one correction clear several errors at once?

Because the templates are linked by keys. A single missing or mistyped key breaks every row that refers to it, so the validator reports one error per broken reference. Repairing the key clears the whole set.

The validator accepts the file but the authority rejects it. What is different?

Schema validity and supervisory acceptance are separate tests. A file can satisfy the data types and allowed values and still fail business rules applied on receipt, such as consolidation scope consistency or supply-chain completeness for critical or important functions.

None of the service types matches our contract. What should we enter?

Select the taxonomy value that most closely corresponds to the service actually received and record the reasoning in your own documentation. Free text in a coded field will be rejected, and inventing a value removes any comparability the supervisor is relying on.

How far down the supply chain do we have to go?

As far as the Implementing Regulation requires for subcontractors supporting a critical or important function, recording the rank of each. If the arrangement does not oblige the provider to disclose its own subcontractors, that is a contractual gap to close rather than a data gap to estimate.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.