Cancel Replace Question

, ,
1

Imported from previous forum

2

All,

Please take a look at the following scenario in FIX 4.2:

Nos- tag11=0010
Ack- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
ModReq- tag11=0020, tag41=0010
Pfill- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
Replaced- tag11=0020, tag41=0010, tag37=0002
Pfill- tag11=0020, tag37=0001, tag38=original qty (should have been new qty)
Pfill- tag11=0020, tag37=0002
Pfill- tag11=0020, tag37=0002

I have 2 questions:
1- Should the OrderID (Tag37) remain static throughout the life of the order?
2- Does the partial after the replaced message look like standard FIX?
3- When booking this, should the partial after the replaced message be associated to the new ClOrdID(11) or the old OrdID(37)? Which ID take the “lead” or is in charge?

Thanks very much!
Michael

3

Tag 11 is always the current order
Tag 41 is always the order to cancel, in a cancel or cancel/replace
Tag 37 is unique for each order
The fill after the cxl/rpl:
tag 38 should always be the current quantity of the open order

 tag 14 will have the shares executed to date

All,

Please take a look at the following scenario in FIX 4.2:

Nos- tag11=0010 Ack- tag11=0010, tag37=0001 Pfill- tag11=0010,
tag37=0001 Pfill- tag11=0010, tag37=0001 ModReq- tag11=0020, tag41=0010
Pfill- tag11=0010, tag37=0001 Pfill- tag11=0010, tag37=0001 Replaced-
tag11=0020, tag41=0010, tag37=0002 Pfill- tag11=0020, tag37=0001,
tag38=original qty (should have been new qty) Pfill- tag11=0020,
tag37=0002 Pfill- tag11=0020, tag37=0002

I have 2 questions: 1- Should the OrderID (Tag37) remain static
throughout the life of the order? 2- Does the partial after the replaced
message look like standard FIX? 3- When booking this, should the partial
after the replaced message be associated to the new ClOrdID(11) or the
old OrdID(37)? Which ID take the “lead” or is in charge?

Thanks very much! Michael

4

Understood, thanks for that.

When you say tag37 is unique for each order, are you treating the orginial order and the replaced order as 2 orders or 1 order?

If they are to be considered 2 seperate orders (in FIX terms) then should the OMS apply the partial fill to the new ClOrdId or the old OrderID? Which ID is more important?

Thanks again!

Tag 11 is always the current order
Tag 41 is always the order to cancel, in a cancel or cancel/replace Tag
37 is unique for each order The fill after the cxl/rpl: tag 38 should
always be the current quantity of the open order

 tag 14 will have the shares executed to date

All,

Please take a look at the following scenario in FIX 4.2:

Nos- tag11=0010
Ack- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
ModReq- tag11=0020, tag41=0010
Pfill- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
Replaced- tag11=0020, tag41=0010, tag37=0002
Pfill- tag11=0020, tag37=0001, tag38=original qty (should have been new qty)
Pfill- tag11=0020, tag37=0002
Pfill- tag11=0020, tag37=0002

I have 2 questions: 1- Should the OrderID (Tag37) remain static
throughout the life of the order? 2- Does the partial after the
replaced message look like standard FIX? 3- When booking this,
should the partial after the replaced message be associated to the
new ClOrdID(11) or the old OrdID(37)? Which ID take the “lead” or is
in charge?

Thanks very much! Michael

5

Michael,

Tag 37 refers to the broker ID which remains same throughout the life cycle of a single order. tag 11 which is client order id keeps on changing for every replace request generated on a single order identified by broker order ID (tag 37).

From client perspective, tag 11 is more important as it refers to the current client order ID for any fills being reported on that order. I hope this clarifies but you are free to come back on any doubts you still have.

Regards,
Sunil

6

[ original email was from Niall McCallion - nmccallion@espeed.co.uk ]
Sunil,

Tag 37, Broker Id, is the broker’s own code. It depends how the broker wants to record their Ids. The definitions for tags 37 and 11 are equivalent for the buy and sell sides.

As I understand it, the protocol is that the Client’s order Id ++has++ to change for each Cancel/Replace, whereas the Broker Id change for each Cancel/Replace is optional.

We have had clients who actually reject as incorrect Cancel/replace accepts when we do not change tag 37, which is strange, but that’s the way they read the protocol.

