Operational Risk Integrated Online Network (ORION)

Issued on: 25 February 2021

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

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

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 Table 6

Types of cyber threats…………………………………………… BDSF event reporting types ………………………………….....

20 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

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;

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.

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;

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.

http://k2.w2k.bnm.gov.my/webcenter/portal/regulatory_handbook/page13?_afrLoop=1636982925519990&_adf.ctrl-state=16paaepqx5_48

http://k2.w2k.bnm.gov.my/webcenter/portal/regulatory_handbook/page13?_afrLoop=1636982925519990&_adf.ctrl-state=16paaepqx5_48

Page 8 of 94


PART B: POLICY REQUIREMENTS 8. Overview of the responsibilities of reporting entities

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.

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.

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 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

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.

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

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;

S

S

S

S

S

S

S

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 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

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

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 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 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.

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.

S

S

S

G

S

G

http://www.bnm.gov.my/

Page 10 of 94


PART C: REPORTING REQUIREMENTS 12. ORION reporting requirements

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 specifications

REs

Appendix 2 Operational risk event reporting requirements

REs

Appendix 3 Cyber threat reporting requirements

FIs

Appendix 4

BDSF event reporting requirements

FIs

Appendix 5 Boundary event reporting requirements

FIs except Licensed Insurers & Takaful Operators

Appendix 6 Customer information breaches reporting requirements

REs

Appendix 7 Insurance-related event reporting requirements

Licensed Insurers & Takaful Operators

Appendix 8 SNC event reporting requirements

FIs

Appendix 9 Payment-related fraud event reporting requirements

REs except Licensed Insurers & Takaful Operators

Appendix 10 Aggregate reporting requirements

REs

Appendix 11 Overseas loss event reporting requirements

FIs

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

S

Page 11 of 94


13. Scope of reporting 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.

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.

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

14.1 All amounts must be reported by REs in Ringgit Malaysia (RM). 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

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.

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.

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.

S

S

S

S

S

S

S

S

Page 12 of 94


Non-financial related operational risk event

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.

S

Page 13 of 94


Table 2: ORION reporting types and timelines

4 Self Service Terminals (SST) are Automated Teller Machines (ATMs), Cash Deposit Machines (CDMs) and Cash Recycler Machines (CRMs).

Reportable operational risk events Classification Timeline

Critical event

Robbery and theft

Self Service Terminals (SST)4 robbery

Robbery and theft events ≥ RM 200k

Actual

Potential

Near miss

By T+1 working day, T being the date of event confirmation

Cyber threat

As defined in Appendix 3 Actual

Near Miss

Reputational Impact

High impact events as defined by REs internal policy

Actual

All operational risk events ≥RM 1mil

Actual

Potential

By T+2 working days, T being the date of event confirmation

Critical BDSF

As defined in Appendix 4

Actual

New modus operandi (MO)

New type of fraud MO committed and impacted the REs for the first time

Actual

Potential

Customer information breaches

As defined in Appendix 6 Actual By T+1 working day, T

being the date of investigation is tabled to the Board

SNC event

Actual SNC


By T+1 working day, T being the date of SNC confirmation by Shariah Committee (SC)

Potential SNC

As defined in Appendix 8 Potential

By T+1 working day, T being the date of event confirmation by an officer within the control function

Fraud event

All fraud types

Payment-related fraud is defined in Appendix 9

Other fraud events

Actual

Potential

Near miss

By the 15th calendar day of the following month or earlier

Other loss event

Aggregate reporting As defined in Appendix 10

All card fraud (Credit Card, Debit Card, Charge Card) with amount involved ≤ RM 5k

Actual

Potential

Near miss

All actual loss ≤ RM 1k

Physical cash shortages

Actual

Overseas loss events


All other loss events

All events other than specified above with financial losses

Actual

Page 14 of 94


16. Additional reporting requirements

16.1 All submission to ORION must not contain any customer information or employee data to satisfy data secrecy and data privacy.

16.2 All on-going Operational Risk events must be re-assessed and updated to reflect changes to event classification and latest information.

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 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.

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.

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

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

S

S

S

G

S

S

G

Page 15 of 94


through the impact of various scenarios, FIs can enhance its contingency plans or business continuity management plans.

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.

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.

S

S

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

field Description

Reporting Entity Name

Yes To select the respective reporting entity for

operational loss event

(Note: Applicable to Financial Group structure)

Reporting entity name will be automatically

displayed for a ‘Single’ entity

Nature of Event

Yes New - New type of MO impacted the REs for the first time.

Repeated - MO that has occurred previously at REs

Refer to FAQ No. 35.

Event Classification

Yes Operational risk events must be classified as either one of the following:

Actual loss

Potential loss

Near miss

Islamic Business

Yes (if the event is related to Islamic product / business)

(√) – If the operational risk event is relating to Islamic business or product (Note: If the event is no longer classified as SNC, Islamic Business box must remain checked (√) because the operational risk event is related to Islamic business or product)

Shariah Non Compliance

Yes FIs must select one: (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)

Page 17 of 94


Data fields Mandatory field

Description

Loss Event Name

Yes Clear and concise name that summarise the nature of the loss event

Internal Loss Event ID

Yes REs are required to generate its own internal ID for each loss event reported in ORION

Business

lines

Yes Must be reported up to Level 3 (banking) and Level 2 (insurance) in accordance with the taxonomy in Appendix 12

Product / Services

Yes Conditionally populated; please select one

Delivery Channel

Yes Conditionally populated; please select one

Event categories*

Yes Must be reported up to Level 3 in accordance with the taxonomy in Appendix 13

Causal categories*

Yes Must be reported up to Level 3 in accordance with the taxonomy in Appendix 14

Country of Events

Yes Country where the loss was incurred

State of Events

Yes Conditionally populated for operational risk event occurred in Malaysia

District of Events

Yes Conditionally populated for operational risk event occurred in Malaysia

Date of Event Occurrence

Yes The date of the operational risk event took place

Date of Event Detection

Yes The date of operational risk event confirmation is obtained

Loss Event Description

Yes 1. General operational risk event

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

Page 18 of 94



Description

(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 Till

No To remove existing operational risk event in ORION; this field is only applicable for genuine duplicated reporting in ORION

Reason Yes (if the above is selected)

The reason for the removal of the loss event must be provided

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 Impact >> Event For

Yes RE must select whichever applicable:

Event for Banking

Event for ATM Acquirer

Event for Payment Instrument

Event for Payment Channel

Event for Insurance & Takaful Operator


Yes >>Banking

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


Yes >> ATM Acquirer Please refer to Appendix 9


Yes >> Payment instrument Please refer to Appendix 9

Page 19 of 94



Description


Yes >> Payment channel Please refer to Appendix 9


Yes >>Insurance &Takaful Operator REs must identify the insurance category impacted from:

Assets

Claims

Premium

Re-insurance

Intermediaries

Others

Amount Involved

Yes This field must have a value to reflect the overall financial amount associated with the operational risk event reported

Financial Impact (for Banking, ATM Acquirer and Payment Channel) >> Actual

Loss / Potential Loss / Recoveries

Yes REs to record the actual loss / potential loss / 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)

Financial Impact (for Payment Instrument)

Yes >> Loss Incurred by Malaysian Entities Please refer to Appendix 9

Financial Impact (for Payment Instrument)

Yes >> Loss Incurred by Foreign Entities Please refer to Appendix 9

Non- Financial Impact >> Impact

Yes REs must select the severity of the non-financial impact either as:

High

Medium

Low

Non- Financial Impact >> Comments

Yes The detailed description of the non-financial impact must be provided to justify the selection of High / Medium / Low

“>>” represents sub-data fields

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 (Malware)

Software designed with malicious intent containing features or capabilities that can potentially cause harm directly or indirectly to entities or their information systems.

Adware

Bots

Bugs

Rootkits

Spyware

Virus A type of malware that is capable of duplicating itself with the intention of stealing information or disrupt the device or system.

MyDoom

Stuxnet

Ransomware A type of malware that installs on a 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.

CryptoLocker

Distributed Denial of Service (DDoS)

DDoS is the prevention of authorised access to information or information systems; or the delaying of information system operations and functions, resulting in the loss of availability to authorised users. DDoS is normally carried out using numerous sources simultaneously.

Network attack

Application attack

Hacking Hacking is an unauthorised intrusion into a computer or a network.

N/A

Web defacement

Website defacement is an attack on a website that changes the visual

N/A

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

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.


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

Page 23 of 94



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

Page 24 of 94




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


(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 >> Events For

REs must select one:

Event for Banking

Event for Insurance & Takaful Operator


>> Banking


Page 25 of 94





>>Insurance &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 / Recoveries

REs to record the actual loss / recovery 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 >>Impact

Please choose either: Low / Medium / High

Non-Financial >> Comments

The detailed description of the non-financial impact must be provided to justify the selection of Low / Medium / High


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 BDSF event

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.

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.

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.

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 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.

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.

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



To select the respective reporting entity for operational loss events


Actual Loss




Islamic Business (√) – If the operational risk event is relating to

Islamic business or product


Business Lines Must be reported up to Level 3 in accordance with the taxonomy in Appendix 12

Products / Services

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

Page 29 of 94




Date of Occurrence

The date that the event took place

Date of Detection The date of event confirmation is obtained






The categories of parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.)



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



Non-Financial Impact – No loss amount involved but has impact on reputation, non-compliance etc.


defined above.


Choose: Banking



Page 30 of 94



Choose: Insurance and takaful operator REs must identify the insurance category impacted from:

Assets

Claims

Premium

Re-insurance

Intermediaries

Others


Actual Loss / Potential Loss / Recoveries

REs must record the actual loss / potential loss / recovery 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, recovered amount must be recorded in the ‘Recovery Amount’ field







Page 31 of 94


4. Customer information breaches in Payment Instrument Issuers

Category: Customer information breaches Event Classification: Actual Loss



To select the respective reporting entity for operational loss events

Event Classification Actual Loss





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







The categories of parties involved in the event (e.g. customer / staff / outsourced service provider / affiliates, etc.)



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

Page 32 of 94



e.g. Name, I/C number and other personal information





defined above



REs must record the actual loss / potential loss / recovery amount incurred to the following categories:

Reporting Entity^

Customer^^








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.

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

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

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.

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.

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.

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.

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


Actual Loss – Any SNC event that has been 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-Compliance

FIs must select one: (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 Contract

FIs must select only ONE primary Shariah 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.

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 Supporting Contracts

FIs must provide the type of secondary Shariah contract used under a particular Shariah primary 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 of Detection

FIs must report the source of detection of the potential and actual SNC e.g. Shariah Compliance Unit, Business Unit, etc.

SC Reporting Date

The date the event was tabled to SC for decision

Board Reporting Date

The date of tabling the rectification plan of an SNC event to the Board

Shariah Date Resolved

Shariah resolution date endorsed by SC

No. of Accounts Involved

The number of accounts involved in a particular SNC event

Shariah Decision

Entailing Shariah resolutions including the basis of 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

Page 42 of 94


Figure 1: Process flow for reporting SNC events

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

(b) Event Type:Clients, products and business practices >> Selection, sponsorship and exposure>> Failure to investigate client per guidelines

(c) Event type: External fraud >> Theft and fraud >> Forgery /

counterfeit (cover notes, policy certificates, currency, cheque, security documents / identifcation documents

“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.

“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.

“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.

Page 44 of 94


(d) Event type: Execution, delivery and process management >>

Transaction capture, execution and maintenance >> Model / system mis-operation

(e) Event type: Damage to physical assets >> Natural disaster & Other losses >> Damage to islamic inventory

(f) Event type:Business disruption and system failures >> Systems >>

Software-Inadequate system capacity

“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.

“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.

“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.

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 and channels

REs responsible to report fraud event in ORION

Payment Instruments

Credit card

Charge card

Debit card

E-money7

Cheque

Card issuers

Card issuers

Card issuers

E-money issuers

Issuing banks (Refer to FAQ No. 57.)

Payment channels

Internet banking (includes desktop banking)

Mobile banking

Internet banking offering banks

Mobile banking offering banks

Unauthorised cash withdrawal

ATM ATM acquirers

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.

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 Over

Fraudster gains access to existing card account and 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 Application

Fraudster applied for a card under the identity of another person and subsequently uses the card to make fraudulent transactions

Internet Authenticated internet transaction Unauthenticated internet transaction

Card information obtained illegally and subsequently used to order goods or services through the internet (a) Authenticated internet transaction: Internet

transaction that was authenticated by verifying the cardholder's password

(b) Unauthenticated internet transaction: Internet

transaction where authentication was not performed or could not be performed

Mail and Telephone Order

Card information obtained illegally and subsequently used to order goods or services through telephone 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

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 mobile devices

(a) Mobile phone is either misplaced or lost (by 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 compromised login credentials

Login credentials obtained illegally, such as via e-mail and short message services (SMS) and 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 value

(also applicable to card-based e-money scheme)

Manipulation of e-money balance / illegally reload or top-up by fraudster so that the account appears to have a greater monetary value than the amount actually paid by the user

(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.

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

Email

SMS

Telephone

A method used by fraudsters to access valuable personal information such as username, PIN and passwords by sending 'spoofed' e-mail messages, 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:

Malware

SIM Card Hijack

REs must specify the fraud MO in the loss event description field:

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

Fraudster impersonating the customer at mobile service provider, to replace the SIM card of registered mobile number to receive TACs in order to conduct unauthorised internet banking transactions

Page 49 of 94


MO Description

Unauthorised Internet Banking Transaction

Browser redirect

Other new MO

Fraudster used stolen customer credentials for the registration of new internet banking profile to conduct unauthorised internet banking transactions

Fraudster used links on search engine results to direct customers to fake internet banking websites to conduct unauthorised internet banking transactions

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

Email

SMS

Telephone

Customers are lured into divulging personal information such as username, PIN and passwords to conduct unauthorised mobile banking transactions

Others:

Malware

SIM Card Hijack

REs must specify the fraud modus operandi in the loss event description field:

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 service provider, to replace the SIM card of 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.

Page 50 of 94


MO Description

Unauthorised Mobile Banking Transaction

Other new MO

Fraudster used stolen customer credentials for the registration of new mobile banking profile to conduct unauthorised mobile banking transactions

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


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




Islamic Business (√) – If the operational risk event is relating to Islamic business or product


Business Lines Must be reported up to Level 3 (banking) in accordance with the taxonomy in Appendix 12

Products / Services Please choose where applicable


Event Category Must be reported up to Level 3 in accordance with the taxonomy in Appendix 13

Page 51 of 94




Date of Occurrence The date that the event took place



An executive summary of the loss event and must include the following details: (a) Chronology of the loss event





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




Both Financial and Non-Financial – as defined above


RE must select whichever applicable:

Event for ATM Acquirer

Event for Payment Instrument

Event for Payment Channel


>> ATM Acquirer

>> Payment instrument REs must select whichever applicable:

Credit Card

Page 52 of 94



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)


>>Payment instrument 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


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.

Page 53 of 94



Types of cheque issuers - REs must select

whichever applicable:

Individual

Corporate

Government


>>Payment Instrument >> Credit card >> Debit card >> Charge card >> E-money

>> Credit card; >> Debit card; >> Charge card; and >> E-money Card brands - REs must select whichever applicable: Credit card & Charge card:

Visa

MasterCard

AMEX

CUP

Diners


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


Page 54 of 94



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


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


Page 55 of 94



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)


>> Payment channel REs must select whichever applicable:

Internet Banking

Mobile Banking

>>Payment Channel >> Internet Banking

>> Mobile Banking

>>Internet Banking >>Mobile Banking

Account type - REs must select whichever

applicable: Internet Banking & Mobile Banking:

Individual

Corporate


Modus operandi - REs must select whichever applicable: Internet Banking & Mobile Banking:

Phishing - Email

Phishing – SMS

Phishing – Telephone Others (please specify)

Page 56 of 94




Financial Impact (for Banking, ATM Acquirer and Payment Channel) >> Actual Loss /

Potential Loss / Recoveries

REs must record the actual loss / potential loss / recovery amount incurred according to the following categories:

Reporting Entity^

Customer^^


Financial Impact (for Payment Instrument) >> Loss Incurred by

Malaysian Entities

REs must record the loss amount incurred according to the following categories:

Actual Loss and / or;

Recoveries and / or;

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

Page 57 of 94



Financial Impact (for Payment Instrument) >> Loss Incurred

by Foreign Entities

REs must record the loss amount incurred by foreign entities according to the following categories:

Actual Loss and / or;

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


REs must record the actual loss / potential loss / recovery amount incurred according to the following categories:

Reporting Entity^

Customer^^







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 threshold

Aggregate submission to ORION

Payment instrument

Aggregate by card types*:

Credit card

Charge card

Debit card *Note: including card fraud committed overseas

Amount involved ≤ RM5,000

To submit:

1 event for ALL actual loss

1 event for ALL potential loss

1 event for ALL near miss

Actual loss events ≤ RM 1,000

Aggregate by event types:

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

Actual loss ≤ RM1,000

To submit:

1 event for actual loss per event type

Page 59 of 94


Category Sub-category Aggregate threshold

Aggregate submission to ORION

All physical cash shortages

Aggregate by event types:

Clients, products and business practices

Execution, delivery and process management

External fraud

All actual loss

To submit:

1 event for shortages at both branch and vendor per event type

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


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:



Page 60 of 94



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 Occurrence & Date of Detection

Choose one date to represent the overall events recorded in a particular month


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

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

Page 62 of 94




Loss By Malaysian Entities

Input the total aggregated loss incurred 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


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



To select the correct entity

Event Classification only Actual Loss

Nature of Event Repeated - MO that has occurred previously at REs


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


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.

Page 64 of 94



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


Select one date to represent the overall incidents recorded in a particular month


Please use this standard format for: Actual loss events ≤ RM 1,000

Event Type Amount No. of cases

No. of customers impacted

Ext. Fraud X X X

Damage to Physical Assets

X X X

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 & Takaful Operators

>>> Insurance category: Please select: N/A


Loss By Banks OR Loss By Insurance & Takaful Operators

The REs must input the total aggregated loss incurred according to the specific categories provided:

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.


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


Reporting Entity Name To select the correct entity

Event Classification only Actual Loss

Nature of Event Repeated - MO that has occurred previously at

REs


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


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

Page 66 of 94



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


Select one date to represent the overall incidents recorded in a particular month


Please use this standard format for: All physical cash shortages* at branch or offsite Self-Service Terminals (SSTs) Cash shortage

Amount No. of

cases

No. of

customers impacted

PDRM

Report Number

Serial

Number

No of

pieces

Branch SSTs X X X X X X

Over-the-counter

X X X X X X

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


>> Banking >>> Boundary Event: No

>> Insurance & Takaful Operators

>>> Insurance category: Please select: N/A


Loss By Banks OR Loss By Insurance & Takaful Operators

The REs must input the total aggregated loss incurred according to the specific categories provided:

Reporting Entity

Customer



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 losses

Event ≥ RM 1mil

All actual financial loss

To submit loss event individually

Aggregate by country for event < RM 1mil

All actual financial loss

To submit the loss event aggregated by country (1 event for ALL actual 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





Only Actual Loss Only Actual loss

Loss Event Name [Country name] Overseas Losses (MM/YY)

[Country name] Overseas Losses (MM/YY)

Countries of Event Please select the ‘country’ involved

Please select the ‘country’ involved


(a) Chronology of the loss event


Please input ‘N/A’

Page 68 of 94








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 Line

Please select the relevant Business Line

N/A – this is a mandatory field, please select any from the list

Level 1 Event Category

Please select the relevant Event Type

N/A - this is a 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 value to reflect the overall financial amount associated with the operational risk event reported

This field must have a value to reflect the overall financial amount associated with the operational risk event reported

Net Actual Loss

The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field.

The REs must not use losses net of insurance recoveries as an input to the ‘Actual Loss’ field.

Page 69 of 94



Instead, recovered amount must be recorded in the ‘Recovery Amount’ field

Instead, recovered amount must be recorded in the ‘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

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 level 1


Business line

level 3

Product / Services

1. Commercial Banking

Corporate Banking

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

Commercial Banking


Bills of Exchange

LC or BA or TR




TL or OD etc.

Lending / Financing

Factoring

Leasing


Fixed Deposit

Savings

NID

CP / MTN

Page 71 of 94




Business line

level 3

Product / Services



SME


Bills of Exchange

LC or BA or TR




TL or OD etc.

Lending / Financing

Factoring

Leasing


Fixed Deposit

Savings

NID

CP / MTN



2. Retail Banking

Retail Banking

Mortgage Residential

Non-Residential

Personal Loan / Financing

Hire Purchase

Wealth Management

Deposits Current Account

Fixed Deposits

Savings

NID

Structured Deposits

Private Banking

Mortgage Residential

Non-Residential

Personal Loan / Financing

Hire Purchase

Wealth Management

Deposits Current Account

Fixed Deposits

Savings

NID

Page 72 of 94




Business line

level 3

Product / Services

Structured Deposits

Card Services

Cards Credit Card

Debit Card

Charge Card

E Money Card Based

Network Based

3. Trading and Sales

Treasury

Fixed income

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


Lending and repos

Brokerage

Debt

Market Making

Fixed income

Equity

Foreign exchanges

Commodities

Credit

Funding


Lending and repos

Brokerage

Debt

Prime brokerage

Proprietary Positions

Fixed income

Equity

Foreign exchanges

Commodities

Credit

Page 73 of 94




Business line

level 3

Product / Services

Funding


Lending and repos

Brokerage

Debt

Prime brokerage

4. Agency Services

Custody Escrow

Depository receipts

Securities lending (customers) corporate actions

Corporate Agency

Issuer and paying agents

Corporate Trust

5. Asset Management

Discretionary Fund Management

Retail

Whole Sale

Non-Discretionary Fund Management

Retail

Whole Sale

6. Payment and Settlement

Note: Payment and Settlement losses

related to a bank’s own activities would be incorporated in

the loss experience of the respective affected eight

Business Line

Fund Transfer

Interbank

Intrabank

Local Remittances

Overseas Remittances

Payment & Collection

Clearing and Settlements

7. Corporate Finance

Advisory Services

Equity Equity Capital Market

Flotation

Bonus Issue

M&A

IPO

Private Placement

Corporate Restructuring

Debt Fund Raising

Structured financing

Underwriting

Equity Equity Capital Market

Flotation

Bonus Issue

Page 74 of 94




Business line

level 3

Product / Services

M&A

IPO

Private Placement

Corporate Restructuring

Debt Fund Raising

Structured financing

8. Retail Brokerage

Broking

Equity Broking – Margin

Equity Broking– Non Margin

Futures Broking

Futures Broking – Margin

Futures Broking – Non Margin

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


5. Reinsurers

Facultative

Non Proportional Treaty

Proportional Treaty


6. Retakaful Operators

Facultative

Non Proportional Treaty

Proportional Treaty


Page 76 of 94


APPENDIX 13 Event types taxonomy Banking

Event type level 1

Event type level 2

Event type level 3

1. Internal fraud

Unauthorised activity

Transactions not reported (intentional)

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

Fraud / credit fraud / worthless deposits

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 fraud

Theft and fraud

Theft / Robbery

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 security

Hacking damage


Page 77 of 94


Event type level 1

Event type level 2

Event type level 3

Unauthorised changes to programs by external parties



3. Employment practices and workspace safety

Employee relations

Compensation, benefit, termination issues

Organised labour activity

Safe environment

General liability (slips and falls, etc.)

Employee health & safety rules events

Workmen’s compensation

Diversity and discrimination

All discrimination types

4. Damage to physical assets

Natural disaster & other losses

Natural disaster – Flood

Natural disaster – Earthquake

Natural disaster – Tsunami

Natural disaster – Others

Human Losses – Vandalism

Human Losses – Terrorism

Damage to Islamic Inventory

5. Business disruption and system failures

Systems

Hardware – Server

Hardware - Storage Disk

Hardware - Local Area Network (LAN)/ 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

Page 78 of 94


Event type level 1

Event type level 2

Event type level 3

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, products and business practices

Suitability, disclosure and fiduciary

Fiduciary breaches / guideline violations

Suitability / disclosure issues (KYC, etc.)

Retail customer disclosure violations

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 business or market practices

Antitrust

Improper trade / market practices

Market manipulation

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, sponsorship and exposure

Failure to investigate client per guidelines

Exceeding client exposure limits

Advisory activities

Disputes over performance of advisory activities

7. Execution, delivery and process management

Transaction capture, execution and maintenance

Miscommunication

Data entry or maintenance or loading

Missed deadline or responsibility

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

Page 79 of 94


Event type level 1

Event type level 2

Event type level 3

Monitoring and reporting

Failed mandatory reporting

Inaccurate external reporting

Inaccurate internal report (including not updating recent trends / ratios into claims / premium reserves / inaccurate aging report)

Customer intake and documentation

Client permissions / disclaimers missing

Legal documents missing / incomplete

Improper documentation (improper receipting or failure to lodge documents, etc.)

Customer or client account management

Unapproved access given to accounts

Incorrect client records

Negligent loss or damage of client assets

Trade counterparties

Non-client counterparty mis-performance

Miscellaneous non-client counterparty disputes

Vendors & suppliers

Outsourcing

Breach of SLA

Technology failure in supplier systems

Service Delivery failure / capacity

Vendor disputes

Page 80 of 94


Insurance

Event type level 1

Event type level 2

Event type level 3

1. Internal fraud

Unauthorised activity

Transactions not reported (intentional)

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 fraud

Theft or extortion or embezzlement or 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 fraud

Theft / Robbery

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 security

Hacking damage


Unauthorised changes to programs by external parties



Page 81 of 94


Event type level 1

Event type level 2

Event type level 3

3. Employment practices and workspace safety

Employee relations

Compensation, benefit, termination issues

Organised labour activity

Safe environment

General liability (slips and falls, etc.)

Employee health & safety rules events

Workmen’s compensation

Diversity and discrimination

All discrimination types

4. Damage to physical assets

Natural disaster & Other Losses

Natural disaster - Flood

Natural disaster - Earthquake

Natural disaster - Tsunami

Natural disaster - Others

Human Losses - Vandalism

Human Losses - Terrorism

Damage to Islamic Inventory

5. Business disruption and system failures

Systems

Hardware - Server

Hardware - Storage Disk

Hardware - Local Area Network (LAN) / 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, products and business practices

Suitability, disclosure and fiduciary

Fiduciary breaches / guideline violations

Suitability / disclosure issues (KYC, etc.)

Regulatory compliance of appointed representatives

Page 82 of 94


Event type level 1

Event type level 2

Event type level 3

Breach of privacy

Unlicensed activity

Misrepresentation of facts

Misuse of confidential information


Aggressive sales

Improper business or market practices

Antitrust

Improper trade / market practices

Market manipulation


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, sponsorship and exposure

Failure to investigate client per guidelines

Exceeding client exposure limits

Advisory activities

Mis-selling due to mortgage endowment

7. Execution, delivery and process management

Transaction capture, execution and maintenance

Miscommunication

Data entry, maintenance or loading

Missed deadline or responsibility

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 reporting

Failed mandatory 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

Page 83 of 94


Event type level 1

Event type level 2

Event type level 3

Customer intake and documentation

Inappropriate underwriting

Inappropriate reinsurance

Customer or client account management

Payment to incorrect client

Incorrect client records

Incorrect payment to client

Trade counterparties

Non-client counterparty mis-performance

Miscellaneous non-client counterparty disputes

Vendors and suppliers

Outsourcing

Breach of SLA

Technology failure in supplier systems

Service delivery failure / capacity

Vendor disputes

Page 84 of 94


APPENDIX 14 Causal categories taxonomy

Causal categories level 1



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 procedures

Dealing with change

Product design

Spreadsheet workarounds

Lack of documentation

Inadequate monitoring / reporting

Lack of due diligence

Poor contract / service level agreement

Process change / implementation

Management decision / change not implemented

Management information inadequate

Inadequate policies Inadequate checks/balances on senior individuals

Inadequate allocation of accountabilities


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

Page 85 of 94





Data integrity

Resilience


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


Page 86 of 94


APPENDIX 15 Key risk indicators taxonomy

1. Generic indicators

KRI Sector Description Cycle

1. Number of application fraud near miss

Banking

Insurance &Takaful Operators

Number of fraudulent application detected and thwarted for secured / unsecured facility, account opening, insurance proposal submission etc.

Note: Remittance/cheque book/trading bill applications should not be included in the KRI.

Monthly*

2. Number of new litigation cases initiated against the FI with SNC implications

Banking

Takaful Operators

Number of new cases that have SNC implications, where the FI was served with Letter of Demand / letter from lawyer within that month

Monthly*

3. Number of reprimands received from other regulators/ enforcement agencies/ operator of designated payment systems

Banking


Number of reprimands received from other regulators / enforcement agencies / operator of designated payment systems (e.g. Bursa Malaysia, Securities Commission of Malaysia, 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.

Monthly*

4. Number of new litigation cases initiated against the FI

Banking


Number of new cases initiated against the FI, where the FI was served with Letter of Demand / letter from lawyer within that quarter. The number includes orders received from Industrial Court.

Quarterly*

Page 87 of 94


X100


5. Staff attrition rate

Banking


Attrition rate for permanent staff No of turnover in current quarter

No of staff beginning of current

quarter

Quarterly*

6. Number of customers’ names in the freeze orders received from enforcement agency without prior STR raised

Banking


Number of customers’ names in the freeze orders received from enforcement agency that does not match against internal list of STR raised

Quarterly*

7. Number of new audit findings

Banking


Number of new audit findings from internal and / or external auditor engaged for non-financial audits to the entity which have never been raised before. Any recurring issues across different business lines must be excluded

Quarterly*

* ALL Reinsurers and Retakaful companies are to report these KRIs on a yearly basis.

Page 88 of 94


2. Technology


1. Number of instances of critical systems downtime exceeding Recovery Time Objective (RTO)

Banking


Tracks specific critical system availability as outlined in FAQ No. 61.

Monthly

2. Number of instances of critical services downtime exceeding Recovery Time Objective (RTO)

Banking



Monthly

3. Number of instances of network utilisation exceed threshold of 60%

Banking


Tracks network bandwidth utilisation to identify potential threats to Denial of Service attack (DDoS)

Monthly

4. Number of instances response time for critical services exceeded predetermined threshold / SLA

Banking


Tracks specific critical system availability as outlined in FAQ No. 61. More details in FAQ No. 88.

Monthly

5. Number of hacking attempts on IT infrastructure

Banking


The number of hacking attempt on internet facing application by external parties.

Monthly

6. Number of instances storage or memory utilisation exceed maximum threshold of 70%

Banking



Quarterly

7. Numbers of batch overrun incidents

Banking



Quarterly

8. Number of instances of failed Disaster Recovery Plan (DRP) tests for critical systems

Banking


To ascertain the reliability of the DRP and readiness of the FI in the event of a system failure

Yearly

Page 89 of 94



9. Number of DRP tests planned but not conducted for the year

Banking


To ascertain the reliability of the DRP and FI readiness in the event of a system failure

Yearly

10. Number of scheduled core system maintenance not conducted

Banking


To ascertain system integrity

Yearly

11. Number of incidents relating to loss of confidential data

Banking


To ascertain any breaches of preservation of data confidentiality in accordance to the FSA, IFSA and Personal Data Protection Act

Yearly

12. Number of incident relating to transactional reporting or updating errors of critical system

Banking


The transactional reporting error refers to a material error in the financial figure or other 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.

Yearly

Page 90 of 94


3. Complaints


1. Number of new complaints on Sales and Marketing

Banking

Insurance &Takaful Operators**

Complaints on sales representatives’ unethical behaviour such as harassing or coercing; or acting in a manner 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)

Monthly

2. Number of new complaints on Services

Banking


Complaints on staff or third party engaged by FIs who are involved in providing services to 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)

Monthly

3. Number of new complaints on Operations

Banking


Complaints on inefficiency of the internal process, system, control and procedure to ensure fair and 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)

Monthly

Page 91 of 94



4. Number of new complaints on Products

Banking


Complaints on products offered not meeting the needs and financial affordability of customers (e.g. different term offered than applied for, unfair term and condition)

Monthly

5. Number of new complaints on Fees & Charges

Banking


Complaints on terms and conditions relating to fees and charges, unreasonable and unfair imposition of fees and charges to 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)

