Operational Risk, Controls and Resilience

Introduction and Context

Investment banking operations connect clients, markets, counterparties, custodians, payment systems, regulators and internal ledgers. A trade may be economically profitable yet operationally damaging if it is booked incorrectly, settled late, reported inaccurately, or exposed through a cyberattack. Operational risk is therefore not merely an administrative concern; it is a strategic determinant of client trust, regulatory standing, capital efficiency and franchise value.

The Basel Committee defines operational risk as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events. The definition includes legal risk but generally excludes strategic and reputational risk, although operational failures frequently create both. In investment banking, examples include erroneous trade capture, unauthorised payments, model-interface failures, sanctions-screening gaps, technology outages, fraud, data corruption and failures by outsourced service providers.

Operational resilience extends the control perspective. It asks whether an institution can continue delivering important business services within acceptable levels despite disruption. A mature operating model therefore combines risk identification, preventive and detective controls, monitoring, incident response, business continuity, cyber resilience and third-party oversight.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain operational risk and distinguish it from market, credit, liquidity and strategic risk.
2. Conduct a risk and control self-assessment (RCSA) and map a process from initiation to reconciliation.
3. Design key risk indicators (KRIs), maker–checker controls and segregation-of-duties arrangements.
4. Apply loss-event analysis and root-cause techniques.
5. Explain the three-lines governance model and evaluate control effectiveness.
6. Design business-continuity, cyber-resilience and third-party-risk responses.
7. Critically assess the limitations of controls and recommend proportionate improvements.

1. The Nature and Structure of Operational Risk

Operational risk arises when the operating system of the bank does not perform as intended. Its sources can be classified into four broad categories:

Operational risk differs from other principal risks. Market risk concerns adverse price movements; credit risk concerns counterparty failure; liquidity risk concerns the inability to meet obligations; operational risk concerns failure of the operating process itself. These categories interact. For example, a settlement-system outage is operational risk initially, but it may produce liquidity and counterparty exposures.

A useful analytical distinction is between inherent risk and residual risk. Inherent risk is the exposure before considering controls. Residual risk is the exposure remaining after controls operate. Controls do not normally eliminate risk; they reduce its likelihood, impact, or detectability.

Risk can be described qualitatively as a combination of likelihood and impact. A quantitative expected-loss representation is sometimes useful:

Here, EL is expected loss over a defined period, p_i is the probability of event type i, and L_i is the financial loss if that event occurs. The formula assumes that event probabilities and loss estimates are sufficiently defined and that the calculation is intended as an average expectation, not a prediction of the next actual loss. It does not capture uncertainty, extreme losses, correlation or non-financial consequences adequately.

For a simple frequency–severity model, if events occur with an average frequency λ per year and average severity μ per event, then:

The units are currency per year because λ is events per year and μ is currency per event. This approximation is useful for screening but can be misleading when losses are highly skewed or event types are heterogeneous.

2. Process Mapping and Control Design

A control cannot be evaluated without understanding the process it is intended to protect. Process mapping makes activities, hand-offs, systems, decisions and evidence visible. A typical investment-banking trade lifecycle is:

1. Client order or mandate received.
2. Pre-trade checks performed.
3. Order executed.
4. Trade captured in the front-office system.
5. Confirmation issued and matched.
6. Trade affirmed and instructed for settlement.
7. Cash and securities settled.
8. Positions and cash reconciled.
9. Accounting, risk and regulatory reports generated.
10. Exceptions investigated and closed.

A process map should identify the process owner, inputs, outputs, applications, data dependencies, manual interventions, control points, exception routes and service-level requirements. It should also distinguish the happy path from exceptions. Operational losses often occur in exceptions that are handled informally rather than through controlled workflows.

Controls are commonly classified as follows:

• Preventive controls: stop an error or unauthorised act before it occurs, such as system limits or approval thresholds.
• Detective controls: identify an event after occurrence, such as reconciliations or exception reports.
• Corrective controls: restore the process, correct the record or remediate the root cause.
• Manual controls: depend on human performance and evidence.
• Automated controls: are executed by configured technology and require appropriate change management.
• Key controls: controls whose failure could materially increase risk or prevent reliable reporting.

Control design should answer five questions: What risk is addressed? Who performs the control? When and how often? What evidence is retained? What happens when an exception is found? A control described only as “operations reviews trades” is insufficiently precise. A stronger specification might require an independent daily comparison of executed trades to the order-management system, documented investigation of all breaks, and escalation of unresolved items within a defined time.

3. Risk and Control Self-Assessments

