[This message was posted by Matt Simpson of CME Group <[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/ce0cb7db - PLEASE DO NOT REPLY BY MAIL.]
The GTC is happy to host a more formal discussion on this topic. If there is ambiguity in either the order state change matrices or the rules as stated in the spec then it should be clarified. This Thursday's monthly GTC meeting would be a good opportunity. Otherwise, we could find another time that suits all parties. Looking at both the 4.2 and 5.0 SP1 specs leads me to the conclusion that the intent is for ExecType to be set to a value indicating that the trade has been canceled (4 or H, depending on version) and that OrderStatus would be set to value determined by the order status priority matrix. In some cases this may simply be "New" if there is no preceding status that overrides this. Unfortunately there is not a bust example that clearly conveys this and we may want to consider providing such. > 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 - > > > > > =1 35=D 49=BUYSIDE_COMPID 56=ORDERROUTINGHUB 34=297 52=20090427- > > > > > 14:09:=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 -370 50=SELLSIDE_COMPID > > > > > 57=BuySideDealerName 43=N 52=20090427- > > > > > 14:09:05 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > > > IDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001560 20=0 1- > > > > > ==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 -371 50=SELLSIDE_COMPID > > > > > 57=BuySideDealerName 43=N 52=20090427- > > > > > 14:09:08 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > > > IDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001570 20=0 1- > > > > > ==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 -372 50=SELLSIDE_COMPID > > > > > 57=BuySideDealerName 43=N 52=20090427- > > > > > 14:09:29 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > > > IDE_COMPID 76=SELLSIDE_COMPID 17=96283.LN24:090427:49107 - > > > > > 5.=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 -373 50=SELLSIDE_COMPID > > > > > 57=BuySideDealerName 43=N 52=20090427- > > > > > 14:09:35 369=297 37=065867546-LN24:090427:96283 11=LZR1010570- > > > > > IDE_COMPID 76=SELLSIDE_COMPID 17=12408316147001580 20=1 1- > > > > > ==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 -~----------~----~----~----~------~----~------~--~---
