Imported from previous forum
Hi,
I have a few questions regarding the correct behavior for a FIX 4.2 Server in the following situation :
- FIX Client sends in a new order. (11=abc1)
- FIX Server acknowledges order add.
- FIX Client sends in an order cancel/replace req (11=abc2, 41=abc1).
- FIX Server sends a pending replace ack for the previous change (11=abc2, 41=abc1)
- FIX Client sends in an order cancel/replace req (11=abc3, 41=abc2).
Q1 : What should the FIX Server do on receiving this second change request (11=abc3, 41=abc2) ?
From my understanding, the first change request has not been fully processed and it could be argued that Client Order ID “abc2” is unknown to the FIX Server and hence cannot be replaced. This would compel the FIX Server to reject the second change request stating “unknown client order id” as the reason. Am I right?
Q2 : In the event that the FIX Server does not reject the second change request and the sequence of FIX messages proceeds as :
(continued from step 5 above)
6. FIX Server sends a pending replace ack for the previous change (11=abc3, 41=abc2)
Now, if the first change request (11=abc2, 41=abc1) has been rejected by the underlying OMS, the fix server would have to send back a change reject for (11=abc2, 41=abc1). But, what would be the FIX-appropriate behavior when dealing with the second change request (11=abc3, 41=abc2)?
As I understand it, the first change request has been rejected, thereby invalidating the Client Order ID “abc2”. If this Client Order ID is invalid, there is no way to replace an order identified by it. Am I right?
Kind Regards,
Prateek Jain
Hi Prateek,
The amend requests should be 11=v2,41=v1 and 11=v3,41=v1
The second amend request should always reference the original client order id. Client order id v1 remains valid until amend request v2 has been validated by the server. If the client is handing you 11=v3,41=v2 when the first amend request is still pending, then that is an error.
Given the above has been straightened out, then the second amend request should be held in a queue [somewhere visible to support] until the first amend request has been decided on. The second amend request can appear as ‘failed’ and can even be auto rejected back to the client [with 11=v3,41=v1 in the 35=9 message], depending on client preferences, or resubmitted when the first amend request has been processed.
Hope that helps!
Hi Andrew,
Unfortunately, the situation really is the following :
new order : 11=abc1
<- order accepted ack
->1st change request : 11=abc2, 41=abc1
<- pending replace ack
->2nd change request : 11=abc3, 41=abc2
The customer obviously insists that 2nd change request is valid in FIX.
If this is invalid in FIX, where can I find this in the specifications?
Thanks and Regards,
Prateek Jain
Let’s take this off-line if you would like to discuss further.
I would normally recommend D16 and D17 in FPL v 4.2 spec, but this cannot be right either as v2 is not valid until the first amend request is accepted 
The second amend request should always reference the current valid client order id in 41 OrigClOrdID.
Obviously up to you regarding how you would like to deal with the client, but perhaps it is wise to remember the maxim ‘be flexible in what you receive, and strict in what you send’ …
The client should take an optimistic approach and conduct chaining accordingly, i.e. reference abc2 in his 2nd request even though he cannot be sure whether the first request will be accepted or not. He does the same when the first request is the NewOrderSingle and the 2nd request is to change the order prior to having received an ER for the order entry. In this case abc1 is the only available reference to the order he wants to change. Just imagine the client were to continue to use abc1 for the 2nd request but that this message crosses the ER from the server inflight, confirming abc2 as a valid ClOrdID. The server would reject abc1 on the basis that he already has moved on to abc2 as the current identifier for the order.
The server must behave differently in the sense that he has to put the last valid ClOrdID into the field OrigClOrdID of the ER which will not be identical to an echo of the OrigClOrdID value received by the client in the scenario discussed here where pending requests are involved.
The scenarios under D in Volume 4 of the spec should provide some examples of what I described above. Admittedly, chaining gets nasty in a high-frequency trading environment if the FIX Engine has to keep state of the order and has to keep track of the entire chain of pending request. FIX engine failures requiring recovery processes will be complex. My personal view in such cases is that a rejection of subsequent requests (“previous change request still pending”) is also a valid approach but that must be agreed between the parties.
Regards,
Hanno.
Hi Andrew,
Unfortunately, the situation really is the following :
new order : 11=abc1
← order accepted ack
->1st change request : 11=abc2, 41=abc1
← pending replace ack
->2nd change request : 11=abc3, 41=abc2The customer obviously insists that 2nd change request is valid in FIX.
If this is invalid in FIX, where can I find this in the specifications?Thanks and Regards,
Prateek Jain
Dear Hanno,
I agree with you completely, and would like to thank you for putting me straight on this matter.
Respectfully yours,
Andrew