Operational risk is the risk of loss resulting from inadequate or failed internal processes, people or systems, or from external events. It includes reputation and franchise risk associated with a bank’s business practices or market conduct. It also includes the risk of failing to comply with applicable laws, regulations, Regulatory Administrative Actions or bank’s policies. Operational risk does not include strategic risk or the risk of loss resulting solely from judgments made with respect to taking credit, market, interest rate, liquidity, or insurance risk.

The objective of the RCSA (Risk Control Self-Assessment) and Operational Risk Policy is to establish a consistent framework for assessing Operational Risk and the overall effectiveness of the internal control environment across the bank. While RCSA data can be used to compute capital charge for operational risk, it is the building blocks for Advance Measurement Approach (AMA) under Basel II guidelines.

Objective

This document has two objectives:

• Firstly, to explain the concepts of RCSA and lay the basic guidelines for developing templates for RCSA entities. This component is business oriented and defines the organization structure, risks and controls at each RCSA entity and assigns ratings for the same.

• Secondly, to outline the process of RCSA tracking which will capture RCSA information and help compute capital charge for Operational Risk. This data will form the basis for computation of operation risk capital charge using AMA approach.

Operational Risk

Operational Risk can be divided into three categories as shown below:

There are a number of incidents (called Loss Events) which occur in all the above categories. They can occur in any unit in the bank like a branch, IT department, Sales department, Controls department – it can occur in any department irrespective of whether it is a profit centre or loss centre. Each incident will have an associated monetary loss value associated with it. The frequency of loss events could be mitigated by controls and constant measurement can result in computation of an average loss frequency and average loss value for a given period of time. Projections based on these numbers using statistical tools could help us in computing the capital charge as described in later sections of this document.

RCSA Process

RCSA is a dynamic and iterative method for identifying important operational risks and Key Controls and for assessing and reporting on their effectiveness for each RCSA entity. When breakdowns in the controls environment are identified they are proactively tracked until fixed.

The key points to note are:

• It is dynamic. It keeps changing all the time based on controls introduced by the unit

• It is iterative – one puts controls, sees its effectiveness and changes it, if is not effective

• It is done at an RCSA entity (unit) level and all RCSA for entities (units) in an entity are put together to come up with an RCSA for the entity. Thus all departments in bank can be RCSA units and one can consolidate the RCSA and come up with an RCSA rating for the bank

• Corrective actions are tracked and implemented continuously

Typically, an organization implementing the RCSA processes will go through the steps described below.

Documenting and Defining

The first step is to define the organization hierarchy and make a list of top level risks for the organization. Based on the organization hierarchy, we can define the RCSA entities or units which will perform tests and measure risks, implement controls, measure their effectiveness and keep improving continuously. RCSA reports from all RCSA entities are submitted to the central group in the entity to arrive at an overall risk for the entity. The reporting entity defines top level risks and controls which percolate to lower units within the entity. Units can also add additional risks and controls if they are not covered by the entity level risks and controls. Let us see an example from the automobile industry and the same can be extrapolated for banking. It is a simplified case to understand the concepts.

In the above example, when we want to evaluate RCSA of XYZ motors, we will have to take RCSA of all its divisions – we are now looking and Used Cars sales as entity which publishes Entity level controls and Risks and each RCSA entity will have to select and give data relating to number of incidents, loss value during a reporting period along with controls to minimize risks and their effectiveness. Within each RCSA entity you can have multiple Test Units. A RCSA entity will collate all results of test units under it for reporting – reporting is done at RCSA entity level.

Identifying Risk and Controls

Each unit will now evaluate the risks and controls under three important categories:

• Risks which come from top level entity

• Regulatory Risks

• Additional risks not covered by top level entity risks

Continuing with our earlier example, the three types of risk monitored by RCSA tracking unit will be as follows:

A RCSA sheet for Risk Management processes in a bank is provided as an example in the annexure.

Assessment of Risks and Controls

RCSA is used for tracking important or materialistic risks only. If there are risks which are identified by a unit as “not important or not materialistic”, they must be documented and reviewed periodically. Managers of units reporting the RCSA are fully responsible for identifying risks, tracking incidents, associating loss value, linking them to risks, implementing controls to mitigate risks and report data in specified formats.

