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

, , , ,
1

Imported from previous forum

2

The Global Technical Committee has reviewed and preliminarily approved the MiFID II and MiFIR Extensions Part 2 Proposal. This proposal addresses the Part 2 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:

  1. FIX Trading Community - MiFID II Workshop September 23rd, 2016 Minutes (Dated October 10, 2016)
  2. ESMA RTS documents reference via this link: http://ec.europa.eu/finance/securities/docs/isd/mifid/its-rts-overview-table_en.pdf
    Specifically RTS 1, RTS 2, RTS 6, RTS 22, and RTS 24
  3. MiFID II: Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Directive 2002/92/EC and Directive 2011/61/EU http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1472752877422&uri=CELEX:32014L0065
  4. MiFIR: Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012. http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0600

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/3788923/fix-protocol-ga-mifidmifir-ii-extension-proposal-part-2

The public comment period ends on March 13, 2017.

3

Hello - I’m looking at row 3 in the proposed solution and note the following four values:
GTC proposes a new field expressly devoted to instructing venue type for an order. It is independent of ExDestination(100) and can be used with or without a value there.
ExDestinationType(tbd)
0 = No trading venue restriction
1 = Can be traded only on a trading venue
2 = Can be traded only on a Systematic Internaliser (SI)
3 = Can be traded on a trading venue or Systematic Internaliser (SI)

I think we’re missing an ‘only’ in value 3 (i.e. can be traded only on…).

Jim.

4

Hi, I’ve noticed that the proposal is for firms to identify on ER’s whether or not they are an SI based on a LastMkt value of ‘SINT’.

This will cause problems from an FCA transaction reporting perspective where firms are required to report the SI MIC code of the firm who has supplied with them the execution.

"RTS 22 – Transaction reporting field 36: Venue

Use the ISO 10383 segment MIC for transactions executed on a trading venue, Systematic Internaliser (SI) or organised trading platform outside of the Union.

Where the segment MIC does not exist, use the operating MIC.

Use MIC code ‘XOFF’ for financial instruments admitted to trading, or traded on a trading venue or for which a request for admission was made, where the transaction on that financial instrument is not executed on a trading venue, SI or organised trading platform outside of the Union, or where an investment firm does not know it is trading with another investment firm acting as an SI. Use MIC code ‘XXXX’ for financial instruments that are not admitted to trading or traded on a trading venue or for which no request for admission has been made and that are not traded on an organised trading platform outside of the Union but where the underlying is admitted to trading or traded on a trading venue."
It was our understanding that firm would use the MIC code supplied by the broker to determine whether or not it belongs to an SI based on reference data. Alternatively, a separate field or flag could be sent to identify whether the execution came from an SI.

5

Robbie,

you can use the Parties component to additionally convey the MIC of the SI. Or you can do it the other way around. Put the SI MIC into LastMkt and use MatchType(574) = 9 (systematic internaliser) to flag the fact that the execution happened on an SI. Only the specific message to ESMA needs to contain “SINT” in the ESMA field called “Venue of execution” for the case described above. Your FCA transaction reporting can have both types of information.

FIX has intentionally not taken the approach to map ESMA fields 1:1 to FIX fields. ESMA has often mixed multiple elements into a single field whereas the FIX paradigm is to have a clear semantic scope for each field. It allows a cleaner modelling of FIX messages but requires more effort when mapping to ESMA messages.

Regards,
Hanno.

6

Thanks the reply Hanno.

I think we need a consistent approach across the industry from a Transparency perspective, where the use of MatchType to identify that the execution happened on an SI should be discouraged as this could cause complications for firms when setting the MatchType indicator to SI on their own SI trade reports.

Owning to the fact that parties component is not widely used to identify the LastMkt, would the better approach here be to introduce a new indicator on executions to identify that the execution has originated from an SI rather than trying to fit this into the one field which is used for multiple purposes?

7

Hi Hanno,

Having discussed this further internally today, it is clear to us how investments firms should identify on execution reports that a transaction has been executed on an investment firms SI (via providing their SI MIC code in LastMkt)

What is not clear however is the suggested approach by FIX to identify on execution reports whether or not an investment firm is an SI in the instrument being traded on OTC transactions.

Will FIX be providing guidance for firms on their suggested approach to identify this? Perhaps this is one for us to discuss further with the transparency working group.

Best Regards,
Robbie

8

