[This message was posted by John Greenan of http://www.alignment-systems.com <[email protected]> to the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can reply to it on-line at http://fixprotocol.org/discuss/read/8170a49b - PLEASE DO NOT REPLY BY MAIL.]
Anand, Forgive me - but why should the order status be shown as "Filled" when the order status is "New"? Surely the order status tells us what the order should look like after the payload of the message has been processed? If you bust a full fill then the order is now zero filled and ready to trade, so in practical terms is just as if the order is "New". Let's look at the spec for guidance: I think that the nearest order state change matrix is D35 but it's not an exact fit for this scenario. The specific issue is around the interpretation of the statement: "In an execution report the OrdStatus is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in the OrdStatus field." - quote from "fix-42-with_errata_20010501.doc" page 92 I suggest that this order does not exist in more than one state - it's simply a new order now that the old full fill was busted. If you take the view that the order exists in two states - filled and new then since Filled (8) is a higher precendence than New (2) then indeed it should be shown as as Filled. But then I refer you to page 93 "The ExecType is used to identify the purpose of the execution report message. To transmit a change in OrdStatus for an order, the broker(sell side) should send an Execution Report with the new OrdStatus value in both the ExecType AND the OrdStatus fields to signify this message is changing the state of the order." Now, what else is a bust doing but changing the state of an order? And so in that case the message should surely be 39=0 / 150=0 What do you say? Anyone else care to comment? John > >Hi John, I have not read the whole thread here but i checked your > >case and i see that in Bust message it has 39=2( showing you have > >busted a fully filled order ) and 150=0 ( showing that its going to > >be new order). > Its the correct behaviour. Interesting.... > > > > There is at least one global Investment Bank that does not get 39/150 > > right when busting full fills. > > > > See below example. The full fill is bust but the bust has 39=2 > > (Filled) > > > > This is live and in production today. > > > > > > > > > > Outbound Message 2009-04-27 16:09:05,192 INFO > > out.ORDERROUTINGHUB_BUYSIDE_COMPID - >297.2 9=281 35=D 49=BUYSIDE_COMPID > > 56=ORDERROUTINGHUB 34=297 52=20090427- > > 14:09:05 97=N 128=SELLSIDE_COMPID 50=BuySideDealerName 11=LZR1010570- > > 1!FUT 21=3 100=XLIF 207=XLIF 54=1 60=20090427- > > 14:09:05 38=5 40=1 15=GBP 59=0 439=JPMCLR 440=89567 107=90 DAY > > STERLING FUTURE 0609 200=200906 55=L M9 22=5 48=L > > M9 167=FUT 1=BOOKING_ACCOUNT 10=237 ) > > > > pending new Inbound Message 2009-04-27 16:09:05,582 INFO > > in.ORDERROUTINGHUB_BUYSIDE_COMPID - <370ID 34=370 50=SELLSIDE_COMPID > > 57=BuySideDealerName 43=N 52=20090427- > > 14:09:05 369=297 37=065867546-LN24:090427:96283 > > 11=LZR1010570-9=BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001560 20=0 > > 1- > > 50=A 39=A 1=BOOKING_ACCOUNT 55=L40=1 15=GBP 59=0 32=0.0 31=0.0 > > 151=5.0 14=0.0 6=0.0 60=20090427- > > 14:09:05.000 10=191 ) > > > > new Inbound Message 2009-04-27 16:09:09,317 INFO > > in.ORDERROUTINGHUB_BUYSIDE_COMPID - <371ID 34=371 50=SELLSIDE_COMPID > > 57=BuySideDealerName 43=N 52=20090427- > > 14:09:08 369=297 37=065867546-LN24:090427:96283 > > 11=LZR1010570-9=BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001570 20=0 > > 1- > > 50=0 39=0 1=BOOKING_ACCOUNT 55=L40=1 15=GBP 59=0 32=0.0 31=0.0 > > 151=5.0 14=0.0 6=0.0 60=20090427- > > 14:09:09.000 10=166 ) > > > > fill Inbound Message 2009-04-27 16:09:30,145 INFO > > in.ORDERROUTINGHUB_BUYSIDE_COMPID - <372ID 34=372 50=SELLSIDE_COMPID > > 57=BuySideDealerName 43=N 52=20090427- > > 14:09:29 369=297 37=065867546-LN24:090427:96283 > > 11=LZR1010570-9=BUYSIDE_COMPID 76=SELLSIDE_COMPID > > 17=96283.LN24:090427:49107 - > > 20=0 150=2 39=2 1=BOOKING_ACCOUNT 55=L2=5.0 31=2365.0 151=0.0 14=5.0 > > 6=2365.0 75=20090427 60=20090427- > > 14:09:29.000 10=196 ) > > > > fill - busted Inbound Message 2009-04-27 16:09:36,145 INFO > > in.ORDERROUTINGHUB_BUYSIDE_COMPID - <373ID 34=373 50=SELLSIDE_COMPID > > 57=BuySideDealerName 43=N 52=20090427- > > 14:09:35 369=297 37=065867546-LN24:090427:96283 > > 11=LZR1010570-9=BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001580 20=1 > > 1- > > 9=96283.LN24:090427:49107 150=0 39=2 1=BOOKING_ACCOUNT 55=L59=0 > > 32=0.0 31=0.0 151=5.0 14=0.0 6=0.0 75=20090427 60=20090427- > > 14:09:35.000 10=120 ) > > > > > Hi Elton, > > > > > > Tag 150 should reflect the status of the order once the bust has > > > been taken into account. So if the bust is the only trade of a fully > > > filled order then the message would be 150=0/20=1. A bust on the > > > last fill of an order filled in several clips should go back as > > > 150=1/20=1. > > > > > > Tag 39 could be different. A busted fill on a partially filled and > > > cancelled order should generate 39=4/150=1/20=1 as per line 7 of > > > example D35 in Appendix D. > > > > > > The comment below made in an earlier post is interesting, especially > > > since I heard something similar recently - > > > > > > "One of our FIX partners told me that ExecType would be *always* > > > 150=4 when the Execution Report is busting an execution -- but I'm > > > not sure about that." > > > > > > - I personally do not understand the logic of this. 150=4 > > > (Cancelled) refers to the order not the fill, and does not follow > > > the logic behind tag 20 in 4.2 to denote the transction type being > > > reported (new, cancel, correct or status). 4.3 and later deprecate > > > tag 20 and put the values into tag 150, but a cancelled order and > > > a trade cancel are still distinct values (150=4 and 150=H > > > respectively). > > > > > > A question for a wider audience - is there a common deviation from > > > the spec with regards to reporting busts as 150=4 ? > > > > > > Regards, > > > > > > - Greg > > > > > > > > > > > > > Hello, > > > > > > > > Thanks, but my question is: when an ExecutionReport is busting an > > > > execution (20=1), what value should I use in tag 150? Does it have > > > > the same value of tag 39? [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
