ICT Third-Party Registers Under DORA and PS26/2: What Regulators Check First and How to Prepare
The Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA) has applied across the European Union since 17 January 2025. Among its most consequential requirements is the obligation imposed by Article 28(3) on financial entities to maintain, and to make available to their competent authority, a register of information on all contractual arrangements with ICT third-party service providers. The technical specifications for that register are set out in the Commission Implementing Regulation (EU) 2024/2956 (the ITS on registers of information), which defines the templates, data fields, formats, and identifiers that every submission must follow.
The first official reporting cycle began in 2025, with competent authorities required to transmit registers from financial entities to the European Supervisory Authorities (the EBA, EIOPA, and ESMA, collectively the ESAs) by 30 April 2025. That deadline was not a formality. Under the ESAs’ November 2024 Decision on CTPP designation, the registers serve as the primary data source from which the ESAs will identify and designate critical ICT third-party service providers (CTPPs) — the providers whose failure could threaten financial stability across the EU. Every register submitted becomes part of a sector-wide mapping exercise. Its accuracy, completeness, and technical conformity determine not only whether it passes validation but also how useful it is to supervisors once it does.
The December 2024 dry run exercise, in which 1,039 financial entities submitted registers under live conditions, made the stakes concrete. Only 6.5% of submissions passed all data-quality checks. A further 92 failed at the integration stage before any data-quality analysis was applied. The EBA’s preparations page and the DORA RoI Reporting FAQ (updated 28 March 2025) provide the detailed guidance that regulators use to assess incoming submissions, and they reveal a consistent review sequence: technical and structural validation first, then mandatory field completeness, then identifier integrity. This article follows that sequence and explains what it requires in practice.
The Regulatory Framework Behind the Register of Information
The Register of Information (RoI) is not a new concept in financial regulation, but DORA has given it a substantially more demanding form. Previous outsourcing registers maintained by payment institutions and e-money institutions under EBA outsourcing guidelines were largely internal governance documents, reviewed periodically by national competent authorities (NCAs) but not subject to standardised machine-readable reporting. Under DORA, the register is a structured data submission governed by a formal data point model (DPM), validated against a defined set of technical and business rules, and transmitted through a common reporting infrastructure operated by the EBA on behalf of the ESAs.
Article 28(3) of DORA requires financial entities to maintain a register of information identifying all contractual arrangements for the use of ICT services provided by ICT third-party service providers. The ITS on registers of information specifies the templates (designated B_01.01 through B_99.01), the data point model governing each field, and the technical package required for submission. The format in which financial entities submit their register to their NCA varies by jurisdiction. In 2025, NCAs adopted different intake approaches: BaFin and DNB accepted Excel and converted it to xBRL-CSV on the back end; AFM required xBRL-CSV directly; ECB-supervised significant institutions submitted via CASPER in Excel. The uniform format applies at the NCA-to-ESA layer: what the ESAs receive and ingest is a plain-CSV (xBRL-CSV) ZIP archive containing a specified set of files. The EBA DORA RoI FAQ is explicit that the ESAs cannot create an Excel solution respecting all referential integrity and data model requirements – meaning Excel cannot pass ESA-level validation regardless of whether an NCA accepted it as an intake format.
The reporting chain is sequential. Financial entities prepare their registers and make them available to their NCA. The submission format at the FE to NCA step is set by each NCA and varies across member states. The NCA then transmits the files to the ESAs, with the EBA acting as the solution provider for the common infrastructure. The reference date for the first official reporting cycle was 31 March 2025, transitioning to 31 December of the preceding year for subsequent annual cycles. Financial entities that did not participate in the dry run or whose dry run submissions failed were reporting under live conditions for the first time in 2025, against a standard that the dry run results had demonstrated was genuinely demanding.
How the ESAs Validate Incoming Submissions
The Three-Layer Validation Architecture
The EBA DORA RoI FAQ describes the validation framework in three sequential layers. The first is the technical layer, which processes each submission before any data is stored. At this stage, the ESA systems check that the ZIP package conforms to the prescribed structure, that the naming convention has been followed, that all required files are present, and that the submission uses genuine reporting files rather than test or template artefacts. Submissions that fail the technical layer are rejected outright, with feedback returned to the submitter. They do not proceed to the next stage.
The second layer is DPM validation. Once a submission has passed the technical checks and its data has been stored, the EBA applies data quality checks derived from the data point model. These checks test whether field values conform to permitted drop-down values, whether date formats are correct, whether mandatory fields have been populated, and whether the relational integrity between templates (the cross-references that link entities, providers, contractual arrangements, and services) holds consistently across the package.
The third layer is the business checks layer, which includes verification of LEIs against GLEIF data and of EUIDs against BRIS where possible. These are not internal consistency checks but external verification steps: the ESAs compare the identifiers reported by financial entities against authoritative reference sources to confirm that the legal persons named in the register correspond to entities that actually exist and are validly registered. An LEI that is inactive, expired, or misattributed will not pass this layer regardless of how consistently it appears across templates.
What the Dry Run Revealed About Failure Rates
The 2024 dry run exercise – in which submissions ran from 1 July to 30 August, with the ESAs publishing their summary report and holding an industry workshop in December – provided the clearest available picture of where financial entities struggled. The exercise was framed throughout as voluntary and conducted on a best-efforts basis; the ESAs were explicit that participating entities were expected to submit what they could on the day, not a fully complete register. Against that backdrop, the results were still instructive. Almost 1,000 financial entities participated (the December workshop materials cited 1,039, while the ESA press release used “almost 1,000”). Of those, 92 were rejected at the integration stage before any data-quality analysis was attempted. This is a significant proportion: nearly one in ten submissions could not be processed at all. The most common causes were structural: incorrect ZIP naming conventions, missing required files within the package, and the absence of a completed B_01.01 template for the entity maintaining the register.
Of the submissions that passed integration, only 6.5% passed all 116 data-quality checks. The most frequent failures fell into two categories: missing mandatory information and invalid identifiers. Within the mandatory information category, the provision of identification codes for ICT third-party providers and their parent undertakings was identified as the most problematic area. Within the identifier category, invalid LEIs were the most common finding. Both categories reflect the same underlying challenge: assembling accurate, verifiable information about counterparties that financial entities may have contracted with informally or whose regulatory identifiers they had not previously been required to track precisely.
Mandatory Fields and the Data Point Model
The DPM as a Control Instrument
The data point model is the authoritative reference for mandatory field requirements. The EBA DORA RoI FAQ confirms that mandatory data fields are identified in the Final ITS and in the DPM. For each template, the DPM specifies which fields are mandatory, which are conditional (mandatory only when certain conditions apply), and which are optional. The annotated table layout, available through the EBA’s preparations page, provides this information in a structured format that compliance teams can use as a checklist. Key values (fields that serve as primary identifiers within a template and underpin referential integrity across templates) are explicitly marked in the annotated table. Their treatment is not optional: they are the structural anchors from which the DPM’s relational logic depends.
For compliance teams, the DPM’s practical utility is as a pre-submission control document. Working systematically through the annotated table for each template before generating the reporting package allows completeness issues to be identified and resolved before submission. The alternative, discovering mandatory field gaps through the EBA’s feedback after rejection, is both slower and more disruptive, particularly where the missing information requires engagement with ICT third-party providers to obtain.
Key Values and How to Handle “Not Applicable”
The treatment of key values requires particular care. Because key values anchor cross-template relationships, their absence breaks referential integrity in ways that cascade across the package. The EBA FAQ provides a specific operational instruction for situations where a particular key value is unavailable: the field should be populated with “Not Applicable”. This approach preserves the structural integrity of the linked records and ensures that the submission can be processed consistently, even where a specific value does not exist for a given arrangement. Leaving the field blank is not an acceptable alternative: a blank key value is treated as a missing value, which triggers a data-quality failure.
The same logic applies to conditional mandatory fields. Where a field is mandatory only under specific conditions, compliance teams must identify whether those conditions apply to each record and populate accordingly. Conditions are defined in the DPM and in the reporting instructions contained in the Final ITS. Treating a conditional field as optional without verifying the applicability of the condition is a common source of errors that the DPM review step is designed to prevent.
Where Submissions Most Commonly Failed
The dry run data identified ICT third-party provider identification as the highest-risk area for mandatory field completeness. Financial entities were frequently unable to provide the required identification codes for their ICT providers, and more often still unable to provide codes for those providers’ parent undertakings. This reflects a practical gap: the information is held by the provider, not the client, and many financial entities have not established the contractual or operational arrangements necessary to obtain it reliably. The ESAs have been clear that financial entities should engage with their providers in advance of reporting to secure the data that the register templates require. In practice, this engagement requires lead time, and for providers that operate across multiple jurisdictions or that are subsidiaries of large technology groups, the relevant identifier data may not be routinely shared with customers without a specific request.
Structural Consistency Requirements
The ZIP Package and Its Components
The plain-CSV reporting package has a prescribed structure that must be followed exactly. The EBA’s preparations page sets out the required components: a report.json file, a parameters.csv file, a FilingIndicators.csv file, the table-level CSV files for each reported template, and a META-INF/reportPackage.json file. Each of these files has its own format requirements. The ZIP archive itself must follow the naming convention specified in the reporting package guidance. Deviations from any of these requirements (including differences in file naming, case sensitivity, or directory structure) will cause the submission to fail at the technical layer.
The structural requirement that a submission covers one module, one reference date, and one reporting subject reflects the ESA systems’ processing architecture. Each package is ingested as a discrete unit associated with a specific entity and reference period. A submission that attempts to consolidate multiple entities or reference dates into a single package will not conform to the structure that the systems expect and will be rejected. For groups with multiple legal entities in scope, each of which must maintain its own register, this means preparing separate packages for each reporting subject, even where the underlying ICT arrangements overlap or are shared across group entities.
Parameter Requirements and Filing Indicators
The parameters.csv file carries the core submission metadata. Reporters provide values for three parameters: entityID (the LEI of the reporting entity), refPeriod (the reference date), and baseCurrency. These values tie the submission to the specific entity and period it represents. The FilingIndicators.csv file lists which templates are included in the submission. Together, these two files give the EBA systems a machine-readable summary of the package before any template data is processed, enabling automated routing and validation.
An important operational point follows from the sequential processing model: the EBA systems validate the parameters.csv and FilingIndicators.csv files before processing the template CSV files. Errors in either of these control files, an incorrect LEI in entityID, a malformed reference period, a template listed in FilingIndicators.csv that is not present in the package, or vice versa, will cause the submission to fail at an early stage. Pre-submission checks should verify the consistency of these control files against the template CSV files that are actually included in the package.
Cell-Level Formatting Rules
Formatting requirements apply at the individual cell level within each template CSV file. The reporting package guidance specifies the eba_ prefix for all drop-down values (enumerated fields drawn from the DPM taxonomy), the yyyy-mm-dd format for all date values, and true/false or 1/0 for boolean fields. These rules are technically simple but operationally significant. A date entered as dd/mm/yyyy or a drop-down value entered without the eba_ prefix will fail DPM validation regardless of whether the underlying value is correct. The formatting check is applied before the value check: a correctly identified enumerated value in the wrong format is still an error.
For templates that may contain multiple rows, covering multiple locations, services, or contractual relationships within the same entity, the EBA FAQ is explicit that each additional row must be fully completed and that key values must remain unique across the table. A row with a duplicate key value in a table where uniqueness is required will fail referential integrity checks. Where an arrangement spans multiple rows because, for example, it covers services delivered from several locations, each row carries the full set of required fields independently; they cannot be aggregated or partially populated on the assumption that shared fields will be inherited from an earlier row.
Identifier Accuracy and Its Supervisory Significance
LEIs and EUIDs as Anchors
Identifier accuracy is where the RoI acquires its supervisory value beyond individual entity compliance. The register’s primary purpose, enabling the ESAs to designate critical ICT third-party service providers, depends on being able to identify the same provider consistently across hundreds of different financial entities’ submissions. That consistency is achieved through standardised identifiers: Legal Entity Identifiers (LEIs) for financial entities and for third-country legal persons among ICT providers, and either LEIs or European Unique Identifiers (EUIDs) for ICT third-party providers that are legal persons registered within the EU.
The EBA FAQ specifies where each identifier type applies. Financial entities use LEIs in templates B_01.01 and B_01.02. For ICT third-party service providers in template B_05.01, LEI and EUID form the main identification framework for legal persons. The LEI must be active: the ITS explicitly requires an active LEI, and the business checks layer verifies activity status against GLEIF data. An LEI that was valid when originally obtained but has since lapsed, or that was obtained for a legal entity that has since been restructured, will not pass the business checks layer. Similarly, for EUIDs, the ESAs use BRIS for verification where possible, and the EUID must be formatted correctly: the ITS requires the dot as an integral part of the EUID code, and a submission that omits the dot fails on format grounds before any substantive verification is applied.
Ultimate Parent Undertaking Identifiers
The identification of the ultimate parent undertaking of each ICT third-party provider carries particular importance for the ESAs’ analytical purposes. The EBA FAQ explains that the parent undertaking identifier supports grouping in the ESAs’ analysis, which is to say, it is the field through which the ESAs aggregate multiple ICT providers that ultimately belong to the same corporate group and assess the concentration risk that group represents across the financial sector. An ICT landscape in which several apparently distinct providers are subsidiaries of the same ultimate parent is structurally more concentrated than it appears from the entity-level data alone. The parent undertaking identifier is how the ESAs see through that structure.
For financial entities, this creates a specific due diligence requirement. Identifying the ultimate parent undertaking of an ICT provider requires understanding the provider’s corporate structure, which may be complex, jurisdiction-spanning, and subject to change through acquisition or group reorganisation. This information is not always available from the provider’s standard commercial documentation. It may need to be obtained through direct enquiry or through reference to corporate registry data. Where the ultimate parent is a non-EU entity, the LEI is the applicable identifier, and its active status must be verified against GLEIF.
Contractual Arrangement Reference Numbers
The contractual arrangement reference number is the identifier through which each arrangement is tracked across templates within a single entity’s register and, in group contexts, across the registers of multiple group entities. The EBA FAQ states that contractual arrangement reference numbers should remain consistent and unique across the RoI, and that in group settings, consistent reference numbers support the aggregation and analysis of cross-entity relationships. An entity that assigns different reference numbers to the same arrangement in different templates, or that uses the same reference number for two distinct arrangements, breaks the cross-template linkage that the data model depends on.
This requirement has practical implications for entities that maintain their ICT contract register in systems that were not designed with DORA reporting in mind. Where contract reference numbers are assigned by procurement systems, legal databases, or manual tracking spreadsheets, those reference numbers may not be consistent across the range of templates that reference the same arrangement. Establishing consistent, stable reference numbering and ensuring that reference numbers assigned for DORA reporting are propagated consistently across all relevant templates is a data governance exercise that many entities have found more complex than anticipated.
Building a Submission-Ready RoI in Practice
The review sequence the ESAs apply to incoming submissions also maps directly onto the preparation sequence that financial entities should follow. Beginning with technical and structural conformity, then addressing mandatory field completeness, then verifying identifier accuracy, mirrors the order in which errors will be caught – and ensures that the most consequential errors (those that prevent a submission from being processed at all) are resolved first.
The first workstream in any RoI preparation cycle should be a structural audit of the reporting package. Before template data is populated, the package architecture (file names, directory structure, control files, and the consistency of FilingIndicators.csv with the templates actually included) should be verified against the specifications in the reporting package guidance. This step is often deferred until after data population, but should logically precede it: a correctly structured package with data errors can be corrected; a structurally non-conforming package cannot be processed regardless of the quality of its data.
The second workstream is a systematic DPM review for mandatory and key field completeness. Working through the annotated table layout for each template and confirming that every mandatory field has a value, or, where the correct value is “Not Applicable”, that the field has been populated accordingly, identifies completeness gaps before submission. Where mandatory information requires engagement with ICT providers (notably, parent undertaking identifiers and provider identification codes), that engagement should be initiated early enough in the preparation cycle to allow for the time providers typically require to respond.
The third workstream is an identifier review. For each LEI appearing in the register, active status should be confirmed against GLEIF immediately before submission – not at the start of the preparation cycle, since LEI status can change. For each EUID, the format should be verified and the entity confirmed against BRIS. Contractual arrangement reference numbers should be checked for uniqueness within each template and consistency across templates. This workstream is often the most time-consuming, particularly for entities with large and complex ICT provider landscapes, but it is also the workstream whose failures are most visible to regulators: identifier errors are verified against external reference sources, making them objectively identifiable in a way that completeness gaps sometimes are not.
Entities that prepare their RoI using the EBA’s validation tools (available through the EBA’s preparations page) can run the technical and DPM validation checks locally before submission, identifying errors that would otherwise surface only after the submission reaches the EBA systems. This step does not replicate the business checks layer (external LEI and EUID verification is not performed locally), but it catches the majority of structural and completeness errors and substantially reduces the probability of integration-stage rejection.
The UK Parallel: PS26/2 and the FCA Third-Party Register
The Register of Information obligation under DORA applies to EU-authorised financial entities. UK-authorised firms, such as authorised payment institutions (APIs) and authorised electronic money institutions (AEMIs) regulated solely by the FCA, are outside DORA’s territorial scope. That does not, however, mean they face no equivalent obligation. Policy Statement PS26/2, published by the FCA on 18 March 2026 and coming into force on 18 March 2027, establishes a UK framework for operational incident reporting and third-party register maintenance that pursues the same supervisory objective as DORA from an independent legal basis. The FCA has been explicit that the regime is designed to give it structured, machine-readable visibility into firms’ supply chain dependencies, enabling it to identify systemic ICT concentration risk across the UK financial sector in a way that fragmented, firm-by-firm incident reporting has never permitted.
The PS26/2 third-party reporting framework applies to a defined subset of firms that includes AEMIs and APIs as named categories. Under the new rules, any third-party arrangement whose disruption or failure could cause intolerable harm to clients, threaten the firm’s ability to satisfy its regulatory threshold conditions, or pose a risk to UK financial system stability or integrity is considered material and subject to the regime’s obligations. Those obligations run in three directions: notification to the FCA of any new material arrangement through Connect, notification of any significant change to an existing material arrangement, and annual submission of the complete third-party register through RegData. The register and notification templates are standardised across the FCA, PRA, and Bank of England, submitted through a single portal regardless of which regulator a firm’s primary obligation runs to.
Structure of the PS26/2 Register and Its Similarities to the DORA RoI
The PS26/2 third-party register shares its essential logic with the DORA RoI. Both require firms to maintain structured records of their ICT and operational third-party arrangements at a field level sufficient to support supervisory analysis. Both link the register obligation to a broader supervisory strategy: under PS26/2, the FCA has stated that the data will be used to “see through firms’ supply chains” to identify systemic exposures and potential candidates for designation under the Critical Third Parties regime introduced by the Financial Services and Markets Act 2023. Under DORA, the CTPP designation process serves the identical function. In both regimes, the register is less a compliance document than a supervisory intelligence instrument, and its value to the regulator depends directly on the accuracy and consistency of the data it contains.
The practical differences, however, are meaningful. The FCA’s submission infrastructure – RegData and Connect – is more mature and more extensively documented than the EBA’s plain-CSV architecture was at the time DORA entered into force. The FCA has also published detailed practical guidance in FG26/3 and FG26/4 covering threshold interpretation, template completion, and provider engagement, reducing some of the definitional uncertainty that characterised the early DORA implementation period. The scope of firms subject to the PS26/2 third-party reporting regime is also narrower than DORA’s, reflecting the FCA’s proportionality argument: the obligations target the firms whose supply chain dependencies are large enough to carry systemic significance at a UK sector level.
The Incident Classification Challenge
PS26/2 bundles third-party register maintenance and operational incident reporting into a single regime, whereas DORA separates the two obligations across different parts of the regulation: the RoI sits under Article 28, while incident reporting is governed by Articles 17–23, supported by Commission Delegated Regulations 2024/1772 (classification criteria) and 2025/301 (reporting content) and Commission Implementing Regulation 2025/302 (templates). DORA’s incident reporting framework has been a live obligation since 17 January 2025, with structured initial, intermediate, and final report timelines of 4 hours, 72 hours, and one month, respectively, and harmonised classification criteria that substantially reduce the scope for firm judgment. PS26/2’s incident obligation is, by contrast, outcomes-based: an incident is reportable where it disrupts service delivery to end users, or affects the availability, authenticity, integrity or confidentiality of end-user data, at a level causing intolerable harm from which consumers cannot easily recover. The FCA has explicitly preserved firm judgment in applying that threshold rather than introducing quantitative metrics, making the UK standard arguably less prescriptive than the DORA framework it parallels – a meaningful difference for dual-regime firms calibrating their classification logic across both obligations.
The practical difficulty this creates is one of real-time classification under operational pressure. A firm experiencing a payment processing outage must simultaneously manage the incident, communicate with affected customers, and make a defensible legal assessment of whether the disruption crosses the harm threshold – not in the abstract, but against its own specific customer base characteristics. FG26/3 provides worked examples and scenario-based guidance on applying the threshold, but the guidance explicitly preserves firm judgment rather than introducing quantitative metrics. Firms that have not pre-built classification logic into their incident management runbooks will find themselves improvising under conditions where improvisation is most likely to produce the kind of inconsistency that attracts supervisory attention after the fact.
Dual-Regime Obligations for Cross-Border Entities
The most operationally significant implication of PS26/2 for many payment institutions and e-money institutions is that it does not operate in isolation. Firms that hold both EU authorisation, as a payment institution or e-money institution licensed in an EEA member state, and FCA authorisation face four parallel obligations: the DORA RoI and DORA major incident reporting under Article 19, and the PS26/2 third-party register and PS26/2 incident reporting, each running on its own regulatory timeline and through its own submission channel. This is a common profile among fintech firms that established EU entities post-Brexit while retaining their UK-regulated entity. For those firms, the underlying data (provider identities, service descriptions, contractual reference numbers, parent undertaking details, concentration metrics) is substantially the same in both registers, even though the submission formats, technical specifications, and submission channels differ.
The annual cycle creates a compounding governance burden. The DORA RoI reference date is 31 December, with the NCA transmission to the ESAs due by 30 April of the following year. The PS26/2 register runs on a separate annual cycle with a 90-calendar-day submission window from the opening of the RegData submission period. Maintaining two register submissions derived from the same underlying third-party arrangements, in two different formats, through two different submission channels, on two different regulatory timelines, is a data management challenge that compounds with each new material arrangement a firm adds. The alternative, maintaining a single source of truth about third-party arrangements from which both submissions are generated, is the more sustainable approach and the one that purpose-built tooling is best placed to support.
A Note on Tooling: One Framework or Two?
The preparation and maintenance of ICT third-party registers under both DORA and PS26/2 is, at its core, a structured data management problem. The constraints imposed by each regime – machine-readable formats, governed field values, external identifier verification, cross-template referential integrity under DORA, and standardised FCA templates with annual submission deadlines under PS26/2 – require tooling that enforces those rules during data entry and review, not only at the point of export or submission.
For firms subject to only one of the two regimes, purpose-built tooling aligned to that regime’s data model provides the most direct path to submission-ready registers. For firms facing both obligations, and there are many, given the cross-border operating profiles common in the payment institution and e-money institution sectors, the more valuable capability is a platform that maintains a single, authoritative record of third-party arrangements and generates compliant outputs for both the EBA’s DPM and the FCA’s RegData template. That approach avoids the duplication, inconsistency, and reconciliation overhead that arises when two separate point solutions draw from different data sources.
The Copla DORA registry platform is built around the DORA RoI requirements and supports financial entities in structuring, validating, and maintaining their registers in a format aligned with the EBA’s technical specifications. As the PS26/2 regime takes effect and UK firms face structurally similar register obligations from March 2027, Copla’s capabilities extend naturally to supporting that parallel compliance need. For firms evaluating how to manage their third-party register obligations across both the EU and UK regulatory environments, understanding what the platform offers is a practical starting point.