Yes I think we actually have two requirements here:
1 The ‘reporting MIC’ (perhaps using PartyRole 16 ‘executing system’ for XOFF or the SI MIC) which would go on terminal-state order messages
2 Something on the order ack (and, optionally, subsequent execution report messages) to state whether the broker is an SI in the instrument on the order. I’ll raise this on the iMeet discussion

9

Thanks Jim.

I think it is worth pointing out that the trade reporting Match-Type / MIC (XOFF, SINT or On-Exchange) should be defined by the firm who is submitting the trade report. For example, if an investment firm executed a client order on their own SI, then they would set MatchType to ‘SI’ on their trade report. However if a firm executed a client order with another broker, then our understanding is the MatchType should be set to ‘OTC’ on the trade report.

If we had some way to convey the SI status of client on the subsequent execution report(s), then this could perhaps remove the requirement for having another reporting MIC where LastMkt could be used as per the guidance in RTS 22 – Transaction reporting field 36: Venue. This also assumes we have something which covers the 2nd requirement you listed above.

10

Hi, Part 1 has the RegulatoryTradeIDGrp added to Execution Report messages (35=8), but in Part 2 this has been removed. Are we therefore supposed to use 527 to send the ExecID of the venue to clients? And this group to be used for Trade Reporting only?

11

Natasha, what has led you to believe Part 2 removed RegulatoryTradeIDGrp? It may not be shown but has certainly not been removed. The message tables in Chapter 5 only show what is needed for the given Gap Analysis (see rows that say “Truncated…”). It could be that we forgot a new row in between shown rows. Please let us know if that is the case. Thanks.

12

Thanks Hanno, If this is the case, in order to send a client the ExecID of the venue, we already have a tag 527. Do you know why this is not being used for 35=8? I understand RegulatoryTradeIDGrp being used for Trade Reports, but for an execution to a client, would 527 not be more suited as its already used.

13

RegulatoryTradeIDGrp is intended to capture all identifiers related to regulatory reporting. We found that people use ExecID / SecondaryExecID for venue specific IDs but would not be able to simply re-use them for ESMA. Re-using the existing field means changing application logic (e.g. scope of uniqueness) rather than extending it. Hence the choice was made for RegulatoryTradeIDGrp which does not impact the trading workflows.

14

Hello,

Please note the below query is in regard to the FIX Protocol GA - MiFID/MiFIR II Extension Proposal Part 2 document.

In page 14; item no 12 of the document, reference is provided to an email conversation (in the change request column). It states the values ‘0-No Client’, ‘1-AGGR’, ‘2-PNAL’ and ‘3-CLIENT’ will also have to be considered as order attributes according to RTS 22/24. Therefore, it has been suggested that these should be included in the NoOrderAttributes (2593) repeating group (in the GTC proposed solution column).

However, in MiFID II and MiFIR Extensions Part 1 document (approved) the values AGGR and PNAL are already mapped to values 0 & 1. In addition the value Liquidity Provision is mapped to 2.

Therefore, could you please let us know the set of values that will be used to indicate the following in the NoOrderAttributes (2593) repeating group;

  • No Client
  • AGGR
  • PNAL
  • CLIENT

Believe that the below values will remain the same as per the MiFID II and MiFIR Extensions Part 1 document (approved).

  • Liquidity Provision - Already mapped to 2 as per MiFID II and MiFIR Extensions Part 1 document
  • Algo - Already mapped to 4 as per MiFID II and MiFIR Extensions Part 1 document

Appreciate your input in this regard.
Thank you.

15

Thank you for the question as it shows a misunderstanding that others may also have. Your sentence “It states the values ‘0-No Client’, ‘1-AGGR’, ‘2-PNAL’ and ‘3-CLIENT’ will also have to be considered as order attributes according to RTS 22/24.” is incorrect. The statement in the Change Request column links these values to reserved short codes inside the Parties component. These values are completely independent from the valid values in the new field OrderAttributeType(2594). The Change Request is the input used by the GTC, only the GTC column is relvant for the actual extension to FIX.

16

MiFID II and MiFIR Extensions Part 1 is approved and implemented as EP222 (http://www.fixtradingcommunity.org/pg/extensions/extension-pack?ExtensionID=EP222). Official values for OrderAttributeType(2594) can be found there and in Part 2 (this thread). Community conventions for the reservation of short codes for specific OrderAttributeType(2594) values cannot be part of the FIX Repository (and FIXimate or FIXwiki) but will probably be contained in MiFID guidelines when published by FIX.