Imported from previous forum
[ original email was from John Rattinger - jrattinger@slk.com ]
Hi All,
I have a situation that I’m not quite sure how to handle. One particular exchange that we route customer orders to (selectnet), occasionaly sends me a partial cancel and then a partial fill. I do not want to deal with queueing up this cancel and then sending it after the partial arrives.
There is no mention of this scenario in the spec, is there a defacto standard way to do this? I need to handle this in both 3.0 and 4.0.
Any suggestions are appreciated.
John
jrattinger@slk.com
Spear, Leeds and Kellogg
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I have a situation that I’m not quite sure how to handle. One particular exchange that we route customer orders to (selectnet), occasionaly sends me a partial cancel and then a partial fill. I do not want to deal with queueing up this cancel and then sending it after the partial arrives.
>
> There is no mention of this scenario in the spec, is there a defacto standard way to do this? I need to handle this in both 3.0 and 4.0.
At issue here is that the only side who can initiate the modification of an order is the buy side. There are cases when the sell side may need to make a modification to the order, either in the case of an automated exchange interface like you describe, or in the case where the request to modify the order is made via a telephone call. I don’t believe there’s a standardized way of the sell side sending an unsolicited modification of an order in FIX. This could be a useful addition to the spec.
My first stab at a straightforward and general way would be to add a new ExecTransType / ExecType of "Order Modified" Upon receipt of such an Execution message, the buy side compares the fields and makes appropriate changes to their internal order state. In your case, the only field that changes is OrderQty (and in 4.1 LeavesQty) which reflects the decrease due to the SelectNet partial cancel.
In the mean time, the only things I can suggest are queueing the message, which you do not want to do, or agree upon a non-standard way of doing this with the client(s) in question.
[ original email was from John Armstrong - johna@ms.com ]
The same problem(although simpler) lies with an
unsolicited cancelled message. I think they should
both behave the same way, i.e. as Ryan says, send
an ExecType of Replaced(or Cancelled) with the
OrderQty and LeavesQty reflecting the new state of
the order.
In 4.1, the fact that an OrigClOrdID would not
exist on the message reflects the fact that it’s
unsolicited.
> > I have a situation that I’m not quite sure how to handle. One particular exchange that we route customer orders to (selectnet), occasionaly sends me a partial cancel and then a partial fill. I do not want to deal with queueing up this cancel and then sending it after the partial arrives.
> >
> > There is no mention of this scenario in the spec, is there a defacto standard way to do this? I need to handle this in both 3.0 and 4.0.
>
> At issue here is that the only side who can initiate the modification of an order is the buy side. There are cases when the sell side may need to make a modification to the order, either in the case of an automated exchange interface like you describe, or in the case where the request to modify the order is made via a telephone call. I don’t believe there’s a standardized way of the sell side sending an unsolicited modification of an order in FIX. This could be a useful addition to the spec.
>
> My first stab at a straightforward and general way would be to add a new ExecTransType / ExecType of “Order Modified” Upon receipt of such an Execution message, the buy side compares the fields and makes appropriate changes to their internal order state. In your case, the only field that changes is OrderQty (and in 4.1 LeavesQty) which reflects the decrease due to the SelectNet partial cancel.
>
> In the mean time, the only things I can suggest are queueing the message, which you do not want to do, or agree upon a non-standard way of doing this with the client(s) in question.
>
>
> Hi All,
>
> I have a situation that I’m not quite sure how to handle. One particular exchange that we route customer orders to (selectnet), occasionaly sends me a partial cancel and then a partial fill. I do not want to deal with queueing up this cancel and then sending it after the partial arrives.
>
> There is no mention of this scenario in the spec, is there a defacto standard way to do this? I need to handle this in both 3.0 and 4.0.
>
> Any suggestions are appreciated.
>
> John
> jrattinger@slk.com
> Spear, Leeds and Kellogg
John,
I would recommend getting another tech involved ASAP. 
[ original email was from Koji Kubota - koji.kubota@gs.com ]
In Japan, trading system of stock exchanges
work in the similar way. They don’t guarantee
the sequence of messages as messages are
generated.
However, partial fill is almost only reason
why the cancellation was done partially,
therefore, a partial fill and a partial
cancel come one after another. After both
messages come in, we see the order has
some executed and the rest cancelled.
The way, I believe, that most Japanese
companies handle this is treating a partial
cancel as quantity reduction, and ignoring
the incorrect order status between a partial
fill and a partial cancel, which lasts only
a few seconds.
> Hi All,
>
> I have a situation that I’m not quite sure how to handle. One particular exchange that we route customer orders to (selectnet), occasionaly sends me a partial cancel and then a partial fill. I do not want to deal with queueing up this cancel and then sending it after the partial arrives.
>
> There is no mention of this scenario in the spec, is there a defacto standard way to do this? I need to handle this in both 3.0 and 4.0.
>
> Any suggestions are appreciated.
>
> John
> jrattinger@slk.com
> Spear, Leeds and Kellogg
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The way, I believe, that most Japanese
> companies handle this is treating a partial
> cancel as quantity reduction, and ignoring
> the incorrect order status between a partial
> fill and a partial cancel, which lasts only
> a few seconds.
I think we agree that there is a business need for the person that accepts an order (sell side / exchange / ecn) to be able to initiate a modification of the order and communicate this in FIX. The partial cancel is just one example; manual intervention, and adjustments based on corporate actions on a GTC order are different scenarios that could use it as well. The big question is how to do it in FIX.
I see a few ways:
-
Send an OrdStatus / ExecType New message with the new parameters. This is something I recently heard recommended for adjusting GTCs based on corporate actions in the morning. FIX implementations would then need to look for a second New execution and if received, update their order record accordingly.
-
Send an OrdStatus / ExecType Replaced. In FIX 4.1, as John Armstrong said, without an OrigClOrdID it would indicate that the event was unsolicited. But I don’t see how this could be easily indicated in FIX 4.0 or prior. Therefore all Replaced messages would need to be scanned for unsolicited changes to the underlying order.
-
Create a separate ExecTransType of Order Modified.
My personal preference is the latter because it is a very direct, non-ambiguous and hard to ignore way of doing it. With 1 and 2, it is conceivable that a FIX engine / OMS might get an unexpected New or Replaced Execution and just forget about it, rather than checking for the case of the sell side / exchange / ecn modifying an order. And not all OMS’s have the concept of allowing such “unsolicited” modifications; they might only allow just an unsolicited UR OUT.
If someone sends an unknown ExecTransType, that probably is going to generate a session-level Reject or otherwise raise eyebrows of the people involved. It also makes documentation of FIX capabilities easier; people can then say, "We can send ExecTransType Order Modified under X, Y, and Z circumstances" or "We will never send ExecTransType Order Modified," or "This OMS can/cannot accept ExecTransType Order Modified."
An obvious disadvantage is that this is a significant change which cannot be incorporated into 4.1 after it has been released. But I believe neither of the other approaches were sufficiently documented in the FIX spec either, so I do not believe people can rely upon implementations behaving in a standard way in these cases.