Finding the reward in managing risk

By Mohammad-Nasser Barakat – General Manager of Aldar International 

The Basel Committee defines operational risk as the ‘risk of loss resulting from inadequate or failed internal processes, people and systems or external events’. The definition includes human error, internal and external fraud, IT systems failures and cyberattack.

In fact, the scope is so wide that without a sound operational risk management methodology combined with the support of bespoke software tools, it is almost impossible for an organisation to capture, analyse, mitigate and monitor these risks. However, such systems, when properly implemented, significantly reduce the number and impact of incidents.

Unfortunately, despite the numerous benefits derived from implementing operational risk management systems, the implementation process is filled with challenges and common mistakes, which, if not addressed properly, will jeopardise the success of this very important initiative.

Having assisted more than 30 financial institutions in the Arab World to successfully implement operational risk management (ORM) systems, in this article I will highlight some of the more common and important factors that should be considered for a successful implementation.  

Identifying and assessing risks is the first phase in implementation and will form a foundation for the future. Sufficient time and effort must be invested in this phase for all the remaining phases to succeed. This is because the relationship between risks and controls is complex and trying to overly simplify this relationship will lead to a failure in capturing, assessing and mitigating risks. Below are just some of our recommendations for conducting sound risk assessments and control evaluations:

Clear definitions including those of ‘risk’ and ‘control’

The definition of operational risk in the minds of officers will vary across the organisation. This will lead to confusion when initially identifying and assessing risks. The scope of the assessment and what types of risks are included (or not), needs to be clearly defined and communicated right at the start of implementation i.e. before the risk assessment exercise starts. Failure to do so will lead to a failure to capture and address important risks and disagreements with the business units on the results of the risk assessment exercise and the remedial actions to be taken. The same also applies to ‘controls’: the scope must be clearly defined and communicated.

Training

Having defined the terms being used, what is considered as risks and what controls are, it is then important to provide a level of training to those involved in the assessments. Generally, training can be provided at two levels. A detailed level of training should be provided to the assessors. A less detailed level may then be provided for those who are involved in assessments but not leading them. Training should also include the tools being used for risk assessment and management.

Conduct an in-depth analysis

 A common mistake in implementation is to identify risks at too high a level. It is impossible to accurately assess the strength of the mitigating controls unless you understand how risk can occur; the risk driver(s), and the exposure. As an example, it is quite common to identify ‘internal fraud’ as a risk. However, unless the risk driver (what will cause the internal fraud to occur), the consequence (what the risk will result in), and the exposure (what will be lost if the risk materialises) are identified, it will be impossible to accurately evaluate whether the existing controls effectively mitigate this risk.

Capture the asset resource that will be impacted if the risk occurs

 Not all assets resources impacted have the same level of importance or value to a business; some are much more important than others. An example in financial institutions would be a risk that impacts an organisation’s reputation in comparison with a risk that impacts its physical assets. Damage to your organisation’s reputation, that you have spent many years building, will be very difficult to repair, however the cost of replacing assets can be more clearly defined and implemented. Unfortunately, this important factor has and is still being ignored by many organisations.

The various impact levels relating to each asset/resource must be defined at the start of implementation and communicated during training. This will help increase the accuracy of risk assessments since the definition of high-, medium- or low-impact levels will differ in people’s minds.

Capture the many-to-many relationships between risks and controls

A common mistake is to assume that the existence of one control is sufficient to mitigate a risk without considering all possible scenarios for the risk to occur. Multiple controls may be required to mitigate all aspects of a risk and each control may be a factor in the mitigation of multiple risks. A failure to capture these many-to-many types of relationships would oversimplify the relationship and lead to a failure in properly estimating the strength and effectiveness of risk mitigations

Control effectiveness should be assessed against each risk it mitigates

A control might be ‘strong’ in mitigating one risk while at the same time ‘weak’ in mitigating another. Weight needs to be assigned to quantify the strength of the control in relation to each risk.

Review the thoroughness with which a control is actually applied

This is where many ORM implementations fail. They usually assess risks assuming the identified controls exist and are working as intended. Even if the controls do exist and are properly functioning on the date of the assessment (and in many cases, this is a false assumption), they still need to be regularly tested to ensure they remain working as intended. For example, a company may control access to certain areas using access controls such as proximity passes. However, if staff regularly tailgate each other through such controls or maybe hold the door open with a door wedge, the control is ineffective and must either be changed or enforced. The risk assessment exercise carried out at the start of ORM implementation to build the risk database gives a snapshot of what an organisation believes the risk and control status to be. A review to check if the controls are actually applied, often finds many controls are not followed and the risk is significantly higher than the assessed level. If not updated (risks reviewed and controls tested periodically), the risk database will rapidly become obsolete.

