Imported from previous forum
Would it be reasonable for an Exchange/ECN to not support changing ClOrdIDs?
In this model clients would specify a ClOrdID in the NewOrderSingle message and subsequently use that same ClOrdID and/or the OrderID given by the Exchange to refer to that order (e.g. in a CancelReplaceRequest). The ClOrdID remains the same in each case, so the OrgClOrd field is redundant.
This runs against the existing FIX standard but would make our FIX implementation simpler, and would probably make our customer’s implementation easier.
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Graeme,
You would not comply with the FIX standard in using one and the same ClOrdID for order modification etc.
The exchanges/ECNs working group recognizes that many exchanges uses a static OrderID as the primary identifier in updates etc. However, in order not to break existing implementations of FIX and in the interest of standardization, we also accept the ClOrdID rules in general. We are working on a proposal for some changes, but not in the context of what you describe.
One reason for unique ClOrdIDs per message is that FIX is asynchronous and the sender will need to ClOrdID to attach a certain response to the relevant request. A user could e.g. send two updates for the same order and get one rejected.
Regards
Rikard
Would it be reasonable for an Exchange/ECN to not support changing
ClOrdIDs? In this model clients would specify a ClOrdID in the
NewOrderSingle message and subsequently use that same ClOrdID and/or the
OrderID given by the Exchange to refer to that order (e.g. in a
CancelReplaceRequest). The ClOrdID remains the same in each case, so the
OrgClOrd field is redundant. This runs against the existing FIX standard
but would make our FIX implementation simpler, and would probably make
our customer’s implementation easier.
The short answer is no, the long answer as follows:
ClOrdID is primarily a message identifier to enable chaining of requests and responses for orders. If you want to omit it, you either need a separate field for this purpose or you are restricted to a synchronous model where your application has to wait for the response. Only the response has a value for OrderID from the exchange and you need a way to match that to the New Order Single request. An asynchronous model places less restrictions on your users but then you need a field to match requests and responses.
There is a second reason for ClOrdID, namely when you want to cancel an order without having received a response from the exchange. This can be the case when the response goes missing (for whatever reason) or also for algorithmic trading where speed is fundamental.
These are aspects to consider and part of the reason for the existence of ClOrdID. If you do not enforce changing ClOrdIDs, you should still keep the field in the message and require it to be filled. However, you can omit OrigClOrdID if you have a unique OrderID that allows you to identify an order to be replaced or cancelled.
If you are interested in some background information on this and other topics, please have a look at the document Recommended Best Practices of the FPL Exchanges/ECN Working Group.
Regards,
Hanno.
Would it be reasonable for an Exchange/ECN to not support changing
ClOrdIDs? In this model clients would specify a ClOrdID in the
NewOrderSingle message and subsequently use that same ClOrdID and/or the
OrderID given by the Exchange to refer to that order (e.g. in a
CancelReplaceRequest). The ClOrdID remains the same in each case, so the
OrgClOrd field is redundant. This runs against the existing FIX standard
but would make our FIX implementation simpler, and would probably make
our customer’s implementation easier.
[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Hello Hanno,
I’ve read the document on best practices for ECN and your reply below, and I need some further clarification regarding the meaning of the following statement:
“ClOrdID is mandatory, OrigClOrdID and OrderID are conditionally required for order modification and deletion”
If a customer places 2 orders with the same ClOrdID (by error) and the ECN does not validate the uniqueness of the ClOrdID, then, if the client sends a cancelation request, prior to receiving the OrderID
would the ECN then need to cancel all the orders with the same OrigClOrdID?
Or does the statement mean that OrderID will become mandatory for cancellations?
Regards
Ainhoa
The short answer is no, the long answer as follows:
ClOrdID is primarily a message identifier to enable chaining of requests
and responses for orders. If you want to omit it, you either need a
separate field for this purpose or you are restricted to a synchronous
model where your application has to wait for the response. Only the
response has a value for OrderID from the exchange and you need a way to
match that to the New Order Single request. An asynchronous model places
less restrictions on your users but then you need a field to match
requests and responses.There is a second reason for ClOrdID, namely when you want to cancel an
order without having received a response from the exchange. This can be
the case when the response goes missing (for whatever reason) or also
for algorithmic trading where speed is fundamental.These are aspects to consider and part of the reason for the existence
of ClOrdID. If you do not enforce changing ClOrdIDs, you should still
keep the field in the message and require it to be filled. However, you
can omit OrigClOrdID if you have a unique OrderID that allows you to
identify an order to be replaced or cancelled.If you are interested in some background information on this and other
topics, please have a look at the document Recommended Best Practices of
the FPL Exchanges/ECN Working Group.Regards, Hanno.
Would it be reasonable for an Exchange/ECN to not support changing
ClOrdIDs? In this model clients would specify a ClOrdID in the
NewOrderSingle message and subsequently use that same ClOrdID and/or
the OrderID given by the Exchange to refer to that order (e.g. in a
CancelReplaceRequest). The ClOrdID remains the same in each case, so
the OrgClOrd field is redundant. This runs against the existing FIX
standard but would make our FIX implementation simpler, and would
probably make our customer’s implementation easier.
Hi,
Accepting 2 orders with the same ClOrdID is not best practice.
If by accident one of the messages is a duplicate, you will have two orders in the market and you might end up buying or selling the double amount of what you intended to buy or sell.
But if you really want to do so, you have to agree with your counterparty what to do on an order cancel for that ClOrdID.
But you also have to think about how to handle error situations like when an order received is a duplicate.
Regards,
Michael
Hello Hanno,
I’ve read the document on best practices for ECN and your reply below,
and I need some further clarification regarding the meaning of the
following statement:“ClOrdID is mandatory, OrigClOrdID and OrderID are conditionally
required for order modification and deletion”If a customer places 2 orders with the same ClOrdID (by error) and the
ECN does not validate the uniqueness of the ClOrdID, then, if the client
sends a cancelation request, prior to receiving the OrderID would the
ECN then need to cancel all the orders with the same OrigClOrdID?Or does the statement mean that OrderID will become mandatory for
cancellations?Regards
Ainhoa
The short answer is no, the long answer as follows:
ClOrdID is primarily a message identifier to enable chaining of
requests and responses for orders. If you want to omit it, you either
need a separate field for this purpose or you are restricted to a
synchronous model where your application has to wait for the response.
Only the response has a value for OrderID from the exchange and you
need a way to match that to the New Order Single request. An
asynchronous model places less restrictions on your users but then you
need a field to match requests and responses.There is a second reason for ClOrdID, namely when you want to cancel
an order without having received a response from the exchange. This
can be the case when the response goes missing (for whatever reason)
or also for algorithmic trading where speed is fundamental.These are aspects to consider and part of the reason for the existence
of ClOrdID. If you do not enforce changing ClOrdIDs, you should still
keep the field in the message and require it to be filled. However,
you can omit OrigClOrdID if you have a unique OrderID that allows you
to identify an order to be replaced or cancelled.If you are interested in some background information on this and other
topics, please have a look at the document Recommended Best Practices
of the FPL Exchanges/ECN Working Group.Regards, Hanno.
Would it be reasonable for an Exchange/ECN to not support changing
ClOrdIDs? In this model clients would specify a ClOrdID in the
NewOrderSingle message and subsequently use that same ClOrdID and/or
the OrderID given by the Exchange to refer to that order (e.g. in a
CancelReplaceRequest). The ClOrdID remains the same in each case, so
the OrgClOrd field is redundant. This runs against the existing FIX
standard but would make our FIX implementation simpler, and would
probably make our customer’s implementation easier.
Would it be reasonable for an Exchange/ECN to not support changing
ClOrdIDs? In this model clients would specify a ClOrdID in the
NewOrderSingle message and subsequently use that same ClOrdID and/or the
OrderID given by the Exchange to refer to that order (e.g. in a
CancelReplaceRequest). The ClOrdID remains the same in each case, so the
OrgClOrd field is redundant. This runs against the existing FIX standard
but would make our FIX implementation simpler, and would probably make
our customer’s implementation easier.
It is very unreasonable to require a constant ClOrdID. The ClOrdID is meant to mark individual requests that your trading partner makes. This enables you to support critical message flows. For example, rejecting a cancel/replace request or a cancel request becomes very difficult to support. Specifically consider a scenario where a client sends an order, and two cancel replace requests (Please see Scenario D16 in appendix D). Your ECN rejects one cancel replace request. How can the client identify which one you’re rejecting?
Please use the OrderID (tag 37) instead. Its reasonable to require this to stay constant.
Would it be reasonable for an Exchange/ECN to not support changing
ClOrdIDs? In this model clients would specify a ClOrdID in the
NewOrderSingle message and subsequently use that same ClOrdID and/or
the OrderID given by the Exchange to refer to that order (e.g. in a
CancelReplaceRequest). The ClOrdID remains the same in each case, so
the OrgClOrd field is redundant. This runs against the existing FIX
standard but would make our FIX implementation simpler, and would
probably make our customer’s implementation easier.It is very unreasonable to require a constant ClOrdID. The ClOrdID is
meant to mark individual requests that your trading partner makes. This
enables you to support critical message flows. For example, rejecting a
cancel/replace request or a cancel request becomes very difficult to
support. Specifically consider a scenario where a client sends an order,
and two cancel replace requests (Please see Scenario D16 in appendix D).
Your ECN rejects one cancel replace request. How can the client identify
which one you’re rejecting?Please use the OrderID (tag 37) instead. Its reasonable to require this
to stay constant.
If we have two (or more) outstanding change requests we would process them on a FIFO basis so the relationship between request and result should be clear to the client. Wouldn’t this be sufficient?
(I am aware that that we can have a constant OrderID, our concern is with the overhead of validating and tracking changing ClOrdIDs.)
Your concern is not unfounded - there is overhead to processing order changes using ClOrdID.
It sounds as though your are using the order message for what is in essence a quote driven market. The quote messages in FIX do not require chaining and are more appropriate for a quote driven (this can mean tradeable quotes as well).
What other exchanges have done is to accept the quote message (or mass quote depending on asset class) and create order objects from them in their trading system, instead of differing from the FIX order handling rules.
My previous experience in deviating from the FIX order handling rules for another exchange was a very painful experience. You will find that doing so may even impact potential market participant’s willingness to connect to your market. This was not a pleasant experience.
A considerable amount of existing infrastructure - FIX engines and OMSs support the FIX order handling rules and firms are very reluctant to invest in making changes.