ClOrdID & Order Status Request

, ,
1

Imported from previous forum

2

[ original email was from Guillaume Jamin - guillaume.jamin@gltrade.com ]
Hi,

I have some questions around the tag ClOrdID.

Consider the following scenario:
a. New Order Single ClOrdID=A -> ack A
b. Replace ClOrdID=B OrigClOrdID=A -> ack B,A
c. Replace ClOrdID=C OrigClOrdID=B -> ack C,B
d. Replace ClOrdID=D OrigClOrdID=C -> ack D,C

If the order is still valid (not expired, not completely filled):

  • Should we keep all the ClOrdID history?
  • Should we reject any new order single using old ClOrdID (A or B)?
  • What should we answer in case of an Order Status Request on ClOrdID A?

Many Thanks for any help,
Regards,
Guillaume

3

[ original email was from Jean-Cedric Jollant - jc@ullink.com ]
.
Guillaume,

Yes, you should reject duplicate ClOrdID to observe the uniqueness rule during a FIX session. Which implies you need to memorize that tree somehow.

Rgds
JC

4

The scope of ClOrdID uniqueness and the requirement for the receiver to enforce it is debatable. The current FIX specification is fairly clear in this respect and describes ClOrdID in the sense of a message identifier that cannot be re-used. The Order Status Request needs to be given the most recent ClOrdID to identify the order.

The FIX Exchange/ECN Working Group has discussed this issue as the enforcement of ClOrdID uniqueness can be a serious performance burden for existing exchanges, e.g. if it internally only uses its own order identification. The scope of uniqueness should not have to go beyond the current session, the current business day, a single security and active orders.

The last point would allow you to re-use values that are no longer associated with an active order. This makes implementation straightforward as you would not have to keep a history of all ClOrdID values but simply need to check if you have an active order with the same ID. Only in this case you would have to reject NewOrderSingle.

However, the question is how practical it is for the sender to keep track of ClOrdID values that can be re-used. It might be easier to start a session with 1 and just keep incrementing a number, thus providing uniqueness to you.

Regards,
Hanno.

Hi,

I have some questions around the tag ClOrdID.

Consider the following scenario:
a. New Order Single ClOrdID=A → ack A
b. Replace ClOrdID=B OrigClOrdID=A → ack B,A
c. Replace ClOrdID=C OrigClOrdID=B → ack C,B
d. Replace ClOrdID=D OrigClOrdID=C → ack D,C

If the order is still valid (not expired, not completely filled):

  • Should we keep all the ClOrdID history?
  • Should we reject any new order single using old ClOrdID (A or B)?
  • What should we answer in case of an Order Status Request on ClOrdID A?

Many Thanks for any help, Regards, Guillaume

5

Hi,

we suggest our customers - I think it’s a good practice:

  • we recommend to keep history,
  • ClOrdId should be unique - we reject orders with “old” ID,
  • you should send “business reject” - “j” - “unknown ID”

Rgds, MS

Hi,

I have some questions around the tag ClOrdID.

Consider the following scenario:
a. New Order Single ClOrdID=A → ack A
b. Replace ClOrdID=B OrigClOrdID=A → ack B,A
c. Replace ClOrdID=C OrigClOrdID=B → ack C,B
d. Replace ClOrdID=D OrigClOrdID=C → ack D,C

If the order is still valid (not expired, not completely filled):

  • Should we keep all the ClOrdID history?
  • Should we reject any new order single using old ClOrdID (A or B)?
  • What should we answer in case of an Order Status Request on ClOrdID A?

Many Thanks for any help, Regards, Guillaume