Operational Risk Management - at a Crossroads!

As a discipline, Operational Risk Management (ORM) is at a crossroads!.

Blindsided and relegated to little more than a data collection function by the Basel Standardised Measurement Approach (SMA) for computing Operational Risk Regulatory Capital (ORRC), operational risk managers are a valuable resource that is currently being wasted and could, because of their very relevant expertise, be used to promote and drive regulators’ Operational Resilience agendas.

This article highlights how operational risk managers could and should position the ORM discipline to take a leading role in helping to improve operational resilience across the financial sector. This means moving away from their rather narrow focus on regulatory capital towards using their skills in a much-wider and, arguably more important, endeavor, that is, integrating operational resilience thinking into the discipline of operational risk management.

The Standardised Measurement Approach

The Financial Services Forum (FSF), an advocacy group for the largest US banks[1], highlighted the current dilemma for Operational Risk Management [1] when discussing the latest Basel III rules of Operational Risk Regulatory Capital (ORRC) [2].

“Banks, like all businesses, are subject to operational risks. These risks are important and need to be managed. Further, banks should maintain robust capital to account for these risks. At the same time, however, there is no clear or compelling evidence to suggest that operational risks present a concern commensurate with a $1.4 trillion dollar increase in RWA [risk weighted assets] that would represent the key driver of increased large bank capital requirements. …. Taken together, these observations suggest that regulators and the public should have serious concerns about moving forward with the standardised operational risk framework as presented in this proposal. The current proposal would inflict a usurious tax on all large bank products and services that is not justified on the merits and stands to weaken our economy. [emphasis added]”

In other words, the SMA, as mandated by Basel, is just not working!

The proposal by the Basel Committee, in 2016, to replace the so-called Advanced Management Approach (AMA), for estimating operational risk regulatory capital, which admittedly was over complicated, with a much simpler Standardised Measurement Approach (SMA) was widely criticised, when it was first mooted as being too simplistic since it mandates estimation of future capital requirement, based purely on historical losses.

There is no theoretical nor empirical rationale for taking such a naive approach to managing operational risk and is, in practice, just wrong [3,4,5,6] ! As the Financial Services Forum [1] argue, the supposedly ‘simpler’ approach is inappropriate, indefensible and unusable in practice.

Worse than that, from the perspective of operational risk management practitioners, the SMA approach turns them into mere bookkeepers who organise the collecting of loss data, enter it into databases, which then spout out aggregate numbers from an extremely simplistic formula. Although arguably, they should have been stronger in their antipathy to the Basel proposals, ORM functions, which consist in general of very knowledgeable experts in how banking operations actually work, are now stuck in a paper-pushing backwater.

In a volatile world, where finance is changing rapidly (think Instant Payment Systems, Central Bank Digital Currencies and even Cryptocurrencies) it would be a crying shame (and real loss to banking) not to put those years of experience and expertise to uses better than running spreadsheets.

Operational Resilience

But there is hope, in the form of new regulatory proposals concerning ‘operational resilience’, such as the new Digital Operational Resilience Act (DORA) promulgated by the European Parliament in 2020 [7]. Other regulators have issued rules in a similar vein, however not as thorough as the European Parliament, such as in the UK [8], USA [9] , Canada [10] and the Basel Committee itself [11].

Operational risk and operational resilience share more than the term ‘operational’ in their names; they have the same basic goal – making banking safer and their relationship is identified by the US Federal Reserve [9].

“ Operational resilience is the ability to deliver operations, including critical operations and core business lines, through a disruption from any hazard. It is the outcome of effective operational risk management combined with sufficient financial and operational resources to prepare, adapt, withstand, and recover from disruptions [emphasis added]”.

Repeating - “it [i.e., operational resilience] is the OUTCOME of effective operational risk management”.

But operational resilience involves very much more than the narrow focus on regulatory capital that has dominated, and arguably distracted, ORM thinking since its inception in the early 2000s.

