ADDRESSING TECHNOLOGY DEBT IN THE WAKE OF REGULATION

Craig Talbot, Global Head Trading & Connectivity at Hatstand

Recent years have seen unprecedented changes to the technical infrastructure of financial institutions. Many of these changes have been driven by regulatory mandates drawn up in response to the financial crisis of 2007/8. As the Global Systematically Important Banks (G-SIBs) battle to comply with the January 2016 deadline of the Basel III Directive BCBS239, it is interesting to reflect on how many of them have had the time or the appetite to review whether the early implementations and changes made to their systems are fit for business.

With falling revenues, fewer clients and changes in market behaviours, those banks who have regularly reviewed their business strategy with mindful consideration of their accumulated technology debt, will be ahead of the competition once the regulatory dust settles.

Technology Debt

After the Global Financial Crisis of 2007/8 it became apparent that the risk exposure data that banks relied on to make decisions was compromised; the data was inaccurate. The banks did not have the technology in place to aggregate and report such data quickly. Each bank subsequently reviewed how data was collected, managed and reported. This was followed by a series of internal projects to aggregate the data, fill in the missing gaps and report the risk exposure.

There is no doubt that huge business and technical efforts have been made to strengthen the banks’ risk data aggregation capabilities and internal risk reporting practices. However, in January 2015 the Basel Committee on Banking Supervision published its progress report showing that nearly half of the 31 G-SIBs said they would not be fully compliant by the January 2016 deadline, being unable to comply with at least one of the 14 Principles of BCBS239.

Furthermore, the banks have reported their reliance in part on manual workarounds to achieve their existing level of compliance. In the early days of aggregating risk data, it is understandable why manual workarounds or bespoke conversions were implemented. The lack of a company-wide governance policy for trading systems in general has resulted in a diverse landscape of gateway connections for trading and market data, protocols, vendors and standards across different departments linked to trading activities or asset classes.

Given the diverse, disparate and decentralised starting point from which banks have been building their compliant risk systems, it is unsurprising that they have been accumulating considerable technology debt. Technology debt in this context is the accumulation of outdated systems still in use or where the original reasons for implementation have changed and the product is no longer fit for purpose. It could be software code itself or the inappropriate or outdated use of workarounds implemented around and including trading technology applications.

Repayment of this debt can be the overall cost of replacing outdated or inappropriately used systems, the price of which would increase the longer it is left. It can also be the direct financial losses incurred as a result of system mistakes, trading and reporting errors, as well as fines. Furthermore, debt can be paid in client perception and reputational loss as well as lost opportunities due to excessive rigidity.

Tactical mitigation and manual workarounds cannot always be avoided when core components are deeply embedded and cannot easily be changed. Technical managers are aware of the limitations of each workaround but there must be a clear way to quantify each and every one when communicating to the business sponsors. Part of the business development strategy must include future operational risk visibility incorporating the accumulation of technology and process debt. This debt could be very costly and damaging to the business in the future.

Revolution not Evolution

The post 2007/8 financial crisis regulatory changes have applied a form of evolutionary pressure on the banks. Their response has been to make small changes to the organism with adaptations of the existing technical infrastructure in order to survive in the new environment.

Like evolution, the regulatory changes are indiscriminate. This will result ultimately in some banks evolving into dominant species. Other banks may become extinct – at least in some areas of business. Some banks, perhaps the ones with smaller and simpler systems, may realise that building workarounds or bespoke patches for old legacy systems in small evolutionary steps would ultimately accumulate an unacceptably high level of technology debt.

A strategic vision is needed to take fewer and bolder revolutionary steps that accumulate less technology debt to leave systems robust, flexible and reliable. The systems are then better able to cope with any future regulatory, business and technical pressures.

Realising where in the complex trading infrastructure the revolutionary change points are is a challenge. Focusing on reducing the system complexity and increasing centralisation is key to uncovering them.

Real-time Risk

