Ci3 Blog

Common-sense might tempt us to believe that the larger financial services organisations are the ones who are most likely to be leading the way towards Enterprise Risk Management. After all they have a more sophisticated view of risk management overall and have many years of experience in different areas of risk management. They also have the most to gain from the benefits of common risk management processes and a consolidated view of risk across the organisation. Some recent market research I have carried out in smaller financial organisations in the US and Europe points to an unexpected challenge to this assumption.

In the smaller banks, insurance companies and asset managers, the growth of regulation means that compliance is one of the most significant challenges that they face and, as a result, compliance management is a comparatively well developed (and well resourced) discipline. Compliance is also a very wide-ranging subject, encompassing most areas of and processes within the organisation and overlapping with many risk areas. What is happening is that regulators on both sides of the Atlantic are asking financial services organisations to take a more risk-based approach to compliance and, at the same time, encouraging them to have an enterprise-wide view of risk.

So why would the smaller firms be in a better position to adopt an Enterprise Risk Management approach? The answer seems to lie in where they are coming from. The larger organisations already have well developed risk management silos for different categories of risk, so there are both technical and organisational barriers to an Enterprise Risk Management approach. Each area has its own specific requirements and has bought or developed sophisticated solutions and bringing them together is both expensive and risky. In the smaller organisations these silos are less well developed, so it appears far more likely that a system implemented to manage compliance risk will also be adopted by other risk management areas that were hitherto using manual methods or spreadsheets. In these firms, cost constraints and small size may mean that instead of there being organisational barriers to an enterprise-wide approach, there are actually organisational incentives.

Mike MacDonagh

My last post looked at definitions of risk appetite and how it fits into a firm’s risk management environment. In this second part, I want to consider the Governance implications of risk appetite. In basic terms; “What’s it for?”

What is apparent is that the expression of risk appetite needs to be closely linked to the underlying objectives and that expression will depend on the nature of those objectives, especially in how it is measured. If an objective, say with regard to Corporate Social Responsibility, is not defined in financial terms, then the appetite for risk against that objective will probably also not be expressed in financial terms. This gives rise to the idea that each objective is likely to have its own risk distribution curve or profile that maps the probability of differing results, using whatever units the objective is expressed in. Different points on that curve will equate to achievement targets (KPIs) and the appetite/tolerance and capacity to withstand negative results. The role of risk management is to ensure that negative results don’t occur by reducing their probability in line with the group’s appetite. This is done not by attempting to shift the entire curve to the right but by addressing specific risk points, as expressed by risk appetite.

From a Governance perspective it is risk appetite and the associated risk and performance points or thresholds that play the key role of joining the organisation’s primary goals to its risk management framework. Of course, this link isn’t always direct or explicit. Large organisations will have a hierarchy of objectives, from high level business goals, to specific measures given to managers and, perhaps, individuals. It isn’t always the case but this hierarchy should be joined up, so that objectives at the lower levels relate, ultimately, to the organisation’s overall goals. In this way, risks to the fulfilment of those objectives and the appetite for risk against those objectives add together to give an overall view of risk against the high level business objectives and the cost of mitigating them can be measured against the objective itself.

So, getting back to the original question of “What’s it for?”, risk appetite is effectively the glue that joins a firm’s risk management framework to its business goals, directs risk management efforts to the overall benefit of the firm and provides management at all levels of the organisation with a consistent and consolidated view of their risks and how important they are in the overall scheme of things. Used wisely, Risk Appetite can be of great value in helping to ensure business objectives are met and significant risks avoided or mitigated.

Mike MacDonagh

I have spent a lot of time recently talking with Financial Services firms about risk and compliance and there’s no doubting that the visibility and maturity of these disciplines is increasing rapidly. Recent events, including the credit crisis certainly provide an incentive for this but the key driver is surely the desire of shareholders, rating agencies, regulators and the businesses themselves for better governance.

Risk appetite is a concept that sits at the heart of good governance but it is a concept that lacks a universally agreed definition and has a hugely varied implementation in Financial Services. It is a term that is often confused with other measures, so it is worth looking at some definitions of these, culled from a variety of web sources:

• Risk Capacity - is the maximum risk that an organisation can bear (defining ‘bear’ is another discussion point but is most often taken to mean ‘before insolvency’). Risk capacity is usually a straightforward financial measure.
• Risk Appetite - includes the additional element of possible gain and tends to align with specific areas of the organisation and is linked to broad objectives, often in a rather qualitative or informal way.
• Risk Tolerance - is a more quantitative measure of the amount of risk that an organisation is prepared to accept in pursuit of specific objectives. Risk tolerance is usually measured as a combination of impact and likelihood.

If we look at statements on risk appetite taken from the annual reports of two of Britain’s largest banks, the difference in approaches is apparent:
For Royal Bank of Scotland: “Risk appetite is an expression of the maximum level of residual risk that the bank is prepared to accept in order to deliver its business objectives.”
Barclays has a more specific view that risk appetite is: “…… expressed as the group’s appetite for earnings volatility ……. credit, market and operational risk …….. against our broad financial targets …. “.

In these cases, it appears that Risk Appetite and Risk Tolerance are perhaps closer than the definitions imply. In each case the key is that they are linked to objectives and this is what I am finding that firms are picking up on. Objectives provide them with the link between risks and a meaningful measure of the impact of that risk on what is important to the organisation. This works both on an enterprise-wide and a local scale and so provides a framework for risk measurement across the organisation. Importantly, it also provides a mechanism for using different frameworks for risk appetite different objectives, some quantitative and some qualitative. I’ll explore this in a future blog.

Mike MacDonagh

Controlling risk is an obvious concern  for organisations providing outsourcing services and for their customers. In addition to the immediate issue of managing risk in the service being offered, there is the added complication of agreeing who owns the risk and how they communicate information on its status and that of any mitigation strategies. In Financial Services, there are at least three areas of risk that need to be considered in this respect: operational risk, compliance risk and Service Level Agreement (SLA) risk. The first is obvious, the second results from the fact that compliance accountability remains with the customer even if risk management and mitigation is carried out by the outsourcer. SLA risk is, at first glance, purely a problem for the provider of the outsourcing services provider, for whom the SLA provides service and performance targets, often linked to financial penalties or, worse still, to cancelling of the contract. In reality these targets should be linked to genuine business requirements of the customer and so their management and mitigation is also a shared interest.

These needs lead to some very specific requirements for a risk management solution. Firstly, it must be able to work seamlessly across two or more organisations while maintaining separation of confidential data where necessary. This requires a system that is securely web-enabled and that has a high degree of permissions management, for task management but also for data management, all the way down to reporting level. It is no good having great security within system functions if a user can produce reports across the entire database. Another requirement is the ability to set up multiple and possibly exclusive risk frameworks for oprisk, compliance and SLAs, so each of these can be assessed and managed separately and associated elements such as losses, breaches and KRIs can also be differentiated. Reporting and audit are also key requirements, the main parties in the relationship must be able to share the right information quickly and flexibly and trust in such a relationship is much easier to achieve if it is based on a comprehensive audit trail that provides both parties with evidence of what actually happened when a problem arises. With an SLA dashboard, both parties can have an immediate view of status of the service, warning of any problems and the ability to drill down to the actions being taken to mitigate them.

Outsourcing is a competitive business but for the outsourcer who can demonstrate the ability to control his customer’s operational and compliance risks while managing his own company’s performance against a Service Level Agreement their is a significant advantage.

Mike MacDonagh

“An organisation’s risk measurement system must be closely integrated with their day-to-day risk management processes.” The FSA’s Use Test aims to ensure that risk measurement that is carried out for regulatory purposes is not separate from but is embedded within their risk management practices. In my experience however, it is surprising how often a firm’s risk management practices are themselves not embedded in their day-to-day business processes. All too often, core risk management processes such as risk and control assessment, KRI assessment and the capture of loss and near miss events is carried out not by the business staff who are closest to them but by a separate risk management or compliance function.

