The DORA Register Will Not Reconcile: Is This a Spreadsheet Repair or a Data Project?
Trace a returned DORA register row across the using entity, contract, ICT service provider, service type and function before deciding whether the work is a local correction or a data-remediation project.
Signals to watch
- A returned file or dry-run error identifies a DORA register template, column or relationship that does not reconcile
- The same entity, contract, provider, service or function identifier differs across templates or systems of record
- A dated supervisory submission, remediation workshop or implementation decision creates a real review window
A DORA register that will not reconcile is not automatically a software project. Start with the rejected relationship: identify the financial entity using the ICT service, the contractual-arrangement reference, the provider identifier, the ICT service type and the supported function. Then find which record owner cannot produce the same value twice. One isolated cell with an agreed source can be repaired locally. Keys that conflict across contracts, entities or systems point to data remediation.
That distinction matters to a regulatory-data platform business-development manager reviewing authorized banking-operations, fintech-compliance and ICT-outsourcing Telegram groups. The useful Signal is not “DORA sheet broken.” It is a named template or relationship failing before a supervisory submission, dry run or remediation workshop. Seeing it a day late can mean arriving after the buyer has assigned the data work or fixed the scope. Treating every returned workbook as a platform lead wastes the same window on formatting errors.
Define the record before diagnosing the error
DORA, Regulation (EU) 2022/2554, requires financial entities to maintain and update a register of information about contractual arrangements for ICT services supplied by ICT third-party service providers. Article 28 says the register is maintained at entity level and, where applicable, at sub-consolidated and consolidated levels. It must distinguish arrangements supporting critical or important functions from those that do not.
Commission Implementing Regulation (EU) 2024/2956 supplies the standard templates. Its recitals describe open tables with predefined columns, indefinite rows and specific keys that form a relational structure. Four keys connect the material across templates:
- the contractual-arrangement reference number;
- the identifier of the financial entity or ICT third-party service provider;
- the function identifier; and
- the type of ICT service.
Those keys explain why a workbook can look complete and still fail. A contract can exist in B_02.01, a provider can exist in B_05.01 and a function can exist in B_06.01, yet a B_02.02 row cannot join them consistently. The problem is the relationship, not the number of filled cells.
Use the returned row as a route map
The following messages are an illustrative composite, not a real bank, submission, customer or supervisory response.
“RoI file came back. B_02.02 provider IDs don’t tie to the contract list. Deadline is close.”
A later comment in another authorized group adds:
“Group cloud agreement. Three entities use it, one shared-service company signed. Function codes differ by country. Not sure which LEI goes on the row.”
This is worth reviewing because it names a template, a provider-link failure, multiple using entities and a dated window. It is not yet a qualified project. The comments do not identify the consolidation level, returned column code, provider identifier, contractual hierarchy, ICT service type, criticality, source system, subcontractor chain, submission route, budget or decision authority.
Obtain a permitted copy of the error or validation result and preserve its exact template and column. Then route the relationship through the following owners.
| Failure location | What the official template is trying to connect | First evidence to request | Likely record owner to confirm it |
|---|---|---|---|
| Entity | The financial entity making use of the ICT service, identified by LEI in B_02.02 | Scope of consolidation, using-entity LEI and the entity listed in B_04.01 | Regulatory reporting or group data governance |
| Contract | The unique reference assigned to a standalone, master or associated arrangement in B_02.01 | Signed arrangement, master/order-form hierarchy and internal contract reference | Procurement or contract management |
| Provider | The ICT third-party provider identifier used in B_02.02 and B_05.01 | Legal name, LEI or EUID as applicable, and the direct contracting party | Third-party risk or vendor master-data owner |
| Service and function | One ICT service type joined to the financial entity’s function identifier | Service description, Annex III service type, licensed activity and B_06.01 function record | ICT service owner and business-function owner |
The signatory is not always the entity using the service. The instructions for B_03.01 explicitly allow the entity signing an arrangement to differ from the financial entity making use of the ICT service, especially in a group. If a shared-service company signed a cloud agreement for three regulated entities, copying the signatory’s identifier into every using-entity field can create a neat but incorrect join.
Follow one relationship all the way through
Take the composite thread above. Suppose the returned row points to B_02.02, the template for specific information about a contractual arrangement. That row combines, among other values, a contract reference, the LEI of the financial entity using the service, the provider identifier, a function identifier and an ICT service type.
Start with the contract reference. B_02.01 requires an internally assigned reference that is unique, consistent over time and used consistently across the register. It can describe a standalone arrangement, an overarching or master arrangement, or a subsequent arrangement such as an order form. A service-level agreement subordinated to those arrangements is not treated as the contractual reference itself.
Now test the row without changing it:
- Does the contract reference resolve to the same master or order form in the contract repository and B_02.01?
- Does the using-entity LEI resolve to the entity actually receiving the service, rather than only the group company that signed?
- Does the provider identifier resolve to the same legal provider in B_05.01 and to the direct party providing the contracted service?
- Does the function identifier resolve to the same combination of entity LEI, licensed activity and function in B_06.01?
- Does the ICT service type describe the service covered by that contract-and-function combination?
If steps two and four fail for one country, the correction belongs first to entity and function ownership. Reformatting the provider column will not repair it. If step one produces different references in procurement, vendor risk and reporting files, the contract key itself is unstable. That is a broader data problem even if a spreadsheet formula can force today’s export to pass.
Decide whether the repair ends in the workbook
A local spreadsheet correction is plausible when all four conditions hold:
- the returned template, column and affected rows are known;
- one authoritative source and one accountable owner agree on the corrected value;
- the correction preserves consistent references in every related template; and
- the same defect is not recreated by the next export or another entity.
A data-remediation project becomes plausible when the team cannot satisfy those conditions without repeatedly rebuilding relationships. Examples include contract references that change between systems, several vendor records for one legal provider, group entities using the same service under incompatible mappings, and function identifiers assembled manually for each submission. Those are not merely “bad cells.” They show that the organization has no repeatable route from source records to the official relationship.
Do not infer budget from severity. A widespread defect can still be handled internally; a small defect can trigger an external engagement if the deadline, controls or technical environment require it. The commercial conversation is ready only after the failure pattern, accountable owners and decision date are known.
Ask for six facts before scoping remediation
Before discussing a platform, migration or managed data service, ask:
- Which register level and reporting perimeter failed: entity, sub-consolidated or consolidated?
- Which template, column code and validation message were returned?
- Which relationship is inconsistent: using entity, contract, provider, service type or function?
- What is the authoritative system for each side of that relationship?
- Who can approve a corrected identifier or mapping?
- When is the next dry run, supervisory request, workshop or submission?
These questions do not perform legal interpretation or promise that the corrected register will be accepted. They establish whether the buyer needs one accountable correction, reconciliation rules between systems, master-data cleanup, or a repeatable register-production process.
For a different kind of evidence request, the SOC 2 onboarding article shows how the requested artifact changes the service route. When a discussion makes a regulatory claim without the actual return message or template, use the official-source ladder before treating it as evidence.
Use group discussion to find the window, not to certify the defect
TOP Prospect can connect fragments from Telegram groups a user deliberately authorizes, preserve original wording, source and time, remove clear duplicates and rank the composite discussion for human review. It cannot access the register, validate a template, identify a legal entity, interpret DORA, contact the writer or confirm a procurement project.
The platform’s role ends at making the fragmented request reviewable. The business-development manager still needs the permitted validation result, the record owners and the decision date. For the broader pattern of compliance work becoming a commercial window, see how regulation-driven demand signals develop.
The decision at the end of the first review should be narrow. If one owner can reconcile one row to an authoritative source and keep every linked template consistent, route it as a controlled repair. If no owner can reproduce the entity-contract-provider-service-function relationship, route a data-discovery conversation. The rejected workbook is the symptom; the repeatability of the relationship determines the project.
Frequently asked questions
What is the DORA register of information?
It is the register financial entities must maintain and update for contractual arrangements involving ICT services supplied by ICT third-party service providers. DORA Article 28 requires it at entity level and, where applicable, sub-consolidated and consolidated levels.
Which values connect the DORA register templates?
Implementing Regulation (EU) 2024/2956 describes four connecting keys: the contractual-arrangement reference number, identifiers for financial entities and ICT third-party service providers, the function identifier, and the type of ICT service.
When is a rejected DORA workbook only a spreadsheet repair?
It may be a local repair when the affected row and owner are known, the authoritative source agrees, the correction does not change related templates, and the same defect is not being recreated elsewhere.
When does DORA register remediation become a data project?
It is more likely a data project when identifiers conflict across entities or systems, contract hierarchy is not stable, provider records are duplicated, or service-to-function mappings cannot be reproduced without manual reconstruction.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
