Parsing the MiFIR consolidated tape: data requirements for DRSPs

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

Why the DRSP data architecture question is distinct from the CTP selection question

ESMA's selection of consolidated tape providers for bonds, equities, and OTC derivatives has been well covered as a market structure development: which entity won the tender, when authorisation is expected, and how revenue redistribution will work. That is a different question from the one facing data reporting service providers (DRSPs), meaning approved publication arrangements (APAs), approved reporting mechanisms (ARMs), and trading venues that are obligated to contribute data to the tape.

For DRSPs and trading venues, the operative question is technical: what format, what latency, what fields, and what quality controls does the RTS actually require for the data they transmit. This is governed by a separate set of regulatory technical standards from the CTP selection and authorisation process, and it is the layer where engineering teams, not just compliance teams, need to be working.

The legal basis: RTS on input and output data, transmission protocols, and business clocks

The technical standards governing DRSP data contribution derive from Commission Delegated Regulation (EU) No 600/2014 (MiFIR) as amended, specifically the mandate for regulatory technical standards specifying the input and output data of consolidated tapes, the synchronisation of business clocks, and revenue redistribution by the equity CTP. This RTS repeals the earlier Delegated Regulation (EU) 2017/574, which governed business clock synchronisation under the original MiFID II framework.

ESMA's final report and the underlying draft RTS were developed through a staged consultation process. The first and second consultation packages, covering minimum requirements for transmission protocols, technical data formats, the definition of real time, data quality measures, and enforcement standards, were followed by a third package addressing the specific substance of input and output data for the equity CTP. The Commission adopted Commission Delegated Regulation (EU) 2025/1155, and it now forms the operative RTS for equity and ETF data contribution, alongside the parallel provisions applicable to bonds.

For DRSPs, this RTS is the primary engineering specification. It answers the questions that matter for building a compliant contribution pipeline: what latency is acceptable, what protocol-level requirements apply, what fields are mandatory, and how timestamps must be formatted.

Transmission protocol requirements: the four technical categories

The RTS organises transmission protocol requirements into four categories of technical criteria: performance, reliability, security, and compatibility. These requirements apply to data contributors, meaning trading venues and APAs transmitting data to the CTP, not to the CTP's own dissemination of consolidated output.

Performance requirements

The performance category sets concrete numeric thresholds rather than principles-based standards. For shares and ETFs, latency in transmitting data to the CTP must be maintained below 50 milliseconds. For bonds, the threshold is materially looser, below 500 milliseconds, reflecting the lower trading frequency and less latency-sensitive nature of bond markets relative to equities.

Beyond latency, the RTS addresses throughput and connection setup. Earlier consultation proposals set throughput requirements above 100 megabits per second and round trip time for connection setup below 500 milliseconds, with protocols required to support operation in clustered or load-balanced environments. These figures were subject to industry feedback during consultation, including concerns that the same numeric thresholds might not be appropriate across venues handling materially different volumes of activity, and the final calibration reflects that feedback.

Critically, latency is measured at a specific point: from the data contributor's outbound transmission to the CTP's inbound receipt. This measurement point matters operationally, because it excludes latency introduced by the CTP's own internal processing and dissemination, and it means a data contributor cannot rely on downstream CTP processing time as a buffer against its own transmission delay.

The "as close to real time as technically possible" definition

MiFIR's level 1 text requires data to be transmitted "as close to real time as technically possible," a phrase that needed level 2 specification to be operationally meaningful. The RTS defines this concretely for post-trade data: no later than 50 milliseconds from the execution timestamp for transactions executed on a trading venue, and 50 milliseconds from the execution timestamp for transactions reported by an APA on behalf of an investment firm executing off-venue.

This distinction between on-venue and APA-reported timing matters for DRSP architecture. A trading venue's data pipeline and an APA's data pipeline are subject to different tolerances, and a DRSP that operates both functions needs to track compliance against two separate thresholds rather than a single uniform standard.

Reliability, security, and compatibility

The reliability category addresses resilience: protocols need to tolerate network interruption without silent data loss, and contributors need failover capability that does not introduce material additional latency. The security category, which drew pushback during consultation from respondents who considered some proposed encryption requirements redundant given that CTPs are not expected to modify contributed data, nonetheless retains baseline requirements for data integrity in transit. Compatibility requirements address the practical reality that DRSPs and CTPs need to interoperate across a range of underlying network architectures, referencing the OSI model's seven layers explicitly in ESMA's technical standards documentation to anchor where in the stack each requirement applies.

Timestamp format: a settled requirement that still generates interpretive questions

Business clock synchronisation and timestamp format are governed by Commission Delegated Regulation (EU) 2025/1155, which requires trading venues subject to business clock obligations to achieve a granularity of 0.1 microseconds. The timestamp fields transmitted to the CTP must follow the ISO 8601 date-time format with six decimal places representing fractions of a second in microseconds, formatted as YYYY-MM-DDThh:mm

Even with this level of specification, ESMA's Q&A function continues to field interpretive questions. In an April 2026 Q&A, ESMA clarified that dissemination of timestamps at the 0.1 microsecond business clock granularity in existing market data feeds does not automatically satisfy the RTS requirement to provide timestamps to CTPs at the specified six-decimal-place precision; the two requirements, business clock granularity and CTP timestamp transmission format, are related but distinct obligations. DRSPs relying on existing market data feed timestamp output without explicit mapping to the CTP transmission format risk a compliance gap that is not obvious from the RTS text alone.

