FIX Reports

, ,
1

Imported from previous forum

2

Is there a proper FIX report (other than Status aka Summary) to handle this situation:

  1. order submitted to trade over time
  2. order receives normal partials throughout day
  3. part of remaining shares submited to a closing auction
  4. client cancels

At this point the client wants to receive back the shares the remaining shares that were not part of the closing auction but still keep the closing auction shares alive on the order. Is there a FIX report that is not a Status (aka Summary) to handle this?

Thanks!

3

By “1. order submitted to trade over time” I understand the order’s Time In Force is GTC ( Good till Cancel ). By “4. client cancels”, I understand the client sends a order Cancel request. You would be required to send a “Pending Cancel” message with the leaves, cumilative quantity and average price.

To take an example

  1. GTC Order for 1000 shares
  2. Two partial fills of 100 each ( exec qty = 200 ) is received during day which is transmitted to the order generating system.
  3. 500 shares is submitted to closing auction
  4. Order Cancel request is received
  5. Pending Cancel is sent with leaves = 800 and cum Qty = 200.

In 5. You cannot pass leaves = 300 ( = 1000 - 200 - 500 ) if that is what your question is.

Also explore the possibillity of using “Done for Day” message.

Is there a proper FIX report (other than Status aka Summary) to handle this situation:

  1. order submitted to trade over time
  2. order receives normal partials throughout day
  3. part of remaining shares submited to a closing auction
  4. client cancels

At this point the client wants to receive back the shares the remaining
shares that were not part of the closing auction but still keep the
closing auction shares alive on the order. Is there a FIX report that is
not a Status (aka Summary) to handle this?

Thanks!

4

By “1. order submitted to trade over time” I understand the order’s Time
In Force is GTC ( Good till Cancel ). By “4. client cancels”, I
understand the client sends a order Cancel request. You would be
required to send a “Pending Cancel” message with the leaves, cumilative
quantity and average price.

To take an example

  1. GTC Order for 1000 shares
  2. Two partial fills of 100 each ( exec qty = 200 ) is received during
    day which is transmitted to the order generating system.
  3. 500 shares is submitted to closing auction
  4. Order Cancel request is received
  5. Pending Cancel is sent with leaves = 800 and cum Qty = 200.

All this is fine, but that pending cancel doesn’t release any shares back to the client. In your example they want to get 100 shares returned to trade elsewhere so they would have CumQty=200, OrderSize=900, but what kind of ‘normal’ report can do that?

I’m beginning to realize that it’s not possible but wanted to at least put it out there, seems like this will come up again in the future as more auctions occur (in Europe there are auctions all the time).

Note: The Done for Day doesn’t work because the order is not Done (the 500 shares are in the auction). Also, note that the 500 shares could end up being partially filled, completely filled or not filled at all.

Thanks,
Cynde

[quote] At this point the client wants to receive back the shares the
remaining shares that were not part of the closing auction but still
keep the closing auction shares alive on the order. [/quote]

In 5. You cannot pass leaves = 300 ( = 1000 - 200 - 500 ) if that is
what your question is.

Also explore the possibillity of using “Done for Day” message.

Is there a proper FIX report (other than Status aka Summary) to handle
this situation:

  1. order submitted to trade over time
  2. order receives normal partials throughout day
  3. part of remaining shares submited to a closing auction
  4. client cancels

At this point the client wants to receive back the shares the
remaining shares that were not part of the closing auction but still
keep the closing auction shares alive on the order. Is there a FIX
report that is not a Status (aka Summary) to handle this?

Thanks!

5

[ original email was from Andrew Scott - ascott@latentzero.com ]
> > By “1. order submitted to trade over time” I understand the order’s

Time In Force is GTC ( Good till Cancel ). By “4. client cancels”, I
understand the client sends a order Cancel request. You would be
required to send a “Pending Cancel” message with the leaves,
cumilative quantity and average price.

To take an example

  1. GTC Order for 1000 shares
  2. Two partial fills of 100 each ( exec qty = 200 ) is received during
    day which is transmitted to the order generating system.
  3. 500 shares is submitted to closing auction
  4. Order Cancel request is received
  5. Pending Cancel is sent with leaves = 800 and cum Qty = 200.

All this is fine, but that pending cancel doesn’t release any shares
back to the client. In your example they want to get 100 shares returned
to trade elsewhere so they would have CumQty=200, OrderSize=900, but
what kind of ‘normal’ report can do that?

I’m beginning to realize that it’s not possible but wanted to at least
put it out there, seems like this will come up again in the future as
more auctions occur (in Europe there are auctions all the time).

