A stress test group estimates how the their bank’s positions and risks would change under a set of economically plausible but possibly unlikely scenarios. They may on occasion need to create a new scenario urgently, perhaps in response to a recent news event.
Let’s imagine that it looks like Greece will exit the Euro but the latest analysis is that the Euro area will survive without further repercussion. At the same time, the UK finances look shot and so Moody’s has just announced it will downgrade 1 notch. The stress test group need to create a new scenario to reflect these conditions. The bank is already running many scenarios on a regular basis. Let’s say that their inventory already includes four scenarios;
- Grexit – a Greek exit from the Euro,
- Unexpected Rally,
- Severe Market Slide and
- Global Recession.
The stress test results for these and all other scenarios are generated from valuations performed by the front-office systems which are then loaded into the stress test system for analysis and reporting. However, it’s usually difficult to create a new scenarios quickly. The stress test team needs to work with several fromt-office teams to organize this. The introduction of the new scenario needs to fit in with planned releases of all the front-office systems and space needs to be allocated in the processing window to generate that new scenario. It may take one month or two to achieve this whereas the results are needed in a day or two – or even for a board meeting that evening!
One alternative is to mash up existing scenarios if an approximation to the new scenario can be expressed in terms of assembling together existing scenarios. This is obviously not as rigorous or as accurate as creating the scenario in the usual way but timeliness is everything.
There are two characteristics of stress test data (assuming it is already in a well structured database) that are of great help here. Firstly, the facts have only three essential properties; the unique trade identifier, the scenario identifier and the P&L value. Once we know the unique trade identifier, we know all the other information about the trade (e.g. trader, book, counterparty, trade-date) and instrument (product type, country of the issue and rating, currency etc). Similarly, the scenario identifier will provide all the other information about the scenario (name, description, market stocks. All this data is held in the dimension tables of the stress text database. Secondly, there is exactly one row in the fact table for each trade for a given scenario.
Let’s say that the business specification of our mashup scenario is as follows
- Apply the ‘Grexit’ scenario to any trades issued in Greece or with a counterparty
- On the remaining trades, apply the ‘Unexpected Rally’ scenario to any trade with an instrument currency of Euro
- On the remaining trades, apply the ‘Severe Market Slide’ to any trade where issuer country is the UK
- Apply the ‘ Global Recession’ scenario to all other trades in the portfolio
Figure 1 shows the details for a rather small fictitious portfolio of 4 trades. We can apply the rules to select and create the 4 facts that will comprise our new mashup scenariousing some straight-forward SQL. The new Mashup rows are highlighted in green and the facts of tha were selected from the existing scenarios the new scenarios in blue.
Figure 2 shows a snsapshot of a visualisation, created with Tableau, with the mashup scenario on the right.
Of course, I’ve ignored a few small matters; scaling up (since a typical portfolio may have 4 million rows rather than just 4), testing, providing an environment separate from the regular production environment that we can use to create the urgent scenario, deployment, approvals and so on). The purpose however is to show that at the core this is a very simple procedure that is capable of providing a “good-enough” results in a short time.