Monthly

6. Number of new complaints on Benefits & Claims


Complaints on demand for payment of an amount due under a policy / refund / claim / surrender etc. (e.g. repudiation of claim, delay in claim settlement, dispute / dissatisfaction of claim settlement / surrender / maturity value, unsatisfactory repair work)

Monthly

7. Number of new complaints on Underwriting


Complaints on the process that an insurer uses to assess the eligibility of a customer to receive their products (e.g. refuse to insure / renew / unfair policy condition, dispute on underwriting)

Monthly

8. Number of new Shariah-related complaints

Banking

Takaful Operators**

Complaints lodged by customers on potential non-compliance with Shariah requirements in product implementation, legal documentation, product brochures, transparency, etc.

Monthly

** ALL Reinsurers and Retakaful companies are excluded from reporting the KRIs

Page 92 of 94


4. Insurance and Takaful


1. Instances of delay in issuance of policies

Insurance &Takaful Operators*

Number of policy issuance exceeding 30 days for Motor and 60 days for Non-motor from the acceptance of risk until issuance of policies. Refer to FAQ No. 89.

Monthly

2. Instances of delay in registering claims


Number of claim registration > 7 working days from receipt of claims notification

Monthly

3. Instances of delay in payment of claims


Number of delay in 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. Refer to FAQ No. 90.

