Order State Change Matrices - New and Pending Cancel

Imported from previous forum

Hi,
I have a question about OrdStatus in FIX4.4 Vol. 4, in the section “Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet been acknowledged
Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which has higher precedence than “New”?

You need to look at the comment of line 4 which says “Order accepted before cancel request is processed.”. The cancel request is therefore unknown at the time that this ER is being produced, even if it is shown to come after the ER in step 3 that has this knowledge.

Regards,
Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the section
“Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet been
acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which has higher
precedence than “New”?

Thank you, Hanno
I understand what you described.

I’m still wondering not about the case B.1.d but in general case.
I’ve never seen any ExecReport that has
ExecType=New and OrdStatus=PendingCancel
in the FIX specification.
Is a ExecReport allowed to have ExecType=New and OrdStatus=PendingCancel?
Or has anyone seen it in the real usage?

Regards,

You need to look at the comment of line 4 which says “Order accepted
before cancel request is processed.”. The cancel request is therefore
unknown at the time that this ER is being produced, even if it is shown
to come after the ER in step 3 that has this knowledge.

Regards, Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the section
“Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet been
acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which has
higher precedence than “New”?

ExecType=New only applies to a response to an order entry. A cancel prior to an entry is not possible as the order does not yet exist. A cancel after order entry changes ExecType from New to Pending Cancel or Cancelled. Therefore I do not see what semantic ExecType=New and OrdStatus=PendingCancel is supposed to convey whether you “allow” it or not.

Regards,
Hanno.

Thank you, Hanno I understand what you described.

I’m still wondering not about the case B.1.d but in general case. I’ve
never seen any ExecReport that has ExecType=New and
OrdStatus=PendingCancel in the FIX specification. Is a ExecReport
allowed to have ExecType=New and OrdStatus=PendingCancel? Or has anyone
seen it in the real usage?

Regards,

You need to look at the comment of line 4 which says “Order accepted
before cancel request is processed.”. The cancel request is therefore
unknown at the time that this ER is being produced, even if it is
shown to come after the ER in step 3 that has this knowledge.

Regards, Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the
section “Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet been
acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which has
higher precedence than “New”?

Let me explain my situation.
My program is a FIX engine which also interfaces to exchage native API.
Values in parentheses of ExecReport are (ExecType, OrdStatus).

  Client                             MY PROGRAM                            Exchange
                                        <OrdStatus>
  1.          New Order --->
    
  2.                                    <PendingNew>     
    
  3.                                                             New Order --->
    
  4.        Cancel Request --->                  
    
  5.                                  <PendingCancel>
    
  6.        <--- ExecReport                           Cancel Request --->
    (PendingCancel,PendingCancel)
    
  7.                                                          <--- Order Confirmation
    
  8.                              <PendingCancel + New>
    
  9.        <--- ExecReport
                 (New,xxx)
    
  10.                                                       <--- Cancelling Confirmation
    
  11.                                    <Cancelled>
    
  12.        <--- ExecReport
          (Cancelled,Cancelled)
    

In the row 8, what should be the value of xxx ?

ExecType=New only applies to a response to an order entry. A cancel
prior to an entry is not possible as the order does not yet exist.
A cancel after order entry changes ExecType from New to Pending
Cancel or Cancelled. Therefore I do not see what semantic
ExecType=New and OrdStatus=PendingCancel is supposed to convey
whether you “allow” it or not.

Regards, Hanno.

Thank you, Hanno I understand what you described.

I’m still wondering not about the case B.1.d but in general case. I’ve
never seen any ExecReport that has ExecType=New and
OrdStatus=PendingCancel in the FIX specification. Is a ExecReport
allowed to have ExecType=New and OrdStatus=PendingCancel? Or has
anyone seen it in the real usage?

Regards,

You need to look at the comment of line 4 which says “Order accepted
before cancel request is processed.”. The cancel request is
therefore unknown at the time that this ER is being produced, even
if it is shown to come after the ER in step 3 that has this
knowledge.

Regards, Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the
section “Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet been
acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which has
higher precedence than “New”?

Repost
Sorry, the post was untidy.

Let me explain my situation. My program is a FIX engine which also
interfaces to exchage native API. Values in parentheses of ExecReport are (ExecType, OrdStatus).

