On 6th August 2020, the Basel Committee on Banking Supervision (“BCBS”) released a consultation on the ‘Revisions to the Principles for the Sound Management of Operational Risk’ (PSMOR). This is arguably one of the most significant updates on expectations surrounding operational risk management in the last 10 years, and will drive regulatory interactions going forward. Whilst the changes can be seen as evolution rather than revolution, and it should be noted that they are under consultation, they point to a shift in momentum, which we believe firms should start considering now. Notably, the Principles suggest greater regulatory scrutiny of banks’ Operational Risk practices through increased expectations upon national supervisors. Comments to this consultative document should be submitted to the BCBS by 6th November 2020, with an expectation that the final Principles will be released in 2021. Although the Principles are initially aimed at banks, we would expect that over time the sentiments set out in the Principles will drive regulatory conversations in the broader FS industry.

The BCBS first set out its PSMOR in 2003 and subsequently revised them in 2011 to incorporate the lessons learnt from the financial crisis. In 2014, BCBS undertook a review of the implementation of the Principles to (a) assess the extent to which banks had implemented them; (b) identify significant gaps in implementation; and (c) highlight emerging Operational Risk practices at banks which the Principles had not addressed. The 2014 review identified that several Principles had not been adequately implemented, and concluded further guidance would be needed to facilitate their implementation. This consultation incorporates the recommendations from the 2014 BCBS review and reinforces and builds upon many of the original Sound Principles required for management of Operational Risk. Whilst the BCBS has not explicitly incorporated lessons learned from COVID-19 pandemic, the consultation period still provides the opportunity to do so before the Principles are finalised. Although operational resilience is not dealt with explicitly in the Principles (and has been tackled in a separate paper by the BCBS), several key issues are common across the papers, in particular in the areas where the BCBS has proposed changes to the operational risk Principles e.g. Principle 10.  

We set out our interpretation of some of the key changes in the PSMOR below.

The increased focus on change management (Principle 7)

With the increase of agile business models, quicker change cycles and the renewed focus on Business (Operational) Resilience, there is greater direction on how Operational Risk functions interact with Change Programmes. This should include new products, business activities and IT change activity and consideration given as to how risks are identified, measured and controlled. The BCBS revisions to Principle 7 stress the need for senior management to have processes that are comprehensive, appropriately resourced and include continuous risk and control assessment articulated between the 1st and 2nd lines of defence. Specifically, the Principle 7 reinforces the general direction of travel of the 1st line of defence performing risk and control assessments of new products and initiatives and the Operational Risk Function providing oversight and challenge to all phases of the change process, from identification and planning stages through to implementation and post implementation. The emphasis of the 2nd line providing challenge over all stages of the change lifecycle is one that many banks may need to enhance practices to meet.

Recognition of the importance of Information, Communication, Technology (ICT) as a component of Operational Risk (Principle 10)

Alongside traditional Operational Risk and Control assessments, there a greater need to better understand the rising risk exposures across a bank’s IT estate. As a consequence, BCBS has introduced a new principle for ICT. This Principle reinforces the need for a robust ICT framework, one that is consistent with the bank’s risk appetite and tolerance statement for Operational Risk, in order to reduce its risk exposure to direct losses, legal claims, reputational damage, ICT disruption and misuse of technology. In addition, the board and senior management should routinely evaluate the design, implementation and effectiveness of their ICT framework to ensure risks arising from data and systems’ confidentiality, integrity and availability are managed and controlledThere is also a requirement for banks to make use of actionable intelligence to continuously enhance their situational awareness of vulnerabilities to ICT systems, networks and applications and facilitate effective decision making in risk. Whilst we observe that IT Risk frameworks are becoming increasing common, many banks still have challenges in reconciling them with Operational Risk frameworks, and many are still too static in nature.

Enhanced design requirements for an effective operational risk appetite and tolerance statement (Principle 4)

Risk appetite continues to be a challenging aspect of many banks’ Operational Risk Management Framework, and whilst thoughts on risk appetite design continue to evolve, this continues to be an increasing area of regulatory focus. To this end, we observe a second wave of enhancement to Operational Risk appetite and more explicitly strengthening the link between business strategy and risk appetite. Given the increasing complexity of risk appetite constructs, there is now a specific PSMOR requirement for risk appetite to be easy to communicate and therefore easily understood by all stakeholders. The Principle also reinforces the general direction of travel where firms cascade appetite limits to Business Unit and at Entity level. This can be challenging, and whilst many larger organisations have implemented such a structure, a number of organisations still have it on their radar to progress.

Emphasis on accurate data for Risk Assessments tools (Principle 6)

Well-established Risk Assessment tools such as RCSA, KRIs, Internal Incidents and Scenario Analysis are widely observed where first line management are responsible for identifying and assessing their risks and controls, with second line providing oversight and challenge. In the era of ‘big data’, we are increasingly observing a number of firms leveraging data analytics, artificial intelligence and intelligent queries to have more robust data that inform their risk assessments. The proposed BCBC revisions to Principle 6, reinforce the importance of risk assessments tools being based on accurate data, with integrity to be ensured by strong governance and robust verification and verification procedures. In our experience, many firms express the view that the quality of their underlying operational risk data is variable at best. The need to increase the timeliness, accuracy, and insight of data will require banks to revisit processes and necessitate consideration of the potential of technology to assist in the improvements required.

Recognition of the importance of Operational Risk reporting in the 1st line of defence (Principle 8)

Risk reporting is a perennial problem for firms, which is characterised by large volumes of often historic data being reported to Boards and executive committees without any clear linkages to Board‑approved risk appetite parameters. The BCBS revisions to Principle 8, stress the need for risk reports to be manageable in scope and volume and linked to a bank’s risk appetite to aid effective decision-making. The Principle reinforces the importance of risk reports that are comprehensive, accurate, consistent and actionable across business units and products. Reflecting the industry trend towards greater risk responsibilities in the business, the Principle also reinforces the need for the 1st line of defence to develop their own operational risk reporting routines. This last expectation will be challenging to implement, as many firms without line 1B control functions still have consolidated operational risk reporting purely within the 2nd line.

Increased transparency to stakeholders through increased disclosure requirements (Principle 12)

An interesting addition is the expectation that banks should disclose operational risk exposures (including loss events) to stakeholders as well as their approach to operational risk. Additionally there is a requirement to create a formal disclosure policy – detailing the scope of risk exposure information to be disclosed, alongside the process for disclosure with associated controls. This reflects the industry trend towards greater transparency and consistency in external operational risk reporting, but if not yet developed, care will be needed in writing a document that manages reputational risk whilst aligning with appetite and being instructive for the wide range of exposures that can crystallise.

Summary – A call to action?

There are new instructions to regulators about an expectation to scrutinise banks’ operational risk frameworks against these Principles, or use external parties to do so. We can therefore envisage that these Principles will be used as a vehicle to push for further increases in operational risk practices maturity. The consultation may result in changes, but broadly the Principles do reflect a direction of travel in the industry in relation to consideration of non-financial risk more holistically, a push of responsibilities  in to the 1st line, focus on insight gleaned from non-financial risk data, and greater transparency. We therefore would advise banks to read the consultation proposals carefully and consider their response. Implementing and embedding enhancements to operational practices can take a significant amount of time, so understanding potential gaps and deciding on required actions should be a priority. Deloitte have developed a Sound Principles Maturity Accelerator which can be used as a structured approach to benchmark maturity against the proposed Principles and current industry progress against them.

If you wish to explore further, please contact:

Stephen Lucas, Mike Kirkman, or Imran Hussain.