ClOrdID and OrderID

, ,
1

Imported from previous forum

2

Hi

One of my clients asked me following question. The client is an oversea exchange.

As I understand, FIX protocol uses ClOrderID for cancel/replace orders. It is sell-side’s job to match the client’s ClOrdID to sell-side assigned OrderID.

Now, this exchange may plan to implement in the reverse…due to the way their legacy matching system is architected. They would like to use OrderID as the main ID for identifying the order and replace/cancel. In this scenario, it is buy-sides (exchange members)’ job to match the ClOrdID with the exchange assigned OrderID. ClOrdID chaining for cancel/replace will not be supported and instead OrderID will change when the order is modified.

Using an example,

  1. Exchange member Firm A sends a new order single with ClOrdID = 001

  2. Exchange responds back with exec report with OrdStatus=NEW, OrderID = E001, ClOrdID=001

  3. Firm A now sends cance/replace with ClOrdID=002, OrigClOrdID=001, but the message also needs to have OrderID=E001 (as exchange will use this ID for cancel/replace).

  4. Exchange responds back with exec report with ExecType=Replaced, OrderID=E002, ClOrdID=001, the message will not contain OrigClOrdID as Exchange will not keep track of order chain of ClOrdID.

  5. If Firm A needs to do another cancel/replace, Firm A will need to now send the message with OrderID=E002.

While I acknowledge this is not the way FIX protocol handles ID, and would result in some extra development effort on the member firm to connect with this exchange, I would like to know a) is there any exchanges in the world who implemented FIX the same or similar way to above method b) how much impact (and pain) would such design cause on member firms who have already implemented FIX system for other exchanges?

Also, another question…this exchange plans not to use OrdStatus=Pending New, Pending Cancel, etc, as the order is received and processed all electronically and they do not see the point of sending back the “pending” status… Even though FIX protocol recommends sending back such status, I assume these pending status are designed for communication between buy-side and brokers and brokers to non-electronic exchange. If the time lag between when order is initially received and then accepted by upstream system is very small, “pending” status would lose much of its value. Please let me know if we are missing something here.

Your responses to the above questions are very much appreciated.

Thanks in advance

Jack

3

Now, this exchange may plan to implement in the reverse…due to the way
their legacy matching system is architected. They would like to use
OrderID as the main ID for identifying the order and replace/cancel. In
this scenario, it is buy-sides (exchange members)’ job to match the
ClOrdID with the exchange assigned OrderID. ClOrdID chaining for
cancel/replace will not be supported and instead OrderID will change
when the order is modified.

In my opinion, this is not acceptable. The reason it is done this way
is so that the buy-side firm does not have to wait for an acknowledgement
from the exchange before cancelling the order. If the buy-side firm decides almost immediately to cancel, it should be able to send that
cancel message right away without waiting for the exchange’s response.
Furthermore, if the exchange has a system problem and the acknowledgements
are delayed, that would prevent the buy-side from sending the cancel.
This is simply unacceptable from a business perspective.

If the exchange is unable to implement a hash table or database lookup
to map the buy-side ClOrdID to the exchange’s internal OrderID, then
the exchange clearly does not possess the technical sophistication to
implement FIX.

Regards,
Andy

4

In addition to not being able to cancel orders until they’ve been acked with an OrderID, not returning OrigClOrdID on execution reports may cause problems for systems using FIX 4.1 or later.

On the question of not sending pending cancels, there are exchanges who don’t send these (CME), and there are exchanges that offer this suppression as an option on a per-connection basis (Archipelago).

David Rhodes
TransactTools

Now, this exchange may plan to implement in the reverse…due to the
way their legacy matching system is architected. They would like to
use OrderID as the main ID for identifying the order and
replace/cancel. In this scenario, it is buy-sides (exchange members)’
job to match the ClOrdID with the exchange assigned OrderID. ClOrdID
chaining for cancel/replace will not be supported and instead OrderID
will change when the order is modified.

In my opinion, this is not acceptable. The reason it is done this way is
so that the buy-side firm does not have to wait for an acknowledgement
from the exchange before cancelling the order. If the buy-side firm
decides almost immediately to cancel, it should be able to send that
cancel message right away without waiting for the exchange’s response.
Furthermore, if the exchange has a system problem and the
acknowledgements are delayed, that would prevent the buy-side from
sending the cancel. This is simply unacceptable from a business
perspective.

If the exchange is unable to implement a hash table or database lookup
to map the buy-side ClOrdID to the exchange’s internal OrderID, then the
exchange clearly does not possess the technical sophistication to
implement FIX.

Regards, Andy

5

[ original email was from Sadat Malik - sm@cameronsystems.com ]
Andy,

As you have described (and for various other reasons), order ID cross-referencing can and does vary by implementation. The CameronFix DMA architecture includes an XREF plug-in which is used to support custom cross-referencing logic. It can be used for example in the scenario you describe, to enhance the technical sophistication of the Exchange to do what is required from a (FIX) business perspective.

I’d be happy to discuss further.

Regards,
Sadat