Monthly

4. Number of replacement of life policy / certificate

Insurance & Takaful Operators with life / family business*

Number of life policy / certificate replaced in a particular month. Refer to FAQs No. 91 and 92.

Monthly

5. Number of occurrences of holding cover prior to facultative placement


Number of risks that are not included in the treaty coverage but were accepted prior to facultative placement

Monthly

6. Number of disputed and repudiated claims recovery from reinsurers and subrogation


Number of:

claims recovery disputed and repudiated from reinsurers

claims recovery disputed and repudiated from subrogation

*Note: This applies to all Reinsurance arrangement which include Treaty and Facultative.

Monthly

7. Number of delay in death claims


Number of death claims paid > 60 days after the notification date. Refer to FAQ No. 93.

Monthly

Page 93 of 94



8. Instances of delay in appointing licensed / in-house adjuster

General Insurance & General Takaful Operators*

Appointment of licensed / in-house adjuster was done >7 working days from receipt of completed claims documents. Refer FAQ to No. 94.

Monthly

* ALL Reinsurers and Retakaful companies are excluded from reporting the KRIs

5. Treasury


1. Number of treasury room limit breaches (including trading positions)

Banking Number of treasury limit breaches on dealing / trading activities as per the approved internal policy

Monthly

2. Total number of confirmation mismatches

Banking Number of confirmation mismatches between the bank and its counterparties

Monthly

3. Number of instances off-market price transactions

Banking Number of deals / trades concluded not within the observable market rates and daily quoted price inclusive of private placements

Monthly

4. Number of instances off-premise trading

Banking Number of deals / trades executed outside the treasury dealing room

Monthly

5. Number of instances - failed trade reconciliation between Front Office and Back Office

Banking Number of unreconciled deals / trades (variance) between Front Office and Back Office, whereby the trades which were concluded by the front office but there were no corresponding confirmations obtained by the back office

Monthly

6. Number of payment and settlement disputes by customers and counterparties

Banking Number of payment and settlement transactions disputed by customers and counterparties

Monthly

Page 94 of 94



7. Instances of buying and selling of the same stock / securities at the same price within the same trading day

Banking Number of trades which are executed on an immediate buy / sell basis, at the same price in the same stock / securities within the same day

Monthly

8. Number of instances – ad hoc request to increase trading limit

Banking Number of specific request by dealers to increase approved trading limit, including instances when dealers share limits with other dealers

Monthly

9. Number of trade / deal cancellations and amendments

Banking Number of trades / deals amended or cancelled by trader / dealer Refer to FAQ No. 95.

Monthly

10. Number of unconfirmed corporate trade / deals

Banking Number of corporate trades / deals not confirmed (not signed and returned by corporate clients)

Monthly

6. Corporate Finance


1. Number of Qualified Senior Personnel (QSP) resignation

Banking To monitor minimum number of QSPs specified as a “registered persons” in third column of Part 1 of Schedule 4 in the Capital Markets and Services Act 2007

Monthly

2. Number of submissions rejected / returned by SC

Banking Number of submissions not meeting SC's standards

Monthly

3. Breaches of the Chinese Wall policy

Banking Number of Chinese Wall Policy breaches occurred in the month

Monthly

ORION Frequently Asked Questions (FAQ)


2

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

3

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

4

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.

mailto:[email protected]


5

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?

http://orion.w2k.bnm.gov.my/metricstream/systemi

https://kijangnet.bnm.gov.my/

http://orion.w2k.bnm.gov.my/metricstream/systemi


https://kijangnet.bnm.gov.my/


6

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”.


7

(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.





8

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

9

‘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).

10

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:

11

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?

12

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.5 million

Singapore – RM1.7 million

13

RE must submit 3 reports to ORION by 15 February or earlier (1 to 14 February).

Report 1: Thailand RM2.5million;

Report 2: Singapore RM1.5 million;

Report 3: Singapore RM1.7 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

Singapore – RM2k

Singapore – RM3k

Vietnam – RM3k

Vietnam – RM1k

RE must submit 3 reports to ORION by 15 February or earlier (1 to 14 February).

Report 1: Thailand RM20k;

Report 2: Singapore RM5k;

Report 3: Vietnam RM4k

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?

14

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.

15

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 Loss (In RM)

Recovery Amount (In RM)

Comments

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 Loss (In RM)

Recovery Amount (In RM)

Comments

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

(In RM) Comments

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.

16

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:

17

(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).

18

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.

19

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

20

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


21

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?

22

(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

23

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.

Appendix 1: ORION User Guide and Technical Specifications


2

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

3

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

4

.... 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

5

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

6

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.

7

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.

8

Organisation of this Document

The table below summarises the contents of the section contained in this document.

Chapter No.

Chapter Description of Coverage

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 (LED)

Provides information on creating and uploading 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.

9

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…

10

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

11

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.

12

LED Workflow for Online Submission

Figure 1 LED Workflow for Online Submission

< Reporting Entity Name > Executive

Login

Click on LED Tab

Click on Data

Upload Link

Enter data in online

form

Field level data validation (E.g.

dependent fields)

Submit

Is there any error

message?

(Submission validation)

Check the error

and correct it.

Done

Loss Event created and Loss ID generated for new event

End

Click on Manage

Loss Events

Yes

No

13

LED Workflow for Batch Submission

< Reporting Entity Name > Executive

Login

Click on LED Tab

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

Status Report

Correct the erroneous

records

Retain only the

erroneous record in excel

Is there any

error in

report?

Loss event created and Loss ID generated for new

event End

Click on Manage

Loss Events

Yes

No

Figure 2 LED Workflow for Batch Submission

14

LED Workflow for Viewing Reports

< Reporting Entity Name > Executive, CRO, Group CRO

Click on Loss Event Reports

View Reports

Download Reports

Click on LED Tab

Login

Click on Operational

Overseas Risk Report

View Reports

Download Reports

Figure 3 LED Workflow for Viewing Reports and Dashboards

15

Workflow for Updating Loss Events

Click on a Loss Event List

Report

Search for Loss Event

that should be updated

Field level data

validation (Eg dependent fields)

Yes

No

Check the error and

correct it

Click on Loss

Event Tab

Login

Reporting entity name Executive

Click on a Loss Event Name in the report

Update loss event

data

Is there any

error message?

(Submission

validation)

Submit

Loss event updated by matching

Reporting entity ID

and Internal Loss

Event ID

Click on Upload

Loss Event Link

Modify Upload Type

as Update in a new .xls file

Attach filled new

xls file in upload loss form

Click on Upload

View Upload

status report

Is there any

error in report? No

Check Error template only

for the erroneous records

Correct the

erroneous

records

Click on Loss Event Tab

Login

Reporting entity name Executive

Loss event updated

by matching Reporting entity ID and Internal Loss

Event ID

Yes

Figure 4 Workflow for Updating Loss Events

16

Workflow for Submitting KRI Values

Open KRI

Provide value for

the KRI

Submit

Login

View KRI /KRI

Assignment

< Reporting Entity Name > Executive, CRO

Figure 5 Workflow for Submitting KRI Values

17

Workflow for Submitting the KRI Value through Infoport

Figure 6 Workflow for Submitting the KRI Values through Infoport

Click Respond to Assigned KRI

Link

Provide value for the KRI

Submit

Login

Click on KRI tab

< Reporting Entity Name > Executive, CRO

18

KRI Workflow for Viewing Reports

Figure 7 KRI Workflow for Viewing Reports

Click on KRI Reports

View Reports

Download

Reports

Login

Click on KRI tab


19

SA Workflow for Responding to Scenarios, Workshops and

Assessments

View scenario

assigned for

response

Open the scenario

Submit

Login

Enter

Impact

Reporting entity Executive

View Assignment

Respond to

questionnaire

Scenario response is now available for

analysis and

reporting

View assessment period /assessment

details

Open the

assessment form

Submit

Login

Enter scenario

(with analysis)


View Assignment

Assessment

response is now available for analysis

and reporting Submit


Respond to

questionnaire

View workshop assigned for

response

Open the

workshop

Login

Enter

Impact

View Assignment

Scenario response is now available for

analysis and

reporting

Figure 8 SA Workflow for Responding to Scenarios, Workshops and Assessments

20

SA Workflow for Viewing Reports

Click on Scenario Analysis

Tab

View/ Download Reports

Login


Click the Reports displayed under the Scenario Analysis

Response infoport

Figure 9 SA Workflow for Viewing Reports

21

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.

22

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.

23

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.

24

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


b) On a 32bit OS;

