Four of the industry's top op risk executives debated risk control self-assessments at a recent briefing in London, moderated by Ellen Davis and sponsored by software vendor Reveleus
What do you consider to be the best-practice components of a risk control self-assessment (RCSA) programme? For example, do you consider the questionnaire or the workshop method of producing RCSAs to be the more effective?
Marc Leipoldt (ABN Amro):
RCSAs are one of the first things we started with in ABN Amro and in a lot of other companies. In thinking about what is best practice, I think it is key to have a very clear idea about who this risk and/or control self-assessment is actually for. I think this is one of the biggest traps you can fall into in conducting risk self-assessments or control self-assessments. There's a huge difference in setting up something to help people improve their processes and get a better grasp on risk; getting them to open up and think about how they can self-improve – this is the 'self' in self-assessment. That is really an internal thing.
It's a totally different kettle of fish if you want to use that RCSA as a benchmark of comparing business units to each other. This is typically something that doesn't bring out the dirty laundry in most people. If you ask them to self assess and, by the way, we're going to compare you to somebody else, a lot of the openness goes out of the window right there. You really have to think what you are going to do with that information and who that information is for before you can answer 'what is best practice?'.
I think we need to have a very clear distinction here. You would need a different approach if you wanted it for self-improvement; if you want people to provide the information that helps improve processes, businesses and their level of control over the risk they face, as opposed to wanting it as a measurement instrument that could be fully objective – compared across time, business units and maybe even companies.
Andrew Brand (Threadneedle Asset Management):
That's provided a really helpful organisational context of the workshop approach. We also use the workshop approach. At Threadneedle we've found it very useful to start with the goals of the department or business area you're helping to do the self-assessment. As you described, it's their thing and the business area needs to feel ownership of it. To a certain extent, that lets the ORM professional off the hook. The real trick that we've stumbled across almost by accident is to sit down with the manager of that area a couple of weeks before the workshop and fish out the corporate strategy document where, inevitably, they're being asked to provide the pages sometimes, and help them to summarise their goals for the year, the next three years or whatever is appropriate into five or six bullet points. We allow them to have one or two sub-bullets but it's got to fit on a piece of A4. We then blow it up onto A0 and put into on the wall. That way, when people come into the workshop they see, probably for the first time for a lot of them, the goals that they're aiming for on a single sheet of paper. As facilitators, that enables us to work down the goals one at a time and to ask people to shout out what they think will prevent them from meeting those goals. People like doing that. They feel they're being rebellious – 'we'll never do that one, we always said we'll never do that one for the following ten reasons'. Suddenly, you've got risks coming out.
How do you ensure that the business lines buy into the RCSA process?
Ravi Varadachari (i-flex consulting):
I think senior management buy-in is definitely required. I think it is a necessary, but not sufficient condition. Apart from senior management buy-in, you also need to have buy-in from the individual departments and the individual business heads. That's a complex area because you are looking at human behaviour – it's really a juxtaposition of human behaviour and risk management. I think there are multiple ways in which this can be achieved. I think one good example is presenting it in such a way that it is understood by the business users. The second is to provide some sort of incentive for the business users – capital allocation is one way of doing it and that is more a way that has been prescribed by the Basel Committee; that's what you would probably do once you had estimated capital. More importantly, you should incorporate performance measures because, as the saying goes, people do what you inspect, not what you expect. In that respect, if you can incorporate performance measures into the whole process, I think that would help in terms of buy-in.
With the RCSA being so subjective, how does one ensure consistency across business lines and geographies in terms of interpretation of the questions, the answers and the risks?
Garth Hinton (ex-Citigroup):
I think this is a very big issue and an area where some of the smaller institutions have a huge advantage over larger institutions. In terms of consistency, I would say it is important to have a single framework for people to refer back to – it need not necessarily be wholly prescriptive, but it needs to be relatively prescriptive in terms of what must be undertaken as a minimum standard. That should be in the form of a group level policy, which is then disseminated down through business segments or otherwise, but it has to be there as a baseline for people to refer back to. It also needs to be there to have an independent review of the process that is being undertaken.
One of the interesting things that larger institutions suffer from, in terms of listing the big risks, if you start at the board and take a top-down approach, is that the board may come up with half a dozen things. Go one level below that to the business unit chief executives and they'll add a few more bits and pieces. If you go down to a more middle management structure, there are another half-dozen to a dozen. In fact, it probably runs exponentially.
At Citigroup I found that by the time we had devolved ourselves from the US, down through the region, down to a sub-region and then into a country – places like South Africa, the Congo or wherever – the laundry list of risk was quite extreme. There is their own regulatory environment and their own business practices to be considered, and that's where the process has the propensity to expand into a huge elephant, and that needs to be guarded against. You can't stop it from happening but you need to be cognisant at the senior management level and at the central level that that will happen.
How does your firm incorporate RCSA results into its operational risk-modelling framework?
How do the results go into the op risk-modelling framework? First of all, they should play a role. They're an important part and are often the part we start with when we are rolling out ORM, so it wouldn't make sense not to include it. We have to be careful how we include it.
In our calculation methodology, it plays a role in two ways. Firstly from a process point of view – you need to plan your RSAs, you need to execute your RSAs, you need to follow up on the actions, you need to do an honest assessment and all those sorts of things. That is something that can be observed quite easily. In rolling out ORM in the first instance, it really helps to have some sort of incentive programme that rewards that type of behaviour – so starting on the behavioural side of things in terms of incentives for people by way of, say, a capital relief of a certain percentage when complying with these practices in terms of the process that is duly followed.
When you want to move into an actual capital calculation from the bottom-up – an AMA type of approach – you need to be a lot more careful. We've found a way around that by not including the results themselves but making compliance with the RCSA requirements a barrier to entry to the AMA calculation. Yes, there is a whole AMA calculation methodology, but if you fail to follow up on the RCSA requirements, a different AMA calculation methodology comes in. You have another type of incentive by now; it becomes a disincentive, it becomes an add-on to your AMA-calculated amount.
I think that is an excellent point – rewarding the right behaviour and punishing the wrong behaviour. From a quantification perspective, I think operational risk is probably very different from most other areas of risk. I think one important difference that should be taken into account is that when you arrive at numbers for capital, the capital numbers for credit risk and market risk carry different meaning to those for operational risk. There were debates a few years back as to whether operational risk can be quantified. I think those debates have died down today but you keep hearing voices that say hey, are these numbers really comparable? If I have a capital number for credit risk and a capital number for operational risk, do they carry the same meaning? Operational risk is still not there in terms of driving the same meaning for that number. I think that one piece of wisdom is applicable here. It says 'not everything that counts can be counted and not everything that can be counted counts'. I think that's very true for operational risk, particularly for the low-frequency high-severity incidents.
Incorporation of the RCSA results into a capital needs, for the various reasons we spoke about earlier, to be done carefully, which obviously goes without saying. By that I mean too much emphasis on the results could be very misleading and could also create huge amounts of volatility in terms of the model itself.
If someone were to assess themselves as being unsatisfactory, and that is to have a 50% change in their capital, nobody can manage a business in that sort of environment, so it needs to be limited in terms of the amount of impact the risk control self-assessment has in the underlying capital.
There's empirical evidence for this as well that suggests that if you were to take an environment where there are no controls, clearly, there are likely to be enormous losses. But, if you were to compare the same types of financial institutions who are running the same types of risks, and could have very different control environments in their own right, the actual losses that they're incurring will probably not be too different from each other. You can see this in terms of analysis of data through various consortia that are available today.
How much does a control environment actually impact the amount of capital required for an institution? If we consider that capital required is for the unexpected losses more than for expected losses, the answer is that, in terms of mitigating unexpected losses, the control environment is probably limited in terms of its ability to foresee those losses and mitigate them going forward. The question is then, if we have a business that has very good RCSA results, does that mean that we should have zero capital – the answer is quite clearly no. The Citigroup framework is predominantly weighted towards the loss distribution approach. That defines what is the capital requirement. It is then modified for what is known as a qualitative adjustment factor, which is not just derived from the RCSA but also from other independent sources within the organisation. The impact is limited on the overall capital number for the reasons I have already mentioned. I think that's very important. Too much weighting is a very bad thing. Too little weighing is the wrong incentive to management to actually do the right thing. You've got to tread the balance in terms of whether it should be a significant benefit to management if they clean up their act, produce a very good control environment within which they operate, recognise the risk they are running and, as far as possible, mitigate those risks.
Apart from capital estimation, how does one derive business benefits by analysing the wealth of information from an RCSA process? In other words, in what form do you return RCSA information to your business lines and how helpful do they find it?
The amount of information collected in any of these processes is so huge that you tend to quickly arrive at some capital number based on that, and all the other wealth of information sits somewhere in some spreadsheet. I think the RCSA process does help you in a variety of ways apart from quantification. One example could be regulatory fines that are imposed by regulators across the globe. The amount of a fine might be very small. For example, the maximum fine that the central bank in India imposes is about $20,000, which is not a very big number and anyone can probably write off that number. If this happens it typically tends to hit the headlines, so from a reputation perspective this has much more significance than the loss amount. This would typically not get captured in any capital process, but would definitely get captured in the RCSA process.
Factors like these need to be captured and properly analysed during the RCSA process. Also, once you have this wealth of information, it needs to be presented in a format that is easily understood by the top management.
This is a real challenge in terms of a short-term versus long-term perspective. Initially there is a great deal of reluctance to go through the process, but once people go through the process they actually see value in it; they recognise that there is a compliance aspect to it that people feel they should attend to, and they do see that there is actually value in sitting down and articulating where the risks are and how they deal with these risks.
They often discover things about their business that they had not really considered before and that they need to deal with. In the short term there are some real benefits in the process itself – the information that gets fed back is quite enlightening in that respect. At the business unit level, long term, it's sustaining that interest factor and the need to continually re-evaluate what the risks are and whether they rank higher or lower than the others. Time and time again the results will come back – we've gone through our risk assessment and nothing has really changed in my environment. Maybe risk numbers five, six and seven have dropped down to the bottom of the pile, a few more have been added in and a few have dropped off but, again, keeping the impetus there is very difficult from a business benefit point of view.
That's where the linkage back to the feedback and the consolidation is very important. These risks don't just need to be articulated for the business management, they also need to be consolidated for the senior management. That is a huge challenge; the ability to present it to management in a manner in which they can say 'OK, we've got half a dozen businesses – here are the issues they have highlighted, which are of business significance to you, the senior management?' The ability to process that plethora of data – this is a significant investment of time and resources, but there's also a real art form developing in terms of picking what is important and what should be disclosed and what shouldn't be, and that's really where the risk manager comes into play.
In terms of the business benefits, I think we need to be extremely careful when we report things up. We advise a number of banks around the globe and in our experience of doing risk self-assessments quite extensively in Asia – for instance in Taiwan – we have found that the most difficult thing to get across is that this information will not go to senior management. We failed to give that message right from the start for the first two that were executed there, and none of the risks scored any more than severity: one, and impact: one. They were simply not willing to move an inch from that. It was extremely hard work to get the risk identified in the first place, but when it came down to assessment there was a complete lack of willingness to do that.
What RCSA best-practice challenges would you like to see the industry address in 2007?
A variety of things, especially some of the questions that we have addressed like ensuring that consistency happens. I also think there are some lessons that can be learned from other industries and incorporated into the banking and financial services industry.
For example, a few years ago there were a lot of accidents in manufacturing companies. How did they go about reducing the number of incidents and accidents? The blue-collar workforce was motivated enough to ensure that they started reporting accidents. When something happened, a lot of incentive was given to the workforce to come up with a solution for that particular problem. The focus was on the solution rather than the incident itself. The workforce took a lot of pride in trying to identify the solutions. That was really stressed – that this particular person identified a solution for this. There are a lot of best practices that we could learn from other industries – things like how do you get buy-in from business departments and so on. And other things like consistency – how do you introduce more rigour into the methodology?
I think one of the biggest challenges is to keep the spark alive and make sure that, after starting out on the RCSA track, that it's still interesting enough to perform after the first, second or third cycle. I think it will be kept interesting by doing the things that we discussed today, starting by making sure it's part of a bigger programme so that it ties in through a loss analysis or more regular control efficiency assessments, rather than just focusing only on the risks now and then. I think another thing we should be able to do is draw in some expertise from other areas as well. The risk self-assessment covers only part of the picture – it won't cover all the risk and it won't cover them all to the correct level of detail. Obviously, using additional experts from outside should be helpful as well, and we need to find a way to do that. That may take some closeness and cosiness [away from] the RSA itself, but I think it will provide some valuable input. OR&C
Sign up for Risk.net email alerts
USA, 25th - 28th Mar 2014
UK, 26th - 27th Mar 2014
There are no comments submitted yet. Do you have an interesting opinion? Then be the first to post a comment.
Updating your subscription status
Risk iPad and iPhone Apps