Table of Contents

Introduction

This document defines the semantics for the key order handling paradigms of the FIX application layer related to the ExecutionReport(35=8) message. The semantics are mainly driven by only two FIX fields as follows:

  • ExecType(150) conveys the reason for the ExecutionReport(35=8) message to have been sent.
  • OrdStatus(39) conveys the current status of an order, i.e. after the event causing the message to be sent.

The various scenarios are grouped as follows and primarily reflect the different events that could occur during the lifetime of an order.

A – Order executions (aka Vanilla)

B – Order cancellations

C – Order modifications

D – Order sequencing and chaining

E – Order restatements

F – Order rejections

G – Order status information

H – Multi-day orders (GTC)

I – Non-resting orders (IOC, FOK)

J – Execution corrections and cancellations

K – Trading halts

L – Miscellaneous

Many of the events change the quantity fields of an order. The main fields shown in the scenarios are as follows:

  • OrderQty(38) – total executable quantity
  • CumQty(14) – executed quantity
  • LastQty(32) – quantity of last execution
  • LeavesQty(151) – quantity remaining for execution

An order can be in more than one state since the owner was last informed. The precedence rules governing the setting of OrdStatus(39) are defined in Chapter 2 Order State Precedences. The first set of scenarios set out in Chapter 3 General Order State Change Matrices are of general nature and are not limited to a specific environment or asset class. A much smaller set of scenarios is defined in Chapter 4 Order State Change Matrices for Exchanges. They mirror general scenarios but define a different workflow specific to exchanges and other electronic trading venues. The key difference is the reduced verbosity of workflows, i.e. less messages are used to convey the same amount of information on an order.

Order State Precedences

In an ExecutionReport(35=8) message OrdStatus(39) is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in OrdStatus(39). The order statuses are as follows (in highest to lowest precedence):

PrecedenceOrdStatusDescription
11Pending CancelOrder with a pending cancel request, used to confirm receipt of an OrderCancelRequest(35=F) message. DOES NOT INDICATE THAT THE ORDER HAS BEEN CANCELED.
10Pending ReplaceOrder with a pending replacement request, used to confirm receipt of an OrderCancelReplaceRequest(35=G) message. DOES NOT INDICATE THAT THE ORDER HAS BEEN REPLACED.
9Done for DayOrder not, or partially, filled; no further executions forthcoming for the trading day
8CalculatedOrder has been completed for the day (either filled or done for day). Commission or currency settlement details have been calculated and reported in this execution message
7FilledOrder completely filled, no remaining quantity
6StoppedOrder has been stopped at the exchange. Used when guaranteeing or protecting a price and quantity
5SuspendedOrder has been placed in suspended state at the request of the client.
4CanceledCanceled order with or without executions
4ExpiredOrder has been canceled in broker’s system due to TimeInForce(59) instructions. The only exceptions are Fill or Kill and Immediate or Cancel orders that have Canceled as terminal order state.
3Partially FilledOutstanding order with executions and remaining quantity
2NewOutstanding order with no executions
2RejectedOrder has been rejected by sell-side (broker, exchange, ECN). NOTE: An order can be rejected subsequent to order acknowledgment, i.e. an order can pass from New to Rejected status.
2Pending NewOrder has been received by sell-side’s (broker, exchange, ECN) system but not yet accepted for execution. An execution message with this status will only be sent in response to a OrderStatusRequest(35=H) message.
1Accepted for biddingOrder has been received and is being evaluated for pricing. It is anticipated that this status will only be used with the BidType(394) = 2 (Disclosed style) List Order Trading model.

General Order State Change Matrices

The following matrices are included to clarify the sequence of messages and the status of orders involved in the submission and processing of new orders, executions, cancel requests, cancel/replace requests and order status requests. The matrices have been arranged in groups as follows.

Overview of Scenarios

A Vanilla

RefDescription
A.1.aFilled order
A.1.bPart-filled day order, done for day

B Cancel

RefDescription
B.1.aCancel request issued for a zero-filled order
B.1.bCancel request issued for a part-filled order – executions occur whilst cancel request is active
B.1.cCancel request issued for an order that becomes filled before cancel request can be accepted
B.1.dCancel request issued for an order that has not yet been acknowledged
B.1.eCancel request issued for an order that has not yet been acknowledged – the acknowledgment and the cancel request ‘cross’
B.1.fCancel request issued for an unknown order

C Cancel/Replace quantity changes

C.1 Replace to increase quantity

RefDescription
C.1.aZero-filled order, cancel/replace request issued to increase order qty
C.1.bPart-filled order, followed by cancel/replace request to increase order qty, execution occurs whilst order is pending replace
C.1.cFilled order, followed by cancel/replace request to increase order quantity

C.2 Replace not for quantity change

RefDescription
C.2.aCancel/replace request (not for quantity change) is rejected as a fill has occurred

C.3 Replace to decrease quantity

RefDescription
C.3.aCancel/replace request sent whilst execution is being reported – the requested order qty exceeds the cum qty. Order is replaced then filled
C.3.bCancel/replace request sent whilst execution is being reported – the requested order qty equals the cum qty – order qty is amended to cum qty
C.3.cCancel/replace request sent whilst execution is being reported – the requested order qty is below cum qty – order qty is amended to cum qty

D Cancel/Replace sequencing and chaining

D.1 Sequencing

RefDescription
D.1.aOne cancel/replace request is issued which is accepted – another one is issued which is also accepted
D.1.bOne cancel/replace request is issued which is rejected before order becomes pending replace – then another one is issued which is accepted
D.1.cOne cancel/replace request is issued which is rejected after it is in pending replace – then another one is issued which is accepted

