[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/8f68ad19 - PLEASE DO NOT REPLY BY MAIL.]
Further to Greg's comments I suggest that there are two broad options: 1. GTC issue guidance for this. 2. Systems vendors and others stop looking at the meta-data tags and derive order state from the tags that relate to order state. This will not work in all cases, but 31,32,38,152,151,14,6 will show a lot of state value for equity orders (add in other tags for f/x and other asset classes). In essence - move some of the logic for deriving order state from the sender of the execution report to the recipient of the execution report. In discussions with a number of firms on this issue it is clear that there are a number of approaches in use today. At least one EMS vendor takes the path of determining order state dynamically from the tags listed in option 2 above. Some brokers invoke different configuration for different buy-sides dependent on which OMS the buy-side uses. Many buy-sides and buy-side vendors take a path of least resistance and simply offload the problem to the broker and request that the broker resolves by sending a specific set of tags on the FIX message. The problem with this approach is simple - we move from a universal langauge of FIX to vendor specific implementations. While perhaps the path of least resistance it's also, in my view, the wrong way to go. As such I back the request from Greg for the GTC to issue guidance. Let's come together, determine the right way and standardise on that. > 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 - > > > > =281 35=D 49=BUYSIDE_COMPID 56=ORDERROUTINGHUB 34=297 52=20090427- > > > > 14:09: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 - > > > > 4=370 50=SELLSIDE_COMPID 57=BuySideDealerName 43=N 52=20090427- > > > > 14:09:05 369=297 37=065867546-LN24:090427:96283 > > > > 11=LZR1010570-YSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001560 20=0 > > > > 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 - > > > > 4=371 50=SELLSIDE_COMPID 57=BuySideDealerName 43=N 52=20090427- > > > > 14:09:08 369=297 37=065867546-LN24:090427:96283 > > > > 11=LZR1010570-YSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001570 20=0 > > > > 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 - > > > > 4=372 50=SELLSIDE_COMPID 57=BuySideDealerName 43=N 52=20090427- > > > > 14:09:29 369=297 37=065867546-LN24:090427:96283 > > > > 11=LZR1010570-YSIDE_COMPID 76=SELLSIDE_COMPID > > > > 17=96283.LN24:090427:49107 - > > > > 5.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 - > > > > 4=373 50=SELLSIDE_COMPID 57=BuySideDealerName 43=N 52=20090427- > > > > 14:09:35 369=297 37=065867546-LN24:090427:96283 > > > > 11=LZR1010570-YSIDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001580 20=1 > > > > 1- > > > > =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 -~----------~----~----~----~------~----~------~--~---
