Enforcement of unique ClOrdID (tag 11)

, ,
1

Imported from previous forum

2

Exchange best practices recommends not to enforce a unique ClOrdID and limit check for duplicate ClOrdID (tag 11) to list of active orders in the order book.
I would like to follow up of how this has been addressed different exchanges.
In addition, I would like to check how risks of over execution associated with retransmissions have been addressed, when limited checks are applied.
I thank you in advance.
Natan

3

[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
> Exchange best practices recommends not to enforce a unique ClOrdID and

limit check for duplicate ClOrdID (tag 11) to list of active orders in
the order book. I would like to follow up of how this has been addressed
different exchanges. In addition, I would like to check how risks of
over execution associated with retransmissions have been addressed, when
limited checks are applied. I thank you in advance. Natan

At an exchange with independent books, it was viewed as wasteful (cpu-wise) to require a check of all books to enforce ClOrdID uniqueness.

For the case of a resent order PossDupe or PossResend should be set, so the order could be ignored if already present in the book.

For the case of an erroneously resent order (without PossDupe or PossResend), you could safely check the same book (since the symbol would be the same) and detect duplicate without the overhead of checking all books.

Greg.

4

[ original email was from John Prewett - jprewett@lavatrading.com ]
I have seen this rigorously enforced and also “best effort” enforced.
Depending on the architecture of some systems, it can be very expensive to rigorously enforce ClOrdID uniqueness as Greg mentioned.

Whatever liberal or restrictive enforcement you offer, there is a basic minimum that must be done (IMHO):

Any incoming request must supply a ClOrdID that doesn’t duplicate a ClOrdID that has been already used by a currently open order.

Failure to do this minimal enforcement opens up a nasty world of confusion. Responding to a duplicated ClOrdID without realizing it is indeed a duplicate can also cause major havoc at the original requester’s side when they interpret your response against the wrong order. Now you could callously declare “they deserve it” but I know we’re all more professional than that :slight_smile: