31-10-2018 | POINT OF VIEW
Why RegTech is not a technology problem

Over the next five years, banks’ spend on RegTech will grow over fivefold, from $18 billion in 2018 to $115 billion in 2023. This shouldn’t be a surprise: trapped between low profitability and high regulatory burden, finding better ways to streamline and simplify compliance and risk management seems like a must.

Globally, misconduct costs have totalled $320 billion – capital that otherwise could have been used to support up to $5 trillion in lending. This has also resulted in around 20% of all financial services staff dedicated to risk and compliance.

While the onus is on banks to use technology-enabled solutions to address regulatory challenges, it was venture capital and private equity funds that seized on this opportunity, with $5 billion raised across nearly 600 deals over the past five years. Large banks have followed suit, embarking on setting up incubators, accelerators, as well as offering funding opportunities to young RegTech firms.

Perhaps part of the reservations among incumbent banks is the lacklustre return on investment in RegTech and that the expected benefits are not being realised. There are many reasons for this, though the common cause appears to be rooted in banks’ approach to investing in RegTech – they have often failed to heed the lessons learnt from previous investments in cutting-edge technology.

To achieve and maintain returns on investment in technology, RegTech included, firms need to treat innovations and technology solutions as first and foremost business problems. Three elements are key to making this happen.

The first is to define a clear strategy for the business in question, whether it be the entire Risk function or a subset such as Transaction Monitoring. Without this strategic vision for the future, it is not possible to make an effective business case for investment decisions, gaining internal support and fundamentally articulating why and how the return on investment will be realised.

RegTech solutions are often seen as a point solution to a specific problem. A common example of failing to do this can be found in the use of 3rd party analytics products for transaction monitoring. The promise of using machine learning to trawl through vast quantities of data and prioritise short lists of suspicious transactions and customers is appealing. However, the reality of a drastically increased workload for investigations teams along with having to manage and support another vendor product is significantly more expensive and resource intensive with very little added value.

Once the business strategy has been defined, senior management should then agree on the future-state operating model that can enable the business to achieve its strategic ambitions. A clear understanding of what is required of the technologies underpinning new capabilities will be critical. But this requires a clear articulation of the roles and requirements of each operating model component – such as data, technologies, analytics capabilities and skills – and a thorough understanding of how these will interact.

Finally, having defined the core strategy and its constituent parts, it is up to the business to design a cohesive plan to deliver on this vision. Translating these requirements into both an initial assessment methodology for selecting the technology and a means by which to measure the ongoing business value provided by the implementation, is one of the key tasks.

Another key implementation decision is the ‘revolution or evolution’ debate. This centres around the extent to which the current operating model components will feature in the new vision, in particular with regards to legacy infrastructure. Removing legacy systems may increase initial programme costs, but it is often the difference between success and failure.

Banks will continue to invest in RegTechs, chasing the clear benefits and capabilities that they can provide. However, only by understanding exactly what they require from a technology product will they be able to select and integrate them into their operating model and extract their true value.

@p_f_g - Parker Fitzgerald