Too many TLAs (Three Letter Acronyms), I agree. Earlier this week the Financial Conduct Authority (FCA) published the results of a pilot programme called Digital Regulatory Reporting. It was an exploratory effort to understand the feasibility of using Distributed Ledger Technology (DLT) and Natural Language Processing (NLP) to automate regulatory reporting at scale.
Let me describe the regulatory reporting process that banks and regulators go through. That will help understand the challenges (hence the opportunities) with regulatory reporting.
- Generally, on a pre-agreed date, the regulators release templates of the reports that banks need to provide them.
- Banks have an army of analysts going through these templates, documenting the data items required in the reports, and then mapping them to internal data systems.
- These analysts also work out how the bank’s internal data can be transformed to arrive at the report as the end result.
- These reports are then developed by the technology teams, and then submitted to the regulators after stringent testing of the infrastructure and the numbers.
- Everytime the regulators change the structure or the data required on the report, the analysis and the build process have to be repeated.
I have super simplified the process, so it would help to identify areas where things could go wrong in this process.
- Regulatory reporting requirements are often quite generic and high level. So interpreting and breaking them down into terms that Bank’s internal data experts and IT teams understand is quite a challenge, and often error prone.
- Even if the interpretation is right, data quality in Banks is so poor that, analysts and data experts struggle to identify the right internal data.
- Banks’ systems and processes are so legacy that even the smallest change to these reports, once developed, takes a long time.
- Regulatory projects invariably have time and budget constraints, which means, they are just built with one purpose – getting the reports out of the door. Functional scalability of the regulatory reporting system is not a priority of the decision makers in banks. So, when a new, yet related reporting requirement comes in from the regulators, banks end up redoing the entire process.
- Manual involvement introduces errors, and firms often incur punitive regulatory fines if they get their reports wrong.
- From a regulator’s perspective, it is hard to make sure that the reports coming in from different banks have the right data. There are no inter-bank verification that happens on the data quality of the report.
Now, to the exciting bits. FCA conducted a pilot called “Digital Regulatory Reporting” with six banks, Barclays, Credit-Suisse, Lloyds, Nationwide, Natwest and Santander. The pilot involved the following,
- Developing a prototype of a machine executable reporting system – this would mitigate risks of manual involvement.
- A standardised set of financial data definitions across all banks, to ensure consistency and enable automation.
- Creating machine executable regulation – a special set of semantics called Domain Specific Language (DSL) were tried to achieve this. This functionality was aimed at rewriting regulatory texts into stripped down, structured, machine readable formats. A small subset of the regulatory text was also converted to executable code, from regulatory texts based on this framework.
- Coding the logic of the regulation in Javascript and executed using DLT based smart contracts.
- Using NLP to parse through regulatory texts and automatically populate databases that regulatory reports run on.
If the above streams of efforts had been completely successful, we would have a world of regulators creating regulations using DSL standards. This would be automatically converted to machine executable code, and using smart contracts be executed on a Blockchain. NLP algorithms input data into the reporting data base, which will be ready with the data when the smart contracts were executed. On execution, the reports will be sent from the banks to the regulators in a standardized format.
This would have meant a few Billions in savings for UK banks. On average, UK banks spend £5 Billion per year on regulatory programmes. However, like most pilots, only part of the programme could be terms as successful. Bank’s didn’t have the resources to complete all the above aspects of the pilot successfully. They identified the following drawbacks.
- Creating regulatory text in DSL, so that machines can automatically create and execute code, may not be scalable enough for the regulators. Also, if the creation of code is defective, it would be hard to hold someone accountable for error prone reports.
- NLP required a lot of human oversight to get to the desired level of accuracy in understanding regulatory texts. So, human intervention is required to convert it to code.
- Standardising data elements specific to a regulator was not a viable option, and the costs involved in doing so is prohibitive.
- While the pilot had quite a few positive outcomes and learnings, moving from pilot to production would be expensive.
The pilot demonstrated that,
- A system where regulators could just change some parameters at their end and re-purpose a report would enable automated regulatory reporting.
- Centralizing processes that banks currently carry out locally, create significant efficiencies.
- Dramatic reduction in the time and cost of regulatory reporting change.
- Using DLT could reduce the amount of data being transferred across parties, and create a secured infrastructure.
- When data is standardised into machine readable formats, it removes ambiguity and the need for human interpretation, effectively improving quality of data and the reports.
In a recent article on Robo-Regulators, I highlighted the possibilities of AI taking over the job of a regulator. That was perhaps more radical blue-sky thinking. However, using NLP and DLT to create automated regulatory reporting definitely sounds achievable. Will banks and the regulators be willing to take the next steps in moving to such a system? Watch this space.
Arunkumar Krishnakumar is a Venture Capital investor at Green Shores Capital focusing on Inclusion and a podcast host.
Get fresh daily insights from an amazing team of Fintech thought leaders around the world. Ride the Fintech wave by reading us daily in your email