Imported from previous forum
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
If a participant sends in a request type message with an unsupported enumeration/option should the message be rejected outright?
As example, lets say the participant sends in a MarketDataRequest with a MarketDepth <264> value of ‘0 = full book depth’. If the ROE states we support only a value of ‘1 = top of book’ then should we reject or send them what we say we provide? (could be dangerous in some cases).
In general should a request be rejected if the inbound message contains an unsupported enumeration/option?
If the RoE reduce the list of valid values, it needs to be the application layer that rejects it, not the session layer (FIX Engine).
Your case is easy, i.e. send a MarketDataRequestReject with 281 MDReqRejReason = 5 = Unsupported MarketDepth.
You can choose in your RoE to interpret unsupported values in some other way and not reject the requets but I would caution against that.
If a participant sends in a request type message with an unsupported enumeration/option should the message be rejected outright?
As example, lets say the participant sends in a MarketDataRequest with a MarketDepth <264> value of ‘0 = full book depth’. If the ROE states we support only a value of ‘1 = top of book’ then should we reject or send them what we say we provide? (could be dangerous in some cases).
In general should a request be rejected if the inbound message contains an unsupported enumeration/option?
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
I guess for most implementations though (ours included) it would be more efficient to reject it at the front door rather than pass it across to the Business tier.
If the RoE reduce the list of valid values, it needs to be the application layer that rejects it, not the session layer (FIX Engine).
Your case is easy, i.e. send a MarketDataRequestReject with 281 MDReqRejReason = 5 = Unsupported MarketDepth.
You can choose in your RoE to interpret unsupported values in some other way and not reject the requets but I would caution against that.
If a participant sends in a request type message with an unsupported enumeration/option should the message be rejected outright?
As example, lets say the participant sends in a MarketDataRequest with a MarketDepth <264> value of ‘0 = full book depth’. If the ROE states we support only a value of ‘1 = top of book’ then should we reject or send them what we say we provide? (could be dangerous in some cases).
In general should a request be rejected if the inbound message contains an unsupported enumeration/option?
Your “front door” can issue a MarketDataRequestReject if you want to reject it as early as possible. The user does not really care which component in your infrastructure creates the response. You might face challenges if you are missing required information at the point where you want to create the response.
I guess for most implementations though (ours included) it would be more efficient to reject it at the front door rather than pass it across to the Business tier.
If the RoE reduce the list of valid values, it needs to be the application layer that rejects it, not the session layer (FIX Engine).
Your case is easy, i.e. send a MarketDataRequestReject with 281 MDReqRejReason = 5 = Unsupported MarketDepth.
You can choose in your RoE to interpret unsupported values in some other way and not reject the requets but I would caution against that.
If a participant sends in a request type message with an unsupported enumeration/option should the message be rejected outright?
As example, lets say the participant sends in a MarketDataRequest with a MarketDepth <264> value of ‘0 = full book depth’. If the ROE states we support only a value of ‘1 = top of book’ then should we reject or send them what we say we provide? (could be dangerous in some cases).
In general should a request be rejected if the inbound message contains an unsupported enumeration/option?