Optional OrderId should be required?

, ,
1

Imported from previous forum

2

[ original email was from Bernt Sanden - bernt.sanden@omgroup.com ]
Hi,

I am designing a FIX interface to an OMS and have a question regarding the OrderId field.

The OrderId field is mandatory when sending an ExecutionReport as an acknowledge to a New Order Single message.

Why is the OrderId field optional when sending a Order Cancel/Order Cancel Replace and mandatory in the ExecutionReport message? I think it should be mandatory in both?

In our FIX interface we would like to make the OrderId mandatory in the Order Cancel/Order Cancel replace. We would like to use the order id that is created in our OMS.

I would like the following transaction flow:

FIX client FIX Gwy

New order single
ClOrdId=ORD1

                  Execution Report
                  ExecType=New
                  ClOrdId=ORD1
                  OrderId=OMS-1

OrderCancel
OrderId=OMS-1
ClOrdId=ORD2
OrigClOrdId=ORD1

                  Execution Report
                  ExecType=Canceled
                  ClOrdId=ORD2
                  OrigClOrdId=ORD1
                  OrderID=OMS-1

Is it ok to require the OrderId field to be filled in the OrderCancel/OrderCancel Replace transactions?

Regards, Bernt Sandén

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The OrderId field is mandatory when sending an ExecutionReport as an acknowledge to a New Order Single message.
>
> Why is the OrderId field optional when sending a Order Cancel/Order Cancel Replace and mandatory in the ExecutionReport message? I think it should be mandatory in both?

OrderID needs to be optional in Order Cancel and Order Cancel/Replace messages.

You are right in that the client assigns ClOrdID, and the OMS receiving the order then turns around and assigns the OrderID. However, when the client sends a Cancel or Cancel/Replace, the client must have the choice of sending just a ClOrdID or both ClOrdID and OrderID.

Let’s say that the client submits the order, but wishes to cancel the order before receiving an Execution Report in acknowledgment. Since the other party assigns OrderID, the client would be out of luck if OrderID were required in the Cancel or Cancel/Replace message. Making it optional allows the client to submit a Cancel with just the ClOrdID only, hence a client can attempt a cancel on an order that has not been acknowledged. This could be a good thing, especially in cases of high latency where the order ack gets delayed.

Two notes here:

  1. It is considered good practice to provide both ClOrdID and OrderID if the order has already been acknowledged. This allows the receiving party to perform a sanity check that both the OrderID and ClOrdID match to the same order.

  2. Even though the FIX spec allows cancelling orders before they ever go live, this does not mean that the sell-side is required to support the functionality. The sell-side may choose to reject cancel requests if the order is not yet live.

4

> Hi,
>
> I am designing a FIX interface to an OMS and have a question regarding the OrderId field.
>
> The OrderId field is mandatory when sending an ExecutionReport as an acknowledge to a New Order Single message.
>
> Why is the OrderId field optional when sending a Order Cancel/Order Cancel Replace and mandatory in the ExecutionReport message? I think it should be mandatory in both?
>
> In our FIX interface we would like to make the OrderId mandatory in the Order Cancel/Order Cancel replace. We would like to use the order id that is created in our OMS.
>
> I would like the following transaction flow:
>
> FIX client FIX Gwy
>
> New order single
> ClOrdId=ORD1
>
> Execution Report
> ExecType=New
> ClOrdId=ORD1
> OrderId=OMS-1
>
> OrderCancel
> OrderId=OMS-1
> ClOrdId=ORD2
> OrigClOrdId=ORD1
>
> Execution Report
> ExecType=Canceled
> ClOrdId=ORD2
> OrigClOrdId=ORD1
> OrderID=OMS-1
>
> Is it ok to require the OrderId field to be filled in the OrderCancel/OrderCancel Replace transactions?
>
> Regards, Bernt Sandén
>
>
>
In the SIAC implementation, the OrderID field is required on all Cancel to Reduce (Message Type F) and all Cancel/Replace (Message Type G) messages.
For more information refer to
http://www.nyse.com/pdfs/fix&fcs0920.pdf