Operational-Risk Monitoring, Control, Reporting and Mitigation - Article

Introduction

Operational-risk management does not end after risks are identified through tools such as RCSA, loss-event analysis and Key Risk Indicators.

A bank must continuously determine:

• whether its operational-risk profile is changing;

• whether controls are working;

• whether risk appetite or tolerance is being breached;

• whether incidents require escalation;

• whether corrective actions are completed; and

• whether some risks should be reduced, transferred or accepted.

The current Basel operational-risk framework describes this process through two important principles:

• Principle 8 — Monitoring and Reporting

• Principle 9 — Control and Mitigation

Basel requires banks to regularly monitor operational-risk profiles and material exposures and maintain reporting at business-unit, senior-management and Board levels. It also requires a strong control environment supported by internal controls and appropriate risk-mitigation or risk-transfer strategies.

RBI's Guidance Note on Operational Risk Management and Operational Resilience, issued on April 30, 2024, aligns Indian regulatory guidance with Basel principles and emphasises preparation, protection, resilience and learning from disruption.

For syllabus accuracy, the official 2026 CAIIB BFM syllabus places Operational Risk under Module D, although the supplied Quiz Academy course mapping identifies this article under Module B.

For case-study questions, remember the basic cycle:

Monitor → Detect → Report → Escalate → Control/Mitigate → Verify

Learning Objectives

After studying this topic, you should be able to:

• explain operational-risk monitoring;

• identify important monitoring information and warning signals;

• understand operational-risk reporting and escalation;

• distinguish preventive, detective and corrective controls;

• explain segregation of duties and maker-checker controls;

• understand risk avoidance, reduction, transfer and acceptance;

• identify limitations of insurance and outsourcing as mitigation tools;

• understand the relationship between operational risk and resilience; and

• solve operational-risk control cases logically.

Operational-Risk Monitoring

Operational-risk monitoring means regularly observing the bank's risk profile to determine whether:

• risks are increasing;

• controls are weakening;

• thresholds are being approached;

• actual losses are rising;

• new risks are emerging; or

• previously identified corrective actions remain incomplete.

Basel states that senior management should implement processes for regularly monitoring operational-risk profiles and material exposures.

Monitoring can use information from:

• KRIs;

• RCSA;

• internal loss data;

• near misses;

• fraud incidents;

• customer complaints;

• audit findings;

• system downtime;

• failed transactions;

• reconciliation exceptions;

• control breaches;

• outsourcing incidents;

• cyber events; and

• regulatory changes.

What Should Be Monitored?

Risk Appetite and Tolerance

The bank should compare actual operational-risk exposure with its approved:

• risk appetite;

• risk tolerance;

• thresholds;

• limits; and

• qualitative requirements.

A breach should not merely appear in a report. It should trigger the appropriate escalation and response.

Key and Emerging Risks

Some risks may become material even before significant internal losses occur.

Examples include:

• rapid increase in digital fraud attempts;

• dependence on one critical technology vendor;

• rising staff attrition;

• ageing unresolved reconciliation entries;

• increasing system capacity utilisation; or

• new cyberattack techniques.

Basel specifically expects operational-risk reporting to include discussion and assessment of key and emerging risks.

Operational Loss Events

Management should monitor:

• number of events;

• gross loss;

• recoveries;

• net loss;

• recurring events;

• business areas affected; and

• root causes.

A small event occurring hundreds of times may require as much attention as a single large incident.

Control Deficiencies

Examples include:

• maker-checker not operating;

• unresolved access rights;

• delayed reconciliations;

• missing documents;

• untested backup systems; and

• overdue audit observations.

Corrective Actions

A control weakness remains a risk until corrective action is actually completed and verified.

Monitoring should therefore track:

Issue → Owner → Action → Due Date → Status → Closure Verification

Operational-Risk Reporting

Monitoring produces risk information.

Reporting ensures that the information reaches someone who can take action.

Basel requires reports to be:

• comprehensive;

• accurate;

• consistent;

• actionable;

• timely; and

• manageable in volume.

Too little information may hide an important risk. Too much information can make decision-making difficult.

What Should Operational-Risk Reports Include?

Basel specifically identifies:

• breaches of risk appetite, tolerance, thresholds or limits;

• key and emerging risks;

• significant internal operational-risk events and losses;

• root-cause analysis;

• relevant external events; and

• regulatory changes affecting the bank.

Useful internal reports may also include:

