DPM Values in the DORA Register
The most frustrating rejection cause of all: a fact that's entirely correct, entered into a field that only accepts a code. The culprit is the DPM and its closed lists.
In short — The DPM (Data Point Model) is the EBA's data dictionary behind the DORA Register of Information: it defines, field by field, the allowed values — ISO country codes, currencies, entity types, ICT service categories, criticality flags. A value outside the closed list, or in the wrong format, gets the whole submission rejected, even when the underlying fact is correct.
What the DPM is
The DORA Register of Information isn't submitted as a free spreadsheet. The expected output is xBRL-CSV, built on the EBA's taxonomy and its DPM — the Data Point Model. The DPM is the data dictionary sitting underneath the format: for every one of the hundreds of data points spread across the register's templates, it specifies the expected data type, the exact format, and — for a large share of fields — the exhaustive list of values the field will accept. Outside that list, nothing passes.
This is what makes the register unforgiving in a very specific way. It doesn't grade whether your ICT risk information is good; it grades whether every cell is coded exactly the way the taxonomy expects it. Two registers can describe the exact same reality and get opposite outcomes purely on how the values are written.
The register doesn't just judge what you report — it judges the exact way you encode it.
Fields with closed lists
A meaningful share of the register's data points are enumerations: the schema defines a finite set of codes, and the value submitted has to match one of them exactly — no synonyms, no free-text description, no approximation. The table below is illustrative — the authoritative source is always the EBA's published DPM annex and the current validation rules for the reporting period — but it gives a sense of where closed lists commonly cause friction:
FR, DE, IE) — not the country name written out.EUR, USD) — not a symbol or a spelled-out name.Other format rules the DPM enforces
Closed lists are the most visible constraint, but the DPM enforces format rules well beyond enumerations:
- LEI: a valid 20-character code, checked against the ISO 17442 structure;
- dates: strict ISO format (
YYYY-MM-DD), never a localised date string; - encoding: UTF-8 throughout the CSV files;
- identifiers: consistent across the register's 15 interlinked templates — a reference used in one template must resolve to a record that actually exists in the template that defines it.
Why one value can fail the whole file
The register isn't reviewed cell by cell by a human before it's accepted or rejected — it's checked automatically against the EBA's validation rules the moment it's submitted. A single value outside a closed list, or a badly formatted date, doesn't just flag one row: it fails the corresponding rule for the entire package, and the submission bounces. A wrong DPM value is one of the most common technical reasons a register is turned back — the fuller picture, including the other frequent causes, is in why DORA registers get rejected.
Common DPM mistakes
- a plain-language label where a code is expected (
Franceinstead ofFR); - a value that doesn't exist in the closed list — an invented or outdated category;
- the wrong case or format — a lower-case code, a non-ISO date;
- copy-pasting a value from a previous taxonomy version that has since been retired or renamed;
- a mandatory enumeration field left blank or filled with a placeholder value.
Check every value against the EBA's lists
Doing this by hand means confronting every cell against the DPM list for its field, across hundreds of rows and 15 templates. DoraReady checks your register against the EBA's 116 validation rules — including closed-list and format checks — flags every non-conforming value line by line, and generates the xBRL-CSV package. Everything runs in your browser: your data never leaves your machine.
Run the free diagnostic