Reject Amend/Cancel on Order not yet NEW

, ,
1

Imported from previous forum

2

Hi,

While a new order is not yet acknowledged (i.e. not yet replied with NEW execution report). There comes another FIX amendment/cancellation request on the same order. Just wonder what OrdStatus(31) value should be returned in OrderCancelReject message to reject the amendment/cancellation request. Is it appropriate to return NEW(0)?

Thanks,

Mike

3

Why would you respond to the second request prior to the first one? You could just queue the second one to process them in order. This seems to be the simplest solution.

If you want to immediately reject any requests on orders that have not reached status NEW then you could use PENDING NEW to express this. Alternatively, you can use OrdStatus=REJECTED, CxlRejReason=1=Unknown Order.

The latter does not allow the submitter to modify or cancel an order before having received a confirmation which might be less desirable.

The former creates a non-deterministic behavior because you accept or reject a modification based on you having sent NEW, regardless whether the submitter has also seen NEW or not. The submitter will therefore not see a rejection in some cases even though he has not seen the ExecutionReport with NEW yet.

Regards,
Hanno.

Hi,

While a new order is not yet acknowledged (i.e. not yet replied with NEW
execution report). There comes another FIX amendment/cancellation
request on the same order. Just wonder what OrdStatus(31) value should
be returned in OrderCancelReject message to reject the
amendment/cancellation request. Is it appropriate to return NEW(0)?

Thanks,

Mike

4

[ original email was from Greg Wood - gregjwood@hotmail.com ]
Hi Hanno and Mike,

In response to Mike’s original question I would suggest 39=A (PendingNew) is the preferred order status for a CancelReject when a new order has not been ack’d prior to a cancel or replace request being received. Similarly for a subsequent request on an order pending cancel or replace then 39=6 or 39=E would be appropriate.

As to Hanno’s point regarding why respond to the 2nd request before the first, sometimes the full sequence is not in our control. As a broker/dealer we rely on various downstream systems - such as exchanges - to provide the ack to a new order. There is obviously inherent latency that can be variable due to load or other conditions such as loss of connectivity, etc, and it is common to receive subsequent requests before the ack is returned to the client, especially for fast moving markets and high frequency traders.

It has been a common debate whether receivers of FIX messages should chain requests or reject if a state is still pending transition. The easiest approach is to reject if still pending (39=A, 39=E, 39=6) simply because it keeps things cleaner. In practice, buffering requests and then applying them when transitions are ack’d can actually lead to bigger errors or strains on messaging infrastructure than forcing the sender to keep submitting their request until the receiver is ready to process it, simply because we reject further upstream before doing too much processing internally.

The argument has been made whether this is right or wrong, especially whether you should still buffer cancel requests when rejecting replaces on pending orders, but it comes down to weighing up the pros and cons and making a decision on which practice to choose - chain or reject.

Regards,

  • Greg

Why would you respond to the second request prior to the first one? You
could just queue the second one to process them in order. This seems to
be the simplest solution.

If you want to immediately reject any requests on orders that have
not reached status NEW then you could use PENDING NEW to express
this. Alternatively, you can use OrdStatus=REJECTED,
CxlRejReason=1=Unknown Order.

The latter does not allow the submitter to modify or cancel an order
before having received a confirmation which might be less desirable.

The former creates a non-deterministic behavior because you accept or
reject a modification based on you having sent NEW, regardless whether
the submitter has also seen NEW or not. The submitter will therefore not
see a rejection in some cases even though he has not seen the
ExecutionReport with NEW yet.

Regards, Hanno.

Hi,

While a new order is not yet acknowledged (i.e. not yet replied with
NEW execution report). There comes another FIX amendment/cancellation
request on the same order. Just wonder what OrdStatus(31) value should
be returned in OrderCancelReject message to reject the
amendment/cancellation request. Is it appropriate to return NEW(0)?

Thanks,

Mike

5

Hi,

While a new order is not yet acknowledged (i.e. not yet replied with NEW
execution report). There comes another FIX amendment/cancellation
request on the same order. Just wonder what OrdStatus(31) value should
be returned in OrderCancelReject message to reject the
amendment/cancellation request. Is it appropriate to return NEW(0)?

Thanks,

Mike

As per my opinion if any execution for the order took place first execution report should be displayed and if Amend/cancel is rejected then tag 31 should should contain the LTP.