Despite all the hype RegTech companies still face several challenges. We explored the key obstacles in an article a few months ago. We also presented you with the experiences of RegTechs and the problems they have to overcome. Now it’s time to hear from potential RegTech clients, i.e big financial institutions to find out how the other side of the table sees things. Jonathan Jordan has been working for industry giants like UBS, Barclays and RBC and gives us an inside account how banks think about RegTech.
A few months ago we published a post about the obstacles that RegTech’s will need to overcome in order to move to the ‘next level’ and focused on six challenges that we, from our experience, find are the key barriers to wider adoption and implementation of RegTech solutions. Subsequently, we sought input from RegTech firms directly to see whether they agree with our assessment as to what the biggest challenges are, and whether they have any additional experience that would be worthwhile sharing in this context. There are many approaches to marketing your solution and it is of course important to devise a sound strategy. This includes knowing who your audience is, and also what customer target will be the most sensible starting place. We know that ideally many RegTechs would like to see their solution implemented by banks and other large financial institutions as this would allow for it to be rolled out on a massive scale. Typically, having such an institution on the client list is on its own a great advertisement feat, which is likely to attract further contracts. The obstacles facing a RegTech will differ depending on who and what is being targeted. This article seeks to build on the first story, which highlighted perhaps more generic obstacles, and to explore whether there are any specific obstacles that are pertinent if you are hoping to sign a major financial institution. The finance industry is entirely aware of the potentially transformative implications that technology solutions present, however, recognise that implementation raises important questions and considerations for regulators and financial institutions alike.
Firms are very aware of the benefits and possible cost reductions that can be derived from implementing tech solutions and products to replace current processes and resource, however, the level of investment required to replace existing legacy IT systems with new technology may deter adoption as at any given time funds are allocated using a risk based approach. In other words, if another more pressing matter (e.g. MiFID II) needs implementing then everything else switches over to the ‘nice to have’ from the ‘must have’ category. Please also be aware that financial institutions of a certain size are always likely to consider whether it is more efficient to build a similar solution in-house, or alternatively want to own a stake in the incumbent technology (maybe because they want to maintain a competitive edge over other market participants).
The ability for RegTechs to demonstrate that their products have the capacity to handle large volumes of time-critical data across multiple institutions and jurisdictions. Research and testing go some way as proof-of-concept, but doesn’t carry as much weight as a proven track record. I think it worthwhile highlighting here the FCA’s regulatory sandbox which is an initiative that allows firms to test innovative products, services or business models in a live and safe market environment. It is part of Innovate, an initiative the UK regulator launched in 2014 to promote competition in the interest of consumers. On RegTech, the FCA Innovate site states that it aims to ‘facilitate collaboration, knowledge sharing and conversations around new technologies that support better regulation’.
Even where costs of new solutions are likely to be lower than existing patch worked legacy systems, another obstacle that RegTechs will face is the issue of how the new solutions will interact with legacy systems, as well as other new solutions that may have been brought into to serve an overlapping purpose. If this is too problematic it will serve as a barrier to adoption.
Security and integrity of a third party solution will always be of upmost importance, and were it to suffer technological fault or hacking, the consequences could be detrimental. Both in terms of existing contracts, but also reputational damage for future contracts. As such, it is critical that RegTechs understand the risks, as well as maintain appropriate standards (such as robust cyber-controls with strong encryption and cryptography protecting data).
Regulatory and legal incompatibility
A key challenge is to determine how the existing, and internationally unharmonised, regulatory framework may apply to the areas that will benefit from your product, and whether there are any rules which may act as a barrier to the use of the technology. I stress existing, because it is not yet clear how existing regulation will over the hopefully near term future be adapted or replaced with new regulations created in light of the potentials that technological advances brings to the industry. From a legal perspective consideration needs to be given to the corporate, property, privacy and securities laws as they may apply and doing so across multiple jurisdictions. In respect of differing legal and governing regulatory frameworks of particular notice is treatment of data privacy including the nature of the data and method of storage; the location of such storage and processing; retention; and accessibility of the data by controllers, owners and users.
As the industry as a whole looks to incorporate new technology to become more efficient, firms may not be able to afford to reinvent infrastructure or take risks on new technology until proven. Regulatory support may prove essential in the full adoption of available technology.
Jonathan Jordan is a compliance professional in investment banking with a keen interest in technology and innovation and their potential to change the financial industry as we know it. You can follow Jonathan on Twitter at @j_e_jordan