Given the dead-end that the Basel Standardised Measurement Approach has become, the message of operational resilience to operational risk management is to park this meaningless capital calculation and focus on the outcomes of operational risk. And then maybe later, when those outcomes are known and are being managed effectively, the known outcomes can drive capital calculations; i.e., put the horse back in front of the cart! The Bank of England/Prudential Regulatory Authority (PRA) has definitely rearranged the cart/horse order [8]:

“Operational risk management supports both operational resilience and financial resilience. Firms should have effective risk management systems in place to manage operational risks that are integrated into their organisational structures and decision-making processes. … When assessing a firm’s operational risk management, the PRA [first] considers the extent to which firms: have reduced the likelihood of operational incidents occurring; [second] can limit losses in the event of severe business disruption; and [after that]whether they hold sufficient capital to mitigate the impact when operational risks crystallise [emphasis added]. “

But what does mean on a day to day basis for ORM practitioners? Sorry, regulators are not going to go there, expect to reiterate that operational resilience as “an outcome that benefits from the effective management of operational risk”[11]. The ORM community has to work out its future for itself.

ORM is at a crossroads – but which way to go? As the old Irish saying goes – ‘we cannot get there from here’!

The default option is to do nothing and continue to do what is being done today? Some ORM professionals will indeed do that, but what of those operational risk experts who want to contribute to, and be part of, the operational resilience future.

Another option is to do the minimum needed to satisfy regulators in their own jurisdiction. For example, APRA, the Australian banking regulator does not describe what resilience entails merely than to ensure that an APRA-regulated entity is “resilient to operational risks and disruptions” [12]. Such an option is attractive but misses the opportunity to improve operational resilience to best practice, which today is DORA [5]. Some in the ORM community may choose to do that but this option is not available to ORM professional that operate in or in banks with offices in Europe.

Another option is to get on board with regulators’ long term agendas (because it is the right thing to do) and expand the visibility and utility of the ORM discipline. The point being that if ORM does not fill the gaps in practice that arise with operational resilience, others will do so anyway and probably not as well? Therefore, there must be a root and branch rethink of what the ORM function does and can do to advance the resilience agenda.

There is a lot to do, but one major area that MUST be addressed in operational resilience is IT/ICT Risk Management (ITRM). Not the first line of defence ITRM but the second line IT risk management which means first understanding exactly what information technology is being used by business lines and then ensuring that business line IT is being managed according to the policies and processes and risk appetites determined by the board. It should be noted that DORA[7] state that firms should “ensure appropriate segregation of ICT management functions, control functions, and internal audit functions, according to the three lines of defence model, or an internal risk management and control model”. However, DORA does not identify how such a 3-LOD model would apply!

What does ORM do?

In its latest revisions to principles for sound management of operational risk, the Basel Committee [13], describe the functions of a CORF (Corporate Operational Risk Function) is

“A functionally independent CORF is typically the second line of defence. The responsibilities of an effective second line of defence should include:

a) developing an independent view regarding business units’ (i) identified material operational risks, (ii) design and effectiveness of key controls, and (iii) risk tolerance;

b) challenging the relevance and consistency of the business unit’s implementation of the

operational risk management tools, measurement activities and reporting systems, and providing

evidence of this effective challenge;

c) developing and maintaining operational risk management and measurement policies, standards and guidelines;

d) reviewing and contributing to the monitoring and reporting of the operational risk profile; and

e) designing and providing operational risk training and instilling risk awareness. [emphasis added]”.

In short, ORM is NOT a risk management group per se, but is a group that operates at a senior level, looking across multiple business lines to ensure that there is a consistent  and accurate approach to identifying, measuring and controlling operational risks across those business lines and reporting those risks and their impacts to senior management and the Board.

The European DORA legislation [7] identifies a number of major areas that must be addressed to improve operational resilience (such as managing Outsourcing and specifically ‘Third Party Risks’) but importantly focuses on Information and Communications Technology (IT/ICT) risk for reasons that should be obvious as banking moves (even further) into a digital age.

While, in theory, IT/ICT risk has always been part of the ORM agenda of ‘people, processes, systems and external’ risks, technology risks have not rated highly on the regulatory agendas; as DORA[7] notes

