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:

A Vanilla

Ref Description
A.1.a Filled order
A.1.b Part-filled day order, done for day

B Cancel

Ref Description
B.1.a Cancel request issued for a zero-filled order
B.1.b Cancel request issued for a part-filled order – executions occur whilst cancel request is active
B.1.c Cancel request issued for an order that becomes filled before cancel request can be accepted
B.1.d Cancel request issued for an order that has not yet been acknowledged
B.1.e Cancel request issued for an order that has not yet been acknowledged – the acknowledgment and the cancel request "cross"
B.1.f Cancel request issued for an unknown order

C Cancel/Replace quantity changes

C.1 Replace to increase quantity

Ref Description
C.1.a Zero-filled order, cancel/replace request issued to increase order qty
C.1.b Part-filled order, followed by cancel/replace request to increase order qty, execution occurs whilst order is pending replace
C.1.c Filled order, followed by cancel/replace request to increase order quantity

C.2 Replace not for quantity change

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

C.3 Replace to decrease quantity

Ref Description
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
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
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

D Cancel/Replace sequencing and chaining

D.1 Sequencing

Ref Description
D.1.a One cancel/replace request is issued which is accepted – another one is issued which is also accepted
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
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

D.2 Chaining

Ref Description
D.2.a One cancel/replace request is issued followed immediately by another – broker processes sequentially
D.2.b One cancel/replace request is issued followed immediately by another – broker processes pending replaces before replaces
D.2.c One cancel/replace request is issued followed immediately by another – both are rejected
D.2.d One cancel/replace request is issued followed immediately by another – broker rejects the second as order is pending replace

E Unsolicited/Reinstatement

Ref Description
E.1.a Telephoned order
E.1.b Unsolicited cancel of a part-filled order
E.1.c Unsolicited replacement of a part-filled order
E.1.d Unsolicited reduction of order quantity by sell side (e.g. for US ECNs to communicate Nasdaq SelectNet declines)
E.1.e Unsolicited cancel of "cancel if not best" order
E.1.f Order is sent to exchange, held waiting for activation and then activated

F Order Reject

Ref Description
F.1.a Order rejected due to duplicate ClOrdID
F.1.b Poss resend and duplicate ClOrdID
F.1.c Order rejected because the order has already been verbally submitted

G Status

Ref Description
G.1.a Order status request rejected for unknown order
G.1.b Transmitting a CMS-style "Nothing Done" in response to a status request
G.1.c Order sent, immediately followed by a status request. Subsequent status requests sent during life of order

H GT

Ref Description
H.1.a GTC order partially filled, restated (renewed) and partially filled the following day
H.1.b GTC order with partial fill, a 2:1 stock split then a partial fill and fill the following day
H.1.c GTC order partially filled, restated (renewed) and canceled the following day
H.1.d GTC order partially filled, restated (renewed) followed by replace request to increase quantity

I TimeInForce

Ref Description
I.1.a Fill or Kill order cannot be filled
I.1.b Immediate or Cancel order that cannot be immediately hit

J Execution Cancels/Corrects

Ref Description
J.1.a Filled order, followed by correction and cancellation of executions
J.1.b A canceled order followed by a busted execution and a new execution
J.1.c GTC order partially filled, restated (renewed) and partially filled the following day, with corrections of quantity on both executions
J.1.d Part-filled order Done for day followed by trade correction and bust

K Trading Halt

Ref Description
K.1.a Trading Halt – Reinstate
K.1.b Trading Halt – Cancel

L Miscellaneous

Ref Description
L.1.a Transmitting a guarantee of execution prior to execution (Stopped/Guarantee)
L.1.b Use of CashOrderQty

The Table below shows which state transitions have been illustrated by the matrices in this Appendix (marked with an asterisk). The row represents the current value of OrdStatus 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 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) *

How to read the Order State Change Matrices:

  • The "Execution Report" message is referred to simply as "Execution"
  • The "Order Cancel/Replace Request" and "Order Cancel Request" messages are referred to as "Replace Request" and "Cancel Request" respectively
  • The shaded rows represent messages sent from buy-side to the sell-side
  • In general where two lines of a matrix share the same time, this means either
    • that there are two possible paths (e.g. a request is accepted or rejected) – in this case the first row of the two possible paths is the reject case which is italicized. The non-italicized row is the path that is continued by the remainder of the matrix
    • that two messages are being sent at the same time but in different directions such that the messages cross on the connection (e.g. a cancel request is sent at the same time as the sell-side is sending an execution) – in this case both lines have bold text
  • For scenarios involving cancel requests or cancel/replace requests "X" refers to the original order, "Y" refers to the cancel/replacing order. A similar convention is used for corrections or cancels to executions