Working through the requirements of Europe’s Markets in Financial Instruments Directive, aka MiFID II, one might wonder if it would be more appropriate to refer to the regulation as MiFIT II. Most requirements in MiFID II will have an impact on banks’ IT systems in some shape or form.
With the introduction of MiFID in 2007 the European Commission (EC) aimed to “[…] improve the competitiveness of EU financial markets by creating a single market for investment services and activities […]”.
Although this aim has been achieved to some extent – for example, trading in blue chip stock is now possible on a wide array of trading venues – the review of MiFID also brought to light a number of issues that were not fully addressed by the regulation. Similarly, MiFID did not yet factor in the rise of algorithmic trading, dark pools and the possibility of arbitrage between trading venues.
MiFID II aims to plug the gaps with requirements that will have a large impact on banks IT systems. One of the core requirements of the directive is the requirement to report transactions executed in financial instruments.
The data that firms are required to report under MiFID II can be grouped into three categories:
• Primary economic terms of the trade.
• Information on the counterparties to the trade.
• Instrument reference data.
When looking at the above the list probably appears very similar to those that already have a reporting obligation under the European Market Infrastructure Regulation (EMIR), Dodd-Frank or similar over-the-counter (OTC) reporting regimes. However, MiFID II adds an additional layer of complexity to what is already deemed to be a challenge in the market.
MiFID II will also require firms to report details on the persons responsible for the decision to execute the transaction, report instrument reference data, and information on the trader or algorithms involved.
These reporting requirements will prove challenging to meet for any institution, because they will require building a comprehensive reference database for client data, financial instruments trade, and the algorithms and traders employed.
Although most institutions will have their own databases already available in some shape or form, the challenge is in streamlining and combining multiple data sources into one transaction report.
Given the challenges that the institutions will face, it is only logical to turn to the parties who will be responsible for the application of the requirements: the regulators.
So what can – or should – we expect from regulators? Not applying the rules is certainly not a realistic option.
In my opinion there are two forms of relief that will help the market implement the transaction reporting requirements.
First, the most helpful relief would come in the issuance of International Securities Identification Numbers (ISINs) for derivatives. If a financial instrument has been provided an ISIN, most instrument reference data fields will not have to be reported.
Second, the ‘ESMA guidelines on transaction reporting, reference data, order record keeping & clock synchronisation’ may offer institutions relief. By publishing these guidelines, ESMA attempts (in a similar way to the publication of the ESMA Q&A) to provide the necessary guidance on how to implement some of the more challenging parts of the transaction reporting requirements. ESMA consulted the market on these guidelines during the first quarter of 2016 and is yet to publish the final version (or second draft).
So what conclusions can we draw from all this? Principally, that there is no time to relax – the January 2018 deadline allows institutions to review their current IT infrastructure, decide on the architecture needed to support the reporting requirements, and the implementation plan for 2017. This requires in-depth knowledge of the regulatory requirements and the ability to define acceptable business solutions.