# msg reject in response of new order **URL:** \ **Category:** General Q&A\ **Tags:** 42-changes, xid\_164282, imported\ **Created:** [February 22, 2005, 1:21pm UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919 "2005-02-22T13:21:01Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [February 22, 2005, 1:21pm UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919/1 "2005-02-22T13:21:01Z")
Imported from previous forum ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [February 22, 2005, 1:21pm UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919/2 "2005-02-22T13:21:01Z")
[original email was from Asim Kaleem - [asimletters@yahoo.com](mailto: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 ?? ---
**Author:** ![jorgthonnes](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/jorgthonnes/32/196_2.png) [@jorgthonnes](https://forum.fixtrading.org/u/jorgthonnes)\ **Post date:** [February 22, 2005, 4:05pm UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919/3 "2005-02-22T16:05:23Z")
> 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 ---
**Author:** ![kashifawa\_x](https://avatars.discourse-cdn.com/v4/letter/k/b19c9b/32.png) [@kashifawa\_x](https://forum.fixtrading.org/u/kashifawa_x)\ **Post date:** [February 25, 2005, 10:32am UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919/4 "2005-02-25T10:32:05Z")
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 ---
**Author:** ![jorgthonnes](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/jorgthonnes/32/196_2.png) [@jorgthonnes](https://forum.fixtrading.org/u/jorgthonnes)\ **Post date:** [March 3, 2005, 10:53am UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919/5 "2005-03-03T10:53:55Z")
> 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” ---
**Author:** ![kashifawa\_x](https://avatars.discourse-cdn.com/v4/letter/k/b19c9b/32.png) [@kashifawa\_x](https://forum.fixtrading.org/u/kashifawa_x)\ **Post date:** [March 14, 2005, 10:41am UTC](https://forum.fixtrading.org/t/msg-reject-in-response-of-new-order/11919/6 "2005-03-14T10:41:07Z")
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”