Operational Risk Integrated Online Network (ORION) Policy Document
Applicable to: 1. Licensed banks 2. Licensed Investment banks 3. Licensed Islamic banks 4. Licensed International Islamic banks 5. Licensed insurers 6. Licensed takaful operators 7. Licensed international takaful operators 8. Prescribed development financial institutions 9. Approved issuers of a designated payment instrument 10. Approved issuers of a designated Islamic payment instrument
Issued on: 25 February 2021
Page 2 of 94
TABLE OF CONTENTS
PART A: OVERVIEW ...... 4 1. Introduction ...... 4 2. Applicability ...... 4 3. Legal provisions ...... 4 4. Effective date ...... 4 5. Interpretation ...... 4 6. Policy document superseded...... 6 7. Enquiries and correspondence ...... 7 PART B: POLICY REQUIREMENTS ...... 8 8. Overview of the responsibilities of reporting entities ...... 8 9. Roles and responsibilities of ORION users ...... 8 10. Access to ORION ...... 9 11. Registration of ORION users ...... 9 PART C: REPORTING REQUIREMENTS ...... 10 12. ORION reporting requirements ...... 10 13. Scope of reporting ...... 11 14. Reporting currency ...... 11 15. Classification and quantification ...... 11 16. Additional reporting requirements ...... 14 17. Key risk indicators ...... 14 18. Scenario analysis ...... 14 APPENDICES...... 16 APPENDIX 1 ORION user guide and technical specifications ...... 16 APPENDIX 2 Operational risk event reporting requirements ...... 16 APPENDIX 3 Cyber threat reporting requirements ...... 20 APPENDIX 4 BDSF event reporting requirements ...... 26 APPENDIX 5 Boundary event reporting requirements ...... 27 APPENDIX 6 Customer information breaches reporting requirements ...... 28 APPENDIX 7 Insurance-related event reporting requirements ...... 33 APPENDIX 8 SNC event reporting requirements ...... 38 APPENDIX 9 Payment-related fraud event reporting requirements ...... 45 APPENDIX 10 Aggregate reporting requirements ...... 58 APPENDIX 11 Overseas loss event reporting requirements ...... 67 APPENDIX 12 Business lines taxonomy ...... 70 APPENDIX 13 Event types taxonomy ...... 76 APPENDIX 14 Causal categories taxonomy ...... 84 APPENDIX 15 Key risk indicators taxonomy ...... 86
Issued on: 25 February 2021 Page 3 of 94
LIST OF TABLES
Table 1 ORION reporting requirements…………………………….…… 10 Table 2 ORION Reporting types and timelines…..………………....….. 13 Table 3 Timeline for KRI reporting to ORION……………………….….. 14 Table 4 Data fields for operational risk event reporting ………………. 16 Table 5 Types of cyber threats…………………………………………… 20 Table 6 BDSF event reporting types …………………………………..... 26 Table 7 SNC specific data fields…………………………………………. 40 Table 8 Payment-related fraud types ………………………………...... 45 Table 9 Card-related fraud MO…………….…………………………….. 46 Table 10 Network based e-money scheme MO …….…………………... 47 Table 11 Cheque fraud MO …………………….……….………………… 47 Table 12 Internet banking fraud MO ……………………………………… 48 Table 13 Mobile banking fraud MO ………………………………………. 49 Table 14 Aggregate reporting types and threshold …………………….. 58 Table 15 Overseas loss event reporting requirements.………………… 67
Issued on: 25 February 2021 Page 4 of 94
PART A: OVERVIEW
1. Introduction
1.1 The sound operational risk management requires a comprehensive identification and assessment of Operational Risk as well as monitoring of Operational Risk exposures through indicators such as Loss Event Data, Key Risk Indicators and Scenario Analysis.
1.2 The objective of this policy document is to require reporting entities (REs) to submit information to the Bank with regard to operational risk exposure.
1.3 This policy document sets out the requirements for the reporting of Loss Event Data, Key Risk Indicators and Scenario Analysis to the Bank through the ORION.
2. Applicability
2.1 This policy document is applicable to REs as defined in paragraph 5.2.
3. Legal provisions
3.1 This policy document is issued pursuant to: (a) sections 47(1) and 143(2) of the Financial Services Act 2013 (FSA); (b) sections 57(1) and 155(2) of the Islamic Financial Services Act 2013 (IFSA); and (c) section 41(1) and constitutes a notice under section 116(1) of the Development Financial Institutions Act 2002 (DFIA).
3.2 The guidance in this policy document is issued pursuant to section 266 of the FSA, section 277 of the IFSA and section 126 of the DFIA.
4. Effective date
4.1 This policy document comes into effect on 1 March 2021.
5. Interpretation
5.1 The terms and expressions used in this policy document shall have the same meanings assigned to them in the FSA, IFSA or DFIA, as the case may be, unless otherwise defined in this policy document.
5.2 For the purpose of this policy document:
“S” denotes a standard, an obligation, a requirement, specification, direction, condition and any interpretative, supplemental and transitional provisions that must be complied with. Non-compliance may result in enforcement action;
Issued on: 25 February 2021 Page 5 of 94
“G” denotes guidance which may consist of statements or information intended to promote common understanding and advice or recommendations that are encouraged to be adopted;
“BDSF” refers to business disruption and system failure;
“CRO” means the Chief Risk Officer of a RE;
“Financial group” refers to a financial holding company approved by the Bank or a licensed institution, and a group of related corporations under such financial holding company or licensed institution primarily engaged in financial services or other services which are in connection with or for the purposes of such financial services which includes at least one licensed person;
“Financial institutions” or “FIs” means: (a) licensed banks, licensed investment banks and licensed insurers under the FSA; (b) licensed Islamic banks which includes licensed international Islamic banks, and licensed takaful operators which includes licensed international takaful operators under the IFSA; and (c) prescribed institutions under the DFIA;
“GCRO” means the Group Chief Risk Officer of a RE;
“Loss Event Data” or “LED” refers to information required for assessing an entity’s exposure to operational risk and the effectiveness of its internal controls. 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;
“Key Risk Indicators” or “KRIs” refer to information that will provide insight into the operational risk exposure and are used to monitor the main drivers of exposure associated with the key risks;
“Operational Risk” has the same meaning assigned to it under the Policy Document on Operational Risk issued by the Bank on 10 May 20161and includes any amendments made thereof from time to time. For ease of reference, Operational Risk refers to the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events. Operational risk is inherent in all activities, products and services of financial institutions and can transverse multiple activities and business lines within the financial institutions. It includes a wide spectrum of heterogeneous risks such as fraud, physical damage, business disruption, transaction failures, legal and regulatory breaches2 as well as employee health and safety hazards. Operational risk may result in direct
1 Paragraph 1.1 of the Policy Document on Operational Risk. 2 Including fiduciary breaches and Shariah non-compliance by Islamic financial institutions.
Issued on: 25 February 2021 Page 6 of 94
financial losses as well as indirect financial losses (e.g. loss of business and market share) due to reputational damage;
“ORION” refers to the Operational Risk Integrated Online Network;
“Payment instrument issuers” or “PIIs” mean: (a) approved issuers of a designated payment instrument under the FSA; and (b) approved issuers of a designated Islamic payment instrument under the IFSA;
“Reporting entities” or “REs” refer to financial institutions and payment instrument issuers;
“Scenario Analysis” or “SA” refers to an assessment made by an entity to identify potential operational risk events and assess potential outcomes including identifying potential significant operational risks and the need for additional risk management controls or mitigation solutions;
“SNC” refers to Shariah Non-Compliance;
“Control function” refers to the definition as provided in the policy document on Corporate Governance issued by the Bank and includes any amendments made to thereof from time time; and
“Officer within the control function” means an officer that meets the following criteria: (a) Performs one of the control functions under Shariah governance (i.e. Shariah risk management, Shariah review or Shariah audit); (b) Independent from the business lines and not involved in revenue generation activities; and (c) Possesses sound understanding of relevant Shariah requirements applicable to Islamic financial business.
6. Policy document superseded
6.1 This policy document supersedes the policy document on Operational Risk Reporting Requirement – Operational Risk Integrated Online Network (ORION) issued on 22 June 2018.
6A. Related legal instruments and policy documents
6A.1 This policy document must be read together with other relevant legal instruments and policy documents that have been issued by the Bank, in particular –
(a) Operational Risk issued on 10 May 2016 ; (b) Corporate Governance issued on 3 August 2016 for FSA and IFSA; (c) Corporate Governance issued on 13 December 2019 for DFIA;
Issued on: 25 February 2021 Page 7 of 94
(d) Shariah Governance Policy Document issued on 20 September 2019; (e) Risk Management in Technology (RMiT) issued on 19 June 2020; (f) Management of Customer Information and Permitted Disclosures issued on 17 October 2017; (g) Guidelines on Business Continuity Management (Revised) issued on 3 June 2011; (h) Guidelines on Handling of Suspected Counterfeit Malaysian Currency Notes issued on 2 September 2014; (i) Letter on the ‘Implementation of Financial Stability Board’s Cyber Lexicon and Bank Negara Malaysia’s Cyber Incident Scoring System for the Financial Institutions’ issued on 28 September 2020; and (j) ORION Frequently Asked Questions (FAQ) document3.
7. Enquiries and correspondence
7.1 All enquiries and correspondences relating to this policy document shall be addressed to:
Pengarah Jabatan Pakar Risiko dan Penyeliaan Teknologi Bank Negara Malaysia Jalan Dato’ Onn 50480 Kuala Lumpur Fax No: 03-26970086 Email: [email protected]
3 For avoidance of doubt, REs must refer to the FAQ document in its entirety notwithstanding any direct reference made in this policy document to a specific paragraph in the FAQ document.
Issued on: 25 February 2021 Page 8 of 94
PART B: POLICY REQUIREMENTS
8. Overview of the responsibilities of reporting entities
S 8.1 The REs must prepare and submit data and information on LED, KRIs and SA to the Bank through ORION in accordance with the requirements specified under section 12 entitled “ORION Reporting Requirements” of this policy document.
S 8.2 The REs must ensure that the data and information is consolidated and centralised at the entity level prior to submitting the information to the Bank.
S 8.3 The REs must put in place appropriate internal governance and processes to ensure completeness, accuracy and timeliness of the data and information submission to the Bank, including processes for consolidation, validation as well as reconciliation of such data and information with the RE’s internal database, system and financial accounts.
9. Roles and responsibilities of ORION users
GCRO
S 9.1 The GCRO or any other officer authorised by the RE to act in that capacity, is required to ensure the RE’s compliance with the reporting requirements set out in this policy document.
CRO
S 9.2 The CRO or any other officer authorised by the RE to act in that capacity, must ensure the RE’s compliance with the reporting requirements set out in this policy document.
S 9.3 The CRO shall:
(a) appoint a Submission Officer to perform the functions set out in
paragraph 9.4; and
(b) ensure that the reporting requirements in this policy document are
complied with at all times, including in the absence of the
Submission Officer.
Submission Officer
S 9.4 The Submission Officer shall: (a) prepare the data and information for submission to the Bank through ORION; (b) ensure that the data and information to be submitted to the Bank is accurate, complete and have been consolidated at the entity level and reconciled with internal reports and databases; (c) ensure the successful transmission of the data and information to the Bank within the timeline specified under each data category;
Issued on: 25 February 2021
Page 9 of 94
(d) perform corrections, make amendments and provide updates on the submitted data and information upon having knowledge of any inaccuracy in the data; and (e) liaise with the Bank on matters pertaining to the data and information to be submitted or generally on the ORION.
10. Access to ORION
Financial group structure
G 10.1 In the case of REs operating as financial groups, access to ORION will be granted to the GCRO, CRO and Submission Officer.
Single entity structure
G 10.2 In the case of REs operating on stand-alone basis, access to ORION will be granted to the CRO and Submission Officer.
Adoption of structure
S 10.3 The REs must notify the Bank in writing on the type of reporting structure that it intends to adopt.
11. Registration of ORION users
Details to be registered
S 11.1 The REs must register the following details of the GCRO, CRO and Submission Officer at FI@KijangNet portal at www.bnm.gov.my: (a) Name (b) Designation (c) Email address (d) Phone number
Refer to FAQ No. 2.
Changes in GCRO, CRO and Submission Officer
S 11.2 The REs must notify the Bank in writing of any changes to the GCRO, CRO or Submission Officer and to update such details accordingly at FI@KijangNet portal. Please refer to FAQ No. 2.
S 11.3 The REs must ensure that any changes to the GCRO, CRO or Submission Officer will not impact the timeliness of data and information submission to the Bank.
Issued on: 25 February 2021 Page 10 of 94
PART C: REPORTING REQUIREMENTS
12. ORION reporting requirements
S 12.1 The REs must submit information to the Bank through ORION in accordance with Table 1: ORION reporting requirements.
Table 1: ORION reporting requirements Appendices Description Applicability Appendix 1 ORION user guide & technical REs specifications
Appendix 2 Operational risk event reporting REs requirements
Appendix 3 Cyber threat reporting FIs requirements
Appendix 4 BDSF event reporting FIs requirements
Appendix 5 Boundary event reporting FIs except Licensed requirements Insurers & Takaful Operators
Appendix 6 Customer information breaches REs reporting requirements
Appendix 7 Insurance-related event reporting Licensed Insurers & requirements Takaful Operators
Appendix 8 SNC event reporting requirements FIs
Appendix 9 Payment-related fraud event REs except reporting requirements Licensed Insurers & Takaful Operators
Appendix 10 Aggregate reporting requirements REs
Appendix 11 Overseas loss event reporting FIs requirements
Appendix 12 Business lines taxonomy FIs
Appendix 13 Event types taxonomy FIs
Appendix 14 Causal categories taxonomy FIs
Appendix 15 Key risk indicators taxonomy FIs
Issued on: 25 February 2021 Page 11 of 94
13. Scope of reporting
S 13.1 The REs must report all operational risk events in accordance with the requirements and timeline set out in Table 2: ORION Reporting types and timelines. The reporting must also include the operational risk events of foreign and offshore subsidiaries or branches of the REs which resulted in financial-related losses.
S 13.2 The REs shall submit to the Bank the LED module for events that occurred from 22 September 2014 onwards and the KRI module data for events that occurred from 1 October 2014 onwards.
S 13.3 For reporting of the operational risk events of foreign and offshore subsidiaries or branches of the REs, REs must notify the Bank of challenges faced by the REs in meeting the reporting requirements of this policy document. A waiver must be obtained from the Bank for failure by REs to comply with reporting requirements under such circumstance.
14. Reporting currency
S 14.1 All amounts must be reported by REs in Ringgit Malaysia (RM).
S 14.2 REs must use its applicable internal exchange rate to convert loss amounts to RM in the instance where a financial loss is in a foreign currency.
15. Classification and quantification
Financial related operational risk event
S 15.1 REs must classify financial-related events in accordance with the following: (a) Actual Loss – Actual Loss refers to an event that resulted in a measurable loss in the RE’s Profit and Loss account. Accounting treatment must be applied in accordance with the RE’s accounting policies. (b) Potential Loss – Potential Loss refers to a conservative estimate of the loss amount until actual loss can be determined. Accounting treatment must be applied in accordance with RE’s internal policy. (c) Near Miss – Near Miss refers to an event which financial losses have been averted by controls or mitigating actions.
S 15.2 Where a provision is made in the Profit and Loss account for the measurable loss of an on-going event, the amount must be classified by the REs as ‘Actual Loss’ in ORION. The ‘Actual Loss’ amount must be adjusted by the REs if the amount for the provision is subsequently changed.
S 15.3 Indirect Loss which was resulted from an Operational Risk event must not be included by REs in the calculation of the actual and potential loss amount reported in ORION.
Issued on: 25 February 2021 Page 12 of 94
Non-financial related operational risk event
S 15.4 REs must classify Non-Financial-related events in accordance with the following: (a) High impact - which caused severe damage to reputation that resulted in long term effect on business credibility; (b) Medium impact - which caused moderate damage to reputation that resulted in medium term effect on business credibility; or (c) Low impact - which caused insignificant damage to reputation that did not result in any damage on business credibility.
Issued on: 25 February 2021 Page 13 of 94
Table 2: ORION reporting types and timelines Reportable operational risk events Classification Timeline Critical Robbery and theft Actual By T+1 working day, T event Self Service Terminals (SST)4 robbery Potential being the date of event Robbery and theft events ≥ RM 200k Near miss confirmation
Cyber threat Actual As defined in Appendix 3 Near Miss Reputational Impact Actual High impact events as defined by REs internal policy
All operational risk events ≥RM 1mil Actual By T+2 working days, T Potential being the date of event Critical BDSF confirmation As defined in Appendix 4 Actual
New modus operandi (MO) Actual New type of fraud MO committed and Potential impacted the REs for the first time
Customer information breaches Actual By T+1 working day, T As defined in Appendix 6 being the date of investigation is tabled to the Board
SNC Actual SNC Actual By T+1 working day, T event As defined in Appendix 8 being the date of SNC confirmation by Shariah Committee (SC) Potential SNC Potential By T+1 working day, T As defined in Appendix 8 being the date of event confirmation by an officer within the control function
Fraud All fraud types Actual By the 15th calendar day event Payment-related fraud is defined in Potential of the following month or Appendix 9 Near miss earlier Other fraud events
Other Aggregate reporting loss As defined in Appendix 10 Actual event All card fraud (Credit Card, Debit Potential Card, Charge Card) with amount Near miss involved ≤ RM 5k
All actual loss ≤ RM 1k Actual Physical cash shortages
Overseas loss events Actual As defined in Appendix 11 All other loss events Actual All events other than specified above with financial losses
4 Self Service Terminals (SST) are Automated Teller Machines (ATMs), Cash Deposit Machines (CDMs) and Cash Recycler Machines (CRMs).
Issued on: 25 February 2021 Page 14 of 94
16. Additional reporting requirements
S 16.1 All submission to ORION must not contain any customer information or employee data to satisfy data secrecy and data privacy.
S 16.2 All on-going Operational Risk events must be re-assessed and updated to reflect changes to event classification and latest information.
S 16.3 Notwithstanding the timeline for reporting of critical events as stated in Table 2, the REs must notify the Bank on the occurrence of critical events through other communication channels at the earliest opportunity upon the detection of the event.
17. Key risk indicators
S 17.1 FIs must submit information on the KRIs according to the applicability, description and frequency set out in Appendix 15 – Key risk indicators Taxonomy.
G 17.2 The Bank may define the KRIs at the following levels: (a) entity level, i.e. generic KRIs that can be aggregated on an enterprise-wide basis; (b) specific to a business line; or (c) shared across multiple business lines.
S 17.3 The FIs must report the KRIs to the Bank within the timeline specified in Table 3 below.
Table 3: Timeline for KRI reporting to ORION KRI frequency Reporting deadline Monthly By the 10th calendar day of the following month
Quarterly By the 15th calendar day of the following month
Semi-annually By the 15th calendar day of the following month
Annually By the 15th of January of the following year
18. Scenario analysis
G 18.1 Scenario Analysis (SA) is a systematic process in the creation of plausible operational risk events and has become an essential element in the operational risk management and measurement. It is one of the operational risk management tools5, however, unlike the others, it is a forward-looking tool that examines and explores predominantly emerging risks and rare tail-end events which are usually low frequency high impact events. Subsequently, the FIs will be able to incorporate the controls on these events to mitigate the risk exposures of those scenarios. By thinking
5 Operational Risk Management tools are LED, RCSA, KRI and SA
Issued on: 25 February 2021 Page 15 of 94
through the impact of various scenarios, FIs can enhance its contingency plans or business continuity management plans.
S 18.2 As part of the Bank’s mandate to promote the safety and soundness of FIs in the financial system, the FIs shall respond to the SA exercise which is executed through ORION via the SA modules where the Bank requires for the FIs to do so.
S 18.3 FIs must conduct SA as and when it may be required by the Bank and submit the results of the SA and other information to the Bank within prescribed time.
Issued on: 25 February 2021 Page 16 of 94
APPENDICES
APPENDIX 1 ORION user guide and technical specifications
1. Please refer to the attached document.
APPENDIX 2 Operational risk event reporting requirements
ORION data fields requirements
1. REs must report the following information for each operational risk event as guided in Table 4 below. Additional data fields for SNC, payment-related fraud and aggregate operational risk related events are provided in Appendix 8, Appendix 9 and Appendix 10 respectively.
Table 4: Data fields for operational risk event reporting Data fields Mandatory Description field Reporting Yes To select the respective reporting entity for Entity Name operational loss event (Note: Applicable to Financial Group structure)
Reporting entity name will be automatically displayed for a ‘Single’ entity
Nature of Yes New - New type of MO impacted the REs for the Event first time. Repeated - MO that has occurred previously at REs
Refer to FAQ No. 35.
Event Yes Operational risk events must be classified as either Classification one of the following: Actual loss Potential loss Near miss
Islamic Yes (if the (√) – If the operational risk event is relating to Islamic Business event is business or product related to Islamic (Note: If the event is no longer classified as SNC, product / Islamic Business box must remain checked (√) business) because the operational risk event is related to Islamic business or product)
Shariah Non Yes FIs must select one: Compliance (a) Yes Event reported as ‘actual’ SNC or ‘potential’ SNC (b) No Event classified as non-SNC (Note: For specific Shariah related fields, please refer to Appendix 8)
Issued on: 25 February 2021 Page 17 of 94
Data fields Mandatory Description field Loss Event Yes Clear and concise name that summarise the nature Name of the loss event
Internal Loss Yes REs are required to generate its own internal ID for Event ID each loss event reported in ORION
Business Yes Must be reported up to Level 3 (banking) and Level lines 2 (insurance) in accordance with the taxonomy in Appendix 12
Product / Yes Conditionally populated; please select one Services
Delivery Yes Conditionally populated; please select one Channel
Event Yes Must be reported up to Level 3 in accordance with categories* the taxonomy in Appendix 13
Causal Yes Must be reported up to Level 3 in accordance with categories* the taxonomy in Appendix 14
Country of Yes Country where the loss was incurred Events
State of Yes Conditionally populated for operational risk event Events occurred in Malaysia
District of Yes Conditionally populated for operational risk event Events occurred in Malaysia
Date of Event Yes The date of the operational risk event took place Occurrence
Date of Event Yes The date of operational risk event confirmation is Detection obtained
Loss Event Yes 1. General operational risk event Description An executive summary of the loss event and shall include the following details: (a) Chronology of the loss event Where the event took place How the event occurred The modus operandi involved Parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.) Number of customers affected by the event Number of business lines affected The root cause of the event (b) Remedial actions to resolve the event (c) Mitigating action plans to prevent recurrence of similar incident in the future
* Those marked with asterisks are not applicable to PIIs
Issued on: 25 February 2021 Page 18 of 94
Data fields Mandatory Description field (d) Indication of timeline when the event can be resolved (e) Progressive update of the event post-reporting to ORION
The executive summary must not include customer / individual confidential information e.g. Name, I/C number, account number and other personal information
2. Aggregate operational risk event
For further description and reporting format on aggregate reporting, please refer to Appendix 10
Event Valid No To remove existing operational risk event in ORION; Till this field is only applicable for genuine duplicated reporting in ORION
Reason Yes (if the The reason for the removal of the loss event must be above is provided selected)
Event Impact Yes Please choose one event impact from the following:
Financial impact - There is an actual or potential financial loss Non-financial impact – No loss amount involved but has impact on reputation, non-compliance etc. Both financial and non-financial – as defined above
Financial Yes RE must select whichever applicable: Impact Event for Banking >> Event For Event for ATM Acquirer Event for Payment Instrument Event for Payment Channel Event for Insurance & Takaful Operator
Financial Yes >>Banking Impact >> Event For REs must identify whether the operational loss event have boundary implications in accordance with Appendix 5 If the loss event is identified as a boundary event, REs must categorise either as Credit Risk or Market Risk related
Financial Yes >> ATM Acquirer Impact Please refer to Appendix 9 >> Event For
Financial Yes >> Payment instrument Impact Please refer to Appendix 9 >> Event For
Issued on: 25 February 2021 Page 19 of 94
Data fields Mandatory Description field Financial Yes >> Payment channel Impact Please refer to Appendix 9 >> Event For Financial Yes >>Insurance &Takaful Operator Impact >> Event For REs must identify the insurance category impacted from: Assets Claims Premium Re-insurance Intermediaries Others
Amount Yes This field must have a value to reflect the overall Involved financial amount associated with the operational risk event reported
Financial Yes REs to record the actual loss / potential loss / Impact (for recovery amount incurred according to the following Banking, ATM categories: Acquirer and Reporting Entity^ Payment Customer^^ Channel) 3rd Party >> Actual Loss / The REs must not use losses net of insurance Potential recoveries as an input to the ‘Actual Loss’ field. Loss / Instead, recovered amount must be recorded in the Recoveries ‘Recovery Amount’ field
(Note: ^ Please input the date of write-off or provision recognised in P&L in the “Comments” column. ^^ Please input the loss amount borne or partially borne by the customer)
Financial Yes >> Loss Incurred by Malaysian Entities Impact (for Payment Please refer to Appendix 9 Instrument)
Financial Yes >> Loss Incurred by Foreign Entities Impact (for Payment Please refer to Appendix 9 Instrument)
Non- Yes REs must select the severity of the non-financial Financial impact either as: Impact High >> Impact Medium Low
Non- Yes The detailed description of the non-financial impact Financial must be provided to justify the selection of High / Impact Medium / Low >> Comments
“>>” represents sub-data fields
Issued on: 25 February 2021 Page 20 of 94
APPENDIX 3 Cyber event reporting requirements
1. Cyber is defined as relating to, within, or through the medium of the interconnected information infrastructure of interactions among persons, processes, data and information systems.
2. Cyber threat is a circumstance with the potential to exploit one or more vulnerabilities that adversely affects cyber security. Vulnerability can be defined as a weakness, susceptibility or flaw of an asset (e.g. network devices, endpoints) or control that can be exploited by one or more threats.
3. Cyber security is preservation of confidentiality, integrity and availability of information and/or information systems through the cyber medium. In addition, other properties, such as authenticity, accountability, non- repudiation and reliability can also be involved.
Table 5: Types of cyber threats Types Description Example Malicious Software designed with malicious Adware Software intent containing features or Bots (Malware) capabilities that can potentially cause Bugs harm directly or indirectly to entities or Rootkits their information systems. Spyware
Virus A type of malware that is capable of MyDoom duplicating itself with the intention of Stuxnet stealing information or disrupt the device or system. Ransomware A type of malware that installs on a CryptoLocker victim’s device, encrypting or locking the victim’s systems or files. A request for payment is made to unlock the affected systems or files. Ransomware is considered to be a form of extortion. Distributed DDoS is the prevention of authorised Network Denial of access to information or information attack Service systems; or the delaying of Application (DDoS) information system operations and attack functions, resulting in the loss of availability to authorised users. DDoS is normally carried out using numerous sources simultaneously.
Hacking Hacking is an unauthorised intrusion N/A into a computer or a network.
Web Website defacement is an attack on a N/A defacement website that changes the visual
Issued on: 25 February 2021 Page 21 of 94
appearance of the website or a webpage.
Note: If there are any new modus operandi of cyber-attacks experienced in overseas subsidiaries or branches, please notify the Bank via email to the respective Supervisor of the Bank.
Cyber event reporting types
4. REs must report all cyber events that occurred as stipulated below to ORION in accordance with the requirements set out in Table 2: ORION reporting types and timelines within 1 working day upon confirmation.
(a) Cyber incident
Defined as a cyber event that: (i) jeopardizes the cyber security of an information system or the information the system processes, stores or transmits; or (ii) violates the security policies, security procedures or acceptable use policies, whether resulting from malicious activity or not.
(b) Cyber event
Defined as any observable occurrence of cyber threat in an information system. Cyber threat events may also provide an indication that a cyber incident is occurring (i.e. cyber threat which could potentially compromise REs’ IT equipment, system, operations, data, services or users).
5. Examples of reportable cyber incidents
(a) Ransomware that has affected corporate PCs / laptops and encrypted the files within.
Event Classification: Actual Loss Event type: BDSF>> System >> Security breach – virus / malware
(b) DDoS attack on the REs network that caused network downtime
Event Classification: Actual Loss Event type: BDSF>> System >> Security breach – Distributed Denial of Service
6. Examples of reportable cyber events
(a) Persistent DDoS attempt coming from the same IP address defined as ‘high risk’ by REs internal monitoring system.
Event Classification: Near Miss
Issued on: 25 February 2021 Page 22 of 94
Event type: BDSF>> System >> Security breach – Distributed Denial of Service
(b) Virus infection successfullly blocked by REs antivirus software defined as ‘high risk’ by REs internal monitoring system.
Event Classification: Near Miss Event type: BDSF>> System >> Security breach – virus / malware
Reporting a cyber incident and cyber event in ORION
7. Cyber incident and cyber event
Category: Cyber incident and cyber event Event Classification: Actual Loss or Near Miss
Data fields Description Reporting Entity Name To select the respective reporting entity for operational loss events
Event Classification Actual Loss – Any cyber incident that has been confirmed Near Miss – any high risk cyber event detected and confirmed
(Note: The event classification above is not referring to the status of financial impact resulted from the cyber incident or event) Refer to FAQ No. 68.
Nature of Event New - New type of MO that impacted the REs for the first time. Repeated - MO that has occurred previously at REs
Refer to FAQs No. 35 and 67.
Islamic Business (√) – If the operational risk event is relating to Islamic business or product
Loss Event Name Clear and concise name that reflects an overall summary and nature of the loss event
Business Lines Must be reported up to Level 3 (banking) in accordance with the taxonomy in Appendix 12
Products / Services Please choose where applicable
Delivery Channel Please choose where applicable
Issued on: 25 February 2021 Page 23 of 94
Data fields Description Event Category Please categorise the cyber incident or event using ONLY the following selection of event types:
OPTION 1 Level 1: Internal Fraud Level 2: Unauthorised Activity Level 3: Select one: Unauthorised changes to programmes, data or transactions Hacking / Cracking Misuse of system access (e.g. Powerful system ID) Computer virus / malware injection
OPTION 2 Level 1: External Fraud Level 2: System Security Level 3: Select one: Hacking damage Theft of information Unauthorised changes to programmes by external parties Misuse of system access by external parties Sabotage by external parties
OPTION 3 Level 1 : BDSF Level 2 : Systems Level 3 : Select one: Security breach – virus / malware Security breach – DDoS Security breach – hacking / cracking Security breach – Web defacement
Causal Category Must be reported up to Level 3 in accordance with the taxonomy in Appendix 14
Date of Occurrence The date cyber incident / event occurred
Date of Detection The date of cyber incident / event confirmation is obtained
Issued on: 25 February 2021 Page 24 of 94
Data fields Description Loss Event Description An executive summary of the incident / event and shall include the following details: (a) Chronology of the cyber incident / event: What type of cyber event occurred What type of system or service impacted from the attack How long was the system or service downtime (if any) Where is the cyber event coming from For DDoS attack, please specify the IP address How the cyber incident / event occurred i.e. root cause Number of customers affected Number of business lines affected
(b) Remedial actions to resolve the incident / event (c) Mitigating action plans to prevent recurrence of similar event in the future (d) Indication of timeline when the incident / event can be resolved (e) Progressive update of the incident / event post-reporting to ORION
The executive summary must not include customer / individual confidential information e.g. Name, I/C number and other personal information
Event Impact Please choose one event impact from the following: Financial Impact - There is an actual or potential financial loss Non-Financial Impact – No loss amount involved but has an impact on reputation, non-compliance etc. Both Financial and Non-Financial – as defined above
Financial Impact REs must select one: >> Events For Event for Banking Event for Insurance & Takaful Operator
Financial Impact >> Banking >> Events For REs must identify whether the operational loss event have boundary implications in accordance with Appendix 5
Issued on: 25 February 2021 Page 25 of 94
Data fields Description If the loss event is identified as a boundary event, REs must categorise either as Credit Risk or Market Risk related
Financial Impact >>Insurance &Takaful Operator >> Events For REs must identify the insurance category impacted from: Assets Claims Premium Re-insurance Intermediaries Others
Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported
Actual Loss / REs to record the actual loss / recovery Recoveries amount incurred to the following categories: Reporting Entity^ Customer^^ 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, the recovered amount must be recorded in the ‘Recovery Amount’ field
(Note: ^ Please input the date of write-off or provision recognised in P&L in the “Comments” column. ^^ Please input the loss amount borne or partially borne by the customer)
Non-Financial Please choose either: >>Impact Low / Medium / High
Non-Financial The detailed description of the non-financial >> Comments impact must be provided to justify the selection of Low / Medium / High
“>>” represents sub-data fields
Issued on: 25 February 2021 Page 26 of 94
APPENDIX 4 BDSF event reporting requirements
1. BDSF is an event or a series of events related to business disruptions or system failures.
2. FIs must report all actual critical BDSF events to ORION in accordance with the requirements set out in Table 6: BDSF event reporting types within 2 working days of event confirmation regardless of whether the events are translated into a financial / non-financial impact.
Table 6: BDSF event reporting types Category Definition Critical Any business disruption of LoD 1 event involving failure BDSF at main branch or processing hub irrespective of event breaching or not breaching MTD timeline including network. Any business disruption of LoD 26 and above irrespective of breaching or not breaching MTD timeline including network. Any system failure or system execution failure occurred at REs or outsourced service provider affecting the critical business functions or systems irrespective of breaching or not breaching RTO timeline. The minimum critical business functions or systems are set out in the FAQ No. 61. Any acceptance of counterfeit Malaysian currency notes by deposit-accepting SST.
3. A BDSF event may affect several lines of business. FIs must select only one line of business which is most affected by the incident. Some factors that could be taken into account to determine the business line includes (based on priority sequence): (a) If the core banking system (deposit) or core insurance system (underwriting and claims processing) is one of the systems affected, this is always the priority above other systems. To also indicate channels such as ATM or Internet if they are also affected; (b) Materiality of the impact (financial and non-financial); (c) Criticality of the business / service / system; (d) Transaction volume processed by the system and availability of manual workaround processes; and (e) Duration of system downtime (in cases where systems are recovered in phases)
6 LoD 2 – affect a number of branches or departments. Probability of exceeding MTD/RTO is moderate.
Issued on: 25 February 2021 Page 27 of 94
APPENDIX 5 Boundary event reporting requirements
1. A boundary event is a loss event that has both operational risk and credit or market risk components. REs must identify events that incur operational losses with credit or market risk implications and report these as boundary events.
Credit related operational risk event
2. A boundary event with credit risk components is a loss event resulting from operational risk events or failures that led to credit risk implications. This type of event is treated as credit risk loss and is therefore excluded from operational risk capital charge. However, REs must report the event in ORION and flag this as Credit Risk Boundary Event.
Example: Event type: External fraud >> Theft & fraud >> Fraudulent application by banking products / facilities >> Boundary event: Credit risk.
A customer has deliberately overstated his income, subsequently provided misleading credit exposure and resulted in loan credit approval. The customer later defaulted as he was unable to service his loan. Fraud is an operational event and default is a credit risk event.
Market related operational risk event
3. A boundary event with market risk components is a loss event resulting from operational risk events or failures, but has market risk implications. This type of event is treated as operational risk loss and is therefore subject to operational risk capital charge. REs must report the event in ORION and flag this as a Market Risk Boundary Event.
Example: Event type: Execution delivery & process management >> Transaction capture, execution & maintenance >> Data entry, maintenance or loading >> Boundary event: Market risk.
A desk dealer transacts a Spot FX trade. The trader input a transaction as “sell” MYR 20 Million against USD when it should have been “buy”. When the trader realised the erroneous input, the exchange rate between MYR and USD has moved against the trader. In this scenario, the error made by the dealer is an operational error. However, the loss incurred was due to market movements and hence has market risk implications.
Issued on: 25 February 2021 Page 28 of 94
APPENDIX 6 Customer information breaches reporting requirements
1. Reporting of customer information breaches must be done in line with the requirements stipulated in Management of Customer Information and Permitted Disclosures policy document issued by the Bank on 17 October 2017.
2. The reporting as ‘Actual Loss’ to ORION must be done within 1 working day upon tabling report to the Board with the summary of the event including the modus operandi involved, the root cause(s) of the customer information breach and the number of customers affected.
Reporting customer information breaches in ORION
3. Customer information breaches in Financial Institutions
Category: Customer information breaches Event Classification: Actual Loss
Data fields Description Reporting Entity To select the respective reporting entity for Name operational loss events
Event Actual Loss Classification Nature of Event New - New type of MO that impacted the REs for the first time. Repeated - MO that has occurred previously at REs
Refer to FAQ No. 35.
Islamic Business (√) – If the operational risk event is relating to Islamic business or product
Loss Event Name Clear and concise name that reflects an overall summary and nature of the loss event
Business Lines Must be reported up to Level 3 in accordance with the taxonomy in Appendix 12
Products / Please choose where applicable Services Delivery Channel Please choose where applicable
Event Category Please categorise the customer information breach event as follows:
Level 1: Client, products and business practices Level 2: Suitability, disclosure and fiduciary Level 3: Breach of Privacy
Issued on: 25 February 2021 Page 29 of 94
Data fields Description Causal Category Must be reported up to Level 3 in accordance with the taxonomy in Appendix 14
Date of The date that the event took place Occurrence Date of Detection The date of event confirmation is obtained
Loss Event An executive summary of the loss event and shall Description include the following details: (a) Chronology of the loss event Where the event took place How the event occurred The modus operandi involved The categories of parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.) Number of customers affected by the event Number of business lines affected The root cause of the customer information breach
(b) Progressive update of the event post-reporting to ORION
The executive summary must not include customer / individual confidential information e.g. Name, I/C number, account number and other personal information
Event Impact Please choose one event impact from the following: Financial Impact - There is an actual or potential financial loss Non-Financial Impact – No loss amount involved but has impact on reputation, non- compliance etc. Both Financial and Non-Financial – as defined above.
Financial Impact Choose: Banking >> Events For REs must identify whether the operational loss event have boundary implications in accordance with Appendix 5
If the loss event is identified as a boundary event, REs must categorise either as Credit Risk or Market Risk related
Issued on: 25 February 2021 Page 30 of 94
Data fields Description Choose: Insurance and takaful operator
REs must identify the insurance category impacted from: Assets Claims Premium Re-insurance Intermediaries Others
Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported
Actual Loss / REs must record the actual loss / potential loss / Potential Loss / recovery amount incurred to the following Recoveries categories: Reporting Entity^ Customer^^ 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
(Note: ^ Please input the date of write-off or provision recognised in P&L in the “Comments” column. ^^ Please input the loss amount borne or partially borne by the customer)
Non-Financial Please choose either: >>Impact Low / Medium / High
Non-Financial The detailed description of the non-financial >> Comments impact must be provided to justify the selection of Low / Medium / High
“>>” represents sub-data fields
Issued on: 25 February 2021 Page 31 of 94
4. Customer information breaches in Payment Instrument Issuers
Category: Customer information breaches Event Classification: Actual Loss
Data fields Description Reporting Entity To select the respective reporting entity for Name operational loss events
Event Classification Actual Loss
Nature of Event New - New type of MO that impacted the REs for the first time. Repeated - MO that has occurred previously at REs
Refer to FAQ No. 35.
Loss Event Name Clear and concise name that reflects an overall summary and nature of the loss event
Event Category Please categorise the customer information breach event as follows:
Level 1: Client, products and business practices
Date of Occurrence The date that the event took place
Date of Detection The date of event confirmation is obtained
Loss Event An executive summary of the loss event and Description shall include the following details: (a) Chronology of the loss event Where the event took place How the event occurred The modus operandi involved The categories of parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.) Number of customers affected by the event Number of business lines affected The root cause of the customer information breach
(b) Progressive update of the event post- reporting to ORION
The executive summary must not include customer / individual confidential information
Issued on: 25 February 2021 Page 32 of 94
Data fields Description e.g. Name, I/C number and other personal information Event Impact Please choose one event impact from the following: Financial Impact - There is an actual or potential financial loss Non-Financial Impact – No loss amount involved but has impact on reputation, non- compliance etc. Both Financial and Non-Financial – as defined above
Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported
Actual Loss / REs must record the actual loss / potential loss Potential Loss / / recovery amount incurred to the following Recoveries categories: Reporting Entity^ Customer^^ 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
(Note: ^ Please input the date of write-off or provision recognised in P&L in the “Comments” column. ^^ Please input the loss amount borne or partially borne by the customer)
Non-Financial Please choose either: >>Impact Low / Medium / High
Non-Financial The detailed description of the non-financial >> Comments impact must be provided to justify the selection of Low / Medium / High
“>>” represents sub-data fields
Issued on: 25 February 2021 Page 33 of 94
APPENDIX 7 Insurance-related event reporting requirements
Insurance / Takaful Fraud
1. Insurance / Takaful fraud occurs when someone knowingly lies to obtain some benefit or advantage to which he / she is otherwise not entitled or someone knowingly lies to deny some benefit that is due and to which another person is entitled. The main motive for committing the insurance / takaful fraud (i.e. in the form of premiums / contributions and claims fraud) is to attain financial gain.
2. Insurance / takaful fraud can be in the form of: (a) Internal fraud Fraud against the insurer / takaful operator committed by an employee or director whether on his / her own or in collusion with other parties which are internal or external to the insurer / takaful operator.
(b) External fraud Fraud against the insurer / takaful operator committed by other than an employee or director of the insurer / takaful operator, such as the policyholder / participant, third party claimant, outsourced service provider, medical provider, beneficiary, workshop, supplier and contractor in the purchase and / or execution of an insurance policy / takaful contract.
3. Fraud committed by intermediaries such as an agent, loss adjuster or broker must be classified under external fraud, unless the fraud is committed in collusion with an employee or director of the insurer / takaful operator. In such a case, the collusion must be reported as internal fraud.
4. The severity of fraud can range from slightly exaggerating claims to deliberately causing accidents or damages in order to file for claims. The most common form of fraud is to obtain lower premiums / contributions, misappropriation of insurance premiums / contributions and to obtain wrongful financial gain through inflated or fictitious claims. In this regard, fraud can be classified as either hard fraud or soft fraud: (a) Hard fraud occurs when a policyholder / participant / claimant deliberately plans or invents a loss, such as a collision, motor theft, or fire that is covered by the insurance policy / takaful contract in order to receive payment for damages. This includes false claims, where the damages claimed actually did not occur; and
(b) Soft fraud, which is far more common than hard fraud, is sometimes also referred to as opportunistic fraud. This type of fraud is where policyholder / participant / claimant exaggerates an otherwise legitimate claim. For example, when involved in a collision, an insured / participant may claim a higher amount compared to the actual cost of damages.
Issued on: 25 February 2021 Page 34 of 94
5. Examples of situations which may indicate fraud is about to be, has been or is being committed includes: (a) Making a false entry, omitting, altering, concealing, destroying or causing to omit, alter, conceal or destroy any entry in respect to the documents of an insurer / takaful operator; (b) Receiving a proposal for insurance / takaful contract or collecting premium / contributions, on a group policy / takaful contract if it has expired or has been cancelled by the insurer / takaful operator; (c) Forging, making use of or holding a false document, purporting to be a policy of an insurer / takaful operator; (d) Altering an entry made in a policy of an insurer / takaful operator; or (e) Issuing / using a policy / takaful contract which is false or incorrect, wholly or partly, or misleading
6. To perpetrate the fraud, documents may be forged or tampered with and this may include the following examples: (a) Unauthorised signature for underwriting and claims approvals; (b) Unauthorised issuance and / or tempering of Cover Notes; (c) Incomplete or non-disclosure of material facts in the proposal forms; (d) Wordings against and / or certificates of insurance / takaful contract; (e) Fake / tempered policy document / takaful contract, policy schedule, claims documents or reports.
7. Paragraphs 5 & 6 contain fraud illustrations as a guide to insurers and takaful operators. While insurance / takaful fraud can take place in various forms with different modus operandi, insurers and takaful operators shall be aware of and must be able to identify other scenarios which indicate that fraud is about to be, is being or has been committed.
Premium / Contribution Fraud
8. Premium / contribution fraud occurs when someone intentionally conceals or misrepresents information when obtaining insurance / takaful coverage, knowing that it would influence the insurance / takaful contract and premium / contribution calculation.
9. However, premium/contribution fraud goes beyond the above definition as illustrated below: (a) Avoid paying equitable premium / contribution for risk proposed to be assumed (Premium Avoidance): When obtaining a new insurance policy / takaful contract, an individual fraudulently misrepresents previous or existing conditions in order to obtain a lower premium/contribution on his / her insurance policy / takaful contract. For example, he / she may not disclose previous claims experience or health condition which would have resulted in higher premium / contribution charged.
(b) Siphoning of premium / contribution monies: This is also known as misappropriation of premium / contribution. This occurs when the employee of insurer, agent or broker on his/her own; or in collaboration with another party pockets the
Issued on: 25 February 2021 Page 35 of 94
premiums / contributions which have been paid and does not remit them to the insurer / takaful operator. The fraudster may also: (iii) Issue a forged cover note or policy / takaful contract; or (iv) Write off outstanding agents’ balances as bad debts via issuance of credit endorsements to cancel policies / takaful contracts after they have expired.
(c) “Bogus insurer / takaful operator”: This type of fraud occurs when an entity or person who holds out to be a branch or representative office of a licensed insurer or takaful operator or impersonates as a licensed insurer or takaful operator. Although premium / contribution may be paid by the policyholder / participant, the insurance policy / takaful contract is worthless.
(d) “Kick-backs”: An employee receives “kick-backs” by recording the premium / contribution of a “walk-in” customer under “agency” and receives a share of the commission, of which he / she is actually not entitled. In other instances, this may be done through the creation of a “fictitious” agency which is actually owned by the employee to earn commission.
(e) Dual premium / contribution charges or inflated premium / contribution: The premium / contribution stated in the policy schedule / takaful contract or debit note is lower than the premium / contribution paid. The difference is pocketed by the employee, agent or broker. For example, premium / contribution rates stated in the debit note and payment receipt issued by insurer / takaful operator is lower than the billing note issued by employee, agent or broker where premium / contribution payment is paid in cash. Normally this type of fraud is discovered when insured / participant complains or queries on the differences between the amounts stated in the insurers / takaful operator’s debit note or policy schedule and the actual premium / contribution paid.
Fraudulent Claim
10. Fraudulent claim includes staged or planned accidents, submitting false claim for a loss which has not occurred, faking death or committing an act of arson to collect insurance money, overstating insurance claims to reap profits for personal gain, false reporting to enable claimant to make a claim under a policy which otherwise is not covered, for example, falsifying the date or circumstances of an accident.
11. Fraudulent claim can be perpetrated by an insured / participant, a third party claimant, crime syndicate either on his / her own or in collusion with an employee(s) of an insurer, service provider, an agent and loss adjuster. For example a loss adjuster may exaggerate the quantum of loss or submit misleading, fabricated or untruthful loss report to the insurer / takaful
Issued on: 25 February 2021 Page 36 of 94
operator. Collaborators to fraudulent claim may either be given a share of the claim benefit or receive some form of kickbacks or bribery. (a) Past posting (Back dating of cover notes / policy period): This happens when an insured/participant who is involved in a motor accident, a victim of a car theft or whose property was damaged, has no insurance / takaful coverage. The insured / participant may decide to take a chance at "past-posting" insurance / takaful contract coverage by creating an elaborate scheme of events including tempering, falsifying or faking claim documents to prove that the policy / takaful contract is in force at the time of the loss.
(b) Deliberate act of arson: This happens when an owner of a property/vehicle, or someone hired by an owner, deliberately burns a property/vehicle to make a claim.
(c) Fictitious or falsified claim: This type of fraud occurs when a fraudster makes a claim for a loss that never took place. Example under this classification includes claiming for non-existent injuries or damage to property.
(d) Exaggerated or inflated claim (Overstating the Amount of Loss): A real loss has occurred, but a third party claimant (e.g. motor workshop) may take the opportunity to incorporate previous minor damages to the vehicle into the repair bill associated with the “real accident” to reap additional profits. The inflated claim is also intended to reap gains for the policyholder / participant, and in some instances to compensate for the “excess” or “deductible” stipulated in the insurance / takaful contract.
(e) Multiple claims (Multiple Policies for Profit): A fraudster buys numerous insurance policies / takaful contracts on a same property, normally with various insurers / takaful operators and then intentionally damages or destroys the property. Subsequently, the fraudster will claim on all the policies / takaful contracts.
(f) Staged accident through organised crime syndicate: These are planned accidents normally orchestrated by organised crime syndicate. Accidents are usually pre-planned manoeuvres which involved self-inflicted accidents and at times, involving an innocent party. Examples of staged accident are: (i) “Swoop and Squat”: Innocent victims are targeted by organised auto accident rings. These rings orchestrate an accident by using pre-planned manoeuvres to set the innocent party up for a rear end collision. (ii) “Paper Accident”: Organised rings actively solicit others to participate in the creation of accidents that only exist on paper. No innocent parties are involved in this type of staged accident.
Issued on: 25 February 2021 Page 37 of 94
(g) Disguised suicide: An insured / participant commits suicide and disguises it as an accident to enable people close to him to benefit from his personal accident insurance / contract. Such action may also constitute fraud in life insurance i.e. where the usual waiting period applying to suicide in a life insurance policy has not yet elapsed.
(h) Faked death: A fraudster will take out a life insurance policy / family takaful contract on himself and make his spouse the beneficiary. A warning sign might be if a spouse or other family member suddenly asks a person to buy or increase life insurance / family takaful coverage. After the policy / takaful contract has been in effect for several months, the fraudster fakes his death and his spouse is paid the death benefit. In the case of faked death, the fraud may be committed in two ways i.e. presenting to the insurer / takaful operator with the body of a stranger which has been made unrecognisable or claiming the insured/participant has died but for some reason the body cannot be found or produced.
(i) Falsified beneficiary: Someone other than the policyholder / participant takes control of the insurance policy / family takaful contract and changes the beneficiary through "nefarious” means.
(j) Medical and Health insurance fraud: Health insurance fraud is described as an intentional act of deceiving, concealing, or misrepresenting information that results in health care benefits being paid to an individual or group. The most common perpetrators of healthcare insurance fraud are health care providers. Examples of medical and health fraud are: (i) Billing for services not provided; (ii) Billing for service which is more expensive than what was actually provided; (iii) Providing and billing for unnecessary services while representing that such services were necessary; and (iv) Fake disability claim, including submission of forged documents to be eligible for a disability claim.
(k) Fraudulent workmen’s compensation claim: This type of fraud is committed with the intent to obtain some benefit or advantage to which the claimant is otherwise not entitled. Examples of fraud committed under the workmen compensation insurance / contract are: (i) Working while collecting workmen' compensation benefits; (ii) Faking injury; (iii) Claiming to be injured at work when injury occurred elsewhere; and (iv) Intentionally misclassifying employees’ job codes.
Issued on: 25 February 2021 Page 38 of 94
APPENDIX 8 SNC event reporting requirements
1. FIs must submit both potential and actual SNC events to ORION in accordance with the requirements and timeline set out in Table 2: Reporting types and timelines.
2. Submission of both potential and actual SNC reports represents an official attestation by the FIs based on the business operations and activities conducted. The officer-in-charge of respective FIs shall be prepared to respond to any query from the Bank as to the details of their submission.
Shariah Committee (SC)
3. The FI’s SC must make decision on events tabled whether it is SNC or non-SNC. This decision must be clearly reflected in the SC’s meeting minutes.
4. The event classification of “Actual” or “Potential” is not under the purview of the SC.
Islamic contracts
5. In relation to the definition of specific Shariah contracts, please refer to the respective policy documents on Shariah contracts issued by the Bank.
Potential SNC event
6. A potential SNC event is defined as any SNC event detected and confirmed by an officer within the control function but pending decision by the SC. Please refer to ORION FAQs No. 71.
7. The FIs must report any potential SNC event to ORION within 1 working day upon confirmation by an officer within the control function. Please refer to Table 2: Reporting types and timelines.
8. The event must be tabled at the SC meeting within 14 working days of the event confirmation by an officer within the control function.
9. In the event where there is no SC meeting that will be held within the 14- day period, FIs are required to conduct an ad-hoc SC meeting (may consist of the minimum required quorum) specifically to deliberate on the matter.
10. Where there is no submission of potential SNC event by the FIs for any particular period, this is deemed as a declaration that there is no occurrence of potential SNC events at the FIs during the period.
Actual SNC event
11. Actual SNC event is defined as any SNC event that has been confirmed by the FI’s SC. Please refer to ORION FAQ No. 71.
Issued on: 25 February 2021 Page 39 of 94
12. The FIs must report any actual SNC event to ORION within 1 working day from the SC’s confirmation date. Please refer to Table 2: Reporting types and timelines.
13. The FIs must submit to ORION a rectification plan as approved by the Board and the SC within 30 calendar days from the reporting date of actual SNC to the Bank.
14. In the event where there is no Board meeting that will be held within the 30-day period, FIs must conduct an ad-hoc Board meeting (may consist of the minimum required quorum) to obtain the Board’s approval on the rectification plan prior to submission to the Bank.
15. FI must take appropriate remedial rectification measures or follow up to resolve actual SNC and control mechanism to avoid recurrences. Latest facts and actions taken on the case must be updated in ORION.
Determining loss from SNC event
16. In determining the actual loss arising from SNC incidents, the following operational risk impact may serve as a basis in deriving the loss:
(a) Legal liability – Judgments, settlements and other legal costs; (b) Regulatory and compliance – fines or the direct cost of any other regulatory penalties. For example, the regulatory fine as stipulated in Section 28(5) of IFSA; (c) Restitution – Payments to third parties on account of operational losses for which the bank is legally responsible; (d) Loss of recourse - Losses experienced when a third party does not meet its obligations to the FIs; (e) Write-downs – Direct reduction in value of assets due to theft, fraud, unauthorised activity or market and credit losses arising as a result of SNC incidents; and (f) Direct purification of income – amount of income that needs to be purified either by channeling it to charity or any other manners as prescribed by the SC.
SNC KRIs
17. FIs must submit on a monthly basis to the Bank the following leading KRIs pertaining to SNC aspects arising from their business operations and activities:
(a) Litigation Any business cases that are currently under litigation that may have potential SNC implications. These include counter-suit by customers claiming the contract is executed not in accordance with Shariah requirement.
Issued on: 25 February 2021 Page 40 of 94
(b) Complaints Any complaints that have been lodged by customers pertaining to Shariah compliance aspects of Islamic contracts (including transparency and proper implementation of Islamic contracts by FIs.
Reporting SNC event in ORION
18. In addition to the general reporting requirements specified in Appendix 2: Operational risk event reporting requirements, SNC related events must be reported by REs in accordance with Table 7: SNC Specific data fields.
Table 7: SNC specific data fields Data item Description Event Actual Loss – Any SNC event that has been Classification confirmed by the FI’s SC as SNC Potential Loss – any SNC event detected and confirmed by an officer within the control function but pending decision by the SC
(Note: The event classification above is not referring to the status of financial impact resulted from the SNC event) Refer to FAQ No. 71.
Shariah Non- FIs must select one: Compliance (a) Yes Event reported as ‘actual’ SNC or ‘potential’ SNC (b) No Event classified as non-SNC
In the event where the SC has decided that the event is non-SNC event, FIs are required to amend in ORION the SNC field from “Yes” to “No”. The event needs to be reassessed whether it is to be considered under operational risk event
Shariah Primary FIs must select only ONE primary Shariah contract Contract applied to the product
If there are several products involved in an event, FI must select more than one main Shariah contract according to the number of products involved
The option “Others (please specify)” is meant for transaction that does not involve any Shariah primary contract e.g. advertisement does not comply with Shariah, questionable sponsorship etc.
Issued on: 25 February 2021 Page 41 of 94
Data item Description (Note: In relation to the definition of specific Shariah contracts, please refer to the respective policy documents on Shariah contracts issued by BNM)
Shariah FIs must provide the type of secondary Shariah Supporting contract used under a particular Shariah primary Contracts contract (where applicable)
If the option “Others (please specify)” is selected, FIs must specify the specific contract used in the ‘Shariah Supporting Contract Comments’ field
(Note: In relation to the definition of specific Shariah contracts, please refer to the respective policy documents on Shariah Contracts issued by BNM)
Shariah Source FIs must report the source of detection of the of Detection potential and actual SNC e.g. Shariah Compliance Unit, Business Unit, etc.
SC Reporting The date the event was tabled to SC for decision Date
Board Reporting The date of tabling the rectification plan of an SNC Date event to the Board
Shariah Date Shariah resolution date endorsed by SC Resolved
No. of The number of accounts involved in a particular SNC Accounts event Involved
Shariah Entailing Shariah resolutions including the basis of Decision the decision on the SNC event. The decision made by SC must be distinctly documented in the minutes of the meeting
Actions Taken Entailing the rectification plan following SC’s decision. SNC rectification plan approved by the Board must be provided within 30-calendar days after the event has been reported to the Bank.
Concurrently, FIs must update ORION on the detailed rectifications and actions taken by FIs
Issued on: 25 February 2021 Page 42 of 94
Figure 1: Process flow for reporting SNC events
Issued on: 25 February 2021 Page 43 of 94
Examples of SNC event
18. Appropriate assessment has to be given in determining SNC events attributed to operational risk loss event types. These types of event may have potential SNC implications. The following examples are provided to illustrate reporting of SNC events: (a) Event Type:Internal fraud >> Theft and fraud >> Misappropriation of assets “When performing Shariah review on Takaful business based on Wakalah model, it is discovered that the Takaful agents have misappropriated the participants’ contribution to the Tabarru’ (donation) fund. Hence, the claims made by the participants are not able to be paid”.
Conclusion: The Takaful agent failed to channel the contribution to the donation fund. Therefore, this incident shall be reported under Internal Fraud operational risk loss event type with SNC implications since the Takaful agents did not perform the Wakalah contract as mandated by the Takaful participants.
(b) Event Type:Clients, products and business practices >> Selection, sponsorship and exposure>> Failure to investigate client per guidelines “During the course of Shariah review, it is discovered that Islamic corporate financing facility has been disbursed to corporate clients who involved in entertainment and tobacco-related industries. Further review revealed that there was no due diligence conducted on the business activities during credit approval process”.
Conclusion: The failure to investigate client per guidelines led to non-compliance with ruling issued by Shariah Advisory Council of Bank Negara Malaysia (BNM SAC) which prohibits the granting of financing to fund Shariah non-compliant business activities.
(c) Event type: External fraud >> Theft and fraud >> Forgery / counterfeit (cover notes, policy certificates, currency, cheque, security documents / identifcation documents “Credit Administration division failed to assess the authenticity of trade invoices supported by one trade finance customer upon processing financing disbursement. The case had been reported to commercial crime police as it also involved some FIs. Hence, the affected FIs need to recognise this actual loss”.
Conclusion: This incident may have Shariah concern as the subject matter i.e. the trade invoices are not genuine leading to non-existence of subject matter when performing the financing transaction. Therefore, it should be raised as a potential SNC event.
Issued on: 25 February 2021 Page 44 of 94
(d) Event type: Execution, delivery and process management >> Transaction capture, execution and maintenance >> Model / system mis-operation
“When processing financing disbursement to one corporate
customer, credit administration unit discovered that commitment
fees have been charged on the customer’s unutilised financing amount. The unit found out that errors in system-setting caused this incident”.
Conclusion: The errors in credit processing system caused the above potential SNC occurrence. Hence, this is against the ruling of BNM SAC which prohibits commitment fees to be charged on the unutilised financing amount.
(e) Event type: Damage to physical assets >> Natural disaster & Other losses >> Damage to islamic inventory
“Some FIs maintain commodity warehouse to facilitate financing transaction with customers. Nevertheless, when Shariah review team performed an on-site review, it is found that the commodity used in the financing transaction is of inferior quality due to improper maintenance of the warehouse. Further, it is found that the warehouse was affected by the recent flash flood caused by poor drainage system. The customer has been purchasing and selling commodity for financing transactions which is of lower quality and not as what have been specified in the Aqad process”.
Conclusion: This incident has led to potential SNC occurrence as the customers have transacted the inferior quality of commodity not as what has been stipulated in the Aqad process.
(f) Event type:Business disruption and system failures >> Systems >> Software-Inadequate system capacity “Claims department discovered that there was no segregation of funds between Takaful participants and Shareholders. This could disrupt Takaful business operations as the participants may dispute in the event of non-payment of claims and no surplus sharing between the Shareholders and the Takaful participants. There is a need to segregate the funds immediately to ensure smooth operations of the Takaful”.
Conclusion: This incident may lead to SNC as there is no proper channeling of participants’ contribution to Participant Risk Fund (PRF) which can be utilised in the event of mishap and claims
made by the participants.
Issued on: 25 February 2021 Page 45 of 94
APPENDIX 9 Payment-related fraud event reporting requirements
1. In line with the general reporting requirements specified in Appendix 2: Operational risk event reporting requirements, applicable REs must report all payment-related fraud events individually per transaction basis as listed in Table 8: Payment-related fraud types.
2. Particularly for payment Card fraud (credit card, charge card and debit card), REs must report based on the following requirements: (a) Card fraud with amount involved > RM5,000, REs must report the event individually per transaction basis. (b) Card fraud with amount involved ≤ RM5,000, REs must report the event on an aggregate basis as stipulated in Appendix 10 – Table 14: Aggregate reporting types and threshold. (c) Card fraud with new MO committed and impacted REs for the first time, REs must report the event individually per transaction basis.
Table 8: Payment-related fraud types Fraud Type of instruments REs responsible to report and channels fraud event in ORION Payment Credit card Card issuers Instruments Charge card Card issuers Debit card Card issuers E-money7 E-money issuers Cheque Issuing banks (Refer to FAQ No. 57.)
Payment Internet banking Internet banking offering channels (includes desktop banks banking) Mobile banking Mobile banking offering banks
Unauthorised ATM ATM acquirers cash withdrawal
Description of MO for payment-related fraud
3. The REs must refer to the detailed description of MO in Table 9 to Table 13 when reporting loss event arising from specific payment instruments or payment channels.
7 E-money comprises card-based and network-based e-money schemes. International brand prepaid card is categorised under card-based e-money scheme.
Issued on: 25 February 2021 Page 46 of 94
(a) Payment instrument: Credit card, debit card, charge card and card- based e-money schemes
Table 9: Card-related fraud MO MO Description Account Take Fraudster gains access to existing card account and Over use them to make fraudulent transactions. This could happen by making fraudulent card replacement request or false change of address request
Counterfeit Fraudsters copies data from the card (typically magnetic strip) and illegally reproduced or duplicate the card and make fraudulent transactions
Forged Fraudster applied for a card under the identity of Application another person and subsequently uses the card to make fraudulent transactions
Internet Card information obtained illegally and subsequently used to order goods or services through the internet
Authenticated (a) Authenticated internet transaction: Internet internet transaction that was authenticated by verifying transaction the cardholder's password
Unauthenticated (b) Unauthenticated internet transaction: Internet internet transaction where authentication was not transaction performed or could not be performed
Mail and Card information obtained illegally and subsequently Telephone used to order goods or services through telephone Order or mail
Loss or Stolen (a) Card is misplaced or lost (by accident or other means) and subsequently used fraudulently; or
(b) Card is stolen as a result of theft, burglary, robbery or other criminal means and used subsequently used fraudulently.
Wire Tapping Card information obtained illegally by tapping the telephone lines. The information is subsequently used to make fraudulent transactions
Non-Receipt Card is stolen from the issuer’s delivery system and subsequently used to make fraudulent transactions
Issued on: 25 February 2021 Page 47 of 94
(b) Payment instrument: Network-based e-money scheme
Table 10: Network based e-money scheme MO MO Description Lost or stolen (a) Mobile phone is either misplaced or lost (by mobile devices accident or other means) and subsequently used fraudulently
(b) Mobile phone is stolen as a result of theft, burglary, robbery or other criminal means and used fraudulently
Stolen or Login credentials obtained illegally, such as via compromised e-mail and short message services (SMS) and login credentials subsequently used to access the e-money account of the genuine owner to make payment for goods or services or to transfer fund
Wire tapping Account information obtained illegally by tapping the telephone lines and then used to make fraudulent transactions
Illegal e-money Manipulation of e-money balance / illegally value reload or top-up by fraudster so that the account (also applicable to appears to have a greater monetary value than card-based e- the amount actually paid by the user money scheme)
(c) Payment instrument: Cheque
Table 11: Cheque fraud MO MO Description Cloning A wholly fabricated cheque or duplicated copy of a genuine cheque.
Forgery A genuine cheque issued without obtaining proper authorisation from the cheque owner, using forged signature.
Alteration A genuine cheque of which its details are illegally altered.
Issued on: 25 February 2021 Page 48 of 94
(d) Payment channel: Internet banking fraud
Any fraudulent transactions performed by a third party via internet banking services offered by the REs (including access to internet web browser using mobile devices). Cases whereby beneficiary accounts or mule accounts are maintained at REs shall be excluded. Any other scams involving customers transferring funds willingly via various social engineering, not classified as an unauthorised transaction (e.g. love scam and telephone scam) must not be captured in this report.
Table 12: Internet banking fraud MO MO Description Phishing A method used by fraudsters to access valuable Email personal information such as username, PIN and SMS passwords by sending 'spoofed' e-mail messages, Telephone sending messages via short messaging service (SMS), making telephone calls etc. to lure customers into divulging such information. This information will be used to conduct unauthorised internet banking transactions
Fraudsters may: a) Copy legitimate logos or message formats with links to direct customers to fake internet banking websites that are convincing replicas of the banks’ genuine internet banking websites; and/or
b) Direct customers to update or register mobile phone number via automated teller machine (ATM) to obtain transaction authorisation codes (TACs) for the completion of unauthorised internet banking transactions
Others: REs must specify the fraud MO in the loss event description field:
Malware Malicious software installed unknowingly in customers’ computer / mobile phone / other devices to ultimately obtain internet banking credentials or TACs to conduct unauthorised internet banking transactions
SIM Card Fraudster impersonating the customer at mobile Hijack service provider, to replace the SIM card of registered mobile number to receive TACs in order to conduct unauthorised internet banking transactions
Issued on: 25 February 2021 Page 49 of 94
MO Description Unauthorised Fraudster used stolen customer credentials for the Internet registration of new internet banking profile to Banking conduct unauthorised internet banking transactions Transaction
Browser Fraudster used links on search engine results to redirect direct customers to fake internet banking websites to conduct unauthorised internet banking transactions Other new MO Please provide details of the MO
(e) Payment channel: Mobile banking fraud
Any fraudulent transactions performed by a third party through a mobile device via mobile banking applications (including but not limited to, SMS and Unstructured Supplementary Service Data, USSD8 based banking platform) offered by the REs. Cases whereby beneficiary accounts or mule accounts are maintained at REs shall be excluded. Any other scams involving customers transferring funds willingly via various social engineering methods, not classified as an unauthorised transaction (e.g. love scam and telephone scam) must not be captured in this report. Table 13: Mobile banking fraud MO MO Description Phishing Customers are lured into divulging personal Email information such as username, PIN and passwords SMS to conduct unauthorised mobile banking transactions Telephone
Others: REs must specify the fraud modus operandi in the loss event description field:
Malware Malicious software installed unknowingly in customers’ computer / mobile phone / other devices to ultimately obtain mobile banking credentials or TACs to conduct unauthorised mobile banking transactions
Fraudster impersonating the customer at mobile SIM Card service provider, to replace the SIM card of Hijack registered mobile number to receive TACs in
order to conduct unauthorised mobile banking
transactions
8 USSD is a technology used by a GSM network to send information, usually text menu between a mobile phone and a system on the network.
Issued on: 25 February 2021 Page 50 of 94
MO Description
Unauthorised Fraudster used stolen customer credentials for Mobile the registration of new mobile banking profile to Banking conduct unauthorised mobile banking Transaction transactions
Other new MO Please provide details of the modus operandi
Reporting payment-related fraud in ORION
4. Payment-related fraud
Category: 1. Card related fraud with amount involved > RM 5,000 2. New MO Event Classification: Actual loss, potential loss and near miss
Data fields Description Reporting Entity Name To select the respective reporting entity for operational loss events
Event Classification Operational risk events must be classified as either one of the following: Actual loss Potential loss Near miss
Nature of Event New - New type of MO that impacted the REs for the first time. Repeated - MO that has occurred previously at REs
Refer to FAQ No. 35.
Islamic Business (√) – If the operational risk event is relating to Islamic business or product
Loss Event Name Clear and concise name that reflects an overall summary and nature of the loss event
Business Lines Must be reported up to Level 3 (banking) in accordance with the taxonomy in Appendix 12
Products / Services Please choose where applicable
Delivery Channel Please choose where applicable
Event Category Must be reported up to Level 3 in accordance with the taxonomy in Appendix 13
Issued on: 25 February 2021 Page 51 of 94
Data fields Description Causal Category Must be reported up to Level 3 in accordance with the taxonomy in Appendix 14
Date of Occurrence The date that the event took place
Date of Detection The date of event confirmation is obtained
Loss Event Description An executive summary of the loss event and must include the following details: (a) Chronology of the loss event Where the event took place How the event occurred The modus operandi involved Parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.) The root cause of the event (b) Remedial actions to resolve the event (c) Mitigating action plans to prevent recurrence of similar incident in the future (d) Indication of timeline when the event can be resolved (e) Progressive update of the event post- reporting to ORION
The executive summary must not include customer / individual confidential information e.g. Name, I/C Number and other personal information
Event Impact Please choose one event impact from the following: Financial Impact - There is an actual or potential financial loss Non-Financial Impact – No loss amount involved but has impact on reputation, non- compliance etc. Both Financial and Non-Financial – as defined above
Financial Impact RE must select whichever applicable: >> Events For Event for ATM Acquirer Event for Payment Instrument Event for Payment Channel
Financial Impact >> ATM Acquirer >> Events For >> Payment instrument REs must select whichever applicable: Credit Card
Issued on: 25 February 2021 Page 52 of 94
Data fields Description Debit Card Charge Card
>> Card brands REs must select whichever applicable: Credit card & Charge card: Visa MasterCard AMEX CUP Diners Other (please specify) Debit card International debit card – Visa International debit card – MasterCard International debit card – Others (please specify) E-Debit (Domestic debit, MyDebit) Combo (Co-badge card9)
Financial Impact >>Payment instrument >> Events For REs must select whichever applicable: Cheque Credit Card Debit Card Charge Card E-Money
>>Payment Instrument >>Cheque
>> Cheque Modus operandi - REs must select whichever applicable: Cloning Forgery Alteration Others (please specify) Source of detection – REs must select whichever applicable: Detected by collecting bank Detected by issuing bank Detected by customers Others (please specify)
9 A co-badged card is a card with two payment brand applications (e.g. MyDebit and Visa) that can be used for purchases at point-of-sales (POS) terminals.
Issued on: 25 February 2021 Page 53 of 94
Data fields Description Types of cheque issuers - REs must select whichever applicable: Individual Corporate Government Others (please specify) >>Payment Instrument >> Credit card; >> Debit card; >> Credit card >> Charge card; and >> Debit card >> E-money >> Charge card >> E-money Card brands - REs must select whichever applicable:
Credit card & Charge card: Visa MasterCard AMEX CUP Diners Other (please specify) Debit card International debit card – Visa International debit card – MasterCard International debit card – Others (please specify) E-Debit (Domestic debit, MyDebit) Combo (Co-badge card) E-money Card-based – Proprietary prepaid card Card-based – International prepaid card – Visa Card-based – International prepaid card – MasterCard Card-based – International prepaid card – Others (please specify) Card types - REs must select whichever applicable: Magnetic Stripe Chip Chip and PIN Contactless Others (please specify)
Issued on: 25 February 2021 Page 54 of 94
Data fields Description Business activity - REs must select whichever applicable : Airlines or Air carriers Travel agencies and tour operators Telecommunication equipment including telephone sales Utilities (electric / gas / water / sanitation) Department stores Grocery stores and supermarkets Miscellaneous food stores Automotive parts stores Service stations Automated fuel dispensers Electronic sales Eating places / restaurants Bars / taverns / lounge / discos / night clubs Jewellery / watch / clock / silverware stores Direct marketing including insurance service / travel arrangement services / Telemarketing merchants / Subscription merchants Insurance sales or underwriting and premiums Lodging / hotels / motels / resorts Professional services Unauthorised cash withdrawals Others (please specify) Modus operandi - REs must select whichever applicable:
Credit card, Debit card and Charge card Account takeover Counterfeit – credit master Counterfeit – skimming Counterfeit – white plastic Forged application Internet – authenticated internet transaction Internet - unauthenticated internet transaction Loss or stolen Mail and telephone order Wire tapping Non-receipt Other (please specify)
Issued on: 25 February 2021 Page 55 of 94
Data fields Description E-money Card-based – Account takeover Card-based – Counterfeit – Credit Master Card-based – Counterfeit – skimming Card-based – Counterfeit – white plastic Card-based – Forged application Card-based – Internet – authenticated internet transaction Card-based – Internet - unauthenticated internet transaction Card-based – Loss or stolen Card-based – Mail and telephone order Card-based – Wire tapping Card-based – Non-receipt Card-based – Illegal E-money value Card-based – Other (please specify) Network-based – Loss or stolen mobile devices Network-based – stolen or compromised login credentials Network-based – Wire tapping Network-based – Illegal E-money value Network-based – Other (please specify)
Financial Impact >> Payment channel >> Event For REs must select whichever applicable: Internet Banking Mobile Banking
>>Payment Channel >>Internet Banking >>Mobile Banking
>> Internet Banking Account type - REs must select whichever >> Mobile Banking applicable:
Internet Banking & Mobile Banking: Individual Corporate Others (please specify) Modus operandi - REs must select whichever applicable: Internet Banking & Mobile Banking: Phishing - Email Phishing – SMS Phishing – Telephone Others (please specify)
Issued on: 25 February 2021 Page 56 of 94
Data fields Description Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported
Financial Impact (for REs must record the actual loss / potential loss Banking, ATM Acquirer / recovery amount incurred according to the and Payment Channel) following categories: >> Actual Loss / Reporting Entity^ Potential Loss / Customer^^ Recoveries 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
(Note: ^ Please input the date of write-off or provision recognised in P&L in the “Comments” column. ^^ Please input the loss amount borne or partially borne by the customer)
Financial Impact (for REs must record the loss amount incurred Payment Instrument) according to the following categories: >> Loss Incurred by Actual Loss and / or; Malaysian Recoveries and / or; Entities Potential Loss
Payment Instrument Payment card and e-money fraud: Card issuers; Cardholders; Acquirer / merchants; and Others
Cheque fraud: Collecting banks; Issuing banks; Customers; and Others
Please ensure the above selection is consistent with the “Event Classification” field above
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
Issued on: 25 February 2021 Page 57 of 94
Data fields Description Financial Impact (for REs must record the loss amount incurred by Payment Instrument) foreign entities according to the following >> Loss Incurred categories: by Foreign Actual Loss and / or; Entities Recoveries and / or; Potential Loss
Please ensure the above selection is consistent with the “Event Classification” field above
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
Actual Loss / Potential REs must record the actual loss / potential loss Loss / Recoveries / recovery amount incurred according to the following categories: Reporting Entity^ Customer^^ 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
(Note: ^ Please input the date of write-off or provision recognised in P&L in the “Comments” column. ^^ Please input the loss amount borne or partially borne by the customer)
Non-Financial Please choose either: >>Impact Low / Medium / High
Non-Financial The detailed description of the non-financial >> Comments impact must be provided to justify the selection of Low / Medium / High
“>>” represents sub-data fields
Issued on: 25 February 2021 Page 58 of 94
APPENDIX 10 Aggregate reporting requirements
1. REs must submit aggregate reporting to ORION in accordance with the requirements and timeline set out in Table 2: Reporting types and timelines.
2. REs must report aggregate events in accordance with the categories and threshold specified in Table 14: Aggregate reporting types and threshold.
3. Events with new MO and / or with amount that are above the threshold specified in Table 14, must NOT be aggregated and must be reported as a single event in ORION according to Appendix 2: Operational risk event reporting requirements.
Table 14: Aggregate reporting types and threshold Category Sub-category Aggregate Aggregate threshold submission to ORION Payment Aggregate by card Amount To submit: instrument types*: involved ≤ 1 event for ALL Credit card RM5,000 actual loss Charge card 1 event for ALL Debit card potential loss *Note: including card fraud 1 event for ALL committed overseas near miss
Actual Aggregate by event Actual loss To submit: loss types: ≤ RM1,000 1 event for events ≤ Internal fraud actual loss per RM 1,000 External fraud event type Employment practices and workspace safety Damage to physical assets Business disruption and system failure Clients, products and business practices Execution, delivery and process management
Issued on: 25 February 2021 Page 59 of 94
Category Sub-category Aggregate Aggregate threshold submission to ORION All Aggregate by event All actual To submit: physical types: loss 1 event for cash Clients, products and shortages at shortages business practices both branch Execution, delivery and vendor per and process event type management External fraud
Reporting aggregate events in ORION
4. Payment instrument - Card related fraud with amount involved ≤ RM 5,000
Category: Card related fraud with amount involved ≤ RM 5,000 Sub-Category: Aggregate by credit card, debit card and charge card Event Classification: Actual loss, potential loss or near miss
Data fields Description Reporting Entity Name To select the correct entity
Event Classification Please select one (where applicable): Actual Loss Potential Loss Near Miss
Nature of Event Repeated - MO that has occurred previously at REs
Islamic Business If reporting on behalf of Islamic Entity, please ‘√’
Loss Event Name Aggregate Credit Card* fraud (MM/YY) *interchangeable with Charge Card and Debit Card
Business Lines For credit card and charge card, please categorise the business line as follows: Level 1: Retail Banking Level 2: Card Services Level 3: Cards
For debit card, please categorise the business line as follows: Level 1: Retail Banking Level 2: Retail Banking
Issued on: 25 February 2021 Page 60 of 94
Data fields Description Level 3: Deposit
Products / Services Please select one (where applicable): Credit Card Debit Card Charge Card
Delivery Channel Please select: N/A
Event Category Please categorise the event as follows: Level 1: External Fraud Level 2: Theft & Fraud Level 3: Card Related Fraud
Causal Category Please categorise the causal as follows: Level 1: External Event Level 2: Others Level 3: Others
Please type ‘N/A’ in the comment box
Countries of Event Please select ‘Malaysia’
State of Events Please select any state
Districts of Events Please select any district
Date of Event Choose one date to represent the overall Occurrence & Date of events recorded in a particular month Detection Loss Event Description Please use this standard format for: Card-related fraud amount involved ≤ RM 5,000
1. Modus Operandi (MO)
MO Amount No. of cases Account take over x x Counterfeit … … Forged application … … Internet – Authenticated … … Internet – Unauthenticated … … Mail & Telephone Order … … Loss or Stolen … … Wire Tapping … … Non-Receipt … … ______TOTAL AMOUNT / CASE x x
2. Card Brand
Credit / Charge Card Amount No. of cases Visa x x MasterCard x x
Issued on: 25 February 2021 Page 61 of 94
Data fields Description AMEX … … CUP … … Diners … … Others … …
Debit Card Amount No. of cases International x x debit card - Visa International x x debit card - MasterCard International x x debit card - Others E-Debit x x (Domestic debit, MyDebit) Combo x x (Co-badge card)
3. Card Type
Credit / Charge Card Amount No. of cases / Debit card Magnetic stripe x x Chip x x Chip and PIN … … Contactless … … Others … …
Event Impact Select one from the list: Financial Non-financial Financial & Non-financial
Events For Select ‘Payment Instrument’
>> Payment Instruments Select one from the list (where applicable): Credit Card Debit Card Charge Card
>> Card Brands Select ‘N/A’ – to represent the overall incidents recorded in a particular month
>> Card Types Select ‘N/A’ – to represent the overall incidents recorded in a particular month
>> Business Activity Select ‘Others’ – to represent the overall incidents recorded in a particular month
Please type ‘N/A’ in the comment box
>> Modus Operandi Select ‘Others’ – to represent the overall incidents during the reporting month
Please type ‘N/A’ in the comment box
Issued on: 25 February 2021 Page 62 of 94
Data fields Description Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported Loss By Malaysian Input the total aggregated loss incurred Entities according to the specific categories provided: Reporting Entity / Issuer Cardholder / Customer Acquirer / Merchant Others
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
Loss By Foreign Entities Input the total aggregated loss incurred according to the specific categories provided. Foreign Entity
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field
“>>” represents sub-data fields
Issued on: 25 February 2021 Page 63 of 94
5. Actual loss events ≤ RM 1,000
Category: Actual loss events ≤ RM 1,000 Sub Category: Aggregate by Event Types Event Classification: Actual loss
Data fields Description Reporting Entity Name To select the correct entity
Event Classification only Actual Loss
Nature of Event Repeated - MO that has occurred previously at REs
Islamic Business If reporting on behalf of Islamic Entity, please ‘√’
Loss Event Name Aggregate loss below RM 1,000 (MM/YY)
Business Lines Since this is an aggregate report, please select the business lines that are mostly affected.
Must be reported up to Level 3 (banking) and Level 2 (insurance) in accordance with the taxonomy in Appendix 12
Products / Services Please select: N/A
Delivery Channel Please select: N/A
Event Category Level 1: Please select according to your submission: Internal Fraud External Fraud Employment Practices and Workspace Safety Damage to Physical Assets Business Disruption and System Failure Clients, Products and Business Practices Execution, Delivery and Process Management
Level 2: Since this is an aggregate report, please select the Event Types that are mostly relevant
Level 3: Since this is an aggregate report, please select the Event Types that are mostly relevant
Causal Category Since this is an aggregate report, please select the Causal Category that are mostly relevant.
Issued on: 25 February 2021 Page 64 of 94
Data fields Description Must be reported up to Level 3 in accordance with the taxonomy in Appendix 14
Countries of Event Please select ‘Malaysia’
State of Events Please select any state
Districts of Events Please select any district
Date of Event Select one date to represent the overall Occurrence & Date of incidents recorded in a particular month Detection
Loss Event Description Please use this standard format for: Actual loss events ≤ RM 1,000
Event Type Amount No. of No. of cases customers impacted Ext. Fraud X X X Damage to X X X Physical Assets TOTAL X X X *Note: this aggregate table formal is applicable to all seven operational risk event types
Event Impact Please select: Financial
Events For Please select one (where applicable): Banking Insurance & Takaful Operators
>> Banking >>> Boundary Event: No
>> Insurance & >>> Insurance category: Takaful Operators Please select: N/A
Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported
Loss By Banks The REs must input the total aggregated loss OR incurred according to the specific categories Loss By Insurance & provided: Takaful Operators Reporting Entity Customer 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field. “>>” represents sub-data fields
Issued on: 25 February 2021 Page 65 of 94
6. Physical cash shortages
Category: Banking OR Insurance & Takaful Operators Scope: Physical cash shortages at branch, over-the-counter and / or Vendor for offsite Self-Service Terminals (SST). Refer to FAQ No. 40. Event Classification: Actual loss
Data fields Description Reporting Entity Name To select the correct entity
Event Classification only Actual Loss
Nature of Event Repeated - MO that has occurred previously at REs Islamic Business If reporting on behalf of Islamic Entity, please ‘√’
Loss Event Name Physical Cash Shortage (MM/YY) Business Lines Banks; please select: Level 1: Retail Banking Level 2: Retail Banking Level 3: Deposits
Insurance & Takaful Operators; please select up to Level 2 (where applicable)
Products / Services Please select: N/A
Delivery Channel Please select: N/A
Event Category Please categorise the event as follows: For execution errors Level 1: EDPM Level 2: Transaction capture, execution & maintenance Level 3: Other Task miss-performance
1. For counterfeit notes accepted by Self-Service Terminals 2. Level 1: BDSF 3. Level 2: System 4. Level 3: Software - Application system bug / unpatched 5. 6. For counterfeit notes discovered through over- the-counter and during internal processing and/or by the outsourced service provider 7. Level 1: External Fraud 8. Level 2: Theft and fraud 9. Level 3: Forgery/ Counterfeit
10. For penalties on cash shortages / cash excess
Issued on: 25 February 2021 Page 66 of 94
Data fields Description 11. Level 1: CPBP 12. Level 2: Suitability, disclosure and fiduciary 13. Level 3: Fiduciary breaches/guideline violations
Causal Category Please select the Causal Category that are mostly relevant. Must be reported up to Level 3 in accordance with the taxonomy in Appendix 14
Date of Event Select one date to represent the overall incidents Occurrence & Date of recorded in a particular month Detection Loss Event Description Please use this standard format for: All physical cash shortages* at branch or offsite Self-Service Terminals (SSTs)
Cash Amount No. of No. of PDRM Serial No of shortage cases customers Report Number pieces impacted Number Branch SSTs X X X X X X Over-the- X X X X X X counter Offsite SSTs X X X X X X TOTAL X X X X *Note: including events where losses were absorbed by outsourced vendor
Event Impact Please select: Financial
Events For Select either: Banking Insurance & Takaful Operators
>> Banking >>> Boundary Event: No
>> Insurance & Takaful >>> Insurance category: Operators Please select: N/A
Amount Involved This field must have a value to reflect the overall financial amount associated with the operational risk event reported
Loss By Banks The REs must input the total aggregated loss OR incurred according to the specific categories Loss By Insurance & provided: Takaful Operators Reporting Entity Customer 3rd Party
The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field. Instead, recovered amount must be recorded in the ‘Recovery Amount’ field “>>” represents sub-data fields
Issued on: 25 February 2021 Page 67 of 94
APPENDIX 11 Overseas loss event reporting requirements
1. The REs must report all operational risk events occurred at foreign and offshore subsidiaries or branches of the REs which resulted in financial- related losses in accordance with the requirements and timelines set out in Table 2: Reporting types and timelines.
2. REs must report these losses in aggregate according to Table 15: Overseas loss event reporting requirements.
3. Events with amount that are above the threshold specified in Table 15, must NOT be aggregated and must be reported as a single event in ORION. Refer to FAQs No. 46 and 47.
Table 15: Overseas loss event reporting requirements Category Sub-category Amount Submission to ORION Overseas Event ≥ RM All actual To submit loss event losses 1mil financial individually loss
Aggregate by All actual To submit the loss event country for financial aggregated by country event < RM loss (1 event for ALL actual 1mil loss)
Reporting overseas operational risk events in ORION
4. Overseas operational risk events
Category: Overseas operational risk events Event Classification: Actual loss
Data fields Individual ≥ RM 1mil Aggregate < RM 1mil Reporting Entity To select the correct To select the correct Name entity entity
Event Only Actual Loss Only Actual loss Classification
Loss Event Name [Country name] [Country name] Overseas Losses Overseas Losses (MM/YY) (MM/YY)
Countries of Event Please select the Please select the ‘country’ involved ‘country’ involved
Loss Event (a) Chronology of the Please input ‘N/A’ Description loss event
Where the event took place
Issued on: 25 February 2021 Page 68 of 94
Data fields Individual ≥ RM 1mil Aggregate < RM 1mil How the event occurred The modus operandi involved Parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.) Number of customers affected by the event Number of business lines affected The root cause of the event
(b) Remedial actions to resolve the event (c) Mitigating action plans to prevent recurrence of similar incident in the future
Level 1 Business Please select the N/A – this is a Line relevant Business Line mandatory field, please select any from the list
Level 1 Event Please select the N/A - this is a Category relevant Event Type mandatory field, please select any from the list
No of Events Please input ‘1’ Count of loss events reported
Amount Involved This field must have a This field must have a value to reflect the value to reflect the overall financial amount overall financial amount associated with the associated with the operational risk event operational risk event reported reported
Net Actual Loss The REs must not use The REs must not use losses net of insurance losses net of insurance recoveries as an input to recoveries as an input to the ‘Actual Loss’ field. the ‘Actual Loss’ field.
Issued on: 25 February 2021 Page 69 of 94
Data fields Individual ≥ RM 1mil Aggregate < RM 1mil Instead, recovered Instead, recovered amount must be amount must be recorded in the recorded in the ‘Recovery Amount’ field ‘Recovery Amount’ field
Net Potential Loss Please input ‘0’ (zero) Please input ‘0’ (zero)
Add Row Link N/A Delete Row Link N/A Check box N/A
Issued on: 25 February 2021 Page 70 of 94
APPENDIX 12 Business lines taxonomy
1. The event must be assigned by REs to the business line category that most accurately describe the business that bears the loss.
2. Events impacting more than one business line must be mapped by REs to the most dominant, or the most suitable business line category.
Banking Business line Business Business line Product / Services level 1 line level 2 level 3 1. Commercial Corporate Trade Finance Export Finance Banking Banking Bills of Exchange LC or BA or TR Lending / Financing Project Finance Non-Individual Mortgage Non-Individual Hire Purchase TL or OD etc. Lending / Financing Factoring Leasing Deposits / Funding Current Account Fixed Deposit Savings
NID CP / MTN Guarantees Bank Guarantee Performance Guarantee Commercial Trade Finance Export Finance Banking Bills of Exchange LC or BA or TR Lending / Financing Project Finance Non-Individual Mortgage Non-Individual Hire Purchase TL or OD etc. Lending / Financing Factoring Leasing Deposits / Funding Current Account Fixed Deposit Savings NID CP / MTN
Issued on: 25 February 2021 Page 71 of 94
Business line Business Business line Product / Services level 1 line level 2 level 3 Guarantees Bank Guarantee Performance Guarantee SME Trade Finance Export Finance Bills of Exchange LC or BA or TR Lending / Financing Project Finance Non-Individual Mortgage Non-Individual Hire Purchase TL or OD etc. Lending / Financing Factoring Leasing Deposits / Funding Current Account Fixed Deposit Savings NID CP / MTN Guarantees Bank Guarantee Performance Guarantee 2. Retail Retail Mortgage Residential Banking Banking Non-Residential Personal Loan / Financing Hire Purchase Wealth Management Deposits Current Account Fixed Deposits Savings NID Structured Deposits Private Mortgage Residential Banking Non-Residential Personal Loan / Financing Hire Purchase Wealth Management Deposits Current Account Fixed Deposits Savings NID
Issued on: 25 February 2021 Page 72 of 94
Business line Business Business line Product / Services level 1 line level 2 level 3 Structured Deposits Card Cards Credit Card Services Debit Card Charge Card E Money Card Based Network Based 3. Trading and Treasury Fixed income Sales Equity Foreign exchanges Commodities Credit Funding Own position securities Lending and repos Brokerage Debt Prime brokerage Sales Fixed income Equity Foreign exchanges Commodities Credit Funding Own position securities Lending and repos Brokerage Debt Market Fixed income Making Equity Foreign exchanges Commodities Credit Funding Own position securities Lending and repos Brokerage Debt Prime brokerage Proprietary Fixed income Positions Equity Foreign exchanges Commodities Credit
Issued on: 25 February 2021 Page 73 of 94
Business line Business Business line Product / Services level 1 line level 2 level 3 Funding Own position securities Lending and repos Brokerage Debt Prime brokerage 4. Agency Custody Escrow Services Depository receipts Securities lending (customers) corporate actions Corporate Issuer and paying Agency agents Corporate Trust 5. Asset Discretionary Retail Management Fund Whole Sale Management Non- Retail Discretionary Whole Sale Fund Management 6. Payment Fund Interbank and Transfer Intrabank Settlement Local Remittances Overseas Note: Payment and Settlement losses Remittances related to a bank’s Payment & own activities would be incorporated in Collection the loss experience Clearing and of the respective affected eight Settlements Business Line 7. Corporate Advisory Equity Equity Capital Market Finance Services Flotation Bonus Issue M&A IPO Private Placement Corporate Restructuring Debt Fund Raising Structured financing Underwriting Equity Equity Capital Market Flotation Bonus Issue
Issued on: 25 February 2021 Page 74 of 94
Business line Business Business line Product / Services level 1 line level 2 level 3 M&A IPO Private Placement Corporate Restructuring Debt Fund Raising Structured financing 8. Retail Broking Equity Broking – Brokerage Margin Equity Broking– Non Margin Futures Futures Broking – Broking Margin Futures Broking – Non Margin
Issued on: 25 February 2021 Page 75 of 94
Insurance Business line level 1 Business line level 2 1. General Fire Motor Medical & Health Marine Hull Marine Cargo Aviation On-shore and Off-shore oil related Personal accident Workmen’s compensation & Employee's Liability Contractor's all risk and engineering Bonds Liabilities Others (Golfers/ D&O/ Plate glass/ Credit Insurance) 2. Takaful General Fire Motor Medical & Health Marine Hull Marine Cargo Aviation On-shore and Off-shore oil related Personal accident Workmen’s compensation & Employee's Liability Contractor's all risk and engineering Bonds Liabilities Others (Golfers/ D&O/ Plate glass/ Credit Insurance) 3. Life Ordinary Life Protection Ordinary Life Investment Investment Linked Medical & Health Annuities Others (Please Specify) 4. Takaful Family Ordinary Life Protection Ordinary Life Investment Investment Linked Medical & Health Annuities Others (Please Specify) 5. Reinsurers Facultative Non Proportional Treaty Proportional Treaty Others (Please Specify) 6. Retakaful Operators Facultative Non Proportional Treaty Proportional Treaty Others (Please Specify)
Issued on: 25 February 2021 Page 76 of 94
APPENDIX 13 Event types taxonomy
Banking Event type Event type Event type level 3 level 1 level 2 1. Internal Unauthorised Transactions not reported (intentional) fraud activity Transaction type unauthorised Mismarking of position (intentional) Misuse of privilege information Falsifying personal details Activity with unauthorised counterparty Activity leading to incorrect pricing Transactions over-reported Unauthorised changes to programs or data or transactions Hacking / Cracking Misuse of system access (e.g. powerful system ID) Computer Virus / Malware Injection Programming fraud Theft and Fraud / credit fraud / worthless deposits fraud Theft or extortion or embezzlement or robbery Misappropriation of assets Malicious destruction of assets Forgery Disclosure of confidential information Cheque kiting Smuggling Account take-over / impersonation / etc. Tax non-compliance / evasion (wilful) Bribes / kickbacks Insider trading (not on firm’s account) Accounting irregularities 2. External Theft and Theft / Robbery fraud fraud Forgery / Counterfeit (Cover Notes, Policy Certificates, Currency, Cheque, Security Documents / Identification documents) Fraudulent billing by suppliers Cheque kiting Card Related Fraud Internet Banking fraud Mobile Banking fraud E-money / Prepaid card fraud Fraudulent account opening Fraudulent application for banking products / facilities Systems Hacking damage security Theft of information
Issued on: 25 February 2021 Page 77 of 94
Event type Event type Event type level 3 level 1 level 2 Unauthorised changes to programs by external parties Misuse of system access by external parties Sabotage by external parties 3. Employment Employee Compensation, benefit, termination issues practices relations Organised labour activity and Safe General liability (slips and falls, etc.) workspace environment Employee health & safety rules events safety Workmen’s compensation Diversity and All discrimination types discrimination 4. Damage to Natural Natural disaster – Flood physical disaster & Natural disaster – Earthquake assets other losses Natural disaster – Tsunami Natural disaster – Others Human Losses – Vandalism Human Losses – Terrorism Damage to Islamic Inventory 5. Business Systems Hardware – Server disruption Hardware - Storage Disk and system Hardware - Local Area Network (LAN)/ failures Wide Area Network (WAN) equipment Software - Application system bug / unpatched Software - Operating system bug / unpatched Software - Database error Software - Local Area Network(LAN) / Wide Area Network (WAN) application Software - Inadequate system capacity Software - System interfaces / linkages issues Software - Delay or failure in batch processing Telecommunication - Telecommunication network Telecommunication - Internet Service providers Telecommunication - International and Local Switches (VISA, MasterCard, MEPS & My Clear) Security Breach – Virus / Malware Security Breach - Distributed Denial of Service Security Breach – Hacking / Cracking Security Breach - Web defacement
Issued on: 25 February 2021 Page 78 of 94
Event type Event type Event type level 3 level 1 level 2 Non systems Business Disruption – Fire Business Disruption – Earthquake Business Disruption – Flood Business Disruption – Pandemic Business Disruption – Civil Unrest Utility Disruption – Electrical Supply Utility Disruption – Water Supply 6. Clients, Suitability, Fiduciary breaches / guideline violations products and disclosure and Suitability / disclosure issues (KYC, etc.) business fiduciary Retail customer disclosure violations practices Breach of privacy Aggressive sales Account churning Misuse of confidential information Lender liability Insider trading (on firm's account) Unlicensed activity Misrepresentation of facts Improper Antitrust business or Improper trade / market practices
market Market manipulation
practices Insider trading (on firm’s account)
Unlicensed activity
Money laundering
Mis-selling Mis-informing of Underlying Shariah
contract Poor servicing by agents Product flaws Product defects Model errors Product defects from Shariah perspective Selection, Failure to investigate client per guidelines sponsorship Exceeding client exposure limits and exposure Advisory Disputes over performance of advisory activities activities 7. Execution, Transaction Miscommunication delivery and capture, Data entry or maintenance or loading process execution and Missed deadline or responsibility management maintenance Model / system mis-operation Accounting error / entity attribution Other task miss-performance Service delivery failure Collateral management failure Reference data maintenance Incomplete / failed batch processing Ambiguous and unclear policy terms
Issued on: 25 February 2021 Page 79 of 94
Event type Event type Event type level 3 level 1 level 2 Monitoring and Failed mandatory reporting reporting Inaccurate external reporting Inaccurate internal report (including not updating recent trends / ratios into claims / premium reserves / inaccurate aging report) Customer Client permissions / disclaimers missing intake and Legal documents missing / incomplete documentation Improper documentation (improper receipting or failure to lodge documents, etc.) Customer or Unapproved access given to accounts client account Incorrect client records management Negligent loss or damage of client assets Trade Non-client counterparty mis-performance counterparties Miscellaneous non-client counterparty disputes Vendors & Outsourcing suppliers Breach of SLA Technology failure in supplier systems Service Delivery failure / capacity Vendor disputes
Issued on: 25 February 2021 Page 80 of 94
Insurance Event type Event type Event type level 3 level 1 level 2 1. Internal fraud Unauthorised Transactions not reported (intentional) activity Transaction type unauthorised Mismarking of position (intentional) Misuse of privilege information Falsifying personal details Activity with unauthorised counterparty Transactions over-reported Unauthorised changes to programs or data or transactions Hacking / Cracking Misuse of system access (e.g. powerful system ID) Computer Virus / Malware Injection Programming fraud Theft and Theft or extortion or embezzlement or fraud robbery Misappropriation of assets Malicious destruction of assets Forgery Disclosure of confidential information Smuggling Account take-over / impersonation / etc. Tax non-compliance / evasion (wilful) Bribes / kickbacks Insider trading (not on firm's account) False insurance claims / premiums Inflated insurance claims / payment Misappropriation of insurance premium Accounting irregularities 2. External fraud Theft and Theft / Robbery fraud Forgery / Counterfeit (Cover Notes or Policy Certificates or Currency or Cheque or Security Documents) Fraudulent billing by suppliers False insurance claims / premiums Inflated insurance claims Misappropriation of insurance premium Fraudulent application for products / facilities Systems Hacking damage security Theft of information Unauthorised changes to programs by external parties Misuse of system access by external parties Sabotage by external parties
Issued on: 25 February 2021 Page 81 of 94
Event type Event type Event type level 3 level 1 level 2 3. Employment Employee Compensation, benefit, termination practices and relations issues workspace Organised labour activity safety Safe General liability (slips and falls, etc.) environment Employee health & safety rules events Workmen’s compensation Diversity and All discrimination types discrimination 4. Damage to Natural Natural disaster - Flood physical disaster & Natural disaster - Earthquake assets Other Losses Natural disaster - Tsunami Natural disaster - Others Human Losses - Vandalism Human Losses - Terrorism Damage to Islamic Inventory 5. Business Systems Hardware - Server disruption and Hardware - Storage Disk system Hardware - Local Area Network (LAN) / failures Wide Area Network (WAN) equipment Software - Application system bug / unpatched Software - Operating system bug / unpatched Software - Database error Software - Local Area Network(LAN) / Wide Area Network (WAN) application Software -Inadequate system capacity Software - System interfaces / linkages issues Telecommunication - Telecommunication network Telecommunication - Internet Service providers Security Breach – Virus / Malware Security Breach – Hacking / Cracking Security Breach - Web defacement Non Systems Business Disruption - Fire Business Disruption - Earthquake Business Disruption - Flood Business Disruption - Pandemic Business Disruption – Civil Unrest Utility Disruption –Electrical Supply Utility Disruption – Water Supply 6. Clients, Suitability, Fiduciary breaches / guideline violations products and disclosure and Suitability / disclosure issues (KYC, etc.) business fiduciary Regulatory compliance of appointed practices representatives
Issued on: 25 February 2021 Page 82 of 94
Event type Event type Event type level 3 level 1 level 2 Breach of privacy Unlicensed activity Misrepresentation of facts Misuse of confidential information Insider trading (on firm's account) Aggressive sales Improper Antitrust business or Improper trade / market practices market Market manipulation practices Insider trading (on firm's account) Unlicensed activity Money laundering Mis-selling
Mis-informing of underlying Shariah
contract
Poor servicing by agents
Product Flaws Product defects
Product defects from Shariah perspective Unintentional guarantees Selection, Failure to investigate client per guidelines sponsorship Exceeding client exposure limits and exposure Advisory Mis-selling due to mortgage endowment activities 7. Execution, Transaction Miscommunication delivery and capture, Data entry, maintenance or loading process execution and Missed deadline or responsibility management maintenance Model / system mis-operation Accounting error / entity attribution Other task miss-performance Service delivery failure Incorrect unit pricing / allocation Reference data maintenance Incomplete / failed batch processing Improper maintenance of claim files (claims not updated or not closed in a timely and an appropriate manner) Ineffective and inefficient recruitment / termination of agents Monitoring and Failed mandatory reporting
reporting Inaccurate external reporting
Inaccurate internal report (including not
updating recent trends / ratios into claims
/ premium reserves / inaccurate aging
report)
Client permissions / disclaimers missing
Legal documents missing / incomplete
Issued on: 25 February 2021 Page 83 of 94
Event type Event type Event type level 3 level 1 level 2 Customer Inappropriate underwriting intake and Inappropriate reinsurance documentation Customer or Payment to incorrect client client account Incorrect client records management Incorrect payment to client Trade Non-client counterparty mis-performance counterparties Miscellaneous non-client counterparty disputes Vendors and Outsourcing suppliers Breach of SLA Technology failure in supplier systems Service delivery failure / capacity Vendor disputes
Issued on: 25 February 2021 Page 84 of 94
APPENDIX 14 Causal categories taxonomy
Causal categories Causal categories Causal categories level 3 level 1 level 2 1. People Training Calibre of recruits Human error Misinterpretation Poor relationship management Competence Lack of communication Not meeting customers reasonable expectations Senior management awareness Knowledge Key person / knowledge dependency Culture / Behaviour Unaware of change Senior management knowledge Inadequate resources Product too complex Inappropriate customer / product fit Regional / international differences Succession planning Others Others (Please specify) 2. Process Inadequate operational Dealing with change procedures Product design Spreadsheet workarounds Lack of documentation Inadequate monitoring / Lack of due diligence reporting Poor contract / service level agreement Process change / Management decision / implementation change not implemented Management information inadequate Inadequate policies Inadequate checks/balances on senior individuals Inadequate allocation of accountabilities Others Others (Please specify) 3. System (IT) Coding Software design Testing Virus IT strategy Hardware failure Complexity of interfaces Security Maintenance Poor user acceptance testing / regression testing Investment Legacy systems
Issued on: 25 February 2021 Page 85 of 94
Causal categories Causal categories Causal categories level 3 level 1 level 2 Data integrity Resilience Others Others (Please specify) 4. External Event Trade counterparty Lack of understanding of third-party data Customer Third-party situation beyond firm control (power / telephony / water / services) Regulatory / political Reliance on third-party data Infrastructure failure Lack of understanding of implications of change to third-party systems Service Provider Increase in transaction volume Environmental factors Natural disasters Unrealistic customer expectation Disgruntled employee Others Others (Please specify)
Issued on: 25 February 2021 Page 86 of 94
APPENDIX 15 Key risk indicators taxonomy 1. Generic indicators KRI Sector Description Cycle 1. Number of Banking Number of fraudulent Monthly* application fraud Insurance application detected and near miss &Takaful thwarted for secured / Operators unsecured facility, account opening, insurance proposal submission etc.
Note: Remittance/cheque book/trading bill applications should not be included in the KRI.
2. Number of new Banking Number of new cases that Monthly* litigation cases Takaful have SNC implications, initiated against Operators where the FI was served the FI with SNC with Letter of Demand / implications letter from lawyer within that month
3. Number of Banking Number of reprimands Monthly* reprimands Insurance received from other received from &Takaful regulators / enforcement other regulators/ Operators agencies / operator of enforcement designated payment agencies/ systems (e.g. Bursa operator of Malaysia, Securities designated Commission of Malaysia, payment systems Inland Revenue Board Of Malaysia (LHDN), Ministry of Human Resource, Companies Commission of Malaysia, Royal Malaysia Police, Fire and Rescue Department of Malaysia, Municipal Council (DBKL), Labuan Financial Services Authority, Paynet etc.) Refer to FAQ No. 82.
4. Number of new Banking Number of new cases Quarterly* litigation cases Insurance initiated against the FI, initiated against &Takaful where the FI was served the FI Operators with Letter of Demand / letter from lawyer within that quarter. The number includes orders received from Industrial Court.
Issued on: 25 February 2021 Page 87 of 94
KRI Sector Description Cycle 5. Staff attrition rate Banking Attrition rate for Quarterly* Insurance permanent staff No of turnover in current quarter &Takaful X100 Operators No of staff beginning of current quarter 6. Number of Banking Number of customers’ Quarterly* customers’ names Insurance names in the freeze orders in the freeze &Takaful received from enforcement orders received Operators agency that does not from enforcement match against internal list agency without of STR raised prior STR raised 7. Number of new Banking Number of new audit Quarterly* audit findings Insurance findings from internal and / &Takaful or external auditor Operators engaged for non-financial audits to the entity which have never been raised before. Any recurring issues across different business lines must be excluded
* ALL Reinsurers and Retakaful companies are to report these KRIs on a yearly basis.
Issued on: 25 February 2021 Page 88 of 94
2. Technology KRI Sector Description Cycle 1. Number of instances Banking Tracks specific critical Monthly of critical systems Insurance system availability as downtime exceeding &Takaful outlined in FAQ No. 61. Recovery Time Operators Objective (RTO)
2. Number of instances Banking Tracks specific critical Monthly of critical services Insurance system availability as downtime exceeding &Takaful outlined in FAQ No. 61. Recovery Time Operators Objective (RTO)
3. Number of instances Banking Tracks network Monthly of network utilisation Insurance bandwidth utilisation to exceed threshold of &Takaful identify potential threats 60% Operators to Denial of Service attack (DDoS)
4. Number of instances Banking Tracks specific critical Monthly response time for Insurance system availability as critical services &Takaful outlined in FAQ No. 61. exceeded Operators predetermined More details in FAQ No. threshold / SLA 88.
5. Number of hacking Banking The number of hacking Monthly attempts on IT Insurance attempt on internet infrastructure &Takaful facing application by Operators external parties.
6. Number of instances Banking Tracks specific critical Quarterly storage or memory Insurance system availability as
utilisation exceed &Takaful outlined in FAQ No. 61. maximum threshold of Operators 70%
7. Numbers of batch Banking Tracks specific critical Quarterly overrun incidents Insurance system availability as
&Takaful outlined in FAQ No. 61. Operators
8. Number of instances Banking To ascertain the Yearly of failed Disaster Insurance reliability of the DRP
Recovery Plan (DRP) &Takaful and readiness of the FI tests for critical Operators in the event of a system systems failure
Issued on: 25 February 2021 Page 89 of 94
KRI Sector Description Cycle 9. Number of DRP tests Banking To ascertain the Yearly planned but not Insurance reliability of the DRP
conducted for the year &Takaful and FI readiness in the Operators event of a system failure
10. Number of scheduled Banking To ascertain system Yearly core system Insurance integrity
maintenance not &Takaful conducted Operators
11. Number of incidents Banking To ascertain any Yearly relating to loss of Insurance breaches of
confidential data &Takaful preservation of data Operators confidentiality in accordance to the FSA, IFSA and Personal Data Protection Act
12. Number of incident Banking The transactional Yearly relating to Insurance reporting error refers to
transactional reporting &Takaful a material error in the or updating errors of Operators financial figure or other critical system information in public reports / documents or reports / documents released to the customers or BNM The transactional updating error refers to the error in the financial or customer information database. Refer to FAQ No. 86.
Issued on: 25 February 2021 Page 90 of 94
3. Complaints KRI Sector Description Cycle 1. Number of Banking Complaints on sales Monthly new Insurance representatives’ unethical complaints on &Takaful behaviour such as harassing or Sales and Operators** coercing; or acting in a manner Marketing with the intention to misrepresent or mislead customers (e.g. force selling of products, mis-selling of financial products, misleading advertisement / brochure, misrepresentation by staff / agent, lack of / wrongful advice / info, bundled or sold with another product)
2. Number of Banking Complaints on staff or third party Monthly new Insurance engaged by FIs who are involved complaints on &Takaful in providing services to Services Operators** customers (e.g. delay / no response to customers’ queries / requests / complaints, harassment of customers by staff / debt collector, delay in processing, delay in disbursement, unprofessional conduct / behaviour, wrongful advice / info)
3. Number of Banking Complaints on inefficiency of the Monthly new Insurance internal process, system, control complaints on &Takaful and procedure to ensure fair and Operations Operators** equitable business practices (e.g. delay in clearing of cheques, wrongly cleared / debited of cheques, card retained by ATM, incorrect recording of dispensed amount in e-channel, system offline, freezing / opening / closing of accounts / credit facilities, revised credit limit, dispute in agreement / document, discharge of guarantor, loss of documents, going after guarantor)
Issued on: 25 February 2021 Page 91 of 94
KRI Sector Description Cycle 4. Number of Banking Complaints on products offered Monthly new Insurance not meeting the needs and complaints on &Takaful financial affordability of Products Operators** customers (e.g. different term offered than applied for, unfair term and condition)
5. Number of Banking Complaints on terms and Monthly new Insurance conditions relating to fees and complaints on &Takaful charges, unreasonable and unfair Fees & Operators** imposition of fees and charges to Charges prevent customer from terminating or switching products / services to another financial service provider (e.g. request to waive / reduce penalty interest, excessive fees / charges / penalty / interest, refund of compensation, non-disclosure of fees / charges / penalty / interest, fees charged by merchant without consent)
6. Number of Insurance Complaints on demand for Monthly new &Takaful payment of an amount due under complaints on Operators** a policy / refund / claim / Benefits & surrender etc. (e.g. repudiation of Claims claim, delay in claim settlement, dispute / dissatisfaction of claim settlement / surrender / maturity value, unsatisfactory repair work)
7. Number of Insurance Complaints on the process that Monthly new &Takaful an insurer uses to assess the complaints on Operators** eligibility of a customer to receive Underwriting their products (e.g. refuse to insure / renew / unfair policy condition, dispute on underwriting)
8. Number of Banking Complaints lodged by customers Monthly new Shariah- Takaful on potential non-compliance with related Operators** Shariah requirements in product complaints implementation, legal documentation, product brochures, transparency, etc.
** ALL Reinsurers and Retakaful companies are excluded from reporting the KRIs
Issued on: 25 February 2021 Page 92 of 94
4. Insurance and Takaful KRI Sector Description Cycle 1. Instances of Insurance Number of policy issuance Monthly delay in issuance &Takaful exceeding 30 days for Motor of policies Operators* and 60 days for Non-motor from the acceptance of risk until issuance of policies. Refer to FAQ No. 89.
2. Instances of Insurance Number of claim registration > Monthly delay in &Takaful 7 working days from receipt of registering claims Operators* claims notification 3. Instances of Insurance Number of delay in payment of Monthly delay in payment &Takaful claims > 35 working days from of claims Operators* receipt of the last supporting document for assessment for example medical report and / or final adjuster’s report until issuance of payment voucher. Refer to FAQ No. 90.
4. Number of Insurance Number of life policy / Monthly replacement of & Takaful certificate replaced in a life policy / Operators particular month. Refer to certificate with life / FAQs No. 91 and 92. family business* 5. Number of Insurance Number of risks that are not Monthly occurrences of &Takaful included in the treaty coverage holding cover Operators* but were accepted prior to prior to facultative placement facultative placement 6. Number of Insurance Number of: Monthly disputed and &Takaful claims recovery disputed repudiated Operators* and repudiated from claims recovery reinsurers from reinsurers claims recovery disputed and subrogation and repudiated from subrogation *Note: This applies to all Reinsurance arrangement which include Treaty and Facultative.
7. Number of delay Insurance Number of death claims paid > Monthly in death claims &Takaful 60 days after the notification Operators* date. Refer to FAQ No. 93.
Issued on: 25 February 2021 Page 93 of 94
KRI Sector Description Cycle 8. Instances of General Appointment of licensed / in- Monthly delay in Insurance house adjuster was done >7 appointing & General working days from receipt of licensed / in- Takaful completed claims documents. house adjuster Operators* Refer FAQ to No. 94.
* ALL Reinsurers and Retakaful companies are excluded from reporting the KRIs
5. Treasury KRI Sector Description Cycle 1. Number of treasury Banking Number of treasury limit Monthly room limit breaches breaches on dealing / trading (including trading activities as per the approved positions) internal policy
2. Total number of Banking Number of confirmation Monthly confirmation mismatches between the bank mismatches and its counterparties
3. Number of Banking Number of deals / trades Monthly instances off- concluded not within the market price observable market rates and transactions daily quoted price inclusive of private placements
4. Number of Banking Number of deals / trades Monthly instances off- executed outside the treasury premise trading dealing room
5. Number of Banking Number of unreconciled deals / Monthly instances - failed trades (variance) between trade reconciliation Front Office and Back Office, between Front whereby the trades which were Office and Back concluded by the front office Office but there were no corresponding confirmations obtained by the back office
6. Number of payment Banking Number of payment and Monthly and settlement settlement transactions disputes by disputed by customers and customers and counterparties counterparties
Issued on: 25 February 2021 Page 94 of 94
KRI Sector Description Cycle 7. Instances of buying Banking Number of trades which are Monthly and selling of the executed on an immediate buy same stock / / sell basis, at the same price securities at the in the same stock / securities same price within within the same day the same trading day
8. Number of Banking Number of specific request by Monthly instances – ad hoc dealers to increase approved request to increase trading limit, including trading limit instances when dealers share limits with other dealers
9. Number of trade / Banking Number of trades / deals Monthly deal cancellations amended or cancelled by and amendments trader / dealer
Refer to FAQ No. 95.
10. Number of Banking Number of corporate trades / Monthly unconfirmed deals not confirmed (not corporate trade / signed and returned by deals corporate clients)
6. Corporate Finance KRI Sector Description Cycle 1. Number of Banking To monitor minimum Monthly Qualified Senior number of QSPs specified Personnel (QSP) as a “registered persons” in resignation third column of Part 1 of Schedule 4 in the Capital Markets and Services Act 2007
2. Number of Banking Number of submissions not Monthly submissions meeting SC's standards rejected / returned by SC
3. Breaches of the Banking Number of Chinese Wall Monthly Chinese Wall Policy breaches occurred in policy the month
Issued on: 25 February 2021
ORION Frequently Asked Questions (FAQ)
Issued on: 25 February 2021 Contents
Glossary...... 3 Registration of ORION user ...... 4 Technical trouble-shooting ...... 5 General ...... 7 Loss event reporting...... 7 General ...... 7 Overseas loss event reporting ...... 12 Customer information breaches loss event reporting ...... 13 Payment-related loss event reporting ...... 14 Aggregate loss event reporting ...... 15 BDSF–related loss event reporting ...... 16 Cyber Threat–related loss event reporting ...... 17 Shariah non-compliance loss event reporting ...... 18 Insurance specific loss event reporting ...... 19 KRI Reporting ...... 19 Generic KRI ...... 20 Technology KRI ...... 21 Insurance KRI ...... 21 Treasury KRI ...... 22 Scenario Analysis ...... 23
2
Glossary Abbreviation Full phrase BCM Business Continuity Management BNM Bank Negara Malaysia CRO Chief Risk Officer DFI Development Financial Institutions FTP File Transfer Protocol KRI Key Risk Indicators LoD Level of Disruption MTD Maximum Tolerable Downtime ORION Operational Risk Integrated Online Network RE Reporting entities RTO Recovery Time Objective SNC Shariah non-compliance SST Self-Service Terminal
3
Registration of ORION user
1. How many users are allowed in ORION? In the case of REs operating as financial groups, access to ORION will be granted to the GCRO, CRO and Submission Officer.
In the case of REs operating on stand-alone basis, access to ORION will be granted to the CRO and Submission Officer.
For additional submission officer’s ORION license, each entity is allowed to purchase only ONE licence. To purchase the licence, please email to [email protected] with the following details of your institution: (i) Contact Person: (ii) Business Registration Number: (iii) Phone Number: (iv) Fax Number:
2. What are the details required for registration of new user and/or change of ORION Submission Officer, CRO and/or GCRO? Firstly, users must register at FI@KijangNet portal through their institution’s FI@KijangNet administrator.
Upon successful self-registration at FI@KijangNet portal, the printscreen of the new officer’s FI@KijangNet profile and reason for changes must be emailed to [email protected]. Registration of the new user in ORION may take up to five working days after receiving the complete printscreen. Sample of FI@KijangNet profile printscreen is as shown below:
3. What if the registration in FI@KijangNet fails? If registration fails: (i) Check if the email used for both ORION and portal registration are the same; (ii) Check if administrator has assigned the roles; or (iii) Check on the browser version guided by the User Guide and Technical Specification document.
4. Should RE’s administrator for FI@KijangNet portal receive confirmation upon new user registration in ORION? No confirmation email will be generated by FI@KijangNet.
4
Technical trouble-shooting 5. Why am I not able to access ORION using the given link @ http://orion.w2k.bnm.gov.my:80/metricstream/systemi. Please access ORION via FI@KijangNet @ https://kijangnet.bnm.gov.my. Do not use the link @ http://orion.w2k.bnm.gov.my:80/metricstream/systemi.
6. I have logged onto FI@KijangNet portal but am unable to see any ORION tabs within the application / I am encountering an error (404 error). This could be due to the following: (i) Internal Server error, do contact your institution’s IT department to ensure that this can be addressed.
(ii) BNM’s Risk Specialist and Technology Supervision Department has not granted access to the new officer. Please ensure that the new officer’s FI@KijangNet profile screenshot and the role of the user (CRO/Submission officer) attempting to access the system has been emailed to BNM at [email protected] .
7. Our CRO / Submission Officer (SO) has tried to log-in to ORION via FI@KijangNet portal but failed due to forgotten password. The CRO / SO has then tried to change the password but failed due to one of the following reasons: (1) there were security questions to be answered, and the user does not have an answer for the questions; or (2) there were no pop-up security questions. What is the next course of action? For forgotten password in ORION, REs must reset their password in FI@Kijangnet. Please do the following: (i) Browse @ https://kijangnet.bnm.gov.my/ and on the landing page, click Reset Password. A new browser window will pop up.
(ii) Key in your complete user ID in the User ID field and click Search. If your account is found, it will be listed in the page with name of the account user.
(iii) Key in the answer for the security questions. If you have set up the security questions and answers correctly during production setup, you will be prompted to answer your personal security questions. Note: Please type in the exact answer you used during registration. Take note of capital letters, spacing and special characters etc.
(iv) If you have forgotten the answers to your FI@Kijangnet security questions, please email [email protected] for assistance.
(v) Change the password after successfully answering all the security questions. You will be prompted to change your password. Key in your new password and click Save.
8. Why does a pop-up error message appear when filling up the loss event form?
5
This could be due to an incompatible browser being used. The supported browsers are Internet Explorer 11 and Google Chrome (64bit) 87.0.4280.88 (Official Build). For Google Chrome, you may go to ‘Help' and click 'About Google Chrome' to update to the latest Google Chrome version.
9. I have been registered by my institution’s FI@KijangNet administrator in the portal and have provided BNM with the details of user. While I can see the ORION tab, I am unable to access it upon clicking. This could be due to internal security settings or firewalls that have been set up based on your institution’s internal IT security policies. Do contact your IT department to ensure that appropriate access has been granted.
10. I am able to navigate through the ORION application, however, when I attempt to download the template and save it to my computer, I am unable to do so due to an unauthorised / insufficient permission error message. As the template is content that is being downloaded from a web based application, your institutions IT policy may not permit such items to be saved to your local machine. Do contact your IT administrator to enable this function.
11. How do we resolve the error message received after the upload of the Loss Event Data template? Depending on the error message received, please do the following to resolve: (i) Upload Completed & Invalid Data Found – Download the error template in the upload status report and refer to the error text under the loss event detail sheet to determine the invalid data input for each loss event submitted. Re- enter the correct value in the field that has been pointed out by the error text and retry submitting the loss events.
(ii) Upload Failed – Download a fresh new template and input the data accordingly with the instruction given to avoid corruption of template. Inputs of data directly into excel template cells for each column are not allowed and will result in corruption of the template.
12. I encounter syntax error message while doing submissions to ORION Please DO NOT use any special characters such as: < > \ : ; " & # ^ ' ` ? % in the Loss Event Description, attachment names or any free text fields. If the issue persists, please email [email protected] to receive the instruction to capture your network logs for further investigation.
13. Will there be any email notification upon a successful submission? No, emails will not be generated upon a successful submission. The submission status can be validated against the Master List Reports.
14. Will there be an audit trail of the changes made in previous submissions? Yes, REs can view the date, fields and user of the last change made.
15. How do REs amend previous submissions? (i) To amend a reported loss event in ORION to reflect any changes to its content / classification etc., users may do so by retrieving the said report using “Loss Event ID”.
6
(ii) Duplicated events can be amended by deactivating one of the reports by filling up the “Event Valid Till” field with the current date.
(iii) If a reported suspected fraud event was concluded as a case of genuine transaction, the event can be removed from ORION by filling up the “Event Valid Till” field with the current date.
16. Do REs need to inform BNM of the changes to previous submissions made in ORION? No.
General
17. How do we communicate to BNM on any enquiries pertaining to ORION? All queries/communication can be directed to [email protected] .
18. Is there a “maker-checker” function in ORION for validation purposes? No. ORION is strictly a submission system. REs internal governance process must be cleared outside the system prior to the submission.
19. Please clarify on the period of the data collection to be reported for monthly reporting. Examples based on the timeline are as follows; (i) Monthly submission of aggregate reporting - by the 15th calendar day of the following month or earlier. This means that all events that occurred from 1 January to 31 January must be reported by 15 February or earlier (1 to 14 February).
(ii) Quarterly KRIs by the 15th calendar day of the following month. This means that all instances that occurred from 1 January to 31 March must be reported by 15 April or earlier (1 to 14 April).
20. How to change RE’s Kijang Administrator? Please email your change request along with details of the new administrator such as Name, Email Address and Contact Number to [email protected] .
21. Our institution’s FI@KijangNet administrator has forgotten his password to login to the portal. What is the next course of action? Please email your request to reset password to [email protected] .
Loss event reporting General
22. There is a high volume of data this month. Can we request for an extension of the loss event submission deadline? There will be no extension granted. Nevertheless, please email to [email protected] to notify us of the late submission and reason.
7
23. How to report high reputational impact events to ORION? For event that may threaten the RE’s reputation, RE must first assess the event according to RE’s internal policy (e.g. Reputational risk framework etc.). Should the assessment conclude that the event poses high reputational impact to the RE, the event must be submitted to ORION within 1 working day.
24. How do REs assess non-financial impact (Low, Medium, High)? REs shall determine the impact based on their internal policy (e.g. Reputational risk framework etc.) considering the nature of the event and REs size, nature and complexity of their respective entities.
25. What does ‘Date of Event Confirmation’ refer to? RE is to determine own “point of confirmation”. Confirmation of an event is to be done by RE’s appropriate line of governance.
26. What does the event classification of “Actual Loss” in ORION signify for general OR events, SNC events, BDSF events and Cyber threat incidents? FIs must be mindful of the event classification when reporting general operational risk events, SNC events, BDSF events and Cyber threat events. The significance of “Actual Loss” event classification for different types of events are as stated below: (i) General OR events - To classify as ‘Actual Loss’ when there is a financial loss impacting the P&L i.e. Write-off or provision.
(ii) SNC events - ‘Actual loss’ refers to Actual SNC status as confirmed by the Shariah Committee (SC) regardless of whether there is financial loss or not. E.g., the bank’s SC has confirmed the event is an SNC event, however the amount that is required to be purified has yet to be determined – to classify as “Actual Loss” as the event is an Actual SNC.
(iii) BDSF events – To classify as ‘Actual Loss’ when a critical BDSF event (as outlined in the guide) occurred at the Res.
(iv) Cyber incidents – To classify as 'Actual Loss' when there is a cyber event that: jeopardizes the cyber security of an information system or the information the system processes, stores or transmits; or violates the security policies, security procedures or acceptable use policies, whether resulting from malicious activity or not.
27. Does financial losses parked in Sundries / Transitory / Suspense account required to be reported to ORION as ‘Actual Loss’? A financial loss booked temporarily in the sundries / transitory / suspense account and yet to be written-off or provisioned for in the P&L, is not considered as an 'Actual Loss' event.
However, if the financial loss booked temporarily in the sundries / transitory / suspense account is ≥ RM1 million, the event would need to be reported to ORION under the category of Critical Events – actual / potential losses ≥ RM1 million as
8
‘Potential Loss’ first and subsequently updated to reflect any ‘Actual Loss’ or ‘Recovery’.
In the case of loss and chargeback, these must be reported as ‘Actual Loss’ event with losses tied to the merchant (Refer to FAQ No. 58).
28. Previous submission of loss event(s) does not appear in the loss event list report in ORION’s default landing page? By default, the loss event list report in the landing page will show only the current month loss event submission. For any previous submission, you can search the loss events submitted via these 2 methods: i) Field ‘Loss Event ID’ – Institution Internal Loss Event ID / ORION generated Loss Event ID can be used to search for previous loss event
ii) Field “Update from” & “Update till” – This field requires you to input the duration of reporting date for any previous submitted loss event.
29. I have tried to search for a loss event that has been reported to ORION previously via the Loss Event ID field and nothing appears. Why? There might be a possibility that the loss event has been end dated (a date has been inputted in the “Event Valid Till” field) or the event was not successfully uploaded via the Excel template. Please re-submit the event to ORION indicating ‘[Re-submission]’ in the “Loss Event Name” and the reason for re-submission along with the details/executive summary of the event itself in the “Loss Event Description”.
30. What is the function of the “Event Valid Till” field? The field is meant to remove a loss event from ORION. Please be noted that inputting a date value in this field does not signify the closure of the event.
31. How to determine the success of the batch excel uploading for LED? Kindly refer to the Upload Status Report under LED.
32. Is there a threshold for reporting loss event? No threshold to ensure sufficient industry data is collected to determine industry analysis, reports and trending. However, please be noted on the requirements of aggregate reporting for: (i) Card related fraud ≤ RM5, 000 (ii) Actual loss ≤ RM1, 000 (iii) All physical cash shortages
33. When do REs report suspected fraud cases to ORION? All suspected fraud events (apart from card fraud – refer to FAQ No. 53) must be reported upon confirmation of suspected fraud by the Fraud Investigation Unit, Claim Unit or similar functions although the exact loss amount is yet to be ascertained.
Subsequently, the suspected fraud must be re-assessed and updated to reflect changes to the ORION loss event classification (e.g. from Potential to Actual) and latest loss description (e.g. confirmed actual loss amount).
9
34. Does application fraud “near miss” needs to be reported as loss events? No. Application fraud events (e.g. banking facilities / financing application, opening of account) are not required to be reported to ORION as loss event unless if it is a new MO to the bank. Nonetheless, the number of these occurrences would need to be reported as KRI.
35. Please elaborate on New and Repeated events. New – New type of MO that impacted the REs for the first time (it does not refer to every new submission of events
Repeated – MO that has occurred previously at REs.
36. Do REs report Code of Ethics cases to ORION? Code of Ethics cases are required to be reported as loss events only if there are actual / potential financial losses incurred (e.g. claims from customer on mis- selling).
Should the potential financial loss be less than RM1mil, the loss event can be submitted when the loss is charged to P&L. If the potential loss is ≥ RM1mil, REs are required to report as ‘Potential Loss’ to ORION.
37. Do events occurred outside REs premises need to be reported too? Yes. As long as the Operational Risk event is within the context of Table 2: ORION reporting types and timelines, as stated in the ORION policy document.
38. In an event which causes / involves two different operational risk ‘Event Types’ in ORION, should REs report as one or two events? The loss event must be reported separately as follows:
Scenario A: Hacking on internet banking database system that causes customers’ data leakage.
(i) Event 1 (for hacking) – Event Category: External Fraud > Systems Security > Hacking Damage.
(ii) Event 2 (for customers’ data leakage) – Event Category: CPBP > Suitability, disclosure and fiduciary > Breach of Privacy.
Event 1 shall record the LED ID number of Event 2 in the Loss Event Description and vice versa. Another similar separate reporting required is for case in FAQ No. 39.
39. Does the cost incurred from repair / replacement resulted from Self-Service Terminals robbery and theft is included in the loss event reporting? Yes. Please report the event as TWO separate events to ORION. Guiding examples are as follows:
10
Scenario A: Attempted robbery with no cash loss (no cash stolen from the Self- Service Terminals as the robbery was unsuccessful but there was some loss due to damage).
(i) Event 1 (for robbery event) – Loss Event Name: Attempted Self-Service Terminals robbery. Event Category: External fraud > Theft and fraud > Theft/robbery. Event Classification: Near miss.
(ii) Event 2 (for repair work if the loss has been charged to P&L) - Loss Event Name: Attempted Self-Service Terminals robbery repair cost. Event Category: Damage to physical assets > Natural disaster & other losses > Vandalism. Event Classification: Actual loss.
Scenario B: Successful robbery with cash loss (stolen cash from the Self-Service Terminal with loss due to damage)
1) Event 1 (for robbery event) Loss Event Name: Self-Service Terminal robbery. Event Category: External fraud > Theft and fraud > Theft/robbery. Event Classification: Potential Loss (if the loss has yet to be charged to P&L) Actual Loss (if the loss has been charged to P&L).
2) Event 2 (for repair work if the loss has been charged to P&L) - Loss Event Name: Attempted ATM/CDM robbery repair cost. Event Category: Damage to physical assets > Natural disaster & other losses > Vandalism. Event Classification: Actual loss.
40. Should cash shortages for Self-Service Terminal outsourced to vendor be reported to ORION despite losses being absorbed by a third party? All Self-Service Terminals cash shortages either at the bank’s branch, offsite Self- Service Terminal including those outsourced to vendor irrespective of whether the losses are borne by the bank or third party, has to be reported – to record the losses in aggregated amount. Please refer to Appendix 10: Aggregate Reporting Requirements.
41. Do REs need to report gains? No.
42. The BCM Guideline specifies that escalation of major disruption must be reported to BNM within 2 hours, which is less than the ORION requirement. Which one prevails? REs must notify any major disruption (LoD 2 and above) within 2 hours to the relevant stakeholders in BNM (Relationship Managers and/or Supervisors) as stipulated in the BCM Guideline. Nonetheless, reporting of BDSF events to ORION must be in accordance with Table 2: ORION Reporting Types and Timelines.
43. How do we map the event type, business lines or causal categories?
11
The principle is that the taxonomies must be mapped to the closest ORION taxonomies for event type, business line or causal categories. This includes the following circumstances: (i) The existing taxonomies in the reporting entities are not as granular. (ii) The event that occurred impacted several business lines/ branches. In this case REs must establish a principle of allocating the loss, e.g. to the most impacted business activity like deposit hence allocated to commercial banking. (iii) The use of “Others” must be done after REs have tried to exhaust all possible options in the taxonomies. If it is genuinely new e.g. new modus operandi for fraud, BNM must be immediately notified.
Overseas loss event reporting
44. What are the types of entities subjected to overseas operational risk event reporting? Only banking and insurance-related foreign and offshore subsidiaries or branches of the REs are subjected to this requirement. 45. How to report losses incurred by overseas branches and/or overseas subsidiaries to ORION? (i) Please use the Overseas Subsidiary Form to report losses incurred by overseas branches and/or overseas subsidiaries.
(ii) There is no excel template available for the purpose of reporting overseas losses.
(iii) Only Actual Loss events are required to be reported.
(iv) Losses must be reported by Country of loss.
(v) Monthly submission of overseas losses reporting - by the 15th calendar day of the following month or earlier.
(vi) Reporting of these losses must be in accordance with the reporting requirement as set out in Appendix 11: Overseas loss event reporting requirements - Table 15: a. Events with amount < RM1 million must be aggregated by country. b. Events with amount that are ≥ RM1 million must NOT be aggregated and must be reported as a single event by country in ORION.
46. How to report losses incurred by overseas branches and/or subsidiaries that are ≥ RM1 million to ORION? For events ≥ RM1 million, to submit loss event individually by country. e.g., There were 3 loss events ≥ RM1 million that occurred from 1 January to 31 January as per below: Thailand – RM2.5 million Singapore – RM1.7 million Singapore – RM1.5 million
12
RE must submit 3 reports to ORION by 15 February or earlier (1 to 14 February). Report 1: Thailand RM2.5million; Report 3: Singapore RM1.7 Report 2: Singapore RM1.5 million. million;
In ORION, to select the relevant Level 1 ‘Business Line’ and Level 1 ‘Event Type’. The chronology of the event detailing how the event happened, root cause along with the remedial actions and mitigation action plans must be included in the ‘Loss Event Description’ field.
47. How are losses incurred by overseas branches and/or subsidiaries that are < RM1 million reported to ORION? For events < RM1 million, to submit the loss event aggregated by country. e.g., There were 5 loss events < RM 1 million that occurred from 1 January to 31 January as per below: Thailand – RM20k Vietnam – RM3k Singapore – RM2k Vietnam – RM1k Singapore – RM3k
RE must submit 3 reports to ORION by 15 February or earlier (1 to 14 February). Report 1: Thailand RM20k; Report 3: Vietnam RM4k Report 2: Singapore RM5k;
In ORION, Level 1 ‘Business Line’ and Level 1 ‘Event Type’ are not required for the aggregate reporting of events < RM1 million. However, due to the mandatory field setting of the Business Line and Event Category, RE is to select any from the drop down list. For Loss Event Description field, please put ‘N/A’.
Customer information breaches loss event reporting
48. Should customer information details be included in ORION when reporting a customer information breach event? The reporting of customer information breach in ORION must include an executive summary of the case, covering the areas specified in Appendix 6 of the ORION policy document. Confidential information of the affected customer or any other individuals (e.g. name, I/C number, account number and other personal information) must not be included.
49. Should customer information details be included in the detailed investigation report submitted to BNM’s Jabatan Konsumer dan Amalan Pasaran? The investigation report must include all the details as set out in Appendix I of the policy document on Management of Customer Information and Permitted Disclosures.
50. The ORION reporting requirements state that customer information breaches must be reported within 1 working day upon completion of investigation tabled to the Board. Where do we input the date in ORION?
13
For the purpose of reporting customer information breaches in ORION, please use ‘Date of detection’ field in reference to ‘Date of investigation tabled to Board’.
Payment-related loss event reporting
51. What is e-money? As stated in the E-money Guidelines and in accordance with the Payment Systems (Designated Payment Instruments) Order 2003, e-money refers to a payment instrument, whether tangible or intangible that; (i) stores funds electronically in exchange of funds paid to the issuer; and (ii) is able to be used as a means of making payment to any person other than the issuer. Example of e-money is Touch n' Go card scheme and International brand prepaid card issued by banking institutions.
52. Do cases of forged / counterfeit notes need to be reported? Yes. All fraud cases must be reported to ORION irrespective of the event classification of actual, potential or near miss.
Any counterfeit Malaysian currency notes accepted via Cash Deposit Machine (CDM) and Cash Recycler Machines (CRM) must be reported under BDSF when the system fails to detect and reject the counterfeit notes. The incident must be reported in ORION even if there is no loss incurred.
53. Please elaborate on ‘attempted fraud’ in terms of payment-related transactions. Attempted fraud refers to an event whereby the issuer managed to detect the fraudulent transaction and managed to stop the transaction from going through (no loss and no charge back).
54. If a customer disputes 10 credit card transactions, should it be reported to ORION on a per transaction basis or per customer basis? The reporting must be per transaction basis. Transactions with amount involved ≤ RM5k must be aggregated for reporting to ORION. Transactions with amount involved > RM5k threshold must be submitted as a single event to ORION. Please refer to Appendix 10: Aggregate reporting requirements.
55. At what stage should the RE report a Card fraud? At the point of detection.
56. For events involving fraudulent altered cheque which the collecting Bank has tagged as Non Conformance Flag in CTCS and fraud did not take place, are these “near miss” events required to be reported to ORION? No, unless there is additional mitigation actions (e.g. calling up customers to verify the cheques that are suspected to be fraudulent) taken by the issuing Bank to verify if these altered cheques that have been tagged as Non Conformance by collecting Bank are fraud or genuine.
14
57. Who should report cheque fraud events? Issuing banks or collecting banks? The issuing bank must report cheque fraud irrespective of whether the loss is borne by the issuing bank or collecting bank. If the loss is borne by issuing bank, please input the amount accordingly as per below - Incurred by Actual Loss / Potential Recovery Comments Loss (In RM) Amount (In RM) RE / Issuing Bank Xx Collecting Bank Customer Others
If the loss is borne collecting bank, issuing will be reporting the loss on collecting bank’s behalf by inputting the amount accordingly as per below - Incurred by Actual Loss / Potential Recovery Comments Loss (In RM) Amount (In RM)
RE / Issuing Bank Collecting Bank xx To input the name of the bank that is absorbing the loss Customer Others
58. How do I report credit card cases (loss and chargeback) whereby the RE can fully recover losses from the Acquirer / Merchant (if it complies with the relevant requirements of Visa / MasterCard)? Report as “Actual Loss” with losses tied to merchant accordingly as per below – Incurred by Actual Loss (In RM) Recovery Amount Comments (In RM) RE / Issuer xx Card holder / Customer Acquirer / Merchant xx
Aggregate loss event reporting
59. How should REs report aggregate card-related fraud ≤ RM5k? Aggregate reporting for card-related fraud event is based on the Amount Involved per Table 14 in ORION Policy Document. For example, a credit card fraud with amount involved of RM3,500 would be reported on an aggregated basis (by card type) as the amount involved is ≤ RM5k.
Whereas, a credit card fraud with amount involved of RM7,500 must not be aggregated as the amount involved is > RM5k. Instead, this event must be reported as a single event to ORION.
60. What is the basis of reporting aggregate loss events ≤ RM1k? Aggregate reporting for loss events is based on Net Actual Loss.
15
BDSF–related loss event reporting
61. What are the critical business functions or systems subjected to ORION reporting for critical BDSF events? a. Any system failure or system execution failure occurred at REs or outsourced service provider affecting the critical business functions or systems listed below irrespective of breaching or not breaching RTO timeline must be reported to ORION. This includes but not limited to: (i) Core Banking System (ii) Core Insurance System (iii) Payment Systems eSpick RENTAS Interbank Fund Transfer (IBFT, MEPS IBG) (iv) Treasury System (v) Self-Service Terminals (SSTs include CRM, CDM & ATM) (vi) Internet Banking System (Retail and Corporate) (vii) Mobile Banking System (viii) Call Centre (ix) Insurance eCover note (x) Internet Insurance System (for public and agents, e.g.: motor & travel insurance) (xi) Card System (xii) SWIFT
Note: The list of critical systems above is not exhaustive and REs should assess whether other systems should be considered as critical, with consideration that the application system supports the provision of critical banking, insurance or payment services, where failure of the system has the potential to significantly impair the financial institution’s provision of financial services to customers or counterparties, business operations, financial position, reputation, or compliance with applicable laws and regulatory requirements
b. Any counterfeit Malaysian currency notes accepted via Cash Deposit Machine (CDM) and Cash Recycler Machines (CRM) must be reported under BDSF when the system fails to detect and reject the counterfeit notes. The incident must be reported in ORION even if there is no loss incurred.
62. If a system disruption has impacted both conventional and Islamic entities, how would the reporting of such event be done in ORION? Please submit two separate LED reporting for each entity. Any financial loss resulted from the event must be split accordingly.
63. What are the parameters to define business disruption? Does this include disruption of just 5 to 10 minutes (or less)? Any business disruption must be reported irrespective of the duration of disruption. However, event severity must be confirmed in accordance to:
16
(i) Any business disruption of LoD 1 event involving failure at main branch or processing hub irrespective of breaching or not breaching MTD timeline including network. (ii) Any business disruption of LoD 2 and above irrespective of breaching or not breaching MTD timeline including network.
64. Is critical system failure/outage with low severity level required to be reported? Any system failure is to be reported irrespective of event severity as long as the systems are listed in FAQ No. 61.
65. Are ‘minimal’ system failures resulting from batch overruns for few minutes required to be reported in ORION? Yes, system failures resulting from batch overruns regardless of short or long duration, is required to be reported in ORION.
66. What is the definition of ‘Main Branch’ or ‘Processing Hub’ in reporting a business disruption event in ORION? Any business disruption involving the RE’s main branch and where there are significant business operations taking place to support the functionality of the RE’s operations i.e. centralised operations centres.
67. What is the definition of ‘New’ and ‘Repeated’ in the context of IT incidents Select “New” if New MO is applied. I.e. The first DDoS attack was impacting bank’s network by flooding it with data packets, and the second DDoS attack MO is by affecting the bank’s system application instead of the network Select “Repeated” if the same MO has been applied in previous attack.
Cyber Event–related loss event reporting
68. How do REs classify cyber incidents and events in ORION? All cyber incidents and events must be reported to ORION as per below:
(i) Cyber incident > Event classification: Actual Loss Defined as a cyber event that: jeopardizes the cyber security of an information system or the information the system processes, stores or transmits; or violates the security policies, security procedures or acceptable use policies, whether resulting from malicious activity or not.
(ii) Cyber event > Event classification: Near Miss Defined as any observable occurrence of cyber threat in an information system. Cyber events sometimes provide indication that a cyber incident is occurring (i.e. cyber threat which could potentially compromise REs IT equipment, system, operations, data, services or users).
17
Shariah non-compliance loss event reporting
69. Do REs still need to declare nil SNC as per the previous requirements? No.
70. Is the officer in charge (OIC) mentioned in Appendix 8 - SNC event reporting requirements, the same as the ORION submission officer mention in the main document? No. The ORION submission officer is responsible to consolidate and liaise with relevant parties, including the OIC in matters pertaining to submission to BNM.
71. Illustration on reporting actual loss and potential loss for SNC. It should be highlighted that actual loss and potential loss are operational risk categorisation hence are NOT the same as actual SNC and potential SNC. REs must be mindful of the operational risk loss category when reporting SNC events. SNC events can be differentiated by flagging the Islamic Business and Actual SNC boxes (selected as “Yes”) in the system. (i) Actual SNC is reported when Shariah Committee confirmed that the event is SNC. Regardless of whether the SNC event is with or without financial losses, the SNC event is to be reported to ORION as “Actual Loss” under the event classification field and to select “Yes” in the SNC box. Non- financial impact must be reported for actual SNC with nil financial loss.
Scenario 1: SC has confirmed that the event is an SNC event but there was no financial loss as FI managed to rectify the matter within 30 days (i.e. new contract was issued before income was recognised). FI is to classify the event as “Actual Loss” to reflect that it is an Actual SNC although there was no financial loss.
Scenario 2: SC has confirmed that the event is an SNC event and there was financial loss (estimate) but the actual amount is yet to be ascertained and has not impacted the FI’s P&L. FI is to classify the event as “Actual Loss” to reflect that it is an Actual SNC.
(ii) Potential SNC is reported immediately (T+1 working day) upon event confirmation by an officer within the control function regardless if the event has been tabled to Shariah Committee or not. In ORION, to select “Yes” in SNC box and event classified as “Potential loss”.
(iii) If the Shariah Committee decided that a potential SNC is a not an SNC event, FI must assess if the event is operational risk related or not: a. If the event is an operational risk event, the event must be reported as such by amending the SNC field previously selected as “Yes” to “No”. The details of the event must be retained for the purpose of reporting to BNM. b. If the event is neither an operational risk event, the event must be removed from ORION by inputting a date in the “Event Validity” field to end date the event.
18
72. On the requirement to conduct ad-hoc Board meeting to meet the 30-day period to obtain Board’s approval on the rectification plan, can it be in the form of circularisation? No. A formal meeting or discussion session must take place. Board’s approval in the form of circularisation and/or memorandum is not permissible.
73. On the requirement to submit rectification plan approved by the Board within 30 calendar days, can it be a principle based / brief plan? In order to meet the 30-day period, the rectification plan that is to be submitted does not have to be a full blown plan and it can be of a principle based plan approved by the Board. However, the detailed rectification plan must be submitted and updated in ORION later.
74. Must SNC events be reported at entity level? Yes, SNC issues must be reported by the entity where the business belonged to. I.e. Investment bank A have SNC issues of which the loss is impacting the GL in Islamic bank A. In this case, Islamic bank A is required to report the SNC event to ORION and indicate in the Loss Event Description that the loss occurred at Investment bank A.
75. Can RE request for extension should they fail to table the potential SNC event to Shariah Committee within the 14 working days timeline? RE is strictly required to observe the timeline of the 14 working days. However, any request for time extensions need to be supported with strong justifications and it has to be through a formal request to the Bank.
Insurance specific loss event reporting
76. Misappropriation of insurance premium by Agent – how shall REs select business line level 2 as the premium owed by the agent encompasses various classes of policies? The business line level 2 is to be reported under each affected class of business.
77. For "Ordinary Life Investment" under business line level 2 for Life business, does it meant for with-profit business/participating fund? Yes.
78. Does the ORION Policy Document and FAQ supersede other insurance related policies and guidelines? No. ORION Policy Document and FAQ does not supersede the Guidelines on Claims Settlement Processes and other insurance related policy document unless otherwise stated in the ORION Policy Document and FAQ. Insurance companies and Takaful operators must continue to ensure compliance with the Guidelines on Claims Settlement Processes and other insurance related policy documents as well as refer to the supervision department.
KRI Reporting
19
79. How to amend previously submitted KRI to ORION? Only the latest submission (latest quarterly/monthly/yearly submission) can be edited. To amend, click on the KRI module tab, select KRI Submission Report and then select your Reporting Entity Type and Reporting Entity Name accordingly. From the list of KRIs submitted populated, select the KRI that you would like to amend. Click on the pencil icon on your top right to edit and submit. On historical data, however, all amendments must be emailed to [email protected] .
80. Will BNM be sharing the industry threshold for KRIs? No. Generic KRI
81. What is the scope to report ‘Number of application fraud near-miss’? For Banking Sector: Remittance/cheque book/trading bill applications must not be included in the KRI.
For Insurance Sector: (i) “Application” here refers to insurance proposal (proposal form); (ii) The KRI includes new policy, upgraded policy application, reinstatement of insurance, endorsement, claim applications etc.; (iii) The KRI only captures confirmed fraud cases; (iv) New agent application / registration or employee application / staff recruitment must not be included in this KRI.
82. What type of reprimands needs to be reported as KRI? Only severe formal and/or official written reprimands that are substantiated with documentation are to be reported as KRI in ORION irrespective of monetary or non- monetary penalty imposed. Reprimands received directly from BNM (e.g. Statistical Department, Consumer Market Conduct) are not required to be reported in this KRI.
83. What is the scope of reporting the KRI on “Number of New Litigation Cases Initiated against the FI”? (i) Where FI was served with Letter of Demand (LOD), to report in the KRI; (ii) Where the reported LOD is translated into a real litigation, FIs are not required to include in the following quarter; (iii) Where FI was served with court order without prior LOD, FIs are to report in the KRI; (iv) Industrial Court related -For case initiated by staff/ex-staff, only cases where unable to be resolved through reconciliation proceedings and subsequently referred to the Court are deemed litigation case that has to be reported under this KRI; (v) Insurance claims-related litigation are not required to be reported.
84. Is the turnover rate calculation includes deceased and/or staff that has retired in “Staff Attrition Rate” KRI? Yes
20
85. Are supervisory / regulatory findings required to be reported in the “New Audit Findings” KRI? No.
Technology KRI
86. Please elaborate on the KRI “Number of incidents relating to transactional reporting or updating errors of critical system”. The KRI is to capture incidents related to errors caused by production system. Any errors caused by human intervention shall not be included in this KRI.
For example: (i) Erroneous financial or transactional reporting caused by system which could affect decision making, analysis or general understanding of the business by anyone who have access to the report. (ii) Errors in computation or processing of financial transactions which result in customers' account being wrongly credited or debited. (iii) Material errors in the total outstanding loans figures or total premiums income reported in the annual report. (iv) Material errors in the financial reporting to BNM as at a specific reporting period. (v) Customers' statements (whether in electronic or paper form) showing wrong account balances or transaction history - if this is due to programming errors, this can be reported as one incident even though it affects many customers. (vi) Incorrect interest or dividend amounts were credited into customers' accounts due to errors in batch jobs - this is also treated as one incident although the erroneous crediting of interest or dividend payments affected many customers (vii) Customers' policy/statements (whether in electronic or paper form) showing wrong sum insured, premium amount or transaction history of payments made - if this is due to programming errors, this can be reported as one incident even though it affects many customers.
87. What is the definition of Critical Systems vs. Critical Services? Critical services = critical business function. Critical systems are those systems supporting the critical services.
88. Please elaborate the KRI “Number of instances response time for critical services exceeded SLA”. Response time here refers to system response time (from the moment an instruction is entered into the system until the user gets the system response). This KRI intends to capture delay in response time for SLA between the bank and their customers (outsourcing contracts SLA are excluded).
Insurance KRI
89. What is the scope of reporting the KRI “Instances of delay in issuance of policies” for number of policy issuance exceeding 30 days for Motor and 60 days for Non-motor from the acceptance of risk until issuance of policies?
21
(i) For Motor, acceptance of risk refers to the date cover note was issued. (ii) For Non-motor, acceptance of risk refers to policy inception date. (iii) The 30 days for Motor and 60 days for Non-motor refers to calendar days. (iv) FIs are expected to track all policies issued including by franchise.
90. What is the scope of reporting the KRI “Instances of delay in payment of claims” for payment of claims > 35 working days from receipt of the last supporting document for assessment for example medical report and / or final adjuster’s report until issuance of payment voucher? (i) Issuance of claim advice can be the last checkpoint if it is regarded same as payment voucher. (ii) The KRI is applicable to all recipient of claims paid out, including third party claimants (except payment made by medical claim administrator) (iii) The KRI includes Life and Personal Accident Death claim cases.
91. On the number of replacement of life policy / certificate (ROP / ROC) KRI, is the indicator meant for internal or external ROP? Both internal and external ROP / ROC must be recorded under the KRI.
92. Would the KRI “Number of replacement of life policy / certificate” be applicable to banks that engage in bancassurance / bancatakaful activity i.e. marketing insurance on behalf of 3rd parties? Yes.
93. What is the scope of reporting the KRI “Number of delay in death claims” where number of death claims paid > 60 days after the notification date? (i) This is only applicable to Life and Personal Accident Death claims including Foreign Workers Compensation Scheme. (ii) The 60 calendar day timeline will commence upon receipt of notification of the claim irrespective complete documentation received or not. [Please refer to Schedule 10 Section 130 Paragraph 12(1) Financial Services Act 2013] [Please refer to Schedule 10 Section 142 Paragraph 12.1 Islamic Financial Services Act 2013]
94. What is the scope of reporting the KRI “Instances of delay in appointing licensed / in-house adjuster” that was done >7 working days from receipt of completed claims documents? The decision whether to appoint adjusters is as defined by REs’ internal policy and procedure. The definition of completed claims documents is as defined by REs’ internal policy and procedure and to comply with the requirements as set out in BNM/RH/GL/003- 9 Guideline on Claims Settlement Practices (Consolidated) and BNM/RH/GL/004- 17 Guideline on Claims Settlement Practices (Consolidated) Takaful. Treasury KRI
95. On the number of trade / deal cancellations and amendments KRI
22
a) What is the definition of a deal/trade in this KRI? The deal/trade is defined from the point of dealer/trader capture/input data in the Treasury system. Hence, any deal/trade amendment/cancellation made by trader/dealer subsequent to the deal creation, need to be captured as this KRI.
The following are scenarios below required reporting in ORION for this Treasury KRI: b) Any cancellations or amendments made by trader/dealer due to customer’s instruction; The KRI is meant to monitor traders’ and/or dealers' behaviour. Hence, any cancellations due to customer’s instruction are not required to be reported as those are genuine cancellation.
c) Any cancellations or amendments that have suspicious / fraud elements; Cancellations or amendments due to suspicious / fraud elements are required to be reported only upon confirmation of fraud as a Loss Event.
d) Any cancellations or amendments due to human error / unintentional ; Cancellations or amendments due to unintentional human error are required to be reported.
e) Any cancellations or amendments without reasoning / justifications. Cancellations without reasoning / justification has to be reported under this KRI.
Scenario Analysis
96. Please define the scenario analysis that BNM is referring to. The scenario analysis will be initiated as an instruction to REs. The instruction can be categorised as follows: (i) Assessment – An assessment initiated by BNM for REs to conduct scenario analyses on the top risks that are unique to the RE. (ii) Assignments – A detailed instruction to perform specific scenario analysis on one specific risk area. (iii) Workshops – A detailed instruction to perform analysis on a few scenarios.
23
Appendix 1: ORION User Guide and Technical Specifications
Issued on: 25 February 2021 Table of Contents
Glossary ...... 6
Organisation of this Document ...... 8
About This Guide ...... 9
.... OVERVIEW ...... 10
Introduction ...... 11 LED Workflow for Online Submission ...... 12 LED Workflow for Batch Submission ...... 13 LED Workflow for Viewing Reports ...... 14 Workflow for Updating Loss Events...... 15 Workflow for Submitting KRI Values...... 16 Workflow for Submitting the KRI Value through Infoport ...... 17 KRI Workflow for Viewing Reports ...... 18 SA Workflow for Responding to Scenarios, Workshops and Assessments ...... 19 SA Workflow for Viewing Reports ...... 20
.... TECHNICAL SPECIFICATION ...... 21
Supported Browser Version ...... 22
Software Requirements for Excel Macros ...... 23
To Enable Macros in Excel 2010 ...... 23
Microsoft Office Driver Requirement ...... 24
Object Libraries Required in Microsoft Office ...... 25
Validation Rules...... 29
.... GETTING STARTED ...... 31
Logging on to the Application ...... 32 Creating a New User ...... 32 Logging on to the Application as an Existing User ...... 36
Basic Elements of the Startup Screen ...... 39
Infocenters ...... 40 BNM Message Board Infocenter ...... 40 LED Infocenter >> Manage Loss Event Sub-Infocenter ...... 40 KRI Infocenter >> Manage KRIs Sub-Infocenter ...... 41 Scenario Analysis Infocenter >> Manage Scenarios and Workshops Sub-Infocenter ...... 41
.... COMMON FUNCTIONS ...... 42
2
Accessing Assignments through My Tasks Menu ...... 43
Form Tool Bar ...... 44
Multi-Window Interface...... 45 User Interface Options ...... 45 Multi-Window Bar > Context-sensitive Menu Options ...... 46
Advanced RTF Editor ...... 47
Sorting and Filtering the List of Values ...... 48
.... EMAIL NOTIFICATIONS ...... 50
Key Risk Indicator Emails ...... 50
Scenario Analysis Emails ...... 51
.... LOSS EVENT DATABASE ...... 53
Creating Loss Events ...... 54 Navigation ...... 54 Loss Event Form > Header Section ...... 55 Loss Event Form > Loss Event Tab ...... 56 Loss Event Form > Impact Tab ...... 60 Loss Event Form > Additional Details Tab...... 65 Form Submission...... 65
Editing Loss Events Details ...... 66 Navigation ...... 66 Form Submission...... 67
Entering Loss Events Details in an Excel Sheet ...... 68 Navigation ...... 69 Details Form > Basic Details Section ...... 71 Details Form > Events Details Section ...... 73 Details Form > Shariah Details Section ...... 75 Details Form > Loss Categorisation Section ...... 77 Details Form > Financial Impacted Area Section ...... 79 Details Form > Financial Section ...... 82 Details Form > Non Financial Section ...... 83 Form Submission...... 84 Uploading the Excel Sheet ...... 85 Navigation ...... 85 Data Upload Form ...... 85 Data Upload Form > Uploading the Loss Event ...... 86 Form Submission...... 87 Viewing the Upload Status ...... 87 Do’s and Don’ts ...... 88
Entering Loss Events Details (Non-Malaysian REs) ...... 89 Navigation ...... 89
3
.... KEY RISK INDICATOR ...... 93
Responding to Key Risk Indicator ...... 94 Navigation ...... 94
Editing KRI Response ...... 95 Navigation ...... 95 KRI Data Entry Form (Edit Mode) ...... 97 KRI Data Entry Form > Details Tab ...... 97 Form Submission...... 97
.... SCENARIO ANALYSIS ...... 98
Responding to Scenarios ...... 99 Navigation ...... 99 Scenario Analysis Response Form ...... 100 Scenario Analysis Response Form > Details Tab ...... 101 Scenario Analysis Response Form > Questions Tab ...... 103 Scenario Form > Additional Details Tab ...... 104 Scenario Form > Action (On Form Submission) Section ...... 105 Form Submission...... 105
Responding to Assessments ...... 106 Navigation ...... 106 Assessment Response Form ...... 106 Assessment Response Form > Header Section ...... 107 Assessment Response Form > Scenario Analysis Section ...... 107 Tree Structure Context-sensitive Menu Options ...... 108 Assessment Response Form > Scenario Analysis Sub-section ...... 112 Assessment Response Form > Comments Section ...... 112 Form Submission...... 113 Task Assignments and Email Notifications ...... 113
.... REPORTS ...... 114
Introduction ...... 114
Accessing Reports ...... 115 Report Filters ...... 115 Report Drilldowns ...... 117 Report Options ...... 117
Loss Event Database Reports...... 118 Loss Events Reports...... 118 Loss Event List Report ...... 118 Loss Event Filter Fields ...... 119 Upload Status Report ...... 121 Upload Status Report Filters ...... 121 Overseas Operational Risk Events Reports ...... 122 Overseas Loss Event List Report ...... 122 Overseas Loss Event List Report Filter Fields ...... 122
Key Risk Indicator Reports ...... 123 Breaches Peer Comparison ...... 123
4
KRI Submission Reports ...... 124
Scenario Analysis Reports...... 125 Scenario Analysis Response Reports ...... 125 List of Scenario Response ...... 125 Workshop Response Report ...... 126 Reporting Entity Scenario Assessment Reports ...... 127 Assessment Response Report ...... 127
Downloading Published Reports ...... 128 Navigation ...... 128
5
Glossary
Infocenter
A common and user specific page that appears to users once they log on to the ORION application. The individual items in the infocenter, such as user forms, assignments, and reports appear on this page.
Infoport
All related objects such as forms, reports and dashboards are grouped under different headings for easy access. One infocenter has one or more infoports.
Landing Page
The default page, which appears for a user after log on.
Key Risk Indicator (KRI)
A submission module that contains the values of the required KRIs.
Threshold
The point that must be exceeded to raise alarm for a probable risk to come in effect.
Scenario
Scenarios are the foreseen risks which are derived based on past data.
Scenario Analysis (SA)
Scenario analysis is conducted to study the impact of risk due to future events which will have effect on a company’s business, reputation and financial position.
6
Workshop
A list of published scenarios which can be assigned to multiple reporting entities.
Assessment
Assessment helps in understanding the prevalent risk scenarios in the financial sector, by gathering scenario data from reporting entities.
Ad Hoc Scenario
A scenario which can be created at any point of time to be assigned to a specific entity
Reports
A tabular representation of data.
Dashboards
Representation of data in the form of charts, such as pie, bar, stacking bar, line, and area.
Multi List of Value (MLOV)
A list that allows a user to select multiple values.
Single List of Value (SLOV)
A list that allows a user to select a single value.
7
Organisation of this Document
The table below summarises the contents of the section contained in this document.
Chapter Chapter Description of Coverage No. Overview Provides an introduction to the modules and the functional workflow. Technical Specification Provides the required technical configurations for the usage of ORION. Getting Started Provides information on registering as a new user and logging on to the ORION application. Common Functions Provides descriptions for the common functions that you encounter. Loss Event Database Provides information on creating and uploading (LED) the loss events. Key Risk Indicator (KRI) Provides information on submitting and editing the KRI values. Scenario Analysis (SA) Provides information on responding to the scenarios and assessments. Reports Provides information on the different reports that you can access.
8
About This Guide
Preface
The BNM — ORION User Guide provides information on using the ORION application for reporting entities. The ORION application is a web-based application.
Document Conventions
The following conventions are used in the document:
Conventions Description
Note: Key pointers, in the form of notes, to help you use this application effectively and efficiently are provided throughout this guide. You can recognise a note when you come across a new paragraph in italics with the word ‘Note’ in red at the beginning of the paragraph. For example: Note: Fields marked with a red asterisk (*) are mandatory.
Boldface All software references appear in boldface. For example: In the Name field…
All acronyms appear in boldface. For example, KRI.
Torn Images Torn images do not contain the entire image; they only contain a portion of the image (a torn image). The portion of the image not visible is shown with torn edges as displayed below.
References to different topics within this User Guide. For example:
For more information, refer to the…
9
Overview
Read this chapter to get an overview of the ORION application and process flows of the Loss Event Database (LED), Key Risk Indicator (KRI), and Scenario Analysis (SA) modules that are a part of ORION application.
This chapter contains the following sections:
Introduction
LED Workflow for Online Submission
LED Workflow for Batch Submission
LED Workflow for Viewing Reports and Dashboards
KRI Workflow for Submitting KRI Values
KRI Workflow for Updating Loss Events
KRI Workflow for Viewing Reports
SA Workflow for Responding to Scenarios and Assessments
SA Workflow for Viewing Reports
10
Introduction
The ORION application comprises of the following modules:
LED: This module enables the Reporting Entity (RE) to create, edit and upload loss events. RE can also view the loss event list report and upload status report.
KRI: This module enables the RE to submit and edit the KRI values. RE can also view reports related to KRI.
SA: This module enables the RE to respond to the assigned scenarios, workshops and assessments. RE can also view the associated response reports.
11
LED Workflow for Online Submission
< Reporting Entity Name > Executive
Login
Click on LED Tab
Click on Manage Loss Events
Click on Data Upload Link
Enter data in online form
Field level data validation (E.g. dependent fields)
Submit
Is there any Yes error Check the error message? and correct it. (Submission validation)
No
Done
Loss Event created and Loss ID generated for new End event
Figure 1 LED Workflow for Online Submission
12
LED Workflow for Batch Submission
< Reporting Entity Name > Executive
Login
Click on LED Tab
Click on Manage Loss Events
Click on Upload Loss Event Link
Download excel template
Fill new loss event data in the excel file
Attach filled excel file in upload loss form
Click on Upload
View Upload Correct the erroneous Status Report records
Yes
Is there any Retain only the error in erroneous record in report? excel
No
Loss event created and Loss ID generated for new End event
Figure 2 LED Workflow for Batch Submission
13
LED Workflow for Viewing Reports
< Reporting Entity Name > Executive, CRO, Group CRO
Login
Click on LED Tab
Click on Loss Click on Operational Event Reports Overseas Risk Report
View Reports View Reports
Download Reports Download Reports
Figure 3 LED Workflow for Viewing Reports and Dashboards
14
Workflow for Updating Loss Events
Reporting entity name Executive Reporting entity name Executive
Login Login
Click on Loss Click on Loss Event Tab Event Tab
Click on a Loss Event List Click on Upload Report Loss Event Link
Search for Loss Event that should be updated Modify Upload Type as Update in a new .xls file Click on a Loss Event Name in the report
Attach filled new xls file in upload loss form Update loss event data
Field level data Click on Upload validation (Eg dependent fields)
View Upload Submit Correct the status report erroneous records Check the error and correct it
Is there any Check Error Is there error template only any message? for the error in (Submission erroneous No report? validation) Yes records
Yes No
Loss event updated Loss event updated by matching by matching Reporting entity ID Reporting entity ID and Internal Loss and Internal Loss Event ID Event ID
Figure 4 Workflow for Updating Loss Events
15
Workflow for Submitting KRI Values
< Reporting Entity Name > Executive, CRO
Login
View KRI /KRI Assignment
Open KRI
Provide value for the KRI
Submit
Figure 5 Workflow for Submitting KRI Values
16
Workflow for Submitting the KRI Value through Infoport
< Reporting Entity Name > Executive, CRO
Login
Click on KRI tab
Click Respond to Assigned KRI Link
Provide value for the KRI
Submit
Figure 6 Workflow for Submitting the KRI Values through Infoport
17
KRI Workflow for Viewing Reports
< Reporting Entity Name > Executive, CRO, Group CRO
Login
Click on KRI tab
Click on KRI Reports
View Reports
Download Reports
Figure 7 KRI Workflow for Viewing Reports
18
SA Workflow for Responding to Scenarios, Workshops and Assessments
Reporting entity Reporting entity Reporting entity Executive Executive Executive
Login Login Login
View Assignment View Assignment View Assignment
View scenario assigned for View assessment View workshop response period assigned for /assessment response details
Open the scenario Open the Open the assessment form workshop
Enter Impact Enter scenario (with analysis) Enter Impact
Respond to questionnaire Submit Respond to questionnaire
Submit Assessment response is now Submit available for analysis and reporting
Scenario response Scenario response is now available for is now available for analysis and analysis and reporting reporting
Figure 8 SA Workflow for Responding to Scenarios, Workshops and Assessments
19
SA Workflow for Viewing Reports
< Reporting Entity Name > Executive, CRO, Group CRO
Login
Click on Scenario Analysis Tab
Click the Reports displayed under the Scenario Analysis Response infoport
View/ Download Reports
Figure 9 SA Workflow for Viewing Reports
20
Technical Specification
Preface The ORION Technical Specification provides the PC Readiness Checklist and validation rules in-built with the ORION application. The Checklist provides information on the system requirements of the ORION application whilst the validation rules sets out the validation done by the application on the data entered by users.
Target Audience This document is intended for the use of Excel template for the batch reporting of loss events.
21
Supported Browser Version
The supported browser version is Internet Explorer version 11.0 & Google Chrome Version above 64.
Please follow the following steps: 1) Please ensure the F12 developer tool default to IE EDGE/IE11 by following the steps below: a. Open IE11 and click on Toggle button to enable F12 developer tool, change IE9 default to IE EDGE/IE11.
22
Software Requirements for Excel Macros
The software requirements for the Excel Macros are as follows: Operating Software Office Driver Windows XP Professional Office 2007 ACE OLEDB Windows 7 Professional Office 2010 ACE OLEDB Windows 7 Professional Office 2013 ACE OLEDB
To Enable Macros in Excel 2010
Perform the following steps: a) Click the File tab. b) Click Options. c) Click Trust Center d) Click Trust Center Settings. The Trust Center1 dialog box opens. e) Click Macro Settings. f) Select Disable All macros with notification. g) Click OK
1 When you change the macro settings in Trust Center, they are changed only for the current Office program. The macro settings are not changed for all the Office programs.
23
Microsoft Office Driver Requirement
1. ACEOLEDB 12.0 is the required DLL for the VB code to execute on the client. This driver is part of the standard Microsoft Office package.
2. To identify if the driver is installed on the machine, follow the instructions below: a) On a 64bit OS; (i) If 32bit is installed "ACEOLEDB.DLL" should exist here: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE14\ACEOLEDB.DLL (ii) If 64bit is installed "ACEOLEDB.DLL" should exist here: C:\Program Files\Common Files\Microsoft Shared\OFFICE14\ACEOLEDB.DLL b) On a 32bit OS; (i) ACEOLEDB.DLL" should exists here: C:\Program Files\Common Files\Microsoft Shared\OFFICE14\ACEOLEDB.DLL
3. If not present, download the correct version (32bit or 64bit) depending on the Target Platform i.e, (AnyCPU, x64, x86). For example: a) For Office 32 bit installation, download ACE 32 bit [x86] b) For Office 64 bit installation, download ACE 64 bit [x64]
24
Object Libraries Required in Microsoft Office
1. For the excel macro to execute, the standard Microsoft Office installation must contain these libraries: a) Visual Basic for Applications b) Microsoft Excel 14.0 Object Library c) Microsoft Forms 2.0 Object Library d) Microsoft ActiveX Data Objects 2.8 Library
2. Follow these steps to check for the object libraries: a) Open a new Excel File. b) Go to the File menu and click Options.
25
3. In the Excel Options window, click Customize Ribbon.
4. Select the Developer tab in the right pane. If Developer tab is not present in this pane, move the Developer tab from the left pane to the right pane by
clicking Add button .
26
5. Click OK. The Developer tab appears in the menu bar.
6. On the Developer menu, click View Code.
7. In the VBA window, click Tools > References.
27
8. In the References dialog box, select the Object Libraries as shown in the image
below:
28
Validation Rules
The application evaluates data entered in accordance to the following rules2: a) Unknown data column validation: It validates incorrect column names in the Excel template submission, whereby the column names and cases have to be exactly the same as in the ORION application. b) Missing data column validation: It ensures that no columns are left empty in the Excel template submission. c) Data type and size validation: It validates the data types in the columns of the Excel template uploaded. E.g. When sending a string value for a date field, user must not exceed the maximum size for a data type, which is 200 characters for free text field. d) Mandatory field validation: It validates all mandatory columns in the Excel template uploaded. E.g. User must not upload the file without filling mandatory data columns. e) List-of-values (LOV) field values validation: It validates the values entered in the LOV fields in the Excel template uploaded. E.g. User must upload using correct LOV values. f) User access validation: It validates that user can upload data only for the entity he / she has access to. E.g. User from Bank A must not be able to view the access by Bank B.
2 For the purpose of understanding the validation rules, this paragraph should be read together with the Operational Risk Reporting Requirements policy document and users should be familiar with the ORION application and User Manual.
29
g) Conditionally required field validation: It validates that conditionally required values are filled based on selection of certain fields. E.g. If user enters value in field "Events For", user must enter value in field "Payment Instrument", which is conditionally required based on value in field "Event For". h) Conditionally required section validation: It validates that conditionally required values are filled based on selection of certain sections. E.g. If user enters value in “Shariah Non-Compliance” as a “Yes”, a conditionally required Shariah Non Compliance section must be filled. i) Dependent field validation: It validates that fields which LOV is dependent on parent field have values based on the parent field. E.g. Level 2 Business Line will be dependent on Level 1 Business Line field validation. j) Event update ID validation: It validates the event ID and status of an event to be updated by a user. E.g. A user cannot update an event with an incorrect event ID. k) Data fields validation: It validates the date fields in that the date must be in correct sequences or some date must be in the past and some dates must be in the future. E.g. “Event Valid Until” should always be current or future date, “Date of Event Detection” should always be current or in the past, and must not be earlier than “Date of Event Occurred”. l) File error handling validation: It provides prompts if there are any error that occurs during the uploading of the Excel template leading to unsuccessful submission.
30
Getting Started
Read this chapter to know about the user interface and infocenters of the ORION application.
This chapter contains the following sections:
Logging on to the Application
Basic Elements of the Startup Screen
Infocenters
31
Logging on to the Application
Creating a New User
Note: The financial institution admin is to create users with the role of ORION-CRO (Oversight), ORION-Submission Officer.
To create a new account, do the following:
In the address bar, type the BNM Portal URL (http://www.bnm.gov.my/) and press Enter. The BNM Portal page appears.
Click the Financial Institutions link.
Figure 10 Accessing the Login Page
Click the FI@KijangNetPortal link.
32
Figure 11 Clicking the Financial Institutions Link.
Click the Register as a Member link.
Figure 12 FI@KijangNetPortal Page
Click the Register tab.
33
Figure 13 FI@KijangNetPortal > Register Page
Click the New Account link.
Figure 14 FI@KijangNetPortal Page > Create New Account
Enter the required details in the fields. Click the Register button.
Financial institution admin to approve registration and assign ORION CRO (Oversight) and ORION Submission Officer Roles for each institution. The
34
email addresses used should be the exact email addresses that were provided to BNM under the roles of CRO and submission officer.
35
Logging on to the Application as an Existing User
To log on the account, do the following:
In the address bar, type the BNM Portal URL (http://www.bnm.gov.my/) and press Enter.
Click the Financial Institutions link.
Figure 15 Accessing the Login Page
Click the FI@KijangNetPortal link.
Ensure “show all content” or “display all information” is enabled.
36
Figure 16 Accessing the Financial Institutions Link.
Enter the Username and Password.
Figure 17 FI@KijangNetPortal Page
Click the Login button.
37
From the home page of FI@Kijangnet, click on ORION, this will bring you to the ORION page.
Figure 18 FI@KijangNetPortal Page
38
Basic Elements of the Startup Screen
Once logged in to the application, you will see a page similar to what is shown in the below image. To get familiarised with the application, refer to the basic elements shown in the image.
Figure 19 Basic Elements of the Startup Screen
Infocenter: This is first level of access in the application.
Sub-Infocenter: This second level of access in the application and it is contained within an infocenter. Infocenter Name: This is name of the active infocenter. It changes as you navigate to different infocenters. Infoport: This is third level of access in the application and it is contained within either infocenter or sub-infocenter. These are boxes that contain links to different forms, reports and so on. My Tasks menu: This is an easiest way of accessing the task assignments. Point to the My Tasks menu to expand the task list. Help menu: This menu contains the general information about the application.
Logout: To log off the application, click this link.
39
Infocenters
BNM Message Board Infocenter
This infocenter is used by the Reporting Entity (RE) to view the BNM message board.
Figure 20 BNM Message Board Infocenter
LED Infocenter >> Manage Loss Event Sub-Infocenter
This infocenter is used by the RE to create loss events, upload loss event data and view the loss event list report.
Figure 21 LED Infocenter >>Manage Loss Event Sub-Infocenter
40
KRI Infocenter >> Manage KRIs Sub-Infocenter
This infocenter is used by the RE to respond to assigned KRI and view reports.
Figure 22 KRI Infocenter>> Manage KRIs Sub-Infocenter
Scenario Analysis Infocenter >> Manage Scenarios and Workshops Sub-Infocenter
This infocenter is used by the RE to respond to scenarios and assessments and view reports.
Figure 23 Scenario Analysis Infocenter >> Manage Scenarios and Workshops Sub-Infocenter
41
Common Functions
Read this chapter to know about the different methods of accessing application forms related to Loss Event Database (LED), Key Risk Indicator (KRI), and Scenario Analysis (SA) and the functionalities available at different stages of the workflow of the ORION application.
This chapter includes the following sections:
Accessing Assignments through My Tasks Menu
Form Tool Bar
Multi-Window Interface
Advanced RTF Editor
Sorting and Filtering the List
42
Accessing Assignments through My Tasks Menu
In addition to accessing the assignments from the respective infoports, you can also access event assignments from the My Tasks menu at the top of the ORION home page.
Figure 24 My Tasks Menu
An event assignment may have one of the following states:
Completed (link appears in black)
Past due date (link appears in red)
New (link appears in green)
To access an event assignment from the My Tasks menu, perform the following steps:
Point to the My Tasks menu at the top of the ORION home page. The list of assignments appears as a drop-down.
Click the assignment you need to work on. The relevant form appears. To navigate to the next page or previous page in the My Tasks menu, click the
forward arrow or backward arrow respectively.
To refresh and get the latest assignments, click the Refresh icon .
Note: To see the latest data, users may refresh the My Tasks periodically.
Note: To navigate to a particular page directly, enter the page number in the Page field and press the Enter key on your key board.
43
Form Tool Bar
The forms available in the ORION application include a common tool bar, which comprises of a set of icons to perform various actions. The below table provides the list of form tool bar icons and their descriptions.
Note: These are the standard form tool bar icons available across all the ORION applications. However, all the icons may not be available in all the forms. The display of these icons is customised based on the function and usage of the form.
Click the… To… Submit the form’s contents and route to the next workflow step based on the action or selected.
Submit Save the form’s contents as a working draft for the user without processing it to the next
Save Draft workflow step and keep the form open.
Save the form’s contents as a working draft for the user without processing it to the next workflow step and close the form. Note: You can access the form through My Save Draft & Close Tasks at a later time and continue working.
View the reports related to this form. Note: This is not an action on the form. Note: On clicking this icon, a list of inline View Reports reports appears. Click the required report name to view the details.
Cancel the changes made to the form and close it. or
Cancel
44
Multi-Window Interface
Multi-window interface feature enables you to open one or more infocenters, sub- infocenters, forms, reports, or dashboards simultaneously within the main window of the ORION application. This helps you to work on multiple windows without closing the page that is currently open.
User Interface Options
To work on multi-window interface, the following icons are available in the upper- right corner of the ORION application.
Figure 25 User Interface Options Pin icon : Click this icon to pin a particular form, report, or infocenter.
Unpin icon Click this icon to unpin the pinned form, report, or infocenter.
Note: The maximum number of windows that you can pin is 3.
Minimise icon : Click this icon to minimise the window.
Maximise icon : Click this icon to maximise the window.
Close icon : Click this icon to close the window.
Figure 26 Multi-Window Interface
45
Pinning and Unpinning Windows:
To pin the window that you are currently working on, click the pin icon. The window is now pinned to the bottom of the screen.
When a window is pinned, the pin icon changes to the unpin icon.
Multi-Window Bar > Context-sensitive Menu Options
The context-sensitive options allow you to switch from one window to another. To access the context-sensitive menu, right-click the window name. The different options appear as shown in the following image.
Note: To view the pinned window, you may also click the window name in the multi- window bar of the application.
Figure 27 Multi-Window Bar > Context-sensitive Menu Options
The context-sensitive menu options are available or unavailable based on the function that you perform in the User Interface Options. For example, if you click the Minimise icon, the Minimise option is unavailable in the context-sensitive menu options and vice versa.
The options in the context-sensitive menu appear based on the state of the window. For example, if you have already minimised the window, then you can only restore, maximise or close the window.
46
Advanced RTF Editor
Advanced Rich Text Format (RTF) editor allows you to:
Enter, edit, and format the information
Enter and edit comments
To work on the Advanced RTF Editor, click the rich text icon adjacent to the RTF field.
Figure 28 Rich Text Icon The Advanced RTF Editor window appears.
Figure 29 RTF Editor
Note: If the RTF field is non-editable, the rich text icon adjacent to the RTF form field is greyed out . This icon indicates that you cannot enter any information in the RTF Editor.
47
Sorting and Filtering the List of Values
In a list, you can narrow down the scope of search based on your search criteria.
Figure 30 Sorting and Filtering the List of Values The following table provides information on the different options available in the list field.
To… Do this…
Narrow down the list of values based on Enter a keyword in the Search field with “%” a keyword before and after the keyword and click Go.
Select the check box of the option and click Add the selected the option(s) to the list Select.
Cancel the selected option and close Click Cancel. the window
Select all the options in the list Click Check All.
Deselect the selected options in the list Click Clear All.
Get all the options in one page Click Get All.
Click Get Selected. Note: This button is available only if the user has selected an option from the list. View only the selected option in the list Note: When you click Get Selected, it is replaced by Back. You can click Back to
48
To… Do this…
go back to the previous list.
49
Email Notifications
Read this chapter to know about the email notifications that are sent automatically for every action performed in the ORION application.
This chapter contains the following procedures:
Key Risk Indicator Emails
Scenario Analysis Emails
Key Risk Indicator Emails
Refer to the following table for information on e‐mail notifications that are triggered on submitting the KRI definition form in the KRI module of the ORION application:
To Workflow Stage Subject Sent When the… Reporting Entity Provide KRI Value Provide
CRO Edited KRI Form KRI
CRO and Reporting Overdue KRI Form KRI Response overdue KRI form is overdue. Entity Executive
50
Scenario Analysis Emails
Refer to the following table for information on e‐mail notifications that are triggered in the SAM module of the ORION application:
To Workflow Stage Subject Sent When the… Reporting Entity Ad-hoc Assignment of [:Object_ID]: Supervisor assigns an Executive Scenario ObjectName has been ad-hoc scenario. This assigned to you for e-mail is sent to notify response. the RE executive to work on ad-hoc assignment.
Reporting Entity Workshop Assignment Scenario - [:Object_ID]: Supervisor assigns the Executive ObjectName has been workshop assignment. assigned to you for This e-mail is sent to response. notify the RE executive to work on workshop assignment.
Reporting Entity Reminder e-mail: Scenario - [:Object_ID] RE executive does not Executive Scenario :ObjectName response provide a response to is due in next 24 hrs’ the scenario. This e- mail is sent to notify the RE executive that the scenario is due.
Reporting Entity Reminder e-mail: Workshop - RE executive does not Executive Workshop [:Object_ID] provide a response to :[Workshop Name the workshop. This e- ]response is due in mail is sent to notify next 24 hrs’ the RE executive that the workshop is due.
Reporting Entity Reminder e-mail: Workshop - RE executive does not Executive Assessment [:Object_ID] provide a response to :[Workshop Name] the assessment. This response is due in next e-mail is sent to notify 24 hrs’ the RE executive that the assessment is due.
Reporting Entity Escalation e-mail: Scenario - [:Object_ID] RE executive does not Executive and CRO Scenario :[Scenario Name] provide a response to response overdue the scenario. This e- mail is sent to notify the RE executive and CRO that the scenario is overdue.
51
To Workflow Stage Subject Sent When the… Reporting Entity Escalation e-mail: Workshop - RE executive does not Executive and CRO Workshop [:Object_ID] provide a response to :[Workshop the workshop. This e- Name]response is mail is sent to notify overdue the RE executive and CRO that the workshop is overdue.
Reporting Entity Escalation e-mail: Workshop - RE executive does not Executive and CRO Assessment [:Object_ID] provide a response to :[Workshop Name] the assessment. This response is overdue e-mail is sent to notify the RE executive and CRO that the assessment is overdue.
Reporting Entity Ad-hoc Assessment Scenario - [:Object_ID]: BNM user assigns the Executive [Assessment Name] ad-hoc assessment. has been assigned to This e-mail is sent to you for response notify the RE executive to work on new assessment.
Reporting Entity Scenario Published Scenario Published RE executive provides Executive a response to the scenario. This e-mail is sent to the RE executive as an acknowledgement that the scenario response (either by workshop / ad-hoc assignment) has been accepted by BNM user.
52
Loss Event Database
Read this chapter to know about the procedures, forms and fields of the Loss Event Database (LED) module of the ORION application.
This chapter contains the following procedures:
Creating Loss Events
Editing Loss Events Details
Entering Loss Events Details in an Excel Sheet
Entering Loss Events Details (Non-Malaysian Res)
53
Creating Loss Events
The Reporting Entities (REs) can record the loss events. The REs can capture details related to the event, including the nature of the event, type of event, location of the event, and the impact of the event.
Note: To create loss events reports, use the Loss Event form. The fields marked with a red asterisk (*) are mandatory.
Navigation
To access the Loss Event form, do the following:
Navigate to the LED Infocenter >> Manage Loss Events Sub-Infocenter >> Create Loss Event infoport.
Figure 31 Accessing the Loss Event Form
Click the Loss Event Form link.
Figure 32 Loss Event Form
54
Figure 33 Loss Event Form (Continued…)
Loss Event Form > Header Section
Use this section to select high-level details of the loss event.
Figure 34 Loss Event Form > Header Section
Field Name Description Reporting Enter the name of reporting entity. Entity Name Reporting This field is populated based on the reporting entity name. It shows the Entity ID identification number of the reporting entity. (read-only) Date Of Event This field is auto-populated. It shows the date when the loss event is Reporting created. Nature of Event Select the nature of the loss event. The following options are available: New Repeated
55
Field Name Description Event Select the event classification. The following options are available: Classification Actual Loss Potential Loss Near Misses Note: If you select Actual Loss, then the fields such as Board Reporting Date and Shariah Committee Reporting Date become mandatory. Islamic If the event is related to an Islamic Business, or if the RE has any Islamic Business check products that are used, select the check box. box Shariah Non- Select the Shariah Non-Compliance from the available options: Compliance Yes: If the event is not compliant to Shariah law, select Yes. No: If the event is compliant to Shariah law, select No.
Loss Event Form > Loss Event Tab
Use this tab to capture details related to the loss event, such as the Basel categorisations, the location, and the date when it occurred and reported.
Figure 35 Loss Event Form > Loss Event Tab
56
Figure 36 Loss Event Form > Loss Event Tab (Continued…)
Field Name Description Event Details Loss Event Name Enter the loss event name. Note: You can report multiple loss events with the same name.
Internal Loss event ID Enter the internal loss event ID.
Level 1 Business Line Select the level 1 business line of the loss event. The values that are available depend on the RE type for the loss event. Note: This field will not appear for the Payment System Regulatees.
Level 2 Business Line Select the level 2 business line of the loss event. The (appears only if you select values that are available depend on the RE type and the the value in the Level 1 level 1 business line. Business Line field)
Level 3 Business Line Select the level 1 business line of the loss event. The (appears only if you select values that are available depend on the RE type and the the value in the Level 2 level 2 business line. Business Line field)
Product/Services Select the product or service applicable for the loss event. (appears only if you select The values that are available depend on the level 3 the value in the Level 3 business line. Business Line field)
57
Field Name Description Delivery Channel Select the delivery channel for the loss event. The values that are available depend on the level 1 business line. Business Line Enter the comments. Comments (appears only if Others is selected in the Business Line and Delivery Channel field.)
Level 1 Event Category Select the level 1 event category of the loss event. The values that are available depend on the RE type for the loss event. Note: This field will be auto-populated for Payment System Operators.
Level 2 Event Category Select the level 2 event category line of the loss event. The (appears only if you select values that are available depend on the RE type and the the value in the Level 1 level 1 event category. Event Category Line field)
Level 3 Event Category Select the level 3 event category of the loss event. The (appears only if you select values that are available depend on the RE type and the the value in the Level 2 level 2 event category. Event Category field)
Level 1 Causal Category Select the level 1 causal category of the loss event. The values that are available depend on the RE type for the loss event. Note: This field will not appear for the Payment System Regulatees.
Level 2 Causal Category Select the level 2 causal category of the loss event. The (appears only if you select values that are available depend on the RE type and the the value in the Level 1 level 1 causal category. Causal Category field)
Level 3 Causal Category This field is populated based on RE type and the level 2 (appears only if you select causal category. the value in the Level 2 Select the level 1 causal category of the loss event. The Causal Category field) values that are available depend on the RE type and the level 2 causal category.
Causal Category Enter the comments related to causal category. Comments (appears only if Others is selected in the Level 2 Causal Category field.)
58
Field Name Description Countries Of Event Select one or more countries where the loss event occurred. The value Malaysia appears by default.
State Of Event Select one or more states where the loss event occurred. (appears only if you select Malaysia in the Countries Of Event field)
Districts Of Events Select one or more districts where the event occurred. (appears only if you select Malaysia in the Countries Of Event field)
Date Of Event Select the date when the loss event occurred. Occurrence Date Of Event Detection Select the date when the loss event was reported.
Loss Event Description Enter a detailed description for the loss event.
Shariah Details Shariah Primary Select the Shariah primary contract. Contract (MLOV) Shariah Supporting Select the Shariah secondary contracts. You can select Contracts multiple contracts. Shariah Source of Select the source of detection. You can select multiple Detection sources. Board Reporting Date Select the date when the non-compliance was detected. Shariah Committee Select the date when the non-compliance was reported to Reporting Date the Shariah committee.
Shariah Date Resolved Select the date when it is resolved. Note: The date should be less than or equal to the current date. No of Accounts Involved Enter the number of Shariah accounts involved. Note: This field only accepts numeric inputs. Shariah Decision Enter the decision taken by the Shariah committee. Action Taken Enter the action implemented to abide the decision. Event Validity Event Valid Till Enter the date till when the event was valid. Reason Enter the reason for the end date of the event.
59
Loss Event Form > Impact Tab
Use this tab to capture details related to the financial or non-financial impact of the loss event. Apart from the values that appear for the Event Impact field (Financial and Non-Financial), the other field values are dependent on the RE type.
Figure 37 Loss Event Form > Impact Tab
Field Name Description Event Impact Select the following options : Financial: If there is a financial impact caused by the loss event, select Financial. Non- Financial: If there is no financial impact caused by the loss event, select Non-Financial. If there is both a financial and a non-financial impact caused by the loss event, select both. Note: If the event is a near miss, there is neither a financial nor a non-financial impact.
Financial Details (appears only if you select the event impact as Financial) Events For Select the event for which the loss is applicable to. The values that appear here depend on the RE type. The following options are available if you are a banking institution, prescribed development FI, or a payment system regulate user: ATM Acquirer Banking Payment Channel Payment Instrument The following option is available if you are a licensed institution or takaful operator user: Insurance
60
Insurance Category Select the insurance category. The following options are (appears only if you select available: Insurance in the Events Assets For field) Claims Premium Re insurance Intermediaries Others NA Boundary Event Select the following options: (appears only if you select Yes: If the event is a boundary event, select Yes. Banking in the Events No: If the event is not a boundary event, select No. For field) Note: This field is applicable only for banking institution, prescribed development FI, and payment system regulatee users.
Related To Select the following options: (appears only if you select Credit Risk: If the event is related to a credit risk, Yes in the Boundary select Credit Risk. Event field) Market Risk: If the event is related to a market risk, select Market Risk. Note: This field is applicable only for banking institution, prescribed development FI, and payment system regulatee users. Payment Instrument Select the type of card that was used. (appears only if you select Note: If you choose E-Money in this field and Network ATM Acquirer or Based option in the Modus Operandi field, then Card Payment Instrument in Brands and Card Types fields will show NA automatically. the Events For field) Card Brands Select the card brand. The values that are available here (appears only if you select depend on the value you select in the payment instrument ATM Acquirer or field. Payment Instrument in Note: This field is applicable only for card-related loss the Events For field) events. Note: If you choose E-Money in Payment Instrument and Network Based option in the Modus Operandi field, then Card Brands will show NA automatically. Card Brands Comments Enter the comments related card brands. (appears only if you select Others in the Card Brands field)
61
Card Types Select the card type. (appears only if you select Note: This field is applicable only for card-related loss the value in the Payment events. Instrument field or if you select Payment Note: If you choose E-Money in Payment Instrument and Instrument in the Events Network Based option in the Modus Operandi field, then For field) Card Types will show NA automatically.
Card Types Comments Enter the comments related to card types. (appears only if you select Others in the Card Types field)
Source of Detection Select the source of detection. (appears only if you select Cheque in the Payment Instrument field)
Source of Detection Enter the comments related to source of detection. Comments (appears only if you select Others in the Source of Detection field)
Type of Cheque Issuers Select the type of cheque issuer. (appears only if you select Cheque in the Payment Instrument field)
Payment Channel Select the payment channel that was used. (appears only if you select Payment Channel in the Events For field) Account Type Select the account type. The following options are (appears only if you select available: Payment Channel in the Individual Events For field) Corporate Others (Please Specify) Account Type Enter the comments related to account type. Comments (appears only if you select Others in the Account Type field) Business Activity Select the business activity. (appears only if you select Payment Instrument in the Events For field)
62
Business Activity Enter the comments related to business activity. Comments (appears only if you select Others in the Business Activity field)
Modus Operandi Select the modus operandi used. The values that are (appears only if you select available here depend on the value you select in the Payment Channel or Payment Channel field. Payment Instrument in the Events For field)
Modus Operandi Enter the comments related to modus operandi. Comments (appears only if you select Others in the Modus Operandi field)
Amount Involved(In Enter the amount involved in MYR. MYR) Loss By Banks (The value that appears here depends on the value you select in the Events For field.) Incurred By To enter the amounts related to the RE, 3rd party, and customer and others, click the icon in line with the respective entity in the table row. The related fields appear below. The amount that you enter in the fields appear in the table row in line with the entity. Actual Loss(In MYR) Enter the amount of actual loss.
Recovery Amount(In Enter the amount recovered. MYR)
Potential Loss Enter the potential loss amount. Amount(In MYR) Comments Enter the comments related to loss incurred by the banks.
Total Actual Loss This field is populated based on the amount entered in the Actual Loss field. It shows the sum of amounts entered in the Actual Loss field of RE, Customer and 3rd party.
Total Recovery Amount This field is populated based on the amount entered in the Recovery Amount field. It shows the sum of amounts entered in the Recovery Amount field of RE, Customer and 3rd party.
63
Total Potential Loss This field is populated based on the amount entered in the Amount Potential Loss field. It shows the sum of amounts entered in the Potential Loss field of RE, Customer and 3rd party.
Non Financial Details (appears only if you select the event impact as Non Financial) Impact Select the non-financial impact due to the loss. The following options are available: Low Medium High Comments Enter the comments related to non-financial impact.
Note: After adding the loss amount details under Impact tab, fields such as Amount Involved, Net Potential Loss and Net Actual Loss get added in the header section of the form.
64
Loss Event Form > Additional Details Tab
Use this tab to attach files related to the loss event.
Figure 38 Loss Event Form > Additional Details Tab
Field Name Description Created By This field is auto-populated. It shows the name of the RE who has created the loss events details. Created On This field is auto-populated. It shows the date when has entered the loss event details for the first time. Modified By This field is auto-populated. It shows the name of the RE who has updated the loss event details. Modified On This field is auto-populated. It shows the date when the details have been updated. Attach Files To upload the file, click the Browse button, and select the file from your local drive. The file gets attached and the name of the file that you attached appears.
To delete an attached file, click the Cancel icon on the right side of the attached file.
Form Submission To take an action on the current form, refer to the Form Tool Bar section.
65
Editing Loss Events Details
The REs can edit or update the details of the loss events.
Navigation
To access the Loss Event form, do the following:
Navigate to the LED Infocenter >> Manage Loss Events Sub-Infocenter >> Loss Events Reports infoport.
Figure 39 Accessing the Loss Event List Report
Click the Loss Event List Report link.
Figure 40 Loss Event List Report
Click the required Loss Event ID. The Loss Event Form appears.
66
Figure 41 Loss Event Form
Edit the details of the required fields.
Refer the Creating Loss Events section to edit the fields of the form.
Form Submission
To take an action on the current form, refer to the Form Tool Bar section.
67
Entering Loss Events Details in an Excel Sheet
As an RE, you can enter multiple loss event details in an excel sheet. This form contains a predefined data format using which users can enter loss data.
There are four worksheets in the excel sheet:
Form
Loss Event Details
Loss by Malaysian Entities
Loss by Foreign Entities
RE should enter loss event details in the Form worksheet. After submitting the data in the Form worksheet, click CTRL+S to save the details in the other three worksheets.
These worksheets (Loss Event Details, Loss by Malaysian Entities and Loss by Foreign Entities) are used only as a reference while uploading the excel sheet in the ORION application. These worksheets are non-editable.
Note: Fields marked with a red asterisk (*) are mandatory.
Note: On adding a new record in the second or subsequent row of the excel sheet, fields such as User Name, Institution ID, Licensed Financial Institution and Industry get populated based on the first record of the excel sheet.
68
Navigation
To enter the details of the loss event in the excel sheet, perform the following steps:
Open the excel sheet.
Figure 42 Loss Management Excel Sheet
In the column Upload Type, select the option based on the event type:
o New: If the loss event has recently occurred, select this.
o Update: If you are modifying the details of an existing loss event, select this.
69
Click the Edit Row button. The Details form appears.
Figure 43 Details Form
Note: If the loss event is new, Loss Event ID field will be non-editable and shows the ID which has been entered in Internal Loss Event ID.
Note: If you are updating the details of existing loss event, Loss Event ID field will be editable. You can enter the ID from the ORION application.
70
Details Form > Basic Details Section
Use this section to enter the basic details of the loss events
Figure 44 Details Form > Basic Details Section
Field Name Description User Details User Name Enter the name of the user. Note: It should be same as username which is used to login ORION application.
Loss Event ID Loss Event ID This loss event ID is used only as a reference. After the excel is uploaded (read-only) successfully, the ORION system generates a unique loss event ID against each loss event ID provided in the excel sheet for reference. Note: When you update an existing loss event, replace the reference event loss ID with the system-generated loss event ID.
Internal Loss Enter the internal loss event ID. It is used by RE to capture their internal loss Event ID event and to identify whether there is any duplicate entry or not.
Loss Event Enter the name of the loss event. Name
71
Reporting Entity Type Select the reporting entity type. The following options are available: Licensed Banking Institution Licensed Insurance Companies & Takaful Operators Payment System Regulatees Prescribed Development Financial Institutions
Industry Based on the RE type, the values get populated in the drop-down list. You can select the desired industry from the drop-down list.
Name Enter the name of the reporting entity.
ID Enter the ID of reporting entity.
Amount Involved Amount Enter the amount involved in the loss event. Involved Net Actual This field is populated based on the amount entered in the Financial tab. Loss (read-only)
Net Potential This field is populated based on the amount entered in the Financial tab. Loss (read-only)
72
Details Form > Events Details Section
Use this section to enter the details of the loss events.
Figure 45 Details Form > Events Details Section
Field Name Description Event Impact (MLOV) Select the desired value from the list and click the Add button to move the value to the field in the right. This is an MLOV field The following options are available: Financial: If there is a financial impact caused by the loss event, select Financial. Non- Financial: If there is no financial impact caused by the loss event, select Non-Financial. If there is both a financial and a non-financial impact caused by the loss event, select both. Based on the selection, Financial or Non-Financial tab appears in the form. Note: You can only select one value at a time. You cannot use the CTRL key to select multiple values. Note: Click Clear to remove the value from the field.
73
Field Name Description Islamic Use this field to indicate whether the loss event is related to an Islamic Business business or not. The following options are available: Yes: If the event is related to Islamic Business, select Yes. No: If the event is not related to Islamic Business, select No.
Shariah Non- Use this field to indicate whether the loss event is related to Shariah non- Compliance compliance or not. The following options are available: (appears only if Yes: If the event is not compliant to Shariah law, select Yes. the event is No: If the event is compliant to Shariah law, select No. related to Islamic Based on the selection, the Shariah Details tab appears in the form. Business) Date of Event Enter the date when the event has been detected. Detection Date of Event Enter the date when the event has occurred. Occurrence Event Select the classification of the event. The following options are available: Classification Actual Loss Potential Loss Near Misses Nature of Select the nature of the event. The following options are available: Event New Repeated Loss Event Enter the description of the loss event. There is a limitation of maximum Description number of characters that can be input when entering a loss event
Countries of Event (MLOV) Select the desired value from the list and click the Add button to move the value to the field in the right. This is an MLOV field Note: You can only select one value at a time. You cannot use the CTRL key to select multiple values. Note: Click Clear to remove the value from the field. State of Event (MLOV) Select the desired value from the list and click the Add button to move the value to the field in the right. This is an MLOV field Note: You can only select one value at a time. You cannot use the CTRL key to select multiple values. Note: Click Clear to remove the value from the field. Districts of Event (MLOV) Select the desired value from the list and click the Add button to move the value to the field in the right. This is an MLOV field Note: You can only select one value at a time. You cannot use the CTRL key to select multiple values. Note: Click Clear to remove the value from the field.
74
Details Form > Shariah Details Section
Use this section to enter the details of the Shariah non-compliance.
Figure 46 Details Form > Shariah Details Section
Field Name Description This tab appears only if the loss event is related to Shariah Non-Compliance. Shariah Select the Shariah primary contract. Primary Contract Note: Click Clear All to remove the value from the field. (MLOV)
Shariah Supporting Select the desired value from the list and click the Add button to Contracts move the value to the field in the right. This is an MLOV field (MLOV) Note: You can only select one value at a time. You cannot use the CTRL key to select multiple values. Note: Click Clear to remove the value from the field.
Shariah Source of Select the desired value from the list and click the Add button to Detection move the value to the field in the right. This is an MLOV field (MLOV) Note: You can only select one value at a time. You cannot use the CTRL key to select multiple values. Note: Click Clear to remove the value from the field. Shariah Enter the date when the event has been reported to the Shariah committee. Committee Reporting Date Board Enter the date when the event has been reported to the Shariah committee. Reporting Date
75
Field Name Description Date Enter the date when the event has been resolved. Resolved No of Enter the number of accounts that have been impacted due to the loss event. Accounts Involved Shariah Enter the decision taken by Shariah committee for loss event. Decision Actions Taken Enter the actions taken by Shariah committee for loss event.
Event Valid Enter the date till when the event was valid. Till Reason Enter the reason for the end date of the event.
76
Details Form > Loss Categorisation Section
Use this section to enter the details of the loss categories.
Figure 47 Details Form > Loss Categorisation Section
Field Name Description Level 1 Business Select the level 1 business line of the loss event. Based on the RE type, Line the values get populated in the drop-down list. Note: This field will not appear for the Payment System Regulatees.
Level 2 Business Select the level 2 business line of the loss event. The values that are Line available depend on the value selected in the Level 1 Business Line field.
Level 3 Business Select the level 2 business line of the loss event. The values that are Line available depend on the value selected in the Level 2 Business Line field.
Product/Services Select the product or service applicable for the loss event. The values that are available depend on the value selected in the Level 3 Business Line field. Delivery Channel Select the delivery channel from the drop-down list.
77
Field Name Description Business Enter your comments. Line/Product Services/Delivery Channel Comments (appears only if Others is selected in the Delivery Channel field)
Level 1 Event Select the level 1 event category of the loss event. Based on the RE type, Category the values get populated in the drop-down list. Level 2 Event Select the level 2 event category of the loss event. The values that are Category available depend on the value selected in the Level 1 Event Category field. Level 3 Event Select the level 3 event category of the loss event. The values that are Category available depend on the value selected in the Level 2 Event Category field.
Comments Enter the comments. (appears only if Others is selected in the Level 3 Event Category field.)
Level 1 Causal Select the level 1 causal category of the loss event. Based on the RE type, Category the values get populated in the drop-down list. Note: This field will not appear for the Payment System Regulatees.
Level 2 Causal Select the level 2 causal category of the loss event. The values that are Category available depend on the value selected in the Level 1 Causal Category field.
Level 3 Causal Select the level 3 causal category of the loss event. The values that are Category available depend on the value selected in the Level 2 Causal Category field.
Comments Enter your comments. (appears only if Others is selected in the Level 3 Causal Category field.)
78
Details Form > Financial Impacted Area Section
Use this section to enter the details of the financial impacted area.
Figure 48 Details Form > Financial Impacted Area Section
Field Name Description Event For Select the event for which the loss is applicable. The values that appear here depend on the RE type. The following options are available if you are a licensed banking institution or prescribed development financial institutions: ATM Acquirer Banking Payment Channel Payment Instrument The following options are available if you are a licensed insurance companies & takaful operators: Insurance & Takaful Operators The following options are available if you are a payment system regulatees: Payment Channel Payment Instrument
Note: Based on value selected in the Event For field, other fields appear in the form.
Payment Select the payment instrument. Instrument
79
Field Name Description Card Brands Select the brand of the card.
Card Brands Enter the comments related to card brands. Comments (appears only if Others is selected in the Card Brands field.) Card Types Select the card types.
Card Types Enter the comments related to card types. Comments (appears only if Others is selected in the Card Types field.)
Boundary of Select the option if it is boundary of event: Event (appears Yes only if Banking is No selected in the Events For field.)
Payment Select the payment channel which was used. The following options are Channel (appears available: only if Payment Internet Banking Channel is Mobile Banking selected in the Events For field.)
Account Type Select the type of account. The following options are available: Individual Corporate Others (please specify)
Account Type Enter the comments related to account type. Comments (appears only if you select Others in the Account Type field)
Modus Operandis Select the modus operandi used. The values that are available here depend on the value you select in the Payment Channel field. The following options are available: Phishing – SMS Phishing – Email Phishing – Telephone Others (please specify)
80
Field Name Description Modus Operandis Enter the comments related modus operandi. Comments (appears only if you select Others in the Account Type field)
Payment Select the payment instrument. The following options are available: Instrument Charge Card (appears only if Cheque you select Credit Card Payment Debit Card Instrument in the E-Money Event For field)
Business Activity Select the business activity.
Modus Operandi Select the modus operandi.
Source of Select the source of detection. Detection (appears only if you select Cheque in the Payment Instrument field)
Source of Enter the comments related to source of detection. Detection Comments (appears only if you select Others in the Source of Detection field)
Type of Cheque Select the type of cheque issuer. Issuers (appears only if you select Cheque in the Payment Instrument field)
81
Details Form > Financial Section
Use this section to enter the financial details such as actual loss, potential loss amount etc.
Figure 49 Details Form > Financial Section
Field Name Description Actual Loss (In Enter the actual loss amount. MYR) Note: The amount entered in this field reflects in the Amount Involved section of the Basic Details tab.
Note: Actual loss should be less than or equal to the amount involved. Recovery Enter the amount recovered. Amount (In MYR) Note: Recovery amount should be less than or equal to the amount involved.
Potential Loss Enter the potential loss amount. Amount (In MYR) Note: The amount entered in this field reflects in the Amount Involved section of the Basic Details tab. Note: Potential loss amount should be less than or equal to the amount involved.
82
Details Form > Non-Financial Section
Use this section to enter the non-financial details.
Figure 50 Details Form > Non Financial Section Field Name Description Impact Select the impact: High Low Medium Non Financial Enter the comments related to non financial impact. Impact Comment
83
Form Submission
To take an action on the current form, refer to the following table:
Click the… To… Submit the form’s contents in the sheet named as “form”. However, the data will not be
Submit Note: Press CTRL+S to save the data in the excel sheet. The data appears in the excel sheet only after the form is saved. Close the form.
Close Go to the next record. On clicking the Next button, a dialog box appears prompting the user to save the changes. If you have already saved the details, click No. It directs you to the next record. Next If you have not saved the details, click Yes and then click the Submit button. It directs you to the next record. Go to the previous record. On clicking the Prev button, a dialog box appears prompting the user to save the changes. If you have already saved the details, click No. It directs you to the previous
Prev record. If you have not saved the details, click Yes and then click the Submit button. It directs you to the previous record. Note: To know more information on entering details in the form, refer to the Creating Loss Event Form section.
Note: If a user updates anything in one of the column in the excel sheet, it gets reflected in the form. Similarly, any update done in the form is reflected in the excel sheet.
Note: Validation happens only after uploading the excel template in the ORION system.
84
Uploading the Excel Sheet
As an RE, you can upload multiple loss events into the ORION application using the Data Upload form.
Note: Fields marked with a red asterisk (*) are mandatory.
Navigation
To upload loss events, perform the following steps:
Navigate to the LED Infocenter >> Manage Loss Events Sub-Infocenter >> Create Loss Event infoport.
Figure 51 Accessing the Loss Event Form to Create a Loss Event
Click the Data Upload link.
Data Upload Form
Figure 52 Data Upload Form
85
Data Upload Form > Uploading the Loss Event
Figure 53 : Data Upload Form > Uploading the Loss Event
Field Name Description Upload Type Select the upload type Data Form. The following options are available: System Entities Data Form Select Module Select the module. When you select LDM, the following links appear: Download Banking Template Download Insurance Template Download DFI Template Download Payment Instrument Template You can download the required template, enter values, and upload it back into the ORION application. Select Data Form This field is populated based on the value selected in the Select Module field. Select Profile This field is populated based on the value selected in the Select Module field. Select System Select the system entities. The following options are available: Entities Organization (appears only if Organization Hierarchy System Entities is Organization Locations selected in the Roles Upload Type field.) UserOrgRoles Users
86
Field Name Description Select file to To upload the file, click the Browse button, and select the file from your upload local drive. The file gets attached and the name of the file that you attached appears.
To delete an attached file, click the Cancel icon on the right side of the attached file.
Download Click to download the template. Template Link
Form Submission
To take an action on the current form, refer to the Form Tool Bar section.
Viewing the Upload Status
Once you click Submit, navigate to the LED Infocenter >> Loss Event Reports Infoport >> Upload Status Report link.
Figure 54 Upload Status Report
To view the success template, click the Success Template link.
To view the error template, click the Error Template link. The description of the error is provided as shown below.
87
Figure 55 Accessing the Error Template Link
The error(s) appear as shown below.
Figure 56 Viewing the Error Template
Note: If any of the mandatory fields are left blank, the system does not allow you to upload the excel sheet.
Do’s and Don’ts
The following table provides information on the do’s and don’ts which you need to follow while entering details in the excel sheet.
Do Don’t
Read the PC Readiness Checklist Delete first four rows and columns of the sheet. document.
Enter the details in the Form worksheet. Enter the details in Meta Data, Loss Event Details, Loss by Malaysian Entities and Loss by Foreign Entities worksheet.
Use correct case for entering username. Press Ctrl key to select MLOV. Username is case sensitive.
Select the date from date picker. Enter the date manually in the date field.
Follow the tool tip. Add rows above the header in the excel template i.e. Row 1 to 3 should not be edited/modified.
Click the Add/Edit button to enter or Edit the rows manually. update the details of the values of the rows
88
Entering Loss Events Details (Non-Malaysian REs)
If the branches of Reporting Entities (REs) are located outside Malaysia, they can record the loss events details using the Overseas Subsidiary Form. The REs can capture details related to the event, including the nature of the event, type of event, location of the event, and the impact of the event.
Note: To enter the loss events details, use the Overseas Subsidiary Form. The fields marked with a red asterisk (*) are mandatory.
Navigation
To access the Overseas Subsidiary Form, do the following:
Navigate to the LED infocenter >> Manage Loss Events Sub-Infocenter >> Overseas infoport.
Figure 57 Accessing the Overseas Subsidiary Form
Click the Overseas Subsidiary Form link.
Figure 58 Loss Event Form
89
Overseas Subsidiary Form > Header Section Use this section to enter the high-level details of the loss events.
Figure 59 Overseas Subsidiary Form > Header Section
Field Name Description Date of Event This field is auto – populated. It shows the date when the loss event is Reporting created. Reporting Entity Name Select the name of reporting entity. Reporting Entity This field is populated based on the reporting entity name. It shows the ID (read-only) identification number of the reporting entity. Select the event classification. The following options are available: Event Actual Loss Classification Potential Loss Near Misses
Overseas Subsidiary Form > Loss Event Details Tab Use this section to enter the loss events details, such event name, countries, description and so on.
90
Figure 60 Overseas Subsidiary Form > Loss Event Details Tab
Field Name Description Event Details: This section is used to fill event name, description and so on.
Loss Event Name Enter the name of the loss event.
Countries of Event Select the country where the event has occurred. Loss Event Description Enter the description related to the event.
Event Impact: This section is used to fill the details related to the financial or non – financial impact of the loss event.
Click the magnifying icon to select the level 1 business line. Select Level 1 Business the level 1 business line of the loss event. The values that are available Line depend on the RE type for the loss event.
Level 1 Event Select the level 1 event category of the loss event. Based on the RE type, Category the values get populated in the drop-down list.
No. of Events Enter the number of loss events occurred
Amount Involved Enter the amount involved in the loss event
91
Field Name Description
Net Actual Loss Enter the actual loss amount
Net Potential Loss Enter the potential loss amount
Add Row Link To add row, click this link Delete Last Row Link To delete the last added row, click this link
Delete check box To delete a selected row, select the check box. The selected row is deleted on form submission.
Overseas Subsidiary Form > Additional Details Tab Use this tab to attach files related to the loss event
Figure 61 Overseas Subsidiary Form > Additional Details Tab
Field Name Description This field is auto-populated. It shows the name of the RE who has Created by created the loss events details.
Created On This field is auto-populated. It shows the date when has entered the loss event details for the first time.
Modified By This field is auto-populated. It shows the name of the RE who has updated the loss event details.
Modified On This field is auto-populated. It shows the date when the details have been updated.
To upload the file, click the Browse button, and select the file from your local drive. The file gets attached and the name of the file that you Attach Files attached appears.
To delete an attached file, click the Cancel icon on the right side of the attached file.
Form Submission
To take an action on the current form, refer to the Form Tool Bar section.
92
Key Risk Indicator
Read this chapter to know about the procedures, forms and fields of the Key Risk Indicator (KRI) module of the ORION application.
This chapter contains the following procedures:
Responding to Key Risk Indicator
Editing KRI Response
93
Responding to Key Risk Indicator
The Reporting Entity (RE) can submit the current value for KRI. The RE can access the form to submit their response after viewing all the details mentioned in the KRI definition form.
Note: To respond to the KRIs, use the Respond to Assigned KRI’s form. The fields marked with a red asterisk (*) are mandatory.
Navigation
To access the Respond to Assigned KRI’s form, do the following:
Navigate to the KRI infocenter >> Manage KRIs sub-infocenter >> Respond to KRI infoport.
Figure 62 Accessing the Respond to Assigned KRI’s Form
Click the Respond to Assigned KRI’s link.
Figure 63 Respond to Assigned KRI’s
Enter the value in the Current Value field and click the Submit icon .
Alternatively, you can also access the assignment through the My Tasks menu.
For more information, refer to the Accessing Assignments through My Tasks Menu section.
94
Editing KRI Response
After submitting the KRI response, reporting entities can also edit the response, if required. They can access the form to edit the KRI response from KRI Definition and Submission Reports infoport.
Note: To edit the KRI response, use the KRI Data Entry form. The fields marked with a red asterisk (*) are mandatory.
Navigation
To access the KRI Data Entry form, do the following:
Navigate to the KRI infocenter >> Manage KRIs sub-infocenter >> KRI Definition and Submission Reports infoport.
Figure 64 Accessing the KRI Submission Report
Click the KRI Submission Report link.
Select the required option to narrow down the search result.
Figure 65 KRI Submission Report Filter Fields
Click the Event ID link to access the KRI Data Entry form.
95
Figure 66 KRI Data Entry Form (Read-only Mode)
Click the Edit icon .
96
KRI Data Entry Form (Edit Mode)
Figure 67 KRI Data Entry Form (Edit Mode)
KRI Data Entry Form > Details Tab
Use this section to edit the KRI value.
Figure 68 KRI Data Entry Form > Details Tab
Form Submission
To take an action on the current form, refer to the Form Tool Bar section.
97
Scenario Analysis
Read this chapter to know about the procedures, forms and fields of the Scenario Analysis (SA) module of the ORION application.
This chapter contains the following procedures:
Responding to Scenarios
Responding to Assessments
98
Responding to Scenarios
Once the scenario has been assigned to the Reporting Entity (RE), the RE accesses the Scenario Analysis Response form to respond. The RE needs to provide details, such as the frequency and severity impact caused by the scenario and the amount recovered as a result of its occurrence (if any).
For ad hoc scenario, the RE receives only one assignment to respond.
For workshop scenario, the RE receives one assignment for each scenario listed in the workshop. The RE needs to respond to the scenarios individually.
Once the RE provides the details in the Scenario Analysis Response form, the assessment appears in List of Scenario Response and Workshop Response report.
Note: To respond to the scenarios, use the Scenario Analysis Response form. The fields marked with a red asterisk (*) are mandatory.
Navigation
To access the Scenario form, do the following:
Navigate to the My Tasks menu. Click the Respond to Assigned Scenario link.
For more information, refer to the Accessing Assignments through My Tasks Menu section.
99
Scenario Analysis Response Form
Figure 69 Scenario Analysis Response Form
Figure 70 Scenario Analysis Response Form (Continued…)
100
Scenario Analysis Response Form > Details Tab
Use this tab to provide a response description, response impact, and amount recovered (if any).
Figure 71 Scenario Analysis Response Form > Details Tab
Field Name Description General Response Description Provide a description for the response.
Reputational Impact Select the reputational impact caused by the scenario. The following options are available: High Medium Low Risk Appetite (MYR) Enter the amount to which the organisation can accept the risk. Impact Rating Select the rating of impact. The following options are available: 1 2 3 4 5 Frequency Select the frequency of the scenario occurrence.
101
Field Name Description Severity (MYR) Select the amount that may be lost as a result of the scenario occurrence. Impact on Earnings Enter the amount that could impact the earning. (MYR) Impact On Liquidity Enter the amount that could impact the liquidity.. (MYR) Impact on Economic Enter the amount that could impact the economic value. Value (MYR) Impact on Capital (MYR) Enter the amount that could impact the capital.
Recovery Potential Recovery Enter the potential recovery amount of a reporting entity to Amount (MYR) restore the better condition.
Insurance Coverage Select the following option: Yes: Select this option if a reporting entity has insurance. No: Select this option if a reporting entity does not have insurance.
Relationships Are There Any Controls Select the following option: Applicable Yes: Select this option if the controls are applicable. No: Select this option if the controls are not applicable
Add Row link To add a row, click this link.
Delete Last Row link To delete the last added row, click this link.
Delete check box To delete a selected row, select the check box. The selected row is deleted on form submission.
Control Name Enter the name of the control.
Control Description Enter the description of the control.
102
Scenario Analysis Response Form > Questions Tab
Use this tab to provide responses to the questions.
Figure 72 Scenario Analysis Response Form > Questions Tab
Field Name Description Row# 1 Question The question provided by the Supervisor appears. (read-only) Answer Select your response.
103
Scenario Form > Additional Details Tab
Use this section to attach files related to the scenario.
Figure 73 Scenario Form > Additional Details Tab
Field Name Description Documents Attach File(s) To upload the file, click the Browse button, and select the file from your local drive. The file gets attached and the name of the file that you attached appears.
To delete an attached file, click the Cancel icon on the right side of the attached file. User Details Created By This field shows the name of the BNM users who has (read-only) created the scenario assignment. Created On This field shows the date when the scenario has been (read-only) created.
104
Scenario Form > Action (On Form Submission) Section
Use this section to take an action on the form.
Figure 74 Scenario Form > Action (On Form Submission) Section
Field Name Description Action (On Form Submission) Action You can select the following action from the drop-down list: Send Response: To submit the response, select this option. Form Submission
To take an action on the current form, refer to the Form Tool Bar section
105
Responding to Assessments
Once the scenario assessment is created, it is assigned to the RE. The RE can access the form to submit the risk scenarios by analysing the possible future events.
Note: To submit the risk scenarios, use the Assessment Response form. The fields marked with a red asterisk (*) are mandatory.
Navigation
To access the Assessment Response form, do the following:
1. Navigate to the My Tasks menu.
2. Click the Respond to Assigned Assessment link.
For more information on the My Tasks Menu, refer to the Accessing Assignments through My Tasks Menu section.
Assessment Response Form
Figure 75 Assessment Response Form
106
Assessment Response Form > Header Section
Figure 76 Assessment Response Form > Header Section
Use this section to view the assessment details to respond.
Field Name Description Assessment The assessment name appears. Name (read-only)
Assessment The assessment objective appears. Objective (read-only)
Assessment The date from when the assessment is valid appears. from (read-only)
Assessment till The date until when the assessment is valid appears. (read-only) Due By The date by when the reporting entity should submit the scenario appears. (read-only)
Assessment Response Form > Scenario Analysis Section
Use this section to add scenarios for the assessment. You can define scenarios and related details and controls. Each section must be associated with one scenario. In the Scenario section, the sections and sub-section details are displayed in a tree structure and the tree structure is organised in the following order:
First node – Sections
Second node – Sub-Section
107
Tree Structure Context-sensitive Menu Options
The tree structure displays the respective context-sensitive menu options on right- clicking the each node. The following table describes the context-sensitive menu options available in each tree node.
Field Name Description First Node Add Scenario: To add scenario, click the No Data Found option and click the Add icon . Delete Scenario: To delete the added scenario, click the No Data Found option and click the Minus icon . Note: The scenario node gets added in the tree structure. Note: The No Data Found text get replaced with the scenario name entered in the Scenario Name field.
Second Node Add Sub-section: To add control, click the Scenario Name option and click the Add icon . Delete Sub-section: To delete the added control, click the No Data Found option and click the Minus icon . Note: You can only add the sub-section if any control is applicable to the scenario. Note: The scenario node gets added in the tree structure. Note: The No Data Found text get replaced with the name entered in the Control Name field.
108
Figure 77 Assessment Response Form> Scenario Analysis Section
Field Name Description General Scenario Name Enter the name of the scenario in the field. Note: No Data Found text gets replaced with the scenario name entered in the Scenario Name field.
Assessment Approach Enter the approach details to assess the scenario. Details
109
Field Name Description Scenario Description Enter a description in the field to specify more details about the scenario. To enter details, click the Rich Text Function (RTF) icon . The RTF window appears. For more information on the RTF functions, refer to the Advanced RTF Editor section. Scenario Categorization Level 1 Business Lines Click the magnifying icon to select the level 1 business line of the scenario. The values that are available depend on the RE type for the scenario. Note: Click the Select button to add the selected option in the field. Level 2 Business Lines Select the level 2 business line of the scenario. Level 3 Business Lines Select the level 3 business line of the scenario. Level 1 Event Category Select the level 1 event category of the scenario. Level 2 Event Category Select the level 2 event category of the scenario. Level 3 Event Category Select the level 3 event category of the scenario. Level 1 Causal Category Select the level 1 causal category of the scenario. Level 2 Causal Category Select the level 2 causal category of the scenario. Level 3 Causal Category Select the level 3 causal category of the scenario. Reputation Impact Select the reputational impact on the reporting entity. Risk Appetite Enter the level of risk that an organisation is prepared to accept. Impact Rating Select the rating impact on the reporting entity due to the effect of scenario. Frequency Use this field to schedule the monitoring frequency of the scenario to get data. Note: This field only accepts numeric inputs.
Severity (MYR) Enter the severity that can impact a reporting entity due to the scenario. Note: This field only accepts numeric inputs.
Impact on Earning (MYR) Enter the impact on earnings due to the scenario. Note: This field only accepts numeric inputs.
110
Field Name Description Impact on Liquidity Enter the impact on liquidity of a reporting entity due to the (MYR) scenario. Note: This field only accepts numeric inputs. Impact on Economic Enter the impact on economic value of a reporting entity Value (MYR) due to the scenario. Note: This field only accepts numeric inputs. Impact on Capital (MYR) Enter the impact on capital of a reporting entity due to the scenario. Note: This field only accepts numeric inputs.
Recovery Potential Recovery Enter the potential recovery amount of a reporting entity to Amount (MYR) restore the better condition.
Insurance Coverage Select the following option: Yes: Select this option if a reporting entity has insurance. No: Select this option if a reporting entity does not have insurance. Relationships Are there Any Controls Select the following option: Applicable? Yes: Select this option if the controls are applicable. No: Select this option if the controls are not applicable.
111
Assessment Response Form > Scenario Analysis Sub-section
Use this section to enter the details of the controls.
Figure 78 Assessment Response Form > Scenario Analysis Sub-section
Field Name Description Control Name Enter the name of the control in the field. Note: No Data Found text gets replaced with the name entered in the Control Name field. Control Description Type description in the field to specify more details about the scenario. To enter details, click the Rich Text Function (RTF) icon . The RTF window appears. For more information on the RTF functions, refer to the Advanced RTF Editor section.
Assessment Response Form > Comments Section
Use this section to enter the comments in the field.
Figure 79 Assessment Response Form > Comments Section
Field Name Description History Action It displays the action. (read-only) Comments Enter the comments in the field.
112
Field Name Description Comment History Report To view the Comments History report, click the link Comments History report link. The Comments History report appears. This report displays the comments entered by all the users who worked on this form in a chronological order. Note: Click the Done button to close the report.
Form Submission
To take an action on the current form, refer to the Form Tool Bar section.
Task Assignments and Email Notifications
On submission of the Response Assessment form, the following assignments and emails are generated: When you Assignment Form Email sent to select the value made to the… assigned… the… in the action field Submit BNM Users View Response BNM Users
113
Reports
Read this chapter to know about the various reports of the Loss Event Database (LED), Key Risk Indicator (KRI), and Scenario Analysis (SA) modules.
This chapter contains the following sections:
Introduction
Accessing Reports
Loss Event Database Reports
Key Risk Indicator Reports
Scenario Analysis Reports
Downloading Published Reports
Introduction
A report is a tabular representation of meaningful data that you can use to make informed decisions. A report is normally made up of one or more columns. Some reports would provide drilldown reports.
For information on drilldown reports, refer to the Report Drilldowns section.
114
Accessing Reports
Based on the role, a user access rights control access to reports.
Upon logging on to the system, you will be able to view all the reports that you have access to. To access the report, click the specific report link. You can use filter parameter fields to narrow down the search.
For example, as a RE, you can view the following reports:
Figure 80 Accessing Reports
Report Filters
Use the report filters to narrow down your search. You can access report filters by clicking the Filter button on top of the report page. Alternatively, you can access report filters by clicking the downward-pointing arrow as shown in the below screenshot.
115
Figure 81 Accessing Report Filters
Once you click the arrow button the related filter window appears. Enter the search criteria as required. Click the Submit button. Based on the criteria that you enter, the report data is displayed. To clear the contents in all filter fields, click the Clear All button. To hide the filters, click the Hide Filters button or upward-pointing arrow
at the bottom of the filter fields’ window.
Figure 82 Report Filters
Note: Search parameters perform the function of filters to refine the output of reports.
You may also see report filters above or beside a particular report. In this case you need to select a value in the mandatory fields (and click the Search button if it is available) to display the data that you require.
116
Figure 83 Report Filters
Note: Fields marked with a red asterisk (*) are mandatory.
Report Drilldowns
A few reports can have associated drilldown reports. To access drilldown reports, click a column link in the parent report. A child report appears.
Note: It is advisable to access parent reports that provide access to drilldown reports, from the Reports infoport of an infocenter as parent reports may require key field values (parameter entries).
To access drilldown reports, click the column value that is hyperlinked. Not all reports have a drilldown report.
Report Options
To… Click…
Send the report as an email
Export the report as an excel sheet Export the report as a PDF document
Print the report
117
Loss Event Database Reports
The reports available in the Loss Event Database (LED) module are grouped based on the category of the report.
Loss Events Reports
Overseas Operational Risk Events Reports
Loss Events Reports
SL. To Answer this Question… Use this Report… No. 1. How do I view all the loss events created in Loss Event List Report the system? 2. How do I view the status of the loss events Upload Status Report uploaded in the system?
Loss Event List Report
Figure 84 Loss Event List Report
Description Drilldown Report or Form
This report provides details on all the loss events The column value in the Loss Event triggered in the system. This report provides ID column drills down to the Loss information such as loss event ID, reporting entity Event Form. ID, reporting entity name, reporting entity type, industry, loss event impact, loss event classification, nature of business etc.
118
Loss Event Filter Fields
Figure 85 Loss Event Filter Fields
Field Name Description Industry Values in this field are available only if you select a value in the Reporting Entity Type field. Event For Values in this field are available only if you select a value in the Reporting Entity Type field. Level 2 Causal Values in this field are available only if you select a value in the Level 1 Category Causal Category field. Level 3Causal Values in this field are available only if you select a value in the Level 2 Category Causal Category field. Level 2 Event Values in this field are available only if you select a value in the Level 1 Category Event Category field. Level 3 Event Values in this field are available only if you select a value in the Level 2 Category Event Category field. Level 2 Business Values in this field are available only if you select a value in the Level 1 Line Event Category field.
119
Field Name Description Level 3 Business Values in this field are available only if you select a value in the Level 2 Line Event Category field. Delivery Channel Values in this field are available only if you select a value in the Level 1 Business Line field. Product/Services Values in this field are available only if you select a value in the Level 1 Business Line field. States of Event Values in this field are available only if you select Malaysia in the Countries of Event field. Districts of Event Values in this field are available only if you select Malaysia in the Countries of Event field. Card Brands Values in this field are available only if you select a value in the Payment Instrument field. Card Types Values in this field are available only if you select a value in the Payment Instrument field. Payment Values in this field are available only if you select a value in the Instrument Modus Payment Instrument field. Operand
120
Upload Status Report
Figure 86 Upload Status Report
Description Drilldown Report or Form This report provides the status of the uploaded Click the Download link in the Success forms in the system. This report provides Template column to open or save the template. information such as form name, upload template name, status, description, created on, success template and error template.
Upload Status Report Filters
Figure 87 Upload Status Report Filters
121
Overseas Operational Risk Events Reports
SL. To Answer this Question… Use this Report… No. 1. How do I view all the loss events that have Overseas Loss Event List Report occurred in overseas business units?
Overseas Loss Event List Report
Figure 88 Overseas Loss Event List Report
Description Drilldown Report or Form
This report provides details on all the loss events The column value in the Loss Event that have occurred in overseas business units. ID column drills down to the Loss This report provides information such as loss Event Form. event ID, reporting entity ID, reporting entity name, reporting entity type, the overseas business unit, industry, business lines etc. Note: This report is not applicable to all Reporting Entities. It will be only shown if the BNM has published this report to a particular Reporting Entity.
Overseas Loss Event List Report Filter Fields
Figure 89 Overseas Loss Event List Report Filter Fields
122
Key Risk Indicator Reports
The reports available in the Key Risk Indicator (KRI) module are grouped based on the category of the report.
Breaches Peer Comparison
KRI Submission Reports
SL. To Answer this Question… Use this Report… No. 1. How do I view all the details of KRI breaches Breaches Peer Comparison across the reporting entities in the system? 2. How do I view all the details of the KRI KRI Submission Reports submission in the system?
Breaches Peer Comparison
Figure 90 Breaches Peer Comparison
Description Drilldown Report or Form This report provides details of KRI breaches across The column value in the No. of reporting entities. This report provides information such KRI column drills down to the KRI as reporting entity name, tier, no. of KRI, number of List Report. submission, number of non-critical breaches, number
of critical breaches and so on.
123
KRI Submission Reports
Figure 91 KRI Submission Reports
Description Drilldown Report or Form
This report provides details on all the KRIs The column value in the Event ID submitted in the system. This report provides column drills down to the KRI Data information such as event ID, frequency, Entry Form. reporting entity name, risk category, data
collection type, status, due date and so on.
124
Scenario Analysis Reports
The reports available in the Scenario Analysis (SA) module are grouped based on the category of the report.
Scenario Analysis Response Reports
Reporting Entity Scenario Assessment Reports
Scenario Analysis Response Reports
SL. To Answer this Question… Use this Report… No. 1. How do I view the list of scenarios assigned List of Scenario Response to reporting entities with their response status in the system? 2. How do I view the list of workshop Workshop Response Report assignment with the responses of reporting entities in the system?
List of Scenario Response
Figure 92 List of Scenario Response
Description Drilldown Report or Form
This report provides details of ad-hoc scenario The column value in the Scenario and workshop assignment by reporting entities Response ID column drills down to the based on the user access. This report provides Scenario Analysis Response form. information such as scenario ID, scenario
response, scenario name, reporting entity name, level 1 event category, due by and so on.
125
Workshop Response Report
Figure 93 Workshop Response Report
Description Drilldown Report or Form
This report provides details of the workshop The column values in the Workshop responses triggered in the system. This report ID and Scenario Name columns drill provides information such as workshop ID, down to the Workshop form and reporting entity name, scenario name, level Scenario forms respectively. 1event category, scenario ID and so on.
126
Reporting Entity Scenario Assessment Reports
SL. To Answer this Question… Use this Report… No. 1. How do I view the value of all the list of Assessment Response Report assessment responses in the system?
Assessment Response Report
Figure 94 Assessment Response Report
Description Drilldown Report or Form
This report provides details of assessment The column value in the Assessment responses by RE in the system. This report Response ID column drills down to the provides information such as assessment ID, Scenario Analysis form. assessment response ID, reporting entity name,
assessment submitted by, severity, frequency and so on.
127
Downloading Published Reports
The user selected as the recipient can view and download the published report from the BNM Message Board.
Note: An e-mail is sent to the user to notify that the reports are published and available to view and download.
Navigation
To download the published report, do the following:
Navigate to the BNM Message Board infocenter >> Industry Report infoport.
Figure 95 Downloading the Published Report
Click the Download link in line with the
Figure 96 File Download Dialog Box
Click Open to open the report.
Note: You can click Save to save the report and click Cancel to cancel the action.
128