“In addition, there has been only some limited or incomplete focus on ICT risks in the context of the operational risk coverage. Finally, these measures vary across the sectoral financial services legislation. Thus, the intervention at Union level did not fully match what European financial entities needed for managing operational risks in a way that withstand, respond and recover from impacts of ICT incidents. Nor did it provide financial supervisors with the most adequate tools to fulfil their mandates to prevent financial instability stemming from the materialization of those ICT risks. [emphasis added]”

Regardless of how we got here, we are here!

And so, it is essential that ORM functions become more deeply involved in understanding IT/ICT risks and equally important, existing first-line IT/ICT risk functions, where they exist, must become more involved in considering corporate, and industry, requirements and standards. Traditionally, IT/ICT risk has been a highly technical area focused on tackling narrow IT/ICT risks, such as cybersecurity breaches, on the front-line. However, that focus must change as the potential disruption caused by failing IT systems becomes obvious.

Much of current IT/ICT risk management has been involved with protecting technical infrastructure particularly defending firms from external attempts to break into computer systems to steal or destroy information. This is an important and essential role but other, equally critical IT/ICT risks have gone untended or at least only addressed on an ad-hoc basis. There are a number of examples, highlighted by DORA [7], including ‘legacy systems’ and ‘outsourcing to third parties’ such as Cloud providers. Both of these very real risks have the potential to cause significant damage to financial firms, and require not only deep knowledge of the relevant technology but also of the business environment in which the technology operates, i.e. the people, process, systems and external actors, such as software suppliers.

As just one example, DORA [7] requires that

“Financial entities other than microenterprises shall on a regular basis, and at least yearly, conduct a specific ICT risk assessment on all legacy ICT systems, especially before and after connecting old and new technologies, applications or systems. [emphasis added]”

On the face of it, this might appear to be a requirement that would be relatively easy to fulfill, but far from it! First, exactly what defines a ‘legacy’ system – 5/10/more years of operation? [It even requires some consistent definition of what a ‘system’ is?]. Second, what are the risks in a ‘legacy system’; there are many, including: lack of expert staff (people); impact on customers (processes); age of technology, support of software (systems); and regulatory/legislative changes to key systems (external ). Third, how does one measure the risks in changing systems, across multiple dimensions, including design, development, maintenance and operations, to mention a few? And, importantly, as most business lines will have one or more ‘core’ legacy systems as part of their technology ‘suite’, what standards are needed to identify, measure and manage risks consistently across the firm.

Given the breadth of risks covered (people, processes, systems and external, including legal) Operational Risk Management functions would seem to be ideally placed to provide second line risk management for IT/ICT risks such as ‘legacy systems’, and also other risks identified in the operational resilience agenda.

Operational Resilience – First and Second line IT/ICT Risk Management - Interactions

Figure 1 shows a two dimensional division of responsibilities for IT/ICT Risk Management (ITRM), relating to operational resilience, using the DORA model, as:

1)      Vertical – with each business line responsible for its ITRM through its first-line ITRM function with responsibilities for Risk Identification, Assessment, Control; Treatment; Monitoring and , importantly, Reporting[2];

2)      Horizontal – with one or more cross-business second-line function responsible for ensuring consistency and accuracy of Risk Identification, Assessment, Control; Treatment; Monitoring and , in particular, Reporting to the Board, senior management and regulators.

Figure 1 – First and Second Line IT/ICT Risk Management

Figure 1 shows a number of key types of IT/ICT related risks identified in DORA[7], including:

1)      IT/ICT Risk management – “Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework, which enables them to address ICT risk quickly, efficiently and comprehensively and to ensure a high level of digital operational resilience that matches their business needs, size and complexity.” This is a huge, complex undertaking!

2)      IT/ICT third-party risk – “As part of their ICT risk management framework, financial entities shall adopt and regularly review a strategy on ICT third-party risk, taking into account the multivendor strategy …. The management body shall regularly review the risks identified in respect of outsourcing of critical or important functions”. Again a huge and highly specialised undertaking!

