[This message was posted by Greg Wood of Credit Suisse <gregjw...@hotmail.com> 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/ff180147 - PLEASE DO NOT REPLY BY MAIL.]
It's amazing how much difference of opinion there has been on this post regarding a relatively straightforward operation such as busting a trade that has been previous reported. John and myself did actually discuss this offline and we both agree that that it makes more sense for OrdStatus to reflect the status *after* the effect of the trade cancel rather than the status *prior* to the trade cancel. That's what an OMS or EMS is typically going to key off so as to set the status of the order in the system. Leaving the OrdStatus as Fully Filled in this case implies that another fill is going to come - something that is not necessarily guaranteed. I think that so far in this post we have had the following combinations put forward for a complete bust of a fully filled order - 39=2/150=0/20=1 39=0/150=0/20=1 39=0/150=4/20=1 There's obviously a wide difference in opinion. My approach to this is to clearly detail our implementation for busts in our rules of engagement, and if a client or vendor requires something different then we will manipulate tags 39 and 150 accordingly based on the presence of tag 20=1. Not ideal, but it allows us to flexibly work around these differences in opinion. I guess that a lot of the ambiguity comes from the evolutionary nature of tag 150 from its first inclusion in 4.1 through to a slightly more rounded definition in 4.4 and later. I would also suggest that this difference of opinion has arisen due to the lack of a simple New Order->Acked->Fully Filled->Fully Busted scenario in Appendix D. Is this something that the GTC should consider revisiting, perhaps by offering best practice guidelines for busts on versions of FIX *prior* to 5.0 ? - Greg > 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 - 9=281 35=D 49=BUYSIDE_COMPID > > > 56=ORDERROUTINGHUB 34=297 52=20090427- > > > 14:09:5 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 - 34=370 50=SELLSIDE_COMPID > > > 57=BuySideDealerName 43=N 52=20090427- > > > 14:09:05 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001560 20=0 1- > > > =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 - 34=371 50=SELLSIDE_COMPID > > > 57=BuySideDealerName 43=N 52=20090427- > > > 14:09:08 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001570 20=0 1- > > > =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 - 34=372 50=SELLSIDE_COMPID > > > 57=BuySideDealerName 43=N 52=20090427- > > > 14:09:29 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=96283.LN24:090427:49107 - > > > 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 - 34=373 50=SELLSIDE_COMPID > > > 57=BuySideDealerName 43=N 52=20090427- > > > 14:09:35 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > BUYSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001580 20=1 1- > > > =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:unsubscribe+10093...@fixprotocol.org] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to FIX-Protocol@googlegroups.com To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
