[This message was posted by Hanno Klein of Deutsche Börse Systems <[email protected]> to the "4.4 Changes" discussion forum at http://fixprotocol.org/discuss/17. You can reply to it on-line at http://fixprotocol.org/discuss/read/f0b69a2b - PLEASE DO NOT REPLY BY MAIL.]
The section on Business Message Reject starts of by defining a pre-requisite and a priority: "The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means." a) Pre-requisite: session-level rules are fulfilled b) Priority: application-level messages come first The question is thus about the scope of session-level rules which I would see defined (at least) by the content of tag 373 SessionRejectReason. A failure of a session-level rule should not be visible above the session layer which can be handled by a FIX engine. The first example carries an order type value (40=200) undefined by FIX. The tag does not allow user defined values and is of data type char. Bottom line is that the FIX semantic is missing here, it is a technical error and can be dealt with at the session level. This allows the application level to make the assumption that it will not have to handle ill-formed messages that are inconsistent with the FIX repository. I see a value in being able to make this assumption. The second example is different as the FIX semantic is available, i.e. a stop limit order. The standard FIX engine has no reason to reject this as it should not have knowledge on how this well-formed FIX message is used by one or more subsequent applications. That is why I believe a session level reject is inappropriate here. I do not want to touch my session layer when I decide to support stop limit orders one day. The question for the second example remains as Business Message Reject (BMR) vs Execution Report (ER). Priority is given to ER and BMR it simply the backup if the ER cannot convey the answer. The ER has tag 103 OrdRejReason which I believe is capable enough. Thus I would exclude the BMR as an option. Tag 103 has two values that could fit, i.e. 0=Broker/Exchange option and 99=Other. They both seem valid but are meaningless without adding tag 58 Text as explanation. Maybe the second example deserves its own enum value for tag 103, e.g. "Functionality not supported" with tag 58 again giving details. Regards, Hanno. > Instead I would think both should send 35=8 , as per my understand of > page 146, Business Message Reject, section. > > I believe 35=3 should be used between fix engines level > communication instead. > > > Hi, > > > > Could someone please clarify, when do we use (35=3)/(35=8)/(35=j) > > to reject an order.Please see examples below. > > > > 1.Place an order(35=D) with orderType 40=200,which is not a valid > > value as per FIX standards, So in this case I would expect 35=3 > > ,with 373 = 5(Value is incorrect for this tag).I beleive this is > > correct in rejecting at session level. > > > > 2.Place an order(35=D) with OrderType 40=4(Stop Limit), which is a > > valid value as per FIX standard, but what if FIX client does not > > support this,do we expect 35=3(with 373=5) or 35=8(with 39=8,150=8, > > 103=0,58=Order Type not recognized) or 35=j(with 380=0,58=OrderType > > not recognized).In this case, I wouldn't expect 35=3 since it passes > > session level, but fails at application level.So once at application > > level, which one would you prefer to use (35=j) or (35=8). > > > > FIX protocol says use 35=j when no other message can be used to > > report reject at application level. > > > > Any help on this would be appreciated. > > > > Thanks, Jayaram [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