3)      Legacy IT/ICT systems – “Financial entities other than microenterprises shall on a regular basis, and at least yearly, conduct a specific ICT risk assessment on all legacy ICT systems, especially before and after connecting old and new technologies, applications or systems.” Not only a huge undertaking but one that must be undertaken often and regularly!

4)      And others, listed in Figure 1,

Management of the other key risk types identified in DORA, and not expanded above, are all significant undertakings that require specialist expertise. For example, risk identification for cyber risk management is very different to, say, third party risk management and, in turn, those risks will vary from business line to business line depending on the size, scope and composition of business lines’ interactions with the external environment.

Before moving on, it should be noted that whether or not a particular risk, or set of risks, is identified by a national regulator, the risks exist, and the rationale for taking a risk seriously is whether a particular risk event would damage a particular financial firm NOT having been identified by regulator(s). In fact, regulators are notorious for being late to the party as regards risks that arise fairly rapidly, as for example new technology or new business practices (e.g. the Global Financial Crisis) . For example, the rapid uptake of Cloud computing, has brought into very sharp relief the importance of managing the resulting third-party risks.

It would appear then, that, because Operational Risk Management functions already perform similar functions today for a wide set of diverse risks, they should be ideally placed to provide these second line risk management for the types of IT/ICT risks that underlie operational resilience efforts.

Figure 1 also shows a box named Infrastructure, which describes key technologies that cut across business lines, such as data centres and shared communication facilities, such as call centres. The functions that manage these cross-business technologies tend to be highly technical and centralised, but not exclusively, for example, trading floor technologies tend to be operated by trading businesses. Centralised examples include management of data centres and cybersecurity which today tends to be managed by a function such as the chief information security office (CISO). Many but not all of these functions employ risk management techniques and standards that are specific to the technical problem at hand, such as for example the National Institute of Standards and Technology Cybersecurity Framework (NIST CSF) or the Factor Analysis of Information Risk (FAIR) framework.

The role of the second-level risk management function in such an organisational setup then is to ensure that processes and reporting follow enterprise standards, adapted and adjusted where necessary, consistently and accurately. This is a difficult undertaking requiring detailed understanding of the subject area. Furthermore, effective organisational interactions with these functions, as with business lines, require good diplomatic skills.

How to Join the Dots?

The Operational Risk Management(ORM) discipline is stuck in a backwater, with its primary organising body, the Institute of Operational Risk (IOR), being subsumed into the more general Institute of Risk Management (IRM). While IOR does provide a high-level introduction to Operational Resilience from the perspective of ‘service management’ [14] with respect to the narrow UK perspective of operational resilience, it does not look beyond that to a more complex, more intensive future. Furthermore, the IOR does not first recognise the sheer amount of work needed to understand the full operational resilience agenda nor, following from  that, the need for ORM functions to upgrade their knowledge, skills and staff to the required levels to be proactive in leading that agenda.

No one can impose any solution on a body as diverse and disparate as the ORM community that has somewhat lost its way and hence the future must be determined by leaders inside the community. That is, change must be driven by senior managers who are prepared to adapt to changing circumstances and are experienced enough to see what change will look like and then to proactively advocate for that change in forums that matter – internally at senior management meeting and externally at industry fora. It is not going to be easy but will, given the sheer size of the task, be exciting and useful!

What about Basel SMA?

A firm, of course, must give to Basel what is Basel’s (at least until they change their mind again)! This means expending as little effort as possible to estimating Operational Risk Regulatory Capital according to the SMA rules - i.e., running spreadsheets. However, even though the ORRC number is merely a tax on doing business, it does not mean that the capital set aside could not be allocated for the purposes of improving operational resilience. Note Operational Risk Capital (ORC) is not the same as ORRC, but is the capital that a firm determines is appropriate to cover losses to its pre-determined confidence level and may be greater or lesser than ORRC.

For example, whenever a defensible method of estimating legacy (especially core) systems risk is determined by a firm (i.e. not waiting for Basel to get around to it), the relative quantum of risk capital for a particular business/system combination could be allocated to the business/system involved, in order to improve operational resilience.

Conclusion

