Modify and order status question

, ,
1

Imported from previous forum

2

Folks, we are a broker and our FIX server runs into the following scenario that we can’t find an answer in FIX protocol,

  1. The client sends us order X
  2. We send back confirm for X
  3. The client sends us modify (Y, X)
  4. Before we can send back the confirm for the modify, the client sends us cancel (Z, X). Note, it is (Z, X), not (Z, Y)

Now should we reject the cancel request because the status of both X and Y are unknown at this point? Does FIX protocol say anything about whether an order can (or can not) have two outstanding modify or cancel requests at the same time?

Thanks in advance.

3

[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
I’m sure you’ll get a range of opinions here but our system would accept the modify (Y,X) [effectively canceling the X order] and reply with an ExecutionReport. Then it would reject the cancel (Z,X) order with an ER “already canceled”. Order Y remains active.

> Folks, we are a broker and our FIX server runs into the following scenario that we can’t find an answer in FIX protocol,
>
> 1. The client sends us order X
> 2. We send back confirm for X
> 3. The client sends us modify (Y, X)
> 4. Before we can send back the confirm for the modify, the client sends us cancel (Z, X). Note, it is (Z, X), not (Z, Y)
>
> Now should we reject the cancel request because the status of both X and Y are unknown at this point? Does FIX protocol say anything about whether an order can (or can not) have two outstanding modify or cancel requests at the same time?
>
> Thanks in advance.
>

4

I agree with this approach because if the user’s requests are processed sequentially, then there is no other way to go.

There is also an interesting situation where the FIX server is just forwarding the replace request to another system, and has to wait for acjnowledgement from that system regarding the first relace request. On our systems, we lock the order and does not allow subsequent replaces until the first replace request is acted upon by the target system.

> I’m sure you’ll get a range of opinions here but our system would accept the modify (Y,X) [effectively canceling the X order] and reply with an ExecutionReport. Then it would reject the cancel (Z,X) order with an ER “already canceled”. Order Y remains active.
>
> > Folks, we are a broker and our FIX server runs into the following scenario that we can’t find an answer in FIX protocol,
> >
> > 1. The client sends us order X
> > 2. We send back confirm for X
> > 3. The client sends us modify (Y, X)
> > 4. Before we can send back the confirm for the modify, the client sends us cancel (Z, X). Note, it is (Z, X), not (Z, Y)
> >
> > Now should we reject the cancel request because the status of both X and Y are unknown at this point? Does FIX protocol say anything about whether an order can (or can not) have two outstanding modify or cancel requests at the same time?
> >
> > Thanks in advance.
> >
>