Reporting Frequency and Escalation

Not every operational-risk item requires the same reporting frequency.

A minor routine event may enter periodic MIS.

A material event may require immediate escalation.

The frequency should depend on:

• severity;

• speed of risk change;

• potential customer impact;

• financial impact;

• regulatory significance;

• threat to critical operations; and

• risk-appetite breach.

Basel requires reporting frequency to reflect the nature and pace of changes in the operating environment and expects banks to be capable of reporting during both normal and stressed conditions.

Operational-Risk Controls

A control is an action, process or mechanism designed to reduce the likelihood or impact of an operational-risk event.

Controls can broadly be classified as:

Preventive Controls

Designed to stop an event before it occurs.

Examples:

• access restrictions;

• transaction limits;

• segregation of duties;

• maker-checker;

• system validation;

• pre-disbursement checks.

Detective Controls

Designed to identify a problem after it has occurred or while it is developing.

Examples:

• reconciliation;

• exception reports;

• fraud-monitoring alerts;

• audit trails;

• supervisory review.

Corrective Controls

Designed to restore operations or correct the effect of a problem.

Examples:

• reversing an incorrect transaction;

• restoring data from backup;

• activating disaster recovery;

• rectifying defective access rights.

A good control environment often requires a combination of all three.

Segregation of Duties

Segregation of duties prevents one person from controlling incompatible stages of a transaction.

For example, the same employee should not ordinarily be able to:

Create transaction → Authorise transaction → Settle transaction → Reconcile transaction

without appropriate independent controls.

Basel identifies segregation of duties as an important internal-control principle because conflicting responsibilities can permit errors or inappropriate actions to remain hidden.

Maker-Checker Principle

Under maker-checker:

• one person initiates or prepares a transaction; and

• another independently verifies or authorises it.

However, maker-checker becomes ineffective if:

• passwords are shared;

• checking is mechanical;

• one person controls both credentials; or

• exceptions can bypass the control without supervision.

The existence of the control does not prove its effectiveness.

Control Exceptions and Overrides

Operational processes sometimes permit authorised exceptions.

Examples include:

• temporary limit override;

• emergency manual processing;

• exceptional approval; or

• temporary change in procedure.

Exceptions should be:

• properly authorised;

• documented;

• time-bound where relevant;

• monitored; and

• reported when material.

Basel specifically expects banks to track approved exceptions, management overrides and other deviations from policies, limits and regulatory requirements.

Repeated exceptions can indicate that:

• the process is poorly designed;

• limits are inappropriate;

• business behaviour is bypassing controls; or

• risk appetite is being exceeded informally.

Operational-Risk Mitigation Strategies

Operational risk can be addressed through several approaches.

1. Avoid the Risk

The bank may decide not to undertake an activity where risk is unacceptable.

Example:

A proposed product cannot meet essential legal or cybersecurity requirements, so launch is deferred.

Risk avoidance removes the particular activity but may also sacrifice business opportunity.

2. Reduce the Risk

The bank strengthens controls to reduce likelihood or severity.

Examples include:

• automation;

• maker-checker;

• stronger authentication;

• reconciliation;

• staff training;

• additional system capacity;

• access controls; and

• process redesign.

3. Transfer or Share the Risk

Part of the financial impact may be transferred using:

• insurance; or

• contractual arrangements with third parties.

However, the underlying operational responsibility may not disappear.

4. Accept the Risk

Some residual risk may be accepted when:

• it is within risk appetite;

• mitigation cost is disproportionate;

• controls are considered adequate; and

• appropriate authority approves acceptance.

Risk acceptance should be a conscious decision, not the result of ignoring the issue.

Insurance as Risk Mitigation

Insurance can reduce the financial impact of specified operational events.

Possible areas may include:

• property damage;

• fraud;

• cyber incidents;

• professional liability; or

• other insured events.

However, insurance does not necessarily:

• prevent the incident;

• restore customer confidence;

• eliminate regulatory consequences;

• cover the full loss; or

• provide immediate recovery.

There may be:

• exclusions;

• deductibles;

• coverage limits;

• delays in claim settlement; and

• insurer counterparty considerations.

Therefore:

Insurance transfers part of financial loss; it does not transfer responsibility for sound operational-risk management.

Outsourcing and Third-Party Risk

A bank may outsource an activity, but this does not mean it has outsourced the associated accountability.

Third-party arrangements may introduce:

• service disruption;