Proactive versus reactive operational risk management 

Operational risk management needs to be proactive; aiming to predict incidents that have the potential to occur in the future and take the necessary measures to protect the organisation against their occurrence. 

Tracking actual events (recording and analysing loss events) is reactive, and although it is useful in updating the risk database and ensuring the necessary measures are taken to avoid the recurrence of these events, it cannot be relied on as the main tool for managing risks. 

This would be like driving forward while looking at the rearview mirror! What if a major risk that has never occurred before and has the potential to collapse the company actually takes place? There will be no benefit from analysing it after the fact.

Remember the 80/20 rule!

Due to the number and diversity of operational risks, it is essential to prioritise ORM activities/tools to start implementing those that will achieve the biggest impact first. A common example would be key risk indicator (KRI) monitoring. 

Many organisations will waste a lot of time and effort if they start monitoring KRIs before completing the risk assessment exercise first, since they will not be targeting the most important risks to monitor using this time-consuming tool.  

Address the risk culture

Changing the culture is one of the most important challenges facing ORM implementation with its significance and benefits often being overlooked. Issues, such as the message from the top highlighting senior management support, risk awareness, line management responsibility and accountability towards risk management and control implementation and monitoring, etc, should all be addressed from day one. 

My experience is that having the responsibilities of the various stakeholders clearly defined in the operational risk management policy, conducting awareness sessions with senior management and the board as well as line management, and linking compensation with KPIs that relate to managing risks and the control environment, will positively contribute to building the right risk culture and avoid a blame culture.

Create synergies

To manage operational risks effectively, risk management cannot work in isolation. This is simply due to the fact that the actual risk mitigating activities are implemented by the individual business units and not by risk management. As a result, line managers should participate in risk assessment and take ownership and responsibility for managing their risks (i.e. identifying and assessing risks together with implementing and monitoring controls required for mitigation). Relying solely on process mapping for the identification and assessment of risks without engaging the business units’ management and staff will not move the responsibility to line management.

ORM should also closely align with other control functions in order to maximise efficiencies.  Internal audit, for example, will rely on the operational risk data to implement a risk-based internal audit approach that will maximise the efficiency and effectiveness of the internal audit function, but while doing that, should conduct independent checks on the self-assessment test results reported by the business units and provide assurance on the reliability of the test results. In addition, if the other control functions (e.g. internal audit and compliance) have their databases of risks ranked in accordance to what they think is important (i.e. they do not rely on the operational risk database), this will create confusion as to what risks are important and should be given higher priority, and might also result in contradictory reports to senior management and the board.

Tool selection

Many software tools are available to assess and monitor risk, however valuable time and effort will be wasted if the implementation starts with the wrong tool. It is common for a business to select a tool and then try to force their business model to fit the tool. 

I have seen many organisations try using Excel sheets initially, but later decide that they cannot proceed further as Excel can only be used to record operational risks and does not have the features needed to manage those risks.  A tool should aid and not hinder your business and should be able to, as an example: 

• Quantify inherent and residual risks
• Allow business units to conduct self-assessment tests
• Use event data to refine and validate the risk database
• Use historical data to predict the value of expected OR loss incidents
• Allow for ORM to collaborate with compliance and internal audit (special modules should be available to allow for compliance monitoring and risk-based internal audits)
• Measure the gap in the control environment
• Send automated alerts for important deadlines, pending remedial actions, risks breaching threshold limits, and any other exceptions noted

About The Author:

Mohammad-Nasser Barakat, is the Managing Partner at Aldar International Governance Consultancy (AIGC), a CPA and a Certified Control Self-Assessment (CCSA) practitioner with 28+ years’ experience including 6 years as Board Member and Chairman of the Audit and Risk Committee of a large public Shareholding Company. With extensive experience implementing Operational Risk Management Systems in financial institutions, he has supervised implementation of systems in financial institutions across the Middle East Region including Commercial, Islamic and Investment banks. His expertise includes the delivery of Operational Risk Management training and awareness, Implementing Operational Risk Management software solutions, Conducting Operational Risk Assessment workshops and Quality assurance reviews of Risk Management and Compliance Functions.