Note: The Done for Day doesn’t work because the order is not Done (the
500 shares are in the auction). Also, note that the 500 shares
could end up being partially filled, completely filled or not
filled at all.

Thanks, Cynde

Cynde,

Would a client order cancel / replace request to reduce the order quantity not suffice here?

Going with the example, order stands at 1000 shares partially executed to 200 shares. 500 shares are to be submitted to closing auction at client request. So, instead of sending in a cancel request, the client sends in a cancel / replace request to change the order quantity to 700. This has the effect of maintaining the 200 executed and leaving 500 for the auction. The other 300 are ‘cancelled back’ to the client.

Alternatively you could consider the use of an unsolicited Execution Report Replaced in which the sell side makes the modification and sends back a 35 = 8 150 = D report with the revised quantities.

6

[ original email was from John Prewett - jprewett@lavatrading.com ]
Unfortunately, the customer may well not be able to submit a cancel/replace request as he/she is unaware of the amount submitted to the closing cross.

I have seen this type of occurrence when the customer sends the order to an algorithm that trades on his/her behalf.

The algorithm takes its own decisions on how/when to split the customer’s order. That decision making can also include participation in the closing cross.

Here is my example:

Customer submits an order for 100,000 shares of a listed stock at 09:30. The algorithm trades the order throughout the day. At 15:39, with 90,000 shares filled, the algorithm submits a 6,000 share market on close order to NYSE. The algorithm then continues to work the remaining 4,000 shares but nothing gets filled. At 15:45, the customer decides to cancel the order. The 4,000 shares could be “returned” to the customer while the 6,000 market on close order cannot be canceled due to market rules concerning this order type.

FIX currently provides no way to handle this situation (that I know of). A CancelReject would mean that the 4,000 shares continues to be worked, which isn’t in the best interests of the customer.

I would like to propose two possible alternatives as responses to the Cancel/Replace request under this circumstance to indicate a partial cancel:

Send back an ExecReport with OrderStatus=partially filled; ExecType=partial cancel; LeavesQty=6000.
This would require adding a new value to ExecType of ‘partial cancel’.

Send back a CancelReject with LeavesQty=6000. This would require adding LeavesQty as an optional field to the CancelReject message.

Personally, I prefer choice #1 above. I’m sure there are some other possible alternative proposals.

I would greatly appreciate it if the next version of the protocol addressed this issue.

I would like to thank Cynde for highlighting this issue which has been vexing me for some time.

John Prewett

7

[ original email was from Andrew Scott - ascott@latentzero.com ]
> Unfortunately, the customer may well not be able to submit a

cancel/replace request as he/she is unaware of the amount submitted to
the closing cross.

Thanks John for the clarification.

I have seen this type of occurrence when the customer sends the order to
an algorithm that trades on his/her behalf.

The algorithm takes its own decisions on how/when to split the
customer’s order. That decision making can also include participation in
the closing cross.

Here is my example:

Customer submits an order for 100,000 shares of a listed stock at 09:30.
The algorithm trades the order throughout the day. At 15:39, with 90,000
shares filled, the algorithm submits a 6,000 share market on close order
to NYSE. The algorithm then continues to work the remaining 4,000 shares
but nothing gets filled. At 15:45, the customer decides to cancel the
order. The 4,000 shares could be “returned” to the customer while the
6,000 market on close order cannot be canceled due to market rules
concerning this order type.

FIX currently provides no way to handle this situation (that I know of).
A CancelReject would mean that the 4,000 shares continues to be worked,
which isn’t in the best interests of the customer.

I would like to propose two possible alternatives as responses to
the Cancel/Replace request under this circumstance to indicate a
partial cancel:

1.Send back an ExecReport with OrderStatus=partially filled;
ExecType=partial cancel; LeavesQty=6000. This would require adding a
new value to ExecType of ‘partial cancel’.

2.Send back a CancelReject with LeavesQty=6000. This would require
adding LeavesQty as an optional field to the CancelReject message.

#3: Send back an unsolicited Execution Report Replaced 35 MsgType = 8, 150 ExecType = D [restated], with 38 OrdQty = 96000, 14 CumExecQty = 90000, 151 LeavesQty = 6000.

This will have the effect of ‘returning’ the ‘cancelled’ 4,000 shares to the client without client interaction. End result: 4000 does not remain on the market for execution, while 6000 goes to closing auction.

Please see email above for the original suggestion. This has the advantage of not requiring the use of additional fields or additional field values.

Personally, I prefer choice #1 above. I’m sure there are some other
possible alternative proposals.

I would greatly appreciate it if the next version of the protocol
addressed this issue.

I would like to thank Cynde for highlighting this issue which has been
vexing me for some time.

John Prewett