Market Data Request and TradingSessionID

, ,
1

Imported from previous forum

2

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
In reviewing comments on the 4.2 protocol, a question arose regarding the placement of TradingSessionID. As this affects multiple working groups, I felt it best to post here.

The issue is that Market Data Request has a repeating group beginning with "NoRelatedSym" and used to list securities for which one is requesting data. The TradingSessionID is part of this group.

This means that the ID of the trading session is logically related to the security. I.e. one is saying "I want MSFT in the Pre-Market session,
and CSCO in the Main session." This makes it difficult to get data for multiple sessions in one request, unless one repeats symbols, i.e. says "I want MSFT in the Pre-Market session, MSFT in the Main session, CSCO in the Pre-Market session, and CSCO in the Main session."

This seems counter-intuitive. I have been thinking that for FIX 4.3 it may be better to make TradingSessionID part of a new repeating group in that message where it is the only member. So one would say "I want securities MSFT and CSCO, for trading sessions Pre-Market and Main."

Note that this ONLY applies to Market Data Request. The responses (Market Data - Snapshot/Full Refresh and Market Data - Incremental Refresh) are unaffected. Also, unsolicited data streams not involving sending a request are likewise unaffected.

The gain here is that it is simpler. The same TradingSessionID list is applied to all securities in the request, so the data does not have to be repeated with every security, or cause people to duplicate securities in their request just to get data for multiple sessions. Of course this also makes certain types of requests (i.e. "MSFT Pre-Market, CSCO Main") impossible in a single request message.

My feeling is that the most good would be done by making TradingSessionID its own repeating group in the FIX 4.3 Market Data Request. It streamlines the more common case, and the above uncommon case could be handled by sending two requests.

Thoughts?