The impact of regulation : Viewpoint : MiFID II/MiFIR : Silvano Stagni

REGULATORY REPORTING, DATA AND THE IMPORTANCE OF A HOLISTIC VIEW.

32-SilvanoStagni-575x326

Silvano Stagni, global head of research at IT consultancy, Hatstand.

Data is one of the most important aspects of the Markets in Financial Instruments Directive/Regulation (MiFID II/MiFIR). Making sure the right data is in the right place at the right time is one of the major challenges when the MiFID Review regulations are implemented. This becomes evident when working towards putting into practice the reporting requirements.

The timetable for regulatory change in the next two years is hectic as demonstrated by four examples of the ‘financial trading’ regulations, all with reporting requirements:

  • MAD II/MAR (Market Abuse Directive/Regulation) will come into force on July 3rd, 2016 with the exception of the part that is dependent on the MiFID Review. That section will be implemented from January 3rd, 2018.
  • EMIR (European Market Infrastructure Regulation) changes to reporting to transaction repositories will take effect in the Spring of 2017.
  • SFTR (Securities Financing Transactions Regulation) is currently under discussion and consultation but it is likely that it will come into operation in 2018.
  • The MiFID II/MiFIR deferred implementation date is now January 3rd, 2018 (subject to confirmation by the European Parliament).

Unfortunately, there is not much coherence across ‘financial trading’ regulations. Trading and post-trading regulations (MiFID and EMIR) have different goals and have been examined by different teams. Although a Transaction Repository (TR) can be licenced as an Authorised Reporting Mechanism (ARM) under MiFID, reporting to repository under EMIR (both the current and the future version) and transaction reporting under MiFID II/MiFIR are inconsistent.

There are no plans to introduce consistency. If an investment firm chooses to report to the regulator using a TR as an ARM, they will still have to prepare two reports rather than one as the two have major differences between them. We still do not know what ‘reporting Securities Financing Transactions to Repositories’ will look like as at the time of writing this article, the technical standards have not yet been published. In any case a SFTR repository and an EMIR repository will very likely be different because the logic behind the content is different.

Be32-SilvanoStagni-Fig.1-375x794If things are so different, why does it make sense to look at all the reporting requirements together?

  • Change is expensive, time consuming and risky. Reviewing it once is more efficient.
  • These regulations are all concerned with reporting trades in financial instruments. All the data comes from the same environment. It makes sense to figure out what information needs to be captured and when, so that all changes to processes and procedures concerned with data capture can take place once.
  • There are some differences in static data and identifiers. It is important to look at them together to secure the most efficient result. MiFID transaction reporting identifies instruments with ISIN code but pure OTC products (most likely a one-off instrument) may not have one. An AII code may be used to report transactions in Financial Instruments that do not have an ISIN code under EMIR. Most reporting regulations include one or more taxonomies to identify the characteristics of the instrument being traded. These taxonomies may not be in common, but looking at them within the same project will help to avoid making unnecessary changes to static data and identifiers.
  • It is easier to look at the rules in a co-ordinated fashion. Both EMIR and MiFID use similar rules to define who the seller is, and who the buyer is, in transactions that do not have a real seller or a real buyer (for instance a foreign currency swap).
  • There are dependencies. MiFID transaction reporting flags a transaction subject to SFTR rules and the trader code included in the report will then be used under MAD II/MAR when there is a pattern of suspicious transactions.

This common approach is described in Figure 1.

A common implementation strategy would allow any synergy or similarity between reports to be taken into account and their implementation planned according to a common timeline across all regulations. Each report would then be prepared separately.

At the last FIX Protocol EMEA Trade Conference, over 70% of the delegates surveyed listed reporting as the major concern in the implementation of regulatory change. A holistic view across regulations will maximise what is common, make the most of any possible synergy, co-ordinate any change to the data structure, and simplify the actual preparation of the report.

©BestExecution 2016[divider_to_top]

[divider_line]


 

Related Articles

Latest Articles