Trace a FIX order across cancel and replace
A replacement gives a request a new client identifier. ClOrdID (11) and OrigClOrdID (41) let you follow the order even when searching for one ID no longer finds every message.
Follow the client IDs
In this acknowledged FIX 4.4 sequence, an order for 100 shares fills 40, is replaced with a total quantity of 150, and is then canceled. OrderQty after replacement is the new total, including earlier fills.
| Step | ClOrdID (11) | OrigClOrdID (41) | What happened |
|---|---|---|---|
| NewOrderSingle · D | DOC-001 | — | Request 100 shares |
| ExecutionReport · 8 | DOC-001 | — | New order accepted |
| ExecutionReport · 8 | DOC-001 | — | 40 filled; 60 remain |
| Cancel/Replace · G | DOC-002 | DOC-001 | Request total quantity 150 |
| ExecutionReport · 8 | DOC-002 | DOC-001 | Replace accepted; 110 remain |
| Cancel Request · F | DOC-003 | DOC-002 | Cancel the accepted replacement |
| ExecutionReport · 8 | DOC-003 | DOC-002 | Canceled; 40 filled, zero open |
OrigClOrdID (41) links backward to the targeted order identifier. Once DOC-002 is accepted, the cancel targets DOC-002. It does not point back to DOC-001 merely because that was the first ID.
Read the complete log
8=FIX.4.4|9=136|35=D|49=CLIENT|56=BROKER|34=1|52=20260901-14:30:01.000|11=DOC-001|21=1|55=AAPL|54=1|60=20260901-14:30:01.000|38=100|40=2|44=185.50|59=0|10=176|
8=FIX.4.4|9=179|35=8|49=BROKER|56=CLIENT|34=1|52=20260901-14:30:01.000|37=VENUE-001|17=EXEC-001|11=DOC-001|150=0|39=0|38=100|151=100|14=0|6=0|55=AAPL|54=1|40=2|44=185.50|60=20260901-14:30:01.000|10=042|
8=FIX.4.4|9=200|35=8|49=BROKER|56=CLIENT|34=2|52=20260901-14:30:02.000|37=VENUE-001|17=EXEC-002|11=DOC-001|150=F|39=1|38=100|32=40|31=185.50|151=60|14=40|6=185.50|55=AAPL|54=1|40=2|44=185.50|60=20260901-14:30:02.000|10=026|
8=FIX.4.4|9=147|35=G|49=CLIENT|56=BROKER|34=2|52=20260901-14:30:02.500|41=DOC-001|11=DOC-002|21=1|55=AAPL|54=1|60=20260901-14:30:02.500|38=150|40=2|44=185.50|59=0|10=255|
8=FIX.4.4|9=196|35=8|49=BROKER|56=CLIENT|34=3|52=20260901-14:30:03.000|37=VENUE-001|17=EXEC-003|11=DOC-002|41=DOC-001|150=5|39=1|38=150|151=110|14=40|6=185.50|55=AAPL|54=1|40=2|44=185.50|60=20260901-14:30:03.000|10=170|
8=FIX.4.4|9=122|35=F|49=CLIENT|56=BROKER|34=3|52=20260901-14:30:03.500|41=DOC-002|11=DOC-003|55=AAPL|54=1|60=20260901-14:30:03.500|38=150|10=163|
8=FIX.4.4|9=194|35=8|49=BROKER|56=CLIENT|34=4|52=20260901-14:30:04.000|37=VENUE-001|17=EXEC-004|11=DOC-003|41=DOC-002|150=4|39=4|38=150|151=0|14=40|6=185.50|55=AAPL|54=1|40=2|44=185.50|60=20260901-14:30:04.000|10=078|The replacement acknowledgement has 150=5 and 39=1: the event is Replaced, while the order is still Partially filled. The final cancellation sets 151=0 without undoing the 40 shares already filled.
Handle rejected and pending requests
A rejected replace request does not make its new ClOrdID the accepted order ID. An OrderCancelReject (35=9) identifies the rejected cancel or replace request; it does not by itself cancel or reject the underlying order.
Pending cancel and pending replace are intermediate states. Fills can arrive while either request is pending. Read the messages in sequence and check the counterparty’s rules before interpreting overlapping requests.
This example waits for each acknowledgement; overlapping requests need additional context.
Trace the chain in FIXtags
Open the complete example above. It starts in the Messages view with DOC-001 traced, including the later messages carrying DOC-002 and DOC-003. Switch to Orders to see the seven messages summarized as one order.
In your own log, first search for a known ID. Select a matching message and use Trace this order. A plain 11=DOC-001 filter alone misses the later requests, because their ClOrdID changed.
Keep the session and counterparties in view when joining logs: ClOrdID (11) and OrderID (37) should not be treated as globally unique identifiers.