The last tools I will consider in this short test on risk management are perhaps the most important of all—stress testing and scenario modelling. Too often, management are able to understand the day-to-day, but are either unwilling or unable to consider what might be considered as unlikely or unexpected. The problem is that we are living in a world where the most unlikely outcomes are appearing to be prevalent; you only need to look at recent election results globally to know that is the case. Consider things such as interest rates and the oil price. Did you see that happening?
Stress testing commences with sensitivity analysis, which looks at the unitary movement of a key variable. Often, this variable will be something such as:
- Interest rates
- Exchange rates
- Commodity prices
- Housing prices
- Unemployment
- GDP growth
- Market growth
- Transaction volumes
- System downtime
In each case, you can identify a small movement that is likely to occur. Interest rates could move up or down by 25 basis points. The impact that this has on your business tells you a lot about how the business works in practice, its profitability, capital requirements and liquidity. It assists management with understanding the pressures on product pricing and day-to-day management. That is all very well, but what about when tomorrow does not look like today with a small variation? That is the role of stress testing and scenario management.
Stress testing takes sensitivity analysis and moves this to a plausible extreme. Of course, events could occur throughout distribution ending up with the increasingly unlikely events that we are now considering.
If interest rates defined as interbank borrowing rates are at 1 percent, then a sensitivity might be 1.25 percent or 0.75 percent. Sensitivities operate both upward and downward and both would be assessed, but what is the tress value?
The plausible stress event is generally the point at which the relationships between the factors that underpin the sensitivity break down. Essentially, you are unable to continue to infer the value or actions from the input data. For interest rate increases, what might be considered as plausible? Some firms will take the largest value that has ever occurred and others will do some form of estimation.
If interest rates are at 1 percent, would 3 percent be plausible within the one-year view? Or 5 percent? Or 25 percent? How would you assess this?
Most stress events are the result of some form of event occurring that was unexpected, although perhaps, the term unlikely is more appropriate.
If a country defaults, then interest rates tend to fly. When Russia defaulted, interest rates hit 150 percent, albeit only for a short period. So, a default of your country would normally result in a massive increase in interest rates. This historic occurrence provides management with some information on what are the consequences of a default. However, there will be issues as to whether they fully appreciate what is likely to be the consequence and the actions that they can take to protect their firm.
Normally, interest rates rise and fall due to either changes in the market or the wish of politicians to meddle with the economy. My view is that this meddling rarely adds value and often results in unintended outcomes. Clearly, there are a lot of possible interest rates between 1 percent and 150 percent and each has a different probability and impact. Indeed, each is likely to lead to a different type of action that management might need to take. At the extreme stress value of 150 percent, a duvet day might seem like a great idea.
So, management should consider the events that would increase interest rates to 3 percent, 5 percent, 10 percent, 15 percent, 20 percent, 25 percent, and so on until such time as the relationships that underpin the stress event break down.
Thinking through what you would do under these scenarios in advance of them occurring is one of the most important parts of this part of the analysis, since were the event to happen, you rarely have the time to properly plan. Indeed, considering the type of event that might cause such a jump in interest rates so that the event can be foreseen is part of the analysis that needs to be conducted.
Stress testing is, however, a rather simplistic two-dimensional view and analysis of risk. It works best where the movement of the sensitivity is not too extreme and it enables management to assess their available options.
A scenario is different. It does not come from a trend. It just happens. Just as plane crashes, flood and volcanoes are all unexpected, each has a consequence and a series of actions that you should take to mitigate the impact of the event. The problem is that there are so many things that could happen.
There are three main sources for scenario data—management knowledge, internal events and external events. Internal events should be included within your internal loss database and might also be used for back testing stress testing. The stress test would then need to consider an event that was either much larger than anticipated or more frequent than anticipated. Remember that we said earlier that when modelling the internal loss database these unusual data points would be excluded since they may not recur. Now they are useful.
The external loss database will also include also include information on events that were so unusual by nature that they might be considered as scenarios. External loss events have happened to other people. To make the information of benefit you need to know what really caused the event, or the data will not be easy to apply. If the external loss results from a volcano, then the cause of the event is clear—it’s a volcano? Other events are less clear and require analysis.
Considering a volcano, will you always model it? If you are sitting in the U.K., this leads to the obvious first question: Do we have a volcano? If there is no local neighborhood volcano, please do not model it. You will know if you have one since it will be quite obvious.
If you do have a local volcano then the database will tell you what might happen based on what has happened when other volcanoes have erupted. You then need to assess what this is likely to mean for your business. What would you lose? Which customers or suppliers would be impacted? How would your bank fare? What about your staff? Would your business continuity plan really work and if not, what else would do you really need to do?
Clearly, you would not place your key processing units on a volcano, yet a firm has. Nor would you place your head office at the end of a runway to an airport—yet, there are firms there. You could put your office anywhere so why place it in an area of heightened risk? These are often decisions taken without regard to scenario modelling. Often the decision that mitigates the scenario is no more expensive than the one that ignores it!
Going back to the volcano you may still need to consider the impact of volcanoes overseas. We saw the business disruption caused by the Icelandic volcano and you will still wish to model the impacts that might result from an overseas volcano eruption if that is relevant to your business.
One case that will appear in your external loss database will concern a disgruntled systems administrator who is able to place a virus in your systems. This scenario caused a major loss for the firm concerned, but the real value to you is to consider the various attributes of the scenario. The first issue is why was the employee disgruntled? In the specific case, they were expecting a bonus of $50,000 and only received $38,000. Rather than saying thank you for the $38,000, they said, “Where is my $12,000?” and took action.
As you are reading this, you are probably thinking who checks your systems administrators. We know what they are supposed to do, we know their policies and procedures, but who checks what they actually do when they are entering a system they are requested and entitled to access?
The second issue is the bonus. Bonuses going up are a motivator, but as they go down, they are frequently a risk management disaster. Do you apply additional controls over such people? Put these two events together and it bought down the computer systems for a major firm.
If I take another case, this will better illustrate what you need to do. A few years ago, I received a newswire saying that the previous day I had received a newswire unchecked and a day early. They claimed that their editor had been sitting at his desk again and had dropped a sandwich sending out the incorrect message. They even provided an electronic trash can to place it in.
A number of issues arise from this simple case. The first is to think through the likely action that will be taken by the recipient of the email. In reality I went into the pam folder where the email always went and looked for the errant message to see what it was that I was not supposed to see.
Essentially, the method of communication probably resulted in more people being aware of the problem than would have otherwise have been the case. The lessons from this are clear. What are your communication plans when something goes wrong and who checks that they add value to your firm?
The next issue is with the errant message. I tried dropping sandwiches onto my computer, but found it difficult to send a message in error. However, when I threw a baguette at the right key, it was possible.
That falls into the so unlikely that it is probably apocryphal and nobody fancies eating apocryphal sandwiches. So, probably just a message that escaped rather than being properly approved and released.
Now, you have a general problem—a message that should not have been sent. Where in your firm would be the worst place from which to release an incorrect piece of information? Finance with the annual accounts? A letter to a client using inappropriate language? A press release that includes a planned but not confirmed event? Each of these events has an impact and a consequence.
Essentially, what you have done is change a specific case from the external loss database into something generic, and then let it hover over your business. It then attaches itself to the area where it has the greatest resonance and this can then be assessed. The value of scenario modelling is in considering the impact and what you might then be able to do since if the event happens, you rarely have time to think. Of course, there are hundreds and hundreds of possible scenarios. Your problem is that you cannot do them all—but that should not stop you starting.
Another case involved Bristol Zoo. Outside Bristol Zoo was a well-preserved car park where a cheerful chap assisted people going to the zoo, providing them with advertising literature, and of course, taking money for parking. He had a nice little office, where he spent his day and he worked every day the zoo was open. One Monday, he was missing. The zoo management called the Council for a new parking attendant, to which they received the reply that the Council had never had a car park at the zoo.
An enterprising stranger identified the opportunity of using the unutilized space as a car park, prepared it and took the funds for more than 20 years without anyone checking. The fact that nobody even knew his name is perhaps even more strange.
You might think such a case is odd, but could you have someone on your payroll that never comes to work and is still being paid? Could you be paying for a service that you never purchased—a register, for example? Could there be someone that is not really being supervised and is not taking holiday, potentially disguising fraud? Until you do the analysis, you really cannot think this through.
The problem with scenario analysis is that it highlights that controls that work in normal environments might actually become a problem under a stress environment, and understanding that is really important. However, reporting this to senior management can also be a problem. They may not understand the implications, and since the analysis is always incomplete, will rarely know what to do with it. My recommendation is to tell them in general rather than specific terms and see how they react.