An RCSA is a structured assessment through which business and control owners identify risks, evaluate controls, assess residual exposure and agree treatment plans. It is not simply a questionnaire. Its quality depends on evidence, challenge and clear accountability.

A practical RCSA sequence is:

1. Define scope, process boundaries and assessment period.
2. Identify objectives and important business services.
3. Identify risk scenarios, including conduct, technology, data and third-party risks.
4. Assess inherent likelihood and impact.
5. Inventory existing controls and assess design adequacy.
6. Evaluate operating effectiveness using incidents, testing and control evidence.
7. Determine residual risk.
8. Compare residual risk with appetite or tolerance.
9. Assign actions, owners, target dates and escalation routes.
10. Obtain independent challenge and management approval.

Many institutions use a scoring matrix. For example, a five-point likelihood score and a five-point impact score may produce a gross risk score:

where L is the likelihood rating from 1 to 5 and I is the impact rating from 1 to 5. The score is ordinal rather than a precise probability or monetary value. Therefore, a score of 12 should not automatically be interpreted as twice the risk of a score of 6. The matrix is a prioritisation device, not a statistical law.

A residual score should not be reduced mechanically merely because a control exists. The assessor must consider whether the control is appropriately designed, consistently performed, evidenced, independently reviewed and capable of detecting the relevant failure. A formally documented control that is frequently overridden may provide little practical protection.

4. Key Risk Indicators and Loss-Event Analysis

KRIs are metrics that provide an early indication of increasing exposure or weakening control performance. Examples include:

• Number and value of aged reconciliation breaks.
• Percentage of confirmations unmatched beyond the service-level agreement.
• Privileged-access exceptions.
• Failed or delayed settlements.
• Volume of manual journal entries.
• System availability and batch-processing failures.
• Phishing reports and endpoint-control exceptions.
• Critical vendors exceeding recovery-time commitments.
• Staff turnover in control-sensitive roles.

A useful KRI has a clear owner, defined data source, reporting frequency, threshold logic and escalation action. Thresholds should distinguish normal variation from meaningful deterioration. A threshold without a prescribed response becomes descriptive rather than preventative.

Loss-event analysis examines actual incidents and near misses. A sound analysis records the date, process, event type, gross loss, recoveries, affected parties, control failures, root causes and remediation. Gross loss is the loss before recoveries; net loss is gross loss less valid recoveries. Non-financial impacts—client disruption, regulatory attention, data compromise and reputational damage—should be recorded even when no accounting loss occurs.

Root-cause analysis should move beyond the immediate error. Techniques include the “five whys,” fault-tree analysis and causal-factor mapping. For example, a late settlement may initially appear to be a clerical mistake. Further analysis may reveal an unclear ownership model, an interface change, an untested static-data update and an escalation threshold that was too high. Effective remediation addresses the system of causes rather than disciplining the last person who touched the transaction.

5. Maker–Checker Controls and Segregation of Duties

A maker–checker control requires one person or system to initiate an action and another suitably independent person or system to verify and approve it. It is particularly important for payments, settlement instructions, static-data changes, manual journals, limit overrides and access provisioning.

A strong maker–checker arrangement requires:

• Distinct identities and authenticated access.
• A checker with appropriate competence and authority.
• Review of the underlying evidence, not merely a click-through approval.
• Prevention of self-approval.
• Immutable or sufficiently reliable audit trails.
• Clear treatment of emergencies and subsequent review.

Segregation of duties (SoD) prevents incompatible responsibilities from being combined. For example, the person who creates a beneficiary should not independently approve a payment to that beneficiary. Common incompatible combinations include trade execution and confirmation, cash-payment creation and approval, user-access administration and access review, and accounting-record preparation and final approval.

SoD is not absolute. Small teams, emergencies and specialist functions may create conflicts. Compensating controls—such as enhanced surveillance, independent daily review, restricted limits and retrospective audit—may reduce but do not erase the residual risk. Privileged access should be time-bound, logged and subject to independent review.

6. The Three Lines of Governance

The three-lines model clarifies accountability rather than creating three separate risk departments.

First line—management and operations: owns risks, designs and operates controls, manages issues and delivers services. Front-office and operations managers remain accountable for the risks generated by their activities.

Second line—risk, compliance and specialist oversight: establishes frameworks, advises, monitors, challenges and reports. It should have sufficient independence to challenge the first line while remaining close enough to understand the business.

Third line—internal audit: provides independent, objective assurance on governance, risk management and controls. Internal audit should not design or operate controls that it later assesses.

The board and senior management provide direction, approve risk appetite and ensure adequate resources. External auditors and regulators are outside the three internal lines but may provide additional assurance or supervisory challenge.

