Imported from previous forum
[ original email was from Bernt Sanden - bernt.sanden@omgroup.com ]
Hi,
The definition of the ClOrdId tag says that:
"Unique identifier for Order as assigned by institution. Uniqueness must be guaranteed within a single trading day"
The uniqueness is supposed to be guaranteed by
the institution. Should the other party, i.e. the broker or the exchange reject messages, e.g. a new order single, that contains a ClOrdId that is not unique?
In this case a FIX engine for example must keep track of all orders submitted during a day to be able to reject orders with not unique values of ClOrdId. This does not seem to be a good idea.
Regards, Bernt Sandén
See D22 in Appendix D - Order State Change Matrices in the FIX 4.2 spec. Note that the "reject" is an ExecutionRpt with ExecType of Rejected vs. a Session-level Reject message, thus the FIX engine is not responsible for tracking every ClOrdID, rather the order handler business-level processing system which interacts with the FIX engine would be.
> Hi,
>
> The definition of the ClOrdId tag says that:
>
> "Unique identifier for Order as assigned by institution. Uniqueness must be guaranteed within a single trading day"
>
> The uniqueness is supposed to be guaranteed by
> the institution. Should the other party, i.e. the broker or the exchange reject messages, e.g. a new order single, that contains a ClOrdId that is not unique?
>
> In this case a FIX engine for example must keep track of all orders submitted during a day to be able to reject orders with not unique values of ClOrdId. This does not seem to be a good idea.
>
> Regards, Bernt Sandén
>