Tuesday, 31 March 2015

Losses Are Not Failures of Risk Management

Well, not necessarily.  But we need to remind ourselves and our stakeholders that that’s really the point.  Losses will happen with certain regularity.  This is the message of a system of a risk appetite system where the limits are calibrated to a 1-in-10 chance over a one-year horizon.   Whether the implications are really appreciated is a different point. 

A paper by Rene Stulz (here) is a good reminder that losses may not represent a failure of risk management.  This is particularly the case where “managers [know] exactly the risks they faced―and they decided to take them.  Therefore there is no sense in which risk management failed”.  He goes on further to say that “deciding whether to take a known risk is not a decision for risk managers.  The decision depends on the risk appetite of an institution.” 

This is consistent with the practitioner’s view as expressed by James Tufts, Group CRO of Guardian Financial Services, expressed in a guest post in this blog: “[T]he objective of the ‘Risk Function’ should not be ‘risk management’.  That’s a business objective.  The objective of the ‘Risk Function’ is to provide the ERM [Enterprise Risk Management] framework and the source of challenge and oversight on all aspects of the business model, relative to this framework.”

There may be risk management failures nevertheless and Stulz’s paper goes on to provide a useful classification:
  1. Mismeasurement of known risks  
  2. Failure to take risks into account 
  3. Failure in communicating the risks to top management 
  4. Failure in monitoring risks 
  5. Failure in managing risks 
  6. Failure to use appropriate risk metrics
I find these categories rather intuitive and I wonder how they can be used in practice.  There is an increasing regulatory expectation of formal assessment of the effectiveness of risk management and these categories could usefully feed into that process in two complementary ways. 

Firstly, banks and insurers track a range of risk events/incidents.  It would be useful to consider if reported incidents fall into any of the above categories.  Alternatively they may be consistent with risk appetite.

Secondly, insurers and banks using an internal model are expected to use it to support a profit and loss attribution.  This means explaining actual profits and losses by reference to the output of the internal model and the risk categories considered.  It would be interesting to consider if the losses arise from changes in values consistent with risk appetite or any of the reasons set out above. 

The above might seem a simple idea but learning from failures, or risk management failures in this case, is usually anything but a simple idea.

If you found this post useful, you may want to subscribe and receive future posts by email (here). There will not be many of them.

Monday, 16 March 2015

Stress Testing: Reporting or ‘So What’?

The Bank of England (BoE) recently published the results of the first concurrent stress testing of UK banks (click here for a post about the implications of this exercise).  Stress testing is not only relevant to banks; EIOPA also initiated a similar process and carried out an exercise in 2014, which I will cover in a future post.   
Much has been written about the results for individual banks.  I would like to share some observations about an aspect of stress testing with wider implications: the consideration of ‘so what’ that may take place when the stress materialises. 
In the BoE stress testing, banks had to spell out the management actions they envisaged taking.  These actions were subject to scrutiny by the Bank of England and ‘a high threshold was set for accepting’ them. 
There is little detail about the specific management actions that were accepted.  Broadly speaking, they appear to be mainly reduction in costs and dividend.  Furthermore, the BoE clarified that they did not accept management actions that resulted in a unilateral reduction in credit supply in the stress scenario.  This approach meant that management actions had limited impacts, specifically no impact for two banks and, for the other six banks, an average improvement (i.e. an increase in common equity Tier 1 [CET1] after the stress) of 9%.  
In an earlier post (here), I suggested the consideration of ‘so what’, including the ability to carry out actions that mitigate the impact of the stress as one of the potential benefits of stress testing.  How should we reconcile this with the limited scope of management actions recognised in this exercise?
A useful starting point would be to make a clear distinction between stress testing undertaken for different purposes and audiences.  This is summarised in the table below:

‘External’ / BoE
Identifying vulnerabilities and addressing them
Evidencing overall resilience
Lines of business/ business units
Enterprise wide
Given the BoE’s intention to continue stress testing and make them an integral part of the supervisory landscape, the question would be how to integrate these two different perspectives of stress testing. 
Ideally, a bank would start an internal review of stress vulnerabilities at the business unit level as soon as the submission to the BoE is delivered.  This would enable the bank to identify and put in place the appropriate risk mitigation.  For example, the bank may choose to adjust its credit risk mitigation by transferring loans or hedging credit before the next BoE stress testing.  Given the focus on addressing vulnerabilities, which could require board approval, it would make sense to review stress vulnerabilities of specific business units/lines of business on a staggered basis. 
Adopting this approach over time would deliver a virtuous cycle of identification of stress vulnerabilities and enhanced risk mitigation which would be reflected in the next stress testing for the BoE.
In conclusion, while the BoE may have adopted ‘a high threshold’ for accepting management actions, banks can still build in a process to identify and implement these management actions and evidence how they address vulnerabilities in key business units and product lines.

You can subscribe to future posts here.