D.2 Chaining

RefDescription
D.2.aOne cancel/replace request is issued followed immediately by another – broker processes sequentially
D.2.bOne cancel/replace request is issued followed immediately by another – broker processes pending replaces before replaces
D.2.cOne cancel/replace request is issued followed immediately by another – both are rejected
D.2.dOne cancel/replace request is issued followed immediately by another – broker rejects the second as order is pending replace

E Unsolicited/Reinstatement

RefDescription
E.1.aTelephoned order
E.1.bUnsolicited cancel of a part-filled order
E.1.cUnsolicited replacement of a part-filled order
E.1.dUnsolicited reduction of order quantity by sell side (e.g. for US ECNs to communicate Nasdaq SelectNet declines)
E.1.eUnsolicited cancel of ‘cancel if not best’ order
E.1.fOrder is sent to exchange, held waiting for activation and then activated

F Order Reject

RefDescription
F.1.aOrder rejected due to duplicate ClOrdID
F.1.bPossResend and duplicate ClOrdID
F.1.cOrder rejected because the order has already been verbally submitted

G Status

RefDescription
G.1.aOrder status request rejected for unknown order
G.1.bTransmitting a CMS-style “Nothing Done” in response to a status request
G.1.cOrder sent, immediately followed by a status request. Subsequent status requests sent during life of order

H GT

RefDescription
H.1.aGTC order partially filled, restated (renewed) and partially filled the following day
H.1.bGTC order with partial fill, a 2:1 stock split then a partial fill and fill the following day
H.1.cGTC order partially filled, restated(renewed) and canceled the following day
H.1.dGTC order partially filled, restated(renewed) followed by replace request to increase quantity

I TimeInForce

RefDescription
I.1.aFill or Kill order cannot be filled
I.1.bImmediate or Cancel order that cannot be immediately hit

J Execution Cancels/Corrects

RefDescription
J.1.aFilled order, followed by correction and cancellation of executions
J.1.bA canceled order followed by a busted execution and a new execution
J.1.cGTC order partially filled, restated (renewed) and partially filled the following day, with corrections of quantity on both executions
J.1.dPart-filled order Done for day followed by trade correction and bust

K Trading Halt

RefDescription
K.1.aTrading Halt – Reinstate
K.1.bTrading Halt – Cancel

L Miscellaneous

RefDescription
L.1.aTransmitting a guarantee of execution prior to execution (Stopped/Guarantee)
L.1.bUse of CashOrderQty

Scenarios for State Transitions

The table below shows which state transitions have been illustrated by the matrices in this section (marked with an asterisk). The row represents the current value of OrdStatus(39) and the column represents the next value as reported back to the buy-side via an execution report or order cancel reject message. Next to each OrdStatus(39) value is its precedence – this is used when the order exists in a number of states simultaneously to determine the value that should be reported back. Note that absence of a scenario should not necessarily be interpreted as meaning that the state transition is not allowed:

OrdStatus (precedence value)New (2)Partially

Filled (4)

Filled (8)Done

For

Day (10)

Pending Cancel (12)Pending

Replace (11)

Canceled (5)Rejected (2)Stopped (7)
Pending New (2)
New (2)
Partially Filled (4)
Filled (8)
Done for Day (10)
Pending Cancel (12)
Pending Replace (11)
Canceled (5)
Rejected (2)
Stopped (7)

A Vanilla

A.1.a – Filled order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by salesperson
2Execution(X)NewNew100000100000
3Execution(X)RejectedRejected10000000If order is rejected by trader/exchange
3Execution(X)TradePartially Filled10000200080002000Execution of 2000
4Execution(X)TradePartially Filled10000300070001000Execution of 1000
5Execution(X)TradeFilled100001000007000Execution of 7000
A.1.b – Part-filled day order, done for day
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000200080002000Execution of 2000
4Execution(X)TradePartially Filled10000300070001000Execution of 1000
5Execution(X)Done for DayDone for Day10000300000Assuming day order. See other examples which cover GT orders

B Cancel

B.1.a – Cancel request issued for a zero-filled order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message Sent

