Imported from previous forum
A MarketDefinitionRequest can be a snapshot request of all markets and market segments. However the MarketDefinition only pertains information to ONE market segment.
Is this a mistake and the MarketDefinition should have a sequence of Markets or that the MarketDefinition should be fragmented (but in that case there should be a LastFragment field), or have I misunderstood something?
Best regards,
Erik Scholander
The request would lead to a number of MarketDefinition messages to define each market and to define each market segment within each market. The assumption is that an exchange environment would have a pre-defined, permanent stream for this information so that no specific request is needed. If you receive a MarketReportID you have already seen, the information is starting over again.
MarketDefinition was modeled similar to SecurityDefinition which has data on one security only. We felt that there is no need for a MarketList (similar to SecurityList).
Regards,
Hanno.
A MarketDefinitionRequest can be a snapshot request of all markets and
market segments. However the MarketDefinition only pertains information
to ONE market segment.Is this a mistake and the MarketDefinition should have a sequence of
Markets or that the MarketDefinition should be fragmented (but in that
case there should be a LastFragment field), or have I misunderstood
something?Best regards, Erik Scholander
Thank you for your reply Hanno!
I am uncertain what you mean, do you mean that the market structure is expected to be static, and these messages are not intended to convey a dynamic market? Ie it’s expected the recipients know how many marketdefinitions their request is expected to yield and thus information for the fragmentation is not needed?
Perhaps it would be good if there would be some way to convey a dynamic market structure in standard FIX too? By for example having an optional field similar to LastFragment, or a field indicating how many replies can be expected.
The request would lead to a number of MarketDefinition messages to
define each market and to define each market segment within each market.
The assumption is that an exchange environment would have a pre-defined,
permanent stream for this information so that no specific request is
needed. If you receive a MarketReportID you have already seen, the
information is starting over again.MarketDefinition was modeled similar to SecurityDefinition which has
data on one security only. We felt that there is no need for a
MarketList (similar to SecurityList).Regards, Hanno.
A MarketDefinitionRequest can be a snapshot request of all markets and
market segments. However the MarketDefinition only pertains
information to ONE market segment.Is this a mistake and the MarketDefinition should have a sequence of
Markets or that the MarketDefinition should be fragmented (but in that
case there should be a LastFragment field), or have I misunderstood
something?Best regards, Erik Scholander
Possibly, however, markets and their segments are assumed to be very large entities that typically cannot change without regulatory approval. It is a means to electronically sends rules®s of an exchange or marketplace. In case of Deutsche Börse Group, we would have Xetra and Eurex as a market and some kind of segmentation of instruments.
It might change from one business day to the next but I do not foresee this to change as dynamically as you seem to want to use it. What is the background? TotNoXXX and Last Fragment are only if you have to split up a single message (typically with a repeating group) such as SecurityList which can become quite long.
I would expect marketplace documentation to tell you about the markets and their segments and your software can process the details electronically.
But if you have a case for such enhancements, feel free to join a working group and make a proposal and gap analysis to extend the spec.
Regards,
Hanno.
Thank you for your reply Hanno!
I am uncertain what you mean, do you mean that the market structure is
expected to be static, and these messages are not intended to convey a
dynamic market? Ie it’s expected the recipients know how many
marketdefinitions their request is expected to yield and thus
information for the fragmentation is not needed?Perhaps it would be good if there would be some way to convey a dynamic
market structure in standard FIX too? By for example having an optional
field similar to LastFragment, or a field indicating how many replies
can be expected.The request would lead to a number of MarketDefinition messages to
define each market and to define each market segment within each
market. The assumption is that an exchange environment would have a
pre-defined, permanent stream for this information so that no specific
request is needed. If you receive a MarketReportID you have already
seen, the information is starting over again.MarketDefinition was modeled similar to SecurityDefinition which has
data on one security only. We felt that there is no need for a
MarketList (similar to SecurityList).Regards, Hanno.
A MarketDefinitionRequest can be a snapshot request of all markets
and market segments. However the MarketDefinition only pertains
information to ONE market segment.Is this a mistake and the MarketDefinition should have a sequence of
Markets or that the MarketDefinition should be fragmented (but in
that case there should be a LastFragment field), or have I
misunderstood something?Best regards, Erik Scholander
MarketDefinition was modeled similar to SecurityDefinition which has
data on one security only. We felt that there is no need for a
MarketList (similar to SecurityList).
Isn’t SecurityDefinition already used to reply to a request for multiple securities, even though each message only contains information about a single security?
This is for example shown in the document “FIX-5.0_SP1_VOL-3” where it is part of a “Start-of-day flow”. Here a request for securities is made by the participant using SecurityDefinitonRequest and in the diagram SecurityDefintion is sent in response to this request.
How does the participant know how many SecurityDefintions to expect in this scenario?
If MarketDefintion is modeled after SecurityDefinition maybe the same information or mechanism could be used when sending multiple MarketDefinitions in reply to a MarketDefinitionRequest?
You can use SecurityList if you need to know beforehand how many securities to receive. Or you repeat the stream and a lower ID indicates that the stream starts over again.
Mechanisms for SecurityDefinition and MarketDefinition should be pretty much the same. If MarketDefinition lacks something I believe SecurityDefinition lacks it as well.
Regards,
Hanno.
MarketDefinition was modeled similar to SecurityDefinition which has
data on one security only. We felt that there is no need for a
MarketList (similar to SecurityList).Isn’t SecurityDefinition already used to reply to a request for multiple
securities, even though each message only contains information about a
single security?This is for example shown in the document “FIX-5.0_SP1_VOL-3” where it
is part of a “Start-of-day flow”. Here a request for securities is made
by the participant using SecurityDefinitonRequest and in the diagram
SecurityDefintion is sent in response to this request.How does the participant know how many SecurityDefintions to expect in
this scenario?If MarketDefintion is modeled after SecurityDefinition maybe the same
information or mechanism could be used when sending multiple
MarketDefinitions in reply to a MarketDefinitionRequest?