Financial Supervisors and RegTech: Four Roles and Four Challenges

The use of information technology (‘IT’) to constrain people’s financial behaviour is as old as writing systems: as Yuval Harari recounts, one of the uses of cuneiform tablets was to document contracts (including financial ones) among private parties, with the then ‘proto-supervisor’ acting as a repository of such contracts, thereby reducing the risk of non-performance. Fast forward 5000 years and it is still the case that advances in information technology have been swiftly deployed not only by financial institutions to make their operations more efficient, but also to improve firms’ compliance functions and financial supervisors’ oversight activities.

That RegTech, as the use of IT in compliance and supervision/regulation is now labeled, is nothing new doesn’t mean it is not a game-changer, given the revolutionary nature of current IT developments, such as data scraping tools, big data analysis techniques, and artificial intelligence or machine learning algorithms, which together allow for the aggregation and effective use of amounts of information that flesh-and-blood compliance officers and supervisors could never muster and master.

Four types of RegTech

In order to understand what the potential roles of supervisors are with regard to RegTech, a few words are useful about how RegTech can be used by market players and policymakers. We can distinguish for this purpose between Operations RegTech, ComplianceTech, OversightTech, and PolicymakingTech.

First of all, market players may use RegTech as part of their operations software solutions (‘Operations RegTech’) or as part of their compliance programs (‘ComplianceTech’). Some compliance functions will require specific software. Such may be for example the case for reporting activities that require the aggregation of data from different departments or subsidiaries. But when it comes to using software to set legal boundaries to operations, for the purposes of better ensuring compliance Operations RegTech and ComplianceTech should be integrated into one single software. Yet, even when that’s the case, the way the integration of the two functions into one single product will take place will vary, depending on how compliance strategies intertwine with business ones at the individual institution. Some financial firms may use RegTech as a built-in limit to FinTech applications: the software that runs, say, a trading strategy has RegTech parameters that limit the set of available options by excluding those that are deemed unlawful.

Because the legal boundaries will be set most likely within a grey area that is neither certainly legal nor unquestionably illegal, each financial institution will draw the line depending on its own (risk) culture and the relative strength of compliance departments vis-à-vis their core business units. At less ‘relaxed’ firms, products with a RegTech component will stop you just before the point the software developers (and their legal advisors) predict that your behaviour would be detected by the supervisor as suspicious. At more regulatory-risk-loving market players, you would be stopped just before the point where the supervisor is predicted to find you in violation of the rule. The extreme case will be for the limit to kick-in no sooner than at the point when the expected benefits from the conduct are predicted to become lower than the expected cost of a fine (taking its probability into account).

A potentially important distinction for policy purposes may prove to be between proprietary RegTech software, outsourced tailored software, and standardized, market-wide solutions. Today, we observe all these models, with a certain prevalence of in-house products for Operations RegTech, for example in the area of algo-trading. The main question for policymakers will be whether regulation and supervision should extend to providers of (FinTech and) RegTech products themselves: given the ever deeper compenetration between operations and compliance, on the one hand, and software solutions, on the other, it may well be that the supervisor will only be able to intervene in market processes in a timely fashion if it has a view over, and a grip on, product designers themselves. Think of product governance: if the product is a code, it may be necessary to extend product governance rules to those who write the code themselves. After all, something similar has happened with algo-trading in Europe: its pervasiveness in the securities markets has led policymakers to include algo-traders within the oversight perimeter. (As a less restrictive alternative, one could think of a code of conduct, whether industry-promoted or supervisor-sponsored, for software developers in this field.)

The key to effective OversightTech, or the use of RegTech by supervisors for oversight purposes, will be for the software to be interoperable (that is, able to dialogue) with ComplianceTech products and possibly even Operations RegTech itself. Interoperability may well have to be forced, which would mean the supervisor having a say over some of the contents of software products. The risk is of course that innovation in this area will be curbed or distorted in a direction that is suboptimal for all market participants, given that the supervisors’ degree of risk aversion may be greater than what is optimal for society as a whole.

Finally, RegTech can be used to improve the policymaking process, by allowing for more accurate cost-benefits analysis, for instance by using agent-based computational models to improve stress testing or for simulating the effects of a given rule. For sure, the analysis will be fancier and therefore possibly more resistant to challenges in court in countries where cost-benefit analysis is a legal requirement. Yet, it is uncertain whether the outcome will also be better than if less sophisticated tools were used.

