The Impact of ESMA’s Latest Revisions to MiFID II/MiFIR Reporting Standards

Adding a MiFIR/MiFID II Module to Validate.Trade is one of the next big areas of investment for Report-it.Trade. We have already developed a beta version based on the original ESMA drafts. The recent version of ESMA’s MiFID II / MiFIR Regulatory technical implementing standards– Annex I (RTS) has some notable differences to the previous draft version from a Transaction Reporting perspective and, therefore, from a Data Validation perspective too. I have summarized the points impacting Validate.Trade below.

Defining Transactions: The definition of a transaction has been further described with some notable exclusions. Exercises of reportable financial instrument resulting from options, warrants & convertibles and securities financing transactions are no longer required to be reported.

Message Formats: ESMA has specified the messaging format as a common XML template in accordance with ISO 20022. While this is the format in which the National Competent Authorities will require the transaction reports to be submitted, ARM’s will continue to accept transaction reports in existing formats, such as CSV.

  • Our goal with Report-it.Trade will be to satisfy all possible interfaces, including the leading ARM’s and the ISO 20022 standard directly.
  • With DTCC announcing its tie up with Unavista, clients of the G20.Validate.Trade product will find it very easy to integrate the new MiFIR module to validate their CSV and FpML messages.
  • As none of these formats are currently in use, we have built our own initial interface to meet the field level RTS requirements below.

Number of Fields: The final RTS contains 65 fields versus the draft’s version’s 81. 25 fields have either been removed (such as country of residence and post code fields) or are no longer required due to the ISO 20022 messaging format.

  • “Code Type” fields are no longer required. However, given that ARM’s will accept reports in CSV format, it is very likely that they will still require a way to define the contents of certain fields and will therefore ask for “Code Type” fields to remain for CSV formats. This will result in transaction reports being longer than the 65 fields defined in the RTS.
  • “Buyer” and “Seller” details are to be repeated for joint account holders, meaning the number of fields required would increase.

New Fields: Most notable amongst the nine new fields are:

  • Trading Venue Transaction Identifier Field – a 52-character alphanumeric field populated with a code generated by the trading venue, disseminated to both buyer and sellers
  • Complex Trade Component ID – a unique ID internal to the reporting firm and used to identify all reports relating to the same execution of a combination of financial instruments (e.g. strategy trades)
  • Instrument Identification Code – Only ISIN’s allowed. The use of AII’s has been removed. If there is no ISIN, then 16 reference data fields will need to be completed in full but these fields are NOT required if an ISIN is supplied.
  • Securities Financing Transaction Indicator – Indicates if the trade falls within the Securities Financing Transaction Regulation or not. It is interesting to see the addition of this field given the previous statements about securities financing transactions being described as not required. This could potentially point to the future inclusion of SFT’s.

Firm Identification Requires LEI: With regards to firm identification, only LEI is allowed in the final version. This means that any firm involved in the transaction must have a valid LEI. However, there is no obligation to check the LEI against the GLEIF on a trade-by-trade basis nor any obligation to check that the LEI status hasn’t lapsed.

Defining Buyer and Seller: The determination of ‘buyer’ and ‘seller’ has been further described. This has always been a point of pain for firms trying to determine who is defined as the buyer and seller, and ESMA has attempted to help with prescriptive details of when to use buyer and seller. This will also, in time, be augmented with the creation of sample trading scenarios by ESMA.

Needing Further Clarification: ESMA acknowledges that further details on validations and trading scenarios are required but there are also other areas that require clarification such as:

  • Why is the Securities Financing Transaction Indicator field present?
  • What is the use of the Instrument Classification field given the CFI code is currently under revision?
  • Which fields are mandatory, optional or conditional?

MiFID II RTS Analysis Table

-Daniel Tate, Business Analyst

 

Click here to contact us.