An order is never a single record. It surfaces as a sequence of messages, and a handful of identifiers are what let those messages be read as one order's life.
August 2, 2026
← Order lessonsA single order across its messages: the flow, the four identifiers that hold it together, and where the record hands off at fulfillment.
An order is never a single record. It reaches the market as one instruction and leaves a trail of messages behind it: an acknowledgment when it arrives, another at every change, another at every fill. To answer any question about the order later, a firm rebuilds that trail from the messages.
Those messages travel in a shared format, the Financial Information eXchange protocol (FIX), and the vocabulary is small. A new order is a NewOrderSingle. Every event that follows, an acknowledgment, a partial fill, a final fill, comes back as an ExecutionReport. A change to the order is an OrderCancelReplaceRequest, and a withdrawal an OrderCancelRequest, each answered by its own report. The record holds the changes, not only the outcome.
What keeps the trail coherent is a handful of identifiers, and the way they behave is the whole trick. The order identifier the venue assigns stays fixed from the first message to the last; it is the spine. The identifier the sending firm attaches does not: a fresh one is issued for the original order and for every amendment after it, so following that one alone loses the order at its first change.
The link is recovered by a third identifier that each change carries, pointing back to the version it replaced. Read the fixed identifier straight down the record, and the pointers backward across it, and an order amended twice reassembles into one ordered life. Each report also states where the order stands, what has just happened to it and what it now is, so reading that state in sequence, from new, to partially filled, to filled, traces a fill from the first acknowledgment to the last share.
This record is rich here, at the order and trade stages, and thin at fulfillment, where settlement moves onto other standards and the reports a regime requires are assembled apart from it. The identifiers are what cross the seam: they carry the order out of its message record and into everything built on top. The order–trade–fulfillment lifecycle is continuous; its record is not, and the identifier chain is what makes the join legible.
For the practitioner · FIX mapping
The identifiers and status fields that let an order be followed across its messages, mapped to their FIX tags. Requiredness is conditional: it depends on the message type, the order type, the FIX version, and any venue or reporting overlay. The notes say when each field applies rather than asserting a blanket rule.
Field
FIX tag
Note
The identifier chain
client order identifier
ClOrdID (11)
a new value on the original order and on every amend or cancel request; followed alone, it loses the order at the first change
prior order reference
OrigClOrdID (41)
on a cancel or replace, the ClOrdID it supersedes; the link backward through the chain of changes
venue order identifier
OrderID (37)
assigned by the broker or venue; stable across the whole life, the spine a reconstruction follows
execution identifier
ExecID (17)
a new value on every ExecutionReport; separates one report from the next
Lifecycle status
what just happened
ExecType (150)
the event this report describes. 0 = new, F = trade, 4 = canceled, 5 = replaced, 8 = rejected
current state
OrdStatus (39)
where the order stands now. 0 = new, 1 = partially filled, 2 = filled, 4 = canceled
event time
TransactTime (60)
the business time of the event; the reference point for clock-synchronization requirements
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.