Four roles for the supervisors

The supervisor can play at least four different, but not mutually exclusive, roles in RegTech: it can act as a developer/user (and seller) of RegTech products; it can be a buyer/user of products developed by others; it can act as a facilitator and coordinator of market developments (similarly to what securities regulators have done with regard to eXtensible Business Reporting Language, or XBRL) or, as hinted before, it can act as the supervisor of RegTech firms.

Whether the supervisor can act as a developer of RegTech products depends on whether it has, and can retain, people with the required skillset among its ranks. As hinted below, this will prove difficult.

If supervisors act as buyers, they may purchase standard products, standard products with some tailored specifications, or fully tailored ones. In the former two cases, one important distinction is between RegTech products that can be used by both supervisors and market players, and products that are only sold to supervisors.

Given the need for interoperability, the former case may be more frequent, but implies the risk that developers, when in a position to exploit information asymmetries with supervisors as customers, rather cater to the interests of market players (the larger and higher-margin market) than to those of supervisors’.

When there is an element of tailoring (and the more tailoring, the more serious the problem), the challenge for the supervisor is to ensure an effective contractual governance of the relationship with the developer: the contract between the two is likely to be incomplete, with all that follows in terms of ex post opportunism and hold-up problems. For the reasons outlined below, this may well turn out to be the cause of most serious headaches for supervisors.

Four challenges for the supervisors

Supervisors face four main challenges in their transition to the new RegTech environment: a human resources challenge, a governance challenge, a cybersecurity challenge, and a core-operations challenge.

I have already discussed the human resources challenge on this Blog (here). The governance challenge mainly stems from the fact that, for the predictable future, the people at the very top of the supervisor’s organization will most likely have insufficient skills to fully understand RegTech products and their implications. Things may not even be better if only one or two people at the top have a clue of RegTech’s implications. The risk is that the one who understands things will have an unconstrained power within the organization, which she may well abuse. If two at the top have the required skills, one can only hope they get on well together, because otherwise the feuds between them will be intractable. (If that sounds overly pessimistic, note that, given the absence of market discipline, plotting and feuding can be especially pernicious within a supervisory agency. Norm Champ has provided a vivid picture of this in his account of his time as a Division Director at the US Securities and Exchange Commission.)

The cybersecurity challenge is self-explaining and definitely not new, but with supervision ever more software-based and interconnected, it becomes absolutely crucial. The bad news is that already supervisors have suffered major intrusions from hackers. The good news is that there is no conflict of interest with the industry here on the goals to achieve, so that supervisors can purchase the same products that are developed for the industry and free ride on the innovation that is spurred by private market pressures.

Finally, it will be interesting to see how the cat-and-mouse game between supervisor and supervisees will evolve. Mice will know that, thanks to RegTech, cats have improved their ability to detect law breaches. But there will always be grey areas wherein to test the effective reach of the law.

Cats, on the other hand, will have to have filters to screen out trivial violations, given the labour-intensive nature of enforcement activity for at least some years to come. To maximize enforcement output (not in terms of number of sanctions, of course, but to maximize deterrence and victims’ redress), how will the filters be set? And how will the supervisor prioritize? We are back here to the organizational challenge: the top echelons will have to make these prioritization and enforcement selection choices, but implementation will take the form of code, which, in turn, the top echelons will lack the knowledge and expertise to monitor for quality and effectiveness: it will be very hard for them to tell, until it is too late, whether a scant catch will be due to high compliance rates across the market, to market participants’ ability to play around badly designed rules, or because the filters themselves are badly engineered.

To conclude, all industries are facing disruption from IT advances and the financial supervision services sector is no exception. While RegTech is bound to improve the overall quality of financial supervision, the transition to a RegTech-dominated environment will pose serious challenges that supervisors must prepare for. In addition to devoting urgent attention to cybersecurity issues, the top priority for supervisors (and policymakers generally) is to deploy serious efforts in the direction of ensuring that a critical mass of high-quality IT-literate personnel is in place and that the people at the top are able to effectively lead and monitor the transition.

Luca Enriques is the Allen & Overy Professor of Corporate Law at the University of Oxford, Faculty of Law.