Client Order Id and Original Client Order Id in restated executions

, ,
1

Imported from previous forum

2

Hi,

I have a question about best practice for populating ClOrdID and OrigClOrdID in Execution Reports for order changes that have occurred out of band. In our system this may occur due to broker intervention on client request or through the use of on-line order management which is independent of the FIX message flow (Web).

The FIX version in use in Fix 5.0 SP2.

I understand that ExecType for such changes should be “Restated”.

I have read that in this case the ClOrdId should be populated with the ClOrdId of last accepted client instruction. I suspect that the OrigClOrdId in this case should not be provided on the Execution Report.

In the FIX 5 SP2 specification for Order Cancel Replace Request however it states the following for OrigClOrdID

“ClOrdID(11) of the previous non rejected order (NOT the initial order of the day) when cancelling or replacing an order. Required when referring to orders that where electronically submitted over FIX or otherwise assigned a ClOrdID”

My question is about how to interpret “or otherwise assigned a ClOrdID”.

Imagine that a client sends an Order Cancel Replace Request with ClOrdId=“2” replacing OrigClOrdID=“1”.

If this instruction is accepted the Execution Report will include ClOrdId=“2” and OrigClOrdID=“1”.

If the order is subsequently cancel/replaced by a broker on client instruction what should ClOrdID and OrigClOrdID contain ?
May the broker “assign” a ClOrdID ? If so should OrigClOrdID contain the ID of the Client Order being replaced ?

This question is also applicable for cancel/replacements which may have been performed on a non FIX channel. May a reference for a client instruction generated in another system be legitimately assigned and returned in an Execution Report ?

In my opinion it would be rational and safer to not entangle FIX process Client Order IDs with those from other agents. This would probably be less astonishing for the author of the client integration.
It would also be impossible for the ClOrdIDs to collide.

How then may a ClOrdID otherwise assigned ?

thanks and regards
David Gibbs

3

First of all congratulations to using FIX 5.0 SP2! The language you are referring to was specifically added to also address the case of FIX and non-FIX interfaces accessing the same entities (e.g. orders) in an exchange environment with legacy interfaces. OrigClOrdID is only relevant in the context of order chaining, hence “when cancelling or replacing an order”. Restating an order does not fall under this category.

The second sentence about electronic submission is only for cancelling and replacing orders. Imagine a verbally submitted order w/o ClOrdID that is to be replaced electronically. OrderID is sufficient here. “Otherwise assigned” means that the broker might have assigned a ClOrdID value during verbal communication (or on the fax he sent) which is provided on the ER with ExecType “New”. Then you have to use order chaining and submit this value in the OrigClOrdID field of the OrderCancelReplaceRequest.

I agree that order chaining should not be emulated over non-FIX channels. Assigning a ClOrdID value upon order entry via non-FIX is ok because it is then about ClOrdID as entity identifier and not about its other purpose as message (request) identifier. The dual purpose of ClOrdID makes these kind of issues complex.

Please have a look at http://www.fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf where such scenarios are described. See section 3.2.3 “Order Entry and Modification from Different Sources” starting on page 24.

Regards,
Hanno.

Hi,

I have a question about best practice for populating ClOrdID and OrigClOrdID in Execution Reports for order changes that have occurred out of band. In our system this may occur due to broker intervention on client request or through the use of on-line order management which is independent of the FIX message flow (Web).

The FIX version in use in Fix 5.0 SP2.

I understand that ExecType for such changes should be “Restated”.

I have read that in this case the ClOrdId should be populated with the ClOrdId of last accepted client instruction. I suspect that the OrigClOrdId in this case should not be provided on the Execution Report.

In the FIX 5 SP2 specification for Order Cancel Replace Request however it states the following for OrigClOrdID

“ClOrdID(11) of the previous non rejected order (NOT the initial order of the day) when cancelling or replacing an order. Required when referring to orders that where electronically submitted over FIX or otherwise assigned a ClOrdID”

My question is about how to interpret “or otherwise assigned a ClOrdID”.

Imagine that a client sends an Order Cancel Replace Request with ClOrdId=“2” replacing OrigClOrdID=“1”.

If this instruction is accepted the Execution Report will include ClOrdId=“2” and OrigClOrdID=“1”.

