Digital Regulatory Reporting – It’s only rules, data and execution – are we finished yet?

In August 2018, we wrote about the progress of the Digital Regulatory Reporting pilot, an industry collaboration between the FCA, Bank of England and several financial institutions. The end goal of this initiative is to prototype a new approach to regulatory reporting for financial institutions in the UK.   

Digital Regulatory Reporting is one of the big three topics we are covering in our Digital Regulation series throughout 2018 and 2019 and will be the focus of our next industry roundtable on 11th December, held in collaboration with the FCA.

In the latest (and final?) update on the pilot, hosted at the FCA office in Stratford, Nick Cook from the FCA explained the aim was to address the common pain points between the regulator and the industry of the current reporting system, – cost, inconsistency, duplication of data and data protection issues.The core team members of the project team then updated us on progress and lessons learnt.

The prototype solution can be broken into the following constituent parts which also mirror the main achievements of the project.

  1. RulesRegulatory rules are interpreted into code (the DRR pilot chose to use Hyperledger chaincodes )
  2. Data –  Modelling of data for regulatory obligations to the coded rules to  enable the third step (execution)
  3. ExecutionAn API gateway is placed close to the source data systems to execute the code and run a compliance check (that all the data for a regulatory report is present and within tolerance, conducted against dummy data for the pilot)

The team then explained that at Step 1 (rules) different obligations could be mapped into different code (or smart contracts) and then that code could be executed against different regulated institutions (depending on which license they have or financial products they are authorised to sell). The regulators then see the result of the execution (step 3).  Step 2 was largely fixed for the pilot and dummy data was provided to map to the rules.

However, getting the data modelling right is fundamental to the future success of the prototype, so the project team explained the approach that was being taken to define and understand the source data and then structure it so that the APIs could act as gateways to both granular and aggregated data, based on the reporting requirements.  

Although the participants in the pilot were mainly from large financial institutions,  the team had clearly thought about the operational aspects of the system from the regulators’ perspective. For example, the prototype includes functionality that allows a newly authorized financial firm could be onboarded. The first step would be to onboard the new firm to the regulatory reporting system from a technical perspective by deploying the necessary technology onto the firm’s infrastructure. Secondly, the system would then automatically assign the necessary regulatory reporting obligations based on the firm’s regulated activities. Finally, the firm would map their internal data to the DRR APIs.

Alongside the technical implementation aspects of this project, it was clear a lot of thought has been given to the legal and operating model aspects of the future state. Questions posed and still largely unanswered are:

  • Where does the liability stand when regulatory rules are written in code?  How are these rules written, by whom and how are they approved?
  • Could we learn from similar industry initiatives?  Examples are AUREP (underpinned by Bearingpoint’s ABACUS platform), ISDA’s Common Domain Model, Open Banking Implemtnation Entity (OBIE)
  • Would a regulatory reporting service be best run as a centralized service or platform? If so, who would be the governing body for the data standards and the platform?
  • What role do existing technology suppliers play in this future state?

These questions are unlikely to be answered in the near future. However, given the success that the FCA and Bank of England have had to date in fostering true and deep industry collaboration with the DRR pilot, there is now a degree of common understanding and momentum that will hopefully continue and take us closer to a digital regulatory reporting solution. We should also celebrate the massive step forward that all those involved in the DRR pilot have made.

At RegTech Associates, we believe there is a huge amount of complexity involved in the data standardisation, modelling and operating/service models necessitated by a move to digital regulatory reporting – so much so that we gathering the industry together on December 11th to take the discussion onto the next level.  Join us if you are in London –  if not sign up to our newsletter to find out more.