The risk information challenge: Bringing technology to bear

What are some of the information challenges that you have run across in the course of your careers? What kinds of information challenges have you come across that have really proved to be intimately connected with the risks you face?

Mark Cooke (EMEA regional head of operational risk control): It's not a lack of data that gives me a problem; it's the lack of high quality information. The challenge is about getting the right content to the right people at the right time. In achieving that you are constantly making a trade-off between the speed of being able to bring the information together, the actual ability to form [sensible] content and the cost of actually achieving that.

As an organisation, we have focused on trying to integrate the disparate sets of risk information. In doing that, we seek to then provide the patterns, particularly at the senior stakeholder level. It's about trying to get those patterns so that they clearly articulate and frame the underlying risk issue. Perhaps I'll stop there. I'll lead on from there in terms of what we're doing to make those disparate patterns come together.

Elaine Fricker (head of UK risk management, Swiss Re): I don't know if this is the disadvantage or the advantage of going second, because I would just like to reinforce those comments. That is the challenge we are facing at the moment – there are a lot of disparate sources of information for risk management. The challenge is to pull them together in an effective way so that you are giving the board the information they want. At the end of the day they want to know where they should be afraid, where they should be very afraid, where they should just be aware, and where are we just telling them 'everything's happening, it's fine, you can have confidence that your risks really are being identified and managed effectively.'

At the end of the day we have to pull together these different things to give them information about what they need to know, not data. If you ask most of our senior management what they want from risk management, they'll say 'no surprises'. The question is: how can we put that framework in place and build that information so we give them advance warning of anything that is going on they need to know about?

Rei Tanaka (head of enterprise risk management and operational risk within the US practice, BearingPoint): One of the things we try to do is introduce a common lexicon of terms that multiple business functions use within their organisation. There are often multiple storage systems and multiple databases that carry similar data for different purposes within organisations, and one of the key first steps is to come up with a common lexicon or taxonomy to ensure that when we talk with each other within the organisation, we are talking about the same things. That is the simplest thing we can do. It is, however, very challenging.

Sean McClowry (head of information management within the UK practice, BearingPoint): In terms of bringing the information together from federated systems, it's a big problem. I think it points back to the need for historical quantification; to be able to quantitatively understand the issues – not just quality issues from an accuracy standpoint, but those related to [referential] integrity or integrating data. I would say that another way we like to start on programmes of work is to actually understand the data before you bring it together and start to move things. We typically like to run an analysis programme or data-profiling programme before we actually try to bring the data together from systems. It's better to find out about risks of failure at an early stage in the project than at the 11th hour.

Elaine Fricker: I'd like to add one small point to that though. When I talked about bringing together data sources, some of those are quantitative and some of those issues apply, and some of them are qualitative, and I would not want to change that either. I want to have a system that uses all of those different sources and brings them together into something that makes sense. I'm not trying to turn everything into just one data feed. I want those differences.

Mark Cooke: That's exactly where I would have come at it from. This is not an IT problem by any stretch of the imagination. It's not about connecting feeds in an automated fashion. It's an architectural problem. We've got a disparate set of risk events, we've got certification results, we've got the known risks – the ones that are already in our operational risk inventory – we've got our control and environmental metrics, we've got a myriad of qualitative data from specialist assessments performed by compliance, tax and HR, we've got top-down assessments from management, we've got the certification process, which is integrated with SOX activity, and we've got order reports.

We want to bring this risk information together in a way that hangs and forms a pattern. Half the art is even deciding what the referencing key is that you're going to use. For us, after 'x' number of years we are finally [going to go on] what we call our control objectives. It's come out of the certification activity. We have a high level of control objectives – there are about 20 for each function of business and that's the master key. So your risks hang off your control objectives, your audit points hang off your control objectives, and your loss history hangs off your control objectives.

Then you can start to aggregate this information up and see patterns. If everything is blowing red, you've probably got an issue you want to speak to senior management about. If it's just [scattered] and there's no leading trend there or nothing that's clustering, then you feel comfortable enough to say 'situation normal, don't mobilise the forces.'

Sean McClowry: When I say 'quantitatively understand' I'm talking about the fact that when you do bring data together, you often don't figure out if you've got problems until you're fairly late in the cycle. We often try to do that analysis in the early stages; to understand the cost or the challenges in bringing information together when you are bringing it together and before you begin talking from a technical perspective and before you begin integration. It's actually a bit of a reversal in terms of the software development lifecycle.

Mark Cooke: Certainly, once you've figured out the architecture you're trying to bring together. I don't downplay the fact there are a number of technical issues that organisations of size and people in this room are used to working with. It means that it actually does become quite challenging to bring it together in a timely fashion and present it in that way without having a massive workload overhead.

Question from audience: I think operational risk is still a journey for firms. Do you see an increasing need for collaboration between firms? There are already some initiatives I think, like in Switzerland where two companies are sharing loss databases, information and best practices across the boundaries of their own organisations.

Mark Cooke: We were having a joke about it when we arrived because it was two weeks ago that our colleagues hooked up to discuss what we can learn from each other in terms of our operational risk frameworks. So the answer to that from my perspective is 'absolutely'.

Elaine Fricker: I couldn't agree more. I've found that risk management is a community where people are actually – partly I guess because operational risk is a new-ish discipline – very willing to share their information. It really helps to bounce your issues around with other people and discover that (1) they're having the same issues, which always makes you feel better, and (2) possibly, they can help you find a different way of looking at things to solve it.

So, yes, I think the more networking and the more sharing of information, the better. Of course, there does have to be a little bit of caution sometimes. I'm more than happy to talk to banks and insurance companies, but probably not another reinsurance company.

Question from audience: There's quite a lot of discussion from the survey about this informal data and the informal networks. Are you finding that the case, or are you managing to track that informal data and get any value from it? Or is that still a challenge for the future?

Elaine Fricker: That survey does strike a resonance because, yes, I do get informal data from all sorts of sources. Some of it is not systematic per se, but there are certain committees and groups of people where we would discuss issues and try and pick up what it is that is concerning people. Those particular meetings/sessions happen on a regular basis and that is a source of informal information if you like – sort of top-down information. I will also collect any information I can from any source I can. I use it to double-check what I'm getting from my actual data that comes up through the system.

I think we've already discussed that we're still working on improving some of the data you can get for operational risk management. I always look to get any other information I can and ask 'shouldn't I also be getting that from bottom-up? If I'm not getting it from there, why not? What is it that's not working, what do we have to do, why didn't that happen?' It's a very useful check. I'm also very lucky because all the businesses I'm responsible for are based in one building. That does make my life very easy compared with, say, when I worked for the European operations that are scattered all over the place and it's much more difficult to get insights into what's going on and to attend the various meetings.

Mark Cooke: Informal data – there must be some buzzwords out there like 'human networks, exploitation of'. It's one of the key sources of good content. And you can go more broadly. You've got the information that you glean by bringing together individuals to talk about the issues. You've got information from what are fundamentally qualitative reports where people write about a specific issue. The art is then taking all that information and being able to bring it together to back-test it, see the patterns and see how it relates to other areas. That's why I talk about referencing and how you use your IT systems to allow you to make all that informal information, or non-digital information, more transparent in order to frame an issue and make decisions and ensure that the real problems in the organisation are absolutely transparent.

Rei Tanaka: I just want to add one more thing. As you all know, executives in many of these large organisations want a dashboard, a report on a regular basis, be it quarterly, monthly or even weekly, to get a bird's eye view of where the company is in terms of vulnerability, exposure to loss and risk and what the root causes are – what are we doing to manage and mitigate those things and so forth and, ultimately, how is it going to affect the bottom line?

We often help clients develop these dashboards and integrate the systems so that the process of creating these reports can be streamlined. These executives often do not totally rely on these dashboards and reports and they go off on their own to capture information through these informal networks. Right now, I think it's a supplementary source of information to manage risk, but we are seeing that it is becoming closer to centre-stage than behind the scenes.

Mark Cooke: Rei, you just got us to the crux of the matter. You can get data, you can apply judgement to that data and bring it together and you can get information. The proverbial pain is in how you are getting to the output of that information – who is it going to and how do they want to see it? In the infancy of this setup it was, in some ways, all about coming with your list of risks, putting it on the desk and adding to that until, before you know it, you're at 42 pages' worth of risk report. And, guess what – by the time you've put it on the desk and before you get out the door it's already gone into the bin. The challenge for us now in terms of bringing home the value that operational risk brings to the organisation is to be able to take information, apply judgement to it, and bring it in a very clear and crisp way. You often get one page to do it, such that you can engage in a 10–15-minute conversation with the key decision makers and get them to understand what their problem is and what they need to do about it, or at least to realise that they have a problem and they need to think about doing something about it.

