Reject message(3) Vs Execution Report for rejects

, ,
1

Imported from previous forum

2

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

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Jayaram,

The good approach to understand is that rejection should be conveyed in the most friendly method possible.

[A perceptive person would see that the above approach works just as well in all aspects of life, not just FIX]

The rejecting application should send ExecReport(rejected) as first choice. If that isn’t possible, send BusinessMessageReject as second choice. If that isn’t possible, send a FIX Session-level Reject.

From the perspective of the application receiving some type of reject, a good versatile application should be prepared to accept any one of these three messages and process it to the best of its ability.

It’s very cold here (NYC) today.

JohnP

4

[ original email was from Carfield Yim - carfield.w.yim@jpmorgan.com ]
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

5

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

6

[ original email was from sonitta peeler - sonitta.peeler@bofasecurities.com ]
Hi,

35=3 is a session level reject, this is not application level reject but engein level, for example if a FIX tag that is required for a spesific msg type is missing, the order will be rejected by the engine.

39=8 is application level reject, orders that are rejected by the trading application.

35=j is also application level reject, not session level.

I hope this helps.

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

7

Hi,

35=3 is a session level reject, this is not application level reject but
engein level, for example if a FIX tag that is required for a spesific
msg type is missing, the order will be rejected by the engine.

39=8 is application level reject, orders that are rejected by the
trading application.

35=j is also application level reject, not session level.

I hope this helps.

Hi,

We have lot of theoritical info for this on different pages in one good liner i would say if something which FIX engine cannot understand( config file of your engine doesn’t know abt it) send 35=3( e.g 35=&)
then if it is a functional mistake and tehir is a code in your system and have a proper error to send a rejection back( e.g. Limit price required for a limit 40=2 order) send 35=8,39=8,150=8,58=text and if their is no code in your application system for something which just somes new and not supported at app level but true at FIX send Business Reject ( 35=j).
The best way to implement this is to have seperate error files in your application and reject pick from that.

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