--- title: "The DORA register of information" summary: "What the register demands, why only 6.5% of almost 1,000 dry-run registers passed all 116 data quality checks, and the provider identity problem that explains most of the failures." canonical_url: https://entitybind.com/guides/dora-register-of-information last_updated: 2026-10-12 copy: full --- # The DORA register of information > What the register demands, why only 6.5% of almost 1,000 dry-run registers passed all 116 data quality checks, and the provider identity problem that explains most of the failures. Canonical page: https://entitybind.com/guides/dora-register-of-information Last updated: 2026-10-12 For the team that owns a company master and has to defend it. Your provider list sits in four systems that were never reconciled with each other, and a supervisory submission date is coming. EU financial entities must maintain and submit a register of information on their contractual arrangements with ICT third-party service providers, identifying each provider by its legal entity identifier. When the European Supervisory Authorities ran a dry run over almost 1,000 of these registers, only [6.5%](https://www.eba.europa.eu/publications-and-media/press-releases/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital-operational) passed every one of 116 data quality checks. That is not a reporting-template problem. Most of what failed was identity: providers named inconsistently, identifiers never obtained, and the same provider appearing as several. - Reading time: 11 min read - Sections: 8 - Questions answered: 6 - Key takeaways: 7 The same measurement, on your rows: A first file is a few hundred of your own rows with the matches you already have beside them. The numbers in this article come back measured on your data, and we write nothing to your systems. [Start free →](https://app.entitybind.com/app?signup=1) Self-service. Create your workspace online and verify your email to start matching company records. Free starts with 300 credits and no card. Paid monthly plans are available in workspace Billing; VAT is added where applicable. Usage is tracked without automatic overage charges. [Trust and security](https://entitybind.com/trust) A stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, counterparty onboarding that has to survive an audit. Read the argument here, take the takeaways at the foot into your next vendor conversation, and send us a file when you want the same measurement on your own rows. Regulatory deadlines · 1,996 words · every figure carries the population it was measured over By [James Rooney](https://entitybind.com/about), founder of Entity Bind · Last revised 12 October 2026 ## What the register demands The register requirement sits in the [Digital Operational Resilience Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554) itself, with the detail in its implementing technical standards, and it has applied since [17 January 2025](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554). A financial entity maintains a register of its contractual arrangements with ICT third-party service providers and submits it to its competent authority annually. The templates want more than a list of suppliers. They want the contractual arrangement, the entity within your own group that holds it, the function being supported and whether it is critical or important, the provider, the provider's own subcontractors where they matter to the function, and the identification of every one of those parties by a code rather than by a name. That last requirement is the one that turns a procurement exercise into a data problem. A name is a string somebody typed; a code is a claim that can be checked against a public source, and a checkable claim is one that can fail. The register did not create the underlying mess. It made it machine-readable, and therefore visible. ## The dry-run finding [6.5%](https://www.eba.europa.eu/publications-and-media/press-releases/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital-operational) of almost 1,000 registers passed every one of 116 data quality checks. The dry-run exercise was run by the European Supervisory Authorities and the result published by the European Banking Authority. The figure is theirs; the reading of it as an identity failure is ours. Read the denominator before the headline. This was every check, not most of them: a register that failed one check out of a hundred and sixteen is in the ninety-three and a half per cent. So the finding is not that the industry cannot fill in a form. It is that a submission of this shape has a very large surface area for a single inconsistency to land on, and the commonest inconsistencies are about who a provider is. It is also a finding about an industry that is not short of budget, tooling or third-party risk expertise. If a well-resourced compliance function with a supplier list and a contract repository still cannot produce a register that passes every check, the missing capability is not effort. It is a way to establish, defensibly, that these four rows are one company and that this one is a different company with a similar name. ## The four failure shapes Almost every identity-shaped failure in a provider register is one of four things, and they have different fixes. - One provider, several rows. The contract repository holds the entity under its legal name, the invoice under its trading name, and the security assessment under the group brand. Each becomes a row, and the register reports three providers where there is one — which understates concentration, the exact thing the register exists to reveal. - The wrong entity in the group. The contracting party is the local subsidiary and the register names the global parent, or the reverse. Both are real companies and both look plausible, and only one of them is party to the arrangement. - A missing or wrong identifier. Nobody ever obtained the provider's LEI, so the field is blank, carries the financial entity's own LEI by copy-paste error, or carries an identifier belonging to a different company in the same group. - A name that does not resolve. The provider is recorded under a product name, an acquired brand, or a name the company stopped using after a merger, and no lookup against any register will find it without knowing that. ## Why this is an entity resolution problem Compiling the register is, structurally, a deduplication and resolution exercise with a supervisory deadline attached. You have a list of names drawn from several systems that were never reconciled with each other, and you need a partition of that list into companies, each identified by a code that a supervisor can check. That is exactly the shape of the problem this site is about, and it has the same two failure modes. Under-merging reports the same provider several times and understates concentration. Over-merging welds two suppliers together and produces a register that validates cleanly and is wrong — which is the worse outcome here, because a register row that fails validation gets looked at and a register row that validates does not. The property that matters most for this work is therefore the refusal. A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. A provider that cannot be resolved on the evidence in your contract repository comes back as an exception with a ranked shortlist and the field that would settle it, rather than as a confident row somebody will submit. On the 317-company live-adjudicated fixture of 2026-08-29 there were 0 false binds across every input shape, and 1,666 / 1,666 accepted matches cleared the floor — historical results on an internal UK fixture with a preloaded catalogue. The September 5 replay has no full-prompt-verified calls and cannot establish current calibration. No independent customer holdout or global coverage claim. ## LEI, EUID, and the identifiers the templates want The LEI is the identifier the register is built around, and it is a good choice: it is global, free to consume, published by the body that assigns it, and carries an offline check digit so a mistyped code can be rejected before it is ever submitted. Coverage follows obligation, which is why a great many technology suppliers to regulated firms acquired one specifically because of this register. The EUID is the other registry-issued code in the picture. The only pan-European registry-issued key that exists. Supply is thin because most member states do not publish it yet. It is structured as a country code, the register's own identifier and the number held in it, which is the correctly qualified shape a bare company number never had — and its practical constraint is supply rather than design. Where a provider has no LEI, that is a finding about the provider and it generates an action: ask them to obtain one, or record the arrangement under whatever the template permits instead. Where nothing in your tooling supplies the scheme, that is a finding about your tooling and it generates a different action. A crosswalk that returned an empty field for both would make those two situations indistinguishable, which is why the four empty states — the scheme was checked and had no value, no source supplies the scheme, the scheme was not checked, the source was unavailable — are separate words in the response rather than one silence. ## Compiling the register, in order The sequence below is the narrow, identity-shaped part of a DORA programme. It is not the programme. - Import the provider list from every system that holds one — the contract repository, accounts payable, the third-party risk tool, the security assessment log — keeping each system's own identifier on every row. - Resolve the rows to companies, and read the abstentions first. The rows nobody can resolve are the rows where your systems disagree about who a supplier is, and that is the register's real backlog. - Establish the contracting entity rather than the brand. The question the template asks is which legal person is party to the arrangement, and a group's global parent is usually the wrong answer. - Retrieve the identifiers for the resolved companies, and record the empty ones with their reason so a reviewer can act on the right one. - Walk one hop of ownership where the template needs a group view, with each edge stating its basis — an LEI parent means accounting consolidation rather than majority ownership, and rendering the two as one field is wrong in a way nobody can see on a concentration report. - Export the values with an exception file beside them, and attach the decision id to every resolved provider so a supervisory question has an answer rather than a reconstruction. ## The rows you should expect to fail A realistic project plan assumes a residue, and naming it in advance is the difference between a controlled exception list and a last-week panic. Providers below the LEI adoption line — small specialist suppliers, regional resellers, individual contractors trading through a company — frequently have no LEI and no reason to obtain one until you ask. That request has a lead time, so it belongs at the start of the project rather than at the end. Providers outside the measured registers. The registers with fixtures behind them are the United Kingdom, the United States via Colorado and via SEC filers, France and Norway; adapters for Finland, Czechia and Poland are wired with no evaluation fixtures and therefore carry no measured quality figure, and Germany is an absence rather than thin coverage because there is no lawful bulk source. A supervisory register is the wrong place to accept an unmeasured claim, so those rows should be worked as a review queue. And the genuinely ambiguous: two live companies with the same name in the same jurisdiction, one of which you contract with. That is the register being correct about a world in which two different companies are that similar, and it is settled by a person reading the contract. What the tooling should do is put that row in front of them with the shortlist and the field that would decide it, rather than picking. ## What this is not It is not a DORA management platform. It does not assess criticality, run resilience testing, manage incident reporting, hold your contract lifecycle or produce your submission. The narrow claim is the identity compiler: canonical provider identities, validated identifiers, duplicates and conflicts surfaced, one hop of ownership with each edge's basis stated, and an exception file with a reason per row. It is not screening, and a third-party risk programme should not read a resolution as one. Scope is company and organisation identity only, and there is no risk boolean anywhere in the data model. And there are no certifications behind it. No SOC 2. It has not been started. No independent external validation of the accuracy figures. Every fixture is one we built. For a regulated buyer running a DORA programme that is material, and it is better established on the first call than in month three. ## What to take away - Only [6.5%](https://www.eba.europa.eu/publications-and-media/press-releases/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital-operational) of almost 1,000 dry-run registers passed every one of 116 data quality checks. The dry-run exercise was run by the European Supervisory Authorities and the result published by the European Banking Authority. The figure is theirs; the reading of it as an identity failure is ours. - The register did not create the problem. Requiring a checkable code rather than a name made an existing inconsistency machine-readable, and therefore visible. - Four failure shapes cover most of it: one provider as several rows, the wrong entity in the group, a missing or wrong identifier, and a name that does not resolve. - Over-merging is the worse error here, because a register row that fails validation gets looked at and a register row that validates does not. - A missing LEI is a finding about the provider; a scheme nothing supplies is a finding about your tooling. Those need to be different words in the output. - Ask providers below the LEI adoption line for their identifier at the start of the project. The request has a lead time you cannot compress at the end. - This is an identity compiler, not a DORA management platform: no criticality assessment, no resilience testing, no incident reporting, no submission. Those takeaways hold for anybody's data. The number for yours comes out of your own rows — a few hundred of them, with the matches you already have beside them. [Start free →](https://app.entitybind.com/app?signup=1) ## Read next Each article names its own further reading. These pick up a question this one raises and leaves open. - [KYB data requirements](https://entitybind.com/guides/kyb-data-requirements) (11 min read): What a know-your-business onboarding flow actually needs, field by field, and which step is identity resolution. Explicitly not a screening, scoring or eligibility tool. - [What is an LEI?](https://entitybind.com/guides/what-is-an-lei) (11 min read): The Legal Entity Identifier explained: the twenty-character structure and its check digits, GLEIF and the LOUs, Level 1 and Level 2 data, annual renewal and lapse, and what a lapsed LEI means for matching. - [Company identifiers explained](https://entitybind.com/guides/company-identifiers-explained) (13 min read): Company number, LEI, CIK, ticker, SIREN and SIRET, DUNS, VAT, EUID and ISIN. What each identifies, who issues it, what it does not guarantee, and which ones actually decide a match. - [How to deduplicate a supplier master](https://entitybind.com/guides/how-to-deduplicate-a-supplier-master) (12 min read): Duplicate vendors, payment leakage, remittance conflicts and parent concentration. The accounts payable playbook for finding which vendor records are one company, with a citation for every finding. Or try your own rows: create your Free workspace and upload a company CSV to inspect its results. Contact us for an assisted measurement against your labelled data, with the working handed back. [Start free →](https://app.entitybind.com/app?signup=1) ## Where this article is applied 2 pages name this method as the working behind what they claim. - [KYC and onboarding](https://entitybind.com/use-cases/kyc-and-onboarding) (Use case): Counterparty identity with a receipt that survives seven years. - [Reference data](https://entitybind.com/use-cases/reference-data) (Use case): Every identifier a company is known by, each separately cited — and the ones nobody holds. ## Is this your file? The article is for anyone. The measurement behind it is worth commissioning for one kind of team. ### Built for Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit. ### Wrong for Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. ## Sources The papers, regulators and registers this article quotes, each with the caveat that travels with it. - [Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554): The Regulation itself. The register templates are in its implementing technical standards, which are separate acts. - [European Banking Authority, “The ESAs' Dry Run exercise shows the goal of reporting of registers of information under Digital Operational Resilience Act in 2025 within reach”, 17 December 2024](https://www.eba.europa.eu/publications-and-media/press-releases/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital-operational): The source of the 6.5%, the 116 checks and the almost 1,000 financial entities; it also reports that half of the registers that did not pass failed fewer than five checks. The ESAs concluded that registers of sufficient quality in 2025 were not out of reach. The reading of the failures as identity failures is ours. - [GLEIF, “The Legal Entity Identifier (LEI)”](https://www.gleif.org/en/organizational-identity/lei-vlei/the-legal-entity-identifier-lei): The operator of the system, describing the twenty-character code and the four ISO 17442 principles it adheres to. It is GLEIF's account of the standard rather than the standard's own text. ## The basis for every figure above Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. Figures read off the product repository on 2026-09-05. The per-tier rates come from the live-adjudicated 317-company recording of 2026-08-29; the gate figures come from the stub-adjudicated continuous-integration run and are a floor rather than a ceiling. The two are never averaged. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none. Every figure, with the population it was measured over and the method behind both recordings, is set out on [the accuracy page](https://entitybind.com/accuracy). The retention, erasure, tenancy and sub-processor detail a security review asks for is under [Trust and security](https://entitybind.com/trust), with where assurance stands: no external validation of the accuracy figures and no customer holdout. ## The same measurement, on your own rows. Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration. [Start free](https://app.entitybind.com/app?signup=1) · [Plans and prices](https://entitybind.com/pricing) 300 credits. No card. For a guided review of your file, explore [the Merge Safety Sprint](https://entitybind.com/audit-pack). ## The questions this article answers ### What is the DORA register of information? A register EU financial entities must maintain of their contractual arrangements with ICT third-party service providers, submitted to their competent authority annually. It records the arrangement, the entity in your group that holds it, the function supported and whether it is critical or important, the provider and its relevant subcontractors, and the identification of each party by a code rather than by a name. The requirement sits in DORA itself with the detail in its implementing technical standards, and it has applied since 17 January 2025. ### Why did so few dry-run registers pass? 6.5% of almost 1,000 registers passed every one of 116 checks, and "every one" is doing the work in that sentence: a register failing a single check falls into the other ninety-three and a half per cent. Most of what failed was identity: providers named inconsistently across the systems the register was compiled from, identifiers never obtained, and the same provider appearing several times. The dry-run exercise was run by the European Supervisory Authorities and the result published by the European Banking Authority. The figure is theirs; the reading of it as an identity failure is ours. ### Does every ICT provider need an LEI? The register is built around identifying providers by their legal entity identifier, and in practice that is why many technology suppliers to regulated firms obtained one. Providers below the adoption line — small specialists, regional resellers, contractors trading through a company — frequently have none and no reason to acquire one until asked. That request has a lead time, which is why it belongs at the start of a register project rather than at the end. ### Can you produce our DORA submission? No. The narrow claim is an identity compiler: canonical provider identities, validated identifiers, duplicates and conflicts surfaced with the evidence, one hop of ownership with each edge's basis stated, and an exception file with a reason per row. Criticality assessment, resilience testing, incident reporting, contract lifecycle and the submission itself are not here. ### What happens to a provider you cannot identify? It comes back as an exception rather than as a row somebody submits. A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. The exception carries a ranked shortlist, a typed cause and the cheapest field that would settle it — frequently the provider's domain, which is usually available from the contract. That is the correct outcome for a register: a row that fails validation gets looked at, and a row that validates because a tool guessed does not. ### How do you handle a provider's group structure? One hop by default and up to ten on request, from the global LEI system's Level 2 relationship records and, for UK companies, the persons-with-significant-control register, cycle-safe and bounded and failing closed on ambiguous or name-only owners. Every edge states its basis and its certainty, because an LEI parent means accounting consolidation rather than majority ownership. An incomplete walk is reported as an absence of coverage rather than as an absence of owners. --- The 0.90 confidence floor. It is an acceptance contract, not calibration evidence: it says what we refuse to return, not how often an accepted match is right. Read it with the coverage it costs. This is the Markdown copy of https://entitybind.com/guides/dora-register-of-information, assembled from the same data the page renders and carrying every sentence, table row, figure and question the page's main content carries. The HTML page is canonical; it adds the layout, the navigation and the interactive parts (the ask panel, the forms), which a copy can name but not run. Every page on the site, with a line on each: https://entitybind.com/llms.txt.