A common governance failure is “responsibility diffusion,” in which each line assumes another party owns the issue. Effective governance uses a clear risk taxonomy, named process owners, documented committee mandates, issue-aging rules and escalation protocols.

7. Operational Resilience and Business Continuity

Business continuity traditionally focuses on restoring processes after disruption. Operational resilience goes further by identifying important business services, setting impact tolerances and testing whether those services can continue through severe but plausible scenarios.

An important business service is a service whose disruption could cause intolerable harm to clients, markets, the institution or the financial system. Examples include executing and settling client trades, processing margin calls, making critical payments and maintaining custody records.

A business-impact analysis should consider:

• Maximum tolerable disruption.
• Maximum tolerable data loss.
• Critical people, facilities, applications and suppliers.
• Dependencies and substitute arrangements.
• Legal, regulatory and client obligations.
• Communications and decision rights.

Two technical measures are frequently used:

The recovery time objective (RTO) is the maximum targeted time to restore a service after disruption. The recovery point objective (RPO) is the maximum acceptable period of data that may be lost, measured between the disruption and the latest recoverable data point. Both are time measures. A lower RTO or RPO generally requires greater investment and architectural complexity.

Continuity arrangements may include geographically separated sites, resilient communications, backup power, replicated data, manual workarounds, alternate staff, reciprocal arrangements and prioritised service queues. Plans must be exercised. A plan that has not been tested under realistic conditions is an assumption, not evidence of resilience.

Scenario testing should include technology failure, cyber extortion, loss of premises, key-person dependency, market-infrastructure outage, cloud-provider failure, corrupted data and simultaneous disruptions. Tests should assess not only recovery speed but also decision-making, data integrity, communications, customer treatment and regulatory notification.

8. Cyber Resilience and Data Integrity

Cyber resilience combines prevention, detection, response, recovery and learning. Controls should be layered because no single control is reliable against all threats. Important practices include strong identity management, multi-factor authentication, least privilege, network segmentation, secure configuration, vulnerability management, endpoint protection, logging, threat monitoring, tested backups and rehearsed incident response.

Investment banks face particular risks from payment fraud, credential theft, ransomware, supply-chain compromise, market-data manipulation and attacks on externally accessible interfaces. Data integrity is as important as availability. A system that is operating but produces corrupted positions or settlement instructions may be more dangerous than a visible outage.

An incident-response plan should define severity levels, technical containment, legal and regulatory consultation, client communications, evidence preservation, recovery authority and post-incident review. Artificial intelligence can assist with anomaly detection, alert triage and control testing, but it introduces model, data-quality, explainability, privacy and adversarial risks. AI-generated alerts or recommendations should not bypass human accountability for high-impact decisions.

9. Third-Party and Cloud Risk

Outsourcing a process does not outsource accountability. Third-party risk management should cover the full lifecycle:

1. Criticality and concentration assessment.
2. Due diligence on financial strength, security, resilience, compliance and subcontractors.
3. Contractual requirements for service levels, audit rights, data location, incident notification, confidentiality and exit assistance.
4. Ongoing monitoring and independent assurance.
5. Scenario testing and contingency planning.
6. Termination, transition and secure data deletion.

A critical provider may support multiple institutions, creating concentration risk. A vendor’s contractual recovery time may also be incompatible with the bank’s impact tolerance. Contracts therefore need to be tested against actual service requirements rather than accepted as evidence of resilience.

Third-party oversight should evaluate fourth parties, privileged access, software updates, data portability and the ability to operate during a provider dispute. Cloud environments require shared-responsibility clarity: the provider may operate the infrastructure, while the bank remains responsible for configuration, identity, data governance and business use.

10. Applied Case: Meridian Capital Markets

The following is an illustrative case.

Background

Meridian Capital Markets, a fictional investment bank, experienced three settlement failures in one quarter. The incidents affected different clients but involved the same custody platform. Operations staff also reported increasing manual overrides and delayed reconciliations.

Problem

The RCSA rated settlement risk “medium” because a maker–checker control existed for instruction release. However, the control did not prevent the maker from also performing an emergency override. The process map omitted a static-data enrichment interface operated by a vendor. KRI reporting focused on the monthly number of failed settlements and did not monitor aged breaks, override frequency or vendor-interface errors.

Analysis

Loss-event analysis identified the following causal chain:

• A vendor interface intermittently truncated an account identifier.
• The exception queue did not distinguish high-value transactions.
• An operator corrected the record manually under time pressure.
• The same operator used an emergency release path.
• Daily reconciliation detected the issue only after settlement cut-off.
• The vendor contract required notification but did not provide tested recovery evidence.