• cyber risk;

• data leakage;

• concentration;

• vendor financial failure;

• subcontractor risk;

• compliance risk; and

• exit difficulties.

Current Basel consolidated guidance treats third-party risk as an important component of operational risk and resilience.

A bank therefore needs controls such as:

• due diligence;

• contractual requirements;

• service-level monitoring;

• information-security controls;

• contingency arrangements;

• concentration assessment; and

• exit planning.

Business Continuity and Operational Resilience

Some events cannot be prevented.

A bank therefore needs the ability to continue or restore critical operations when disruption occurs.

Basel requires forward-looking Business Continuity Plans linked to the Operational Risk Management Framework, supported by scenario analysis, impact assessment and recovery procedures.

Operational resilience takes this further by asking:

Can the bank continue delivering critical operations through disruption and recover within acceptable limits?

Basel's current supervisory principles require banks to identify threats, protect against failures, respond, recover and learn from disruptive events.

Controls vs Resilience

Controls try to prevent or reduce failure.

Resilience prepares the bank to continue operating when failure nevertheless occurs.

Both are necessary.

Case Study 1: Rising Reconciliation Exceptions

A payment-processing unit has the following KRI trend:

• Month 1: 20 old unreconciled entries

• Month 2: 45

• Month 3: 90

No major financial loss has yet occurred.

Management proposes waiting until a loss occurs before allocating additional staff.

Analysis

The increasing number of unresolved entries is an operational-risk warning.

The bank should:

• investigate root causes;

• assess staffing and process capacity;

• clear aged entries;

• review reconciliation controls;

• determine whether KRI thresholds have been breached; and

• escalate where required.

CAIIB Lesson

Operational-risk monitoring is intended to identify increasing risk before actual loss occurs.

Case Study 2: Maker-Checker Exists but Fraud Occurs

A branch payment system requires maker-checker authorisation.

An employee discovers that a colleague's password is written near the workstation and uses both credentials to process an unauthorised transaction.

Management argues that the fraud could not have been prevented because maker-checker control existed.

Analysis

The control existed in design but failed operationally.

The bank should examine:

• credential sharing;

• access management;

• user-awareness controls;

• authentication design;

• transaction monitoring; and

• supervisory failures.

Corrective action may require:

• stronger authentication;

• disciplinary measures;

• revised access controls; and

• monitoring for similar weaknesses elsewhere.

CAIIB Lesson

A control that can be easily bypassed is not an effective control.

Case Study 3: Major Incident Reported in Monthly MIS

A digital banking platform suffers a serious outage affecting thousands of customers.

The incident is recorded correctly.

However, senior management learns about it only through the next month's operational-risk report.

Analysis

The primary weakness is escalation and reporting timeliness.

A material disruption affecting critical operations should trigger reporting based on severity, not normal periodic MIS frequency.

The bank should review:

• incident-classification thresholds;

• escalation procedures;

• communication responsibilities; and

• crisis-management arrangements.

CAIIB Lesson

Recording an event correctly does not compensate for delayed escalation.

Case Study 4: Insurance Cover Creates False Comfort

A bank has insurance against certain cyber losses.

Management reduces cybersecurity investment because major financial loss is insured.

Analysis

This is weak risk management.

Insurance may not cover:

• every event;

• reputational consequences;

• regulatory action;

• customer disruption;

• deductibles; or

• losses beyond policy limits.

Cybersecurity controls remain necessary to reduce the likelihood and impact of the event itself.

CAIIB Lesson

Risk transfer complements controls; it does not replace them.

Case Study 5: Critical Service Outsourced to One Vendor

A bank uses one technology vendor for an important payment service.

The vendor experiences a major outage.

The contract includes financial penalties, but the bank has no practical alternative provider.

Risk Identification

The bank faces:

• third-party operational risk;

• concentration risk;

• business-continuity risk; and

• potentially customer and reputational consequences.

Contractual penalties may compensate part of the financial impact but do not restore the critical service.

The bank should examine:

• vendor resilience;

• recovery arrangements;

• alternative processing;

• concentration;

• contingency plans; and

• exit strategy.

CAIIB Lesson

A contract can transfer some financial consequences but cannot transfer the bank's need to maintain operational resilience.

Case Study 6: Repeated Policy Override

A business unit is permitted to override a transaction limit with senior approval in exceptional situations.

During three months, the exception is used dozens of times.

Every override is technically authorised.

Analysis

