The DORA register of information is an entity-data exercise

The Luxembourg collection is a worked example of the mechanics. The CSSF eDesk portal opens on 11 February 2026 and closes on 31 March 2026, and the register must cover contractual arrangements contracted up to the reference date of 31 December 2025. The submitting entity's legal entity identifier has to reach the CSSF before the file does, and at least one member of staff must hold the DORA reporting role in eDesk before anything can be uploaded.

The format is unforgiving in a way that is quietly useful. Registers go up as plain CSV files inside a zip archive that follows a set folder structure and naming convention, and a register that fails the European Supervisory Authorities' validation checks has to be corrected and resubmitted before the window closes. A rejection in the last week of March is not a technical inconvenience; it is a report that has not been made. Groups with entities in several member states should expect several windows and several portals.

One regulated company reconciles its register against itself. A group maintains the register at entity level and, where it applies, at sub-consolidated and consolidated level, so one contract can appear in more than one file, described from more than one vantage point. The consolidated view only holds together if the hierarchy recorded in the file is the hierarchy that existed on the reference date.

Fund and holding structures are where that comes apart. An entity renamed in November, a branch opened in a second member state, a manager whose identifier was renewed under a slightly different legal name, a contract signed by a service company on behalf of three regulated entities: each is ordinary corporate housekeeping, and each surfaces as a validation failure or as an inconsistency between levels that somebody has to explain in March.

The instinct under time pressure is to patch. Someone edits a legal name in a CSV so the row passes, and the register goes in carrying a value that matches neither the constitutional documents nor the bank mandate nor last year's submission. By the following January the edit is invisible, and whoever builds the next file reproduces the same mismatch from the same source. Treat the annual submission instead as a yearly test of the entity record, and write every correction back into it: one authoritative legal name for each entity, one identifier with its renewal date, one recorded parent, one list of branches, and a named owner for each. Generate the register from that record and a validation failure becomes a finding about the record, which somebody can fix once.

The fields the register of information asks for are the fields a governed entity record already holds: identifiers, ownership, officers, the documents behind each fact, bank accounts and mandates, and obligations carrying due dates. They are held once, with an audit trail showing when each value changed and who changed it.

Alethia submits nothing and connects to no portal. Where it earns its place is the fortnight before a window closes. Each in-scope entity carries a dated obligation for its own authority's collection, the structure chart comes off the record, and the person building the file sees the entity data without being handed everything else in the register.