PUBLIC COMMENT PERIOD – Market Data Extension Proposal

, ,
1

Imported from previous forum

2

The Global Technical Committee has reviewed and preliminarily approved the Market Data Extension proposal. The document now enters a public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Governance Board 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 proposal can be found at:

http://www.fixprotocol.org/documents/4740/FIX%20Protocol%20Gap%20Analysis%20Market%20Data%20Extensions%20v05.doc

The public comment period ends on October 2, 2009.

3

[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Just a naming issue:

The FIX protocol already have messages like ‘Order Mass Status Request’ and ‘Order Mass Action Request’.

The proposed messages ‘Mass Security Status Request’ and ‘Mass Security Status’ should perhaps be renamed to ‘Security Mass Status Request’ and ‘Security Mass Status’ respectively to follow the same naming scheme as existing FIX messages.

4

Valid point, I guess we had looked at MassQuote messages where the “Mass” is the prefix. The existing SecurityStatus also does not have the suffix “Report” like OrderMassXXX has but in this case I would not use it to have the single version in sync with the mass version.

Just a naming issue:

The FIX protocol already have messages like ‘Order Mass Status Request’
and ‘Order Mass Action Request’.

The proposed messages ‘Mass Security Status Request’ and ‘Mass Security
Status’ should perhaps be renamed to ‘Security Mass Status Request’ and
‘Security Mass Status’ respectively to follow the same naming scheme as
existing FIX messages.

5

I agree Mikael’s suggestion is a good one.

6

We are currently working on an implementation at an exchange that, like the ISE, may require the dissemination of market orders in the order book in its market data feed. The support for this requirement proposed in the extension would be most helpful.

I have two questions in this regard:

  1. In terms of the proposed new values for MDEntryType (269), would it be correct to assume that, if the proposal is approved, the values that will be assigned for Market Bid and Market Offer will be “b” and “c” respectively?
  2. What is the recommendation for the MDPriceLevel (1023) of market orders? Is there a need to include a MDPriceLevel (1023) for market orders?
7

I cannot answer your first question as valid values are being issued by FPL in the order in which Extension Packs are being implemented. The values you mention are likely but cannot be guaranteed.

MDPriceLevel is an optional field and can thus be omitted when sending market order information. They do not really belong to a specific price, e.g. level 1 but also level 0 might be confusing for users when implementing MDUpdateAction and shifting entries up or down. I suggest to keep the information separate. MDUpdateAction for market orders would then always be 0=NEW, i.e. you simply overwrite what you have.

We are currently working on an implementation at an exchange that, like
the ISE, may require the dissemination of market orders in the order
book in its market data feed. The support for this requirement proposed
in the extension would be most helpful.

I have two questions in this regard:

  1. In terms of the proposed new values for MDEntryType (269), would it
    be correct to assume that, if the proposal is approved, the values
    that will be assigned for Market Bid and Market Offer will be “b” and
    “c” respectively?
  2. What is the recommendation for the MDPriceLevel (1023) of market
    orders? Is there a need to include a MDPriceLevel (1023) for
    market orders?
8

Thanks for the feedback Hanno.

I presume your suggestion that MDUpdateAction (279) should always be New (0) would only apply if the order book is disseminated by price depth (i.e. quantity at each price point is aggregated). The MDUpdateActions Change (1) and Delete (2) would probably be required for market orders if the order book is disseminated by order depth (i.e. the details of each order is disseminated).

I cannot answer your first question as valid values are being issued by
FPL in the order in which Extension Packs are being implemented. The
values you mention are likely but cannot be guaranteed.

MDPriceLevel is an optional field and can thus be omitted when sending
market order information. They do not really belong to a specific price,
e.g. level 1 but also level 0 might be confusing for users when
implementing MDUpdateAction and shifting entries up or down. I suggest
to keep the information separate. MDUpdateAction for market orders would
then always be 0=NEW, i.e. you simply overwrite what you have.

We are currently working on an implementation at an exchange that,
like the ISE, may require the dissemination of market orders in the
order book in its market data feed. The support for this requirement
proposed in the extension would be most helpful.

I have two questions in this regard:

  1. In terms of the proposed new values for MDEntryType (269), would it
    be correct to assume that, if the proposal is approved, the values
    that will be assigned for Market Bid and Market Offer will be “b”
    and “c” respectively?
  2. What is the recommendation for the MDPriceLevel (1023) of market
    orders? Is there a need to include a MDPriceLevel (1023) for market
    orders?
9

Correct, use Change and Delete to convey new information about existing orders in an order-depth scenario. Please also refer to http://www.fixprotocol.org/documents/4419/MDOWG_Book_Mgt_Final_draft.doc posted to the FPL Global Exchanges & Markets website.

Thanks for the feedback Hanno.

I presume your suggestion that MDUpdateAction (279) should always be New
(0) would only apply if the order book is disseminated by price depth
(i.e. quantity at each price point is aggregated). The MDUpdateActions
Change (1) and Delete (2) would probably be required for market orders
if the order book is disseminated by order depth (i.e. the details of
each order is disseminated).

I cannot answer your first question as valid values are being issued
by FPL in the order in which Extension Packs are being implemented.
The values you mention are likely but cannot be guaranteed.

MDPriceLevel is an optional field and can thus be omitted when
sending market order information. They do not really belong to a
specific price,
e.g. level 1 but also level 0 might be confusing for users when
implementing MDUpdateAction and shifting entries up or down. I
suggest to keep the information separate. MDUpdateAction for
market orders would then always be 0=NEW, i.e. you simply
overwrite what you have.

We are currently working on an implementation at an exchange that,
like the ISE, may require the dissemination of market orders in the
order book in its market data feed. The support for this requirement
proposed in the extension would be most helpful.

I have two questions in this regard:

  1. In terms of the proposed new values for MDEntryType (269), would
    it be correct to assume that, if the proposal is approved, the
    values that will be assigned for Market Bid and Market Offer will
    be “b” and “c” respectively?
  2. What is the recommendation for the MDPriceLevel (1023) of market
    orders? Is there a need to include a MDPriceLevel (1023) for
    market orders?
10

Has FPL assigned values to the new enumerations and fields that were created in terms of this proposal?

I am particularly interested in:
(a) The values for Market Bid and Market Offer which were the new values added to the MDEntryType (269) field.
(b) The tags for the new fields MDSecurityTradingStatus and MDHaltReason.

11

EP106 (Mkt Data Extensions) has not been posted yet due to the complexity of EP105 (Parties Ref Data Extensions) but tags have been assigned. Please check the spec page for FIX 5.0 SP2. It should be posted there in the coming weeks.

Here are the IDs you were looking for (sneak preview…)

MDEntryType (269)
b – Market Bid
c – Market Offer

MDSecurityTradingStatus (1682)
MDHaltReason (1684)

Regards,
Hanno.

Has FPL assigned values to the new enumerations and fields that were
created in terms of this proposal?

I am particularly interested in:
(a) The values for Market Bid and Market Offer which were the new values
added to the MDEntryType (269) field.
(b) The tags for the new fields MDSecurityTradingStatus and
MDHaltReason.