(ClOrdID, OrigClOrdID)

ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected
2Execution(X)NewNew100000100000
3Cancel Request(Y,X)10000
4Cancel Reject (Y,X)NewIf rejected by salesperson
4Execution (Y,X)Pending CancelPending Cancel100000100000Acknowledge the cancel request
5Cancel Reject (Y,X)NewIf rejected by trader/exchange
5Execution (Y,X)CanceledCanceled10000000Confirm that order has been canceled
B.1.b – Cancel request issued for a part-filled order – executions occur whilst cancel request is active
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000200080002000Execution for 2000
4Cancel Request(Y,X)10000
4Execution(X)TradePartially Filled10000500050003000Execution for 3000. This execution passes the cancel request on the connection
5Cancel Reject (Y,X)Partially FilledIf request is rejected
5Execution (Y,X)Pending CancelPending Cancel10000500050000‘Pending cancel’ order status takes precedence over ‘partially filled’ order status
6Execution(X)TradePending Cancel10000600040001000Execution for 1000 whilst order is pending cancel – ‘pending cancel’ order status takes precedence over ‘partially filled’ order status.
7Cancel Reject (Y,X)Partially FilledIf request is rejected
7Execution (Y,X)CanceledCanceled10000600000‘Canceled’ order status takes precedence over ‘partially filled’ order status
B.1.c – Cancel request issued for an order that becomes filled before cancel request can be accepted
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000200080002000Execution for 2000
4Cancel Request(Y,X)10000
4Execution(X)TradePartially Filled10000500050003000Execution for 3000. This execution passes the cancel request on the connection
5Cancel Reject (Y,X)Partially FilledIf request is rejected
5Execution (Y,X)Pending CancelPending Cancel10000500050000‘Pending cancel’ order status takes precedence over ‘partially filled’ order status
6Execution(X)TradePending Cancel100001000005000Execution for 5000 whilst order is pending cancel. ‘Pending cancel’ order status takes precedence over ‘filled’ order status
7Cancel Reject (Y,X)FilledCancel request rejected – CxlRejectReason = 0 (too late to cancel)
B.1.d – Cancel request issued for an order that has not yet been acknowledged
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Cancel Request(Y,X)10000Order sender immediately wishes to cancel the order
3Execution (Y,X)Pending CancelPending Cancel100000100000OrigClOrd set to X even though X has not yet been ‘accepted’.
4Execution(X)NewNew100000100000Order accepted before cancel request is processed.
5Execution (Y,X)CanceledCanceled10000000Order canceled.
6New Order(A)5000
7Cancel Request(B,A)5000Order sender immediately wishes to cancel the order
8Execution (B,A)Pending CancelPending Cancel5000050000OrigClOrd set to A even though A has not yet been ‘accepted’.
9Execution (B,A)CanceledCanceled5000000Order canceled before it is accepted. Note OrigClOrdID set to A even though A has not yet been accepted
B.1.e – Cancel request issued for an order that has not yet been acknowledged – the acknowledgment and the cancel request ‘cross’
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Cancel Request(Y,X)10000Order sender immediately wishes to cancel the order
2Execution(X)NewNew100000100000This message crosses the cancel request
3Execution (Y,X)Pending CancelPending Cancel100000100000
4Execution (Y,X)CanceledCanceled10000000Order canceled.
B.1.f – Cancel request issued for an unknown order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1Cancel Request(Y,X)10000
2Cancel Reject (Y,X)RejectedCancel request rejected with reject reason of “Unknown Order”, OrdStatus is “Rejected” and OrderID is “NONE”

NOTE: It is important to note that rejecting a cancel request for an unknown OrigClOrdID(41) does not cause the sell-side to consume the OrigClOrdID(41) used in the OrderCancelReplaceRequest(35=G).

C Cancel/Replace quantity changes

C.1 Replace to increase quantity

C.1.a – Zero-filled order, cancel/replace request issued to increase order qty
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Replace Request(Y,X)11000Request to increase order qty to 11000
4Cancel Reject (Y,X)NewIf request is rejected by salesperson
4Execution (Y,X)Pending ReplacePending Replace100000100000Acknowledge the Replace request
5Cancel Reject (Y,X)NewIf rejected by trader/exchange
5Execution (Y,X)ReplaceNew110000110000Confirm order has been replaced
6Execution(Y)TradePartially Filled110001000100001000Execution for 1000. Use Y as the new ClOrdID.
7Execution(Y)TradePartially Filled11000300080002000Execution for 2000
C.1.b – Part-filled order, followed by cancel/replace request to increase order qty, execution occurs whilst order is pending replace
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)12000Request increase in order quantity to 12000
5Cancel Reject (Y,X)Partially FilledIf request is rejected
5Execution (Y,X)Pending ReplacePending Replace10000100090000‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6Execution(X)TradePending Replace1000011008900100Execution for 100 before cancel/replace request is dealt with
7Cancel Reject (Y,X)Partially FilledIf request is rejected
7Execution (Y,X)ReplacePartially Filled120001100109000Confirm replace has been accepted
8Execution(Y)TradeFilled1200012000010900Execution for 10900
C.1.c – Filled order, followed by cancel/replace request to increase order quantity
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradeFilled1000010000010000Execution for 10000
4Replace Request(Y,X)12000Request increase in order quantity to 12000
5Cancel Reject (Y,X)FilledIf request is rejected
5Execution (Y,X)Pending ReplacePending Replace100001000000‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6Cancel Reject (Y,X)FilledIf request is rejected
6Execution (Y,X)ReplacePartially Filled120001000020000. Confirm order has been replaced
7Execution(Y)TradeFilled120001200002000Execution for 2000

C.2 Replace not for quantity change

C.2.a – Cancel/replace request (not for quantity change) is rejected as a fill has occurred
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)10000Assume in this scenario that client does not wish to increase qty (e.g. client wants to amend limit price)
4Execution (X)TradeFilled100001000009000Execution for 9000 – the replace request message and this execution report pass each other on the connection
5Cancel Reject (Y,X)FilledCxlRejectReason = 0 (too late to cancel)

C.3 Replace to decrease quantity

