TAG 128 in the SessionReject message (TAG 35 = 3)

, ,
1

Imported from previous forum

2

When an Order Request is placed as an agency and is rejected with a Session Reject message. Should TAG 128 be sent in the Session
Reject message (TAG 35 = 3). Or is it required?

Any kind of information or suggestions will be appreciated.

Many Thanks in advance
Ravi A

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
> When an Order Request is placed as an agency and is rejected with a Session Reject message. Should TAG 128 be sent in the Session
> Reject message (TAG 35 = 3). Or is it required?
>
> Any kind of information or suggestions will be appreciated.
>
> Many Thanks in advance
> Ravi A
>

Hi Ravi,

The first issue is whether a session-level Reject message should be generated at all. There two other options if the message being generated is as a result of an application receiving bad details in a NewOrderSingle message:

  1. The best choice is for the application to respond with an ExecutionReport with OrdStatus(tag 39)= rejected(value 8).
  2. If that is not possible, the next best choice if you are using FIX.4.2 or later is for the application to respond with a BusinessMessageReject.

If neither of the above are possible, then a session-level Reject message is the only other choice. Note that if you are using FIX.4.2 and later, a session-level Reject should only be sent by the FIX engine when a disastrous message is received. It should not be generated by the application at all, which should really be using a BusinessReject message instead.

Nonetheless, whatever message you choose to use as a "bad" response to a NewOrderSingle, the choice of what fields you put into the message header is still the issue.

In my humble opinion, your application should attempt to generate a header in the best way possible. This means if you receive a SenderSubID, your response should contain the same value in TargetSubID. Similarly, if you receive a message that contains OnBehalfOfCompID, your response should contain the same value in DeliverToCompID. And so on, with the many fields that should be "echoed" back in the header of the response.

Lastly, I think that a session-level Reject being generated by a FIX engine (not the application layer) as a response to a catastrophic message having been received, the above may not apply. It is perfectly possible that the application layer may be abusing the standards and sending a date in SenderSubID, which it expects then to see a price returned in SenderLocationID or something equally crazy. So a session-level Reject generated by a FIX engine may choose not to populate the "extra information" fields in the header for fear of breaking a badly behaving application at the other end. In this case, the header need only contain the minimum required fields.

I hope this helps.

4

> > When an Order Request is placed as an agency and is rejected with a Session Reject message. Should TAG 128 be sent in the Session
> > Reject message (TAG 35 = 3). Or is it required?
> >
> > Any kind of information or suggestions will be appreciated.
> >
> > Many Thanks in advance
> > Ravi A
> >
>
> Hi Ravi,
>
> The first issue is whether a session-level Reject message should be generated at all. There two other options if the message being generated is as a result of an application receiving bad details in a NewOrderSingle message:
>
> 1. The best choice is for the application to respond with an ExecutionReport with OrdStatus(tag 39)= rejected(value 8).
> 2. If that is not possible, the next best choice if you are using FIX.4.2 or later is for the application to respond with a BusinessMessageReject.
>
> If neither of the above are possible, then a session-level Reject message is the only other choice. Note that if you are using FIX.4.2 and later, a session-level Reject should only be sent by the FIX engine when a disastrous message is received. It should not be generated by the application at all, which should really be using a BusinessReject message instead.
>
> Nonetheless, whatever message you choose to use as a "bad" response to a NewOrderSingle, the choice of what fields you put into the message header is still the issue.
>
> In my humble opinion, your application should attempt to generate a header in the best way possible. This means if you receive a SenderSubID, your response should contain the same value in TargetSubID. Similarly, if you receive a message that contains OnBehalfOfCompID, your response should contain the same value in DeliverToCompID. And so on, with the many fields that should be "echoed" back in the header of the response.
>
> Lastly, I think that a session-level Reject being generated by a FIX engine (not the application layer) as a response to a catastrophic message having been received, the above may not apply. It is perfectly possible that the application layer may be abusing the standards and sending a date in SenderSubID, which it expects then to see a price returned in SenderLocationID or something equally crazy. So a session-level Reject generated by a FIX engine may choose not to populate the "extra information" fields in the header for fear of breaking a badly behaving application at the other end. In this case, the header need only contain the minimum required fields.
>
> I hope this helps.
>
Hi John,

Thank you, the information was really helpful.

Thanks once again
Ravi