Financial institutions are responsible for preparing their operational and reporting data in terms of the common standard, while regulators draft regulation in natural language, as well as machine executable language. The automated system to produce executed reporting outputs can either be built and managed by the regulator or developed by independent software vendors. While digital regulatory reporting has many components, the functionality of the solution can be broken down into two main concepts:
MRR encapsulates the process of converting legal regulatory reporting standards into structured, machine-readable language that accurately replicates the structure and flow of the regulation using a standardised data dictionary. This conversion is a challenge in and of itself as the structured, binary nature of computing does not lend itself well to regulatory interpretation and judgement or principle-based regulation. Furthermore, the regulators who draft these documents are either lawyers or risk managers, who often do not have the technical skills to convert their legal instructions into machine-readable programming languages.
MER refers to the process through which machine-readable regulation in a high-level programming language (JSON, SQL, Rosetta) is converted into executable instructions, using a compiler programme to create code processable by a CPU. This code is then combined with standardised datasets to execute and calculate the regulatory reporting output. The Digital Regulatory Reporting (DRR) pilot, launched by the Financial Conduct Authority (FCA) and Bank of England (BoE), has been tackling this issue of machine-readable and executable regulation by looking at various methods of conversion. This includes using natural language processing (NPL) technology to automatically convert natural language text into structured information using artificial intelligence. DRR also focuses on drafting regulation in a domain specific language (DSL) and then converting it into the formal model of the solution. DSL, usually stripped-down structured languages with limited functionality to focus on a specific application domain [1], should provide the functionality for both machine and human readability, thereby bridging the gap between the business team that draft regulation and the IT team that manages the structured information.
The International Swaps and Derivatives Association (ISDA) has similarly produced their Common Domain Model (CDM) using the Rosetta DSL to formally model derivative data for products, calculations and events across the trade lifecycle in a machine-readable format. ISDA’s CDM was utilised in phase 2 of the DRR pilot to express reporting rules for EMIR and MiFIR and demonstrated the principles of standardisation and reusability that demonstrates the solution’s scalability.
The benefit of digital regulatory reporting lies in using a common data standard, including a data-dictionary and data model, across the financial industry. This ultimately provides interoperability, with a standardised model that allows for accurate and efficient exchange of data between all institutions and between internal systems. It also reduces the burden of reconciliations (inter-institutional post-trade reconciliations being a particular concern by ISDA) and integration transformations between systems (straight-through-processing), thereby allowing business teams to focus on value-add activities. A common standard also promotes transparency as the industry and regulators share greater alignment on regulatory judgements and data definitions. Scalability of the solution through the use of reusable machine-executable code and a standard data model also reduces the number of data points required for various types of regulatory reports.
Despite these potential benefits, digital regulatory reporting has yet to gain momentum to move past proof of concept and tackle the real-world complexities of an end-to-end automated solution. The process of designing, building and vetting the various elements of the solution will require intense collaboration and consultation amongst industry stakeholders including regulators, supervisory bodies and risk and compliance functions. The FCA alone regulates over 58 000 firms illustrating the scope of such engagement.[2] Furthermore, all financial services industries will have their unique ecosystem of technology, architecture and reporting processes that have accumulated over decades of operations. An industry-wide transformation of the reporting landscape will require exceptionally well planned, funded and motivated rollout.