C.3.a – Cancel/replace request sent whilst execution is being reported – the requested order qty exceeds the cum qty. Order is replaced then filled
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request a decrease order quantity to 8000 (leaving 7000 open)
4Execution(X)TradePartially Filled1000015008500500Execution for 500 sent. Replace request and this execution report pass each other on the connection
5Cancel Reject (Y,X)Partially FilledIf request is rejected by salesperson
5Execution (Y,X)Pending ReplacePending Replace10000150085000‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6Execution(X)TradePending Replace1000016008400100Execution for 100 occurs before cancel/replace request is accepted
7Cancel Reject (Y,X)Partially FilledIf request is rejected by trader/exchange
7Execution (Y,X)ReplacePartially Filled8000160064000Replace is accepted as requested order qty exceeds cum qty
8Execution (Y)TradeFilled8000800006400Execution for 6400.
C.3.b – Cancel/replace request sent whilst execution is being reported – the requested order qty equals the cum qty – order qty is amended to cum qty
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Replace Request(Y,X)7000Client wishes to amend order qty to 7000
3Execution(X)TradePartially Filled10000700030007000Execution for 7000 – the replace message and this execution report pass each other on the connection
4Execution (Y,X)ReplaceFilled7000700000The replace request is interpreted as requiring the balance of the order to be canceled – the ‘filled’ order status takes precedence over ‘canceled’.
C.3.c – Cancel/replace request sent whilst execution is being reported – the requested order qty is below cum qty – order qty is amended to cum qty
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Replace Request(Y,X)7000Client wishes to amend order qty to 7000
3Execution(X)TradePartially Filled10000800020008000Execution for 8000 – the replace message and this execution report pass each other on the connection
4Execution (Y,X)ReplaceFilled8000800000The replace request is interpreted as requiring the balance of the order to be canceled – the ‘filled’ order status takes precedence over ‘canceled’.

D Cancel/Replace sequencing and chaining

D.1 Sequencing

D.1.a – One cancel/replace request is issued which is accepted – another one is issued which is also accepted
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Execution (Y,X)Pending ReplacePending Replace10000100090000‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6Execution(X)TradePending Replace1000015008500500Execution for 500
7Execution (Y,X)ReplacePartially Filled8000150065000
8Execution (Y)TradePartially Filled8000350045002000Execution for 2000
9Replace Request(Z,Y)6000Request decrease in order quantity to 6000, leaving 2500 open
10Execution (Z,Y)Pending ReplacePending Replace8000350045000
11Execution(Y)TradePending Replace800040004000500Execution for 500
12Execution (Z,Y)ReplacePartially Filled6000400020000
13Execution(Z)TradeFilled6000600002000Execution for 2000
D.1.b – One cancel/replace request is issued which is rejected before order becomes pending replace – then another one is issued which is accepted
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Cancel Reject (Y,X)Partially FilledRequest is rejected
6Execution(X)TradePartially Filled1000015008500500Execution for 500
7Execution(X)TradePartially Filled10000350065002000Execution for 2000
8Replace Request(Z,X)6000Request decrease in order quantity to 6000, leaving 2500 open. Note that OrigClOrdID = X , as this is the last non rejected ClOrdID
9Execution (Z,X)Pending ReplacePending Replace10000350065000Note that OrigClOrdID = X
10Execution (Z,X)ReplacePartially Filled6000350025000Note that OrigClOrdID = X
11Execution(Z)TradePartially Filled6000500010001500Execution for 1500
D.1.c – One cancel/replace request is issued which is rejected after it is in pending replace – then another one is issued which is accepted
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Execution (Y,X)Pending ReplacePending Replace10000100090000
6Execution(X)TradePending Replace1000015008500500Execution for 500. ‘Pending replace’ order status takes precedence over ‘partially filled’ order status
7Cancel Reject (Y,X)Partially FilledRequest is rejected (e.g. by trader/exchange)
8Execution(X)TradePartially Filled10000350065002000Execution for 2000
9Replace Request(Z,X)6000Request decrease in order quantity to 6000, leaving 2500 open. Note that OrigClOrdID = X as this is the last non rejected ClOrdID
10Execution (Z,X)Pending ReplacePending Replace10000350065000
11Cancel Reject (Z,X)Partially FilledIf request is rejected (e.g. by trader/exchange)
11Execution (Z,X)ReplacePartially Filled6000350025000
12Execution(Z)TradePartially Filled6000500010001500Execution for 1500

D.2 Chaining

D.2.a – One cancel/replace request is issued followed immediately by another – broker processes sequentially
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Replace Request(Z,Y)7000Request decrease in order quantity to 7000, leaving 6000 open. Note OrigClOrdID set to last non rejected ClOrdID i.e. Y (on an ‘optimistic’ basis)
6Execution (Y,X)Pending ReplacePending Replace10000100090000Broker processes Replace (Y,X) first
7Execution (Y,X)ReplacePartially Filled8000100070000Broker processes Replace (Y,X) first
8Execution (Z,Y)Pending ReplacePending Replace8000100070000Broker then processes Replace (Z,Y). Note OrigClOrdID set to last accepted ClOrdID i.e. Y
9Execution (Z,Y)ReplacePartially Filled7000100060000Broker then processes Replace (Z,Y)
10Execution(Z)TradeFilled7000700006000Execution for 6000
D.2.b – One cancel/replace request is issued followed immediately by another – broker processes pending replaces before replaces
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Replace Request(Z,Y)7000Request decrease in order quantity to 7000, leaving 6000 open. Note OrigClOrdID set to last non rejected ClOrdID i.e. Y
6Execution (Y,X)Pending ReplacePending Replace10000100090000Broker processes Replace (Y,X) first
7Execution (Z,X)Pending ReplacePending Replace8000100070000Broker then processes Replace (Z,Y). Note OrigClOrdID set to last accepted ClOrdID i.e. X
8Execution (Y,X)ReplacePending Replace8000100070000Broker processes Replace (Y,X) first Note OrigClOrdID set to last accepted ClOrdID i.e. X. OrdStatus of Pending Replace takes precedence over Partially Filled
9Execution (Z,Y)ReplacePartially Filled7000100060000Broker then processes Replace (Z,Y) Note OrigClOrdID set to last accepted ClOrdID i.e. Y
10Execution(Z)TradeFilled7000700006000Execution for 6000
D.2.c – One cancel/replace request is issued followed immediately by another – both are rejected
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Replace Request(Z,Y)7000Request decrease in order quantity to 7000, leaving 6000 open. Note OrigCOrdID set to last non rejected ClOrdID i.e. Y
6Execution (Y,X)Pending ReplacePending Replace10000100090000Broker processes Replace (Y,X) first
7Cancel Reject (Y,X)Partially FilledBroker rejects first replace request Note OrigClOrdID set to last accepted ClOrdID i.e. X
8Execution (Z,X)Pending ReplacePending Replace10000100090000Broker then processes Replace (Z,Y). Note OrigClOrdID set to last accepted ClOrdID i.e. X
9Cancel Reject (Z,X)Partially FilledBroker then rejects second replace request Note OrigClOrdID set to last accepted ClOrdID i.e. X
10Execution(X)TradePartially Filled10000700030006000Execution for 6000
D.2.d – One cancel/replace request is issued followed immediately by another – broker rejects the second as order is pending replace
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Replace Request(Y,X)8000Request decrease in order quantity to 8000, leaving 7000 open
5Replace Request(Z,Y)7000Request decrease in order quantity to 7000, leaving 6000 open Note OrigCOrdID set to last non rejected ClOrdID i.e. Y
6Execution (Y,X)Pending ReplacePending Replace10000100090000
7Cancel Reject

