SCALED RISK. Will Big Data Save You From MiFID II Hell? White Paper. Executive Summary. Context. Problem

Transcription

1 SCALED RISK Will Big Data Save You From MiFID II Hell? White Paper Executive Summary Context MiFID II and MAD/MAR II implementation projects have been an increasing pressure point on financial firms information systems and their teams. As organization challenges now start to become clearer for CIOs and IT managers, we see the technical issues gradually coming under the spotlight, with Big Data playing a central role. The two promises made by Big Data scalability and flexibility may indeed sound particularly appealing for financial firms. Big Data systems are scalable because their capacity to store and process data grows proportionally to any increase in the volume of data. This is especially important since upcoming regulations such as MiFID II should result in a x increase of the amount of data to be monitored, stored and reported. The second point flexibility comes from the ability of Big Data systems to offer flexible data schemas to seamlessly adapt to new and unanticipated modifications (of both data and data models). This is absolutely key as we see every new regulation widening the scope of asset classes and entities subject to reporting mandates. While in the beginning of 2015, many actors still wondered whether Big Data should be considered to be part of the response, today most (if not all) acknowledge that it is unavoidable. The question has now clearly shifted from should we use it to how can we use it. Problem The how is indeed the true pain point and from our perspective, any answer to the how must be articulated around 3 key regulatory requirements that emerge as the most challenging on your data organizations and workflows: 1

2 1. Large and heterogeneous sets of trade data must be monitored and stored (almost any asset, any format - including voice - from any source, regardless of silos) 2. Trade data must be processed and stored in a way that guarantees a complete and instantly available audit trail (supervisory agencies should be able to access it without delay) 3. Transactions must be monitored in near-real-time (with a latency not greater than 5 seconds) From those key requirements, the following three technical challenges follow : As we said, IT managers familiar with the topic now tend to agree that collecting and storing such very large volumes of data would be difficult to achieve without an appropriate Big Data architecture. Granted, this mere volume issue, on its own, is not the hardest challenge. Many banks have already deployed big data projects on other use cases, some of them even have large scale infrastructures already in production. There is now a complete array of mature solutions available on the market. Hadoop companies such as Cloudera, HortonWorks and MapR or alternate solutions such as MongoDB and DataStax for example, have developed offers around the need for enterprise-ready big data DBMS. However, large distributed infrastructures for data collection and processing have been historically uneasy to reconcile with the level of data consistency and transactional integrity required in a regulatory context. This difficulty can be circumvented through the ability to timestamp and version any modification of a single data point hence turning a consistency problem into a volume constraint. But the final and perhaps most critical layer of complexity comes from the need for a near realtime monitoring of transactions, and rendering of the data (needless to say, this difficulty becomes even more acute in the context of algorithmic trading and especially, high-frequency trading), without compromising on both scalability and consistency. When it comes to market surveillance, monitoring & reporting obligations, any choice in architecture and/or vendor should take a full account of these 3 challenges. Tackling them from the very beginning of your Mifid2 / MAR project will not only prevent unfortunate surprises down the road, it will also allow your organization to take a decisive competitive advantage. Having a centralized, real-time picture of all your transactional data with full analytics capabilities will drive better and more efficient decisions. Bottom line Regardless of the kind of Big Data solution your organization intends to implement to address Mifid II & MAR (in-house project, vendor toolsets, integrated platform ), do make sure that is solves the Scalability / Integrity / Real-Time equation. If it does not, you may end up with a shiny new big data platform which, unfortunately, will not solve your regulatory issues. Contents 2

3 The Data Cost of MiFID II and MAR II A One Size Fits All Regulation 4 How big is your MiFID II data? 5 How long is your MiFID II project? 7 Gauging Your Options Select Use Cases with Scaled Risk Real-time monitoring and record-keeping Real-time monitoring 8 Responding to an inquiry from the regulator 9 Market abuse surveillance system for a firm providing DEA Persona and solution usage 10 Surveillance and alerting 10 Processing alerts 11 3