Controls are put in place in each RCSA entity to mitigate and eliminate risks. It is important to have periodic checks to see if the controls are effective are not. If the controls are found ineffective, a corrective action plan (CAP) must be put in place to mitigate risks. This must be a continuous process as risks change with changing processes and controls become ineffective from time to time and hence it is required to test periodically. Testing of controls can only be done on a sampling basis. The testing of controls must follow the following process:

• Select the appropriate sampling size

• Identify an independent tester to execute the test – someone other than the person performing the process or control on a BAU basis

• Summarize testing results for the completed tests

• Capture and document the location or attach evidence to prove the test’s outcome

• Determine the control’s operating effectiveness (e.g., Satisfactory, Not Satisfactory: Business Issue (BI), Not Satisfactory: Major Business Issue (MBI)

The following table summarizes the sample size required for effective testing of controls. It also gives the periodicity of testing required based on frequency of application of the control.

The following ratings must be used for Key Controls after testing is complete:

• Satisfactory: Results indicate that the Key Control operates effectively

• Not Satisfactory: Business Issue (BI): Results indicate that the Key Control does not operate effectively and could have a negative impact on the RCSA Entity, or a significant component of the RCSA Entity.

• Not Satisfactory: Major Business Issue (MBI): Results indicate that the Key Control does not operate effectively and could have a material negative impact on the RCSA Entity, or a significant component of the RCSA Entity.

Continuing with the automobile example, the logic to decide the ratings of the controls is shown below with examples.

Corrective Action Plan (CAP) is required where the controls are found to be inadequate to mitigate the risk. A CAP should address areas of weakness identified during testing where controls are absent, inadequate or ineffective. CAPs are required when:

• There is a lack of a Key Control(s) against an Important Risk

• An Important Risk has not been significantly mitigated by a key control

• As a result of testing, you’ve concluded that the controls are not operating effectively

If the CAP cannot be implemented within the stipulated time frame, then compensating controls that mitigate the Important Risk must be identified or put in place as a temporary measure. Compensating controls must be tested until the key control that is the subject of the corrective action is implemented and tested

Each RCSA Entity must assign a Risk and Control Rating to each Important Risk on a residual basis and assessed as:

• Acceptable: Key Control(s) assessed as ‘Satisfactory’

• Acceptable with Concerns: Key Control(s) assessed as ‘Not Satisfactory’, but compensating controls are in place to reduce the risk to an acceptable level. CAPs to be implemented can be accomplished without significantly diverting resources from business objectives

• Less-than-Acceptable: Key Control(s) assessed as ‘Not Satisfactory’, and compensating controls are not in place to reduce risk to an acceptable level.

The rating should also be used when CAPs cannot be accomplished without significantly diverting resources from business objectives

Reviewing and Ratings

A Risk & Control Rating must be assigned to the RCSA Entity as a whole and is the responsibility of the head of the RCSA entity. The Risk & Control Rating must be Acceptable, Acceptable with Concerns, or Less-than-Acceptable. The RCSA Entity Risk & Control Rating is assigned after taking into consideration the following:

– Risk & Control Ratings of each Important Risk,

– Any other known issues, and

– Management’s judgment

Thus the final rating of the RCSA entity must be based on rules like worst rating of risks or weighted average of ratings of risks with a slab definition to define risk for the entity. The processes must have the ability to provide manual override with authorization for final rating of the entity.

There must be an ability to consolidate ratings across RCSA entities to arrive at organization or enterprise based risk rating. This can also be based on rules as worst rating or a weighted average of ratings of various RCSA entities with a slab definition to define the risk of the organization or enterprise.

Key Risk Indicators

The RCSA process and Management review of business will help classifying risks by risk levels. Risks below certain risk levels can be ignored as they are not applicable to the RCSA entity or are very unlikely to occur. Risks identified as important or key risks must be monitored and reviewed through the RCSA process.

Key risks should have thresholds for escalations and if they are continuously below certain thresholds for a considerable period of time, a review must be conducted to see if it is still a key risk or not.

Loss Events Data

Each RCSA entity will have to capture actual loss events or incidents during the reporting period. Each loss event will have the following attributes:

• RCSA Entity code

• Incident reference number

• Description of the incident

• Key Risk category with which it is associated

• Actual or estimated loss due to the incident

• Did it have customer impact

• Was it reported externally (Police/Press)

• Potential cause of the incident

• Suggested remedy to prevent recurrence

While we can capture more descriptive or categorization data for each loss event, the key fields are the following:

• linking the incident to the right key risk category and

• Actual or estimated loss value

The above will have a key impact in computing capital charge for operational risk for the bank.

Reporting

Each RCSA entity will submit a periodic (defined by the bank) RCSA report. The periodicity could be different based on the nature of work done in each RCSA entity. The need for the reports/Queries given below is visualized. This section will need a review and will vary from customer to customer. We will also have to come up with some good dashboards and this can come out of a discussion once the concept is understood.

RCSA Enterprise Report

The report should contain overall rating of the organization with time period of reporting and risk rating of all RCSA entities under it. It is possible that the RCSA entities could have tiered levels and appropriate levels of drill down will have to be provided.

RCSA Entity Report

All entities will have to submit a report at the prescribed periodicity.

• Loss Events – Covered in section 5. Fields required for the report could vary from bank to bank

• RCSA results summary at entity level – overall rating, number of risks and method adopted for overall rating

• Key Risks and associated ratings with drill down to sampling tests, if required

• Management Summary – free text

Risk-Control Environment Summary report

Risk Control Testing Details

Capital Computation

The capital computation for operational risk is based on:

• Internal Loss Data

• External Loss Data

Internal Loss data is captured by the bank and external loss data can be used and supplementary data where internal data is not found adequate. It is the bank’s responsibility to arrange and collect external data.

There are three methods for computing capital charge:

• Loss Distribution Approach (LDA)

• Scenario Based AMA

• Risk Drivers and Control Approach

Under LDA, Capital is computed using Model loss distributions obtained by fitting Internal and/or external loss data. Capital is obtained from a joint frequency/severity distribution.

Under Scenario based approach, a large number of discrete loss scenarios are identified and quantified (from a combination of loss data and expert judgment). “A bank must use Scenario Analysis of expert opinion in conjunction with external data to evaluate its exposure to high severity events. This approach draws on the knowledge of experienced business managers and risk management experts to derive reasoned assessments of plausible severe losses. Scenario Analysis involves identifying plausible future events and making educated assumptions to generate “what if” scenarios and examine their possible impact on our businesses. Scenario Analysis can help management make contingency plans to

• reduce the impact from such scenarios, and

• implement or strengthen controls to reduce the likelihood of scenarios happening

Scenario Analysis will be an additional tool for both the measurement and management of Operational Risk.

Under Risk Drivers and Control Approach, capital is posted using BIA approach (or standardized approach) and allocated to units based on risk drivers. Relationship between capital and risk drivers can be done using an algorithm based on loss data or risk control ratings – there is nothing fixed and it can vary from bank to bank.

In this document, we will focus on computing capital charge using Scenario based Approach. The following steps should be used to compute the capital charge:

• Compute average loss associated with each loss event. The weightage given to external and internal data can be different.

• Based on frequency of occurrence over a period of time (say 3 years), compute the probability of occurrence of the event.

• Check the RCSA rating for the risk associated with the loss event. Associate a premium on capital charge, if the risk rating is “Acceptable with Concerns” or “Less than Acceptable”

• The bank can specify a minimum capital charge for risks which do not have loss events.

• Compute estimated losses for scenarios painted by the expert and associate a probability with the likelihood of the scenario. Multiply the two to arrive at a scenario premium in additional to the actual loss based capital charge

• The summation of actual loss charge and scenario based charge will become the operational risk capital charge.

Some banks may want to compare the operational risk charge computed by above methodology and the BIA approach and take the higher of the two till processes stabilize.

The capital charge for operations risk can be a sum of (average loss* Probability of occurrenceweightage for external/internalrisk rating factor based on rating) across all risks.