…Client …MY PROGRAM… Exchange
…(OrdStatus)…

  1. …New Order —>…
  2. …(PendingNew)…
  3. …New Order —>…
  4. …Cancel Request —>…
  5. …(PendingCancel)…
  6. …<— ExecReport…Cancel Request —>…
    …(PendingCancel,PendingCancel)…
  7. …<— Order Confirmation…
  8. …(PendingCancel + New)…
  9. …<— ExecReport…
    …(New,xxx)…
  10. …<— Cancelling Confirmation…
  11. …(Cancelled)…
  12. …<— ExecReport …
    …(Cancelled,Cancelled)…

In the row 9, what should be the value of xxx ?

ExecType=New only applies to a response to an order entry. A cancel
prior to an entry is not possible as the order does not yet exist.
A cancel after order entry changes ExecType from New to Pending
Cancel or Cancelled. Therefore I do not see what semantic
ExecType=New and OrdStatus=PendingCancel is supposed to convey
whether you “allow” it or not.

Regards, Hanno.

Thank you, Hanno I understand what you described.

I’m still wondering not about the case B.1.d but in general case.
I’ve never seen any ExecReport that has ExecType=New and
OrdStatus=PendingCancel in the FIX specification. Is a ExecReport
allowed to have ExecType=New and OrdStatus=PendingCancel? Or has
anyone seen it in the real usage?

Regards,

You need to look at the comment of line 4 which says “Order
accepted before cancel request is processed.”. The cancel request
is therefore unknown at the time that this ER is being produced,
even if it is shown to come after the ER in step 3 that has this
knowledge.

Regards, Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the
section “Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet
been acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which
has higher precedence than “New”?

[ original email was from Carfield Yim - carfield.w.yim@jpmorgan.com ]
In fact, from page 214 of FIX4.2 spec. , what you suggest is right, ordstatus is “pending replace” ( probably also for pending cancel ) and exectype is partial at that time, time 5 and time 6

Question was about FIX 4.4 I believe. ExecTransType would need to be considered as well in case of FIX 4.2.

In fact, from page 214 of FIX4.2 spec. , what you suggest is right,
ordstatus is “pending replace” ( probably also for pending cancel ) and
exectype is partial at that time, time 5 and time 6

Exec Type - Identifies the Event associated with the ER
Order Status - Identifies the Status of the order at each event.

To my understanding, Exec Type vary from Order status in only two events (Replaced, Trade) where the Exec Type will show the Event and the order status will be (New, PF, Filled). For all other states, both will be same.

In Row 9, it should be New, New as the current status of the order is New and ER is issued for reporting Confirmation of Order.

If you have a concern in your scenario of sending ERs with order status as Pending cancel, New and Cancelled in that sequence, then this is a defined scenario in FIX order Matrices in 4.3/4.4 etc.

Regards, Kasim

It looks like you are changing the status of the order prior to having received confirmation of your request. This way, you already “switch” to “pending cancel” before having processed the confirmation of the order entry. The cancellation request could be rejected, i.e. you cannot make a change to the order status based on your request.

You also distinguish between “client” and “my program” and say that the latter is a FIX engine. I do not understand why the FIX engine and not the client is the one keeping state of the order.

Repost Sorry, the post was untidy. …-
… Let
me explain my situation. My program is a FIX engine which also
interfaces to exchage native API. Values in parentheses of ExecReport
are (ExecType, OrdStatus).

…Client …MY
PROGRAM… Exchange …-
…(OrdStatus)…

  1. …New Order —

  2. …(PendingNew)…-
  3. …-
    …New Order —>…
  4. …Cancel Request —

  5. …(PendingCancel)…-
  6. …<— ExecReport…Cancel
    Request —>… …(PendingCancel,PendingCancel)…-
  7. …<—
    Order Confirmation… 8.
    …(PendingCancel +
    New)…
  8. …<— ExecReport…-
    … …(New,xxx)…-
  9. …<— Cancelling
    Confirmation…
  10. …(Cancelled)…-
  11. …<— ExecReport

    …(Cancelled,Cancelled)…-

In the row 9, what should be the value of xxx ?

