Cancel/Replace

, ,
1

Imported from previous forum

2

Hi

If a broker system receives a Cancel/Replace with another Cancel/Replace still outstanding, should the new one be put into the broker system immediately? If so, what about the first one?

Regards
Harry

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
> Hi
>
> If a broker system receives a Cancel/Replace with another Cancel/Replace still outstanding, should the new one be put into the broker system immediately? If so, what about the first one?
>
> Regards
> Harry
>

Hi Harry,

In actual fact, while your scenario is very simple to describe, it is nonetheless a very tricky subject (IMHO).

The broker system can operate in any way it sees fit. The most important thing is to make the customers aware of the broker system behavior in advance (if they care).

For the circumstance you detailed, there are 2 possible behaviors that I can think of (I’m sure other people can think of several more):

  1. The second cancel/replace is considered unacceptable as the order is currently in “pending state” while the previous cancel/replace processing isn’t yet complete. Under this circumstance a CancelReject message would be the applicable response. The first cancel/replace would then still be worked upon until it was completed.
  2. The second (and indeed any other subsequent) request against this order would be put into a holding area, having send back a "pending cancel/replace" or "pending cancel" as applicable. When the current request against the order was completed, the next request against the order would be pulled from the holding area and commenced.

Whatever your design, it would be highly unfriendly not to be able to accept a CancelRequest against an order that was currently processing a Cancel/Replace request. Even in the version #1 design above, you must be able to handle a CancelRequest at any time, even if you defer its processing until a pending cancel/replace is finished.

Design #2 above is a more versatile design. It permits many, many requests to be queued against an order and processed in the sequence they were received, one at a time. Even with this model, you have to be able to handle the case where an order gets completely filled while still having many requests queued up against it. You also have to handle the fact that each request in a chain of requests depends on successful completion of the previous request. What happens if you have 5 cancel/replace requests queued and the one currently being processed is rejected? Do you kill all queued requests? Do you attempt to process them “if it makes sense”? You couldn’t cancel/replace a ClOrdID that never “went live”. You couldn’t cancel a ClOrdID that never went live either, despite the fact that the intention of the cancel request is quite clear. You could decide to always honor a cancel request, cancelling an order, even if it applied to a “never went live” ClOrdID.

I hope at least I have given you something to apply further thought to.