4 The Data Cost of MiFID II and MAR II A One Size Fits All Regulation MiFID review started in 2011 with an ambition going far beyond improving the initial legislation: with the overarching principles of transparency and accountability, the rewriting of the regulation attempted to address most financial market issues encountered prior to and during the review process. MiFID II firstly extends the MiFID initial scope to all assets, and strengthening existing provisions which had either led to loopholes (OTC trading on BCN, waivers on dark pools) or shortcomings (limited use of the Systematic Internaliser status). For most of those subjects, the level of detail specified in the regulation increases drastically: venue and liquidity providers classification and obligations pre and post trading transparency liquidity definition enforcement of best execution. The new legal framework is very prescriptive in terms of volume, detail, depth, and format of data to process, archive, analyze and publish, including in real-time Other important regulations on market abuse and derivatives clearing and reporting (MAR and EMIR), are also now tied to MiFID, thus creating a comprehensive regulatory framework for all market activities. As a result of this complexity and the willingness to avoid loopholes, the new legal framework is very prescriptive in terms of volume, detail, depth, and format of data to process, archive, analyse, and publish, including in real-time. It is also particularly prescriptive on the granularity of business processes to be controlled, documented, and reviewed. Those requirements extend far beyond regulated markets, to all type of liquidity pools and market participants. 100 x More data Scaled Risk clients estimate their need for data storage to increase by a factor of Mandates Of record-keeping obligations 6 40 Potential number of details required in orders/trades records Fields specified to be recorded by HFT firm for orders (initial decision & executed orders) 20 + Patterns Of Market Abuse Detection 4

5 How big is your MiFID II data? Given the inflation of data archiving and monitoring obligations impacting most market participants, the implementation of a truly scalable system in terms of storage, performance and cost is inevitable. As an example, a global CIB expects the MiFID II mandates to increase the volume data to be reported by 20x. Keep in mind that this data must be fully auditable for 5 years and the regulation also requires any data variation to be available from any future point in time. Regulators have been thoughtful enough to require market participants to guarantee the usability of data, demanding visualization tools and replay features to be available but typical BI tools are not equipped to handle such levels, not even mentioning real-time. For global players of the capital markets, traditional data storage and processing technology just cannot cope with the upcoming regulatory landscape, as they are limited in scalability, granularity and by their exponential cost. Data must be kept for 5 years with a full audit trail and the possibility to replay scenarios Visualization is another strong pain point. Traditional BI tools are simply not equipped to handle extremely large volumes not even mentioning real-time. More data because of new record-keeping obligation The range and scope of the data covered by the recordkeeping requirements as well as the ability to retrieve data through a full audit trail for compliance and regulatory purposes is an obvious call for big data adoption. Those requirements cover critical functions from client service to trading, systems governance, and compliance processes. The data concerned are heterogeneous, generated from different systems and represent huge volume. As the regulation mandates specific format for certain records, the data dictionary management requires agility. In order to be able to use the data for compliance purposes, and possibly to respond to regulatory inquiries, flexible and sophisticated extraction and analytical tools are necessary as well as secured and granular access to reliable data through a full audit trail. The data dictionary function must be implemented in 5

6 More data because of new monitoring mandates Real-time trading monitoring as well as post-trade controls are mandated for investment firms engaged in algorithmic trading with additional specific requirements for direct electronic access (DEA) providers, general clearing members (GCM), high frequency traders (HFT). Specific provisions regarding market abuse surveillance are applicable to algo traders and trading venues. Those provisions require to generate alerts triggered by complex analysis of massive data. Audit trail extends to rules and configuration, allowing to prove exact system state at the time investigated More data because of increased pre- and post-trade transparency Pre-trade and post trade obligations extend to all asset classes. Trade reporting is a standard case of big data requirement, where all trades are pushed to a data lake and a rule engine decides if the instrument, quantity and other characteristics such as message type qualify the instrument for reporting. Existing trade reporting functions should all be migrated onto your Big Data solution. This may seem a hassle, but do keep in mind usage of this data once made public is also an opportunity for participants. Liquidity pools used to be non-transparent (typically RFQ markets or single dealer platform) will generate data that was simply not available previously (in realtime for the most liquid instruments). The new information available will certainly be used to better track liquidity. In the two-tier fixed income markets especially, the publication of dealers best quotes (even partial due to exemptions) will provide dealers with new insights to measure how competitive they are, and buy side firms with tangible indication of the quality of the quotes they receive. Flow business participants will be able to enhance their automated trading tools with machine learning capability using the new data available. 6

