A typical stress testing solution

As shown below, a typical stress testing setup consists of three distinct components:

  • 1.
    Stress testing computation
  • 2.
    Reporting (regulatory or internal), and
  • 3.
    Data quality and integrity controls (during the computation and during reporting)

Basinghall offers an end-to-end stress testing solution, an all-in-one solution

It has been created, from the ground up, to deal with the orchestration of stress testing and similar processes

Pluto – simplified architecture

  • A simplified architecture is shown below
  • The modules marked a), b) and c) is where the main computation takes place
  • The main tool and the sandbox are independent of each other and run the entire stress testing process end-to-end but rely on the same libraries. They can also be used to test each other

Pluto – principal differentiators

  • Streamlined yet comprehensive solution (most competitor solutions cover only one aspect out of three)
  • Designed from the ground up by practitioners with cutting-edge technology to work in practical environment
All-in-one solution
  • Multiple use cases
  • End-to-end process orchestration
  • Wide coverage of business activities and risks types via clusters
  • Architecture with modular components
Use cases
  • Climate ST: BoE, ECB
  • Scenario-based financial planning
  • Recovery ST
  • Easy to add new use cases and clusters
  • Golden source library
  • Portfolio/cluster specific
  • All rules built by senior regulatory analysts with BoE and EBA experience
  • Around 1500 per use case
  • Golden source library
  • Portfolio/cluster specific
  • All mock models built by senior London quants
  • Around 250 per use case
Populated tool
  • Fully populated tool: variables, rules, models, synthetic data
  • Easy to replace rules and models by firm’s own rules and models
Data quality and
  • Data quality checks for end-to-end process
  • 4000+ validation and reconciliation rules
  • Complete data lineage as required by BCBS239
Versioning and
audit trail
  • Rigorous versioning
  • Ability to run any previous simulation easily
  • Full audit trail
Sandbox and main
  • Same tool, two implementations
  • Sandbox is fully transparent, designed for what-if analysis
  • Main tool is fully scalable, cloud-enabled, employs a microservices architecture and use Spark for execution of rules and models

Multiple use cases

Pluto covers many use cases as shown below
Regulatory capital stress tests
Bank of England’s STDF
European Banking Authority’s stress tests (EBA ST)
Regulatory climate stress tests
Bank of England’s
climate stress tests (CBES)
ECB climate physical
ECB climate transition
Internal stress testing
or scenario analysis
Scenario-based financial
Recovery plan – systemic scenario
Financial planning – climate scenario

“Divide and rule” strategy

We divide each use case into smaller clusters as shown below. This has many advantages: can be run by specific teams independently of each other, the intermediate results are independent of any regulatory requirement, the same simulation orchestration can be used for scenario-based financial planning as well as recovery planning

Simulation overview

Data goes through 6 stages as shown below

Climate stress tests

  • The figure below summarizes the different components of a climate stress testing process
  • The shaded boxes represent an area that requires specialist climate risk knowledge and experience
  • Currently, there is limited focus in the market on embedding Climate Stress Testing into the firm’s own BAU risk management. Firms will have to embed climate impacts into their more granular stress testing, business planning and all of the other stress testing use cases
  • Pluto uniquely focuses on the end-to-end process and provides a straightforward path to integration with existing BAU use cases

How Pluto’s climate risk stress test work

Add climate data, variables, scenarios
  • New climate variables
  • New portfolio information
  • New scenarios
  • Incorporates standalone impacts on key metrics and input into existing BAU models
  • Modify BAU PD/LGD/asset valuation models to incorporate climate variables (fully integrated)
  • PD/LGD adjustments are implemented through application of scalars and haircuts
  • Existing validation and reconciliation rules retained (climate-specific can be added as required)
  • New climate regulatory charges captured by modifying existing cluster rules

Stress testing

What is stress testing?

  • It is an integral part of sound risk management and financial planning
  • In essence it is about analysing the impact of chosen scenarios on key metrics
  • And then incorporating the results into the business plan and strategy

Why is it important?

  • Because stress testing is like a crystal ball. It enables a firm to see how it will look like under different future scenarios
  • Which in turn allows for proper contingency planning
  • In response to the 2007-2008 financial crisis it has become a regulatory requirement for many financial institutions in advanced jurisdictions
  • Banks and insurers are required to perform annual/regular stress tests by the Bank of England (STDF), European Banking Authority (EBA ST), US Fed (DFAT, CCAR), and various other regulators (FINMA, JFSA, HKMA, MAS, APRA, ...)
  • After the Covid-19 pandemic, the need and benefits of such an analysis have become more apparent to many financial institutions and corporates

Unified treatment
of scenario-based processes

Stress testing
  • Stress testing requires forecasting of key risk and financial metrics over a 3 to 7 years horizon under prescribed baseline and adverse scenarios and impact of preventive (management) actions that an institution will take under stress
  • Climate stress tests have longer time horizons and can require forecasts up to 30 years. Currently, regulators do not require a fully integrated climate and macroeconomic stress test but we believe that may be the direction of travel
  • Financial institutions also conduct their own internal stress tests, which are more  tailored to their firm and can be more extensive than the regulatory stress tests
Scenario-based financial planning
  • As part of strategy sessions, many firms (both financial and non-financial) regularly produce scenario analysis of key risk and financial metrics
  • And are now (especially after Covid-19) looking to produce rigorous detailed financial plans under a range of future scenarios
  • Some financial regulators recommend production of such plans and require consistency with stress testing results
Recovery planning
  • Recovery planning is similar to stress testing with more extreme scenarios
  • However, the simulation and orchestration is the same as stress testing
  • What is different then? These are the business rules, the models and the metrics
Regulatory reporting
  • It is a requirement in many countries to produce standardized (i.e. prescribed by the regulator) risk and financial reports on a quarterly/annual basis
  • These are usually in a format that is different from internal MI and contain large amounts of data, e.g. COREP, FINREP
  • These reports are at a point-in-time and do not require forecasting of metrics under different scenarios


  • Stress testing is a complex and involved process, bring together many different parts. The end-to-end orchestration poses several challenges, which are described below
  • Many other challenges are also present, but not specifically related to a tool, such as operating model of teams involved (especially handoffs between teams), quality of reports and insights, embedding the valuable output information into decision making. These are not covered here.
  • Siloed approach for similar use cases (e.g. BoE ST, EBA ST, ICAAP)
  • Leading to duplication and large inefficiencies
  • And to inconsistencies, requiring unnecessary reconciliations
  • No coherent standard for business and transformation rules
  • No golden source (i.e. no rules library)
  • Rules are difficult to view and QA
  • No easy way to call the models from one application
  • Especially if in different language or business
  • No golden source (i.e. no models library)
  • Inconsistent naming convention for data
  • Unclear mapping of variables, rules and models
  • Data quality controls are incomplete
  • Data lineage is difficult or impossible to trace
  • Opaque system, e.g. difficult to find which rules were involved where
  • Assumptions and overlays are hidden
  • High effort is required to reconcile results before trying to understand
Audit trail
  • Full audit trail is unavailable
  • Version control is poor
  • No exhaustive change log, hence difficult to replicate previous simulation runs