If the order is subsequently cancel/replaced by a broker on client instruction what should ClOrdID and OrigClOrdID contain ?
May the broker “assign” a ClOrdID ? If so should OrigClOrdID contain the ID of the Client Order being replaced ?

This question is also applicable for cancel/replacements which may have been performed on a non FIX channel. May a reference for a client instruction generated in another system be legitimately assigned and returned in an Execution Report ?

In my opinion it would be rational and safer to not entangle FIX process Client Order IDs with those from other agents. This would probably be less astonishing for the author of the client integration.
It would also be impossible for the ClOrdIDs to collide.

How then may a ClOrdID otherwise assigned ?

thanks and regards
David Gibbs

4

Thank you Hanno,

I think I understand your reply. I’m still a little unsure if I have understood your reply correctly with regard to the Client Order ID where a non FIX transaction has occurred. Should the Client Order ID of the last accepted FIX order be provided?

That would look like this;

Imagine that a client sends an Order Cancel Replace Request with ClOrdId=“2” replacing OrigClOrdID=“1”.

If this instruction is accepted the Execution Report will include ClOrdId=“2” and OrigClOrdID=“1”.

If the order is subsequently replaced by a broker on client instruction the execution report for this would contain the ClOrdID with value “2” (referring to the last accepted client order). OrigClOrdID would not be present (no chaining).

If the order is yet again cancelled or replaced by a broker, without any intervening FIX order messages from the client, the execution report for this would contain the ClOrdID with value “2” (still referring to the last accepted client order). OrigClOrdID would not be present (no chaining).

I hope this puts the case clearly.

thanks
Dave

First of all congratulations to using FIX 5.0 SP2! The language you are referring to was specifically added to also address the case of FIX and non-FIX interfaces accessing the same entities (e.g. orders) in an exchange environment with legacy interfaces. OrigClOrdID is only relevant in the context of order chaining, hence “when cancelling or replacing an order”. Restating an order does not fall under this category.

The second sentence about electronic submission is only for cancelling and replacing orders. Imagine a verbally submitted order w/o ClOrdID that is to be replaced electronically. OrderID is sufficient here. “Otherwise assigned” means that the broker might have assigned a ClOrdID value during verbal communication (or on the fax he sent) which is provided on the ER with ExecType “New”. Then you have to use order chaining and submit this value in the OrigClOrdID field of the OrderCancelReplaceRequest.

I agree that order chaining should not be emulated over non-FIX channels. Assigning a ClOrdID value upon order entry via non-FIX is ok because it is then about ClOrdID as entity identifier and not about its other purpose as message (request) identifier. The dual purpose of ClOrdID makes these kind of issues complex.

Please have a look at http://www.fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf where such scenarios are described. See section 3.2.3 “Order Entry and Modification from Different Sources” starting on page 24.

Regards,
Hanno.

Hi,

I have a question about best practice for populating ClOrdID and OrigClOrdID in Execution Reports for order changes that have occurred out of band. In our system this may occur due to broker intervention on client request or through the use of on-line order management which is independent of the FIX message flow (Web).

The FIX version in use in Fix 5.0 SP2.

I understand that ExecType for such changes should be “Restated”.

I have read that in this case the ClOrdId should be populated with the ClOrdId of last accepted client instruction. I suspect that the OrigClOrdId in this case should not be provided on the Execution Report.

In the FIX 5 SP2 specification for Order Cancel Replace Request however it states the following for OrigClOrdID

“ClOrdID(11) of the previous non rejected order (NOT the initial order of the day) when cancelling or replacing an order. Required when referring to orders that where electronically submitted over FIX or otherwise assigned a ClOrdID”

My question is about how to interpret “or otherwise assigned a ClOrdID”.

Imagine that a client sends an Order Cancel Replace Request with ClOrdId=“2” replacing OrigClOrdID=“1”.

If this instruction is accepted the Execution Report will include ClOrdId=“2” and OrigClOrdID=“1”.

If the order is subsequently cancel/replaced by a broker on client instruction what should ClOrdID and OrigClOrdID contain ?
May the broker “assign” a ClOrdID ? If so should OrigClOrdID contain the ID of the Client Order being replaced ?

This question is also applicable for cancel/replacements which may have been performed on a non FIX channel. May a reference for a client instruction generated in another system be legitimately assigned and returned in an Execution Report ?

