--> ​



Collaborate on prudential regulation implementations using open standards

OpenBasel3 Initiative


In January 2019 OpenRegTech will release the OpenBasel3 initiative.

The goal is to produce a fully open source implementation of the Basel 3 prudential requirements processing (Market Risk, Credit Risk, Counterparty Risk and Liquidity Risk), tailored as appropriate to each national regulator.

The key to achieving this is the creation of a language tailored precisely to this exact goal.

Introducing Common Regulatory Language (CRL)

Common Regulatory Language is the language created by OpenRegTech for defining regulatory calculations. It is completely open and free to use. And programs written in CRL are not tied to running on any one vendors runtime, or tied to any vendors IDE for editing the programs.

OpenRegTech will provide a free reference implementation of CRL runtime, which translates CRL programs to easy to understand excel and VBA code. Also, we are producing a runtime that uses Java, one that uses Scala and one that uses Apache Spark fast analytics platform.

OpenRegTech will also provide a free visual Integrated Development Environment (IDE) for writing programs in the CRL.

Other parties are welcome to write open or commercial IDE’s and Runtimes for CRL also.

What are the properties of CRL.

CRL is purpose built for the collaborative design of prudential regulation calculations. We describe below some of its many features:

Focussed on the Domain expert

CRL is designed from scratch to be a language that business analysts and domain experts can understand and write.

The language uses concepts familiar to users of Excel and basic SQL, and programs are easy to represent and build with a visual representation.

The programs in CRL are translated to code that is understood by modern fast technical frameworks. We do not start with a technical framework and work backwords to a language that carries the baggage of the desired runtime.


CRL is designed to reflect a model of computation which can support parallelism, efficient memory management, and distribution provided by a wide range of executable platforms.

Full featured

Although the CRL language is simple to learn, it allows for flexibility to tackle any problem. In essence CRL follows principles from the functional programming paradigm and focusses on the subset of these that relate to well known concepts in Excel and SQL. However, for software developers it is possible to step out of the common Excel and SQL patterns and write more complex code which is neatly defined in function definitions that domain experts can understand and work with much like custom VBA functions in Excel. The amounts of this more custom code required should be minimal, but when we consider more complex aspects like efficient collateral and exposure matching in credit risk mitigation they may be required. CRL can deal with a great deal of advanced processing without the need for developer specific knowledge and does not shy away from processing of complex requirements.

Industry friendly

The language and the runtime are separated, the language is fully open source, this helps us in the OpenBasel3 initiative, allowing collaboration on the business logic of the regulatory rules defined in CRL, regardless of the runtime used to execute the rules.

Model based

Everything in a CRL program is an instance of a well-defined model, this is key to the traceability of the language

Focussed on well understood standards

Every program written in CRL is stored as XML following a precise open schema defined in XSD.


CRL is designed to work will with source control systems like git and SVN. Much research has been done on collaborating on models and OpenRegTech make use of this innovation in their free IDE, with concepts such as visual model diffing.


Small changes in requirements do not require large verbose changes in the program

Traceable, Traceable, Traceable, and Traceable.

Results produced by CRL are completely traceable to the source data, offering complete data lineage of the numbers produced, right to the source data and the intermediate numbers created in the process.

Data Items (such as report cells) are completely traceable pre-runtime to the required source data items (table columns). This powerful feature allows for excellent management of an evolving common data structure.

All calculations and Data Items are traceable to the regulatory text that they implement.

All tests are traceable to calculations, regulatory text, and data items, to the extent that we can search for which tests test which part of a regulatory rulebook, and we can see which tests are no longer valid when we change a data structure.

Traceability is a key requirement in BCBS239 “Principles for effective risk data aggregation and risk reporting”


CRL’s modularity allows for the neat evolution of programs. Every part of a program is within a module, modules have versions defined using semantic versioning, and each module declares which modules it is dependant upon along with their precise versions.


Modules can be re-usable, for example a high-level description of BCBS’s interest rate market risk curvature calculations can be composed with one low level logical description for Japanese regulators and a different low-level logical description for the UK regulator.

Also, since scenarios are first class artefacts (such as comprehensive or simple approach to credit risk mitigation) we can turn off scenarios (a kind of decomposition) and get a simpler set of data requirements for simplified processing or testing.

Provides a methodology for the creation of common data models

A serious difficulty in the creation of collaboratively developed open source regulatory engines is the ‘choice’ of data model. We believe that common data models should be evolved, using the principles of need and refactoring. The traceability and decomposability features of CRL allows for calculations to be added on a cell by cell, scenario by scenario basis, so that items are added to the data model only as they are needed, and with the reason for that need recorded. Over time renaming or changing of data model will be required to keep a data model neat. CRL’s precise pre-runtime traceability allows us to ask for each column in a data model exactly which calculations, report cells, reports (including national regulatory specific reports) and scenarios, are dependent upon that column allowing for careful refactoring (such as renaming or even just refining the definition of a input column in an input data structure)

Designed for Change Management

The modular nature of the programs makes for well-defined change management, for example you can check which version of a regulatory rulebook is used by a set of calculations in CRL and manage the impact of changing to the next release of the rulebook.


CRL is designed with testing at the forefront, it is very easy for test suites of regulatory calculations to degrade over time as data structures and processing evolves. We define coverage per report cell, and per set of scenarios relevant to the cell, and using CRLs pre-runtime traceability of data items we create the smallest set of input data required for each test, so that tests are longer lived in the face of changes. The testing can link easily to Continuous Integration environments.

Test cases can be managed centrally under version control managed and searchable by defined tags (e.g. find me a test case for UK Standard approach to credit risk and Comprehensive approach to Credit Risk Mitigation)

The traceability between tests and linked calculations, data structures, and data items allow us to spot quickly which tests are affected when we change data structures or calculations, so we can know instantly when tests get out of date.

Scenarios as first-class artefacts in CRL so that programs can be easily understood by testers from the outset.

Simplified levels of abstraction

Programming languages without good ways of dealing with abstractions tend to produce verbose and repeated code, Object Oriented languages provide great flexibility with regards to abstraction but tend to be confusing to Domain experts without a great deal of experience in this paradigm. CRL introduces abstraction in a simpler means to reduce verbosity and avoids data encapsulation common in OO languages which can limit traceability.

Support simpler interfacing

A major cost of implementing any regulatory calculation engine is the effort required to interface a banks data to the engines data model. We consider what CRL can do at the outset to reduce this. Due to the pre-runtime traceability and decomposability of programs in CRL we can allow incremental interfacing, where interfacing starts with a small set of cells or reports (hence a small set of input requirements known by pre-runtime traceability) and is grown incrementally with confidence, this is more manageable than a big bang of needing to interface to every element of a monolithic data dictionary before testing that the results in repots are as expected.


As CRL programs are instances of a well-defined model, we can look at a program from different viewpoints, e.g. a high-level view for project managers, a test focussed view for testers, a business logic focussed view for domain experts and /or developers. Since all disciplines are interacting with the same model then they are on the same page. This is much better than each discipline having their own set of distinct unconnected artefacts which may get out of synch (e.g. testers in Excel, developer in Java code, Domain experts in Visio)