(Z,X)

Pending ReplaceRejected because broker does not support processing of order cancel replace request whilst order is pending cancel. CxlRejReason = ‘Order already in pending cancel or pending replace status’ OrigClOrdID set to last accepted ClOrdID i.e. X
8Execution (Y,X)ReplacePartially Filled8000100070000
9Execution (Y)TradePartially Filled8000300050002000Execution for 2000

This matrix illustrates the case where the broker/order receiver does not support multiple outstanding order cancel or order cancel/replace requests

E Unsolicited/Reinstatement

E.1.a – Telephoned order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1Order for 10000 phoned to broker
2ExecutionNewNew10000000Confirm that the broker has accepted the order – note that broker does not need to capture a ClOrdID
3ExecutionTradePartially Filled10000200080002000Execution of 2000
4ExecutionTradePartially Filled10000300070001000Execution of 1000
5ExecutionTradeFilled100001000007000Execution of 7000
E.1.b – Unsolicited cancel of a part-filled order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Broker verbally agrees to cancel order
5Execution(X)CanceledCanceled10000100000Broker signifies that order has been canceled – ExecRestatementReason = Verbal change

This scenario might occur if the buy-side has not implemented order cancel requests or alternatively there is an electronic communication problem at the point that the buy-side wishes to send a cancel request.

E.1.c – Unsolicited replacement of a part-filled order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Broker verbally agrees to increase order quantity to 11000
4Execution(X)RestatedNew110000110000Broker signifies that order has been replaced ExecRestatementReason = Verbal
5Execution(X)TradePartially Filled110001000100001000Execution for 1000
6Broker verbally agrees to increase order quantity to 12000
7Execution(X)RestatedPartially Filled120001000110000Broker signifies that order has been replaced ExecRestatementReason = Verbal change

This scenario might occur if the buy-side has not implemented order cancel/replace requests or alternatively there is an electronic communication problem at the point that the buy-side wishes to send a cancel replace request

E.1.d – Unsolicited reduction of order quantity by sell side ( e.g. for US ECNs to communicate Nasdaq SelectNet declines)
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)RestatedNew9000090000ExecRestatementReason=”Partial Decline of OrderQty”
4Execution(X)TradeFilled9000900009000
E.1.e – Unsolicited cancel of a ‘cancel if not best’ order
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyPriceCumQtyLeavesQtyLastQtyComment
1New Order(X)1000056ExecInst = Z ( Cancel if Not Best)
2Execution(X)RejectedRejected1000056000If order is rejected by sell-side (broker, exchange, ECN) (e.g. if the order book is at 56.1-57.1 prior to this order)
2Execution(X)NewNew10000560100000Order accepted as order book was 55.9-56.9 prior to this order. Order book is now 56.0-56.9
3Execution(X)CanceledCanceled1000056000Order book moves to 56.1-57.0. Order is no longer best bid/offer so is canceled with ExecRestatementReason =”Canceled, Not Best”
E.1.f – Order is sent to exchange, held waiting for activation and then activated
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000Entry of a stop (OrdType = 3), stop limit (OrdType = 4), At the Close (TimeInForce = 7), etc, order. E.g. an order that is held off the book waiting for activation subject to specified conditions.
2 Execution(X)RejectedRejected10 000000If order is rejected by trader / exchange
2Execution(X)NewNew10 000010 0000Trader / exchange acknowledge receipt of order but does not enter it into the book at activation conditions are not met (WorkingIndicator = N).

Note that if the conditions are met on entry, this WorkingIndicator is not sent.

3Execution(X)Triggered by (Trading System)New10 000010 0000Activation conditions are reached. Trader / exchange acknowledge that order is put on book (WorkingIndicator = Y).

Note that this message can be implicit in situations where there is an immediate fill or partial fill (as any state other than New / Pending New means the order has been added to the book and is working).

4Execution(X)TradePartially Filled10 0002 0008 0002 000Execution of 2000
5Execution(X)TradeFilled10 00010 00008 000Execution of 8000

