How does Copla Registry handle output and submission format?
What format the DORA Register of Information must be submitted in, which taxonomy version Copla Registry is aligned to, what packaging rules apply, and why a previously accepted register may be rejected in a later cycle.
Covered on this page:
Do we have to submit XBRL? How does the output work?
The DORA Register of Information is submitted in plain CSV format — one CSV file per EBA template — packaged into a .zip file. This is sometimes referred to as xBRL-CSV, because the plain CSV files are supported by xBRL-JSON metadata defined in the EBA taxonomy.
In practice, what you produce and submit are plain CSV files; no XBRL authoring tool is required.
Copla Registry generates an export file structured according to these requirements. You do not need to manually assemble or format the CSV files — the export is structured for submission to your NCA once it passes validation.
Submission is made through your NCA's own reporting channel.
Which taxonomy and version is Copla Registry aligned to?
Copla Registry is aligned with the EBA Regulatory Reporting Framework 4.0 and EBA Filing Rules version 5.5. The DORA part of the 4.0 taxonomy defines how the register data must be encoded, structured, and transmitted so that submission files are technically acceptable to NCAs and ESAs.
We keep the platform aligned with the current taxonomy version and update it as the EBA publishes new framework releases.
Are there specific packaging rules for submission files?
Yes.
The submission file must be a .zip containing the required plain CSV files for each template. The .zip file must follow the EBA naming convention for submission to your NCA:
[LEI].[CON/IND]_[Country]_DORA010100_DORA_[ReferenceDate]_[CreationTimestamp].zip
For example:
DUMMYLEI123456789012.CON_IT_DORA010100_DORA_2025-03-31_20250421141632000.zip
Copla Registry accepts .zip files under any name for import purposes — the naming convention applies to the file you submit to your NCA, not to the file you upload into the platform.
My register was accepted last year but rejected this year
Passing validation in one reporting cycle does not guarantee passing in the next.
The EBA updates its validation rules, data quality checks, and taxonomy between cycles. A register that met last year's technical requirements may not meet this year's if those requirements have changed — even if the underlying data has not.
The validation layer applied by the ESAs when they receive files from NCAs has three components: a technical layer that can cause immediate rejection, a DPM validation layer that flags data quality issues requiring resubmission, and LEI/EUID checks against external databases. Any of these can change between reporting cycles as the EBA refines its framework.
If your register was accepted previously but is now being rejected or flagged, check whether the issue relates to updated validation rules rather than errors in your data.
We update Copla Registry's validation logic in line with EBA framework updates, so running a fresh validation in the platform after any framework update is a recommended first step.