ESMA publishes review on MiFID II best execution reports

RTS 27 Challenges

• Lengthy reports: There are a large number of fields required for reporting that are of questionable value.

• Lack of consistency: Due to the different interpretations of the requirements (both definitions of reportable fields, and format of the actual report (XML, CSV, 1 instrument per table per day vs. 1 report for all tables for 1 instrument, etc.)), reports have varied in consistency. This has resulted in severe technical challenges in consuming the myriad of different RTS27 reports and translating them into meaningful insights. There also hasn't been any consistency in the 'housing' of the reports on venue websites. 

• Volume: Due to the reporting tables being split by instrument and due to ISIN proliferation (particularly in OTC products); the size of the actual reports can be very large.

Proposed changes to RTS 27 reporting

• Reduce the overall number of reportable fields to 13 (vs. the current number of >50), with only 6 fields being "calculated" fields;
  • Total nominal of all transactions
  • Median transaction value
  • Median transaction cost
  • Variable costs for a median transaction
  • Speed of execution
  • Total number of market makers
• Make RTS27 reportable to a central data repository 
• Make CSV format obligatory

• Restrict reportable scope to transactions executed on Trading Venues and on those OTC transactions where an SI or another LP is a party to the transaction

• Exclude market makers from the scope of obligations

• Exclude the reporting of instruments that are not deemed to have a liquid market (except in the case of derivatives subject to the derivatives trading obligation) 

• Aggregate reports using MiFIR identifiers (i.e., shares, ETFs, equity-like instruments, etc.) and their associated liquidity profile rather than the current implementation which is by instrument

• Change the reporting deadline to one month after each quarter-end as opposed to three

RTS 28 Challenges

• Limited consumption and utility: The RTS28 reports do not show much. ESMA noticed ‘good practices’ of firms extensively documenting their execution flow and approach alongside their RTS28 reporting.

Proposed changes to RTS 28 reporting

• Make a distinction between orders which a firm executes and orders a firm transmits for onward execution

• Remove fields to distinguish between passive and aggressive order percentages. ESMA acknowledges these fields have added ‘little value’

• Include information received for ‘payments for order flow’

• Make CSV format obligatory

Providing feedback on the proposed changes to RTS27 and RTS28