In my opinion it would be rational and safer to not entangle FIX process Client Order IDs with those from other agents. This would probably be less astonishing for the author of the client integration.
It would also be impossible for the ClOrdIDs to collide.

How then may a ClOrdID otherwise assigned ?

thanks and regards
David Gibbs

5

Yes, the last accepted ClOrdID is the valid entity identifier and should be the one used for unsolicited (or solicited via non-FIX channel w/o ClOrdID) ExecutionReports (e.g. restatements, fills).

Thank you Hanno,

I think I understand your reply. I’m still a little unsure if I have understood your reply correctly with regard to the Client Order ID where a non FIX transaction has occurred. Should the Client Order ID of the last accepted FIX order be provided?

That would look like this;

Imagine that a client sends an Order Cancel Replace Request with ClOrdId=“2” replacing OrigClOrdID=“1”.

If this instruction is accepted the Execution Report will include ClOrdId=“2” and OrigClOrdID=“1”.

If the order is subsequently replaced by a broker on client instruction the execution report for this would contain the ClOrdID with value “2” (referring to the last accepted client order). OrigClOrdID would not be present (no chaining).

If the order is yet again cancelled or replaced by a broker, without any intervening FIX order messages from the client, the execution report for this would contain the ClOrdID with value “2” (still referring to the last accepted client order). OrigClOrdID would not be present (no chaining).

I hope this puts the case clearly.

thanks
Dave

First of all congratulations to using FIX 5.0 SP2! The language you are referring to was specifically added to also address the case of FIX and non-FIX interfaces accessing the same entities (e.g. orders) in an exchange environment with legacy interfaces. OrigClOrdID is only relevant in the context of order chaining, hence “when cancelling or replacing an order”. Restating an order does not fall under this category.

The second sentence about electronic submission is only for cancelling and replacing orders. Imagine a verbally submitted order w/o ClOrdID that is to be replaced electronically. OrderID is sufficient here. “Otherwise assigned” means that the broker might have assigned a ClOrdID value during verbal communication (or on the fax he sent) which is provided on the ER with ExecType “New”. Then you have to use order chaining and submit this value in the OrigClOrdID field of the OrderCancelReplaceRequest.

I agree that order chaining should not be emulated over non-FIX channels. Assigning a ClOrdID value upon order entry via non-FIX is ok because it is then about ClOrdID as entity identifier and not about its other purpose as message (request) identifier. The dual purpose of ClOrdID makes these kind of issues complex.

Please have a look at http://www.fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf where such scenarios are described. See section 3.2.3 “Order Entry and Modification from Different Sources” starting on page 24.

Regards,
Hanno.

Hi,

I have a question about best practice for populating ClOrdID and OrigClOrdID in Execution Reports for order changes that have occurred out of band. In our system this may occur due to broker intervention on client request or through the use of on-line order management which is independent of the FIX message flow (Web).

The FIX version in use in Fix 5.0 SP2.

I understand that ExecType for such changes should be “Restated”.

I have read that in this case the ClOrdId should be populated with the ClOrdId of last accepted client instruction. I suspect that the OrigClOrdId in this case should not be provided on the Execution Report.

In the FIX 5 SP2 specification for Order Cancel Replace Request however it states the following for OrigClOrdID

“ClOrdID(11) of the previous non rejected order (NOT the initial order of the day) when cancelling or replacing an order. Required when referring to orders that where electronically submitted over FIX or otherwise assigned a ClOrdID”

My question is about how to interpret “or otherwise assigned a ClOrdID”.

Imagine that a client sends an Order Cancel Replace Request with ClOrdId=“2” replacing OrigClOrdID=“1”.

If this instruction is accepted the Execution Report will include ClOrdId=“2” and OrigClOrdID=“1”.

If the order is subsequently cancel/replaced by a broker on client instruction what should ClOrdID and OrigClOrdID contain ?
May the broker “assign” a ClOrdID ? If so should OrigClOrdID contain the ID of the Client Order being replaced ?

This question is also applicable for cancel/replacements which may have been performed on a non FIX channel. May a reference for a client instruction generated in another system be legitimately assigned and returned in an Execution Report ?

In my opinion it would be rational and safer to not entangle FIX process Client Order IDs with those from other agents. This would probably be less astonishing for the author of the client integration.
It would also be impossible for the ClOrdIDs to collide.

How then may a ClOrdID otherwise assigned ?

thanks and regards
David Gibbs