In what perspective must ClOrdId be unique

, ,
1

Imported from previous forum

2

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

I know that ClOrdId must be unique, but in what perspective? Must it be unique among existing orders or unique whatsoever. If it must be unique whatsoever the OMS system, that has to do the validation, must keep track of all orders from the start of time. It seems more reasonable that the ClOrdId is unique among existing orders. In the latter case the ClOrdId can be reused. Perhaps the ClOrdId must be unique thru the trading day?

Regards, Bernt Sandén

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I know that ClOrdId must be unique, but in what perspective? Must it be unique among existing orders or unique whatsoever. If it must be unique whatsoever the OMS system, that has to do the validation, must keep track of all orders from the start of time. It seems more reasonable that the ClOrdId is unique among existing orders. In the latter case the ClOrdId can be reused. Perhaps the ClOrdId must be unique thru the trading day?

The general view I have heard is that ClOrdID must be unique for a given FIX session, among all orders live at one time today.

I.e. FIX Session A sends me ClOrdID=1 and FIX Session B sends me ClOrdID=1. No problem, as they are on different sessions.

On FIX Session A someone sends me ClOrdID=1, the order is then cancelled and dies. They CANNOT send me a new order ClOrdID=1 that same day, even though the existing one is dead.

Or someone sends me ClOrdID=1, and it is a GTC order. Next Wednesday the order finally trades. That firm cannot send me ClOrdID=1 until that order is no longer live, and even then they cannot send it again on the same day the order died (next Wednesday). They have to wait one more day (next Thursday) to reuse the ClOrdID.

Now a few interesting notes on the subject:

  1. Defining the end of day becomes a huge problem in 24-hour sessions, especially with international markets open all around the world. Is the rollover time midnight where the client lives? Midnight where the server lives? Midnight GMT? Has the broker chosen an arbitrary rollover time to try to hit a slot where none of the most commonly used world markets aren’t open?

  2. It makes a lot of sense for buy-sides to embed a date in their ClOrdID to assure global uniqueness. However the sell-sides really can’t require it. Embedding such a date eliminates the problem above, as well as the problem where one or more orders have their ClOrdIDs sticking around longer than they should on the sell-side’s system, and the buy-side finds their orders rejected for no good reason.

  3. In FIX routing networks, serious uniqueness problems can occur. Suppose buy-side firms A and B have a FIX session to a hub, and the hub connects to sell-side C. The buy-sides set DeliverToCompID C, and hub sends the orders to C with OnBehalfOfCompID A or B. Now let’s say both A and B try to use ClOrdID=1. This will result in a collision at C, since the spec states a uniqueness requirement, and does not limit the requirement to uniqueness only within a given OnBehalfOfCompID. Hence the hub may have to rewrite ClOrdIDs to assure their uniqueness at C. Likewise, ExecIDs that C sends back to A and B could conflict with ExecIDs that another sell-side broker D sends to A and B as well.

4

> Hi,
>
> I know that ClOrdId must be unique, but in what perspective? Must it be unique among existing orders or unique whatsoever. If it must be unique whatsoever the OMS system, that has to do the validation, must keep track of all orders from the start of time. It seems more reasonable that the ClOrdId is unique among existing orders. In the latter case the ClOrdId can be reused. Perhaps the ClOrdId must be unique thru the trading day?
>
> Regards, Bernt Sandén
>
In the SIAC implementation, ClOrdId is defined as Branch Code, Sequence number and date. Branch Code and Sequence number must be unique within a single trading day, the date assures global uniqueness.
For more information refer to
http://www.nyse.com/pdfs/fix&fcs0920.pdf

5

[ original email was from Jim Northey - jnorthey@lasalletech.com ]
CBOE also uses a format similar to SIAC with a branch code, branch sequence, and order date. This is done for backward compatibility to CMS style systems - and should not be endorsed as a de facto standard. There is no specified format for ClOrdID[11] so the widest variety of counterparty order identification methods can be supported. The only recommendation in the specification that is encouraged is to embed the order date for multi-day orders. As Jeanne Breuer points out, having the date embedded ensures that the ClOrdID is unique across days for multi-day orders - and cleanly addresses the "scope" of uniqueness - providing you with a mechanism to reuse the non-date order identification scheme per day and still have all orders contain a unique ClOrdID.

, Bernt Sandén
> >
> In the SIAC implementation, ClOrdId is defined as Branch Code, Sequence number and date. Branch Code and Sequence number must be unique within a single trading day, the date assures global uniqueness.
> For more information refer to
> http://www.nyse.com/pdfs/fix&fcs0920.pdf
>
>