F Order Reject

F.1.a– Order rejected due to duplicate ClOrdID
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4New Order(X)15000Order submitted with the same order id.
5Execution(X)RejectedPartially Filled10000100090000OrdRejReason = duplicate order. Note combining a reject of the order for 15000 with a status on the first order for 10000 (which is partially filled)
F.1.b – PossResend and duplicate ClOrdID
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3New Order(X)10000PossResend=Y
4Execution(X)Order StatusNew10000010000Because order X has already been received, confirm back the current state of the order. Last Qty not required when ExecType = Order Status
5New Order(X)20000PossResend=N or not set
6Execution(X)RejectedNew10000010000OrdRejReason = duplicate order. Note combining a reject of the second order for 20000 with a status on the first order for 10000.
7New Order(Y)15000PossResend=Y
8Execution(Y)NewNew150000150000Because order Y has not been received before, confirm back as a new order.
F.1.c – Order rejected because the order has already been verbally submitted
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000Order for 10000 sent electronically
2Order passed verbally as there is communication problem and order does not arrive. The verbally passed order starts getting executed
3Execution(X)RejectedRejected10000000Order finally arrives and is detected as a duplicate of a verbal order and is therefore rejected. OrdRejReason = duplicate of a verbal order

Note that the sell-side may employ a number of mechanisms to detect that the electronic order is potentially a duplicate of a verbally passed order, e.g. :

  • Checking the possdup flag on the order message header
  • Checking the incoming order details against other orders from the same client (e.g. side, quantity)
  • Looking at the transact time on the order as a guide to ‘staleness’

G Status

G.1.a – Order status request rejected for unknown order
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Status Request (Y)
5Execution(Y)Order StatusRejected000OrdRejReason = unknown order

LastQty not required when ExecType=Order Status

G.1.b – Transmitting a CMS-style “Nothing Done” in response to a status request
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Status Request(X)
4Execution(X)Order StatusNew100000100000Text=”Nothing Done”
G.1.c – Order sent, immediately followed by a status request. Subsequent status requests sent during life of order
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Status Request (X)
3Execution(X)Order StatusPending New10000010000Sent in response to status request. LastQty not required when ExecType=Order Status
4Execution(X)RejectedRejected10000000If order is rejected
4Execution(X)NewNew100000100000
5Status Request (X)
6Execution(X)Order StatusNew10000010000Sent in response to status request.
7Execution(X)TradePartially Filled10000200080002000Execution for 2000
8Status Request (X)
9Execution(X)Order StatusPartially Filled1000020008000Sent in response to status request
10Execution(X)TradeFilled100001000008000Execution for 8000
11Status Request (X)
12Execution(X)Order StatusFilled10000100000Sent in response to status request
13Replace Request(Y,X)12000Request to increase order qty
14Execution (Y,X)Pending ReplacePending Replace100001000000
15Execution (Y,X)ReplacePartially Filled120001000020000
16Status Request (X)
17Execution
(Y,X)
Order StatusPartially Filled12000100002000Sent in response to status request. Note reference to X to allow tie back of execution report to status request
18Status Request (Y)
19Execution(Y)Order StatusPartially Filled12000100002000Sent in response to status request

H GT

H.1.a – GTC order partially filled, restated (renewed) and partially filled the following day
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyDay

OrderQty

Day

CumQty

Comment
Day 1,1New Order(X)10000
Day 1,2Execution(X)NewNew100000100000
Day 1,3Execution(X)TradePartially Filled10000200080002000Execution for 2000
Day 1,4Execution(X)Done for DayDone for Day10000200080000Optional at end of trading day
Day 2,1Execution(X)RestatedPartially Filled1000020008000080000ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2Execution(X)TradePartially Filled1000030007000100080001000Execution for 1000
H.1.b – GTC order with partial fill, a 2:1 stock split then a partial fill and fill the following day
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyDay

OrderQty

Day

CumQty

Comment
Day 1,1New Order(X)10000
Day 1,2Execution(X)NewNew100000100000
Day 1,3Execution(X)TradePartially Filled10000200080002000Execution for 2000 @ 50
Day 1,4Execution(X)Done for DayDone for Day10000200080000Optional at end of trading day
Day 2,1Execution(X)RestatedPartially Filled200004000160000160000Sent the following morning after the split ExecRestatementReason = GTC corporate action. AvgPx=25, DayAvgPx=0
Day 2,2Execution(X)TradePartially Filled200009000110005000160005000Execution for 5000
Day 2,3Execution(X)TradeFilled20000200000110001600016000Execution for 11000
H.1.c – GTC order partially filled, restated(renewed) and canceled the following day
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyDay

OrderQty

Day

CumQty

Comment
Day 1,1New Order(X)10000
Day 1,2Execution(X)NewNew100000100000
Day 1,3Execution(X)TradePartially Filled10000200080002000Execution for 2000
Day 1,4Execution(X)Done for DayDone for Day10000200080000Optional at end of trading day
Day 2,1Execution(X)RestatedPartially Filled1000020008000080000ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2Cancel Request (Y,X)10000
Day 2,3Cancel Reject (Y,X)Partially FilledIf rejected by salesperson
Day 2,3Execution (Y,X)Pending CancelPending Cancel1000020008000080000
Day 2,4Cancel Reject (Y,X)Partially FilledIf rejected by trader/exchange
Day 2,4Execution (Y,X)CanceledCanceled1000020000080000
H.1.d – GTC order partially filled, restated(renewed) followed by replace request to increase quantity
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyDay

OrderQty

Day

CumQty

Comment
Day 1,1New Order(X)10000
Day 1,2Execution(X)NewNew100000100000
Day 1,3Execution(X)TradePartially Filled10000200080002000Execution for 2000
Day 1,4Execution(X)Done for DayDone for Day10000200080000Optional at end of trading day
Day 2,1Execution(X)RestatedPartially Filled1000020008000080000ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2Replace Request(Y,X)15000Increasing qty
Day 2,3Cancel Reject (Y,X)Partially FilledIf rejected by salesperson
Day 2,3Execution (Y,X)Pending ReplacePending Replace1000020008000080000
Day 2,4Execution (X)TradePending Replace1000030007000100080001000Execution for 1000
Day 2,5Cancel Reject (Y,X)Partially FilledIf rejected by trader/exchange
Day 2,5Execution (Y,X)ReplacePartially Filled150003000120000130001000

I TimeInForce

I.1.a – Fill or Kill order cannot be filled
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000Order is FOK
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)CanceledCanceled10000000If order cannot be immediately filled
I.1.b – Immediate or Cancel order that cannot be immediately hit
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000Order is IOC
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Execution(X)CanceledCanceled10000100000If order cannot be immediately hit

J Execution Cancels/Corrects

J.1.a – Filled order, followed by correction and cancellation of executions
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyAvgPxLastQtyLastPxExecId

(Exec
RefID)

Comment
1New Order(X)10000
2Execution(X)RejectedRejected10000000AIf order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew1000001000000B
3Execution(X)TradePartially Filled10000100090001001000100CExecution for 1000 @ 100
4Execution(X)TradeFilled100001000001099000110DExecution for 9000 @ 110
5Execution(X)Trade CancelPartially Filled100009000100011000E (C)Cancel execution for 1000.
6Execution(X)Trade CorrectPartially Filled10000900010001009000100F (D)Correct price on execution for 9000 to 100.
7Execution(X)TradeFilled100001000001021000120GExecution for 1000 @ 120
8Execution(X)Trade CorrectFilled100001000001209000120H (F)Correct price on execution for 9000 to 120
9Replace Request (Y,X)12000Request to increase order qty
10Execution (Y,X)Pending ReplacePending Replace1000010000012000I
11Execution (Y,X)ReplacePartially Filled1200010000200012000J
12Execution(Y)Trade CorrectPartially Filled120001050015001209500120K (H)Correct execution of 9000 @ 120 to 9500 @ 120
J.1.b – A canceled order followed by a busted execution and a new execution
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyExecID

(Exec
RefID)

Comment
1New Order(X)10000
2Execution(X)NewNew100000100000A
3Execution(X)TradePartially Filled10000500050005000BLastPx=50
4Cancel Request(Y,X)10000
5Execution
(Y,X)
Pending CancelPending Cancel10000500050000C
6Execution (Y,X)CanceledCanceled10000500000D
7Execution(X)Trade CancelCanceled10000000E(B)Cancel of the execution. ‘Canceled’ order status takes precedence over ‘New’
8Execution(X)TradeCanceled10000400004000FFill for 4000. LastPx=51
J.1.c – GTC order partially filled, restated (renewed) and partially filled the following day, with corrections of quantity on both executions
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyDay

OrderQty

Day

CumQty

ExecID

(Exec
RefID)

Comment
Day 1,1New Order(X)10000
Day 1,2Execution(X)NewNew100000100000A
Day 1,3Execution(X)TradePartially Filled10000200080002000BExecution for 2000
Day 1,4Execution(X)Done for DayDone for Day10000200080000COptional at end of trading day
Day 2,1Execution(X)RestatedPartially Filled1000020008000080000DExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2Execution(X)TradePartially Filled1000030007000100080001000EExecution for 1000
Day 2,3Execution(X)Trade CorrectPartially Filled1000025007500150085001000F (B)Correct quantity on previous day’s execution from 2000 to 1500
Day 2,4Execution(X)Trade CorrectPartially Filled10000200080005008500500G (E)Correct quantity on today’s execution from 1000 to 500
J.1.d – Part-filled order Done for day followed by trade correction and bust
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyExecID

(Exec
RefID)

Comment
1New Order(X)10000
2Execution(X)NewNew100000100000A
3Execution(X)TradePartially Filled10000500050005000BLastPx=50
4Execution(X)Done for DayDone for day10000500000CDone for day message sent
5Execution(X)Trade CorrectDone for day10000400004000D (B)Correct quantity on execution to 4000. LastPx = 50
6Execution(X)Trade CancelDone for day10000000E (D)Done for Day OrdStatus takes precedence

K Trading Halt

K.1.a – Trading Halt – Reinstate
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000ExecInst set to reinstate on trading halt
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Trading halt established
4Trading halt lifted
5Execution(X)TradeFilled1000010000010000
K.1.b – Trading Halt – Cancel
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000ExecInst set to cancel on trading halt
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Trading halt established
4ExecutionCanceledCanceled10000000Order canceled due to trading halt. ExecRestatementReason = Canceled due to trading halt

L Miscellaneous

L.1.a– Transmitting a guarantee of execution prior to execution
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyLastPxComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000
3Execution(X)StoppedStopped10000010000100050.10Text=”You are guaranteed to buy 1000 at 50.10”; This is similar to the concept of a ‘protected’ trade. Not actually reporting a trade, so ExecType = Stopped
4Execution(X)TradeStopped1000010009000100050.00Executed price is better than guaranteed
L.1.b- Use of CashOrderQty
TimeMessage
Received
(ClOrdID, OrigClOrdID)
Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCash

