Business Message Rejects from Hubs

, ,
1

Imported from previous forum

2

Hello,

I’m looking for some steer with regards to FIX 3rd Party Hubs and whether or not it violates protocol or accepted convention for Hubs to send Business Message Rejects (j) from themselves. Having checked as many protocol documents as I can find there’s nothing that specifically states this should not be done but I’m thinking that, strictly speaking, a Hub should only be dealing with FIX messages at a session level so any Business Message Rejects it sends should only be on behalf of one of it’s subscribers.

Does anyone have any thoughts on this? Is it likely to ‘confuse’ any OMS’ or engines out there that would not expect a BMR from a hub or, if they received one, would assume 115 would be present in the message?

Many Thanks,
Chris.

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
I do not believe there is any violation of protocol here. However, the behavior of this hub should be clearly specified and understood by its users.

If the hub receives a message with DeliverToCompID=FinalDestination and the hub has no route to FinalDestination, I could easily believe that a BusinessMessageReject is a reasonable response (BusinessRejectReason=7). The only other alternative would be a session level Reject (unless the hub were totally “application aware”). Provided that the BusinessMessageReject contains RefSeqNum and/or BusinessRejectRefID, I would favor it over a session level Reject as it must also contain RefMsgType & BusinessRejectReason. If neither RefSeqNum nor BusinessRejectRefID is present in the BusinessMessageReject, then I would prefer a session level Reject where RefSeqNum is a mandatory field.

I think that the hub should not add OnBehalfOfCompID=FinalDestination, so that the originator of the BusinessMessageReject can be clearly identified as not being FinalDestination.

Will OMSs become confused?

A decent OMS should at least be aware what message is being rejected and thus take the appropriate action. This does depend on the BusinessMessageReject clearly identifying the message being rejected either by RefSeqNum or BusinessRejectRefID (or preferably both).

A bad OMS will probably post all its user account information onto the Internet :slight_smile:

JohnP

Hello,

I’m looking for some steer with regards to FIX 3rd Party Hubs and
whether or not it violates protocol or accepted convention for Hubs to
send Business Message Rejects (j) from themselves. Having checked as
many protocol documents as I can find there’s nothing that specifically
states this should not be done but I’m thinking that, strictly speaking,
a Hub should only be dealing with FIX messages at a session level so any
Business Message Rejects it sends should only be on behalf of one of
it’s subscribers.

Does anyone have any thoughts on this? Is it likely to ‘confuse’ any
OMS’ or engines out there that would not expect a BMR from a hub or, if
they received one, would assume 115 would be present in the message?

Many Thanks, Chris.