Hardly a month goes by without another bank being handed a hefty fine by regulators. In 2014 the UK’s financial regulator, the Financial Conduct Authority (FCA), dished out record fines totalling a staggering £1.47 billion. Quite a year.
And the fines are only part of the problem. There are also the costs pertaining to litigation (should they choose to fight the fine), the cost of wasted time spent by employees on fixing the problems, as well as untold collateral damage to the brand.
In parallel, more regulations are on the way: the Markets in Financial Instruments Directive (MiFID II), for example, which will come into effect in January 2017. The next iteration of what has become the cornerstone of the EU’s financial markets regulation is designed to improve the functioning of these markets in the light of the financial crisis and to strengthen investor protection.
While MiFID II and other regulatory imperatives are broadly welcomed by the industry and the wider public, the potential for banks to find themselves unprepared when they come into force is considerable. And the prospect of more fines looms large.
But the pressure arising from compliance and the changing regulatory framework does not need to be a problem. By getting their data in order now, banks can be fully prepared for MiFID II as well as any other new regulations on the horizon.
There is a growing realisation in the financial services industry that the answer lies in the deployment of a Trade Store (or Data Hub) – a virtual filing cabinet that holds a single source of truth for all trade events within a bank. With this Trade Store approach – effectively a trade lifecycle management system – every single ‘event’ that happens to a trade or asset is recorded, meaning that auditors and regulators can easily understand how a certain position was reached.
Over the last few years I have been involved in quite a few Trade Store discussions and deployments. The design of the technology platform always comes down to some basic requirements such as tracking legitimate trades, meeting regulatory requirements and also flushing out the odd rogue trader.
The IT challenges banks face stem from two key factors: a rabbit’s warren of data silos, and a historical reliance on relational databases.
Banks typically have lots of individual product lines and trading systems that feed into specific information silos. The flurry of M&As hasn’t helped, creating even more trading system fiefdoms and silos that have to somehow be cobbled together to provide an integrated, consolidated view for reporting and regulatory purposes. This is further complicated by the fact that banks are continually moving money around to hedge against certain positions.
Some banks have tried – and failed – to use their legacy relational databases to build a Trade Store. They have come unstuck because of the changing nature, variety and complexity of the trading data, which does not lend itself to the rigidity of a schema-based relational model. Banks now understand that legacy relational databases are simply not capable of being agile enough to provide a single source of truth for trades.
In the absence of a workable Trade Store built on existing relational databases, many banks have opted for an interim solution: pushing data into a spreadsheet and using this for reporting. But this approach is like putting a sticking plaster on a leaky boat – a short-term, time-intensive patch at best.
But these internal and external pressures mean the tide is turning. Some of the world’s largest investment banks have solved the conundrum by building a Trade Store on an Enterprise NoSQL database platform.
A NoSQL database is flexible, schema-agnostic and specifically designed for rapidly changing, multi-structured, complex data applications – like a Trade Store. Choosing the right NoSQL database is important though: open source variants do not have all the enterprise-grade features required. These features include support for ACID transactions, government-grade security, high availability, elasticity or scalability and disaster recovery.
It is also useful to look for a database that supports bitemporal data management. This ‘time machine’ function allows banks and regulators to identify what a user knew at any point in time. This capability is critical for regulated companies to maintain and demonstrate compliance with, for example, Frank-Dodd legislation.
An Enterprise NoSQL database combines the flexibility of NoSQL with enterprise-hardened features found in relational databases. Using an Enterprise NoSQL database, some of the largest global banks have become early adopters, successfully deploying Trade Stores that streamline regulatory reporting and make the data easily available for all permitted users.
For example, one global investment bank built a Trade Store on the MarkLogic database in just six months. This acts as a single source of truth for all trade events and related data, and ensures data consistency. More than 30 internal systems were reworked in order to bring vast amounts of unstructured and structured data into one central repository and make it accessible by tens of line of business’s downstream systems. This allows the bank to handle various reporting requirements, including regulatory reporting, and helps to protect against regulatory fines.
Today, the Trade Store takes inputs from multiple trade sources and three reference data sources, and unifies and stores more than 25 TB of unstructured data in one single repository. It currently holds information on over a billion trades and ingests, in near real-time, up to 2 million trade events and reference data records per day from upstream production systems, including validity and duplication checks and version management.
Because MarkLogic is an Enterprise NoSQL database with ACID capability, even the largest datasets are processed consistently and reliably so none of the data is ever altered or lost. Importantly, the system can also be quickly adapted, extended and enhanced to meet changing business and regulatory requirements.
With this approach, not only are banks able to avoid the prospect of hefty regulatory fines, they can also reduce costs because there is no longer a need to develop and maintain multiple different systems. In the new Enterprise NoSQL world, the system is built on a commodity architecture that is easy to scale. The result is a lower cost per trade. An additional benefit arising from the better risk management provided by the Trade Store is that regulators typically require the bank to hold less capital.
Looking ahead, the idea of a Trade Store on steroids that is used to evaluate aggregated risks – for example for BCBS 239 – is being mooted by some banks. If they know where they stand with regard to a risk-adjusted position at any one time, they can work out how much capital they have available to trade with too.
And while it’s true that regulators are less concerned about the process used – as long as they are able to check every piece of data (from IM logs to analytics to individual trades) when they want – an Enterprise NoSQL-based Trade Store offers a proven approach with rapid development and deployment.
In today’s regulatory climate, it is a sobering thought that much of the technology the banks rely on is past its sell-by date.
And this is a global phenomenon.
With MiFID II just around the corner, ushering in an even more granular level of reporting, banks need to act now to get their digital filing in order and ensure they do not fall victim to massive – and wholly avoidable – regulatory fines.
