ARCLogics Sword Blog

Many organizations today have some form of method and system in place for the effective management of day - to - day risks, such as control assurance frameworks and effective risk and control assessment processes. These processes are employed to effectively manage their current risk and somewhat help to identify future risk within the organization. The application of other practices such as mitigation techniques and incident management further enhances this process. But what about those risks that are coming down the track in the long term?

Many organizations are currently considering how they can improve their capabilities for identifying their next big emerging risk. Many emerging risks or ‘global’ risks are systemic in nature and may often be beyond the capability of one single organization to contain. The World Economic Forum’s Global Risks Network, with organizations such as SwissRe and Zurich at the helm, recently published its 2010 Global Risk Report. Fiscal crises and unemployment, underinvestment in infrastructure and chronic disease are identified as the pivotal areas of risk over the next years in the report. The report also explores the interconnectedness of risks, and considers how the strategies for the mitigation of emerging risks might be structured.

The Global Risks Network recommends that organizations take a long-term approach to emerging risk identification, analysis, tracking and mitigation. The management of global or emerging risks can be supported using different functions within our Sword Operational Risk system. The use of these functions can be combined or they can be used independently to manage emerging risks depending on the organizations own internal approach. One approach is to assess the risk’s significance within the organization, how it is linked to other risks and its implications to the business through risk assessment in Swords Risk and Control Assessment module. Such a process should be separate to the current assessment framework.

Another more powerful method is the use of scenario analysis through the Sword Scenarios module. Scenario analysis can serve as an effective means for organizations to estimate their potential risk exposures and levels of preparedness should catastrophic risk events emerge. This method is currently being employed by relatively few organizations but provides an excellent format for exploring what the future might look like and the likely challenges to the business.

A third method is to routinely monitor emerging risks through effective use of leading indicators within Swords indicator module. Monitoring emerging risk indicators helps to develop the organizational agility to address unknowable risks when they arise. Lessons learned should be captured in the issue and action module for analysis in relation to leading indicators, to further improve risk resilience.

The three approaches can also be combined together to identify, manage and mitigate emerging risks more effectively in the long term.

 Dan Wallace

I have written recently on the the value of scenario analysis in terms of reducing the risk of or mitigating the impact of extreme events (http://www.cchsword.com/blog/?p=20). As a vendor of a risk management solutions we are constantly faced with the need to convince our customers and prospective customers of their value. In the case of Scenario Analysis, where the solution is seen simply as an aid for assessing a dozen or so scenarios to calculate regulatory capital, this can be a challenge. Of course there is an existing answer to that, based around pillar 2 and the Use Test. Where the scenario modelling and analysis functionality is built into the same system that supports the risk management framework, as it is in Sword, it will be much easier to satisfy the regulators.

From the insurance community however is emerging a different use of scenarios that has a more immediate business value. Scenarios used for assessing regulatory capital concentrate on the tail events in loss distributions, attempting to estimate the frequency and size of extreme events but scenarios can also be used to model the high volume, low value events that  fall in the ‘expected losses’ portion of the loss curve. Insurers are used to this type of analysis when looking at insurance risk but are starting to look at their own risks in the same way. Taking an expected loss scenario for which several million euros or more is reserved each year; if the organisation can build scenarios around the actual risks, controls and losses involved, it can examine the impact of further mitigation measures and put indicators in place to monitor the risk and allow early intervention. Unlike with extreme event scenarios, this involves assessing fifty or more different scenarios at many different points across the enterprise, with the total number of scenarios reaching or exceeding one thousand. This level of scenario analysis must be automated but it does raise the possibility of being able to go to senior management and ask for a budget to reduce expected losses immediately. I wouldn’t dare suggest that senior management in our financial insitutions might take a short-term view but human nature is such that this may be an argument that is much easier to win.

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

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

Risk Convergence, the coming together of Operational Risk Management and Compliance is real, at least from an organisational perspective. Some Financial Services Organisations are bringing their Compliance department under Risk, some simply putting people with risk management experience in charge of compliance. This is driven both by regulatory pressures requiring them to take a more risk-based approach to compliance and by the need for efficiency, in the hope that duplicated actvities and systems may be avoided.

The organisational challenges of Risk Convergence should not be underestimated. Compliance departments (and individuals) are often criticised for being pedantic, rules-driven and technology averse but these are admirable qualities in their particular sphere and the attention to detail, and sheer doggedness shown by many compliance officers could be seen as characteristics that many risk officers could do with more of.

One way to help with organisational challenges is to implement a common IT infrastructure to support both functions but there is a fundamental problem here, that is born of the different ways in which risk and compliance are managed in businesses. As you would expect, Risk departments take a risk-based approach, identifying risks to achieving business objectives within their activities and processes, assessing those risks and then developing and managing mitigation strategies for them. Compliance however is much more likely to be control-based. A set of regulatory outcomes is defined, often in policy documents, controls are identified and a rolling programme of assessment, monitoring and reporting created. In one case (risk), the fundamental element is a Risk Register, underpinning a risk framework, while in the other (compliance), it is a Control Register. Similarly, reporting tends to reflect the risk- or control-based approach.

Depending on their provenance, IT solutions tend to take one approach or another. So, Operational Risk systems will be risk-based, whereas compliance systems (often SOx solutions) will be control-based. This means that attempts to implement a common it infrastructure for risk and compliance usually favours one approach to the detriment of users who want to take the opposite one. Ci3’s SWORD is, perhaps, unique in that it allows users to take view data from either perspective and we are in the process of adding a Control Register to the existing risk register. This means that an organisation can implement a single solution for risk and compliance but still allow risk and compliance professionals to manage their responsibilities as works best for them.

Mike MacDonagh