Operational risk management process - OR-1 Operational Risk Management V.2

OR-1 Operational Risk Management V.2 - consultation

7. Operational risk management process

7.1 Overview

7.1.1 AIs should have effective means processes and tools to regularly identify, assess, monitor and control the operational risk inherent in their material products, activities, processes and systems in a timely manner, which should ensure that potential risks, threats and vulnerabilities that may affect critical operations delivery are prevented. They should take Reasonable steps should be taken to ensure that these processes and tools the risk management systems put in place to identify, assess, monitor and control operational risk are adequate and effective for the that purposes.

7.2 Risk identification and assessment

7.2.1 In order to better understand its operational risk profile and effectively target risk management resources, an AI should identify the types of operational risks to whichrisk that it is

16 See Basel consolidated framework OPE25.17 Table 2.

17 See Annex 7 – Detailed Loss Event Type Classification of Basel II.

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

exposed to as far as reasonably possible and assess its vulnerability to these risks. It should identify and assess the operational risk inherent in all existing or new, material products, activities, processes and systems, based on its own definition and categorisation of operational risk.

Effective operational risk identification and assessment are fundamental characteristicsprocesses are paramount for the subsequent development of an effectivea viable operational risk managementmonitoring and control system, and directly contribute to operational resilience capabilities.

7.2.2 When identifying its operational risk, an AI should consider both internal and external factors that could adversely affect the achievement of the AI’s objectives, such as:

(a) the AI’s management structure, risk culture, human resource management practices, organisational changes and employee turnover;

(b) the nature of the AI’s customers, products and activities, including sources of business, distribution mechanisms, and the complexity and volumes of transactions;

(c) the design, implementation, and operation of the processes and systems used in the operating cycle of the AI’s products and activities; and

(d) the external operating environment and industry trend, including political, legal, technological and economic factors, the competitive environment and market structure.

7.2.3 Having identified the risks, AIs need to define the appropriate approach to assessing each identified risk, estimate the probability that the identified risks will materialise by considering the causes of the risks, and assess their impact by referring to the potential effect on the realisation of corporate objectives.

7.2.4 A number of tools are commonly used for identifying and assessing operational risk:

(a) Event management (the process of identification, analysis, end-to-end management and reporting of an operational risk event that follows a pre-determined set of protocols) – A sound event management approach typically includes analysis of events to identify new operational risks,

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

understanding the underlying causes and control weaknesses, and formulating an appropriate response to prevent recurrence of similar events.

This information is an input to self-assessments (see (c) below) and, in particular, to the assessment of control effectiveness.

(b) Operational risk event data (a comprehensive operational risk event dataset that collects all material events experienced by an AI and serves as a basis for operational risk assessments) – The event dataset typically includes internal loss data and near misses. Event data is typically classified according to a taxonomy defined in the ORMF policies and consistently applied across the AI.

Event data typically include the date of the event (occurrence date, discovery date and accounting date) and, in the case of loss events, financial impact. Where available, other root cause information for the events should ideally also be included in the operational risk dataset. Where feasible, AIs should also seek to gather external operational risk event data and use the data in their internal analysis, as it is often informative of risks that are common across the industry.

(c) Self-assessments (assessments of operational risks and controls on various different levels conducted by the AI) – The assessments typically evaluate inherent risk (the risk before controls are considered), the effectiveness of the control environment, and residual risk (the risk exposure after controls are considered) and contain both quantitative and qualitative elements. The qualitative element reflects consideration of both the likelihood and consequence of the risk event in the bank’s determination of its inherent and residual risk ratings. The assessments may utilise business process mapping to identify key steps in business processes, activities, and organisational functions, as well as the associated risks and areas of control weakness. The assessments should contain sufficiently detailed information on the business environment, operational risks, underlying causes, controls and evaluation of control effectiveness to enable an independent reviewer to determine how the bank reached its ratings. A risk register can be

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

maintained to collate this information to form a meaningful view of the overall effectiveness of controls and facilitate oversight by senior management, risk committees and the Board.

