EBA export

Where it lives

The export workspace is at /eba/ (Licensed tier). It aggregates data automatically from every module - providers, contracts, functions, assessments, entity, scope, branches, intra-group and definitions - into the EBA ITS Reporting Framework 4.0 templates.

The 15 templates

Controlled codes

Each typed column is emitted with its controlled eba_* code rather than free text. You select human-readable values in the UI (a country, a service type, an arrangement type) and the export resolves them to the official codes - eba_GA: for countries, eba_TA:S01-S19 for ICT service types, eba_CO: for arrangement types, eba_CU: for currencies, and so on. See the DORA mapping for the full vocabulary list.

Preview & download

• Preview any template - the column grid (c00xx) with resolved codes.
• Download a single CSV per template, all raw CSVs at once, or the full deposit package.

Validation

Before you build the package, click Validate. The validator checks the package you are about to file the way the EBA's reception does, and returns errors and warnings with the template, row, column and value at fault:

The report groups findings by category, so a long list stays readable. Findings that would make the EBA reject the package are errors; the others are warnings, as in the EBA's own feedback.

EBA feedback downloads the same findings as the detailed-feedback.csv the EBA returns after a submission, to share with whoever fixes the data.

Online identifier checks

The identifier checks are off by default: they send the LEIs of your register to the public GLEIF API (api.gleif.org), and need outbound HTTPS from the server. An administrator turns them on in Organization > General > Identifier checks. They cover the checks the EBA runs as VR_2, VR_12, VR_23, VR_71 and VR_77. EUIDs are checked for their format only, since the European business registers (BRIS) offer no public API. With the option off, only the LEI check digits (ISO 17442) are verified.

The deposit package

The deposit-ready package is a single .zip conforming to the official xBRL-CSV report-package structure:

{LEI}.CON_{COUNTRY}_DORA010100_DORA_{date}_{timestamp}.zip
├── META-INF/
│   └── reportPackage.json        # package manifest
└── reports/
    ├── report.json               # DORA taxonomy binding
    ├── parameters.csv            # reporting parameters
    ├── FilingIndicators.csv      # which templates are filed
    ├── B_01.01.csv
    ├── B_01.02.csv
    ├── B_01.03.csv
    ├── B_02.01.csv
    ├── B_02.02.csv
    ├── B_02.03.csv
    ├── B_03.01.csv
    ├── B_03.02.csv
    ├── B_03.03.csv
    ├── B_04.01.csv
    ├── B_05.01.csv
    ├── B_05.02.csv
    ├── B_06.01.csv
    ├── B_07.01.csv
    └── B_99.01.csv

Filename pattern

• {LEI} - the reporting entity's 20-character LEI (from B_01.01).
• {COUNTRY} - ISO 3166-1 alpha-2 code of the competent authority's country.
• DORA010100 - the module identifier for the DORA register.
• {date} - the register reference date (yyyy-mm-dd).
• {timestamp} - generation timestamp, making each package unique.

From data to deposit, in order

1. Set the reporting entity and reference date (/ei/). If you file as a branch, answer the branch question and run the applicability test.
2. Complete providers, contracts, functions and assessments across the modules.
3. Classify every arrangement's services as ICT, non-ICT or other (/or/, or the services tab of a contract). An arrangement with no service blocks the export.
4. Open /eba/ and click Validate; resolve every error.
5. Download the deposit package .zip.
6. Submit it to your competent authority through their reporting channel.

What the register does and does not carry

Only ICT arrangements are exported. An arrangement whose services are all non-ICT is legitimately tracked in the outsourcing register and is excluded from every template: B_02.x, B_03.x, B_04.01, B_05.x and B_07.01. A provider held only under non-ICT arrangements leaves B_05.01 with it.

An arrangement carrying no service at all cannot be judged either way, so Download and Download Package refuse with a 400 and list the arrangements at fault. Classify them and export again.

Filing as a third-country branch

When the reporting entity is a branch, B_01.01 is filed under the branch LEI where GLEIF has issued one, and falls back to the head office LEI otherwise, which the validation report flags as a warning. The entity type reported is the one the head office would qualify as. B_01.03 carries the branch itself, and arrangements it uses default to eba_ZZ:x838 in B_04.01. The head office never appears in B_01.02.

See DORA mapping for the full field-by-field mapping.