The problem is no longer merely whether each override was approved.

Repeated overrides may indicate:

• an inappropriate limit;

• weak process design;

• excessive risk-taking;

• abuse of exceptional authority; or

• a mismatch between policy and actual business practice.

Management should analyse the pattern rather than examining each exception in isolation.

CAIIB Lesson

Repeated authorised exceptions can themselves become an operational-risk indicator.

Operational-Risk Case Analysis Framework

For CAIIB case studies, use S–R–C–A–V.

Step 1 — Signal

Identify what has happened:

• loss event;

• KRI deterioration;

• near miss;

• control failure;

• threshold breach; or

• external threat.

Step 2 — Risk Assessment

Determine:

• likelihood;

• impact;

• affected process;

• customer impact;

• criticality; and

• residual risk.

Step 3 — Control and Cause

Ask:

• Which control should have prevented or detected this?

• Did the control exist?

• Did it operate?

• What is the root cause?

Step 4 — Action and Escalation

Depending on severity:

• escalate;

• strengthen controls;

• stop activity;

• transfer part of risk;

• activate continuity plans; or

• formally accept residual risk.

Step 5 — Verify

Confirm that:

• corrective action was completed;

• the control works;

• residual risk is acceptable; and

• monitoring continues.

CAIIB Exam Focus

Remember these high-value points:

• Operational-risk monitoring should be continuous and forward-looking.

• KRIs, losses, near misses, audit findings and emerging risks are monitoring inputs.

• Risk-appetite and tolerance breaches require appropriate escalation.

• Operational-risk reports should be timely, accurate, actionable and manageable.

• Basel reporting covers significant loss events, root causes, key risks, appetite breaches and relevant external developments.

• Material incidents may require immediate reporting rather than waiting for routine MIS.

• Preventive controls try to stop events.

• Detective controls identify events or weaknesses.

• Corrective controls restore or rectify.

• Segregation of duties reduces the risk of error and fraud.

• Maker-checker works only when independence is genuine.

• Management overrides and policy exceptions require monitoring.

• Repeated exceptions may indicate deeper control weakness.

• Risk can be avoided, reduced, transferred or accepted.

• Risk acceptance must be conscious and within authorised appetite.

• Insurance reduces some financial impact but does not eliminate operational risk.

• Outsourcing does not remove the bank's accountability for operational risk.

• Business continuity and operational resilience complement preventive controls.

• Corrective action should address root causes, not merely immediate symptoms.

• Control effectiveness should be verified after remediation.

Common Exam Traps

Trap 1: “Operational-risk monitoring means recording losses after they occur.”

Incorrect. Monitoring also uses forward-looking KRIs, control weaknesses and emerging risks.

Trap 2: “A control is effective because it is documented in the procedure manual.”

Incorrect. It must also operate effectively in practice.

Trap 3: “Every operational-risk event can be completely prevented.”

Incorrect. Some risks cannot be eliminated economically or practically, making mitigation and resilience important.

Trap 4: “Insurance eliminates the operational risk.”

Incorrect. It may transfer part of the financial loss but does not prevent the underlying event.

Trap 5: “Outsourcing transfers operational-risk responsibility to the vendor.”

Incorrect. The bank remains responsible for managing material risks arising from outsourced activities.

Trap 6: “A correctly authorised exception cannot create operational risk.”

Incorrect. Frequent or inappropriate overrides can themselves indicate weak controls or excessive risk.

Trap 7: “Periodic reporting is sufficient for every operational event.”

Incorrect. Material events may require immediate escalation.

Trap 8: “Maker-checker eliminates fraud risk.”

Incorrect. Credential sharing, collusion or mechanical checking can defeat the control.

Trap 9: “Business continuity and operational-risk control mean exactly the same thing.”

Incorrect. Controls seek to prevent or reduce events, while continuity and resilience focus on maintaining or restoring critical operations through disruption.

Trap 10: “Correcting the financial loss completes operational-risk management.”

Incorrect. Root cause, control weakness and recurrence risk must also be addressed.

Memory Technique

Remember M–R–C–M:

M — Monitor: Watch indicators, incidents and controls. R — Report: Provide timely information and escalate material issues. C — Control: Prevent, detect and correct operational failures. M — Mitigate: Avoid, reduce, transfer or consciously accept residual risk.

For a case study, ask:

What changed? → Which control failed? → Who must know? → What action reduces the risk? → Has the action worked?