ExecType=New only applies to a response to an order entry. A cancel
prior to an entry is not possible as the order does not yet exist. A
cancel after order entry changes ExecType from New to Pending Cancel
or Cancelled. Therefore I do not see what semantic ExecType=New and
OrdStatus=PendingCancel is supposed to convey whether you “allow” it
or not.

Regards, Hanno.

Thank you, Hanno I understand what you described.

I’m still wondering not about the case B.1.d but in general case.
I’ve never seen any ExecReport that has ExecType=New and
OrdStatus=PendingCancel in the FIX specification. Is a ExecReport
allowed to have ExecType=New and OrdStatus=PendingCancel? Or has
anyone seen it in the real usage?

Regards,

You need to look at the comment of line 4 which says “Order
accepted before cancel request is processed.”. The cancel
request is therefore unknown at the time that this ER is being
produced, even if it is shown to come after the ER in step 3
that has this knowledge.

Regards, Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the
section “Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet
been acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which
has higher precedence than “New”?

It looks like you are changing the status of the order prior to having
received confirmation of your request. This way, you already “switch” to
“pending cancel” before having processed the confirmation of the order
entry. The cancellation request could be rejected, i.e. you cannot make
a change to the order status based on your request.

You also distinguish between “client” and “my program” and say that the
latter is a FIX engine. I do not understand why the FIX engine and not
the client is the one keeping state of the order.

My program has to keep the order statuses because it talks FIX so it has to be able to response the order status. The Exchange native API doesn’t provide us the order statuses as FIX needs.

It looks like you are changing the status of the order prior to having
received confirmation of your request. This way, you already “switch”
to “pending cancel” before having processed the confirmation of the
order entry. The cancellation request could be rejected, i.e. you
cannot make a change to the order status based on your request.

You also distinguish between “client” and “my program” and say that
the latter is a FIX engine. I do not understand why the FIX engine and
not the client is the one keeping state of the order.

My program has to keep the order statuses because it talks FIX so it has
to be able to response the order status. The Exchange native API doesn’t
provide us the order statuses as FIX needs.

Understood, but my question remains, i.e. when do you update the order status? If you wait for confirmation of the cancel request, your order status cannot be pending cancel when the confirmation of the order entry arrives and you should not have a problem.

I understand the difficulties you have with the native API if it does not support the same state and/or transaction model. You have to hide this at the FIX level and cannot try to impose the non-FIX concepts from the exchange on your FIX messages. This can be a significant effort depending on the conceptual differences you encounter.

Regards,
Hanno.

Maybe I can help answer the question by asking another question.

What should the status request return on line 5 in this same sequence?

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Status Request (X) —>
  5. Execution Report (?) ← ? ?

Based on this thread, it seems like people are arguing for one of the following:

(X) <— OrderStatus PendingNew
or
(Y,X) <—OrderStatus PendingCancel

I think the result depends on how the engine handles the pending cancel states. If it treats them like a real state transition, then I would expect the status to return PendingCancel. If the engine just sends an immediate PendingCancel acknowledgement without changing the state on the order, then presumably the status request would return PendingNew.

I tend to think that it should return PendingCancel. It seems strange that a status request should return something other than the last reported status if the order state hasn’t changed. If you take this stance, then I think the answer to your question is that the order confirmation would also return PendingCancel.

In some ways, I think it’s very similar to C.1.b (line 6) in the state transitions when you receive an execution on an order while its pending replacement.

Ryan

You need to look at the comment of line 4 which says “Order accepted
before cancel request is processed.”. The cancel request is therefore
unknown at the time that this ER is being produced, even if it is shown
to come after the ER in step 3 that has this knowledge.

Regards, Hanno.

Hi, I have a question about OrdStatus in FIX4.4 Vol. 4, in the section
“Order State Change Matrices”.
B.1.d – Cancel request issued for an order that has not yet been
acknowledged Buy Side Sell Side ExecType OrdStatus

  1. New Order (X) —>
  2. Cancel Request (Y,X) —>
  3. Execution Report (Y,X) <— PendingCancel PendingCancel
  4. Execution Report (X) <— New New
  5. Execution Report (Y,X) <— Canceled Canceled

Why is the OrdStatus in the row 4. not “Pending Cancel” which has
higher precedence than “New”?