Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I’ve implemented the suggested OrdStatus priority in a FIX server. I agree with the logic behind it, but I’ve noticed that it has caused some FIX clients to drop trades.
It seems that some FIX clients process execution messages as follows:
if ExecTransType == New
if OrdStatus == Filled or OrdStatus == Partially Filled
Process Trade of LastShares at LastPx
else if OrdStatus == Cancelled
Kill Order
This means that the FIX client will drop trades if:
A user cancels an order, but a partial fill comes back. Pending Cancel/Replace takes priority over Partially Filled, hence I send the execution as Pending Cancel/Replace, with LastShares and LastPx set as the trade price.
A user cancels an order, and a final partial fill comes back. The FIX server alternately sends a final partial fill, with status Cancelled.
Although this probably isn’t that likely, an order is stopped and more than one partial fills come back. Stopped has priority over Partially Filled, so the first partial fill will have status of Stopped.
I’m thinking a more general way to handle these cases is:
if ExecTransType == New
if LastShares > 0
Process Trade of LastShares at LastPx
if OrdStatus == Cancelled
Kill Order
I’m wondering if it may help to clarify the specification by stating that a new trade is defined as an Execution message of type New with LastShares > 0. Any message changing the status of an order but not indicating a trade, such as a CMS-style UR OUT being represented as an OrdStatus of Cancelled, would then be required to have LastShares equal to 0.
Comments?
Ryan Pierce
Townsend Analytics Ltd.
[ original email was from John Armstrong - ]
What version are you using? The OrdStatus priority was only one of
several proposed changes for a FIX 4.1 release. The precedence
will definitely break < 4.1 versions because the second part of the
proposal, the ExecType field does not exist.
John Armstrong
> I’ve implemented the suggested OrdStatus priority in a FIX server. I agree with the logic behind it, but I’ve noticed that it has caused some FIX clients to drop trades.
>
> It seems that some FIX clients process execution messages as follows:
>
> if ExecTransType == New
> if OrdStatus == Filled or OrdStatus == Partially Filled
> Process Trade of LastShares at LastPx
> else if OrdStatus == Cancelled
> Kill Order
>
> This means that the FIX client will drop trades if:
>
> A user cancels an order, but a partial fill comes back. Pending Cancel/Replace takes priority over Partially Filled, hence I send the execution as Pending Cancel/Replace, with LastShares and LastPx set as the trade price.
>
> A user cancels an order, and a final partial fill comes back. The FIX server alternately sends a final partial fill, with status Cancelled.
>
> Although this probably isn’t that likely, an order is stopped and more than one partial fills come back. Stopped has priority over Partially Filled, so the first partial fill will have status of Stopped.
>
> I’m thinking a more general way to handle these cases is:
>
> if ExecTransType == New
> if LastShares > 0
> Process Trade of LastShares at LastPx
> if OrdStatus == Cancelled
> Kill Order
>
> I’m wondering if it may help to clarify the specification by stating that a new trade is defined as an Execution message of type New with LastShares > 0. Any message changing the status of an order but not indicating a trade, such as a CMS-style UR OUT being represented as an OrdStatus of Cancelled, would then be required to have LastShares equal to 0.
>
> Comments?
>
> Ryan Pierce
> Townsend Analytics Ltd.
>