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.
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.
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.
Everything in a CRL program is an instance of a well-defined model, this is key to the traceability of the
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
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
Traceability is a key requirement in BCBS239 “Principles for effective risk data aggregation and risk
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
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
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
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)