PUBLIC COMMENT PERIOD – MiFID II/MiFIR Extensions Part 1 Proposal

, , , ,
1

Imported from previous forum

2

The GTC has discussed the public review comments above yesterday and will post a response here. In the interest of time it was decided to pre-assign tags and valid values and make them available prior to the actual implementation in the FIX Repository and subsequent publication which also includes an updated version of FIXimate and the Gap Analysis document. We plan to provide the pre-assigned values early next week.

3

Is it possible to provide a timeframe for when these proposals will be finalised - I’m looking to plan internal development and external rollout. Cheers. Col.

4

Feedback on behalf of Deutsche Bank is similar to Fidessa’s - TrdRegPublicationReason should provide the ability to hold all the OTC post-trade indicators rather than a subset.

5

Feedback on behalf of Fidessa to the proposals:

Table 2 / Item 4 (OTC post-trade indicator)

Fidessa opinion is that for purposes of passing this information from a sell-side system to a transaction reporting system the use of 5 different fields (TrdRegPublicationType, TrdType, TrdSubType, SecondaryTrdType,TradePriceCondition) is unnecessarily complex.

Can be it be considered that TrdRegPublicationType is extended to support all pre and post trade indicators required by MiFID?

Table 2 / Item 5 (Client Identifier, Execution Decision, Investment Decision parties)

Fidessa is in agreement with the proposal to add new roles and sources, we do however request publication of the new values as soon as possible.

The proposal to introduce a separate fields (OrderAttributeGrp) to represent AGGR and PNAL makes the processing of Client Identifier far more complex than we’d ideally prefer.

Can it be considered that if using short codes that “AGGR” and “PNAL” are identified via a short code mapping and/or as reserved values?

Table 2 / Item 8 (Liquidity Provision flag)

Fidessa is in agreement with the proposal to add a new OrderAttributeValue.

Can it be considered that the attribute description used is “Liquidity provision activity”, not “Market making strategy order”, so as to align with the name of field 8 in RTS 24?

6

Feedback on behalf of Deutsche Börse Group regarding ESMA fields 4 (Investment decision within firm) and 5 (Execution within firm):

The proposal offers to fill a PartyID field with an actual value or a short code. It does not offer a possibility to leave PartyID empty and instead make an implicit reference to the session context or to a field outside of the Parties component. Actual values can be very long and short codes imply the need for a separate mapping table that needs to be uploaded regularly to the venue and used as a lookup for actual values sent to ESMA.

The main use case for implicit references relates to the fact that some venues already have certain information that does not need to (or simply cannot) be sent on every order. For example, a trading session may be tied to a specific trader that cannot change during the lifetime of the session. An implicit reference to the trader of a session avoids the explicit entry of a party instance on every order and ensures correctness of the value.

Another use case for implicit references is to support the migration from existing fields such as ComplianceID(376) which has so far been used to convey the algorithm identifier.

Valid values for such an indicator could be as follows:
0=None, use value in PartyID (default)
1=Executing firm of session
2=Entering firm of session
3=Executing unit of session
4=Entering unit of session
5=Executing trader of session
6=Entering trader of session
7=ComplianceID
8=???

7

The Global Technical Committee has reviewed and preliminarily approved the MiFID II and MiFIR Extensions Part 1 Proposal. This proposal addresses the Part 1 business requirements from the MiFID II Workshop (September 23, 2016) discussions including input from the Transparency Subgroup and the Order Data and Recordkeeping Subgroup. References considered in the gap analysis include:

Specifically RTS 1, RTS 2, RTS 6, RTS 22, and RTS 24

This gap analysis introduces multiple enhancements to FIX to support MiFID II and MiFIR requirements.

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.fixtradingcommunity.org/pg/file/fplpo/read/3713119/fix-protocol-ga-mifid-ii-mifir-extensions

The public comment period ends on January 9, 2017.

8

Will the proposed Algo order flag AlgorithmicTradeIndicator(2267) be added to NewOrderSingle(35=D)? It is currently used in TradeCaptureReport and there is an action is to add 2667 to ExecutionReport (35=8), but it is not clear if it will also be used in NewOrderSingle.

9

The proposal does not seem to include an “SI indicator flag” on order messages (NewOrderSingle). In the MiFID 2 workshop on 23rd Sep the following FIX protocol change was proposed:

Subject: Order flags – SI
Reference: RTS 1
Change request: Optional flag to identify that an order is being sent from an SI
Comments: To help investment firms with the ‘who reports’ requirement for trade reporting

Are there any plans to add this flag to NewOrderSingle, perhaps using the OrderAttribGrp component?

10

The GTC has now updated the Gap Analysis document and created an ASBUILT version as part of Extension Pack 222 (http://www.fixtradingcommunity.org/pg/extensions/extension-pack?ExtensionID=EP222). It has assigned tag numbers and valid values for new fields and values. The FIX Repository, FIXML Schema and FIX Repository will be updated in due course. The GTC further decided to introduce a number of user-defined fields for EP222 to support regulatory reporting to ESMA for FIX 4.2 users. These will be published shortly under http://www.fixtradingcommunity.org/pg/structure/tech-specs/additional-resources/user-defined-fields/user-defined-fields-tab-4.