This has echoes back to the 1980’s and 1990’s when we were introduced to Total Quality Management with the realisation that if you have a separate quality assurance team, the rest of the workforce has a tendency to assume that quality is someone else’s problem. As with quality, this has the potential to be a significant factor with risk management. Identifying and trying to mitigate risk should be the concern of every employee, not just the risk and compliance teams. Only when business staff are actively involved in the management of risk does genuine best practice have the chance to evolve within an organisation.

Many organisations have compromised, with an intermediate approach in which risk and compliance staff gather information from business staff on an occasional basis. On the surface, this sounds like an improvement but it too has significant weaknesses. Firstly, timing, the gap between the event and its recording is itself a risk. More importantly, the potential role of business staff in identifying risks and losses or near misses and their involvement in devising mitigation strategies affects not just the effectiveness of risk management but its efficiency as well.

So, by involving business staff in the risk and compliance processes, organisations can reduce the incidence and seriousness of risk and cut the amount they spend on doing so ………… the FSA has it right!

Mike MacDonagh

In Financial Services we are all familiar with the idea that the financial system is so interdependent that the failure of a relatively small firm has the potential to cause larger failures and, possibly, complete meltdown of the system. There is a general principle at work here, that of tightly coupled networks. Basically, this says that if a network is highly efficient, redundancy has been removed and therefore an apparently insignificant failure in one location can lead to a total failure. One of the classic cases of this was the electricity blackouts experienced in North America in 2003, as a result of the failure of apparently unimportant nodes in the grid.

This same concept can be applied to business processes within a global financial enterprise. As financial services organisations become more highly organised and (hopefully) more efficient, redundancy is removed. The question is, where should redundancy be retained, and how do we identify when lack of it might become a threat? Risk managers identify individual risks in business processes across the organisation and put controls in place to mitigate them. The difficulty is that risks are usually managed in silos across the organisation, so the correlation between, say, credit risk and liquidity risk may not be known and won’t therefore be controlled. Even within a silo, there is rarely much attention given to the inter-relatedness of risks. And correlation also applies to controls; if a control fails or is not run this may have an impact not just on the related risk(s) but on other controls as well. There can be several consequences of this, all of them undesirable: in the best case scenario, the impact and likelihood of risks may be underestimated and the ability of controls to mitigate those risks may be overestimated, in the worst case risks are not recognised at all and are therefore completely uncontrolled.

I have blogged before about the EU’s MUSING project and one of the key benefits that MUSING aims to deliver is in this area of correlation. How does this work? Firstly, MUSING uses ontologies to describe the risk management domain. The use of ontologies has the advantage over simple Object Oriented domain modelling in that it has a logical inference capability that allows us to model not just the relationships between elements (e.g. risks and controls) but the rationale behind those relationships. Once we have that information, we can start to assign quantitative information to those relationships and, here, bayesian networks can help us not just to understand and measure the impact of correlation but to model it on an ongoing basis. By combining this technology with an enterprise-wide view of risk and its mitigation, financial services organisations can start to understand the impact of tightly coupled networks in their business processes and ensure that it is managed.

Mike MacDonagh

We all recognise the format; one word, four different but apparently plausible definitions but only one is actually true. All good fun but now let’s visit any risk management or compliance conference; at least four vendors touting their wares, all using one term, GRC, but all of them selling something different and who’s bluffing?

Of course I’m not suggesting that our industry is full of liars trying to take advantage of the unwary but the fact is that GRC is a term that perhaps lacks a clear and universally accepted definition and, of course, the tendency for any vendor is to favour an interpretation that most closely fits whatever products it happens to have. This may be a sign that GRC is still an immature discipline but, more likely, it reflects the different directions from which organisations are addressing compliance. For example, a company that already has a good Operational Risk Management solution is likely to look at the possibility of extending that to start provide GRC services (such as centralised issue and action management), or a company that has a strong Audit function might decide to lead their GRC strategy from there. As long as GRC is still a series of steps driven by a vision and is not a single project, this approach is likely to remain in favour.

In this way, diverse vendors will acquire ‘GRC’ customers and then try to leverage those by proposing similar projects to other companies. To the market they simply say; “We have a GRC solution and GRC customers”, not quite true but, in most cases, not a conscious bluff either.

