ClOrdID, OrigClOrdID And Order Identity

Every order a firm sends carries a ClOrdID (tag 11) — a unique identifier the client itself assigns, not the exchange. This matters because the exchange's own order ID (assigned only after acceptance) can't be known at the moment of sending, so the client needs its own way to say "this is the order I mean" before any acknowledgment comes back. A firm's FIX engine is responsible for making sure every ClOrdID it generates is unique, typically by incrementing a counter or embedding a timestamp.

Why amending an order changes its ID

Here's the part that trips people up: when you cancel/replace an order — say, moving its price — the new, amended order isn't sent with the same ClOrdID as before. It gets a fresh ClOrdID, and carries an OrigClOrdID (tag 41) pointing back to the ClOrdID it's replacing. So an order that started life, got amended twice, and was finally cancelled leaves behind a chain of four distinct ClOrdIDs, each one's OrigClOrdID pointing to its predecessor. To reconstruct "what happened to this order across its whole life," a system has to walk that chain backward, not just look up one ID.

This design exists because a cancel/replace isn't really an in-place edit at the exchange — under the hood it's usually a cancellation of the old order and the creation of a new one at the back of the queue (see cancel/replace semantics), so giving the new order its own identity mirrors what's actually happening to it in the matching engine.

Where this shows up in practice

Any system that needs to answer "show me this order's full history" — a compliance tool, a P&L attribution system, a post-trade reconciliation job — has to be built around following the OrigClOrdID chain, not just filtering execution reports by a single ClOrdID. Getting this wrong is a common source of bugs: a naive implementation that only tracks the original ClOrdID will silently lose track of an order the moment it's amended, because every message about the amended order references a different ID.