Imported from previous forum
[ original email was from Binaya Patel - binayakumar.patel@wipro.com ]
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,
- What will be the values of 11 and 41 in 35=9 message? Since both are mandatory tags in 35=9 message.
- And what will be the value of 434(CxlRejResponseTo) in 35=9 message??
Thanks in advance
Binayakumar patel
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,
- What will be the values of 11 and 41 in 35=9 message? Since both are
mandatory tags in 35=9 message.- And what will be the value of 434(CxlRejResponseTo) in 35=9 message??
Thanks in advance Binayakumar patel
[ original email was from Bivas Mishra - bivas.mishra@wipro.com ]
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,
- What will be the values of 11 and 41 in 35=9 message? Since both
are mandatory tags in 35=9 message.- And what will be the value of 434(CxlRejResponseTo) in 35=9
message??Thanks in advance Binayakumar patel
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,
- What will be the values of 11 and 41 in 35=9 message? Since both
are mandatory tags in 35=9 message.- And what will be the value of 434(CxlRejResponseTo) in 35=9
message??Thanks in advance Binayakumar patel
[ original email was from Bivas Mishra - bivas.mishra@wipro.com ]
Thanks.
I do agree that FIX should not mandate one approach or the other.
As mentioned in your post below, OrderCancelRejects might be used to convey more details other than just the Ack. However, one issue here is that Tag 434 (CxlRejResponseTo), which is a mandatory tag in the OrderCancelReject message, has valid enums as {1 = Order cancel request & 2 = Order cancel/replace request}.
Of these two values the nearest value that can be used (for lack of other options) would be Tag 434 = 1 to represent OrderMassCancelRequest as the respondee, even though it may not be entirely accurate.
Alternatively, it’s best to use the NoAffectedOrders group and completely avoid this ambiguity in the OrderCancelReject messages.
Regards,
Bivas
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,
- What will be the values of 11 and 41 in 35=9 message? Since
both are mandatory tags in 35=9 message.- And what will be the value of 434(CxlRejResponseTo) in 35=9
message??Thanks in advance Binayakumar patel
I agree that CxlRejResponseTo might not be 100% accurate semantically but the response can be uniquely associated with the request nonetheless. The response message OrderCancelReject carries the ID of the deletion request message in tag 11 ClOrdID. The same field is used in both the OrderCancelRequest and the OrderMassCancelRequest. The submitter of the request can thus identify whether the single or mass request triggered the reject. This is due to the fact that ClOrdID serves both as an entity and a message identifier. I would prefer to separate the two concepts but they are quite fundamental.
Thanks. I do agree that FIX should not mandate one approach or
the other.As mentioned in your post below, OrderCancelRejects might be used to
convey more details other than just the Ack. However, one issue here is
that Tag 434 (CxlRejResponseTo), which is a mandatory tag in the
OrderCancelReject message, has valid enums as {1 = Order cancel request
& 2 = Order cancel/replace request}.Of these two values the nearest value that can be used (for lack of
other options) would be Tag 434 = 1 to represent OrderMassCancelRequest
as the respondee, even though it may not be entirely accurate.Alternatively, it’s best to use the NoAffectedOrders group and
completely avoid this ambiguity in the OrderCancelReject messages.Regards, Bivas