(i) ACEOLEDB.DLL" should exists here:

C:\Program Files\Common Files\Microsoft


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]

25

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.

26

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 .

27

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.

28

8. In the References dialog box, select the Object Libraries as shown in the image

below:

29

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.

30

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.

31

Getting Started

Read this chapter to know about the user interface and infocenters of the ORION

application.


Logging on to the Application

Basic Elements of the Startup Screen

Infocenters

32

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.


33

Figure 11 Clicking the Financial Institutions Link.

Click the Register as a Member link.

Figure 12 FI@KijangNetPortal Page

Click the Register tab.

34

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

35

email addresses used should be the exact email addresses that were provided

to BNM under the roles of CRO and submission officer.

36

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.


37

Figure 16 Accessing the Financial Institutions Link.

Enter the Username and Password.


Click the Login button.

38

From the home page of FI@Kijangnet, click on ORION, this will bring you to

the ORION page.


39

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.

40

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

41

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

42

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

43

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.

44

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…

or

Submit

Submit the form’s contents and route to the next workflow step based on the action selected.

Save Draft

Save the form’s contents as a working draft for the user without processing it to the next workflow step and keep the form open.

Save Draft & Close

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 Tasks at a later time and continue working.

View Reports

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 reports appears. Click the required report name to view the details.

or

Cancel

Cancel the changes made to the form and close it.

45

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

46

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.

47

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.

48

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 a keyword

Enter a keyword in the Search field with “%” before and after the keyword and click Go.

Add the selected the option(s) to the list Select the check box of the option and click Select.

Cancel the selected option and close the window

Click Cancel.

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.

View only the selected option in the list

Click Get Selected.

Note: This button is available only if the user has selected an option from the list.

Note: When you click Get Selected, it is replaced by Back. You can click Back to

49

To… Do this…

go back to the previous list.

50

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 Executive and CRO

Provide KRI Value Provide <KRI> data: <Definition-Name> [<ID>] for <date>

KRI form is assigned to provide KRI value.

CRO Edited KRI Form KRI <Definition-Name> [<ID>] has been edited

KRI value has been edited.

CRO and Reporting Entity Executive

Overdue KRI Form KRI Response overdue KRI form is overdue.

51

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:


Reporting Entity Executive

Ad-hoc Assignment of Scenario

[:Object_ID]: ObjectName has been assigned to you for response.

Supervisor assigns an ad-hoc scenario. This e-mail is sent to notify the RE executive to work on ad-hoc assignment.


Workshop Assignment Scenario - [:Object_ID]: ObjectName has been assigned to you for response.

Supervisor assigns the workshop assignment. This e-mail is sent to notify the RE executive to work on workshop assignment.


Reminder e-mail: Scenario

Scenario - [:Object_ID] :ObjectName response is due in next 24 hrs’

RE executive does not provide a response to the scenario. This e-mail is sent to notify the RE executive that the scenario is due.


Reminder e-mail: Workshop

Workshop - [:Object_ID] :[Workshop Name ]response is due in next 24 hrs’

RE executive does not provide a response to the workshop. This e-mail is sent to notify the RE executive that the workshop is due.


Reminder e-mail: Assessment

Workshop - [:Object_ID] :[Workshop Name] response is due in next 24 hrs’

RE executive does not provide a response to the assessment. This e-mail is sent to notify the RE executive that the assessment is due.


Escalation e-mail: Scenario

Scenario - [:Object_ID] :[Scenario Name] response overdue

RE executive does not provide a response to the scenario. This e-mail is sent to notify the RE executive and CRO that the scenario is overdue.

52



Escalation e-mail: Workshop

Workshop - [:Object_ID] :[Workshop Name]response is overdue

RE executive does not provide a response to the workshop. This e-mail is sent to notify the RE executive and CRO that the workshop is overdue.


Escalation e-mail: Assessment

Workshop - [:Object_ID] :[Workshop Name] response is overdue

RE executive does not provide a response to the assessment. This e-mail is sent to notify the RE executive and CRO that the assessment is overdue.


Ad-hoc Assessment Scenario - [:Object_ID]: [Assessment Name] has been assigned to you for response

BNM user assigns the ad-hoc assessment. This e-mail is sent to notify the RE executive to work on new assessment.


Scenario Published Scenario Published RE executive provides 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.

53

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.


Creating Loss Events

Editing Loss Events Details

Entering Loss Events Details in an Excel Sheet

Entering Loss Events Details (Non-Malaysian Res)

54

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

55

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 Entity Name

Enter the name of reporting entity.

Reporting Entity ID

(read-only)

This field is populated based on the reporting entity name. It shows the identification number of the reporting entity.

Date Of Event Reporting

This field is auto-populated. It shows the date when the loss event is created.

Nature of Event Select the nature of the loss event. The following options are available:

New

Repeated

56

Field Name Description Event Classification

Select the event classification. The following options are available: 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 Business check box

If the event is related to an Islamic Business, or if the RE has any Islamic products that are used, select the check box.

Shariah Non- Compliance

Select the Shariah Non-Compliance from the available options:

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

57

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.


(appears only if you select the value in the Level 1 Business Line field)

Select the level 2 business line of the loss event. The values that are available depend on the RE type and the level 1 business line.



Select the level 1 business line of the loss event. The values that are available depend on the RE type and the level 2 business line.

Product/Services


Select the product or service applicable for the loss event. The values that are available depend on the level 3 business line.

58

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 Comments (appears only if Others is selected in the Business Line and Delivery Channel field.)

Enter the comments.

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.


(appears only if you select the value in the Level 1 Event Category Line field)

Select the level 2 event category line of the loss event. The values that are available depend on the RE type and the level 1 event category.


(appears only if you select the value in the Level 2 Event Category field)

Select the level 3 event category of the loss event. The values that are available depend on the RE type and the level 2 event category.

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

(appears only if you select the value in the Level 1 Causal Category field)

Select the level 2 causal category of the loss event. The values that are available depend on the RE type and the level 1 causal category.


(appears only if you select the value in the Level 2 Causal Category field)

This field is populated based on RE type and the level 2 causal category.

Select the level 1 causal category of the loss event. The values that are available depend on the RE type and the level 2 causal category.

Causal Category Comments (appears only if Others is selected in the Level 2 Causal Category field.)

Enter the comments related to causal category.

59

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

(appears only if you select Malaysia in the Countries Of Event field)

Select one or more states where the loss event occurred.

Districts Of Events

(appears only if you select Malaysia in the Countries Of Event field)

Select one or more districts where the event occurred.

Date Of Event Occurrence

Select the date when the loss event occurred.

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 Contract (MLOV)

Select the Shariah primary contract.

Shariah Supporting Contracts

Select the Shariah secondary contracts. You can select multiple contracts.

Shariah Source of Detection

Select the source of detection. You can select multiple sources.

Board Reporting Date Select the date when the non-compliance was detected.

Shariah Committee Reporting Date

Select the date when the non-compliance was reported to 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.

60

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

61

Insurance Category

(appears only if you select Insurance in the Events For field)

Select the insurance category. The following options are available:

Assets

Claims

Premium

Re insurance

Intermediaries

Others

NA

Boundary Event

(appears only if you select Banking in the Events For field)

Select the following options:

Yes: If the event is a boundary event, select Yes.

No: If the event is not a boundary event, select No.

Note: This field is applicable only for banking institution, prescribed development FI, and payment system regulatee users.

Related To

(appears only if you select Yes in the Boundary Event field)

Select the following options:

Credit Risk: If the event is related to a credit risk, select Credit Risk.

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

(appears only if you select ATM Acquirer or Payment Instrument in the Events For field)

Select the type of card that was used.

Note: If you choose E-Money in this field and Network Based option in the Modus Operandi field, then Card Brands and Card Types fields will show NA automatically.

Card Brands

(appears only if you select ATM Acquirer or Payment Instrument in the Events For field)

Select the card brand. The values that are available here depend on the value you select in the payment instrument field.

Note: This field is applicable only for card-related loss 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

(appears only if you select Others in the Card Brands field)

Enter the comments related card brands.

62

Card Types

(appears only if you select the value in the Payment Instrument field or if you select Payment Instrument in the Events For field)

Select the card type.

Note: This field is applicable only for card-related loss events.

Note: If you choose E-Money in Payment Instrument and Network Based option in the Modus Operandi field, then Card Types will show NA automatically.

Card Types Comments

(appears only if you select Others in the Card Types field)

Enter the comments related to card types.

Source of Detection (appears only if you select Cheque in the Payment Instrument field)

Select the source of detection.

Source of Detection Comments (appears only if you select Others in the Source of Detection field)

Enter the comments related to source of detection.

Type of Cheque Issuers

(appears only if you select Cheque in the Payment Instrument field)

Select the type of cheque issuer.

Payment Channel

(appears only if you select Payment Channel in the Events For field)

Select the payment channel that was used.

Account Type

(appears only if you select Payment Channel in the Events For field)

Select the account type. The following options are available:

Individual

Corporate

Others (Please Specify) Account Type Comments

(appears only if you select Others in the Account Type field)

Enter the comments related to account type.

Business Activity

(appears only if you select Payment Instrument in the Events For field)

Select the business activity.

63

Business Activity Comments (appears only if you select Others in the Business Activity field)

Enter the comments related to business activity.

Modus Operandi

(appears only if you select Payment Channel or Payment Instrument in the Events For field)

Select the modus operandi used. The values that are available here depend on the value you select in the Payment Channel field.

Modus Operandi Comments (appears only if you select Others in the Modus Operandi field)

Enter the comments related to modus operandi.

Amount Involved(In MYR)

Enter the amount involved in 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 MYR)

Enter the amount recovered.

Potential Loss Amount(In MYR)

Enter the potential loss amount.

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.

64

Total Potential Loss Amount

This field is populated based on the amount entered in the 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.

65

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.

66

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:


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.

67


Edit the details of the required fields.

Refer the Creating Loss Events section to edit the fields of the form.

Form Submission


68

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.

69

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.

70

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.

71

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

(read-only) This loss event ID is used only as a reference. After the excel is uploaded 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 Event ID

Enter the internal loss event ID. It is used by RE to capture their internal loss event and to identify whether there is any duplicate entry or not.

Loss Event Name

Enter the name of the loss event.

72

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 Involved

Enter the amount involved in the loss event.

Net Actual Loss

(read-only)

This field is populated based on the amount entered in the Financial tab.

Net Potential Loss

(read-only)

This field is populated based on the amount entered in the Financial tab.

73

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.

74

Field Name Description Islamic Business

Use this field to indicate whether the loss event is related to an Islamic 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-Compliance

(appears only if the event is related to Islamic Business)

Use this field to indicate whether the loss event is related to Shariah non-compliance or not. The following options are available:

Yes: If the event is not compliant to Shariah law, select Yes.

No: If the event is compliant to Shariah law, select No.

Based on the selection, the Shariah Details tab appears in the form.

Date of Event Detection

Enter the date when the event has been detected.

Date of Event Occurrence

Enter the date when the event has occurred.


Select the classification of the event. The following options are available:

Actual Loss

Potential Loss

Near Misses

Nature of Event

Select the nature of the event. The following options are available: New

Repeated


Enter the description of the loss event. There is a limitation of maximum 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.


State of Event (MLOV) Select the desired value from the list and click the Add button to



Districts of Event (MLOV) Select the desired value from the list and click the Add button to



75

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 Primary Contract (MLOV)

Select the Shariah primary contract.

Note: Click Clear All to remove the value from the field.

