Imported from previous forum
Is it necessary for a sell side or exchange side FIX engine to verify the duplicity in value of ClientOrderId (Tag 11) field in incoming new order, order modify/cancel request?
For example,
Say exchange side FIX engine receives the first New Order Single with ClientOrderId (Tag 11) with value “ABCD”.
Again from the same source, FIX engine receives the second New Order Single with ClientOrderId (Tag 11) with value “ABCD”.
Should FIX engine generate rejection for the second order since Tag 11 value was already received in the first confirmed order? Alternatively, can FIX engine ignore the value received in Tag 11 with the consideration that it is responsiblity of sender of new order to maintain the uniqueness of Tag 11?
I agree “it is responsiblity of sender of new order to maintain the uniqueness of Tag 11” but its the responsibility of every counterparty to ensure that messages which breach FIXProtocol are rejected in some way.
The sell side FIX engine should validate uniqueness of Client Order ID and when a duplicate is received, it should reject the duplicate order using ExecReport 35=8 with OrdStatus 39=8 Rejected. Starting with FIX 4.1, there is an OrdRejReason 103=6 Duplicate Order. FIX 4.0 does not define this enum, so you have the following choices :-
-
Use ExecReport 35=8 with OrdStatus 39=8 Rejected and OrdRejReason 103=6 Duplicate Order if your application / FIX engine permits use of value from a higher FIX version.
-
Use ExecReport 35=8 with OrdStatus 39=8 Rejected with a user-defined tag to indicate rejection due to duplicate ClOrdID and mention this tag in your rules of engagement.
-
Create a User defined message to indicate rejection due to duplicate ClOrdID and mention this in your rules of engagement.
-
Use ExecReport 35=8 with OrdStatus 39=8 Rejected and populate tag 58 Text field so that the counterparties can use its contents to process the rejection appropriately and mention this in your rules of engagement.
-
Some Buy side systems have a bug where rejecting the second order with duplicate clOrdID using ExecReport 35=8 with OrdStatus 39=8 Rejected might get mapped to the first order which has unique ClOrdID and the first order is incorrectly marked as rejected resulting in a live order with open shares on the sell side getting killed on the buy side system. In this case, use Session level Reject 35=3 so that the buy side can identify the correct order to kill using RefSeqNum 45.
Of all the above, 1 is the best solution because its a step in the direction of upgrading to higher FIX version(s).
Regards,
K. Mahesh
Is it necessary for a sell side or exchange side FIX engine to verify the duplicity in value of ClientOrderId (Tag 11) field in incoming new order, order modify/cancel request?
For example,
Say exchange side FIX engine receives the first New Order Single with ClientOrderId (Tag 11) with value “ABCD”.Again from the same source, FIX engine receives the second New Order Single with ClientOrderId (Tag 11) with value “ABCD”.
Should FIX engine generate rejection for the second order since Tag 11 value was already received in the first confirmed order? Alternatively, can FIX engine ignore the value received in Tag 11 with the consideration that it is responsiblity of sender of new order to maintain the uniqueness of Tag 11?
Its good to reject but considered expensive by some exchanges and they do not. Sell side applications usually check for duplicate ClOrdID and reject. The recommended best practices document here http://www.fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf discuss the alternatives. See section 3.1 - Identification.
Is it necessary for a sell side or exchange side FIX engine to verify the duplicity in value of ClientOrderId (Tag 11) field in incoming new order, order modify/cancel request?
For example,
Say exchange side FIX engine receives the first New Order Single with ClientOrderId (Tag 11) with value “ABCD”.Again from the same source, FIX engine receives the second New Order Single with ClientOrderId (Tag 11) with value “ABCD”.
Should FIX engine generate rejection for the second order since Tag 11 value was already received in the first confirmed order? Alternatively, can FIX engine ignore the value received in Tag 11 with the consideration that it is responsiblity of sender of new order to maintain the uniqueness of Tag 11?
I agree with the concern of a uniqueness check being potentially expensive. Note that ClOrdID serves two purposes as message and as entity identifier. The uniqueness constraint cannot be relaxed with respect to message identification. Otherwise the submitter has no way to tie responses to his requests unless he uses a separate field for message identification.
The uniqueness constraint could be relaxed for entity identification, e.g. by reducing the scope of uniqueness to an instrument to avoid a bottleneck in a distributed environment.
As long as ClOrdID is used for both purposes, I do not see the benefit of re-using ClOrdID values, even if this is permitted by the standard for rejected requests. The functional audit trail (not the message log on the engine level) is much simpler if you just use increasing, unique ClOrdID values for your FIX session. The order of ExecutionReports is not guaranteed and you might get an ER for a later request first.
Its good to reject but considered expensive by some exchanges and they do not. Sell side applications usually check for duplicate ClOrdID and reject. The recommended best practices document here http://www.fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf discuss the alternatives. See section 3.1 - Identification.
Is it necessary for a sell side or exchange side FIX engine to verify the duplicity in value of ClientOrderId (Tag 11) field in incoming new order, order modify/cancel request?
For example,
Say exchange side FIX engine receives the first New Order Single with ClientOrderId (Tag 11) with value “ABCD”.Again from the same source, FIX engine receives the second New Order Single with ClientOrderId (Tag 11) with value “ABCD”.
Should FIX engine generate rejection for the second order since Tag 11 value was already received in the first confirmed order? Alternatively, can FIX engine ignore the value received in Tag 11 with the consideration that it is responsiblity of sender of new order to maintain the uniqueness of Tag 11?