I’ve found a way to supply an Broker Order Id that seems to satisfy most connections is to prepend the date YYYYMMDD and append a version number (if you internally use single order id, with multiple versions). Apply any munging to suit. It does means the field is not semantic-free however.

Cheers

Niall

7

Niall,

Thanks for making me aware of that. Its a value-add for my knowledge base.

Regards,
Sunil

8

Tag 37 must be the same through out the life of an order.

Tag 11 is the milestone key of that order.
However, tag 37 is the permanent key after the new order request is accepted.

Tag 35=G should be interpreted as “modification of order” but not CMS sense of “cancel old and create new”.

Understood, thanks for that.

When you say tag37 is unique for each order, are you treating the
orginial order and the replaced order as 2 orders or 1 order?

If they are to be considered 2 seperate orders (in FIX terms) then
should the OMS apply the partial fill to the new ClOrdId or the old
OrderID? Which ID is more important?

Thanks again!

Tag 11 is always the current order
Tag 41 is always the order to cancel, in a cancel or cancel/replace
Tag 37 is unique for each order The fill after the cxl/rpl: tag 38
should always be the current quantity of the open order

 tag 14 will have the shares executed to date

All,

Please take a look at the following scenario in FIX 4.2:

Nos- tag11=0010 Ack- tag11=0010, tag37=0001 Pfill- tag11=0010,
tag37=0001 Pfill- tag11=0010, tag37=0001 ModReq- tag11=0020, tag41=0010
Pfill- tag11=0010, tag37=0001 Pfill- tag11=0010, tag37=0001 Replaced-
tag11=0020, tag41=0010, tag37=0002 Pfill- tag11=0020, tag37=0001,
tag38=original qty (should have been new qty) Pfill- tag11=0020,
tag37=0002 Pfill- tag11=0020, tag37=0002

I have 2 questions: 1- Should the OrderID (Tag37) remain static
throughout the life of the order? 2- Does the partial after the
replaced message look like standard FIX? 3- When booking this,
should the partial after the replaced message be associated to the
new ClOrdID(11) or the old OrdID(37)? Which ID take the “lead” or is
in charge?

Thanks very much! Michael

9

[ original email was from Niall McCallion - nmccallion@espeed.co.uk ]
After reading Eric’s and Sunil’s posts, I’ve gone back to the spec (fix-42-with_errata_20010501.doc) as I am concerned about my own interpretation of tag 37.

In summary, whilst I think there may be some amibiguity about tag 37 in Fix 4.2, the document does not in anyway require or preclude Tag 37 from being static over the entire lifecycle of an order, or from it changing like ClOrderId. My reasoning is below.

From Field Definitions:

TAG 37: “Unique identifier for Order as assigned by broker. Uniqueness must be guaranteed within a single trading day. Firms which accept multi-day orders should consider embedding a date within the OrderID field to assure uniqueness across days.”

TAG 11: “Unique identifier for Order as assigned by institution (identified by SenderCompID or OnBehalfOfCompID as appropriate). Uniqueness must be guaranteed within a single trading day. Firms, particularly those which electronically submit multi-day orders, trade globally or throughout market close periods,should ensure uniqueness across days, for example by embedding a date within the ClOrdID field.”

On on page 94, in execution reports discussion, “The OrderID field is populated with the broker-generated order number. Unlike ClOrdID/OrigClOrdID which requires a chaining through Cancel/Replaces and Cancels, OrderID and SecondaryOrderID are not required to change through changes to an order.”

You’ll notice the definitions are essentially the same for the client’s order id and the broker’s order id field values, and the discussion does not appear to endorse or forbid the OrderId changing over the course of an Orders lifetime.

On the Execution Report Tag 37 is noted as “is required to be unique for each chain of orders”, on the Order Cancel/Replace and Order Cancel requests it is noted as “unique identifier of most recent order as assigned by broker”. These lack clarity alone but taken in conjunction with the field definitions and discussion I believe Tag 37 can be static or can change like ClOrderId over the lifecycle of an order.

All comments, observations, builds, etc happily recieved.

Thanks again,

Niall

10

If we let tag37 (OrderId) change during the course of cxl/rep,
what the order status with previous ID should be? (open or closed)
(here I assume the OrderId is the key for ECN or any order acceptor)