The immediate cause was an incorrect account identifier. The deeper causes were incomplete process mapping, weak exception design, insufficient SoD in emergency procedures, and inadequate third-party monitoring.

Approach and Solution

Meridian implemented a risk treatment plan:

1. High-value and high-risk static-data changes required independent approval.
2. Emergency releases were restricted to named senior staff and reviewed next business day.
3. The interface performed validation checks and rejected truncated identifiers.
4. KRIs included aged breaks, manual overrides, failed interface messages and settlements approaching cut-off.
5. A service-level agreement was linked to the bank’s impact tolerance and tested quarterly.
6. The RCSA was revised to distinguish control design from operating effectiveness.
7. A scenario exercise simulated vendor outage during a high-volume settlement day.

Outcome

After implementation, the number of late settlements declined and management received earlier warning of interface deterioration. The exercise also revealed that the bank’s backup process could preserve transaction records but could not generate valid settlement instructions without the vendor’s reference data. This led to a further investment in portable reference data and an alternate processing arrangement.

Learning Points

The case demonstrates that a control may exist on paper yet fail in practice. It also shows why process maps must include interfaces and exceptions, why KRIs should be predictive, and why third-party resilience must be assessed against the bank’s own service obligations.

11. Challenges, Limitations and Professional Judgement

Operational-risk measurement is difficult because data is incomplete, rare events are consequential, and control effectiveness is partly behavioural. Historical losses may understate future cyber or technology risk. A high number of reported incidents may indicate either poor performance or a healthier reporting culture. Conversely, zero incidents may reflect under-reporting.

Control proliferation is another danger. Excessive approvals can slow decisions, encourage workarounds and obscure accountability. Controls should be risk-based, proportionate and designed around the actual failure mode. Automation can reduce manual error but may also scale a configuration error rapidly. Independent validation, change control and exception monitoring remain necessary.

Ethically, operations staff must protect client assets, confidentiality and fair treatment. Incident concealment, manipulation of evidence, unauthorised override and retaliation against whistle-blowers are governance failures. Senior managers should reward timely escalation rather than merely low reported loss numbers.

Regulatory expectations vary by jurisdiction, but common themes include board accountability, sound internal controls, operational resilience, cyber security, outsourcing oversight, record retention, incident reporting and recovery testing. Institutions must consult applicable local rules rather than treating any single framework as universally sufficient.

12. Best-Practice Operating Model

A mature operational-risk programme generally exhibits the following characteristics:

• Clearly defined important business services and process ownership.
• Integrated process maps, risk registers, control inventories and issue logs.
• Evidence-based RCSAs with independent challenge.
• KRIs linked to action thresholds and escalation.
• Strong identity, maker–checker and SoD controls.
• Reconciliations that are timely, risk-based and independently reviewed.
• Incident and near-miss reporting without blame-driven suppression.
• Root-cause remediation tracked to closure and tested for effectiveness.
• Business-continuity plans tested through severe but plausible scenarios.
• Cyber controls addressing confidentiality, integrity and availability.
• Third-party due diligence, concentration analysis and exit planning.
• Board reporting that explains trends, vulnerabilities, tolerance breaches and decisions required.

The strategic objective is not zero operational incidents, which is unrealistic. It is an operating environment in which important risks are understood, controls are proportionate, failures are detected quickly, services remain within tolerance, and the institution learns faster than its risk environment changes.

Chapter Summary

Operational risk results from failures of people, processes, systems or external events and can amplify market, credit, liquidity and reputational exposures. Effective management begins with process mapping and proceeds through RCSAs, control design, KRIs, incident analysis and clear ownership. Preventive, detective and corrective controls should be supported by maker–checker arrangements and segregation of duties.

The three-lines model assigns operational ownership to management, oversight and challenge to the second line, and independent assurance to internal audit. Operational resilience requires identification of important business services, impact tolerances, tested recovery capabilities and attention to data integrity. Cyber resilience and third-party-risk management are integral rather than separate disciplines. Good practice combines proportionate controls, evidence-based testing, transparent escalation and continuous learning.

Key Terms

Operational risk: Risk of loss from inadequate or failed processes, people, systems or external events.

Inherent risk: Exposure before considering controls.

Residual risk: Exposure remaining after controls operate.

Risk and control self-assessment (RCSA): Structured evaluation of risks, controls and residual exposure by accountable management.

Key risk indicator (KRI): Metric that signals changing risk exposure or control weakness.

Loss event: An incident producing financial or significant non-financial impact.

Near miss: An event that could have caused loss but did not.

