Imported from previous forum
In Fix v4.0, if my fix engine receives a 35=D request on an existing previously used ClOrdID, what should the appropriate response be? Thanks K.G.
K.G.
I would recommend to send an execution report 35=8 with ordstatus 39=8 rejected.
The reason I recommend this is because the order initiator might otherwise still have an order on their system that is waiting for a response.
In Fix v4.0, if my fix engine receives a 35=D request on an existing
previously used ClOrdID, what should the appropriate response be?
Thanks K.G.
K.G.
I would recommend to send an execution report 35=8 with ordstatus
39=8 rejected.The reason I recommend this is because the order initiator might
otherwise still have an order on their system that is waiting for
a response.
Starting with FIX 4.1, there is an OrdRejReason=6 (Duplicate Order), which could be used to provide extra information. FIX 4.0 does not define this code, but maybe you could use it anyway.
Cheers, Jörg
In Fix v4.0, if my fix engine receives a 35=D request on an existing
previously used ClOrdID, what should the appropriate response be?
Thanks K.G.
[ original email was from Nick Wright - nick.wright@drkw.com ]
K.G.
The best thing to do would be to reject the order, maybe adding some comment to the text field identifying the ClOrdID as a duplicate.
It is worth remembering that the FIX protocol suggests that any multi-day orders have an embedded date in the ClOrdID to ensure uniqueness across multiple days. However, Day orders only have to have a ClOrdID that is unique for that day. This means that you could receive the same value again the following day.
I know of several buy-side firms who reset their ClOrdID back to 1 during their end of day cycle.
For these clients we add the date to the ClOrdID in our FIX engine before passing on the the OMS for execution. This is then stripped off before returning the execution reports to the client.
Regards,
Nick.
K.G.
I would recommend to send an execution report 35=8 with ordstatus 39=8
rejected.The reason I recommend this is because the order initiator might
otherwise still have an order on their system that is waiting for a
response.Starting with FIX 4.1, there is an OrdRejReason=6 (Duplicate Order),
which could be used to provide extra information. FIX 4.0 does not
define this code, but maybe you could use it anyway.Cheers, Jörg
In Fix v4.0, if my fix engine receives a 35=D request on an existing
previously used ClOrdID, what should the appropriate response be?
Thanks K.G.
[ original email was from Mohamed Kasim - kasim@opussoft.com ]
I think sending 35=3 message (Session level rejection) similar to handling any malformed message with the SessionRejectReason (373=6) Incorrect data format for value.
#1. Fix engines generally will have implementation to expect 35=3 as one of the possible response for their request.
#2. Assuming the clordid is duplicated due to some issues not intended, there might already a valid order exist on the sender side with the same clordid.
In such case, 35=8 response with this clordid might get mapped to the earlier order. That order might wrongfully termed as rejected. So sending 35=8 response might throw up another error in the counter party side
cheers… Kasim
msmkasim@gmail.com
www.ften.com
K.G.
The best thing to do would be to reject the order, maybe adding some
comment to the text field identifying the ClOrdID as a duplicate.It is worth remembering that the FIX protocol suggests that any multi-
day orders have an embedded date in the ClOrdID to ensure uniqueness
across multiple days. However, Day orders only have to have a ClOrdID
that is unique for that day. This means that you could receive the same
value again the following day.I know of several buy-side firms who reset their ClOrdID back to 1
during their end of day cycle. For these clients we add the date to
the ClOrdID in our FIX engine before passing on the the OMS for
execution. This is then stripped off before returning the execution
reports to the client.Regards,
Nick.
K.G.
I would recommend to send an execution report 35=8 with ordstatus
39=8 rejected.The reason I recommend this is because the order initiator might
otherwise still have an order on their system that is waiting for a
response.Starting with FIX 4.1, there is an OrdRejReason=6 (Duplicate Order),
which could be used to provide extra information. FIX 4.0 does not
define this code, but maybe you could use it anyway.Cheers, Jörg
In Fix v4.0, if my fix engine receives a 35=D request on an
existing previously used ClOrdID, what should the appropriate
response be? Thanks K.G.
Hi Kasim,
I think sending 35=3 message (Session level rejection) similar to
handling any malformed message with the SessionRejectReason (373=6)
Incorrect data format for value.
IMHO, this is the wrong way to handle it. It mixes up session level and application level.
#1. Fix engines generally will have implementation to expect 35=3 as
one of the possible response for their request.
True, BUT this is clearly an application level error, which should be handled at the application level (ie. by message specific rejects codes/message or a general BusinessReject).
#2. Assuming the clordid is duplicated due to some issues not
intended, there might already a valid order exist on the sender side
with the same clordid.
In such case, 35=8 response with this clordid might get mapped to the
earlier order. That order might wrongfully termed as rejected. So
sending 35=8 response might throw up another error in the counter
party side
OK, in this case it is important to check the OrdRejReason (which exists since FIX 4.1). If it is “duplicate ClOrdID”, then the already existing order should not be affected.
Actually, this is an important point: The client side should be able to know the difference between “duplicate ClOrdID” and any other error. If you rely on the FIX 4.0 provided codes 0-5, you have to put some indication into the 58=Text field.
Cheers, Jörg
First of all, THANK YOU all for all responses on this matter.
Kasim’s point below (35=3) is specifically what I’m getting at. Certainly, in Fix 4.1 and higher, the specs have outlined specific response behaviour that works, and I have no issues with my 4.1, 4.2 connections.
My problem is that on my 4.0 connections, I’m experiencing the exact problematic scenario Kasim outlines in #2 below: 35=8, 39=8 rejects any previous references to the same tag 11, resulting in some cases with a live order being silently killed by the FIX engine, whilst in fact there are open shares on the order still live on the exchange.
From a technical perspective, and certainly from the 4.0 spec, 35=8,39=8 is the way to go as this is business-related info, as Jorg states below. However, I’m wondering if in fact a 35=3 reject may handle this scenario better?
Cheers
K.G
Hi Kasim,
I think sending 35=3 message (Session level rejection) similar to
handling any malformed message with the SessionRejectReason (373=6)
Incorrect data format for value.IMHO, this is the wrong way to handle it. It mixes up session level and
application level.#1. Fix engines generally will have implementation to expect 35=3 as
one of the possible response for their request.True, BUT this is clearly an application level error, which should be
handled at the application level (ie. by message specific rejects
codes/message or a general BusinessReject).#2. Assuming the clordid is duplicated due to some issues not
intended, there might already a valid order exist on the sender side
with the same clordid. In such case, 35=8 response with this clordid
might get mapped to the earlier order. That order might wrongfully
termed as rejected. So sending 35=8 response might throw up another
error in the counter party sideOK, in this case it is important to check the OrdRejReason (which exists
since FIX 4.1). If it is “duplicate ClOrdID”, then the already existing
order should not be affected.Actually, this is an important point: The client side should be able to
know the difference between “duplicate ClOrdID” and any other error. If
you rely on the FIX 4.0 provided codes 0-5, you have to put some
indication into the 58=Text field.Cheers, Jörg
My problem is that on my 4.0 connections, I’m experiencing
the exact problematic scenario Kasim outlines in #2 below: 35=8, 39=8
rejects any previous references to the same tag 11, resulting in some
cases with a live order being silently killed by the FIX engine, whilst
in fact there are open shares on the order still live on the exchange.
From a technical perspective, and certainly from the 4.0 spec,
35=8,39=8 is the way to go as this is business-related info, as Jorg
states below. However, I’m wondering if in fact a 35=3 reject may
handle this scenario better?
OK, as there is no 4.0 compliant way to handle the case of a duplicate ClOrdID, you have two options:
(1) Use some extra user-defined tag or special indication in the 58=Text field. In this case, the client side has to be aware of this special indication and treat the order as still being alive.
(2) You use Reject as suggested. The other side will see that the message is invalid, but treat the order as still being alive, ie it does not change the order state.
The advantage of (2) is clearly, that it would be also work with clients, which are not tailored to handle duplicate ClOrdID specifically.
On the other hand, (1) seems to be a bit more compliant to the FIX way.
But this is not an excuse to accept that the client miss any live orders.
So I would suggest to go with (2) to be on the save side.
Cheers, Jörg
[ original email was from Mohamed Kasim - kasim@opussoft.com ]
> > My problem is that on my 4.0 connections, I’m experiencing the exact
problematic scenario Kasim outlines in #2 below: 35=8, 39=8 rejects
any previous references to the same tag 11, resulting in some cases
with a live order being silently killed by the FIX engine, whilst in
fact there are open shares on the order still live on the exchange.
From a technical perspective, and certainly from the 4.0 spec,
35=8,39=8 is the way to go as this is business-related info, as Jorg
states below. However, I’m wondering if in fact a 35=3 reject may
handle this scenario better?OK, as there is no 4.0 compliant way to handle the case of a duplicate
ClOrdID, you have two options:(1) Use some extra user-defined tag or special indication in the 58=Text
field. In this case, the client side has to be aware of this special
indication and treat the order as still being alive.(2) You use Reject as suggested. The other side will see that the
message is invalid, but treat the order as still being alive, ie it
does not change the order state.The advantage of (2) is clearly, that it would be also work with
clients, which are not tailored to handle duplicate ClOrdID
specifically.On the other hand, (1) seems to be a bit more compliant to the FIX
way. But this is not an excuse to accept that the client miss any
live orders.So I would suggest to go with (2) to be on the save side.
Cheers, Jörg
Hi
In FIX 4.0 , method (2) is workable. But in the later version say 4.3 and above, this can be clearly demarcated with 150= and 39= field.
#1. Fix as suggested by Jorg in point(2) for rejects.
#2. Fix the generation of clordid logic to avoid any duplicates (looks you get them regular which is abnormal).
#3. When you upgrade FIX to higher versions, follow FIX recommendations to use 150= and 39= field, where 150=8 tells the message rejection and 39= retains the original order’s status. This way the original order do not get changed.
hmm… When thinking of this scenario, I wonder what will happen to the request with duplicate order id. That is a bug in the system and will hopefully not create a second order in the order book which never exist in the exchange.
cheers… Kasim
msmkasim@gmail.com
www.ften.com