(d) Control monitoring and assurance framework (a structured approach to the evaluation, review and ongoing monitoring and testing of key controls) – The analysis of controls ensures they are suitably designed for the identified risks and operating effectively. The analysis should also consider the sufficiency of control coverage, including adequate prevention, detection and response strategies, taking into account different operational risks across business areas.

(e) Metrics (quantitative indicators developed using operational risk event data and risk and control evaluations to assess and monitor operational risk exposure) – Metrics are primarily selected operation/control indicators considered relevant for management tracking and escalation triggering.

They may be simple indicators that are identified and periodically tracked by various functions of an institution, such as event counts, or outputs from more sophisticated exposure models as appropriate. The intention of metrics is to provide early warning information to monitor ongoing performance of the business and the control environment, and to report the operational risk profile, so that management can act on issues before they become major problems to an institution. Effective metrics clearly link to the associated operational risks and controls.

Monitoring metrics and related trends through time against agreed thresholds or limits provides valuable information for risk management and reporting purposes.

(f) Scenario analysis (a method to identify, analyse and measure a range of scenarios, including low probability and high severity events (e.g.

pandemics, natural disasters, and failures or disruptions at a third party or within the third party’s supply chain, etc.), some of which could result in severe operational risk losses) – Scenario analysis typically involves workshop meetings of subject matter experts including senior management,

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

business management and senior staff responsible for operational risk management and other functional areas such as compliance, human resources and IT risk management, to develop and analyse the drivers and range of consequences of potential events. Inputs to the scenario analysis would typically include relevant internal and external loss data, information from self-assessments, the control monitoring and assurance framework, forward-looking metrics, root-cause analyses and the process framework, where used.

The scenario analysis process could be used to develop a range of consequences of potential events, including impact assessments for risk management purposes, supplementing other tools based on historical data or current risk assessments. It could also be integrated with disaster recovery and business continuity plans, for use within testing of operational resilience (also see OR-2 “Operational Resilience”). Given the subjectivity of the scenario process, a robust governance framework and independent review are important to ensure the integrity and consistency of the process.

(g) Benchmarking and comparative analyses (comparisons of the outcomes of different risk measurement and management tools deployed within the AI, as well as comparisons of metrics from the AI to other firms in the industry) – Such comparisons can be performed to enhance understanding of the AI’s operational risk profile.

For example, comparing the frequency and severity of internal losses with self-assessments can help the AI determine whether its self-assessment processes are functioning effectively. Scenario data can be compared to internal and external loss data to gain a better understanding of the severity of the AI’s exposure to potential risk events.

 Self or Risk Assessment – a bank assesses its operations and activities against a menu of potential risk vulnerabilities. This process is internally driven and often incorporates checklists and/or workshops to identify the strengths and weaknesses of the operational risk environment.

 Risk Mapping – in this process, various business

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

units, organisational functions or process flows are mapped by risk types. This exercise can reveal areas of weakness and help prioritise subsequent management action.

 Risk Indicators – risk indicators are statistics and/or metrics, often financial, which can provide insight into an AI’s risk position. These indicators tend to be reviewed on a periodic basis (such as quarterly, monthly) to alert AIs to changes that may be indicative of risk concerns. Such indicators may include the number of failed trades, staff turnover rates and the frequency and/or severity of errors and omissions.

7.2.5 AIs should ensure that the operational risk assessment tools’ outputs are:

(a) based on accurate data, whose integrity is ensured by strong governance and robust verification and validation procedures;

(b) adequately taken into account in the internal pricing and performance measurement mechanisms as well as for business opportunities assessments;

and

7.2.6 The operational risk assessment tools cited in para. 7.2.4 can also directly contribute to an AI’s operational resilience approach. In particular, event management, self-assessment and scenario analysis procedures allow AIs to identify and monitor threats and vulnerabilities to their critical operations. AIs should use the outputs of these tools to improve their operational resilience controls and procedures¹⁸.

