In a guest article for International Investment, Giles Nelson argues that aging technology is failing to meet the data challenges of MiFID II.
A significant part of the MiFID II regulation, now one year old, concerns transparency of trade processing and reporting. Financial institutions must give transparency to the regulator on many aspects of the trading process, in particular with real-time and end-of-day trade reporting.
In part, the systems that have been put in place are delivering. The stipulated requirements can be adhered to. But what organisations are discovering is that these systems are not delivering when it comes to dealing with requests that local regulators now have the authority to make when they wish to know specific details of a transaction or set of transactions.
With a data management system that is too rigid and inflexible, banks have no hope of meeting ad-hoc requests from the regulator."
For example, if the UK local regulator, the Financial Conduct Authority (FCA), wishes to know about a specific transaction, it is entitled to contact a bank to request that information and set the deadline for a response. The FCA can ask for as much or as little information as it requires, including the individuals involved, the transactions associated with that employee, the dates that a transaction took place, the behaviour of the traders and the clients they were dealing with, all within a very specific time frame.
These ad-hoc reporting requests are exposing the weaknesses of existing compliance systems. While access to the structured trade data itself may be straightforwardly available, from the system built to satisfy the MiFID II trade reporting requirements, other information typically will not be.
Rather, it will exist in many different systems underpinned by many different technologies. As such, when an organisation is asked to present such a 360° view of their trading process it's difficult and time-consuming to achieve, particularly when dealing with a short notice request.
An inability to answer these requests in a timely way is also causing the regulator to question whether certain banks can meet the requirements of MiFID II. From a reputation standpoint, no bank wants this. It can also lead to fines or the forcing by a regulator of an independent review (in the FCA's case, a Section 166) of the organisation's processes, paid for by the bank.
At the heart of the solution lies access to the data required to deal with these ad-hoc requests. This will often be held in multiple systems, some of which will be built upon conventional relational database technology and also involve desktop applications and open source technology, such as Hadoop. To obtain a view over all this data and allow it to be accessed, queried and searched, a process of data integration needs to occur with the objective of creating a single data hub. Not to replicate the data in another silo, but to integrate existing data systems together.
Conventional approaches, using relational technology, to creating a data hub are costly, time consuming and often such projects end up being abandoned. In addition, although relational technologies can be adequate for dealing with fixed, structured data and environments that change infrequently, they are intrinsically not suitable for dealing with environments that change regularly and where the model of what data is required not only evolves but is often not known in advance. In short, they are not agile. And this lack of agility is exactly what is preventing firms from dealing with regulators' ad-hoc requests efficiently.
With a data management system that is too rigid and inflexible, banks have no hope of meeting ad-hoc requests from the regulator. And this isn't just about patching holes. Regulation is evolving continuously and organisations need the right data architectures in place to deal with this efficiently and flexibly. Firms should be looking to more flexible, non-relational data hubs that allow them to access all their data in one place, where it is easily searchable and where data can be shared safely across the organisation.
Dr Giles Nelson is chief technology officer for financial services at MarkLogic