Elaine Fricker: I think that's absolutely right and it's quite difficult when you have a dynamic process – something that changes – and you get different information in different ways. To actually come up with a structured report that gives your audience the information they want in the same way on a repetitive basis… always looking at it thinking perhaps we should do it this way or that way. We've tried hard to get a standard structure to the reporting – the headings, what's in there and where it comes from – but also to give flexibility as to the content so it's not just strictly dashboard.

We use the dashboard-type information to identify what it is we should be looking to tell the board about, and we try to have a slightly more flexible paper so it's actually about the commentary on what the issue is and what they should do about it that's the focus. The dashboard part of it is almost the bit underneath that tells us what we should be talking to them about.

Sean McClowry: Are you trying to incorporate any of the informal network information into the dashboard, or is that more if you're going to present the results on a more discussion-type basis?

Mark Cooke: There are three roles that I sometimes feel like I'm playing. I'm doing brand because I'm trying to create a sense that this is an op risk product, to ensure we have a constant lexicon and enforce that lexicon, and to enforce a risk methodology and context within an organisation – so it's a brand. Then I'm a graphic designer trying to come up with a cute picture that people understand because they don't like words. Then I'm a Sun reporter because I have to sensationalise, so it's 'shock, horror, you've got a really big problem with credit derivatives.' At that point you bring all your information together with your judgement to effectively give a qualitative commentary onto the hard data you may have displayed on your dashboard.

Elaine Fricker: But you're also using that qualitative data to validate what you've got in the dashboard. If the dashboard's telling you one thing – that something is your top risk – and you're hearing something different around the organisation, before that dashboard goes anywhere you need to have understood why that situation is happening and what is it, really, that you want to be telling the board.

Looking at Basel II's AMA, do you get value from it? I know you're maybe not applying Basel II, strictly speaking, but those are the building blocks of the business and if they aren't providing value, can you suggest that maybe should be in the AMA 2.0?

Rei Tanaka: I can talk about Basel a little bit. As I said, we've done a lot in Basel and in this [sector], for the past three years to be specific. Among the different types of operational initiatives that organisations can do, I believe that the risk and control self-assessment is one of the most critical in terms of identifying the risks, managing those risks and finding what kinds of mitigations or controls there are to go on and manage and monitor.

Mark Cooke: Just so we're clear, what do you mean when you refer to 'risk control self-assessment'?

Rei Tanaka: It means many things depending on the organisation. Before Basel or even the nascent years of applying to Basel's operational risk, self-assessment of risks by line of business were often driven by internal audit departments – they were mostly a checklist of questions that were distributed by internal audit. It wouldn't have been of much benefit to anyone other than the audit people. Then there was Basel and these businesses came up with a self-assessment, which was hopefully more beneficial to the business units in terms of risk management. Then there was Mifid and Sarbanes-Oxley (Sox), so I see the large organisations taking in these different types of regulatory compliance issues and taking a risk control self-assessment, and getting more value out of those efforts than just being compliant with regulations.

Mark Cooke: When we think of self-assessment I suppose we think of certification, so that's probably why I was…

Rei Tanaka: It's certification in terms of Sox and Mifid but, when I talk about RCSAs, I think it's more than that. We try to enforce to the line of business that there is business value beyond being compliant.

Mark Cooke: We have a certification process of which 40% of the things certified will specifically allow us to sign off on our requirements for Sox. The other 60% are asking us to sign off [to confirm] their control environment is effective and operating. It was particularly useful in the early days because it allowed us to form the initial inventory in terms of what our issues were. It also gave us the basis on which to establish control documentation and standardise our approach to an op risk framework. It certainly had value from more than just a compliance point of view. Today, that does not even get us over the line – not even close. It's just not dynamic enough. At best, it's done twice a year and we're looking to do that once a year. Now, our challenge is to use the information that exists on a day-by-day basis and bring it together effectively so that, at the very least, we form a view of our risk profile on a monthly basis.

Sponsored content