[This message was posted by Hanno Klein of Deutsche Börse Systems <[email protected]> to the "4.4 Changes" discussion forum at http://fixprotocol.org/discuss/17. You can reply to it on-line at http://fixprotocol.org/discuss/read/7bcd326d - PLEASE DO NOT REPLY BY MAIL.]
You are correct, the report is the immediate response. As you need to at least convey which orders have actually been cancelled, you have to either used the repeating group embedded in the report or individual ExecutionReports for each order. If you need to convey outside of the report (NotAffectedOrdersGrp) that an order could not be cancelled, the OrderCancelReject is the only available message. It can then be seen as a response to an OrderCancelRequest, i.e. OrderMassCancelRequest is simply a shortcut for one cancel request per order. The scope of orders that are affected by a mass cancel request is debatable and my view is that only active orders qualify if performance is relevant. In many exchange environments, non-active orders cannot be inquired any more. The group of (un)affected orders is optional as FIX does not want to force you to use it. As you point out, a series of ExecutionReports and OrderCancelRejects can also be used. If you need more than a simple ACK per order (e.g. remaining qty at the time of deletion), that might be the better way but it means more time and more processing. I do not think FIX should mandate one or the other. The Rules of Engagement should always have a chapter on message flows to explain what goes back and forth for every type of business process. A simple list of message layouts is not enough to understand the details needed to implement against a FIX interface. The standard spec cannot describe all possible flows which sometimes leads to ambiguities. Posting questions like you did is a recommended approach for such cases. Regards, Hanno. > Hi Hanno, > > Though the 'OrderMassCancelReport' seems to be the most logical response > to a 'OrderMassCancelRequest', the specs (Ref. FIX5.0SP2-Vol-4, Pg-117) > mentions that: "The Order Mass Cancel Report is used to acknowledge an > Order Mass Cancel Request. Note that each affected order that is > canceled is acknowledged with a separate Execution Report or Order > Cancel Reject message." > > Also Ref. FIX5.0SP2-Vol-4, Pg-113 which states that: > > "An immediate response to this message is required. It is recommended > that an ExecutionRpt with ExecType=Pending Cancel be sent unless the > Order Mass Cancel Request can be immediately accepted (ExecutionRpt with > ExecType=Canceled) or rejected (Order Cancel Reject message)." > > This is a bit confusing. > > Since the 'NoAffectedGroups' and 'NoNotAfectedGroup' components are > optional goups in the Mass Order Handling Messages, can it be safely > assumed that the immediate response to the 'OrderMassCancelRequest' > should be an 'OrderMassCancelReport' followed by Execution Reports or > Order Cancel Rejects for all the individual orders? > > Although, this approach for implementation does make it a very lengthy > and time taking process for cancellation notification. > > More clarity on the same would definitely be helpful :-) > > Regards, Bivas > > > The response to a mass cancel request is a mass cancel report. The > > OrderCancelReject can only reject modification or deletion requests > > for individual orders. The mass cancel response has a repeating group > > AffectedOrdGrp where you can send those that were deleted. By > > definition, all others were not deleted (for whatever reason). > > > > If you look beyond FIX 4.4 you can see how the functionality has been > > further developed by adding a repeating group of orders that were not > > affected. Here you could convey those that have been filled and can > > thus not be deleted. The original idea for this was to convey things > > like locked orders that only temporarily prevent deletion. > > > > In general I would say that none of the orders that have reached end > > of life should be included in the lookup of orders that meet the > > matching criteria of the mass cancel request. Otherwise, you also have > > to convey orders that have expired or have been cancelled by the user. > > An Algo trader issuing a mass cancel is not interested about the many > > orders he has previously entered and cancelled. > > > > The mass cancel should only apply to active orders that can still be > > matched against other orders. > > > > Regards, Hanno. > > > > > > > Hi All, > > > > > > We are in the process of implementing OrderMassCancel Request; Need > > > your help on how to handle a particular instance on server side > > > (simulator). Below is the scenario, > > > > > > Client sends OrderMassCancel Request to server (Simulator) and > > > specifies Matching criteria would be Tag 530=4 (CxlOrdersCFICode) > > > and 461(CFIcode)=ESXXXX. So all the orders which is having 461= > > > ESXXXX on the server side should be cancelled. > > > > > > There are some of the orders which is having 461=ESXXXX are fully > > > filled and Serve sends cancelreject message to client for fully > > > filled order. My question is, > > > 1. What will be the values of 11 and 41 in 35=9 message? Since both > > > are mandatory tags in 35=9 message. > > > 2. And what will be the value of 434(CxlRejResponseTo) in 35=9 > > > message?? > > > > > > Thanks in advance Binayakumar patel [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.
