Lesson 01 · trade

What the execution record captures

At the moment of execution, the record thickens. This examines what a venue is obliged to capture, and what a reconstruction later depends on.

July 8, 2026

← Trade lessons
The data footprint of the trade stage: a matched buy order and sell order converging at execution into a single trade record, with the fields captured at the match, feeding three downstream destinations — clearing and settlement, the US Consolidated Audit Trail, and the EU/UK MiFID II transaction report.
The trade stage of the lifecycle — what is captured at the match, and where the record goes next.

An order is intent. A trade is a fact. Between the two sits a single instant — the match — and everything a regulator will later ask a firm to prove depends on what gets written down in that instant.

At the moment of execution, a venue's matching engine writes down a compact but exacting record: a trade identifier distinct from the order, the matched order IDs on both sides, the execution price and quantity, a timestamp carried to microsecond precision, the venue identifier, and a flag for which side was passive and which was aggressive. In FIX-based markets, this is the moment the ExecutionReport message is generated — the first document in the trade's life to describe something that happened, rather than something that was requested.

None of this is useful in isolation. A reconstruction typically has to line up records from more than one venue, more than one broker, and more than one regulator's own repository — which only works if every system's clock agrees closely enough that the sequence of events is not in dispute. That is why clock synchronization is regulated in its own right: MiFID II's technical standards in the EU and UK, and the Consolidated Audit Trail's tolerance against the US atomic clock, both exist purely so a timestamp on one system can be trusted against another.

The United States and the EU/UK frame the record differently once it exists. The Consolidated Audit Trail treats execution as one event in a chain reported by different participants and stitched together through linkage keys; MiFID II's transaction reporting places the obligation on the investment firm directly — a single structured submission covering dozens of fields, due by the close of the next business day. Both are answering the same question a reconstruction eventually asks: given a trade that already happened, can every fact about it be recovered independently of what any one party now says occurred.

For the practitioner · FIX mapping

The fields captured at the match, mapped to the FIX tags that carry them back to the originating firm. Requiredness below is the base-protocol rule. ExecType governs how the remaining fields are interpreted — a report describing a cancellation carries a different subset of meaningful data than one describing a fill.

FieldFIX tagNote
At the match
trade identifierExecID (17)required. Unique to this execution report, distinct from the order ID
order identifierOrderID (37)required. The venue's identifier for the order being filled
execution typeExecType (150)required. Governs interpretation of the remaining fields — fill, cancel, reject, and so on
priceLastPx (31)price of this particular fill
quantityLastQty (32)quantity filled in this event
timestampTransactTime (60)required. Time of execution, at the precision the venue supports
venueLastMkt (30)market or venue where the fill occurred

Source: FIX Trading Community, FIXimate tag dictionary.

Responses from readers

This website does not host open comments. Verified responses are published here at the editor's discretion. Submit a response to editorial@tradesreconstructed.com.