ESMA has published a consultation paper on the transaction data reporting and order book record keeping requirements introduced by Regulation (EU) 2024/791 (Updated MiFIR). This is the latest in a series of consultations published by ESMA as it fulfils its various mandates as part of the MIFID Review (see our briefing here) in light of Updated MiFIR entering into force (see our briefing here). This consultation proposed changes to RTS 22 and RTS 24 following the changes to Article 25 and Article 26 made by Updated MiFIR.
It is difficult to summarise the requirements for transaction reporting proposed. The main takeaways are:
A) there is some good news (i.e. the removal of the shortselling indicator)
B) firms with UK and EU entities who have run centralised reporting frameworks will now have to start thinking more seriously about the D word ("divergence")
C) the main proposals thematically relate to the addition of:
- new execution/transaction codes (TVTIC/TICs/Updated INTC's);
- revisions to decision-making fields (these need to be a close attention to as a popular topic…); and
- standards for reporting derivatives in terms of buyers/sellers.
The deadline for comments is 3 January 2025. ESMA is expected to publish a final report and submit technical standards to the Commission in Q1 2025.
Notable proposals
- Updated MiFIR amends the scope of transactions to be reported in relation to transactions in derivatives. OTC derivatives where the underlying is not traded on trading venue or an index made of instruments traded on a trading venue will only need to be reported where they are traded on a trading venue (unless they fall within the list of OTC derivatives set out in article 8a(2) of Updated MiFIR).
- Data field to be reported in relation to the identification of the “entity subject to the reporting obligation”. Trading venues can use this when they report on behalf of a member or firm not subject to MiFIR and a third party is relied on to submit the report. This new field would complement field 4 (executing entity populated with the LEI of the entity not subject to MiFIR) and field 6 (submitting entity equal to the LEI of the third party) and would contain the LEI of the trading venue operator.
- Trading venues will need to include a transaction identification code generated and disseminated by the trading venue to both buyers and sellers at the trading venue (TIVTIC). ESMA is planning to align the TVTIC requirement in RTS 22 with that in RTS 24. RTS 22 is to specify that the TVTIC code: should be maintained for each transaction; it should be unique, consistent, and persistent per MIC and per trading day; and its component should not disclose the identity of the counterparties. The consultation also proposes extending the requirement for disseminating and reporting the TVTIC to cover all on EEA venue transactions including those relating to negotiated trades and trades brought under the rules of the venue.
- The reporting of TVTIC code is to be extended to transactions executed in non-EEA venues. The non-EEA trading venue would be the primary entity responsible for the creation of the non-EEA TV TIC code and for disseminating it. Level 3 guidance will set out methodology for harmonising the code (ESMA is considering a TVTIC code’s syntax combining existing information e.g. ISIN, LEI of the generating entity, Date, Time and Quantity and considers that it should not be too problematic for non-EEA trading venues to obtain and disseminate this information to members).
- A new transaction identification code (TIC) for off venue transactions is to be introduced. A clear syntax for generating and disseminating the code to entities involved in OTC transactions is to be further developed by Level 3 guidance and would also address the entities responsible for generating the code and the parties involved in the dissemination process of the non-EEA TV TIC and the off-venue TIC. ESMA proposes identifying the “market facing” firm acting as the seller of the financial instrument as the primary entity responsible for the creation of the TIC code of off–venue transactions and for disseminating it to the other “market facing” firm acting as the buyer.
- A new identification code (INTC identifier) to link cases of aggregate orders (from multiple clients) resulting from the execution of the transaction when field 7 (Buyer identification code) or 16 (Seller identification code) is reported as INTC. The executing investment firm would be responsible for generating the INTC identifier.
- A new code (Chain Identifier) disseminated across all counterparties involved in the chain flow to make it easier to link all transaction reports pertaining to the same sequence of chains. A party to the chain would be required to transmit the code to its direct counterparty until the ultimate reporting entity. The code would apply to XOFF transaction executed on venue. The code would be transmitted across the counterparties along with the sequence of confirmations chains. The firm executing the transaction would be the primary entity responsible for the creation of the code and for disseminating it.
- Amendments to Art.4 of RTS 22 to extend the transmission of order agreement to cases of acting on own account.
- A portfolio management company taking an investment decision on behalf of a client under a discretionary mandate would be identified by the investment firm receiving and executing the order as buyer/seller in fields 7/16 (field 12 would not be populated).
- New fields to be added to Table 2 annex 1 of RTS 22 (e.g. new field for client categories to mirror the client categories specified under Article 30 and 24 of MiFID II). ESMA also proposes to amend existing fields in Table 2 of Annex I and Annex II, as well as to remove existing fields such as the short selling indicator.
- Revisions to promote more alignment with EMIR (alignment of reporting direction, reporting price and complex trades) and SFTR reporting.
- Amending Article 2(5) to include in the list of exempted transactions emission allowances auctioned on auction platforms.
RTS 24
- Adopting JSON as standard and format of order book data keeping and transmission.
- Updating the field list in the Annex of RTS 24 to align with the proposed RTS 22 fields
- A new field to capture the date and timestamp when a transaction is cancelled after validation from both parties.
- Amending fields in the Table 2 of the Annex of RTS 24, including field 3 (Client identification code) to align with fields 7 and 16 of RTS 22 for indicating an aggregate client account (INTC) instead of AGG.