Much effort has been made to identify the many touch points within trading systems from where to collect the relevant pre-trade and post- trade risk data. This can come from multiple single market trading servers and their risk control modules. Data can also come in different formats and from decentralised and regional locations. The pre-trade risk modules that feed their data into aggregated databases sit side-by-side or in-line with the order-entry application server, meaning each one is blissfully unaware of the trading activities of the other markets. Some vendors or internally-built trading systems can support a truly globalised real-time order book. However, implementing such an infrastructure in the past would have been unnecessarily expensive, added unacceptable latency and would have lacked the governance practices to control it.

When reviewing risk architecture for compliance, the focus has been on data collection and reporting. A tactical rather than strategic approach was initially taken, doing what was required to tick the regulatory boxes. As compliance education within financial institutions matures, a need has arisen to review the technology that controls risk at the execution gateways. It is important to gauge how fit for purpose it is now and in the future and how much of this technology is good enough, and will not result in unacceptable levels of technology debt.

None of the 14 principles of BCBS239 cover automatically adjusting trading risk monitoring tools in real time. They do focus on risk reporting. As more time is spent looking at risk systems and exposure, the next logical step would be to automate risk sentinel parameters. These risk sentinels are the trading risk modules that have the power to stop trades if limit thresholds have been breached.

With more centralisation and a desire for simplification, banks will look to implement ‘smart’ risk sentinels, to replace the outdated, siloed and localised ‘dumb’ risk sentinels that only know their market in isolation and can only take modified limit instructions from human controlled administration screens. While some trading risk modules have open Application Protocol Interfaces (APIs) or can read global order book databases, there are historical reasons why the technology has not matured or been implemented. Reasons can include cost, practical re- architecting, governance and latency issues.

With the wealth of risk data now available and better governance across trading systems, the ability to automate trade risk modules in real-time across multiple exchanges and currencies is now possible. The alternative is to keep relying on high touch and slow human interventions.

Business Intelligence

There is no doubt that once the regulatory dust settles, the sheer volume of data available to analysts and sponsors will be unrecognisable in comparison with 5 years ago. Just how useful this data is in helping each business make informed decisions will depend on the chosen method adopted when building the data management systems. Those that adopted the revolutionary or centralised methodology will be much better placed then those burdened with the evolutionary decentralised approach.

Creating a robust and centralised data aggregation facility is essential to identify risk exposure. However, it can also be used to gather trade lifecycle data, client connection and trading behaviour data in addition to risk data. Together this can all help to develop a clear strategy.

Robust quality assurance processes in data collection and centralised governance on standardisation and data protocols will help to reveal previous risk patterns and allow early alerts to be flagged when fledgling patterns emerge. This will provide business decision makers with a new tool to review and assess the trading practices of each client and desk.

Changing market conditions have also brought to the surface the need to know at a granular level who is trading what and how often and, equally important, how much each type of instrument costs to service in respect of market fees together with database and infrastructure hosting. Banks will have already have done some divesting to drive down capital costs. To have a clear picture of what each client does, how they trade and how profitable each market, segment and instrument are could result in ‘trimming off the fat.’ Decisions on which clients to drop and indeed which instrument, markets or segments to also drop or invest in would rely in part on the business intelligence collected.

Conclusion

A strong, symbiotic relationship between business and technical strategies is key when embarking on a programme to identify revolutionary change points in what could already be a highly developed and evolved technical architecture. A strong understanding of the already accumulated technology debt is needed together with a clear appreciation of how this will cripple further progress and apply excessive rigidity to the systems. Principle 6 of BCBS239 states that risk systems should be adaptable. Manual workarounds built on decentralised systems cannot truly be described as flexible and adaptive.

Nobody knows when the tide of regulatory pressures will ease but it will be the banks with the clearest, most progressive strategies built on the solid foundations of simplified, centralised systems and governance with minimal technology debt that will be ahead of the competition.