Large financial institutions often rely on a complex array of trade surveillance systems, many of which have developed incrementally in response to various regulatory requirements rather than through a cohesive, long-term strategy. As a result, the control frameworks across different products and asset classes have evolved over time, leading to a patchwork of disparate systems and approaches. This fragmentation poses significant challenges to achieving unified and efficient surveillance across the institution’s operations.
Since MAR regulation in Europe and increased expectations in the US, the focus for the last decade has been on increasing the coverage of controls, both in terms of business lines and scenarios covered. In this rush for coverage, little focus has been given to the governance of data. Crucially, in almost all cases, this evolution of the systems and processes involved will have had very limited focus on the governance of data passing into and through the workflow. It should, therefore, be clear that this presents a considerable risk of trade and order records being dropped and, therefore, of suspicious activity being missed.
The industry now finds itself under significant regulatory pressure to change, and to introduce proper governance and auditing of the flow of data through surveillance systems. This pressure is most obviously manifested in the fines totalling USD 448 million imposed on JP Morgan by the Office of the Comptroller of the Currency (OCC), the US Federal Reserve and the Commodity Futures Trading Commission (CFTC). The pressure will likely also manifest in major fines at other financial institutions.
In the light of this pressure, and the need to do something, it is tempting to try and retrofit data governance into each of the systems and controls individually. However, this is likely to prove inefficient and expensive and is unlikely to be future proof (and therefore will simply result in the issue resurfacing at a later date). In short, retrofitting data governance into each system separately and in an ad hoc way is likely to fail.
TradingHub considers that there is a better way.
The core of the problem
In financial institutions, trade surveillance is effectively the end of the ‘production line’. The trade surveillance calculations rely upon receiving information from numerous other upstream sources (trades from trade capture systems, orders from OMSs, RFQs and (potentially) market data and various types of static data from in-house sources and third-party providers. Inaccuracy, or incompleteness, in any one of these, could result in lost records and resultant failures to identify instances of malfeasance or, in extreme cases, components of the entire surveillance programme being ineffective.
Whilst trade surveillance programmes rely on many upstream systems, few if any, downstream systems rely upon the outputs of the trade surveillance process. Indeed, the program is extremely unlikely to produce feeds to downstream systems other than alerts sent to case management systems. This means that no other departments are checking the results of the trade surveillance programme, and the responsible individuals are forced to self-determine if the programme is working as designed. The problem of self-determination is then exacerbated as it is impossible to say what the correct number of alerts a surveillance programme should be generating (and how stable that number should be over time or across business lines) - is a daily generation of three to five ramping alerts better than no alerts being generated? Should it be twenty? Thirty? Does the absence of alerts mean that the trading desks are behaving properly and that no market abuse is taking place? Or does it suggest an error in the calculation logic or missing data and that market abuse may be taking place unnoticed?
Other departments, such as the trading desk, risk management and finance, have good ways of checking the data that they receive and the outputs that they produce. If the finance team receives corrupted trade data and calculates an incorrect Profit & Loss (P&L), the traders will undoubtedly complain immediately. If the risk management department generates the wrong risk and Value at Risk (VaR) figures and this shows limit breaches, alarm bells will ring throughout the institution. Variation margins are agreed daily with counterparties and exchange clearing houses. Cash is settled and confirmations are exchanged. This series of daily interactions between departments, customers and counterparties produces a multitude of cross-checks that ensure trade populations are correct and that every trade is properly represented in the firms’ systems.
Furthermore, the process of risk managing a trading desk results in potentially huge offset positions in different instruments that, in aggregate, net to a total position which can be close to zero. These are, therefore, in essence, finely balanced systems with integrated feedback loops. This is recognised in P&L and VaR figures, which, despite the enormous gross notional amounts, will end up being relatively close to zero. In such a system, any error (such as missing trade population, inverted notional amounts, etc.) is likely to create obviously erroneous P&L and VaR numbers (in contrast to trade counts, which may still look sensible).
In contrast, these useful processes and cross-checks almost never include the outputs from the trade surveillance team; they operate independently of this useful noise and derive no benefit from it. Furthermore, in the case of unfilled trade orders, they are probably the only people in the organisation who have the slightest interest in this data; other departments have no need for it and historically have made little effort to capture and store it.
Finally, trade data is usually captured in multiple systems, each with its own idiosyncrasies and each with its own cycle of enhancements and releases. New products and transaction types are released periodically (sometimes requiring complex structures or trade types to be decomposed into components, thus blurring their provenance). Outside of trade surveillance, these changes rarely create problems; the checks and balances described above (such as VaR and P&L) exist to prevent trades, new and old, from going missing or being booked erroneously.
Questions that require an answer
It therefore appears that there are five key questions that a successful trade surveillance data governance programme needs to be able to answer. These are:
The first two of these questions deal with the quality of the data that a surveillance programme ingests. The final three questions lay the foundation for a framework of data governance and data lineage.
The inbound data set
Answering the first two of the questions above requires us to ensure completeness and accuracy of the inbound trade and order data set. There is no quick fix to solving this problem however, there are a number of partial solutions that, when employed together, can give a degree of confidence that the inbound data is correct.
The broad categories of the types of checks that can be employed are shown below, with the list running from the simplest to the most sophisticated:
Further thoughts on some of these approaches are considered in the following paragraphs:
In a target state, all the above checks could be performed daily and automatically as part of a surveillance process; indeed, a best-in-class solution to the data governance problem would feed the compliance workflow automatically (for example sending alerts directly into an inbox or ticketing system). However, such analysis is not simple to generate and takes time and cost to implement.
For these reasons set out above, TradingHub proposes that implementing data governance controls broadly (rather than individually to each system) is the logically correct thing to do.
Data governance within surveillance systems
Individual surveillance systems are complex, with many processing and calculation steps. Joining trade and order records with market data, static data, exchange opening and closing times and other information creates opportunities for joins to fail and for trade records to be dropped. Dropping records means that they will be ignored by one or more individual controls and that suspicious activity could be unmonitored.
A potential solution to this is for each individual system to have checks implemented at each step in the calculation process to identify dropped trade and order records and to produce an audit trail showing these. Where this is not already the case, such checks could be retrofitted.
Alternatively, and better still, it should be possible to introduce features into a surveillance framework which would automatically record any occasion when a critical data element (like a trade or order record) is rejected by a given set of control logic. This would produce an audit trail for each trade and order record, the results of which could be consolidated and output as a report identifying issues in each step of the calculation.
If such features were to exist, all future enhancements and new controls would benefit automatically from these features without the need for further programmer time or parameter setting. Crucially, such framework features would address data governance within a surveillance system once-and-for-all, meaning that future control-scenarios will automatically benefit from best-in-class governance reporting.
Conclusion
Data governance has become a key point of focus for regulators. This focus is likely to be sustained and is also likely to result in further large fines for financial institutions. As such, the problem must be addressed. Addressing the problem by implementing data governance to each surveillance system individually is likely to prove inefficient and expensive and is unlikely to be future-proof. The problem should, therefore, be addressed holistically and implemented in a consolidated manner that adapts to future changes.
The size of the task can seem unduly onerous, but data completeness and accuracy checks already occur across many departments in large and small financial institutions; these checks can be adapted and implemented. Indeed, the fact that a surveillance system needs to see all orders placed and all trades executed allows an institution to ask intelligent questions about the input data to ensure that the data received is likely accurate and complete.
Furthermore, the use of big data calculation frameworks (such as a calculation-graph approach) means that a system can bake-in data governance to all operations defined within it.
The above two points work harmoniously with each other. The target state should effectively be a walled garden containing high-quality data, which also benefits from strong data governance reporting.
This approach changes the problem from one of second fixing data governance onto a multifarious trade surveillance estate and instead becomes one of porting controls into a single system where the data governance problem has already been addressed (and does not need further work). Such a shift not only results in surety of data integrity but comes with a significant reduction in the total cost of ownership of the trade surveillance programme itself.
Programme effectiveness testing
Data governance is one aspect of a much broader question: how successful is the trade surveillance programme? Such a question is very hard to answer. Certainly, it is easy to consider scenarios in which one can identify weaknesses and even the failure of such programmes (such as regulatory enforcement and the imposition of monitorships). However, success is much harder to manage.
The following are a few indications of a programme that is likely to be operating well and has a reduced risk of suffering failure:
Limited number of surveillance systems with all controls under a single framework
A complex and fragmented surveillance estate is likely to be hard to own, modify and keep up to date (and be expensive to maintain). As discussed at length above, problems like data lineage are much easier to solve in a simple framework than in a complex one.
Successful model review and approval
A degree of assurance can be felt when all the models used in the programme have been through a rigorous review process. Furthermore, models which are able to operate across all products and all asset classes with minimal customisation and/or adaptation imply well-thought-through control logic and inspire confidence when new products or markets are introduced.
Regulatory example testing
Demonstrating that the system catches standardised examples of abuse and that it captures known cases of regulatory enforcement, and criminal prosecutions will further evidence robust controls. Such examples (or adaptations thereof) should ideally be recalculated daily using current market data to confirm that the system settings remain appropriate irrespective of market conditions.
Threshold testing
Controls often employ alerting thresholds whereby alerts which produce an alert size below the threshold are ignored. Whilst this makes sense, such thresholds should be tested regularly (potentially daily). Such testing can, and perhaps should be coupled with standard examples and enforcement cases (explained above) to prove not just that such examples will trigger an alert but that that alert meets the threshold test for analyst review and potential escalation.
Below-the-line sampling
A further method of demonstrating that alert thresholds have been set appropriately is to randomly sample alerts which fall below the set threshold. Various statistical techniques exist to generate the sample set to be tested.