Preventive control: Control intended to stop an unwanted event before occurrence.

Detective control: Control intended to identify an event after occurrence.

Corrective control: Control that restores, repairs or remediates after failure.

Maker–checker: Arrangement requiring independent initiation and verification or approval.

Segregation of duties: Separation of incompatible responsibilities.

Three-lines model: Governance model distinguishing management, oversight and independent assurance.

Operational resilience: Ability to continue important business services through disruption.

Impact tolerance: Maximum acceptable level of disruption or harm to an important service.

RTO: Target time to restore a service after disruption.

RPO: Maximum acceptable period of data loss.

Third-party risk: Risk arising from reliance on external providers or their subcontractors.

Root-cause analysis: Investigation of underlying causal factors rather than only immediate errors.

Review Questions

Short Answer Questions

1. Define operational risk and give two investment-banking examples.
2. Distinguish inherent risk from residual risk.
3. What is the purpose of a KRI?
4. Explain the maker–checker principle.
5. What do RTO and RPO measure?

Long Answer Questions

1. Explain the stages of an RCSA and discuss why operating effectiveness must be distinguished from control design.
2. Describe how process mapping supports operational-risk management across the trade lifecycle.
3. Analyse the three-lines model and explain the accountability of each line.
4. Discuss how business continuity and operational resilience differ.
5. Explain the principal elements of a third-party-risk management lifecycle.

Analytical / Application Questions

1. A bank reports rising manual overrides, aged reconciliation breaks and late settlements. Design three KRIs, specify threshold responses and explain how you would investigate the underlying causes.
2. A payment operator can create beneficiaries, initiate payments and approve emergency releases. Identify the SoD weaknesses and propose compensating controls for a small operations team.
3. A critical cloud provider suffers a regional outage during a major settlement cycle. Design a response covering service prioritisation, communications, data recovery, regulatory escalation and post-incident learning.

Multiple Choice Questions with Answers

Question 1

Which statement best describes operational risk?

A. Risk of loss from adverse interest-rate movements

B. Risk of loss from inadequate or failed processes, people, systems or external events

C. Risk that a borrower will default

D. Risk that the bank cannot raise long-term equity

Correct Answer: B. Risk of loss from inadequate or failed processes, people, systems or external events

Question 2

Which is a preventive control?

A. A post-settlement reconciliation

B. An incident report prepared after an outage

C. A system limit that blocks unauthorised payment amounts

D. A review of last quarter’s losses

Correct Answer: C. A system limit that blocks unauthorised payment amounts

Question 3

What is the primary purpose of an RCSA?

A. To replace internal audit

B. To identify risks, evaluate controls and determine residual exposure

C. To calculate market prices

D. To approve every client trade

Correct Answer: B. To identify risks, evaluate controls and determine residual exposure

Question 4

Which KRI is most directly associated with settlement-control deterioration?

A. Number of office parking spaces

B. Aged reconciliation breaks

C. Annual marketing expenditure

D. Number of holidays taken by staff

Correct Answer: B. Aged reconciliation breaks

Question 5

Which arrangement best demonstrates segregation of duties?

A. One employee creates and approves a beneficiary

B. The trader confirms the trade alone

C. One employee creates a payment and another independently approves it

D. The system administrator reviews their own access

Correct Answer: C. One employee creates a payment and another independently approves it

Question 6

In the three-lines model, which function provides independent assurance?

A. Business operations

B. The second-line risk function

C. Internal audit

D. The external vendor

Correct Answer: C. Internal audit

Question 7

If events occur at an average frequency of 4 per year and average severity is $25,000 per event, the simple expected annual loss is:

A. $6,250

B. $25,000

C. $100,000

D. $1,000,000

Correct Answer: C. $100,000

Question 8

What does an RPO measure?

A. The time required to approve a payment

B. The maximum acceptable period of data loss

C. The number of recovery staff available

D. The total annual cost of controls

Correct Answer: B. The maximum acceptable period of data loss

Question 9

Which statement about outsourcing is correct?

A. Outsourcing transfers accountability to the vendor

B. Only the vendor’s financial strength matters

C. The bank remains accountable and must manage lifecycle and concentration risks

D. A contract eliminates third-party risk

Correct Answer: C. The bank remains accountable and must manage lifecycle and concentration risks

Question 10

Why is root-cause analysis important after an operational loss?

A. It identifies only the last person involved

B. It prevents all future incidents with certainty

C. It addresses underlying systemic causes rather than only the immediate error

D. It removes the need for control testing

Correct Answer: C. It addresses underlying systemic causes rather than only the immediate error