7 More data because of renewed exemptions and threshold management Aiming at preventing erratic price movements on physical commodities because of certain speculative strategies on commodity derivatives, position limits (with their specific exemption policies) and position reporting are mandated. Regulator are to collect reports, compute, consolidate data and intervene if needed. In this area of the regulation as in many others where obligations/waiver regimes can be complex, many participant firms will be closely following waivers criteria and thresholds so as to stay away from the more stringent obligations of the regulation. Regulatory references Real-Time Monitoring shall have the capability to calculate their outstanding exposure and that of their traders and clients in real time. - MiFID II Article 17 - Algorithm trading - RTS 6, Article 16 - Real-time monitoring - RTS 6, Article 17 Post-trade controls Record-keeping shall be retained [ ] in such form and manner that [ ] it must allow IT or any other efficient exploitation when the analysis of the data cannot be easily carried out due to the volume and the nature of the data - MiFID II Article 16 (6) (7) Organisational requirements - Technical advices (2.5 & 2.6) - ESMA s Technical Advice to the Commission on MiFID II and MiFIR How long is your MiFID II project? Beside scalability and cost issues, MiFID II brings a number of organizational challenges in both systems and deployment processes. Aging applications built on legacy systems and front to back silos makes it very painful for organizations to implement MiFID s requirements in a reasonable time. IT departments have already explored and experimented Big Data Technologies They approach Big Data either with a global data governance strategy but also, and sometimes more successfully, through a committed bottom up Proof of Concept approach, whereby teams are exploring use cases and vendors. But while Big Data technologies are notoriously more flexible than traditional solutions when they are properly set up (in essence, they do not require existing applications to be fundamentally altered or resized), their implementation and adaptation to regulatory use cases can become extremely painful. We have seen several projects where the transition from proof of concept to production took more than 3 years (against an initial estimate of 9 months), with some others being dropped after a year or two. 3 years? Client s in-house project took 3 years instead of 9 months initially expected with incomplete results. Gauging your options Off-the-shelf distributions of data crunching technology initially designed for advertisement prediction have not been designed for real-time, secure and accurate results as required in a regulatory context. Gathering data and processing them according to the MiFID specifications requires a much strongly normalized processes. Your solution of choice should include the additional layer to meet those mission critical objectives: it should include data dictionary versioning, real-time capture and output, bi-temporality, transactionality while at the same time leveraging on functions such as Mine and Search, Machine Learning, rules engine, and as such is fully compatible with existing big data distributions 7

8 Select Use Cases with Scaled Risk 1 Real-time monitoring and record-keeping Real-time monitoring of its trading activity by an investment firm engaged in algorithmic trading as well as post-trade controls are essential to mitigate operational and financial risk. Since Knight Capital went bankrupt because of a dysfunctional algorithm, that kind of threat is not hypothetical any more. In addition, investment firms should be able to demonstrate to the regulator that they have the relevant systems in place and that all the mandated information was recorded in their system. Persona and scenario A sell-side investment firm engaged in listed options market making uses Scaled Risk for real-time monitoring and post-trade controls. Scaled Risk can generate alerts within a one second delay of the relevant event, far below the required five seconds delay. Real-time monitoring Real-time monitoring of algorithms aims at detecting signs of disorderly trading from a cross-market, cross-asset class, or crossproduct perspective. Real-time monitoring and continuous posttrade controls are based on the analysis of heterogeneously formatted data: - Real-time orders/trades generated by the market making algorithm - Real-time market data - Reference data - Historical trading data Various rules and metrics to be monitored: - Trading venues requirements (circuit-breaker parameters, - maximum order to trade ratio, maximum message rate, maximum number of quotes/orders updates per second ) - Market making obligations - Investment firm rules regarding position limits, maximum market exposure, P&L - Moving averages of notional value traded - Client credit line update Scaled Risk allows to work with real-time data as well as static/batch data and to reconcile different formats in order to monitor the market making activity. 8

