Banking's Operational Risk: When the Machinery Fails

Operational risk is the unglamorous but important side of banking. It is defined by the Basel framework as the risk of loss from inadequate or failed internal processes, people, systems, or external events. This includes legal risk but excludes strategic and reputational risk. The risk manifests when the machinery of banking malfunctions. This can happen through payment errors, system failures, employee mistakes, or cyberattacks.

Governance is the starting point for managing this risk. A bank's board must establish its risk appetite. This defines how much operational risk it is willing to accept. Responsibility cannot be siloed in an operational risk department. Instead, the industry-standard Three Lines of Defense model applies.

The first line of defense is the business itself. Staff in branches, payment processing, and loan approvals encounter risk daily. The second line includes functions like operational risk and compliance. They provide oversight and challenge management. The third line is internal audit. It offers independent assurance. The principle is clear: those who create and manage a risk should not be the sole judges of its control.

Identifying Operational Risks

With governance set, banks must identify what can go wrong. A key tool is the Risk and Control Self-Assessment (RCSA). Here, business units examine their processes to pinpoint risks and evaluate control adequacy. The second line's role is to challenge these self-assessments. Another tool is the Key Risk Indicator (KRI). This is an early-warning signal measuring metrics like system downtime or staff turnover. Effective KRIs provide useful warnings before losses occur.

Banks also rely on operational loss data. They record historical failures, frauds, and system outages. This internal data is supplemented by external loss databases from other institutions. This helps reveal patterns. Honest recording of mistakes turns experience into valuable data.

Planning for Severe Scenarios

Historical data has a weakness. It shows what happened, not what could happen next. Scenario analysis and stress testing address this by imagining severe, plausible events. Banks might test resilience against a 24-hour core system failure. They could test a major simultaneous cyberattack, or the loss of a key supplier. These are imaginative exercises. Their purpose is to test the bank's capacity to withstand disruption.

Implementing and Maintaining Controls

Once identified, risks require controls. These can be preventative, like segregation of duties, or detective. A classic control ensures the person initiating a transaction does not also approve it. Principles like dual authorisation and multi-factor authentication remain vital. Technology changes their implementation. Technology itself introduces new risks. This happens particularly through dependence on third-party providers, cloud platforms, and telecom networks. Outsourcing a process does not outsource the bank's ultimate responsibility for its failure.

Building Operational Resilience

Business continuity and operational resilience are the next steps. Traditional disaster recovery focuses on restoring systems after a failure. Operational resilience goes further. It asks if a bank can maintain critical services during the disruption. The distinction is important. Perfectly restored systems are little comfort to customers locked out of their accounts for days. Resilience planning involves disaster recovery, crisis management, backup facilities, and mapping dependencies between systems and suppliers.

Insurance can transfer the financial consequences of catastrophic events like cyber incidents. However, it is not a control substitute. Insurance may cover costs. It cannot restore a damaged reputation or retrieve lost data.

Despite all controls, failures will occur. The goal of operational risk management is not to eliminate all failure. It is to limit its frequency and impact and to learn from it. Root Cause Analysis is essential after a significant incident. It looks beyond the immediate error to underlying process flaws. Corrective Action Plans must then address these root causes, not only the symptoms. This prevents recurrence.