What are regulatory technical standards and why do they matter more than the regulation itself?

The regulation is not the whole story

When a new EU financial regulation passes, most compliance teams start reading the regulation. That is the right instinct but it gets them only part of the way there.

EU financial regulation is structured in layers. The headline regulation, the text that passes through the European Parliament and gets published in the Official Journal of the European Union, establishes the framework. It sets out who is in scope, what obligations exist in broad terms, and which authorities are empowered to develop the detail.

The detail lives elsewhere. It lives in regulatory technical standards, implementing technical standards, delegated acts, and supervisory guidance. For most firms, the regulatory technical standards (RTS) are where the actual compliance requirements are specified, and they arrive later than the headline regulation, on their own publication schedule.

A firm that reads the regulation and considers itself informed is working with an incomplete picture. A firm that tracks the RTS is doing compliance properly.

What a regulatory technical standard actually is

An RTS is a legal instrument developed by a European supervisory authority (ESA) under a mandate from a parent regulation. The three ESAs that produce most of the RTS relevant to financial services are the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA).

The mandate works like this: the regulation passes and includes provisions that say, in effect, “the competent authority shall develop technical standards specifying X.” The ESA then consults with industry, produces a draft, submits it to the European Commission for endorsement, and the Commission adopts it as a delegated regulation. At that point the RTS has binding legal force across all EU member states.

The distinction from implementing technical standards (ITS) is worth noting. An RTS specifies substantive requirements: what firms must do and how. An ITS specifies procedural or format requirements: how firms must report it, in what template, using what data fields. Both matter, but the RTS is where firms find the obligations that require operational change.

Why the RTS matters more than the headline regulation

The best illustration is the Digital Operational Resilience Act (DORA), which entered into force in January 2023 under CELEX number 32022R2554 and became applicable to financial entities in January 2025.

Reading DORA tells you that in-scope financial entities must implement ICT risk management frameworks, report major ICT-related incidents, manage ICT third-party risk, and conduct digital operational resilience testing. These are significant obligations. But DORA does not tell you what your ICT risk management framework must contain. It does not tell you the specific criteria that make an incident reportable, the classification thresholds, or the timeline for submitting initial, intermediate, and final reports. It does not tell you what your contracts with critical ICT third-party providers must include.

The Joint Committee of the ESAs developed twelve RTS and ITS under DORA mandates. Those documents answer the questions that DORA leaves open. They specify the content requirements for ICT risk management frameworks. They define the incident classification criteria. They set out the contractual provisions required for third-party ICT agreements.

A compliance team that read DORA in 2023 and stopped there did not know, from the regulation alone, what they actually needed to build. The RTS told them.

The same logic applies to the Markets in Crypto-Assets Regulation (MiCA), which passed under CELEX number 32023R1114. MiCA establishes the authorisation requirements for crypto-asset service providers (CASPs) and the issuance requirements for asset-referenced tokens and e-money tokens. But the authorisation process itself, the information that must be included in an application, the governance and organisational requirements in detail, the liquidity stress test methodology for reserve assets, these are in the RTS that ESMA and EBA have developed under MiCA mandates.

The timing problem

There is a structural feature of EU financial regulation that creates compliance risk even for teams that understand the RTS system: the RTS often arrive late.

A regulation passes and sets a compliance date. The ESAs then have a development window, typically twelve to eighteen months, to produce the RTS under each mandate. The Commission then takes additional time to endorse and adopt them. In practice, some RTS arrive close to, or even after, the compliance date they are meant to specify.

This is not a theoretical problem. Firms building DORA-compliant ICT risk management frameworks in 2024 were working with draft RTS, not final ones. Positions shifted between consultation drafts and final texts. Teams that had built to the draft had to revisit their work.

The implication is that tracking the headline regulation and waiting for the RTS to arrive before taking action is not a viable strategy. Firms that track the full legislative pipeline from proposal through RTS development can begin building to the likely requirements earlier, monitor for changes between draft and final, and avoid being caught by last-minute revisions.

How RTS are published and where to find them

RTS are published in two places. Draft versions, consultation papers, and final draft submissions to the Commission are published on the relevant ESA’s website: eba.europa.eu for EBA documents, esma.europa.eu for ESMA documents. Final adopted versions are published in the Official Journal of the European Union and indexed in EUR-Lex with their own CELEX identifiers.

Each adopted RTS has a CELEX number structured as a delegated regulation or implementing regulation, depending on the type. For example, the DORA RTS on ICT risk management tools adopted in January 2024 has its own CELEX number distinct from DORA’s. Tracking the full corpus of RTS under a given regulation means monitoring not just one CELEX identifier but multiple ones, published on different dates.

For a firm tracking MiCA, for example, the relevant corpus includes MiCA itself (CELEX 32023R1114), plus all the RTS and ITS that ESMA and EBA have developed under MiCA mandates, each with its own publication date, consultation history, and effective date. That is a meaningful monitoring workload that does not reduce to reading a single document.

What this means in practice

For a compliance team, the practical implication of the RTS structure is that compliance readiness requires monitoring two things simultaneously: the headline regulation and its implementation timeline, and the RTS development pipeline under each mandate.

The questions to ask for any regulation in scope are: which ESA holds each mandate, what is the expected delivery timeline for each RTS, what has been published in consultation, and where do the draft requirements currently stand relative to what has been built.

For a fintech founder assessing regulatory exposure, the implication is slightly different: the regulation tells you whether you are in scope, but the RTS tells you what being in scope actually costs in terms of operational change. Scope decisions made before the RTS are made on incomplete information.

For a boutique investment manager or compliance professional at a small firm, the implication is that the monitoring workload is larger than the headline regulation count suggests. Five regulations in scope does not mean five documents to track; it means five regulations plus however many RTS and ITS mandates each one carries.

Forseti, Citium’s EU regulatory intelligence platform, is in development and will monitor EU financial regulation continuously, including adopted RTS and implementing technical standards anchored to verified EUR-Lex sources with full CELEX traceability. If you want to be kept informed ahead of launch, get in touch.