MiFIR Makes it’s Move: What to expect in MiFID III

Effective date: This field, applying to both derivatives and debt instruments, captures the date when a transaction becomes legally effective, enhancing the clarity of reporting timelines and obligations. For derivatives, it should be the date when the obligation of the contract becomes effective, which is in alignment with EMIR. For debt Instruments, the effective date should be the transaction’s settlement date.

Entity subject to the reporting obligation – This field, which may be familiar, identifies the entity responsible for the MiFIR reporting obligation, which provides additional transparency to multi-intermediary transactions.

New identifiers

• Internal Code Identifier (INTC): To link aggregate orders from multiple clients, a new INTC identifier will be used. This identifier will be generated by the executing investment firm and reported in fields 7 or 16 (Buyer or Seller Identification codes) when the relevant client is identified as INTC.
• A new ‘Chain Identifier’ will be used to link transaction reports for a sequence of chain transactions executed on-venue. The executing firm will create this identifier and disseminate it to all counterparties involved in the chain. This will facilitate easier tracking of related transaction reports
• Distributed Ledger Technology (DLT) pilot regime recommended inclusion of a DLT identifier for financial instruments natively issued on a blockchain and for financial instruments that are re-issued in a tokenised form. Two fields are proposed to identify the DLT “financial instrument code” and “underlying identification code” respectively.

Significant scope increases include:

• OTC derivatives denominated in EUR, JPY, USD or GBP which are subject to the clearing obligation, covering medium dated IRS (interest rate swap) tenors; and
• Single name & Index CDS (credit default swaps) that are cleared and referenced to a global systemically important bank.

The above categorised derivatives are now reportable whether carried out on-venue, or OTC.

The purpose of TVTIC is to provide a unique identifier for transactions executed on-venue, allowing for more precise monitoring of trade execution across different platforms.

Proposed enhancements of TVTIC enable regulators to trace and link large block trades or aggregated orders executed across multiple venues. TVTIC is set to become mandatory for all on-venue EEA transactions to enhance the accuracy of execution tracking.

New proposals will also extend TVTIC to “negotiated” trades and introduce new ‘Trade Identification Codes’ (TICs) for transactions traded on non-EEA trading venues and off-venue transactions, leading to implementation challenges.

ESMA is considering switching from XML to JSON for regulatory reporting to improve efficiency in data transmission and processing. Currently, RTS 22 requires transaction reports in XML under ISO 20022. However, a review suggests JSON may offer simpler syntax, faster transmission, and better parsing performance. Further, it will offer data providers and National Competent Authorities the benefit of consistency following the expectation that RTS 23 (Ref Data) will also transition to JSON.

MiFIR proposes to streamline reporting of instrument characteristics by leveraging reference data reported under RTS 23. If an instrument is already reported under RTS 23, its characteristics will not need to be reported again under RTS 22. Existing fields in MiFIR reporting (42-56) will be updated to reflect the proposed changes in the RTS 23 reference data review. New reference data elements will be included in MiFIR reporting (e.g., “Term of the contract”). Some data elements (effective date, expiry date) will be moved from instrument characteristics to transaction details. Finally, specific OTC reference data related requirements (following the new scope) remain outstanding and will be clarified via a delegated act.

• Common sense amendment to the list of exempt transactions, as the current framework does not address the reporting of Legal Entity Identifiers (LEIs) in cases of liquidation, bankruptcy, or insolvency. In these scenarios, it is often impossible for firms to retrieve LEIs. The proposal is to revise the list of exempt transactions to include these situations.
• New fields in table 2 of Annex I
  • ‘Client Category’ – an indicator of the category of the client (e.g., retail, professional and eligible counterparties) to improve transaction reporting and market analysis.
  • ‘Validity Timestamp’ – a new timestamp field for “New” and “Cancellation” action types that will provide a validity timestamp to indicate when the report was issued, helping resolve issues with multiple submissions for the same execution, particularly for “new” and “cancelled” actions on the same day.
• General amendments to fields – scope expansion of certain fields, providing more clarity and granular validation rules.
• Field removal of field 63 ‘short selling indicator’, as the data requirement of this field is already covered in RTS 22 article 11.
• Amendments on transmission of an order, which now extends to an investment firm acting on its own account.
• Amendments to clarify decision maker of investment decisions by funds – To align the interpretation of the rule to properly identify when a firm is acting as external decision maker of a client or as a buyer/seller in the transaction, Article 7 of the RTS 22 is amended to include the specific cases of portfolio and fund managers.
• Narrowing and clarifying the scope of exemptions for reporting. For example, Novations are now exempt under specific conditions, particularly when they relate to clearing arrangements and CCPs have their own reporting obligation.

Given the intercorrelated nature of regulatory reporting regimes, cross jurisdictional harmonisation is a key ESMA objective. As such, selected fields are reflected in the paper, driving efficiency and consistency. Examples include:

• Adopting the EMIR logic to provide clarity in identifying the buyer and seller for different products.
• Mirroring EMIR logic whereby the price field is only to be populated where not already reflected in another field (e.g. fixed rate or spread), to avoid duplication of data. This may see the introduction of the field ‘option premium amount’
• Including the ‘Package transaction price’ field as seen in EMIR, while aligning with the broader EMIR definition of a package which ensures separately executed transactions, that are mutually contingent, are also captured.
• Introducing identifiers for digital assets, which EMIR mandates, albeit at a slightly higher level.

Back-reporting rules will be difficult to implement after go-live due to the scale of changes. It is advised that firms prioritise outstanding back reporting obligations before go-live.

ESMA’s consultation paper is predominantly focused on RTS 22 and the changes proposed to RTS 24 are less significant by scale. Examples include a new field to capture the cancellation date and time of validated transactions from both parties involved as well as minor amendments to the descriptions and values related to “execution within firm” and “client identification code” for aggregated orders.

Multiple RTS 24 amendments stem from RTS 22 to promote consistency. Mirrored proposals include TVTIC clarifications, the new DLT identifier and the transition in reporting data format from XML to JSON.