7.2.5 If conducted effectively, self-assessment should result in the identification of control gaps, and consequently the appropriate corrective actions to be taken (or a specific statement to accept the exposure), with a clear indication of the lines of responsibility for implementing the corrective actions and a target completion date. As such, the process should make the risk analysis of an institution explicit, clarify accountability in the line business areas, and ensure

18 These controls and procedures should be consistent with and conducted alongside the identification of threats and vulnerabilities as part of an AI’s operational resilience approach.

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

oversight by senior management.

7.2.6 In order to understand the effects of its operational risk exposures, an AI should continually assess its operational risks, taking into account factors such as:

 actual operational loss events or events that could have resulted in significant operational losses but were avoided (e.g. near misses or penalties waived by counterparty as a gesture of goodwill);

 results of internal assessment of risks and controls;

 the figures or trends shown in risk indicators (i.e.

quantitative data which can demonstrate operational efficiency, e.g. settlement failures, staff turnover, system downtime, processing volumes and number of errors, or effectiveness of controls,

 e.g. audit score or number of audit exceptions, limit excesses);

 reported external operational losses and exposures; and

 changes in its business operating environment.

7.2.7 Methodologies to quantify operational risk are developing.

As an institution aims to become more sophisticated in quantifying operational risks, complete and accurate data on operational loss events (by categories of risk) and potential sources of operational loss need to be collected.

An established and complete loss event database can potentially be used for empirical analysis and modelling of operational risk as well as quantification of the associated loss. Its importance is being recognised for more effective measurement and management of operational risk.

7.3 Risk monitoring and reporting

7.3.1 AIs should implement a process to monitor their operational risk profiles and material exposures to losses on an on-going basis. The process should include both qualitative and quantitative assessment of an AI’s exposure to all types of operational risk, assessing the quality and appropriateness of corrective/mitigation actions, and ensuring that adequate controls and systems are in place to identify and address problems before they become major concerns. It should be appropriate to the scale of risks and activities undertaken by the AI.

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

7.3.2 In monitoring its operational risks, an AI should make use of appropriate metrics (referred to in paragraph 7.2.4(e)).

identify or develop appropriate indicators that provide management with early warning of operational risk issues (often referred to as “key risk indicators” (KRIs)). KRIs used by AIs should provide management with predictive information and reflect potential sources of operational risk so that management can act on issues before they become major problems to the institution. KRIs are primarily a selection from a pool of operations/control indicators identified and being tracked by various functions of a bank on a periodic basis, which are considered to be relevant for management tracking and escalation triggering. By setting appropriate “goals or limits” or “escalation triggers” to KRIsthe metrics, monitoring of the KRIsmetrics can provide early warning of an increase in operational risk or a breakdown in operational risk management and facilitate communication of potential problems to a higher level of management.

7.3.3 Risk monitoring should be an integrated part of an AI’s activities, the frequency of which should reflect the risks involved in an AI’s activities as well as the pacefrequency and nature of changes in the operating environment.

7.3.4 The results of an AI’s monitoring activities, assessmentsfindings of the ORMFcompliance reviews performed by internal/external audit and/or the risk management function, management letters issued by external auditors, and reports generated by supervisory authorities, as appropriate, should be included in regular reports to the Board and the senior management to support proactive management.

7.3.5 An AI should be able to produce timely reports in both normal and stressed market conditions¹⁹. The reports should be comprehensive, accurate, consistent and actionable across business units and products. To this end, the first line of defence should ensure reporting on any residual operational risks, covering operational risk events, control deficiencies, process inadequacies, and non-compliance with operational risk tolerances. Reports should be manageable in scope and volume by providing an outlook on the AI’s operational risk profile and adherence to the operational risk appetite and tolerance