OrderQty

CumQtyLeavesQtyLastQtyLastPxComment
1New Order(X)10000Currency=EUR. A buy order to invest 10,000 EUR.
2Execution(X)RejectedRejected10000000If order is rejected
2Execution(X)NewNew5001000005000Assuming product has a unit price of 20 EUR at time of order receipt
3Execution(X)TradePartially Filled5001000020030020020.1Execution of 200 @20.1 (i.e. does not have to be at the ‘conversion price’ of 20)
4Execution(X)TradeFilled50010000500030020.2Execution of 300 @20.2 (i.e. does not have to be at the ‘conversion price’ of 20)

Order State Change Matrices for Exchanges

This section addresses issues with order state changes in an exchanges or marketplace environment. These supplement the general Order State Change Matrices above and are documented as specific to exchanges and marketplaces. The titles and references have been chosen in accordance with the general matrices. These specific cases supersede the general ones when implementing the FIX Protocol for exchanges and centralized marketplaces. General Order State Changes matrices that are not mentioned in this section apply to the exchange and centralized marketplace environment. Please also refer to the general Order State Change Matrices defined in Chapter 3 General Order State Change Matrices.

Overview of Scenarios

A Vanilla

RefDescription
A.1.aFilled order after order rests on book
A.1.bPart-filled day order after order rests on book, done for day
A.1.cOrder filled upon hitting the book
A.1.dOrder partially filled upon hitting the book

I TimeInForce

RefDescription
I.1.aFill or Kill order cannot be filled
I.1.bImmediate or Cancel order that cannot be immediately hit

Applicability of general scenarios depicted in Chapter 3 General Order State Change Matrices for electronic exchange/ECN environments:

  • Filled and Canceled are considered to be terminal states of an order, i.e. a state transition from Filled or Canceled to Partially Filled or Pending Replace should be avoided.
  • Pending order states requiring additional messages should be avoided in the interest of performance.

The ExecType is used to identify the purpose of the execution report message. The value of ExecType will typically be New to convey the fact that a new order has been received and processed. However, the value of OrdStatus in this initial response may not necessarily be New as the order might have been executed immediately. The initial value of OrdStatus can therefore also be Partially Filled or Filled. It can even be Canceled if the order has time in force values such as Fill or Kill and Immediate or Cancel and the order could not be executed immediately (and in its entirety in case of Fill or Kill).

The following diagram illustrates the complete set of state transitions recommended for electronic exchange/ECN environments. The dotted lines lead to initial order states other than New and apply to cases where an order does not simply rest on the order book after having been accepted by the exchange/ECN. It is a possibility aimed at increasing performance by reducing the overall number of “Execution Report” messages that need to be provided and processed. Message flows with explicit messages to convey the order state New are equally possible.

Order State Change Diagrams for Exchanges

Scenarios for State Transitions

A Vanilla

A.1.a – Filled order after order rests on book
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by salesperson
2Execution(X)NewNew100000100000
3Execution(X)RejectedRejected10000000If order is rejected by trader/exchange
3Execution(X)TradePartially Filled10000200080002000Execution of 2000
4Execution(X)TradePartially Filled10000300070001000Execution of 1000
5Execution(X)TradeFilled100001000007000Execution of 7000
A.1.b – Part-filled day order after order rests on book, done for day
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by the exchange
2Execution(X)NewNew100000100000
3Execution(X)TradePartially Filled10000200080002000Execution of 2000
4Execution(X)TradePartially Filled10000300070001000Execution of 1000
5Execution(X)Done for DayDone for Day10000300000Assuming day order. See other examples which cover GT orders
A.1.c – Order filled upon hitting the book
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by the exchange
2Execution(X)TradeFilled1000010000010000Immediate execution of 10000
A.1.d – Order partially filled upon hitting the book
TimeMessage Received

(ClOrdID, OrigClOrdID)

Message
Sent
(ClOrdID, OrigClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000
2Execution(X)RejectedRejected10000000If order is rejected by the exchange
2Execution(X)TradePartially Filled10000700030007000Immediate execution of 7000

I TimeInForce

I.1.a – Fill or Kill order that cannot be filled
TimeMessage Received

(ClOrdID)

Message
Sent
(ClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000Order is FOK
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker,the exchange, ECN)
2Execution(X)NewNew100000100000If messages are not bundled
3Execution(X)CanceledCanceled10000000If order cannot be immediately filled
4New Order(Y)10000Order is FOK
5Execution(Y)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
6Execution(Y)CanceledCanceled10000000If message bundling is being used and order cannot be immediately filled
I.1.b – Immediate or Cancel order that cannot immediately be hit completely
TimeMessage Received

(ClOrdID)

Message
Sent
(ClOrdID)
ExecTypeOrdStatusOrderQtyCumQtyLeavesQtyLastQtyComment
1New Order(X)10000Order is IOC
2Execution(X)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
2Execution(X)NewNew100000100000If messages are not bundled
3Execution(X)TradePartially Filled10000100090001000Execution for 1000
4Execution(X)CanceledCanceled10000100000If order cannot be immediately hit completely
5New Order(Y)10000Order is IOC
6Execution(Y)RejectedRejected10000000If order is rejected by sell-side (broker, exchange, ECN)
6Execution(Y)TradeCanceled10000100090001000If message bundling is being used and execution of 1000 occurs immediately upon hitting the book