Bank Negara Malaysia issues replacement Policy Document on Operational Risk Reporting
16 February 2026
Bank Negara Malaysia (“
BNM”) issued a
Policy Document on Operational Risk Reporting on 30 January 2026 (“
Policy Document”). The Policy Document came into effect immediately upon its issuance and superseded the policy document by the same name issued on 10 April 2025.
The Policy Document applies to all Reporting Entities (severally a “
RE” and collectively “
REs”) as defined in paragraph 5.2 thereof, namely:
- Financial Institutions comprising:
- Licensed Banks;
- Licensed Investment Banks;
- Licensed Islamic Banks;
- Licensed International Islamic Banks;
- Licensed Insurers;
- Licensed Takaful Operators;
- Licensed International Takaful Operators; and
- Prescribed Development Financial Institutions;
- Issuers of Payment Instruments1 comprising:
- Approved Issuers of a Designated Payment Instrument; and
- Approved Issuers of a Designated Islamic Payment Instrument;
- Approved Operators of a Payment System; and
- Registered Merchant Acquirers.
The objective of the Policy Document is to require REs to submit information to BNM with regard to operational risk exposures and, among others, aims to:
- promote more structured operational risk reporting across all REs for the relevant types of operational risk; and
- streamline reporting with the enhanced Operational Risk Reporting (“ORR”).
The Policy Document also sets out the requirements for the reporting to BNM of Loss Event Data (“
LED”) (that is, information for assessing an RE’s exposure to operational risk and the effectiveness of its internal controls)
[2] and Key Risk Indicators (“
KRIs”) (that is, information that will provide insight into the operational risk exposures and are used to monitor the main drivers of exposure associated with the key risks) through the ORR system (formerly known as ORION – Operational Risk Integrated Online Network).
The Policy Document is to be read with the 21 legal instruments and policy documents set out in paragraph 7.1 of the Policy Document, as amended from time to time, and as are applicable to the relevant RE.
Responsibilities of parties
The Policy Documents imposes the following responsibilities an RE and its Group Chief Risk Officer (“
GCRO”), Chief Risk Officer (“
CRO”), RE’s Administrator (“
RE Admin(s)”) and Submission Officer (“
SO”):
RE
- prepare and submit data and information on LED, KRIs and Scenario Analysis (SA) to BNM through the ORR system in accordance with paragraph 13 of the Policy Document;
- ensure consolidation and centralisation of data and information at the entity level before submitting the same to BNM; and
- establish appropriate internal governance and processes to ensure completeness, accuracy and timeliness of the data and information submitted to BNM, including processes for consolidating, validating and reconciling such data and information with the RE’s internal database, system and financial accounts.
- ensure the RE complies with its reporting requirements set out in the Policy Document;
- appoint up to two RE Admin(s) and up to 10 SOs to perform the functions set out below; and
- ensure that the reporting requirements of the RE Admin(s) and SOs set out below are complied with at all times, in the absence of such personnel.
RE Admin(s)
- ensure the reporting requirements in the Policy Document are complied with at all times and that the RE’s submissions are in accordance with such reporting requirements;
- assign SOs to perform the functions set out below;
- verify that the data and information to be submitted to BNM is accurate, complete and has been consolidated at the entity level and reconciled with internal reports and databases, and approve such data and information to be submitted to BNM;
- liaise with BNM on matters pertaining to the data and information to be submitted or generally on the ORR system; and
- ensure the successful transmission of the data and information to BNM within the timeline specified under each data category.
SOs
- prepare the data and information to BNM through the ORR system; and
- perform corrections, amendments and provide updates on the submitted data and information via the ORR system, upon having knowledge of any inaccuracy in the submission.
Changes in GCRO, CRO, RE Admin(s) and SOs
REs must register and update the changes to the GCRO, CRO, RE Admin(s) or SOs in the ORR system within one working day from the official change in the role. REs must also ensure that any changes to the GCRO, CRO, RE Admin(s) or SOs will not impact the timeliness of data and information submission to BNM.
ORR reporting requirements
The ORR reporting requirements are set out in Table 1 of paragraph 13.1 of the Policy Document. In summary, Table 1 sets out 17 types of reporting requirements (e.g. customer information breaches and fraud events), the REs to whom such requirements are applicable, and the appendix number of each reporting requirement.
Scope of reporting
REs must report all operational risk events in accordance with the requirements and timelines set out in Table 2: Operational risk information reporting deadlines and Table 3: ORR LED reporting types and deadlines. The reporting must include the operational risk events of foreign and offshore subsidiaries or branches of the REs which resulted in financial-related losses
4.
Classification and quantification
Reportable operational risk events shall be classified as follows:
- Actual Event: An operational risk event that impacted the RE with a financial and/ or non-financial impact. Such event may result in an actual loss or potential loss which will be concluded with an actual loss on a later date;
- Potential Event: A possible operational risk event yet to be confirmed by the RE’s internal governance. A Potential Event has the tendency to be re-classified as Actual or Near Miss event upon completion of the investigation; and
- Near Miss Event: An event for which actual operational risk did not materialise due to the timely use of controls or mitigating actions implemented by the RE.
REs must also collect information about the reference dates of the operational risk event, in accordance with the following sequence:
- Date of occurrence: the date when the event happened or took place;
- Date of detection: the date on which the RE discovered the event;
- Date of confirmation: the date on which the RE has verified or confirmed the operational risk event;
- Date of loss event captured in Profit & Loss (P&L) account: the date when the operational risk loss is recognised based on the RE’s accounting framework; and
- Date of loss event captured in Provision account: the earliest date when the operational risk loss has been accrued in suspense, reserve or provision of the RE’s account.
REs must classify the financial impact in accordance with the following:
- Actual Loss: A definitive loss amount in accordance with the RE’s accounting framework;
- Gross Actual Loss: Actual loss that occurs before any form of recovery; and
- Net Actual Loss: Actual loss after taking into account the impact of recoveries;
- Potential Loss: A conservative estimate of the loss amount until actual loss can be determined; and
- Recovery: A separate event from the original loss event, occurring at a different period, in which monies or inflows of economic advantages are received from a third party such as reimbursements received from insurers, repayments received from perpetrators of fraud, and recoveries of erroneous transfers.
An RE must not include indirect financial loss which resulted from an operational risk event in the calculation of the actual and potential loss amount reported in the ORR system.
Where a provision is made for the measurable loss of an on-going event, the amount must be classified as ‘Actual Loss’ or ‘Potential Loss’ in the ORR system based on the RE’s accounting framework. The loss amount must be adjusted if the provisional amount is subsequently changed.
Non-financial operational risk events may be ascribed impact ratings of “high”, “medium” and “low” that may be used to consider the following non-financial risks, which are non-exhaustive in nature:
- Reputational risks;
- Regulatory and legal risks;
- Compliance and conduct risk;
- Systemic risks;
- Cyber and IT risks; and
- Business continuity risks.
REs must report the operational risk information as tabulated in Table 2: Operational risk information reporting deadlines and Table 3: ORR LED reporting types and deadlines. For an operational risk reporting that falls within the requirements in both Table 2 and Table 3, REs must adhere to the earliest stipulated deadline.
Additional reporting requirements
All submissions to the ORR system must not contain any customer information or employee data, unless the submissions are for the purpose of reporting breaches involving customer information.
REs must reassess and update all on-going operational risk events to reflect any changes to event classifications and latest information.
Notwithstanding the timeline for reporting critical events as stated in Table 3: ORR LED reporting types and deadlines, the REs must notify BNM of the occurrence of critical events through other communication channels at the earliest opportunity, upon the detection of the event.
REs must notify BNM via oprisku@bnm.gov.my of any late submission and the reason(s) for the delay. Such notification does not constitute a waiver of the reporting requirements or an extension to the reporting timelines, by BNM.
Where an event causes or involves multiple different reportable operational risk events in the ORR system, REs must report each event as separate reportable operational risk events according to Table 3: ORR LED reporting types and deadlines.
5
KRIs
REs must submit information on the KRIs according to the applicability, description and frequency set out in Appendix 16 – Key risk indicators Taxonomy of the Policy Document.
BNM may define the KRIs at the following levels:
- entity level, i.e. generic KRIs that can be aggregated on an enterprise-wide basis;
- specific to a business line; or
- shared across multiple business lines.
REs are required to report the KRIs to BNM within the timeline specified in Table 5 of paragraph 18.3 of the Policy Document.
Access to ORR system
BNM will grant access to the ORR system via KijangNet to an RE’s GCRO, CRO, RE Admin(s) and SOs (as applicable) once the RE has completed the self-registration process. REs are also required to perform the self-registration process for their respective GCRO, CRO, RE Admin(s) and SOs via KijangNet.
Comments
This Policy Document ensures accurate and timely reporting of operational risk events. The ORR framework introduces a clearer role structure and refined reporting timelines, while enhancing digital system integration via KijangNet and overall regulatory responsiveness. The structured approach through the use of standard templates set out in the Appendices of the Policy Document also ensures consistency of information provided to BNM under the ORR system.
Article by Lee Ai Hsian (Partner) and Chong Zhi Shin (Associate) of the Banking and Finance Practice of Skrine.
1 Payment instruments include debit card, debit card-i, credit card, credit card-i, charge card, charge card-i and electronic money.
2 The purpose of the analysis of LED is to provide insight into the causes for large losses and whether control failures are isolated or systematic in nature. Identifying how operational risk may lead to credit risk and market risk-related losses also provides a more holistic view of the operational risk exposure.
3 An RE may authorise any other officer to act in the capacity of GCRO or CRO.
4 Where there are challenges to comply with the requirements set out in the Policy Document in relation to foreign and offshore subsidiaries or branches, an RE must notify BNM of such challenges in writing to seek a waiver, which may be granted at BNM’s discretion.
5 Refer to paragraphs 17.5 and 17.6 of the Policy Document for examples of such scenarios.
This article/alert contains general information only. It does not constitute legal advice nor an expression of legal opinion and should not be relied upon as such. For further information, kindly contact skrine@skrine.com.