19 Reporting should be consistent with the BCBS’s Principles for effective risk data aggregation and risk reporting (https://www.bis.org/publ/bcbs239.pdf).

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

statement. Effective decision-making is impeded by both excessive amounts and paucity of data.

7.3.57.3.6 In general, the Board should receive sufficient high-level information to enable them to understand the AI’s overall operational risk profile and focus on the material and strategic implications for the business.

7.3.7 Generally, the management reports should describe the operational risk profile of an AI by providing contain relevant internal financial, operational, and compliance indicatorsdata, as well as external market or environmental information about events and conditions that are relevant to decision making. They should aim to provide information such as:

(a) the criticalkey and emerging operational risks facing, or potentially facing, the institution (e.g. as shown in KRIsmetrics and their trend data, changes in risk and control self-assessments, comments in audit/compliance review reports, etc.);

 major internal operational risk events/loss experience, issues identified and losses (including root causes, intended remedial actions;

(b) the status and/or effectiveness of remedial actions taken); and

(c)(d) exception reporting (covering, among others, authorized and unauthorized deviations from the AI’s operational risk policy (including in terms of risk appetite and risk tolerance) and likely or actual breaches in predefined thresholds, limits or qualitative requirements for operational exposures and losses).

7.3.67.3.8 Data capture and risk reporting processesReports should be analysed periodically with the goal of enhancing riska view to improving existing management performance as well as advancingdeveloping new risk management policies, procedures and practices.

7.3.77.3.9 To ensure the usefulness and reliability of the reports received, management should regularly verify the timeliness, accuracy, and relevance of reporting systems and internal controls in general.

7.3.87.3.10 AIs may consider keeping track of the information

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

provided in the reports, particularly the loss data, to establish a framework for systematically tracking and recording the frequency, severity and other relevant information on loss events.

7.4 Risk control and mitigation

7.4.1 A critical element to an AI’s control of operational risk is the existence of a sound internal control system. When properly designed and consistently enforced, a sound internal control system will help management ensure the efficiency and effectiveness of the operations, safeguard the institution’s resources, produce reliable financial reports, and comply with laws and regulations. Sound internal controls will also reduce the possibility of significant human errors and irregularities in internal processes and systems, and will assist in their timely detection when they do occur.

7.4.2 For all material operational risks that have been identified, the AI should decide whether to use appropriate policies, processes, procedures and systems to control and/or mitigate the risks, or bear the risks. For those risks that cannot be controlled or mitigated, the AI should decide whether to accept these risks, reduce the level of business activity involved, or withdraw from this activity completely.

7.4.3 A sound internal control programme consists of risk assessment, activities monitoring and control, communication and information²⁰, which are also integral components of the risk management process. Typical practices to control operational risk in an AI include:

(a) clearly established authorities and/or processes for approval;

(b) segregation of duties - to avoid a conflict of interest in the responsibilities of individual staff (which can facilitate concealment of losses, errors or inappropriate actions) should be identified, avoided or minimized to the extent possible. Conflict of interest that cannot be avoided in practice should be subject to dual controls (e.g. a process that uses two or more separate entities/persons operating in concert to protect sensitive functions or information) or other countermeasures, independent monitoring

20 Management should make clear the internal control requirements to individual functions, which in turn provide information and feedback to enhance the control requirements on an ongoing basis.

Supervisory Policy Manual

OR-1 Operational Risk Management

V.2 - consultation

and review to guard against concealment of losses, errors or other inappropriate actions;

(d) maintaining safeguards for access to, and use of, bank assets and records;

(e) appropriateness of ensuring that staff level have appropriate expertise and training to maintain technical expertise;

(f) ongoing processes to identifyidentifying business lines or products where returns appear to be out of line with reasonable expectations (e.g. where a supposedly low risk, low margin trading activity generates high returns that could call into question whether such returns have been achieved as a result of an internal control breach); and

(g) regular verification and reconciliation of transactions and accounts.; and

(h) vacation policy that provides for officers and employees being absent from their duties for a period of not less than two consecutive weeks, or another period commensurate with the role of the employee and the risk profile / complexity of the AI.

7.4.4 The control processes and procedures should include a system for ensuring compliance with the policies regulations and laws.AIs should have policies, processes

在文檔中 Supervisory Policy Manual (頁 31-46)