Shariah Supporting Contracts (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.


Shariah Source of Detection (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.

Shariah Committee Reporting Date

Enter the date when the event has been reported to the Shariah committee.

Board Reporting Date

Enter the date when the event has been reported to the Shariah committee.

76

Field Name Description Date Resolved

Enter the date when the event has been resolved.

No of Accounts Involved

Enter the number of accounts that have been impacted due to the loss event.

Shariah Decision

Enter the decision taken by Shariah committee for loss event.

Actions Taken Enter the actions taken by Shariah committee for loss event.

Event Valid Till

Enter the date till when the event was valid.

Reason Enter the reason for the end date of the event.

77

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 Line

Select the level 1 business line of the loss event. Based on the RE type, the values get populated in the drop-down list. Note: This field will not appear for the Payment System Regulatees.


Select the level 2 business line of the loss event. The values that are available depend on the value selected in the Level 1 Business Line field.


Select the level 2 business line of the loss event. The values that are 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.

78

Field Name Description Business Line/Product Services/Delivery Channel Comments

(appears only if Others is selected in the Delivery Channel field)

Enter your comments.


Select the level 1 event category of the loss event. Based on the RE type, the values get populated in the drop-down list.


Select the level 2 event category of the loss event. The values that are available depend on the value selected in the Level 1 Event Category field.


Select the level 3 event category of the loss event. The values that are available depend on the value selected in the Level 2 Event Category field.

Comments

(appears only if Others is selected in the Level 3 Event Category field.)

Enter the comments.


Select the level 1 causal category of the loss event. Based on the RE type, the values get populated in the drop-down list.

Note: This field will not appear for the Payment System Regulatees.


Select the level 2 causal category of the loss event. The values that are available depend on the value selected in the Level 1 Causal Category field.


Select the level 3 causal category of the loss event. The values that are available depend on the value selected in the Level 2 Causal Category field.

Comments

(appears only if Others is selected in the Level 3 Causal Category field.)

Enter your comments.

79

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:


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 Instrument

Select the payment instrument.

80

Field Name Description Card Brands

Select the brand of the card.

Card Brands Comments (appears only if Others is selected in the Card Brands field.)

Enter the comments related to card brands.

Card Types Select the card types.

Card Types Comments (appears only if Others is selected in the Card Types field.)

Enter the comments related to card types.

Boundary of Event (appears only if Banking is selected in the Events For field.)

Select the option if it is boundary of event:

Yes

No

Payment Channel (appears only if Payment Channel is selected in the Events For field.)

Select the payment channel which was used. The following options are available: Internet Banking

Mobile Banking

Account Type Select the type of account. The following options are available:

Individual

Corporate


Account Type Comments (appears only if you select Others in the Account Type field)

Enter the comments related to account type.

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


81

Field Name Description

Modus Operandis Comments (appears only if you select Others in the Account Type field)

Enter the comments related modus operandi.

Payment Instrument (appears only if you select Payment Instrument in the Event For field)

Select the payment instrument. The following options are available:

Charge Card

Cheque

Credit Card

Debit Card

E-Money

Business Activity Select the business activity.

Modus Operandi Select the modus operandi.

Source of Detection (appears only if you select Cheque in the Payment Instrument field)

Select the source of detection.

Source of Detection Comments (appears only if you select Others in the Source of Detection field)

Enter the comments related to source of detection.

Type of Cheque Issuers

(appears only if you select Cheque in the Payment Instrument field)

Select the type of cheque issuer.

82

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 MYR)

Enter the actual loss amount. 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 Amount (In MYR)

Enter the amount recovered.

Note: Recovery amount should be less than or equal to the amount involved.

Potential Loss Amount (In MYR)

Enter the potential loss amount.

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.

83

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 Impact Comment

Enter the comments related to non financial impact.

84

Form Submission

To take an action on the current form, refer to the following table:

Click the… To…

Submit

Submit the form’s contents in the sheet named as “form”. However, the data will not be

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

Close the form.

Next

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.

If you have not saved the details, click Yes and then click the Submit button. It directs you to the next record.

Prev

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 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.

85

Uploading the Excel Sheet

As an RE, you can upload multiple loss events into the ORION application using the

Data Upload form.


Navigation

To upload loss events, perform the following steps:


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

86

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 Entities

(appears only if System Entities is selected in the Upload Type field.)

Select the system entities. The following options are available:

Organization

Organization Hierarchy

Organization Locations

Roles

UserOrgRoles

Users

87

Field Name Description Select file to upload

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.

Download Template Link

Click to download the template.

Form Submission


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.

88

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 document.

Delete first four rows and columns of the sheet.

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. Username is case sensitive.

Press Ctrl key to select MLOV.

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 update the details of the values of the rows

Edit the rows manually.

89

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.


90

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


Date of Event Reporting

This field is auto – populated. It shows the date when the loss event is created.

Reporting Entity Name Select the name of reporting entity.

Reporting Entity ID (read-only)

This field is populated based on the reporting entity name. It shows the identification number of the reporting entity.


Select the event classification. The following options are available:

Actual Loss

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.

91

Figure 60 Overseas Subsidiary Form > Loss Event Details Tab


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 the level 1 business line of the loss event. The values that are available depend on the RE type for the loss event.


Select the level 1 event category of the loss event. Based on the RE type, 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

92


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


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.


Form Submission


93

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.


Responding to Key Risk Indicator

Editing KRI Response

94

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


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.

95

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.

96

Figure 66 KRI Data Entry Form (Read-only Mode)

Click the Edit icon .

97

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


98

Scenario Analysis

Read this chapter to know about the procedures, forms and fields of the Scenario

Analysis (SA) module of the ORION application.


Responding to Scenarios

Responding to Assessments

99

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.

100

Scenario Analysis Response Form

Figure 69 Scenario Analysis Response Form

Figure 70 Scenario Analysis Response Form (Continued…)

101

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.

102

Field Name Description Severity (MYR)

Select the amount that may be lost as a result of the scenario occurrence.

Impact on Earnings (MYR)

Enter the amount that could impact the earning.

Impact On Liquidity (MYR)

Enter the amount that could impact the liquidity..

Impact on Economic Value (MYR)

Enter the amount that could impact the economic value.

Impact on Capital (MYR) Enter the amount that could impact the capital.

Recovery

Potential Recovery Amount (MYR)

Enter the potential recovery amount of a reporting entity to 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 Applicable

Select the following option:

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.

103

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

(read-only) The question provided by the Supervisor appears.

Answer Select your response.

104

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.


User Details

Created By

(read-only) This field shows the name of the BNM users who has created the scenario assignment.

Created On

(read-only) This field shows the date when the scenario has been created.

105

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

106

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


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

107

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 Name

(read-only)

The assessment name appears.

Assessment Objective

(read-only)

The assessment objective appears.

Assessment from

(read-only)

The date from when the assessment is valid appears.

Assessment till

(read-only) The date until when the assessment is valid appears.

Due By

(read-only) The date by when the reporting entity should submit the scenario appears.

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

108

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.

109

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 Details

Enter the approach details to assess the scenario.

110

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 1 Causal Category Select the level 1 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.


Severity (MYR) Enter the severity that can impact a reporting entity due to the scenario.


Impact on Earning (MYR) Enter the impact on earnings due to the scenario.


111

Field Name Description Impact on Liquidity (MYR)

Enter the impact on liquidity of a reporting entity due to the scenario.


Impact on Economic Value (MYR)

Enter the impact on economic value of a reporting entity due to the scenario.


Impact on Capital (MYR) Enter the impact on capital of a reporting entity due to the scenario.


Recovery

Potential Recovery Amount (MYR)

Enter the potential recovery amount of a reporting entity to 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 Applicable?

Select the following option: Yes: Select this option if the controls are applicable.

No: Select this option if the controls are not applicable.

112

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

(read-only) It displays the action.

Comments Enter the comments in the field.

113

Field Name Description Comment History Report

link To view the Comments History report, click the 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


Task Assignments and Email Notifications

On submission of the Response Assessment form, the following assignments and

emails are generated:

When you select the value in the action field

Assignment made to the…

Form assigned…

Email sent to the…

Submit BNM Users View Response BNM Users

114

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.


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.

115

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.

116

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.

117

Figure 83 Report Filters


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

118

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. No.

To Answer this Question… Use this Report…

1. How do I view all the loss events created in the system?

Loss Event List Report

2. How do I view the status of the loss events uploaded in the system?

Upload Status Report

Loss Event List Report

Figure 84 Loss Event List Report

Description Drilldown Report or Form

This report provides details on all the loss events triggered in the system. This report provides information such as loss event ID, reporting entity ID, reporting entity name, reporting entity type, industry, loss event impact, loss event classification, nature of business etc.

The column value in the Loss Event ID column drills down to the Loss Event Form.

119

Loss Event Filter Fields

Figure 85 Loss Event Filter Fields


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.


Values in this field are available only if you select a value in the Level 1 Causal Category field.

Level 3Causal Category

Values in this field are available only if you select a value in the Level 2 Causal Category field.


Values in this field are available only if you select a value in the Level 1 Event Category field.





120




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 Instrument Modus Operand

Values in this field are available only if you select a value in the Payment Instrument field.

121

Upload Status Report

Figure 86 Upload Status Report


This report provides the status of the uploaded forms in the system. This report provides information such as form name, upload template name, status, description, created on, success template and error template.

Click the Download link in the Success Template column to open or save the template.

Upload Status Report Filters

Figure 87 Upload Status Report Filters

122

Overseas Operational Risk Events Reports

SL. No.


1. How do I view all the loss events that have occurred in overseas business units?

Overseas Loss Event List Report

Overseas Loss Event List Report

Figure 88 Overseas Loss Event List Report


This report provides details on all the loss events that have occurred in overseas business units. This report provides information such as loss event ID, reporting entity ID, reporting entity name, reporting entity type, the overseas business unit, industry, business lines etc.

The column value in the Loss Event ID column drills down to the Loss Event Form.

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

123

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. No.


1. How do I view all the details of KRI breaches across the reporting entities in the system?


2. How do I view all the details of the KRI submission in the system?



Figure 90 Breaches Peer Comparison


This report provides details of KRI breaches across reporting entities. This report provides information such as reporting entity name, tier, no. of KRI, number of submission, number of non-critical breaches, number of critical breaches and so on.

The column value in the No. of KRI column drills down to the KRI List Report.

124


Figure 91 KRI Submission Reports


This report provides details on all the KRIs submitted in the system. This report provides information such as event ID, frequency, reporting entity name, risk category, data collection type, status, due date and so on.

The column value in the Event ID column drills down to the KRI Data Entry Form.

125

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. No.


1. How do I view the list of scenarios assigned to reporting entities with their response status in the system?

List of Scenario Response

2. How do I view the list of workshop assignment with the responses of reporting entities in the system?

Workshop Response Report

List of Scenario Response

Figure 92 List of Scenario Response


This report provides details of ad-hoc scenario and workshop assignment by reporting entities based on the user access. This report provides information such as scenario ID, scenario response, scenario name, reporting entity name, level 1 event category, due by and so on.

The column value in the Scenario Response ID column drills down to the Scenario Analysis Response form.

126

Workshop Response Report

Figure 93 Workshop Response Report


This report provides details of the workshop responses triggered in the system. This report provides information such as workshop ID, reporting entity name, scenario name, level 1event category, scenario ID and so on.

The column values in the Workshop ID and Scenario Name columns drill down to the Workshop form and Scenario forms respectively.

127

Reporting Entity Scenario Assessment Reports

SL. No.


1. How do I view the value of all the list of assessment responses in the system?

Assessment Response Report

Assessment Response Report

Figure 94 Assessment Response Report


This report provides details of assessment responses by RE in the system. This report provides information such as assessment ID, assessment response ID, reporting entity name, assessment submitted by, severity, frequency and so on.

The column value in the Assessment Response ID column drills down to the Scenario Analysis form.

128

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 <report name> link. The File

Download dialog box appears.

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.

Date post:	04-Dec-2021
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times