Ack's for Cancel, Cancel/Replace messages

, ,
1

Imported from previous forum

2

[ original email was from jim whitehead - jwhitehead@latentzero.com ]
Good Morning

I have used this sites search facility to check to see whether this query has come up before, I didn’t find anything similar, but apologies if this is going over old ground for some of you.

My query concerns the validity of cancelling or cancel/replacing a new single order that hasn’t yet been acknowledged.

In practise, over the years I’ve seen several scenarios where this workflow may be required.

i) DMA, in general.
ii) DMA, in particular where a trader wants to utilise a ‘synthetic’ iceberg or FOK style strategy on an exchange which doesn’t support that functionality.
iii) As a ‘get out of jail’ card in the event of a network issue between
the buyside and sellside.In that as soon as the connection is re-established the cancel should kick in before any further action is taken.
iv) To cancel an order sent to the sellside where the broker has been deemed to have taken too long to ack the order. (This would be in a situation where the ack is generated by the sellside trader physically accepting an order on their front end rather than a situation where the ack is generated by the sellside FIX gateway.

There are probably other scenarios as well, but all of these seem valid to me.

However on looking through the FPL 4.2 spec, p13 states

‘The FIX protocol does not support individual message acknowledgment. However, a number of application messages require explicit application level acceptance or rejection. Orders, cancel requests, cancel/replace requests and allocation require specific application level response, executions can be rejected with the DK message but do not require
explicit acceptance.’

The Order State Change Matrices in section D, also seem to show an ack is required.

Is this a case of the spec being a guideline rather than the law?

Thanks in advance for your input
Jim

3

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
A good question.

Let’s look at two different workflow scenarios:

  1. Before a buy-side can send a cancel request it must receive an ACK
  2. A buy-side can send a cancel request at any time.

If an ack is really required then it would make sense for 35=F to have 37 as a required field. Tag 37 is not required for 35=F.

If a buy side can cancel at any time then it would make sense for tag 37 not be be required - since you would not know the broker assigned order id if the broker has not actually assigned an order id. Tag 37 is not required for 35=F.

On a broader - less geeky - note, the workflow involved in FIX cannot allow the sell-side to hold the buy-side “to ransom”. By that I mean, a buy-side dealer cannot be forced to wait for a sell-side to ack an order before the buy-side sends a cancel request on an order.

Think back to the days of the telephone - after a buy-side placed an order by phone it could try to cancel at any stage. Sure, it may be too late - the order may be filled, but the buy-side can get on the phone and ask to cancel at any time. FIX should and does allow for that flexibility.

Take another example - an order is sent by FIX from a buy-side to a sell-side. The buy side broker is off the desk. If the buy-side wants to deal right now it should not have to wait for the ack before sending a cancel request for the order - the buy side should be able to send a cancel and then re-send the order to another brokerage. In this case the buy-side will want to know that a cancel request has been sent via FIX so there’s an audit trail - in case the first, slow, sell-side tries to claim the order has already been executed before the ack was sent.

I do agree that the documentation in this area is lacking and I think again that your point is totally valid “spec being a guideline rather than the law”.

Good Morning

I have used this sites search facility to check to see whether this
query has come up before, I didn’t find anything similar, but apologies
if this is going over old ground for some of you.

My query concerns the validity of cancelling or cancel/replacing a new
single order that hasn’t yet been acknowledged.

In practise, over the years I’ve seen several scenarios where this
workflow may be required.

i) DMA, in general.
ii) DMA, in particular where a trader wants to utilise a ‘synthetic’
iceberg or FOK style strategy on an exchange which doesn’t support
that functionality.
iii) As a ‘get out of jail’ card in the event of a network issue between
the buyside and sellside.In that as soon as the connection is re-
established the cancel should kick in before any further action is
taken. iv) To cancel an order sent to the sellside where the broker
has been deemed to have taken too long to ack the order. (This
would be in a situation where the ack is generated by the sellside
trader physically accepting an order on their front end rather than
a situation where the ack is generated by the sellside FIX gateway.

There are probably other scenarios as well, but all of these seem
valid to me.

However on looking through the FPL 4.2 spec, p13 states

‘The FIX protocol does not support individual message acknowledgment.
However, a number of application messages require explicit application
level acceptance or rejection. Orders, cancel requests, cancel/replace
requests and allocation require specific application level response,
executions can be rejected with the DK message but do not require
explicit acceptance.’

The Order State Change Matrices in section D, also seem to show an ack
is required.

Is this a case of the spec being a guideline rather than the law?

Thanks in advance for your input Jim