Imported from previous forum
[ original email was from Asim Kaleem - asimletters@yahoo.com ]
Hi,
If a new order hits Sell side with missing tag 60 (using 4.2), what’s the regular way to reject the new order? by sending 35=8,39=8 OR 35=3 ??
Hi, If a new order hits Sell side with missing tag 60 (using 4.2),
what’s the regular way to reject the new order? by sending 35=8,39=8
OR 35=3 ??
Since tag 60 (TransactTime) is a required tag for NewOrderSingle, I would expect a session level Reject message (35=3) here.
Cheers, Jörg
Although you are right in saying that tag 60 is ‘required’ for New Orders but I think it would make more sense to generate a 35=8,39=8 (order reject message). It is stated in FIX 4.2 specs that “As a rule, messages should be forwarded to the trading application for business level rejections whenever possible”. It would be ill-advised to filter out application messages based on tags such as 60 and conditionally required tags such as tag 44. The business application would obviously be more adept to handling such conditions and communicating to the counter-party more descriptively. And in some conditions the business applications may choose to honor messages that would otherwise be stopped at a more constrained FIX session level.
In light of the experiences I have had with various buy and sell side parties, it is preferred that the client be notified straight away whether the order he sent has been rejected. If you generate a session level reject the counter-party would have an outstanding order that has neither been rejected nor acknowledged. Rejecting orders based on session level rejects would needlessly tie in both the application and session level logic; “a recipe for disaster!”. Every implementation has its pros and cons and in the end its upto the implementer to decide what suits him/her most.
Hi, If a new order hits Sell side with missing tag 60 (using 4.2),
what’s the regular way to reject the new order? by sending 35=8,39=8
OR 35=3 ??Since tag 60 (TransactTime) is a required tag for NewOrderSingle, I
would expect a session level Reject message (35=3) here.Cheers, Jörg
Although you are right in saying that tag 60 is ‘required’ for New
Orders but I think it would make more sense to generate a 35=8,39=8
(order reject message). It is stated in FIX 4.2 specs that “As a rule,
messages should be forwarded to the trading application for business
level rejections whenever possible”. It would be ill-advised to filter
out application messages based on tags such as 60 and conditionally
required tags such as tag 44. The business application would obviously
be more adept to handling such conditions and communicating to the counter-
party more descriptively. And in some conditions the business
applications may choose to honor messages that would otherwise be
stopped at a more constrained FIX session level.In light of the experiences I have had with various buy and sell side
parties, it is preferred that the client be notified straight away
whether the order he sent has been rejected. If you generate a session
level reject the counter-party would have an outstanding order that has
neither been rejected nor acknowledged. Rejecting orders based on
session level rejects would needlessly tie in both the application and
session level logic; “a recipe for disaster!”. Every implementation has
its pros and cons and in the end its upto the implementer to decide what
suits him/her most.
If a FIX application sends an order and the order cannot be sent due to a network failures, this must be reported back to the business level. I do not consider this as a needless tying of application and session level logic.
In the same way, a message being rejected due to FIX protocol violations has to be reported back as a failure at the technical/session level. If the FIX engine fails to report back such errors to the business level or the business level is not prepared to deal with this kind of errors, I would regard this as a deficiency of the business application which should be fixed.
Converting session-level Rejects into BusinessRejects, ExecReport(Rejected) etc. may be a quick hack to workaround incomplete business applications, but not a real solution. Actually the business application should be fixed here.
Cheers, Jörg
P.S. See related thread in “General Q/A”
It seems I have not put forward my point clearly enough. As the FIX protocol has matured over the past years, we have seen quite some changes in the successive FIX versions. Lets take the example of tag 60 which is not required in FIX 4.0. It would be a more robust and extensible approach if you build your business application around a FIX protocol neutral platform so that you can have message influx from clients supporting 4.0, 4.1, 4.2 and so on … Then it would not make much sense if you are accepting orders from 4.0 where tag 60 isnt required and rejecting on a session level in the latter versions where it is required. Not to mention the duplication of the validation logic that you would be doing in all those versions.
But after all this if you still want to reject on a session level for all those versions then be my guest. Dont say I warned you 
Although you are right in saying that tag 60 is ‘required’ for New
Orders but I think it would make more sense to generate a 35=8,39=8
(order reject message). It is stated in FIX 4.2 specs that “As a rule,
messages should be forwarded to the trading application for business
level rejections whenever possible”. It would be ill-advised to filter
out application messages based on tags such as 60 and conditionally
required tags such as tag 44. The business application would obviously
be more adept to handling such conditions and communicating to the counter-
party more descriptively. And in some conditions the business
applications may choose to honor messages that would otherwise be
stopped at a more constrained FIX session level.In light of the experiences I have had with various buy and sell side
parties, it is preferred that the client be notified straight away
whether the order he sent has been rejected. If you generate a session
level reject the counter-party would have an outstanding order that
has neither been rejected nor acknowledged. Rejecting orders based on
session level rejects would needlessly tie in both the application and
session level logic; “a recipe for disaster!”. Every implementation
has its pros and cons and in the end its upto the implementer to
decide what suits him/her most.If a FIX application sends an order and the order cannot be sent due to
a network failures, this must be reported back to the business level. I
do not consider this as a needless tying of application and session
level logic.In the same way, a message being rejected due to FIX protocol violations
has to be reported back as a failure at the technical/session level. If
the FIX engine fails to report back such errors to the business level or
the business level is not prepared to deal with this kind of errors, I
would regard this as a deficiency of the business application which
should be fixed.Converting session-level Rejects into BusinessRejects,
ExecReport(Rejected) etc. may be a quick hack to workaround incomplete
business applications, but not a real solution. Actually the business
application should be fixed here.Cheers, Jörg
P.S. See related thread in “General Q/A”