ESMA publishes two new reports on transaction reporting under the DLT Pilot Regime

Why a study on transaction reporting under the DLT Pilot?

Transaction reporting helps regulators monitor market behaviour, ensure oversight and protect market integrity and transparency. Under MiFIDII / MiFIR, investment firms executing transactions in financial instruments must report transactions in financial instruments to the NCA “as quickly as possible, and no later than the close of the following working day” (Article 26 MiFIR).

The DLT Pilot allows the operator of a DLT market infrastructure to ask for an exemption from such a reporting obligation. If granted, the operator must keep records of all transactions executed through its system and give the NCA direct and immediate access to the transaction data by letting it join the DLT market infrastructure as a regulatory observer participant¹. This would be akin to an “observer” node on the DLT platform used by the DLT market infrastructure.

However, the DLT Pilot does not specify how the authority should access the transaction records or what data fields they should contain, only that they should reflect those in Article 26(3) MiFIR that are “relevant, having regard to the DLT used by the market infrastructure’s operator and the member or participant executing the transaction”². Therefore, ESMA conducted two studies to clarify these issues and published the reports that are the focus of this post.

The reports concern DLT Multilateral Trading Facilities (DLT MTFs) and DLT Trading and Settlement Systems (DLT TSSs), the two market infrastructures under the DLT Pilot where trades are normally executed.

Report on extraction of transaction data

The Study on extraction of transaction data analyses and compares three main approaches for extracting data produced by a transaction occurring on DLT: the file-based approach, the API³-based approach and the native-access method. ESMA tested them on three major DLT networks – Corda, Hyperledger Fabric and Ethereum (the first two private, the latter public) – to identify the best method in terms of reliability and cost-efficiency.

The file-based approach involves sharing transaction data in files via either an SFTP server⁴ or a shared drive provided by the regulator. The DLT market operator extracts the data stored on the ledger, parses it into the requested format and provides it to the regulator. The method is similar to the systems already used by incumbents for transaction reporting for traditional financial instruments. It would only require adapting the existing mechanisms and standards – such as the ISO20022 XML format together with the prescribed data fields under Delegated Regulation (EU) 2017/590 (RTS 22) – to a DLT environment.

However, the file-based approach does not use the full potential of DLT, such as real-time transaction reporting. This feature is achieved with the API-based and the native access approach. In the API-based approach, the operator builds an API layer on top of its DLT network that offers the transaction data to the NCA upon request. Its main pain point lies in the current absence of an API standard enabling all participants to maintain the same stable and interoperable transaction reporting process across all DLT networks and protocols. Other drawbacks include the costs of implementing and maintaining the API layer and the risk of system failures in the DLT network affecting the NCA’s systems.

In the native access approach, the NCA has an observer node on the DLT network, where transaction data is automatically and instantly transmitted upon the execution of a trade. The NCA has direct read-access to all transactions on the network. The data is stored in the observer node’s vault and can be extracted by the NCA at its discretion. Like the previous method, the NCA’s direct involvement allows for real-time reporting, reduces the possibility of data tampering and fosters trust in DLT technology. However, the costs related to the technical set-up of the observer node (by the NCA) and the fast-changing nature of DLT technology (which may require constant updates) may make this approach more burdensome compared to the previous methods.

After a cost-benefit analysis of the three approaches, considering the security, stability and overall costs for both the regulator and the market infrastructure operator, ESMA concluded that the file-based approach is, for now, the most reliable and cost-effective method to extract transaction data from a DLT market infrastructure. It therefore recommended that the operators of DLT MTF and DLT TSS use the file-based method to implement the transaction reporting exemption under the DLT Pilot.

Report on how transactions are registered in various blockchain solutions

The aim of this Study is to determine how data natively generated by transactions on the three DLT platforms match the data fields required by Article 26 MiFIR, which are specified in RTS 22. Unless an exemption from Article 26 MiFIR is granted, the reporting obligation still applies to the operator of a DLT market infrastructure and its members⁵. 

The RTS 22 envisage 65 data fields that have to be reported to the NCA, ranging from buyer and seller information to the details of the financial instrument traded (e.g. quantity and price), as well as other transaction details such as date and time of the trade.

The gap analysis conducted by ESMA revealed that: a) the fields defined on Corda, Hyperledger Fabric and Ethereum are very limited and do not cover all the 65 data fields under the RTS 22 schema; b) on the other hand not all the 65 data fields are relevant in a DLT environment; c) significant differences exist between the three DLT networks in terms of native data fields; and d) some fields that are essential for supervision are currently not captured by the RTS 22 schema, especially those identifying a specific transaction on the ledger and those identifying the trading parties. 

For each of the three DLT networks, ESMA identified the native fields falling outside of the RTS 22 schema and suggested NCAs request them from the DLT market infrastructure operator, in addition to the traditional 65 data fields. 

Besides the DLT transaction native fields, ESMA recommended the inclusion of the Digital Token Identifier (DTI) in the smart contract governing a DLT financial instrument. A DTI, similar to the ISIN code, provides valuable information on the technical attributes of the token traded (price, issuer’s identity, maturity date etc.) and on the DLT used, which is not generated by the transaction itself. A DTI may also be assigned to e-money tokens (or other tokens serving as cash-leg of the transaction), allowing the NCA to track and study the development of these crypto-assets.

ESMA concluded by anticipating the future issuance of guidelines to adapt the RTS 22 to a DLT environment and to harmonise and standardise transaction reporting under the DLT Pilot.

On-chain analysis as a complement to transaction reporting

In both reports, ESMA also explores the potential of on-chain analysis, the analysis of the transaction activity taking place on the ledger. ESMA considers that on-chain analytics may help regulators detect fraudulent activities such as market manipulation or insider trading more effectively. For example, by examining the transaction records of wallets or addresses involved in criminal activities. While there are publicly available on-chain analytics tools for Ethereum and other public blockchains, the use of such tools in private DLTs is restricted to network participants and subject to permission by the blockchain operator. On-chain analytics tools for private DLTs may be used by regulators with an observer node on the DLT market infrastructure.

Acknowledgments to Giacomo Benincasa, trainee in the A&O Luxembourg Financial Services Regulatory team, for his contribution to this post.

Footnotes

_{¹The idea is that, in a DLT environment, there is no need for market operators to send daily reports to the competent authority as the latter can be directly connected to the DLT network and receive transaction information in near-time sequence.}

_{² Article 4(3) DLT Pilot.}

_{³ An application programming interface (API) is a set of defined rules that enable computer programmes to interact and communicate with each other.}

_{⁴ The Secure File Transfer Protocol (SFTP) is a network protocol designed by the Internet Engineering Task Force which uses cryptography to safely access, transfer and manage large files and sensitive data over a network. An SFTP server helps transfer files server-to-server or client-to-server using the SFTP.}

_{⁵ In this regard, the ESMA Q&A on the implementation of the DLT Pilot Regime sheds some light on how some of the RTS 22 data fields shall be populated for reporting transactions with DLT financial instruments.}