The Operational Risk Management function is at a crossroads; to continue towards irrelevance tied to an out-of-date vision of the Basel capital rules; or to pivot toward using their not inconsiderable skills and experience to help drive the global operational resilience agenda. A root and branch change of orientation is needed, but will the ORM discipline grab the opportunity? The truth is that if they don’t, someone else, probably not as adept, will grasp the enormous opportunity!

References

[1] Financial Services Forum. 2023. “Capital Insights: The Coming $1.4 Trillion Tax on Financial Services Provided by Large Banks - Financial Services Forum.” Fsforum.Com. Retrieved January 15, 2024 (https://fsforum.com/news/capital-insights-the-coming-1-4-trillion-tax-on-financial-services-provided-by-large-banks).

[2] Basel Committee on Banking Supervision. 2017. “Basel Framework OPE.” Bis.Org. Retrieved December 2, 2023 (https://www.bis.org/basel_framework/standard/OPE.htm).

[3] McConnell, Patrick. 2017. “Standardised Measurement Approach: Is Comparability Attainable? - Journal of Operational Risk.” Journal of Operational Risk 12(1):71–110. doi: 10.21314/JOP.2017.194.

[4] Butler, Tom, and Robert Brooks. 2023. “Time for a Paradigm Change: Problems with the Financial Industry’s Approach to Operational Risk.” Risk Analysis n/a(n/a). doi: 10.1111/risa.14240.

[5] Peters G.W., Shevchenko P.V., Hassani B. and Chapelle A.. 2016. “Should the advanced measurement approach be replaced with the standardised measurement approach for operational risk?” Journal of Operational Risk, 11 (3)

[6] Mignola G., Ugoccioni R. and Cope E. . 2016 . “Comments on the Basel Committee on Banking Supervision proposal for a new standardised approach for operational risks” Journal of Operational Risk, 11 (3)

[7] European Parliament. 2020. “Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on Digital Operational Resilience for the Financial Sector and Amending Regulations.” EUR-LEX. Retrieved January 8, 2024 (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52020PC0595).

[8] Bank of England. 2021a. “Operational Resilience.” Bankofengland.Co.Uk. Retrieved January 12, 2024 (https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/statement-of-policy/2021/operational-resilience-march-2021.pdf).

[9] Federal Reserve Board of Governors. 2020. “Interagency Paper on Sound Practices to Strengthen Operational Resilience.” Bostonfed.Org. Retrieved January 13, 2024 (https://www.federalreserve.gov/supervisionreg/srletters/SR2024.htm).

[10] Office of the Superintendent of Financial Institutions. 2023. “Operational Resilience and Operational Risk Management.” Osfi-Bsif.Gc.Ca. Retrieved January 11, 2024 (https://www.osfi-bsif.gc.ca:443/Eng/fi-if/rg-ro/gdn-ort/gl-ld/Pages/e21-dft.aspx).

[11] Basel Committee on Banking Supervision. 2021b. “Principles for Operational Resilience.” Bis.Org. Retrieved December 4, 2023 (https://www.bis.org/bcbs/publ/d516.htm).

[12] Australian Prudential Regulation Authority. 2025. “Prudential Standard CPS 230 Operational Risk Management.” Apra.Gov.Au. Retrieved (https://www.apra.gov.au/sites/default/files/2023-07/Prudential%20Standard%20CPS%20230%20Operational%20Risk%20Management%20-%20clean.pdf).

[13] Basel Committee on Banking Supervision. 2021. “Revisions to the Principles for the Sound Management of Operational Risk.” Bank for International Settlements. Retrieved November 20, 2023 (https://www.bis.org/bcbs/publ/d515.htm ).

[14] Institute of Operational Risk. 2024. “Operational Resilience.” IOR-Institute. Retrieved (https://www.ior-institute.org/sound-practice-guidance/operational-resilience/).

[1] According to its website “The Financial Services Forum is an economic policy and advocacy organization whose members are the chief executive officers of the eight largest and most diversified financial institutions headquartered in the United States.”

[2] Note DORA uses a slightly different classification, based on cybersecurity model: “identification, protection and prevention, detection, response and recovery, learning and evolving and communication”.