Imported from previous forum
Hello,
I have a question regarding FIX compliance in an emulated change environment.
The sequence of events is as follows :
- FIX Client issues a change request for an unfilled order.
- FIX Server forwards change request to (non-fix) exchange.
- Exchange emulates change in two steps : cancels existing order and adds a new one in its place. However, the cancel was successful and the order add was not. The current state of the order is canceled.
My problem lies in what to send back to the FIX Client now.
Currently, I am sending back an Order Cancel Reject with Status Canceled.
However, my customers expect to see two responses - one for the rejected change and then an execution report relaying the canceled status of the order.
Which is correct - the current behavior or the behavior expected by the customer?
Thanks,
Prateek Jain
Thank you for the question as it helps to illustrate a key issue when it comes to FIX. FIX is not just an interface, it is an entire set of concepts that needs to go all the way into the core system. This is often not possible if one deals with legacy systems having non-FIX concepts. In your case the transactional model of the core system does not really offer a modify. It is more of a shortcut for two independent transactions CANCEL and NEW whereby the first could succeed and the second could fail.
My first advice would be to avoid emulation and not support FIX OrderCancelReplace. You did not mention whether the new order is actually the old order or not. Imagine the order had already been partially filled and the modification does NOT fail. Does the “new” order maintain its status “Partially Filled” with CumQty>0, does it have the same OrderID value or a new one? It needs to be one and the same order for your emulation to work at all.
A modification leading to a cancellation is not unknown to FIX. It happens when you reduce OrderQty to or below CumQty, i.e. when you want less or equal to the amount already executed. However, one does not respond with a OrderCancelReject in this case. One sends an ExecutionReport and the order status changes from Partially Filled to Filled (higher precedence than Cancelled). A reject message always says “I have validated your request and refuse to act upon it for reason XYZ, i.e. there is no change whatsoever”. By sending an OrderCancelReject as a response to the modification request, you are telling the customer that nothing happened. You must NOT change the order status at this point. The rejection reason could and should already point to the fact that something will happen (e.g. “failed modification leading to order cancellation”). A second, unsolicited ExecutionReport should then follow that conveys the actual order cancellation together with OrdStatus = Cancelled.
Bottom line is that I am afraid your customer is right, which he should always be 
Regards,
Hanno.
Hello,
I have a question regarding FIX compliance in an emulated change environment.
The sequence of events is as follows :
- FIX Client issues a change request for an unfilled order.
- FIX Server forwards change request to (non-fix) exchange.
- Exchange emulates change in two steps : cancels existing order and adds a new one in its place. However, the cancel was successful and the order add was not. The current state of the order is canceled.
My problem lies in what to send back to the FIX Client now.
Currently, I am sending back an Order Cancel Reject with Status Canceled.However, my customers expect to see two responses - one for the rejected change and then an execution report relaying the canceled status of the order.
Which is correct - the current behavior or the behavior expected by the customer?
Thanks,
Prateek Jain
Thanks Hanno.
Sometimes, I wish everyone would just use FIX.
Kind Regards,
Prateek
Hello Hanno,
I couldn’t find anything in the standard that forbids a CancelReject with OrdStatus=Canceled as reply for a CancelReplaceRequest.
Is there a diagram available that describes valid order state transitions?
I’m only aware of the order state change matrices in volume 4, but it’s stated that it does not describe all valid scenarios.
For me the reject with state canceled make sense. Why else do we need OrdStatus in the reject if the state can not change with a reject?
Regards
Oliver
Thank you for the question as it helps to illustrate a key issue when it comes to FIX. FIX is not just an interface, it is an entire set of concepts that needs to go all the way into the core system. This is often not possible if one deals with legacy systems having non-FIX concepts. In your case the transactional model of the core system does not really offer a modify. It is more of a shortcut for two independent transactions CANCEL and NEW whereby the first could succeed and the second could fail.
My first advice would be to avoid emulation and not support FIX OrderCancelReplace. You did not mention whether the new order is actually the old order or not. Imagine the order had already been partially filled and the modification does NOT fail. Does the “new” order maintain its status “Partially Filled” with CumQty>0, does it have the same OrderID value or a new one? It needs to be one and the same order for your emulation to work at all.
A modification leading to a cancellation is not unknown to FIX. It happens when you reduce OrderQty to or below CumQty, i.e. when you want less or equal to the amount already executed. However, one does not respond with a OrderCancelReject in this case. One sends an ExecutionReport and the order status changes from Partially Filled to Filled (higher precedence than Cancelled). A reject message always says “I have validated your request and refuse to act upon it for reason XYZ, i.e. there is no change whatsoever”. By sending an OrderCancelReject as a response to the modification request, you are telling the customer that nothing happened. You must NOT change the order status at this point. The rejection reason could and should already point to the fact that something will happen (e.g. “failed modification leading to order cancellation”). A second, unsolicited ExecutionReport should then follow that conveys the actual order cancellation together with OrdStatus = Cancelled.
Bottom line is that I am afraid your customer is right, which he should always be
Regards,
Hanno.Hello,
I have a question regarding FIX compliance in an emulated change environment.
The sequence of events is as follows :
- FIX Client issues a change request for an unfilled order.
- FIX Server forwards change request to (non-fix) exchange.
- Exchange emulates change in two steps : cancels existing order and adds a new one in its place. However, the cancel was successful and the order add was not. The current state of the order is canceled.
My problem lies in what to send back to the FIX Client now.
Currently, I am sending back an Order Cancel Reject with Status Canceled.However, my customers expect to see two responses - one for the rejected change and then an execution report relaying the canceled status of the order.
Which is correct - the current behavior or the behavior expected by the customer?
Thanks,
Prateek Jain
Hi Oliver,
In general, you cannot expect the spec to define everything that is forbidden. It also cannot cover all flavors of what is allowed. The order state model and the flow of messages are two different things. OrderCancelReject has OrdStatus to convey the final order state in which it was cancelled. For example it could be New, Partially Filled or Filled (see Volume 4 scenarios B.1.a-c). Your order could be filled as you submit the request. In that sense I am contradicting my previous post that you must NOT change the status. If the modification request encounters an order that has already been cancelled (e.g. by Market Operations), you might even report back OrdStatus=Cancelled. It would not happen at our exchange because cancelled orders are immediately removed, i.e. the rejection would say “order not found”. In your case however, the request itself is the cause of the cancellation. The order status is changed temporarily as part of the modification, i.e. from X to Cancelled and back to X if it succeeds. The modification fails half-way so that I would expect the order status to go back to X, You would like to report back the intermediate state of the order which I disagree with. The consequence of the failure of the modification half-way is that the user must be told that the order is no longer available. This is an unsolicited cancellation and the ExecutionReport is the message to use for that.
You are faced with an atomic FIX modification message that has to be mapped to a non-atomic legacy system modification. The problem will not go away so the question is how much of that you make visible to the FIX user. The fact that this issue has made it into the forum shows that not everybody is on the same page regarding the answer. I still believe the standard FIX use will more easily digest a rejected modification followed by an unsolicited cancel.
What about my question from my previous post? I asked if the “new” order maintains a status “Partially Filled” with CumQty>0, does it have the same OrderID value or a new one? If the new order always comes with CumQty=0, i.e. total order qty and previous fills are not transferred to the new order, then we have a different issue related to a successful modification.
Regards,
Hanno.
Hello Hanno,
I couldn’t find anything in the standard that forbids a CancelReject with OrdStatus=Canceled as reply for a CancelReplaceRequest.
Is there a diagram available that describes valid order state transitions?
I’m only aware of the order state change matrices in volume 4, but it’s stated that it does not describe all valid scenarios.For me the reject with state canceled make sense. Why else do we need OrdStatus in the reject if the state can not change with a reject?
Regards
Oliver
Hi Hanno,
we are trying to emulate a change request with a delete/add transaction for exchanges that do not support a change. The intermediate status canceled (after the delete reply) is not send to the client. As long as the following add transactions succeeds the client does not see any difference to a normal change transaction. From the client point of view it’s only one order. Also a CumQty>0 before the change will remain the same after the emulated change. OrderID will change but that could be even the case for real cancel replace request.
It think many FIX users may not expect a change reject with status canceled, but since it’s undefined one could argue that it is compliant to the standard.
Regards
Oliver
Hi Oliver,
In general, you cannot expect the spec to define everything that is forbidden. It also cannot cover all flavors of what is allowed. The order state model and the flow of messages are two different things. OrderCancelReject has OrdStatus to convey the final order state in which it was cancelled. For example it could be New, Partially Filled or Filled (see Volume 4 scenarios B.1.a-c). Your order could be filled as you submit the request. In that sense I am contradicting my previous post that you must NOT change the status. If the modification request encounters an order that has already been cancelled (e.g. by Market Operations), you might even report back OrdStatus=Cancelled. It would not happen at our exchange because cancelled orders are immediately removed, i.e. the rejection would say “order not found”. In your case however, the request itself is the cause of the cancellation. The order status is changed temporarily as part of the modification, i.e. from X to Cancelled and back to X if it succeeds. The modification fails half-way so that I would expect the order status to go back to X, You would like to report back the intermediate state of the order which I disagree with. The consequence of the failure of the modification half-way is that the user must be told that the order is no longer available. This is an unsolicited cancellation and the ExecutionReport is the message to use for that.
You are faced with an atomic FIX modification message that has to be mapped to a non-atomic legacy system modification. The problem will not go away so the question is how much of that you make visible to the FIX user. The fact that this issue has made it into the forum shows that not everybody is on the same page regarding the answer. I still believe the standard FIX use will more easily digest a rejected modification followed by an unsolicited cancel.
What about my question from my previous post? I asked if the “new” order maintains a status “Partially Filled” with CumQty>0, does it have the same OrderID value or a new one? If the new order always comes with CumQty=0, i.e. total order qty and previous fills are not transferred to the new order, then we have a different issue related to a successful modification.
Regards,
Hanno.Hello Hanno,
I couldn’t find anything in the standard that forbids a CancelReject with OrdStatus=Canceled as reply for a CancelReplaceRequest.
Is there a diagram available that describes valid order state transitions?
I’m only aware of the order state change matrices in volume 4, but it’s stated that it does not describe all valid scenarios.For me the reject with state canceled make sense. Why else do we need OrdStatus in the reject if the state can not change with a reject?
Regards
Oliver