9 Scaled Risk rules engine enables users to configure real-time alerts. Different configurations can be applied to perform distinct tests from the same data or to adjust trigger values. The trading desk and the risk function can, if needed, configure their own alerts. Once an alert is generated the system uses the business process workflow to document the remedial actions taken by users. For real-time monitoring, the rules engine can, for instance, be set up to generate an alert when the algorithm exceeds 80% of the maximum message rate allowed by a trading venue in order to prevent exceeding that limit. Once an alert is generated it can feed the trading application and be raised to the trader in charge of the algorithm. In addition, Scaled Risk analytics allows to investigate further whether remedial action is needed. An alert pertaining to abnormal orders/quotes update frequency can be further investigated by comparing historical data, computing mean activity over a defined period, comparing with previous peaks. One post-trade control alert can similarly consist of signaling when approaching a position limit set by the investment firm. Responding an inquiry from the regulator The competent authority overseeing the investment firm trading desk activity investigates the causes for disorderly trading (including trading halts triggered without obvious reasons such as a news announcement) that happened on one of the instrument for which it has market making obligations. The trading desk / compliance function are able to leverage Scaled Risk search analytics and reporting functions to demonstrate that it has fulfilled its obligation as market maker and has not caused disorderly trading conditions. To do so, the trading desk is able to replay the sequence investigated by the regulator by retrieving orders and trades generated by its algorithm to demonstrate it maintained two-sided quotes and the prevailing market conditions (market data) at the same time. It can also generate reports about the alerts that were potentially generated during the sequence under investigation (and the corresponding remedial actions taken), any relevant voice recording, time series of the firm net position and corresponding position limit, and market risk calculated by its risk systems. The Scaled Risk bi-temporality feature ensures that the accurate data prevalent at the point(s) of time of the investigation is retrieved (for instance if there were several 9

10 2 Market abuse surveillance system for a firm providing DEA An investment firm providing direct electronic access (DEA) to trading venue(s) is not a mere gateway to those venues: the firm is responsible for monitoring the trading activity of its clients, including the surveillance of potential market abuse. If the proper systems are not in place, the firm is at risk both from a regulatory and reputational standpoint. Persona and solution usage Our participant, a GCM, provides DEA access to trading venues to algorithmic trading clients, and executing brokers to execute their own client s trades. With the MiFID II obligation to monitor their flow of orders and transactions for signs of potential market abuse, they have put in place a surveillance system based on Scaled Risk and operated by the firm s compliance department. The surveillance system relies on two core features: - Detecting signs of potential market abuse - Investigating and managing alerts triggered by the system Surveillance and alerting To detect signs of potential market abuse, the compliance department processes the entire order flow of the firm on all markets in conjunction with multimarket, multivendor data and news. Various sources of data are reconciled and put to equivalent format on read using the dynamic data model. Given the amount and granularity of data (all modification, cancellation, execution of orders), Scaled Risk surveillance provides a system which is highly automated and fully scalable. The surveillance system includes a library of about twenty predefined checks based on the existing regulation. Those tests are based on abuses and indicators of manipulative behaviour such as defined in the 2014 Market Abuse Regulation. Specific indicators of abuses related to electronic markets such as spoofing, layering and quote stuffing, are also monitored. Certain key parameters of those tests can be adjusted to properly configure the system. In addition, the compliance team has the ability to develop their own tests if needed: they first identify key events combinations and thresholds and set the relevant detection rules using their dedicated interface. The application provides the necessary flexibility to adapt to future changes in regulation or in trading strategies. Back testing and replay allows for a smooth calibration and minimize false positives and false negatives. 10

11 Processing alerts For each alert, Scaled Risk surveillance provides an explain report providing the underlying data and an explanation of why the alert was triggered. If further investigation is necessary, the integrated online analytical processing (OLAP) can be used to generate new analytics to put the alert in the right context. The replay function for a specific sequence of orders and market data provides an efficient way to investigate/visualize suspicion of market manipulation. Further investigation may require a certain level of mining on client data stored in the data lake or in the public domain: history of past suspicious or false positive patterns, relevant voice records can also be easily checked. Taking advantage of cell granularity, access permissioning provides adequate security to make sure that each authorized user only has access to the data he is allowed to read/write. The Scaled Risk process workflow management tool allows the predefined alerting workflow to support the compliance team. Once an alert is generated, several statuses are available as they all should be processed. The compliance team member in charge of managing the alerts can choose to ignore an alert if it is deemed to be nonrelevant or open an investigation. The status of an alert under investigation can be further refined as it can be assigned to another team member, closed, or escalated. Eventually a suspicious trading report can be generated to be transmitted to the regulator if needed. Whatever the outcome, the alerts, reports and additional data gathered will be recorded, and each step regarding the alert management will be fully auditable by the system. The compliance also has the ability to customize the pre-defined workflow if necessary. Another Scaled Risk functionality further enhances the firm surveillance tool: machine learning can help the compliance function to detect complex patterns and signals by detecting correlation within the big data set used for surveillance. 11

12 About Scaled Risk Scaled Risk provides financial firms with a fully integrated software solution for managing risk, market surveillance & fraud at a very large scale and in real-time. Built on a Big Data storage platform, Scaled Risk ensures the level scalability, flexibility and transactional integrity required by missioncritical functions. Its intuitive interface makes it easy to operate by business users who can create pivot tables, charts & graphs, alerts and simulations in a breeze. Created in 2012 by financial risk & big data experts, Scaled Risk is now trusted by leading global CIBs and trading venues. Would you like to know more? Contact us to schedule a demo. For press inquiries, please contact Edouard at pr@scaledrisk.com SCALED RISK 12