Connecting to the EU Consolidated Tape: What EuroCTP Selection Means for Your Data Plumbing

The EU now has a named consolidated tape provider for shares and ETFs, and that turns a decade of policy argument into an engineering task with a delivery date. The question on the table is no longer whether the tape happens. It is where it plugs into your market-data plumbing, and what breaks when it does.

On 19 December 2025, ESMA selected EuroCTP as the first consolidated tape provider for shares and ETFs, following the selection process it launched in June 2025. EuroCTP is a Netherlands-based joint venture owned by a group of European exchange operators, invited to apply for authorisation and then to run the tape for five years under ESMA’s direct supervision. The legal basis is the MiFIR review, Regulation (EU) 2024/791, which amended the original MiFIR to remove the obstacles that had kept a pan-European tape from emerging. A separate provider, Ediphy, was selected earlier for the bonds tape. This post is about the shares and ETF tape and what consuming it does to your architecture.

Most of what you will read about the tape frames it as a market-structure story: better transparency, a level playing field, a step towards Capital Markets Union. All true, and none of it tells you where to put the connector. The tape is a new authoritative feed arriving into estates that already have venue feeds, vendor consolidators and a reference-price model that predates it. Retrofitting it late, into pipelines that were never designed to carry it, is the expensive way to do this.

What the tape actually is, as a feed

Strip away the policy language and the consolidated tape is a single electronic stream that combines trade reports and quotes from across the EU’s trading venues and approved publication arrangements into one continuous feed, carrying a consolidated European best bid and offer. For a firm that today stitches together a partial picture from a handful of venue connections and a commercial data vendor, that is a materially different input: broader coverage, a common format, and — this is the part that changes governance — a status as the regulatory reference for what the market was doing at a point in time.

The precise latency, distribution mechanism and licensing terms follow from EuroCTP’s authorisation and its published specifications, so treat any specific number you see today as provisional until the specification is final. What you can design against now is the shape of the thing: a high-volume, normalised, consolidated stream that you will consume, store and reconcile against feeds you already run. The uncertainty is in the parameters, not the pattern.

Where it lands in your architecture

There are three honest options for what the tape does to your existing market-data plumbing, and you should decide which one you are building before you write any code.

Supplement. The tape sits alongside your current feeds as an additional, authoritative source used for specific purposes — best-execution evidence, transaction-cost analysis, reference pricing in reporting — while your latency-sensitive paths keep running on direct venue connections. This is the low-regret starting position for most firms, because it adds a source without ripping out a working one.

Displace. The tape replaces a commercial consolidated feed you currently pay for. This is where the business case lives, but it is also where the risk lives: you are swapping a mature vendor product with known coverage and support for a new service still proving its operational record. Displacement is a phase-two decision, taken once the tape has a track record, not a launch-day bet.

Reconcile-only. You never route decisions off the tape, but you continuously compare it against your existing consolidated view as a control — a way of catching gaps in your own coverage. Cheap, defensible, and a good first integration even if you intend to go further later.

These are not mutually exclusive over time, but on day one you are building one of them. The mistake is to leave it implicit and let the integration drift into a de facto dependency nobody signed off.

The normalisation layer is the real work

Whatever role the tape plays, you have to land its records in your internal market-data model, not consume its wire format directly throughout your systems. The tape’s schema is the tape’s; your book of code speaks your own instrument identifiers, venue codes, timestamps and price conventions. The connector’s job is to translate one into the other at the edge, so that the rest of your estate never has to know whether a price came from the tape, a venue or a vendor. This is the same discipline that governs any feed you bring in-house — the data-movement decision of where transformation happens and against which canonical model.

A minimal consumer makes the boundary explicit: ingest the tape record, map it to the internal model, and flag anything that does not reconcile against the venue feed you already trust.

from dataclasses import dataclass
from datetime import datetime
from decimal import Decimal

# Internal canonical model. The rest of the estate speaks this,
# never the tape's wire format.
@dataclass(frozen=True)
class MarketDataPoint:
    isin: str
    venue_mic: str          # normalised MIC, our vocabulary
    bid: Decimal
    ask: Decimal
    event_time: datetime    # UTC, from the tape's timestamp
    source: str             # "CTP", "VENUE", "VENDOR"

CTP_SOURCE = "CTP"

def normalise(record: dict) -> MarketDataPoint:
    """Map one consolidated-tape record onto the internal model.
    Field names here follow EuroCTP's published spec once final;
    treat the mapping as configuration, not hard-coded constants."""
    return MarketDataPoint(
        isin=record["instrumentId"],
        venue_mic=record["executionVenue"],
        bid=Decimal(str(record["bestBid"])),
        ask=Decimal(str(record["bestOffer"])),
        event_time=datetime.fromisoformat(record["tradingDateTime"]),
        source=CTP_SOURCE,
    )

def reconcile(tape: MarketDataPoint, venue: MarketDataPoint,
              tolerance: Decimal = Decimal("0.0005")) -> bool:
    """True when the tape agrees with our own feed within tolerance.
    A False here is a signal to investigate, not to trade on."""
    if tape.isin != venue.isin:
        return False
    spread = abs(tape.bid - venue.bid) + abs(tape.ask - venue.ask)
    return spread <= tolerance

That is deliberately small, because the point is the boundary, not the cleverness. The tape’s fields are configuration you finalise against the published specification; the internal model is fixed; the reconciliation function is a control you can point a supervisor at. Where the consolidated view diverges from your own, you want to know before best execution assumes the tape was right.

Storage, retention and the reference-price problem

Once the tape is authoritative for anything — best-execution evidence, transaction-cost analysis, reporting — you have to store it in a form you can query months later, when a client or a regulator asks what the market was showing at a specific moment. That is a retention and query-cost question before it is a storage-format one, and it favours an open, queryable table layout over a proprietary feed archive nobody can read without the vendor. The table-format decision that has settled across analytical estates applies directly here: you are keeping a large, append-heavy, time-series record that you will interrogate long after capture.

The reference-price problem is the subtle one. The moment your best-execution logic, your TCA or your reporting starts to assume a consolidated reference price exists, the tape stops being an optional extra and becomes a dependency your controls rely on. That is a governance change, not just a technical one: an outage or a gap in the tape now degrades an obligation, not merely a nice-to-have feed. Map that dependency deliberately, with a fallback to your own consolidated view, rather than discovering it during the first disruption.

Why the build starts now, not at launch

The instinct with a service that is still being authorised is to wait until it is live. That is the wrong instinct here, for the same reason it is wrong with any long-lead data dependency: the internal model, the reconciliation controls and the storage decisions take longer to get right than the connector does, and they are the parts you can build before the wire format is final. We made this argument about the ECB’s integrated reporting framework — a distant deadline still means starting your data model now — and the logic transfers. The connector is a fortnight. The canonical model, the reconciliation discipline and the retention design are the year.

The firms that will retrofit the tape cheaply are the ones treating it today as a normalisation and reconciliation exercise against a model they already control. The ones that will pay for it are the ones waiting for a go-live date, then wiring an authoritative feed into pipelines that were never asked whether they could carry it.