Imported from previous forum
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
Hi there,
I need to publish Market Data events on a given instrument, but the events might take place on different “trading channels” (e.g. main electronic trading system, ex-pit, OTC). Thus, I might end up publishing the same statistics (High, Low, VWAP, etc) multiple times for each channel. In order to avoid spurious overwriting between channels, I need some kind of “channel qualifier” for the market data item. I found MDStreamID (1500) on the market data messages, but from the field description I can’t be sure if this is the use case for it.
Any thoughts on this?
Thanks,
Andrei Goldchleger
Andrei,
I would look into MDFeedType as a generic means to distinguish logical streams that might be on the same physical stream (multicast address). Tag 1683 MDSubFeedType has been added with Extension Pack EP106 to offer further granularity. You could simply define MDFeedType values M/E/O for main, ex-pit and OTC. The data recipients can then easily determine to what kind of data the statistics apply.
Regards,
Hanno.
Hi there,
I need to publish Market Data events on a given instrument, but the
events might take place on different “trading channels” (e.g. main
electronic trading system, ex-pit, OTC). Thus, I might end up publishing
the same statistics (High, Low, VWAP, etc) multiple times for each
channel. In order to avoid spurious overwriting between channels, I need
some kind of “channel qualifier” for the market data item. I found
MDStreamID (1500) on the market data messages, but from the field
description I can’t be sure if this is the use case for it.Any thoughts on this?
Thanks,
Andrei Goldchleger
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
Thanks Hanno,
The only problem is that I might end up coming with multiple logical streams data on a single Incremental message, and MDFeedType is a root level field. This is why I am considering MDStreamID.
Andrei,
I would look into MDFeedType as a generic means to distinguish logical
streams that might be on the same physical stream (multicast address).
Tag 1683 MDSubFeedType has been added with Extension Pack EP106 to offer
further granularity. You could simply define MDFeedType values M/E/O for
main, ex-pit and OTC. The data recipients can then easily determine to
what kind of data the statistics apply.Regards, Hanno.
Hi there,
I need to publish Market Data events on a given instrument, but the
events might take place on different “trading channels” (e.g. main
electronic trading system, ex-pit, OTC). Thus, I might end up
publishing the same statistics (High, Low, VWAP, etc) multiple times
for each channel. In order to avoid spurious overwriting between
channels, I need some kind of “channel qualifier” for the market data
item. I found MDStreamID (1500) on the market data messages, but from
the field description I can’t be sure if this is the use case for it.Any thoughts on this?
Thanks,
Andrei Goldchleger
MDStreamID was specifically added for the FX market. Technically it would work, semantically I would be more explicit. I would rather see your different channels as different “sub-books” where information comes from. MDBookType is on the root level and can denote if you are sending top of book or depth. MDSubBookType is on the entry level and can then distinguish your channels.
Another option is to use the Parties block in the entry group with PartyRole=73=Execution Venue. Tag 1430 VenueType is not part of the market data messages but its valid values could serve as an input for PartyID in your case.
However, I am not sure you are doing yourself a favor by bundling feeds from different logical sources together in a single MDEntry repeating group. As long as all of your users are always entitled to see all information you should be fine but what if you decide to separate things one day? Also, do you have updates for main trading / ex-pit / OTC at the same time? Otherwise they would not end up in the same logical message or even on the same UDP packet on the wire.
Regards,
Hanno.
Thanks Hanno,
The only problem is that I might end up coming with multiple logical
streams data on a single Incremental message, and MDFeedType is a root
level field. This is why I am considering MDStreamID.