Why <OrderQtyData> block is required for OrderCancelRequest [type 'F']?

, ,
1

Imported from previous forum

2

Hi,

It seems strange that since FIX 4.3 until the latest FIX 5.0 the block is marked as ‘required’ for OrderCancelRequest [type ‘F’]. Assuming the fact that the most of obsolete requirements have been dropped off in FIX 5.0, it looks very suspicious that the requirement in question is still there, as if there is a crystally clear idea behind it.

Also, since all 's tags are optional, and according to the similar situation for 35=D with the mandatory block but all block’s tags optional, where it ended up with being ‘conditionally required’, looks like at least one of 's tags is conditionally required then.

Is it correct? What is the semantics behind it? Doesn’t it mean “partial cancellation”???

Regards,
Igor

3

No ideas?..

It seems strange that since FIX 4.3 until the latest FIX 5.0 the
block is marked as ‘required’ for OrderCancelRequest
[type ‘F’].

4

Main reason is for order identification similar to Instrument and Side being required. One could use it to confirm the quantity one believes to be still open, i.e. reject the cancel if it does not match due to the order being (partially) filled in between the last Execution Report being processed and the Cancel Request. The reject would serve as a notification.

The only thing it must not be used for is to cancel part of the quantity. The request always has to apply to the entire order. The field might be redundant but I also do not see a problem sending it, or?

No ideas?..

It seems strange that since FIX 4.3 until the latest FIX 5.0 the
block is marked as ‘required’ for OrderCancelRequest
[type ‘F’].

5

Thanks for the answer!

I agree that it must not be used to cancel part of the quantity, because in that case it would mean modification (also we know the rule “use modify message for modifications only!”). My question about it was provocative, of course.

At first sight, making as a part of order identification sounds like “specifying values in addition to real identifiers”, one might also ask – why then we don’t specify which is also mandatory for 35=D? – it seeminly has similar “rights” in respect to order identification.

The only venue we met that required worked fine if “0” was specified for .

I tend to think that this was designed as an optional possibility for venues to prevent races from client side:

  • Since only ‘total’ quantities are used in , no partial fills should cause rejects for such cancels
  • ‘Total’ quantity is changed by the originating side usually (few other cases can be skipped for this “feature”?)
  • So, the only case when we (as a client) don’t know the ‘total’ quantity can be due to races at our side

Hence, if we want to ask venue to check the races from our side, we can “ask” it to check quantities, by specifying quantity in cancel message. And, as you pointed out, “the reject would serve as a notification”. If we don’t want this check to work, we can either not specify quantity at all (if venue’s FIX engine supports that), or specify “0” there (not documented though).

Sounds farfetched?

Main reason is for order identification similar to Instrument and Side
being required. One could use it to confirm the quantity one believes to
be still open, i.e. reject the cancel if it does not match due to the
order being (partially) filled in between the last Execution Report
being processed and the Cancel Request. The reject would serve as a
notification.

The only thing it must not be used for is to cancel part of the
quantity. The request always has to apply to the entire order. The field
might be redundant but I also do not see a problem sending it, or?

No ideas?..

It seems strange that since FIX 4.3 until the latest FIX 5.0 the
block is marked as ‘required’ for OrderCancelRequest
[type ‘F’].

6

Hi,
to me, it makes no sense, too. If the counterparts want to include the quantity for identification purposes, this component should be marked as optional. In my opinion comparing the clOrdID, instrument and side should be sufficient.

We’ve implemented a dummy with 38=0. Works with all of our borkers.

Hi,

It seems strange that since FIX 4.3 until the latest FIX 5.0 the block is marked as ‘required’ for OrderCancelRequest [type ‘F’]. Assuming the fact that the most of obsolete requirements have been dropped off in FIX 5.0, it looks very suspicious that the requirement in question is still there, as if there is a crystally clear idea behind it.

Also, since all 's tags are optional, and according to the similar situation for 35=D with the mandatory block but all block’s tags optional, where it ended up with being ‘conditionally required’, looks like at least one of 's tags is conditionally required then.

Is it correct? What is the semantics behind it? Doesn’t it mean “partial cancellation”???

Regards,
Igor

7

[ original email was from John Harris - john.harris@bondmart.com ]
Agreed, it should be optional, not required. Neither should instrument or side be required.

Hi,
to me, it makes no sense, too. If the counterparts want to include the quantity for identification purposes, this component should be marked as optional. In my opinion comparing the clOrdID, instrument and side should be sufficient.

We’ve implemented a dummy with 38=0. Works with all of our borkers.

Hi,

It seems strange that since FIX 4.3 until the latest FIX 5.0 the block is marked as ‘required’ for OrderCancelRequest [type ‘F’]. Assuming the fact that the most of obsolete requirements have been dropped off in FIX 5.0, it looks very suspicious that the requirement in question is still there, as if there is a crystally clear idea behind it.

Also, since all 's tags are optional, and according to the similar situation for 35=D with the mandatory block but all block’s tags optional, where it ended up with being ‘conditionally required’, looks like at least one of 's tags is conditionally required then.

Is it correct? What is the semantics behind it? Doesn’t it mean “partial cancellation”???

Regards,
Igor

8

Actually we have also managed to fix most such requirements with a dummy 38=0.

However, for “NYFIX dark pool” we had to populate the proper total volume there. No other such samples, though.

to me, it makes no sense, too. If the counterparts want to include the quantity for identification purposes, this component should be marked as optional. In my opinion comparing the clOrdID, instrument and side should be sufficient.

We’ve implemented a dummy with 38=0. Works with all of our borkers.