|
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:
| Ref |
Group |
Description |
| 1 |
Vanilla |
Filled order |
| 2 |
Vanilla |
Part-filled day order, done for day |
| 3 |
Cancel |
Cancel request issued for a zero-filled order |
| 4 |
Cancel |
Cancel request issued for a part-filled order — executions occur whilst cancel request is active |
| 5 |
Cancel |
Cancel request issued for an order that becomes filled before cancel request can be accepted |
| 6 |
Cancel |
Cancel request issued for an order that has not yet been acknowledged |
| 7 |
Cancel |
Cancel request issued for an order that has not yet been acknowledged — the acknowledgment and the cancel request ‘cross’ |
| 7a |
Cancel |
Cancel request issued for an unknown order |
| 8 |
Replace to increase qty |
Zero-filled order, cancel/replace request issued to increase order qty |
| 9 |
Replace to increase qty |
Part-filled order, followed by cancel/replace request to increase order qty, execution occurs whilst order is pending replace |
| 10 |
Replace to increase qty |
Filled order, followed by cancel/replace request to increase order quantity |
| 11 |
Replace not for qty change |
Cancel/replace request (not for quantity change) is rejected as a fill has occurred |
| 12 |
Replace to decrease qty |
Cancel/replace request sent whilst execution is being reported — the requested order qty exceeds the cum qty. Order is replaced then filled |
| 13 |
Replace to decrease qty |
Cancel/replace request sent whilst execution is being reported — the requested order qty equals the cum qty — order qty is amended to cum qty |
| 14 |
Replace to decrease qty |
Cancel/replace request sent whilst execution is being reported — the requested order qty is below cum qty — order qty is amended to cum qty |
| 15 |
Replace – sequence |
One cancel/replace request is issued which is accepted — another one is issued which is also accepted |
| 16 |
Replace – sequence |
One cancel/replace request is issued which is rejected before order becomes pending replace — then another one is issued which is accepted |
| 17 |
Replace – sequence |
One cancel/replace request is issued which is rejected after it is in pending replace — then another one is issued which is accepted |
| 18 |
Replace – chaining |
One cancel/replace request is issued followed immediately by another — broker processes sequentially |
| 19 |
Replace – chaining |
One cancel/replace request is issued followed immediately by another — broker processes pending replaces before replaces |
| 20 |
Replace – chaining |
One cancel/replace request is issued followed immediately by another — both are rejected |
| 21 |
Replace – chaining |
One cancel/replace request is issued followed immediately by another — broker rejects the second as order is pending replace |
| 22 |
Unsolicited reports |
Telephoned order |
| 23 |
Unsolicited reports |
Unsolicited cancel of a part-filled order |
| 24 |
Unsolicited reports |
Unsolicited replacement of a part-filled order |
| 25 |
Unsolicited reports |
Unsolicited reduction of order quantity by sell side (e.g. for US ECNs to communicate Nasdaq SelectNet declines) |
| 26 |
Order reject |
Order rejected due to duplicate ClOrdID |
| 27 |
Order reject |
Poss resend and duplicate ClOrdID |
| 28 |
Order Reject |
Order rejected because the order has already been verbally submitted |
| 29 |
Status |
Order status request rejected for unknown order |
| 30 |
Status |
Transmitting a CMS-style "Nothing Done" in response to a status request |
| 31 |
Status |
Order sent, immediately followed by a status request. Subsequent status requests sent during life of order |
| 32 |
GT |
GTC order partially filled, restated (renewed) and partially filled the following day |
| 33 |
GT |
GTC order with partial fill, a 2:1 stock split then a partial fill and fill the following day |
| 34 |
GT |
GTC order partially filled, restated (renewed) and canceled the following day |
| 35 |
GT |
GTC order partially filled, restated (renewed) followed by replace request to increase quantity |
| 36 |
TIF |
Fill or Kill order cannot be filled |
| 37 |
TIF |
Immediate or Cancel order that cannot be immediately hit |
| 38 |
Execution correct/cancel |
Filled order, followed by correction and cancellation of executions |
| 39 |
Execution correct/cancel |
A canceled order followed by a busted execution and a new execution |
| 40 |
Execution correct/cancel |
GTC order partially filled, restated (renewed) and partially filled the following day, with corrections of quantity on both executions |
| 41 |
Execution correct/cancel |
Part-filled order Done for day followed by trade correction and bust |
| 42 |
Stopped/Guarantee |
Transmitting a guarantee of execution prior to execution |
| 43 |
Trading Halt |
Trading Halt — Reinstate |
| 44 |
Trading Halt |
Trading Halt — Cancel |
|
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
|
