A JWG analysis of the 687 transaction reporting fields used across MiFID II, EMIR, REMIT and SFTR found that approximately 40% of these fields cover the same topic. Even so, the different regulatory regimes named above require different interfaces.
From a global perspective, this problem gets even worse, for example, the forthcoming collateral and valuation reporting under EMIR. The recent ESMA review of Article 9 of EMIR (ESMA/2015/1645) takes a different route compared to other G20 regulators like an article by Risk Focus has laid out. The article notes that the U.S. Commodity Futures Trading Commission (CFTC) requires netting sets to be reported whereas ESMA requires nominal values to be reported on a very granular level.
A spaghetti soup of interfaces
This leaves multi-national investment firms with the task of having different reporting interfaces not only for each type of reporting but also for each major jurisdiction. In combination with different operational systems for each country or region this adds up to a 3-dimensional headache. Moreover, each regulatory topic usually means several releases, like we saw with Basel I, II and III.
Therefore, regulatory interfaces should be planned not as a one-off solution for Jurisdiction A, Country B and System C. A better approach is to go for a continuous process based on a reasonable investment book of record (IBOR) solution combined with data marts that include specific functionality to meet typical regulatory requirements and enable auditing and reconciliation of the sent data.
Moving towards an integrated view
SimCorp’s IBOR solution for example, comes with dedicated data marts for legal reporting requirements. These configurable data marts enable our clients to solve complex legal reporting requirements for different topics and regions in one system.
From an industry perspective it would be helpful to have, as a very least, a common “European Regulatory Reporting Hub” in the long run. Sadly, this might remain wishful thinking because regulators often do not collaborate with the financial industry on reporting interfaces and national authorities tend to define interfaces of their own.
An example of this was the 2007 ECB regulation concerning statistics on the assets and liabilities of investment funds (ECB/2007/8). Since then, it has been standard to have EU regulations that need to be adopted to national law. As a result, all national banks in the European Monetary Union (EMU) invented their own interfaces for their financial industry to meet the ECB regulation.
There has been one exemption. The fund industry in Austria convinced the Austrian National Bank to accept FundsXML as a general transaction format for fund related data. The Oesterreichische Kontrollbank AG (OeKB) acts as a data hub extracting the relevant data for the national bank similar to Fundsquare for the Luxembourgian market. But in the case of Luxembourg, the Banque Central de Luxembourg defined its own reporting interface based on the common ECB regulation. The same observation holds for the German Bundesbank and other national banks.
Therefore, many will appreciate the fact that the forthcoming ECB regulation on the collection of granular credit and credit risk data “AnaCredit” (ECB/2016/13) will be harmonized on EMU level.
Finding a common standard
Coming back to MiFID II, it can be considered progress that MiFID II/MiFIR applies on an EU level without being adopted in 28 different interfaces like in the case of MiFID I. On the other hand, the “end-reporting” still has to go to the different National Competent Authority (NCA), a task to be a burden on the different Approved Reporting Mechanism (ARM). In this regard, there is no common report standard in sight for the different transaction reports to authorities.
So a common “European Regulatory Reporting Hub” might remain a wish for the next decade?
Frank works at SimCorp’s Center of Regulatory Excellence, working to convert regulatory insight into efficient solutions.
