DORA for Trade Repositories: Operational Resilience in Regulatory Data Infrastructure
The Invisible Infrastructure
Trade repositories (TRs) are perhaps the least visible but most critical component of post-crisis financial market infrastructure. Created by the G20 Pittsburgh declaration in 2009 and mandated in Europe through EMIR (for derivatives) and SFTR (for securities financing transactions), TRs collect, maintain, and provide access to the transaction data that supervisors need to monitor systemic risk, market abuse, and counterparty exposure.
When a trade repository's ICT systems are unavailable, the consequences are not immediately visible to the public. There are no frozen ATMs or failed payments. But the supervisory consequences are severe: regulators lose visibility into market positions, systemic risk monitoring is degraded, and the reporting entities that depend on the TR for their regulatory obligations face compliance failures.
DORA Article 2(1)(d) explicitly includes "trade repositories" in scope. This is not incidental — it reflects the recognition that regulatory data infrastructure is critical financial infrastructure, and that its operational resilience deserves the same attention as the resilience of banks, CCPs, and payment systems.
The Unique TR Risk Profile
Trade repositories face a distinctive set of operational resilience challenges that differ from other DORA-regulated entities:
| Challenge | TR-specific dimension | DORA provision |
|---|---|---|
| Data integrity | Transaction records must be complete, accurate, and immutable — supervisory decisions depend on them | Art. 8 (asset identification), Art. 9 (protection) |
| Reporting availability | Entities must be able to submit reports continuously; any outage creates a backlog that may trigger regulatory breaches | Art. 11 (business continuity), Art. 12 (backup/recovery) |
| Supervisor access | ESMA and NCAs must have uninterrupted access to TR data for systemic risk monitoring | Art. 11, Art. 17-23 (incident reporting) |
| Cross-border data | TRs hold data from entities across all 27 EU member states; data residency and access requirements vary | Art. 28-30 (third-party risk, data location) |
| Concentration | Only a handful of TRs operate in Europe (DTCC GTR, Regis-TR, KDPW, UnaVista, CME) — a single TR outage affects thousands of reporting entities | Art. 29 (concentration risk) |
DORA Obligations Layered on EMIR/SFTR
TRs already operate under demanding regulatory requirements. EMIR Art. 78-81 and the EMIR RTS on TR operational standards specify requirements for data integrity, business continuity, and operational risk. DORA adds a more structured and prescriptive layer:
ICT Risk Management Framework (Art. 5-16)
TRs must maintain a board-approved ICT risk management framework that covers:
- ICT asset register: Complete inventory of all systems involved in data receipt, processing, storage, dissemination, and supervisory access
- Risk assessment: ICT risks specific to TR operations — data corruption, reporting channel unavailability, unauthorized data access, data loss
- Data classification: Transaction data is highly sensitive — classification must reflect the systemic sensitivity of aggregated position data
- Backup and recovery: Near-zero RPO for transaction data; any data loss means missing regulatory records
| TR data category | Classification | RTO | RPO | Rationale |
|---|---|---|---|---|
| Transaction records (live) | RESTRICTED | <2 hours | 0 (zero loss) | Core regulatory data |
| Historical records | CONFIDENTIAL | <4 hours | <1 hour | Audit and investigation data |
| Supervisory access portal | CONFIDENTIAL | <1 hour | N/A | Supervisor real-time access |
| Reporting channels (inbound) | CONFIDENTIAL | <2 hours | 0 | Entity reporting capability |
| Aggregated position data | RESTRICTED | <2 hours | <15 minutes | Systemic risk monitoring |
Incident Reporting (Art. 17-23)
A TR ICT incident has cascading effects. If the TR cannot receive reports, every reporting entity is potentially non-compliant with EMIR reporting obligations. If the TR cannot provide data to supervisors, systemic risk monitoring is degraded.
The incident reporting pipeline for a TR must account for:
- ESMA notification: ESMA directly supervises EU TRs — ESMA is the NCA for incident reporting purposes
- Reporting entity notification: TRs must notify their reporting entities of outages that affect submission capability
- Supervisor notification: NCAs relying on TR data for supervision must be informed of data availability issues
Resilience Testing (Art. 24-27)
TRs should expect to be designated for mandatory TLPT given their systemic importance. The testing must cover:
- Data ingestion channels (connectivity, validation, processing)
- Data storage and retrieval (database integrity, query performance under load)
- Supervisory access (portal availability, data export capabilities)
- Data reconciliation (accuracy of aggregated positions)
- Disaster recovery (failover to backup site with zero data loss)
Third-Party Risk (Art. 28-30)
TRs depend on technology providers for infrastructure, data validation services, network connectivity, and cloud hosting. The third-party register must document these dependencies, and the concentration risk analysis must assess the impact of provider failure.
A specific TR concern: many TRs provide services to each other through data portability mechanisms (required under EMIR for TR switching). This inter-TR dependency creates a unique third-party risk dimension.
Data Integrity: The TR's Primary Resilience Objective
For a bank, the primary resilience objective is service availability — customers must be able to transact. For a TR, the primary objective is data integrity. An available TR that serves incorrect data is worse than an unavailable TR that preserves correct data. Incorrect aggregated position data could mislead supervisors about systemic risk concentrations.
This means that TR resilience architecture must prioritize:
- Data immutability: Transaction records, once validated and accepted, must not be modifiable except through formally controlled amendment processes
- Data completeness: Every transaction submitted must be accurately recorded — no silent drops or incomplete processing
- Data consistency: Aggregated positions must accurately reflect the underlying transactions — reconciliation must be continuous
- Data availability: Subject to integrity — data is made available only when its correctness is confirmed
This priority ordering — integrity > completeness > consistency > availability — differs from the typical banking priority of availability > integrity.
The Portability Challenge
EMIR requires that reporting entities must be able to switch between trade repositories. This portability requirement creates a unique operational resilience dimension: TRs must be able to export complete transaction histories to a competing TR in a structured format, and receiving TRs must be able to ingest and validate those histories without data loss.
From a DORA perspective, portability is both a resilience mechanism and a resilience challenge:
As a mechanism: Portability reduces concentration risk. If a TR experiences a prolonged outage, reporting entities can switch to an alternative TR, maintaining their regulatory reporting obligations.
As a challenge: The portability process itself must be resilient. A TR migration that loses transactions, corrupts data, or creates duplicate records is worse than no migration at all. The sending TR must maintain data availability and integrity throughout the transition period, and the receiving TR must validate data completeness post-migration.
The exit strategy required under Art. 28(8) must, for TRs, include specific provisions for data portability — not just in theory, but tested in practice. ESMA has historically required TRs to demonstrate portability capability as a condition of registration.
Market Integrity Implications
The intersection of DORA and market integrity regulation creates a heightened compliance landscape for TRs. Under the Market Abuse Regulation, aggregated position data from TRs can be market-sensitive information. An unauthorized disclosure of large position concentrations — whether through a data breach or an operational error — could constitute market abuse.
This means that a TR's ICT security posture has direct market integrity implications. A successful cyberattack on a TR that exfiltrates position data is not just a privacy incident — it is a potential market abuse enabling event. The data classification framework for TRs must reflect this dual sensitivity: regulatory data sensitivity and market abuse sensitivity.
Supervisory Expectations
ESMA directly supervises EU trade repositories. DORA's requirements will be assessed through ESMA's existing supervisory engagement framework, supplemented by the ESA coordination mechanisms established under DORA Art. 46-49.
ESMA's supervisory expectations for TR operational resilience include:
| Expectation | Evidence required | Assessment method |
|---|---|---|
| ICT risk framework adequacy | Board-approved framework, annual review records | Document review + supervisory visit |
| Board reporting quality | Art. 14 compliant reports, board minutes | Sample review |
| Incident reporting timeliness | All incident records with timestamps | Automated monitoring |
| Data integrity controls | Reconciliation logs, amendment audit trail | Operational assessment |
| Business continuity testing | Test results with measured recovery metrics | Test observation and evidence review |
| Third-party governance | Register of information, concentration analysis | Document review |
Use the DORA readiness assessment to evaluate your TR's operational resilience posture, review the pillars overview for the complete DORA requirements, and consult the glossary for regulatory definitions applicable to financial market infrastructure.
Conclusion
Trade repositories are the regulatory data infrastructure that enables supervisors to monitor systemic risk in real time. Their operational resilience is not just an institutional concern — it is a market integrity concern. DORA's application to TRs recognizes this by applying the full regulatory framework without proportionality reduction, with ESMA as the direct supervisor and data integrity as the primary resilience objective. The TRs that demonstrate robust ICT risk management, tested recovery capabilities, and comprehensive third-party governance will maintain their position as trusted regulatory data custodians. Those that do not will face ESMA scrutiny that is both thorough and consequential.
Resume en francais
Les referentiels centraux (TR) sont l'infrastructure de donnees reglementaires qui permet aux superviseurs de surveiller le risque systemique en temps reel. L'article 2(1)(d) de DORA les inclut explicitement dans son perimetre. Cet article analyse le profil de risque unique des TR (integrite des donnees, disponibilite du reporting, acces des superviseurs, donnees transfrontalieres, concentration), les obligations DORA superposees aux exigences EMIR/SFTR existantes, et les specificites de mise en oeuvre : le cadre de gestion des risques TIC avec des objectifs de recuperation proches de zero pour les donnees transactionnelles, le signalement des incidents avec notification triple (ESMA, entites declarantes, ANC), les tests de resilience incluant le TLPT probable, et la gouvernance des tiers. L'objectif de resilience principal d'un TR est l'integrite des donnees, pas la disponibilite — un TR disponible servant des donnees incorrectes est pire qu'un TR indisponible preservant des donnees correctes.