Imported from previous forum
The Global Technical Committee met on September 20, 2007 and reviewed the Volatility and EE Committee Market Segmentation Proposal. The specification now enters into a 30 day public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Committee will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.
A link to the Volatility and EE Committee Market Segmentation Proposal can be found at
http://fixprotocol.org/documents/3633/
The Public Comment Period closes on October 25, 2007
[ original email was from Mikael Brännström - m.brannstrom@ngm.se ]
Two comments/questions:
-
What is the motivation of replacing the field “SecurityExchange (207)” with “MarketID”? They both have the same type (Exchange = MIC) and the same meaning (more or less).
-
Shouldn’t the “MarketSegmentID” field be added to several other messages, e.g. “New Order - Single (D)”? I think the “MarketSegmentID” field (and SecurityExchange/MarketID) should affect how a security (order book) is identified.
/Mikael
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Mikael,
The SecurityExchange (207) field was once introduced to qualify the Symbol of a Security - representing the primary place of listing. In orders etc, the ExDestination (100) field specifies the marketplace for execution. We saw it as a mistake that the SecuritytExchange (207) was also added to he “reference data” messages. We also wanted to have a more representative field name (MarketID) to represent the fact that not all markets are exchanges per se.
On using the MarketSegmentID in orders etc. When a single security is traded at different segments or venues, we have not found that anyone includes the MarketSegmentID in orders (etc). While some markets require different FIX connections for different venues, others use separate Symbols or SecurityIDs. We also felt that extending so many FIX messages with the MarketSegmentID would cause lots of breakage.
Regards
Rikard
Two comments/questions:
What is the motivation of replacing the field “SecurityExchange
(207)” with “MarketID”? They both have the same type (Exchange = MIC)
and the same meaning (more or less).Shouldn’t the “MarketSegmentID” field be added to several other
messages, e.g. “New Order - Single (D)”? I think the “MarketSegmentID”
field (and SecurityExchange/MarketID) should affect how a security
(order book) is identified./Mikael
[ original email was from Mikael Brännström - m.brannstrom@ngm.se ]
If MarketSegmentID isn’t needed for qualifying a security when placing an order, why is it needed in SecurityStatus etc?
Regards
Mikael
[…]
On using the MarketSegmentID in orders etc. When a single security is
traded at different segments or venues, we have not found that anyone
includes the MarketSegmentID in orders (etc). While some markets require
different FIX connections for different venues, others use separate
Symbols or SecurityIDs. We also felt that extending so many FIX messages
with the MarketSegmentID would cause lots of breakage.Regards
Rikard
[…]
- Shouldn’t the “MarketSegmentID” field be added to several other
messages, e.g. “New Order - Single (D)”? I think the
“MarketSegmentID” field (and SecurityExchange/MarketID) should
affect how a security (order book) is identified./Mikael
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Mikael,
thanks for a couple of good guestions.
First I’d like to point out that the fields are optional. While some actors (exchanges e.g.) might find them useful, others may not.
The MarketSegmentID (and the MarketID or the SecurityGroup) are applicable as filtering criteria in various Request messages that are used to query or subscribe to reference data. Such filtering criteria are relevant to relay in the corresponding reponse messages too. Many exchanges will use unsolicited feeds instead of query/subscribe, but again the filtering criteria is relevant if separate feeds are used for various segments.
The Security Status (and Trading Session Status) message are not regarded as “reference data” messages by the group behind the proposal, rather they are “state” messages. However, they do relay a dynamic aspect of the entities described in reference data and that is why we included the MarketID and MarketSegmentID in them. And again, filtering is relevant and thereby the inclusion of the filtering fields.
I guess you now wonder why we didn’t include the fields in the Market Data messages? Well, maybe we should have, but Market Data feeds was not an area we prioritized and there already is the concept of “feed types” in there that can be used to partition the market into segments if that if what a publisher wishes.
Regards
Rikard
If MarketSegmentID isn’t needed for qualifying a security when placing
an order, why is it needed in SecurityStatus etc?Regards Mikael
[…]
On using the MarketSegmentID in orders etc. When a single security is
traded at different segments or venues, we have not found that anyone
includes the MarketSegmentID in orders (etc). While some markets
require different FIX connections for different venues, others use
separate Symbols or SecurityIDs. We also felt that extending so many
FIX messages with the MarketSegmentID would cause lots of breakage.Regards
Rikard
[…]
- Shouldn’t the “MarketSegmentID” field be added to several other
messages, e.g. “New Order - Single (D)”? I think the
“MarketSegmentID” field (and SecurityExchange/MarketID) should
affect how a security (order book) is identified./Mikael
I think the GExMC and GTC needs to revisit the premise that MarketID and MarketSegmentID are not required on the order routing messages.