Imported from previous forum
Hi all,
I’m interested in people’s thoughts on the interpretation of the OrdStatus (39) field of an OrderCancelReject (35=9) message. The 4.2 spec simply says this is the “OrdStatus value after this cancel reject is applied”, which I’ve always taken to mean the status of the complete order chain after the cancel reject has been applied. This interpretation has served us well, until we recently had to integrate with a server (a home-grown one, I believe) that always sets 39=8 (Rejected) on any OrderCancelReject, yet still sends subsequent execution reports for the order. This seems bogus to me - it’s the cancel request that is being rejected, not the order - but the server vendor insists their behaviour is valid. They may be correct within the letter of the spec but my feeling is that this violates the spirit of the protocol at least; although we will probably implement a workaround for this case regardless, I’d still like to be able to claim some moral high ground and produce some evidence that their implementation is incorrect.
So what do other people think - how should 39=8 in an OrderCancelReject be handled?
Below is a sample message sequence demonstrating what I’m talking about - the client attempts to cancel an order that’s already in the Pending Cancel state and gets an OrderCancelReject with 39=8 (please excuse any dodgy line wrapping):
8=FIX.4.2 9=178 35=D 34=228 49=FIXAPAMA 52=20080125-14:44:38 56=XXXX 1=TD580IT 7 08470615C6 CDS 5J9535E 11=1:168:72278 21=1 38=500 40=2 44=99 47=J 54=1 55=RIM 60=20080125-08:44:38 100=110 114=N 10=170
8=FIX.4.2 9=236 35=8 34=469 49=XXXX 52=20080125-14:44:38 56=FIXAPAMA 6=0 11=1:168:72278 14=0 17=FIXAPAMA-70080125-95-0 20=0 30=110 31=0 32=0 37=FIXAPAMA-70080125-95 38=500 39=A 44=99 47=J 54=1 55=RIM 59=0 60=20080125-14:44:38 99=0 150=A 151=500 167=CS 10=158
8=FIX.4.2 9=236 35=8 34=470 49=XXXX 52=20080125-14:44:38 56=FIXAPAMA 6=0 11=1:168:72278 14=0 17=FIXAPAMA-70080125-95-1 20=0 30=110 31=0 32=0 37=FIXAPAMA-70080125-95 38=500 39=0 44=99 47=J 54=1 55=RIM 59=0 60=20080125-14:44:38 99=0 150=0 151=500 167=CS 10=117
8=FIX.4.2 9=147 35=F 34=230 49=FIXAPAMA 52=20080125-14:44:39 56=XXXX 11=1:170:12012 37=FIXAPAMA-70080125-95 38=500 41=1:168:72278 54=1 55=RIM 60=20080125-08:44:39 10=015
8=FIX.4.2 9=242 35=8 34=472 49=XXXX 52=20080125-14:44:39 56=FIXAPAMA 6=99 11=1:168:72278 14=200 17=FIXAPAMA-70080125-95-2 20=0 30=110 31=99 32=200 37=FIXAPAMA-70080125-95 38=500 39=1 44=99 47=J 54=1 55=RIM 59=0 60=20080125-14:44:38 99=0 150=1 151=300 167=CS 10=190
8=FIX.4.2 9=254 35=8 34=473 49=XXXX 52=20080125-14:44:39 56=FIXAPAMA 6=99 11=1:170:12012 14=200 17=FIXAPAMA-70080125-95-3 20=0 30=110 31=0 32=0 37=FIXAPAMA-70080125-95 38=500 39=1 41=1:168:72278 44=99 47=J 54=1 55=RIM 59=0 60=20080125-14:44:39 99=0 150=6 151=300 167=CS 10=251
8=FIX.4.2 9=147 35=F 34=232 49=FIXAPAMA 52=20080125-14:44:39 56=XXXX 11=1:172:72279 37=FIXAPAMA-70080125-95 38=500 41=1:170:12012 54=1 55=RIM 60=20080125-08:44:39 10=013
8=FIX.4.2 9=143 35=9 34=474 49=XXXX 52=20080125-14:44:39 56=FIXAPAMA 11=1:172:72279 37=NONE 39=8 41=1:170:12012 58=Order Not Found (Too late to cancel?) 434=1 10=006
8=FIX.4.2 9=239 35=8 34=478 49=XXXX 52=20080125-14:44:39 56=FIXAPAMA 6=99 11=1:168:72278 14=200 17=FIXAPAMA-70080125-95-4 20=0 30=110 31=0 32=0 37=FIXAPAMA-70080125-95 38=500 39=4 44=99 47=J 54=1 55=RIM 59=0 60=20080125-14:44:39 99=0 150=4 151=300 167=CS 10=047
Cheers,
Scott
–
Dr Scott Mitchell, Apama Connectivity Engineering Manager, Cambridge UK
This looks like a bug in the server side software. 39 OrdStatus = 8 will set the order status to rejected, which is not the intent. Instead, 39 OrdStatus should be communicating the current state of the order, in this case 39 = 6 [Pending Cancelled].
This looks like a bug in the server side software. 39 OrdStatus = 8 will
set the order status to rejected, which is not the intent. Instead, 39
OrdStatus should be communicating the current state of the order, in
this case 39 = 6 [Pending Cancelled].
Thanks Andrew, that’s exactly our view, but it’s good to have it confirmed by someone else!
Cheers,
Scott
Scott,
You are correct in stating that it is a bug on the server side and not as per fix. But let me explain you that there is a reason behind it doing so. The sell side server is loking at tag 41 in your 2nd Cxl req and is not able to find that order in its system as it is yet to accept or reject the 1st Cxl req. Hence its straightaway rejecting your 2nd Cxl req but with an incorrect value in tag 39. I just tried to draw your attention of the possible reason for sell side server behaving in this way. But in the end, yes you are correct in stating that their system response is wrong as per fix.
Regards,
Sunil Singh