Imported from previous forum
Hi,
The FIX spec says that Business Message Reject can be used to reject a valid FIX business message that fulfills the session-level rules but is not supported by the recipient.
We would like to exclude all FIX messages that we do not support from our FIX repository. This will have the effect that an unsupported FIX message will be rejected using session level Reject message and 373=11 (Invalid MsgType) as we do not recognize the message type.
Is this policy OK or do we always have to include all valid FIX messages in our repository so we can send a Business Message Reject instead for every valid but not supported FIX message?
Regards, Bernt
“valid” fix messages you do not support should be rejected with a business level reject.
Session level reject messages at least in QuickFix as I recall) are dealt with in the session layer, and may not be seen by the application layer - and thus may be incorrectly identified as a connection fault.
Hi,
The FIX spec says that Business Message Reject can be used to reject a
valid FIX business message that fulfills the session-level rules but is
not supported by the recipient.We would like to exclude all FIX messages that we do not support from
our FIX repository. This will have the effect that an unsupported FIX
message will be rejected using session level Reject message and 373=11
(Invalid MsgType) as we do not recognize the message type.Is this policy OK or do we always have to include all valid FIX messages
in our repository so we can send a Business Message Reject instead for
every valid but not supported FIX message?Regards, Bernt
Thanks Jay,
I guess you mean Business Message Reject when you say business level reject?
“valid” fix messages you do not support should be rejected with a
business level reject.Session level reject messages at least in QuickFix as I recall) are
dealt with in the session layer, and may not be seen by the application
layer - and thus may be incorrectly identified as a connection fault.Hi,
The FIX spec says that Business Message Reject can be used to reject a
valid FIX business message that fulfills the session-level rules but
is not supported by the recipient.We would like to exclude all FIX messages that we do not support from
our FIX repository. This will have the effect that an unsupported FIX
message will be rejected using session level Reject message and 373=11
(Invalid MsgType) as we do not recognize the message type.Is this policy OK or do we always have to include all valid FIX
messages in our repository so we can send a Business Message Reject
instead for every valid but not supported FIX message?Regards, Bernt
Since you “do not support” that message type, that means that messages is “invalid” based on your spec. Your repository should be consistent with your spec, and hence naturally a session level Reject with 373=11
(Invalid MsgType) if the way to go.
That’s assuming that you do have your own published spec – otherwise you wouldn’t even be able to define “supported” or “unsupported”, and it’d be a different game.
Just my two cents…
Hi,
The FIX spec says that Business Message Reject can be used to reject a
valid FIX business message that fulfills the session-level rules but is
not supported by the recipient.We would like to exclude all FIX messages that we do not support from
our FIX repository. This will have the effect that an unsupported FIX
message will be rejected using session level Reject message and 373=11
(Invalid MsgType) as we do not recognize the message type.Is this policy OK or do we always have to include all valid FIX messages
in our repository so we can send a Business Message Reject instead for
every valid but not supported FIX message?Regards, Bernt
And idealy your client should be made aware of this via the initial on-boarding or rule-of-engagement process.
Since you “do not support” that message type, that means that messages
is “invalid” based on your spec. Your repository should be consistent
with your spec, and hence naturally a session level Reject with 373=11
(Invalid MsgType) if the way to go.That’s assuming that you do have your own published spec – otherwise
you wouldn’t even be able to define “supported” or “unsupported”, and
it’d be a different game.Just my two cents…
Hi,
The FIX spec says that Business Message Reject can be used to reject a
valid FIX business message that fulfills the session-level rules but
is not supported by the recipient.We would like to exclude all FIX messages that we do not support from
our FIX repository. This will have the effect that an unsupported FIX
message will be rejected using session level Reject message and 373=11
(Invalid MsgType) as we do not recognize the message type.Is this policy OK or do we always have to include all valid FIX
messages in our repository so we can send a Business Message Reject
instead for every valid but not supported FIX message?Regards, Bernt
While I agree wholeheartedly with everything written here, I have to wonder under what circumstances one would expect to use a BusinessMessageReject Unsupported Message Type.
And idealy your client should be made aware of this via the initial on-boarding or rule-of-engagement process.
Since you “do not support” that message type, that means that messages
is “invalid” based on your spec. Your repository should be consistent
with your spec, and hence naturally a session level Reject with 373=11
(Invalid MsgType) if the way to go.That’s assuming that you do have your own published spec – otherwise
you wouldn’t even be able to define “supported” or “unsupported”, and
it’d be a different game.Just my two cents…
Hi,
The FIX spec says that Business Message Reject can be used to reject a
valid FIX business message that fulfills the session-level rules but
is not supported by the recipient.We would like to exclude all FIX messages that we do not support from
our FIX repository. This will have the effect that an unsupported FIX
message will be rejected using session level Reject message and 373=11
(Invalid MsgType) as we do not recognize the message type.Is this policy OK or do we always have to include all valid FIX
messages in our repository so we can send a Business Message Reject
instead for every valid but not supported FIX message?Regards, Bernt
Most FIX interfaces always only support a small subset of the now over 100 possible message types. You would use the BMR to reject a valid but unsupported message type. You need the FIX repository to determine that it is valid. If one strips it down to the supported subset (which many do) then the distinction between invalid and unsupported is no longer possible.
While I agree wholeheartedly with everything written here, I have to wonder under what circumstances one would expect to use a BusinessMessageReject Unsupported Message Type.