MiFID II: toward one synchronised reporting architecture?

Is it possible to have a single reporting architecture that takes into account MiFID II and other capital markets rules like SFTR and EMIR?

MiFID II: toward one synchronised reporting architecture?

A regulatory tsunami

Banks face more and more reporting requirements in the field of capital markets and there is more on the way. One of the most pressing rules is the trade and transaction reporting requirements under the Markets in Financial Instruments Directive II (MiFID II) and the Markets in Financial Instruments Regulation (MiFIR). It plans major extensions to pre- and post-trade transparency and transaction reporting for non-equity instruments. Another capital markets regulation whose purpose is to improve regulation of “shadow banking” is the Securities Financing Transactions Regulation (SFTR).

SFTR applies to financial and non-financial counterparties and fund managers and aims to reduce risks by improving transparency in the securities financing markets. And, last but not least, there is the European Market Infrastructure Regulation (EMIR) Review. Although the regulation has already been in place since 2013, the European Commission has taken the opportunity to align it with MiFID II.

The goal is to clarify some rules and add some specific fields. In the past, different capital markets regulations were handled mostly in tactical solutions. In the current context it makes sense to think more strategically and build a horizontal solution that copes with the different capital markets regulatory requirements.

Complexity and overlap of different reporting requirements

When we look at the different capital markets regulations side by side, we definitely notice some differences. The purpose of MiFID II is market abuse. EMIR focuses on systemic risk. SFTR aims at monitoring shadow banking activities. The financial organisations targeted by MiFID II are investment firms and trading venues while SFTR and EMIR cover financial and non-financial counterparties. Major differences also appear when looking at relevant reportable instruments. Where EMIR only focus on exchange-traded, over-the-counter (OTC) derivatives and SFTR on securities financing transaction, MiFID II has a wider scope and focus on all financial instruments admitted to an eligible trading platform.

However there is quite some overlap concerning these major regulations. A good example is a reportable event. A reportable event in the case of EMIR and SFTR is when an in-scope entity concludes, modifies or terminates a reportable product. MiFID II has a larger scope and includes “execution”, meaning any action that results in a transaction. There is also some overlap concerning the frequency – no later than the close of the following working day – between MiFID II and SFTR and the associated EMIR and SFTR reporting authorities (trade repository).

Another interesting topic requiring some investigation is the one concerning data requirements. Transaction reporting requirements in the context of MiFID II are set to increase in scope and prescription compared to MiFID. The number of data fields to be reported under MiFID II has increased to 65 although it remains lower than the number of fields required for SFTR or the EMIR review.

Where SFTR and the EMIR review are not absolutely clear about the final data requirements, we notice that a variety of fields are related and talk about the same facts with a broadly aligned format for transaction, counterparty and financial instrument details.

Can one solution cope with all requirements?

When talking to industry players, it is easy to note that there is a need to harmonise transaction reporting. It makes sense to imagine a holistic transaction reporting solution that can handle multiple trade and transaction reporting regimes. This would not only cover the EU regulations such as MiFID II, SFTR and EMIR but would also include other regulations such as the American Dodd-Frank Act.

When changes in regulation occur, solutions shouldn’t have to be developed from scratch so that the cost of compliance for financial institutions could remain in check, especially since the workflow for all these capital markets reporting is the same: the loading of all required data from source systems, the enrichment, validation and transfer of the data into the required format of the regulator.

This requires a solution that can identify in-scope trades and transactions required by each reporting regime, the regulatory bodies and third party entities to which they need to be reported. Such a solution should be completely compatible with any and all trade repositories, approved publication arrangements (APAs) and approved reporting mechanisms (ARMs) to which firms will report. And it should also ensure that any validations required by the relevant regulator are undertaken.

Firms must also report in a very short time frame. MiFID II will also require real-time reporting of trade data to APAs. This presents a significant set of challenges already encountered by market participants in the US when trying to meet the real-time challenges of Dodd-Frank. Platforms that support both real-time and batch processes simultaneously while also allowing for reconciliation between the two are hard to find. In a nutshell, a third-party solution can not only save time and effort but also provides a clear advantage in terms of costs compared with the development and maintenance of an in-house reporting solution.