LEI & GLEIF in the DORA Register of Information

A 20-character code, but it identifies both your entity and every one of your ICT providers — and it is one of the most common reasons a DORA register bounces back. Here's what a LEI is, where the register needs one, what to do when a provider doesn't have one, and how a lapsed status quietly breaks a filing.

In short — In the DORA Register of Information, the LEI (Legal Entity Identifier, a 20-character ISO 17442 code from the GLEIF database) identifies both the reporting entity and every ICT third-party provider. It must be active (ISSUED), not LAPSED. A missing, expired or mistyped LEI is one of the most frequent causes of technical rejection.

What a LEI and GLEIF are

The LEI (Legal Entity Identifier) is a globally unique identifier for legal entities: a 20-character alphanumeric code standardised under ISO 17442. It is issued by accredited bodies called LOUs (Local Operating Units) and published in the free, public reference database maintained by GLEIF (the Global Legal Entity Identifier Foundation).

Think of the LEI as a license plate for a legal entity: unique, verifiable, and only useful if it's kept current.

DORA leans on the LEI precisely because it is already the standard identifier used across EU financial reporting — it lets a supervisor cross-reference the same entity or provider across different regulatory filings without ambiguity.

Where the register needs a LEI

The LEI does double duty in the Register of Information — it identifies the entity filing the register and it identifies who that entity depends on:

• the entities within the scope of consolidation — the reporting entity itself and every group entity in scope (template B_01.02);
• the ICT third-party service providers — every vendor with a contractual arrangement, mapped in template B_05.01, part of the broader ICT provider declaration;
• a chain of other templates — arrangements, functions, assessments — that reference these LEIs by foreign key rather than repeating them. Full breakdown: the 15 templates of the register.

That foreign-key structure is why a single bad LEI rarely stays contained: get the entity's own LEI wrong in B_01.02 and every downstream template that points back to it becomes inconsistent too.

Getting and checking a LEI

• Getting one: apply through a LOU or an accredited registration agent. The LEI then has to be renewed every year to stay active — it does not renew itself.
• Checking one: use the free GLEIF search and confirm the status reads ISSUED, not LAPSED. It only takes a minute per entity and per provider, and it's worth doing for the whole list before you build the register, not after.

When a provider has no LEI

A valid LEI is expected for every ICT third-party provider you declare, but in practice not every vendor has one on hand — this shows up most often with smaller software vendors and providers based outside the EU that have never needed a LEI for anything else. Where the register's rules allow another permitted identification code as a fallback, that path exists for a reason: LEIs aren't universal, and the format anticipates it.

What doesn't work is discovering this the week before the filing deadline. Applying for a LEI through a LOU takes time — and if the provider itself has to request and pay for it, that adds a negotiation you don't want to run under time pressure. Build the list of providers' LEI status well ahead of the filing, and chase down the missing ones early.

ISSUED vs LAPSED — the status that trips people up

A LEI doesn't expire outright, but it does need annual renewal with its LOU. Skip the renewal and GLEIF marks the code LAPSED: the number still exists and still resolves to the right entity, but it's no longer treated as current. In practice, a register built with a lapsed LEI is generally treated the same as one built with an invalid LEI — it is one of the checks most likely to flag a filing.

• LAPSED LEI: technically valid, but its renewal is overdue — treat it as if it needs fixing before submission;
• missing LEI: no code recorded at all for a provider that should have one — see the no-LEI case above;
• typo: one wrong character out of twenty is enough for the code to match no entity in GLEIF at all;
• inconsistency: the same entity's LEI recorded differently between B_01.02 and the templates that reference it downstream.

LEI-related rejection causes, in context

None of this is unique to the LEI — it's one instance of a broader pattern behind DORA register rejections. Across the ESAs' 2024 EU dry run, only 6.5% (ESAs, 2024) of submitted registers passed validation on the first attempt, and the recurring failures were technical rather than substantive: non-ISO dates, out-of-range DPM values, invalid identifiers, missing templates, wrong encoding, or exactly this kind of cross-template inconsistency. The full picture, with more failure modes than LEIs alone, is in why DORA registers get rejected.

Frequently asked questions

← Back to the DORA Register of Information guide · Lire ce guide en français →