BusinessMessageReject or MarketDataRequestReject

, ,
1

Imported from previous forum

2

Hello,

When the MarketDataRequest message is not supported for a certain type of connection (we have STREAM and TRADE type connection), but API user sends such a request anyway, are we supposed to send back a BusinessMessageReject or a MarketDataRequestReject message? (I would say BusinessMessageReject but am not sure.)

Regards,
Gunnar

3

Hi Gunnar,

The theory is that the MarketDataRequestReject would be preferred method of rejecting as a BusinessMessageReject should be used if a message cannot be rejected via any other means. In this case it can be by using the MarketDataRequestReject.

Just make sure that you make the reject reason very clear by combinging 281 and 58 so that your client/counterparty knows they are sending the request down the wrong session/connection.

Jasper

Hello,

When the MarketDataRequest message is not supported for a certain type of connection (we have STREAM and TRADE type connection), but API user sends such a request anyway, are we supposed to send back a BusinessMessageReject or a MarketDataRequestReject message? (I would say BusinessMessageReject but am not sure.)

Regards,
Gunnar

4

Hello Jasper,

Thanks, I understand the reasoning. On the other hand the BusinessMessageReject is for rejecting unsupported message types (BusinessRejectReason = 3), in which case our process also does not have to spend time subtracting the MDReqID from the unsupported message (req’d in the MarketDataRequestReject). But we’ll go with the type of reject message that gets the most votes.

Thanks again,
Gunnar

Hi Gunnar,

The theory is that the MarketDataRequestReject would be preferred method of rejecting as a BusinessMessageReject should be used if a message cannot be rejected via any other means. In this case it can be by using the MarketDataRequestReject.

Just make sure that you make the reject reason very clear by combinging 281 and 58 so that your client/counterparty knows they are sending the request down the wrong session/connection.

Jasper

Hello,

When the MarketDataRequest message is not supported for a certain type of connection (we have STREAM and TRADE type connection), but API user sends such a request anyway, are we supposed to send back a BusinessMessageReject or a MarketDataRequestReject message? (I would say BusinessMessageReject but am not sure.)

Regards,
Gunnar

5

Hi Gunnar,

Taking a step back, looking at this and giving it an extra braincell, the theory below assumes that MD is supported in some way on the session the request is being sent on and therefore a MarketDataRequestReject would be the way forward.

Given that it is not at all, I am going to have to concur that BusinessMessageReject is the correct reject.

Hello Jasper,

Thanks, I understand the reasoning. On the other hand the BusinessMessageReject is for rejecting unsupported message types (BusinessRejectReason = 3), in which case our process also does not have to spend time subtracting the MDReqID from the unsupported message (req’d in the MarketDataRequestReject). But we’ll go with the type of reject message that gets the most votes.

Thanks again,
Gunnar

Hi Gunnar,

The theory is that the MarketDataRequestReject would be preferred method of rejecting as a BusinessMessageReject should be used if a message cannot be rejected via any other means. In this case it can be by using the MarketDataRequestReject.

Just make sure that you make the reject reason very clear by combinging 281 and 58 so that your client/counterparty knows they are sending the request down the wrong session/connection.

Jasper

Hello,

When the MarketDataRequest message is not supported for a certain type of connection (we have STREAM and TRADE type connection), but API user sends such a request anyway, are we supposed to send back a BusinessMessageReject or a MarketDataRequestReject message? (I would say BusinessMessageReject but am not sure.)

Regards,
Gunnar

6

I moved the thread to the FIX Semantics forum as it is not specific to FIX 4.2 and pertains to reject workflows in general.
I agree that BMR is more appropriate when some one sends a message that is not supported at all. Otherwise, one would have to have the capability to format every specific reject message of FIX instead of the generic BMR with BusinessRejectReason=3 (Unsupported Message Type).
Regards,
Hanno.

Hi Gunnar,

Taking a step back, looking at this and giving it an extra braincell, the theory below assumes that MD is supported in some way on the session the request is being sent on and therefore a MarketDataRequestReject would be the way forward.

Given that it is not at all, I am going to have to concur that BusinessMessageReject is the correct reject.

Hello Jasper,

Thanks, I understand the reasoning. On the other hand the BusinessMessageReject is for rejecting unsupported message types (BusinessRejectReason = 3), in which case our process also does not have to spend time subtracting the MDReqID from the unsupported message (req’d in the MarketDataRequestReject). But we’ll go with the type of reject message that gets the most votes.

Thanks again,
Gunnar

Hi Gunnar,

The theory is that the MarketDataRequestReject would be preferred method of rejecting as a BusinessMessageReject should be used if a message cannot be rejected via any other means. In this case it can be by using the MarketDataRequestReject.

Just make sure that you make the reject reason very clear by combinging 281 and 58 so that your client/counterparty knows they are sending the request down the wrong session/connection.

Jasper

Hello,

When the MarketDataRequest message is not supported for a certain type of connection (we have STREAM and TRADE type connection), but API user sends such a request anyway, are we supposed to send back a BusinessMessageReject or a MarketDataRequestReject message? (I would say BusinessMessageReject but am not sure.)

Regards,
Gunnar