If we had some partial executions fo this order, what the OrderId should be when any correction/cancellation of those partials generates new Exec Report?

Of course, we can always programmatically overcome those issues.
Neverthless, what is the purpose to have tag37 (OrderId) in FIX exec, cxl/rep or cancel?

Tag 37 must be the same through out the life of an order.

Tag 11 is the milestone key of that order. However, tag 37 is the
permanent key after the new order request is accepted.

Tag 35=G should be interpreted as “modification of order” but not CMS
sense of “cancel old and create new”.

Understood, thanks for that.

When you say tag37 is unique for each order, are you treating the
orginial order and the replaced order as 2 orders or 1 order?

If they are to be considered 2 seperate orders (in FIX terms) then
should the OMS apply the partial fill to the new ClOrdId or the old
OrderID? Which ID is more important?

Thanks again!

Tag 11 is always the current order
Tag 41 is always the order to cancel, in a cancel or cancel/replace
Tag 37 is unique for each order The fill after the cxl/rpl: tag 38
should always be the current quantity of the open order

 tag 14 will have the shares executed to date

All,

Please take a look at the following scenario in FIX 4.2:

Nos- tag11=0010 Ack- tag11=0010, tag37=0001 Pfill- tag11=0010,
tag37=0001 Pfill- tag11=0010, tag37=0001 ModReq- tag11=0020,
tag41=0010 Pfill- tag11=0010, tag37=0001 Pfill- tag11=0010, tag37=0001
Replaced- tag11=0020, tag41=0010, tag37=0002 Pfill- tag11=0020,
tag37=0001, tag38=original qty (should have been new qty) Pfill-
tag11=0020, tag37=0002 Pfill- tag11=0020, tag37=0002

I have 2 questions: 1- Should the OrderID (Tag37) remain static
throughout the life of the order? 2- Does the partial after the
replaced message look like standard FIX? 3- When booking this,
should the partial after the replaced message be associated to the
new ClOrdID(11) or the old OrdID(37)? Which ID take the “lead” or
is in charge?

Thanks very much! Michael

11

Examples would be better if they included ExecType /OrdStatus

#1. As Niall said: FIX does not impose a constraint on the OrderID remaining constant throughout the life of the order. Most implementations I have come across leave the OrderID the same across the life of the order. The sender of the order should build their systems to accept and update the OrderID they recieve on Execution Reports for flexibility. I know of markets that use CMS style order handling semantics that will change the OrderID in certain cancel-replace instances. A submitter should not rely on the OrderID being constant across the life of an order.

#2. If the Execution Report ExecType=Replaced has a new OrderID (tag 37) = 0002 your example looks valid. The PFill following the Replaced report appears to have a typographical error - shouldn’t it have 37=0002 in this case as well? Also the comment that the Pfill following the Replace should have the new quantity is correct.

#3 How should the order be booked (tracked?) - I don’t know of any case where the order submitter doest not track or identify orders by ClOrdID(tag 11). The submitter usually maintains the OrderID(tag 37) as a piece of reference information not as the primary identifier.

The order recipient will also use the ClOrdID(tag 11) to identify the order on inbound messages as well because the submiter is not required to send OrderID(tag 37) on any messages - so the ClOrdID will usually be the only identification available from the submitter.

All,

Please take a look at the following scenario in FIX 4.2:

Nos- tag11=0010 Ack- tag11=0010, tag37=0001
Pfill- tag11=0010,tag37=0001
Pfill- tag11=0010, tag37=0001
ModReq- tag11=0020, tag41=0010
Pfill- tag11=0010, tag37=0001
Pfill- tag11=0010, tag37=0001
Replaced-tag11=0020, tag41=0010, tag37=0002
Pfill- tag11=0020, tag37=0001,tag38=original qty (should have been new qty)
Pfill- tag11=0020,tag37=0002 Pfill- tag11=0020, tag37=0002

I have 2 questions: 1- Should the OrderID (Tag37) remain static
throughout the life of the order? 2- Does the partial after the replaced
message look like standard FIX? 3- When booking this, should the partial
after the replaced message be associated to the new ClOrdID(11) or the
old OrdID(37)? Which ID take the “lead” or is in charge?

Thanks very much! Michael