This pattern, a numerically specific requirement still generating live interpretive questions eighteen months after the underlying RTS entered into force, is a useful signal for DRSP engineering teams: treating the RTS as a static specification, read once and implemented, understates the ongoing monitoring burden. ESMA's Q&A output functions as a rolling addendum to the technical schema.

Core market data: what must actually be transmitted, by asset class

The substance of "core market data," meaning the specific fields a CTP must disseminate and therefore that data contributors must transmit, differs by asset class in ways that matter for DRSP schema design.

For shares and ETFs, core market data includes the European best bid and offer with corresponding volume, transaction price and volume, applicable waivers and deferrals, standardised instrument identifiers, and timestamp data covering execution, order entry, and dissemination. A deliberate design choice in the RTS is that the CTP does not publish the market identifier code of the venue when disseminating the European best bid and offer; this is intended to reduce the informational advantage of direct venue feed subscribers relative to CTP subscribers, and it means DRSP output schemas need to support field suppression at the dissemination layer even where the same field is present in the input data.

For bonds, the tape covers post-trade data only: transaction price and quantity, venue identifier, standardised instrument identifier, and timestamp data. Pre-trade data is explicitly out of scope for the bond tape, which simplifies the bond CTP's input schema relative to equities but means DRSPs supporting both asset classes need materially different pipelines rather than a shared one with asset-class flags.

For OTC derivatives, the tape covers post-trade data including identifying reference data based on a globally agreed unique product identifier, specifically the ISO 4914 Unique Product Identifier (UPI), replacing the ISIN-based approach used for equities and, historically, for some derivatives reference data. This is a structurally different identifier regime from the other two asset classes, and DRSPs building OTC derivatives contribution pipelines need to plan for UPI resolution and mapping as a distinct data engineering task, not an extension of existing ISIN-based reference data infrastructure.

The OTC derivatives tape: later, and still being finalised

The OTC derivatives consolidated tape sits on a materially different timeline from equities and bonds, and DRSPs should not assume the technical requirements finalised for those asset classes will simply transfer.

ESMA's OTC derivatives CTP selection procedure launched on 5 January 2026, with Etrading Software (Netherlands) B.V. selected on 6 July 2026. In parallel, ESMA published its final report under the MiFIR review on derivatives transparency, package orders, and the input and output data for the OTC derivatives consolidated tape, submitting the final draft RTS to the Commission, which then had three months to decide whether to endorse them. Industry commentary places the expected application date for the new derivatives transparency and reporting rules at 1 March 2027, materially later than the equity and bond frameworks.

The final report reflects a "simplification and burden reduction" principle that ESMA applied specifically to the derivatives package: consolidating all derivative-related amendments into a single review, setting one application date across the relevant RTS, removing a transparency reporting obligation to ESMA that had been under consideration, and using static thresholds that do not require annual recalibration. For DRSPs, this means the OTC derivatives technical schema, when finalised, is likely to be simpler in some respects than the equity framework's evolving calibration, but it will not exist in final form until the Commission's endorsement decision and subsequent Official Journal publication.

Transaction and order book reporting: RTS 22 and RTS 24 remain largely unchanged

A separate but related question for DRSPs, particularly ARMs handling transaction reporting under Article 26 of MiFIR, is whether the underlying transaction data and order book data reporting standards, RTS 22 and RTS 24 respectively, would be revised as part of the MiFIR review. ESMA's consultation on this question, launched in October 2024, concluded that it would not propose substantive changes to either RTS at this stage, opting instead to focus effort on the consolidated tape and market data pricing standards. This means ARMs can treat the existing RTS 22 and RTS 24 field specifications as stable for now, which is a useful point of continuity in an otherwise fast-moving technical standards environment. ESMA's March 2024 public statement, building on the Commission's interpretative notice, clarified that Level 1 rules in force prior to the MiFIR review, together with RTS 22 and RTS 24, continue to apply until any revised versions become applicable.

Summary: key technical parameters by asset class

What DRSPs and trading venues should be building now

For entities already contributing to the equity or bond tape, the immediate technical task is confirming that transmission protocol performance, particularly the latency measurement from outbound transmission to CTP inbound receipt, is being tested and monitored against the specific asset-class threshold, not against a single internal standard applied uniformly. The measurement point defined in the RTS is precise enough that internal testing needs to replicate it exactly to be meaningful.

For entities anticipating OTC derivatives contribution obligations, the practical preparation task is UPI infrastructure, since this is a materially different reference data regime from the ISIN-based approach used elsewhere, and it cannot be retrofitted quickly once the final RTS and application date are confirmed. Waiting for the Commission's endorsement decision before beginning UPI mapping work compresses an already tight timeline further.

For all DRSPs, monitoring ESMA's Q&A output on the CTP input and output data RTS is not optional. The timestamp granularity clarification issued in April 2026 demonstrates that the published RTS text, however numerically specific, does not resolve every implementation question, and ESMA's Q&A mechanism is where those gaps get filled in practice.

For the market structure context behind the CTP selection process and the reasonable commercial basis pricing reforms, see the EU consolidated tape: how MiFIR amendments change market data sourcing. For how EU technical standards move from consultation to binding law, see what are regulatory technical standards and why do they matter more than the regulation itself. For the ISIN-based instrument reference data underlying MiFIR reporting obligations, see the ESMA FIRDS directory.

Forseti monitors ESMA technical standards, Q&A updates, and CTP authorisation developments continuously, anchored to verified official sources including EUR-Lex and ESMA publications. Start for free.