Mike MacDonagh

If you want to start an ERM project in a Financial Services Organisation, you start with one of the hardest tasks of all, convincing senior management that the outcomes will make it worth spending what may well be a significant amount of money. Their first questions will probably be “What will be our Return on Investment, where will it come from and when will we get it?” Of these, the ‘where’ question is probably the easiest to answer. Commonly cited benefits include:

• Cutting(or at least not increasing) costs as a result of greater efficiency in risk management (mainly cutting down on the duplication of effort in data collection and reporting)
• Reducing spending on siloed risk management systems
• Cutting down on losses resulting from risk events
• Reducing insurance premiums by demonstrating a good control infrastructure

My experience at the moment is that the ‘what’ and ‘when’ questions are just too hard and ERM projects tend to be driven either by a desire to prevent serious losses that could result from interdependent risks across multiple risk types or by specific regulatory requirements, e.g. scenario analysis for ICAS/ICAAP. This may change, especially as belts are tightened after recent events, but I’m not holding my breath.

Mike MacDonagh

I have spent the last two days at a meeting of the Governing Body of the MUSING project (www.musing.eu). This EU project is dedicated to investigating ways “to integrate Semantic Web and Human Language technologies and combine declarative rule-based methods and statistical approaches for enhancing the knowledge acquisition and reasoning in Business Intelligence applications towards industries with a deep socio-economic impact”.

What this means in reality is a group of academics, technologists and business people combining leading edge research and practical experience in projects that will result in the building of a platform that can be deployed in real businesses and, most importantly, to deliver real business value. I will write more on this in the coming weeks but the key areas of interest include:

- Semantic-based Knowledge Management - taking unstructured data in different forms and using new techniques to turn this into data and thence into knowledge. This has links to the drive towards the Semantic Web, aiming to exploit the vast amount of unstructured information on the internet.

- Ontology Engineering - is a key element of the ability to understand unstructured information. Ontologies allow us to describe the kinds of entities that exist in a domain and to describe the relationships they have with each other. This goes further than an XML schema or a data or class model, in that it represents what we know about a domain and not just that entities are related but the reasoning behind those relationships.

- Bayesian Statistics -  in the real world, most situations involve a mixture of qualitative and quantitative information and the use of Bayesian analysis and Bayesian networks enables us to bring these together in more effective ways, in order to arrive at a more accurate view of the real world around us.

So what does this mean for Risk Management? - well rather a lot. The issues that we are addressing in MUSING can improve our ability to manage many of the key elements of Risk Management:

- Risk Identification - it can be the risks that are missed completely that cause the greatest damage. Semantic methods, linked to well defined ontologies can play a major role in improving the identification process.

- Risk Assessment - risk assessment is often not quantitative and, where it isn’t, these techniques can be used to find the key assessment data from a wide range of sources and bring them together more accurately than currently possible.

- Loss Management - loss data comes in a wide range of forms; formal and informal, quantitative and qualitative, structured and unstructured, internal and external. The MUSING technology will help to find more information and to make better use of the information that can be found.

- Risk Mitigation  - in the same way that Bayesian networks can be used to assess correlated risks, they can also be used to make sure that the benefits gained through mitigation of one risk are reflected in correlated risks.

- Key Risk Indicators - the ability of Bayesian analysis to help us find the correlations between apparently unrelated data and then measure its significance is sure to prove of great value in avoiding risk events.

Mike MacDonagh

Shortly after writing today’s blog on the different approaches to the management of risk and of compliance (http://www.ci3.ie/blog/?p=7), I happened to visit Michael Rasmussen’s latest GRC.Pundit blog. Thinking about IT Governance, it also falls very much into the control-based category and IT standards such as COBIT and ISO17799/27001 all take a controls-based approach. I suspect that the difference between the approaches for IT Governance and Compliance, is that compliance controls tend to reference regulations, as enshrined in policies, whereas IT governance controls tend to reference processes. In an Enterprise Risk Governance environment, both should also be described and quantified (if only in a qualitiative manner) in terms of the underlying risk(s) they are controlling.

Mike MacDonagh