Additions to MarketDataRequestReject

, ,
1

Imported from previous forum

2

I would like to propose 4 new MDReqRejReason codes for the MarketDataRequestReject message

D = Use Specified Engine
E = Already Subscribed
F = Subscription Replaced
G = Forced Unsubscribe

D) Use Specified Engine
Used to "reroute" a specific MarketData request to another engine that can handle it.
1) It can be in direct response to a MarketDataRequest – no subscription takes place
2) Can be sent in a subsequent "loss-of-data-feed" scenario – with the engine automatically unsubscribing the affected MDRefReqIDs.

In lieu of a new tag for thefield containing the new "rerouted" connection information, it has to be agreed-on among firms (something like OnBehalfOfCompID, perhaps).

E) Already Subscribed
1) to prevent duplicate subscriptions for the same product
2) to prevent duplicate subscriptions for a product already subscribed for as a part of a larger subscription (option class, etc) containing that product

F) Subscription Replaced
1) to remove duplicate subscriptions for a product upon a larger subscription (option class, etc) containing that product

G) Forced Unsubscribe
1) to allow the engine to remove subscriptions, for throughput, bandwidth, or other reasons, but not for "Use Specified Engine" reasons.

I would also like to add a repeating group to contain the MDReqID’s affected by the MDReqRejReason codes F and G:

NoMDRefReqID – number of affected MDReqID’s
MDRefReqID – affected MDReqID

Thank you,

Dmitry Volpyansky

3

[ original email was from Jim Northey - jnorthey@lasalletech.com ]
Create the redirected engine info in a application level field similar similar to the out of band stuff used in trade capture /postions.

> I would like to propose 4 new MDReqRejReason codes for the MarketDataRequestReject message
>
> D = Use Specified Engine
> E = Already Subscribed
> F = Subscription Replaced
> G = Forced Unsubscribe
>
> D) Use Specified Engine
> Used to “reroute” a specific MarketData request to another engine that can handle it.
> 1) It can be in direct response to a MarketDataRequest – no subscription takes place
> 2) Can be sent in a subsequent “loss-of-data-feed” scenario – with the engine automatically unsubscribing the affected MDRefReqIDs.
>
> In lieu of a new tag for thefield containing the new “rerouted” connection information, it has to be agreed-on among firms (something like OnBehalfOfCompID, perhaps).
>
> E) Already Subscribed
> 1) to prevent duplicate subscriptions for the same product
> 2) to prevent duplicate subscriptions for a product already subscribed for as a part of a larger subscription (option class, etc) containing that product
>
> F) Subscription Replaced
> 1) to remove duplicate subscriptions for a product upon a larger subscription (option class, etc) containing that product
>
> G) Forced Unsubscribe
> 1) to allow the engine to remove subscriptions, for throughput, bandwidth, or other reasons, but not for “Use Specified Engine” reasons.
>
>
> I would also like to add a repeating group to contain the MDReqID’s affected by the MDReqRejReason codes F and G:
>
> NoMDRefReqID – number of affected MDReqID’s
> MDRefReqID – affected MDReqID
>
> Thank you,
>
> Dmitry Volpyansky
>

4

[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The use of a repeating group has been rejected by GTC - each Request ID should be referred to with a separate message.

> I would like to propose 4 new MDReqRejReason codes for the MarketDataRequestReject message
>
> D = Use Specified Engine
> E = Already Subscribed
> F = Subscription Replaced
> G = Forced Unsubscribe
>
> D) Use Specified Engine
> Used to “reroute” a specific MarketData request to another engine that can handle it.
> 1) It can be in direct response to a MarketDataRequest – no subscription takes place
> 2) Can be sent in a subsequent “loss-of-data-feed” scenario – with the engine automatically unsubscribing the affected MDRefReqIDs.
>
> In lieu of a new tag for thefield containing the new “rerouted” connection information, it has to be agreed-on among firms (something like OnBehalfOfCompID, perhaps).
>
> E) Already Subscribed
> 1) to prevent duplicate subscriptions for the same product
> 2) to prevent duplicate subscriptions for a product already subscribed for as a part of a larger subscription (option class, etc) containing that product
>
> F) Subscription Replaced
> 1) to remove duplicate subscriptions for a product upon a larger subscription (option class, etc) containing that product
>
> G) Forced Unsubscribe
> 1) to allow the engine to remove subscriptions, for throughput, bandwidth, or other reasons, but not for “Use Specified Engine” reasons.
>
>
> I would also like to add a repeating group to contain the MDReqID’s affected by the MDReqRejReason codes F and G:
>
> NoMDRefReqID – number of affected MDReqID’s
> MDRefReqID – affected MDReqID
>
> Thank you,
>
> Dmitry Volpyansky
>