If your Register of Information came back rejected with something like
[EBA.VR_71] LEI 984500914ED4D50AZ405 needs to be a valid one according to
the GLEIF databases.
this page explains what happened, why the LEI looked fine to you, and how to stop it happening on the next submission.
The short version: the LEI check is an external lookup against the live GLEIF register. Your own tooling cannot do it offline, and the ESAs only run it after you submit. dora-lei-check runs the same lookup locally, before you send anything.
pip install dora-lei-check
dora-lei-check register.zip
An LEI has to clear two entirely separate bars, and passing the first tells you nothing about the second.
Bar one — is it well formed? Twenty characters, [0-9A-Z]{18}[0-9]{2}, with a mod-97 check digit under ISO 17442. This is arithmetic. It works offline and every XBRL tool can do it.
Bar two — is it live in GLEIF right now? The registration status must be ISSUED at the moment of submission. LAPSED, RETIRED, ANNULLED, MERGED and DUPLICATE all fail, and so does an LEI that simply does not exist.
Almost every painful rejection is a register that cleared bar one and failed bar two. A lapsed LEI is a correct LEI. Nothing about it is malformed. Its owner just did not renew — and an LEI that was ISSUED when you assembled the register can be LAPSED by the time you submit it, with no change to your file at all.
That is also why third-party provider LEIs fail more often than your own. You renew yours. You have no control over whether a vendor renews theirs, and a register can carry hundreds of them.
Each code points at one table and column. The message text is the same; the location is what differs.
| Rule | Table | Column | What it identifies |
|---|---|---|---|
EBA.VR_2 |
B.01.01 | 0010 | LEI of the entity maintaining the register |
EBA.VR_12 |
B.01.02 | 0010 | LEI of the entity in scope |
EBA.VR_23 |
B.01.02 | 0060 | LEI of the ultimate parent undertaking |
EBA.VR_71 |
B.05.01 | 0010 | LEI of the ICT third-party service provider |
EBA.VR_77 |
B.05.01 | 0030 | LEI of the provider’s ultimate parent |
All five carry the same wording: LEI [LEI] needs to be a valid one according to the GLEIF databases. The LEI in that message is not contained in the official GLEIF database, or is not active there.
Related codes you may see alongside them:
EBA.VR_16 — the country code you reported does not match the legal address on the LEI certificate.EBA.VR_72, EBA.VR_78 — the EUID equivalents, validated against BRIS rather than GLEIF.v8826_m (incorrect LEI in table) and v8891_m (wrong LEI format in table) — malformed rather than inactive.ICTO007 — no valid or existing LEI has been found for this entity, which in some jurisdictions also means the LEI was never communicated to the NCA before the first submission.The LEI is lapsed. Only the registered owner can renew it, through their LEI issuer. For a third-party provider that means contacting the provider — which takes time you will not have inside a submission window, so find it early. GLEIF’s record shows the next renewal date, which lets you see what is about to expire before it does.
The LEI does not exist in GLEIF. Usually a transcription error from a contract or a vendor spreadsheet, or an LEI belonging to a different group entity. Confirm against the provider’s own documentation rather than a search by name — names are not unique, LEIs are.
The provider has no LEI at all. Smaller and non-EU providers frequently do not have one. Report the EUID instead where the entity is EU-registered; check the current ITS and your NCA’s guidance for the ordering of identifier types.
The format is wrong. Trailing whitespace, a lowercase letter, O typed for 0, a truncated 19-character value from a spreadsheet cell. These are caught offline, before any lookup.
$ dora-lei-check register.zip
LEI VERDICT GLEIF STATUS LEGAL NAME
-------------------- ---------- ---------------- ----------------------
254900ZD9J74PNOI5L11 NOT ISSUED LAPSED VARANDO LTD
5493001KJTIIGC8Y1R12 OK ISSUED Bloomberg Finance L.P.
5493001KJTIIGC8Y1R13 INVALID invalid checksum —
984500914ED4D50AZ405 NOT ISSUED LAPSED BONOCAP LTD
4 distinct LEI(s): 1 OK, 3 failing, 0 unverified
These will be rejected at submission:
254900ZD9J74PNOI5L11 NOT ISSUED found in b_05.01.csv:0030 [EBA.VR_77]
5493001KJTIIGC8Y1R13 INVALID found in b_05.01.csv:0010 [EBA.VR_71]
984500914ED4D50AZ405 NOT ISSUED found in b_05.01.csv:0010 [EBA.VR_71]
Exit code 1 when something will be rejected, so it works as a gate in CI rather than as a thing someone has to remember to run.
Your register stays local. It is a full map of your ICT third-party estate — providers, arrangements, criticality assessments. Hosted validators ask you to upload that. This one reads it on your machine and sends only the public 20-character LEI codes to GLEIF’s free API. With --offline and GLEIF’s daily golden-copy file, it sends nothing at all.
Arelle is the free, open-source XBRL processor most people use for the technical and DPM layers, and it should stay in your pipeline. Its validate/EBA plugin does check LEIs — but format and checksum only, entirely offline, and only for context entity identifiers. There is no GLEIF capability in it.
So a lapsed provider LEI passes Arelle cleanly and fails your submission. The two tools do not overlap; run both.
If your register failed on something this did not catch, open an issue and say what the rejection said. That is what decides the next release.
Rule codes and message wording follow the CSSF guidance on interpreting DORA register error messages. Always check your own NCA’s current guidance — this page is not regulatory advice.