Unsolicited Cancel vs Reject Execution Report

, ,
1

Imported from previous forum

2

Hi,

I am building a FIX application where new order and subsequent order amendment(s) will be auto-accepted first before market opens. And when the market opens, the system will route only the new order (with order attributes following the amendment(s)) to the exchange.

By auto-accept, we will return NEW execution report (150=0) to the buy-side. For any amendment to the order before we route the order out to the exchange, we will also auto-accept and return REPLACE execution report (150=5). After the order has been accepted into the exchange, the system won’t further acknowledge the buy-side

I am stucked by the case where the order is rejected by the exchange.
Since the order has been auto-accepted (execution report of 150=0 and 150=5 are sent before to the buy-side), if the order is actually rejected by the exchange, how should I update the buy-side?

Is unsolicited cancel execution report (150=4) a good idea to reject in this case? or should we still send reject execution report (150=8), even the order has been replaced before?

I understand that reject execution report can still be replied after new execution report is provided earlier. However, I also note that by the order Status change matrix specified in FIX 4.2, ordStatus transition from REPLACE(5) to REJECTED(8) is not a valid transition.

In advance, Thanks very much for your expert opinion !

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
This model is somewhat dangerous when it comes to covering all the state transitions, but I don’t see why it couldn’t be made to work with some leniency from the entities that send you orders.

Having already issued ExecReport(ExecType=Replaced), it would not be appropriate to subsequently issue an ExecReport(ExecType=Rejected) as you stated. I believe that an unsolicited cancel of the order would be the only option under these circumstances.

Please beware that some buy-side software gets upset when it receives an unsolicited cancel as this is generally an abnormal situation.

What I’m wondering about is why you acknowledge the orders.
Have you considered using ExecReport(ExecType=Pending New) as a response for the original order and ExecReport(ExecType=Pending Replace) as a response for the replacement order?
If you did this, you could then forward the orders and replace requests when the execution venue subsequently becomes available and relay the responses back to your buy side customers. In this respect, you would be acting as a FIX store-and-forward device.

Lastly, you haven’t mentioned how you handle what happens when:

  1. The orders are still flowing and the market now becomes available. Do you still pre-acknowledge orders?
  2. The buy-side sends two (or twenty-two) replace requests prior to market open.
  3. Handling of cancel requests.

I hope this helps.

JohnP

4

Thanks John!

Client demands that the should be able to amend a number of times of the order. So, the only way is to auto-accept the order and further amendment.
Once the market opens, we will not do auto-accept. Any new order or amendment will flow directly to the exchange and NEW/AMEND execution report will only be replied upon the exhange acknowledged.
For cancel request, we will also auto-accepted because we won’t send the order after market opens.

This model is somewhat dangerous when it comes to covering all the state
transitions, but I don’t see why it couldn’t be made to work with some
leniency from the entities that send you orders.

Having already issued ExecReport(ExecType=Replaced), it would not be
appropriate to subsequently issue an ExecReport(ExecType=Rejected) as
you stated. I believe that an unsolicited cancel of the order would be
the only option under these circumstances.

Please beware that some buy-side software gets upset when it receives an
unsolicited cancel as this is generally an abnormal situation.

What I’m wondering about is why you acknowledge the orders. Have you
considered using ExecReport(ExecType=Pending New) as a response for the
original order and ExecReport(ExecType=Pending Replace) as a response
for the replacement order? If you did this, you could then forward the
orders and replace requests when the execution venue subsequently
becomes available and relay the responses back to your buy side
customers. In this respect, you would be acting as a FIX store-and-
forward device.

Lastly, you haven’t mentioned how you handle what happens when:

  1. The orders are still flowing and the market now becomes available. Do
    you still pre-acknowledge orders? 2. The buy-side sends two (or twenty-
    two) replace requests prior to market open.
  2. Handling of cancel requests.

I hope this helps.

JohnP

5

[ original email was from John Prewett - jprewett@lavatrading.com ]
Now that I have more of the picture, maybe you want to consider this:

  1. When the customer sends in a NewOrderSingle, respond with an ExecReport(PendingNew).
  2. When the customer sends in a CancelReplaceRequest against an original order, issue an ExecReport(new) on the original order and an ExecReport(pendingReplace) on the replacement version.
  3. When the customer sends in a CancelReplaceRequest against a previous replacement order, issue an ExecReport(replaced) for the previous replacement order and an ExecReport(pendingReplace) for the new replacement version.
  4. When the customer sends in a CancelRequest against an original order, issue an ExecReport(new) against the original order and an ExecReport(canceled) for the CancelRequest.
  5. When the customer sends in a CancelRequest against a replacement order, issue an ExecReport(replaced) against the replacement order and then an ExecReport(Canceled) for the CancelRequest.

In the above manner, you have never actually confirmed the latest version of an order, so you can ultimately send a NewOrderSingle to the market when it becomes available with the most recent version of an order and take the following actions, depending on the market’s response:
A. If the market accepts the order and the order was the original version, issue an ExecReport(new).
B. If the market rejects the order and the order was the original version, issue an ExecReport(rejected).
C. If the market accepts the order and the order was actually a replacement version, issue an ExecReport(replaced).
D. If the market rejects the order and the order was a replacement version, this is the only tricky scenario. You must issue an unsolicited cancel on the previous version of the order, followed by a CancelReject for the replacement version.

I believe this removes any liability as a result of your system actually accepting an order. You only accept an order when the next version is submitted.

I hope this helps.

JohnP

6

Thanks for your detailed and great opinion!

Now that I have more of the picture, maybe you want to consider this:

  1. When the customer sends in a NewOrderSingle, respond with an
    ExecReport(PendingNew).
  2. When the customer sends in a CancelReplaceRequest against an
    original order, issue an ExecReport(new) on the original order and
    an ExecReport(pendingReplace) on the replacement version.
  3. When the customer sends in a CancelReplaceRequest against a previous
    replacement order, issue an ExecReport(replaced) for the previous
    replacement order and an ExecReport(pendingReplace) for the new
    replacement version.
  4. When the customer sends in a CancelRequest against an original
    order, issue an ExecReport(new) against the original order and an
    ExecReport(canceled) for the CancelRequest.
  5. When the customer sends in a CancelRequest against a replacement
    order, issue an ExecReport(replaced) against the replacement order
    and then an ExecReport(Canceled) for the CancelRequest.

In the above manner, you have never actually confirmed the latest
version of an order, so you can ultimately send a NewOrderSingle to
the market when it becomes available with the most recent version
of an order and take the following actions, depending on the
market’s response:
A. If the market accepts the order and the order was the original
version, issue an ExecReport(new).
B. If the market rejects the order and the order was the original
version, issue an ExecReport(rejected).
C. If the market accepts the order and the order was actually a
replacement version, issue an ExecReport(replaced).
D. If the market rejects the order and the order was a replacement
version, this is the only tricky scenario. You must issue an
unsolicited cancel on the previous version of the order, followed by
a CancelReject for the replacement version.

I believe this removes any liability as a result of your system actually
accepting an order. You only accept an order when the next version is
submitted.

I hope this helps.

JohnP