version 3.0 june 2015 - financial services royal commission

GUIDE

Operational Risk Self Assessment (ORSA)

Version 3.0

June 2015

MGL.0010.0003.0657

Table of Contents

1. Introduction ....................................................................................................................................... 3

1.1 Objective of this document........................................................................................................... 3 1.2 Governance of the ORSA Framework ......................................................................................... 3

2. ORSAs ................................................................................................................................................ 3

2.1 Objectives of ORSAs ................................................................................................................... 3 2.2 ORSA quality standards ............................................................................................................... 3 2.3 ORSA documentation requirements in OpenPages .................................................................... 4 2.4 ORSA processes ......................................................................................................................... 5

2.4.1 Identify Key Risks facing the business and assess inherent risk rating. .............................. 5 2.4.2 Identify Critical Controls ........................................................................................................ 6 2.4.3 Assess Control Effectiveness ............................................................................................... 6 2.4.4 Assess Residual Risk ........................................................................................................... 7 2.4.5 Identify remedial actions ....................................................................................................... 7 2.4.6 ORSA Workshops and alternative approaches .................................................................... 7 2.4.7 Ongoing maintenance of previously created ORSA ............................................................. 8

2.5 ORSA Summary .......................................................................................................................... 8

3. RMG Operational Risk’s role in ORSAs .......................................................................................... 9

3.1 ORSA Review and Board Reporting ............................................................................................ 9 3.2 Hindsight Reviews ....................................................................................................................... 9

4. Internal Audit’s role in ORSAs ......................................................................................................... 9

5. User and Data Administration ....................................................................................................... 10

5.1 Access Management ................................................................................................................. 10 5.2 Data Management ..................................................................................................................... 10

APPENDIX A ORSA Summary: what works and what does not work? ............................................ 11

APPENDIX B Parent Risks and Control Areas .................................................................................. 13

APPENDIX C Risk (Likelihood and Impact) ratings ........................................................................... 17

APPENDIX D End to End ORSA requirement – Example with BFS and Technology ....................... 19

APPENDIX E Alternative approaches to ORSA Workshops ............................................................. 20

MGL.0010.0003.0658

1. Introduction

1.1 Objective of this document

This document aims to provide a broad outline of the Operational Risk Self-Assessment (ORSA) requirements from start to finish and to outline roles and responsibilities in executing these requirements of the Operational Risk Management Framework (ORMF).

1.2 Governance of the ORSA Framework

RMG Operational Risk is responsible for reviewing the ORSA and Control Assurance policy and this guidance. Any questions on this guidance should be forwarded to RMG Op Risk Mailbox.

2. ORSAs

2.1 Objectives of ORSAs

Operational Risk Self Assessment (ORSA) is a key element of Macquarie’s ORMF. It is designed to assist businesses in identifying their material operational risks, controls in place to mitigate those risks and issues and actions. The objectives of ORSAs are:

To provide a mechanism for the identification of risks, controls that manage those risks and actions for any control weaknesses; and

Facilitate more informed prioritisation and decision making by management. The ORSA is further used to support representations made as to the effectiveness of controls in the:

Management Representation Letters for the purposes of the half and full year financial reports;

Annual representations made to the Board and APRA by the CEO; and

Sign-offs by the CEO and CFO as to the efficiency and effectiveness of internal controls over financial reporting for compliance with ASX Corporate Governance Guidelines.

2.2 ORSA quality standards

RMG Operational Risk has set the following quality standards in reviewing ORSAs:

Live ORSA – Critical controls in OpenPages and their evaluations (Effective, Needs Improvement, and Ineffective) should reflect all known material information (e.g. new product approvals, approved incidents, results of completed control assurance and audit). This requirement should be met at all times. RMG Operational Risk will monitor this on a 6 monthly basis.

End to end view - Business ORSAs should cover critical controls in business AND support functions. Controls in support functions that are deemed critical for business should be raised in the support area ORSA against the relevant risk in the support area. Business ORSAs should consider those critical controls in support area ORSAs and their impact on the relevant risk in the business ORSA. Business must evidence their end-to-end considerations. This may be done in Open Pages by linking to the support area critical control however, other evidence may also be acceptable. Refer Appendix D;

MGL.0010.0003.0659

mailto:[email protected]

Completeness – All material risks and critical controls mitigating them, together with issues and actions relating to those critical controls must be adequately identified and documented in OpenPages

Coverage and granularity – All material businesses, products and geographical locations must be adequately covered by ORSAs. It is expected that Businesses will adopt Divisional ORSAs and Support Areas will adopt ORSAs in line with the Business that they support.

— For example in CFM, ORSAs should be prepared for CFM Energy Markets, CFM Credit Trading etc rather than 1 CFMORSA.

— For COG Technology it means preparing ORSAs at COG Technology (BFS), COG Technology (MSG), rather than 1 COG Technology ORSA.

— Risks arising from Joint ventures (where applicable) should be considered

Reasonableness of control and risk assessments – ratings should be reasonable given all available information;

Appropriateness of remedial actions – All critical controls not rated Effective should have actions. Actions and their due dates should be adequate to address the identified control weaknesses.

In addition to the quality standards above, ORSAs must meet the following basic requirements:

All submitted ORSAs have been reviewed by the BORM team and the ORSA owner

ORSA summary has been discussed and approved by the Group Head

ORSAs are submitted to RMG on time. Risks, controls, issues and actions are described clearly and concisely. Descriptions are business specific, rather than generic, and enable someone with basic understanding of the business to understand the ORSA;

All the required fields for risks, controls, issues and actions in OpenPages are appropriately populated. See the section below on ORSA documentation requirements in OpenPages.

There are no risks without controls;

There are no critical controls that are rated less than Effective, without appropriate issues and actions linked to them or documented risk acceptance.

2.3 ORSA documentation requirements in OpenPages

The following are fields that are required to be completed in OpenPages: Risks:

Risk Name – A brief title for a risk. The title should be specific to each business. Using generic Parent Risk names (see Appendix B) is not appropriate. Control breakdowns (failure of reconciliation to pick up errors) should be avoided, unless the ORSA belongs to a control function (e.g. Market Operations may have a risk called failure of confirmations to detect an error, but the relevant CFM risk would be Trade Error, or Trade Booking Error, or Unauthorised Trading);

Risk Description – A more detailed risk description. Various causes could be listed here;

Risk Source – Flags whether it’s a Library or a Business Risk;

Risk Status – Identifier of whether a risk is Active or Deleted;

Parent Risk Category & Parent Risk – A high level risk theme developed by RMG Operational Risk for Macquarie wide analysis. See Appendix B;

Inherent Risk Impact Rating – The impact of the risk eventuating, with no controls in place. See Appendix C;

Inherent Risk Likelihood Rating – The likelihood that the risk will eventuate with no controls in place. See Appendix C;

Residual Risk Impact Rating – The impact of the risk eventuating, with controls in place. See Appendix C;

Residual Risk Likelihood Rating – The likelihood that the risk will eventuate with controls in place. See Appendix C;

Controls:

Control Name – A brief title for a control. The title should be specific to each business. Using generic Control Areas (see Appendix B) is not appropriate;

MGL.0010.0003.0660

Control Description – A more detailed control description. Control objective can also be described here in more detail;

Control Source – Flags whether it’s a Library or a Business Risk;

Control Status – Identifier of whether a risk is Active or Deleted;

Control Type – Flags whether it is an Operational Risk or Compliance control;

Control Area – A high level control theme developed by RMG Operational Risk for Macquarie wide analysis. See Appendix B;

Control Weighting – Flags controls as Critical, Key or Non-key (see section 2.4.2);

How does management know it’s working – Description of the mechanisms in place that allow management to answer whether the critical control is working or not. E.g. exception reporting.

Issues:

Audit Issue – This field is for RMG Internal Audit use only;

Issue Source – Flags whether it’s a Library or a Business Issue;

Issue Title – A brief heading for an issue;

Issue Description – A more detailed explanation of an issue. The issue is a control deficiency or gap;

Issue Type – Flags whether it is an Operational Risk or Compliance issue;

Issue Status – Identifier of the stage of the issue lifecycle (e.g. Open, Closed);

Issue Priority – The significance of the issue. Refer to the Operational Risk Action Guide.

Publish Status – The issue status (i.e. draft or published). This field should be set to “published” for it to appear on dashboards and reports.

Actions:

Audit Action – This field is for RMG Internal Audit use only;

Action Title – A brief heading for an action;

Action Description – A detailed description of the action to resolve the issue;

Action Owner – Employee responsible for performing the action;

Action Type – Flags whether it is an Operational Risk or Compliance action, or both;

Business Status – Identifies action status – Not Started, In Progress, Implemented, or No Longer Applicable;

Publish Status – The action status (i.e. draft or published). This field should be set to “published” for it to appear on dashboards and reports;

Due Date – The date by which the action needs to be completed. Refer to the Operational Risk Action Guide.

Action Priority – The significance of the action. Refer to the Operational Risk Action Guide.

2.4 ORSA processes

To set up a new ORSA the following suggested process should be followed:

2.4.1 Identify Key Risks facing the business and assess inherent risk rating.

Start with survival threatening risks, and then work down the severity of impact. Please note:

Identification should include risks whether or not they are under the control of the Business Unit (e.g. a third party vendor failure is still a risk to the business).

It is important to identify all material risks to the business, not all possible risks.

After first analysis similar risks should be combined.

MGL.0010.0003.0661

At this stage controls mitigating these risks should not be considered. You can assume that people have the same morals and that laws, the police, government still exist. Assess the risk’s impact and likelihood using Impact & Likelihood rating matrix in Appendix C. It is expected that, at this stage, most of the risks identified should have a high inherent risk score. If risks are low inherently, they maybe immaterial to the business and therefore it may be appropriate to remove them from the ORSA.

2.4.2 Identify Critical Controls

Identify the critical controls that currently exist to manage each of the risks identified. Consider the different types of controls (e.g. preventative, detective). Definition: A control is a process, device or practice that acts to minimise negative risks and consequences.

Critical controls are preventative or detective controls that are crucial to the effective management of operational risk. These controls are so crucial that they require regular proactive assurance. The operational failure of a Critical Control could:

— Result in an unexpected material1 loss; or

— Result in an internal / external fraud; or

— Materially impact the ability to comply with regulatory or legislative requirements; or

— Materially impact Macquarie’s reputation; or

— Result in a significant Work, Health, Safety and Environmental (WHS&E) incident.

Key controls are controls that are important but not crucial to the effective management of operational risk. The breakdown of which attract management interest;

Non Key controls are any other controls that contribute to the prevention or detection of errors or inadequacies. The breakdown of such controls would not directly lead to material errors or losses.

Note that RMG Operational Risk does not require having Non-Key controls in ORSA. The requirement is to identify Critical and Key Controls.

2.4.3 Assess Control Effectiveness

Control Design Rating Guidance

Effective (E) The control meets the design objectives and mitigates the risks.

Needs Improvement (NI) The control is designed to mitigate some but not all aspects of the risk

Ineffective (I) The control is poorly designed and does not meet its objectives or mitigate the risks.

Control Performance Rating Guidance

Effective (E) The control operates as designed.

Needs Improvement (NI) The control is normally operational but has occasional breakdowns

Ineffective (I) The control breakdowns are systemic in nature.

When assessing Critical Control effectiveness, the following should also be taken into account:

1 Material loss is considered to be at least 1% of MGL’s Net Profit after Tax. This is currently between $5million-10million.

MGL.0010.0003.0662

Timing of Control Assurance work performed over Design and Performance of the Critical Controls;

“Effective” Critical Controls ratings indicate that proactive Control Assurance work has been performed to support the positive rating;

The Design and Performance of the Critical Control has been analysed and challenged by appropriate people (e.g. walkthrough or samples testing has been performed);

Systems on which the control relies have been considered (e.g. Access is segregated, data is secure);

Actions associated with controls have been appropriately addressed (i.e. no high open actions)

A level of conservatism has been applied to a control rating; and

Materiality of control breakdowns (e.g. incidents) has been considered. Materiality must be set at an ORSA level (e.g. Division for a divisional ORSA).

For further guidance on Critical Control ratings refer to section 5.5 in the Control Assurance Methodology document on Macnet. Note: Controls rated ‘Needs Improvement’ or ‘Ineffective’ cannot be rated ‘Effective’ just because of a risk acceptance decision. Risk acceptance decision should not impact control ratings.

2.4.4 Assess Residual Risk

The objective is to assess the level of risk after the effect of controls is considered. This is called the Residual Risk.

2.4.5 Identify remedial actions

Once the risk and control assessment are completed, actions for critical controls not rated Effective must be agreed and documented in OpenPages.

2.4.6 ORSA Workshops and alternative approaches

ORSA workshops are useful in coming up with a brand new ORSA through discussing risk and controls in a business. They are also useful in updating ORSAs for significant changes (e.g. significant new product or business, or internal change). Key material pertinent to the ORSA should be prepared and analysed in advance (e.g. audit issues, NPAs, etc). These should be summarised as a pack and presented to workshop participants. There are two key roles required to run an effective workshop: Facilitator - Responsible for ensuring that the workshop considers the key operational risks and to assist the business participants to articulate the key risk events. To this end the Facilitator should ensure that discussion does not stray away from achieving the objectives of the session. Data Capturer - Responsible for capturing the output of the discussion, particularly risks (including causes & effects), controls, control deficiencies or control enhancements. If participants mention or identify control weakness then these should be captured appropriately. The Data Capturer aids the facilitator in ensuring that conversation in the session remains focused and that risk events are clarified. Any issues that cannot be resolved during the workshop should be noted by the Data Capturer and taken offline. Alternative approaches to ORSA Workshops include:

MGL.0010.0003.0663

Scenarios;

Qualitative reviews;

Questionnaires; Refer to Appendix E for further details on these alternative approaches.

2.4.7 Ongoing maintenance of previously created ORSA

Once ORSAs have been created, the ongoing maintenance involves:

Keeping the list of critical controls and key risks up to date, based on internal and external changes;

Keeping the ratings of critical controls up to date based on incidents, control assurance work, audits, key risk indicators;

Keeping issues and actions up to date (due dates, responsible person etc).

2.5 ORSA Summary

The ORSA Summary is intended to be a top down analysis tool, which should form a conclusion as to ongoing appropriateness of the control environment and identified actions. The ORSA Summary complements the ORSA, which is a bottom up analysis tool. A good ORSA summary should provide a transparent view of known and emerging control weaknesses and be no longer than a few pages. The following points should be included in the ORSA Summary, where relevant:

Outline the key changes that have taken place in your business (e.g. acquisitions, new products, new locations, new systems, new processes, restructures) or other issues affecting your business risk profile, including whether given the significance of the change there is a need for an New Product Approval (NPA) refresh for the relevant business/product.

Describe at a high level the impact these changes are having on your business and control environment (e.g. transaction volumes, deal sizes, incidents, audit issues etc, emerging issues);

Discuss significant themes highlighted by support areas’ ORSAs;

Provide an update on your Control Assurance;

Describe key projects in the business (including status update and key milestones). Comment on the effectiveness of the governance structure and the impact on the control environment;

Draw your conclusions. The ORSA Summary should be a concise document. Refer to Appendix A for the list of examples of what works and what does not work.

MGL.0010.0003.0664

3. RMG Operational Risk’s role in ORSAs

RMG Operational Risk owns the ORSA framework, refines and updates it to keep it relevant to the changing internal and external environment, and provides thought leadership on ORSAs to businesses. Businesses should engage Lead Directors throughout the ORSA process (Discussion of ORSA approach, participation in business workshops, discussions with Senior Management and review draft ORSA Summary).

3.1 ORSA Review and Board Reporting

RMG Operational Risk reviews ORSA quality on a six monthly basis and provides feedback to businesses and support areas. RMG Operational Risk assesses the reasonableness of the ORSA conclusions based on various risk data available to RMG Operational Risk (e.g. new product approvals, audits, incidents, control assurance results, scenarios explainable events). Following the analysis, discussions are held with Business Operational Risk Managers (BORMs). These discussions involve some probing of effectiveness of Critical Controls and clarification of themes identified in ORSA Summary documents. RMG Operational Risk will review and challenge the submitted ORSA documents as appropriate. The business owns their assessment of risk and control rating and RMG Operational Risk will not validate every assessment of risk and control. However, RMG Operational Risk has the discretion to determine ORSA ratings. RMG Operational Risk reviews ORSAs and Control Assurance against the minimum requirements set out in this policy and accompanying guidance and provides feedback to businesses and operating areas on ORSA and Control Assurance quality. This feedback is also summarised and reported to the relevant Board Committee each 6 months.

3.2 Hindsight Reviews

From time to time, RMG Operational Risk performs hindsight reviews on ORSAs. A significant incident or audit finding, which can reasonably be expected to have been identified through control assurance and ORSA processes, may prompt such a review. The review involves the analysis of ORSA information in OpenPages. In cases, where known control gaps or weaknesses were not transparently identified in OpenPages, discussions take place with relevant BORMs on why it was the case. Based on those discussions a capital penalty may be applied in the relevant business scorecard.

4. Internal Audit’s role in ORSAs

Internal Audit also reviews ORSAs as part of the normal Audit cycle and performs validation of key risk and control information in ORSAs as part of normal audits, with the objective of checking their accuracy and completeness. Due to differences in approach and materials, Internal Audit conclusions on ORSA quality of each business may differ from those of RMG Operational Risk.

MGL.0010.0003.0665

5. User and Data Administration

5.1 Access Management

Access levels in the OpenPages system are complex and require careful management. Therefore, no new users can be set up, and access should not be upgraded unless users received relevant training. The following table summarises various access levels in OpenPages relevant to ORSAs and Control Assurance.

ORSA Issue Action Test Plan Test Result

User type

RE

AD

WR

ITE

DE

LE

TE

*

AS

SO

CIA

TE

RE

AD

WR

ITE

DE

LE

TE

*

AS

SO

CIA

TE

RE

AD

WR

ITE

DE

LE

TE

*

AS

SO

CIA

TE

RE

-OP

EN

RE

AD

WR

ITE

DE

LE

TE

*

AS

SO

CIA

TE

RE

AD

WR

ITE

DE

LE

TE

*

AS

SO

CIA

TE

Op Risk Write

Op Risk Read and Associate

Business Read Only

Incident Creator

For granting or editing user access, contact COG Tech ETD RMG Helpdesk. READ - The user can view the details of the objects contained in the folder and the folder itself, but cannot edit them. WRITE - The user can view the details of the objects within a folder and modify them, but cannot delete them. Write access to a folder is required for creating new objects within the folder. DELETE - The user can soft-delete objects by changing the object status to deleted. ASSOCIATE - Ability to associate the object with other objects in the system. RE-OPEN - The user can re-open the object within a folder.

5.2 Data Management

Data in OpenPages can be hard or soft deleted. A soft delete involves changing the status of the Open Pages object to “Deleted”. OpenPages users with Op Risk Write access can soft delete any Op Risk data (risks, controls, non-audit issues, non-audit actions, incidents, test plans, test results). Hard deletion involves removing the data from the system and is done through a separate request sent to COG Tech ETD RMG Helpdesk

MGL.0010.0003.0666

APPENDICES

APPENDIX A ORSA Summary: what works and what does not work? Based on previous ORSA Summaries we have summarised elements that do and do not work well in drafting an ORSA Summary:

What works well? What doesn’t work?

Top down analysis with conclusions Example: “After the acquisition of ABC Financial in Johannesburg the business has been working on integration. Many system security issues were identified last month in the integration process. In addition, some weaknesses have been flagged around segregation of duties in support functions. Dispensations are being obtained for IT Security gaps, and business has addressed the segregation of duties issue by moving some back office functions to Sydney. The business continues to assess back office controls ‘Effective’ but in our view this will put significant resourcing pressure in coming months on support teams in Sydney.” This is within risk tolerance

Bottom up analysis of changes in risk ratings Example: “Risk B’s residual rating has increased from 4 to 6 due to higher level of audit issues.” OR “Our top 10 risks are now A, B, C, D, E, F, G, H, I, G. Out of these E is a new top 10 risk and K has fallen off the list.”

Where BORM is aware of known or emerging control gaps, a transparent calling out of those issues Example: “Recently a payment process was moved from New York to Sydney. While there have been no payment related incidents, we are concerned that there may have been gaps in the handover process. This is outside our risk tolerance. The BORM has reprioritised Control Assurance tasks and is planning to review the payment controls in Sydney by June 2011.”

Not calling out known or emerging issues Example: “There have been no losses relating to payment process post handover. The process continues to work well.”

MGL.0010.0003.0667

What works well? What doesn’t work?

A summary of significant projects/initiatives with explanations of why they are in place Example: “A new ABC system implementation has been initiated to address current weaknesses around managing daily P&L process for this business.”

A listing of projects with no explanations of what is driving them Example: “A new ABC system implementation has been initiated.” A listing/summary of BORM’s own actions only. Examples:

“BORM is overseeing project ABC”.

BORM will redesign the process, or set up fortnightly meetings to address the known issues.

Reporting on the ORSA process by exception, i.e. only where the policy was not followed Example: “Because the new back office system implementation has taken over most of the BORM’s time, we agreed with RMG that ORSA workshop for this business wouldn’t be conducted. Instead the BORM independently reviewed key risk ratings and critical control assessments. All other divisions’ ORSAs fully met the policy requirements”.

A detailed description of the ORSA process Example: “We started the ORSA process in February 2011, met with all division heads, and discussed their businesses through ORSA workshops. We covered external and internal losses, and as a result, raised the residual risk rating for XYZ risk, and changed the effectiveness of KLM control.”

An update on Control Assurance Example: “3 out of 12 Critical Controls were tested (ABC, DEF, GHI). We found 1 issue relating to the design of ABC control. The business head has committed to resolve it by June 2011.”

A general statement about Control Assurance Example: “Control Assurance is on track”

Commentary and conclusion on significant themes in Finance, IT, other support area ORSAs. If business ORSA contradicts support area’s ORSA, an explanation as to why it is the case and the BORM’s own conclusions.

Example: “IT have assessed User Access Review (UAR) controls as Ineffective due to delays in implementing a system solution for UARs. We conclude that, while the manual UAR’s are neither scalable nor efficient, they remain Effective.”

Disagreeing with support area ORSA assessments, with no proper explanation.

Example: “Finance have assessed Balance Sheet Reconciliation control as ‘Needs Improvement’. From business perspective this control is Effective.”

MGL.0010.0003.0668

APPENDIX B Parent Risks and Control Areas In order to enable Macquarie wide analysis of risks and controls, RMG Operational Risk has developed a list of Parent Risks and Control Areas. Parent Risk Categories & Parent Risks

Asset Risk Business Disruption

Risk

Client and Product

Risk

Financial Manageme

nt Risk

Information

Technology Risk

Legal and Complianc

e Risk

People Risk

Theft and Fraud

Transaction Risk

Error on cash or

securities movements

Business Disruption

Inappropriate advice or Mis-selling

Credit Risk Manageme

nt

IT Project Failure

Environmental Damage

Employee Mis-

management

Theft and Fraud

Trade Execution

Error

Loss or damage to

physical assets

Inadequate third party

service

Model or valuation

error

Hedging Error

Lack of data integrity

Legal and Compliance

risk

Inadequate staff or skills

Unauthorised Activity

Transaction Processing

Error

Poor customer

management

Inaccurate external reporting

Tax error People

Safety Risk

Product Flaws

Inaccurate internal

reporting

Liquidity and funding

risk

Market risk manageme

nt

Parent Risk Parent Risk Description and Examples

Error on cash or securities movements

Includes incorrect or late payments and settlements, payments made to incorrect party, failure to receive payment. Excludes fraud.

Loss or damage to physical assets

Losses from damage to physical assets owned by Macquarie. Includes losses due to fire, flood, earthquake, vandalism.

Business disruption Losses due to systems, data or premises unavailability. Includes losses resulting from software or hardware outages, telecommunications and utility outages/disruptions, businesses not being able to recover within expected timeframes.

Inadequate third party service

Includes losses arising from mis-performance or failure of third party service provider, lack of oversight, inappropriate SLA, over-reliance on third parties. Excludes oversight over JVs.

Inappropriate advice or mis-selling

Includes losses arising from poor advice given to client, negligence or unintentional failure to act in the best interests of the clients, failure of fiduciary duty, failure to disclose all relevant information, disputes over performance of advisory activities.

MGL.0010.0003.0669


Model or valuation error

Includes incorrect assumptions and formulas in spreadsheets and system calculations/valuations. May include unit pricing errors (depending on the cause).

Poor customer management

Includes losses due to poor customer service, incorrect statements sent to clients, customer complaints.

Product flaws Includes losses due to inadequate or inappropriate product development, product design, product quality, product complexity. Excludes mis-selling and model/valuation errors.

Credit risk management

Includes losses due to errors or breakdowns in the credit risk management process. Includes collateral management, incorrect or failed margining, breach of credit limit, failure to obtain credit approvals.

Hedging error Includes losses as a result of inadequate hedging, including flaws or errors in the hedge calculation or model, delays in placing the hedge, or a lack of understanding of the exposure.

Inaccurate external reporting

Includes losses due to errors in external financial or management reporting. Excludes tax returns (Tax Error).

Inaccurate internal reporting

Includes losses due to errors in internal financial/management reports, or inadequate financial risk management processes.

Liquidity and funding risk

Includes losses due to breakdown or failure in liquidity and funding risk management, failure to maintain sufficient liquid financial resources to meet near term liabilities as and when they fall due.

Market risk management

Includes losses due to errors or breakdowns in market risk processes leading to losses arising from changes in market prices or volatility. Includes errors or breakdowns in interest rate risk management leading to losses due to adverse changes in the level, shape and volatility of yield curves. Excludes Hedging errors.

IT Project failure

Includes losses arising from inadequate project planning, management and monitoring. Late delivery, poor supervision or management, failure to recognise a risk, priority of projects incorrectly managed. Excludes IT change management incidents leading to Business Disruption or Lack of Data Integrity.

Lack of data integrity Includes losses due to errors, omissions or misrepresentation of data, lack of reliable data, data sources unknown, lack of understanding of data, inconsistent, or not documented, use of incorrect information which causes a negative impact.

Environmental damage

Includes losses due to environmental damage caused by Macquarie, e.g. marine or environmental damage.

Legal and Compliance risk

Includes losses due to breach of regulation or legislation, breach of contract, lack of enforceability of legal documents, incorrect disclaimers, mis-statements, documentation errors, breach of client mandate, confidentiality breach, failure to manage conflicts of interest. Includes fines, penalties and punitive damages by regulators. Includes breach of internal policies, e.g. Information Barriers. Excludes Tax.

Tax error Includes losses due to lack of understanding of tax regulations, errors in tax calculations, fines, penalties, or punitive damages from tax regulators.

Employee mismanagement

Includes losses due to inappropriate treatment of employees, compensation, benefits, termination issues, equal opportunity issues, harassment, discrimination, victimisation, concerns & complaints and other inappropriate workplace behaviour. Excludes People safety risk.

MGL.0010.0003.0670


Inadequate staff or skills

Includes losses due to inadequately trained/skilled employees, appropriate pre-employment checks not carried out, loss of key person, lack of succession planning and/or cross training.

People safety risk

Includes losses incurred as a result of not providing a safe environment for employees, contractors and third parties, such as breaching health and safety regulations, general liability, workers compensation, civil action, employee recompense. Includes the application of the WH&S framework to subsidiary companies and affiliates (e.g. Funds).

Theft and fraud

Includes losses due to internal employees undertaking fraudulent activities and losses due to fraudulent acts by a third party. Includes physical security breach, hacking, theft of information, bribes, extortion, embezzlement, collusion, disbursement to inappropriate accounts, improper expense claims, forgery, client misrepresentation, misappropriation of funds. Excludes Unauthorised Trading.

Unauthorised activity Includes losses due to unauthorised trading, inappropriate or unauthorised access to our IT assets, access to sensitive data, physical security breach.

Trade execution error

Includes losses arising from fat finger errors, mis-matched trades, and buy instead of sell trades.

Transaction processing error

Includes losses or errors due to failures in the transaction process. Excludes Error on cash or securities movements, Trade execution error. May include unit pricing errors (depending on the cause).

Control Areas

Control Area Control Area Description

Finance & Accounting controls

Relates to controls in the accounting process, including identification, measurement and reporting of financial information.

Operational Reconciliations

Relates to business reconciliations outside of normal Finance reconciliations. E.g. Daily securities reconciliations, data integrity reconciliations by Market Operations.

Board & executive management oversight

Relates to Board & Executive Committees executing their oversight & management responsibilities.

Business continuity management

Relates to disaster recovery, business continuity, management of unusual or overload activity levels, building maintenance etc.

IT change management

Relates to IT changes and controls within IT Change Management process (e.g. UAT, Rollback etc).

Compliance Relates to controls to ensure compliance with legal & regulatory requirements.

Culture, training & development

Relates to the shared values & practices of employees, training & career development, and the delivery of learning to improve skills and knowledge or performance.

Customer management

Relates to managing customers including, pre-sales customer due-diligence and post sale service and relationship management activities.

Management supervision

Relates to the management of information used for managerial decision making such as use of intelligence & benchmarking data, monitoring of outstanding items or breaches etc.

Management of systems

Relates to the availability and performance of systems.

Third party oversight and management

Relates to the management of third party service providers.

MGL.0010.0003.0671

Control Area Control Area Description

Payment processing controls

Relates to the authorisation, execution & recording of payments and other settlement processes.

People planning, selection & succession

Relates to HR processes including recruitment & termination, promotion & remuneration, performance management and succession planning.

Product & business approval

Relates to the due diligence, review & approval of new products, businesses or clients, as well as major organisation changes and business restructures.

Risk management Relates to managing risk exposures in terms of identifying, assessing, monitoring & reporting on risks, & actions taken to mitigate them.

Safeguarding of information & physical assets

Relates to the security of information in any media format such as written, electronic etc, and the security of physical assets for fixed assets, intangibles, physical commodities (e.g. oil) in transit etc.

Transaction or trade processing controls

Relates to the authorisation, execution, recording and confirmation of transactions. Excludes transaction settlement.

User access management & segregation controls

Relates to the management of user access and segregation of duties.

MGL.0010.0003.0672

APPENDIX C Risk (Likelihood and Impact) ratings The following Risk heat map is only a guide for how to rate risks. A level of professional judgement is required. Since it is a very subjective area, the value of risk ratings is in ranking risks relative to each other.

Rating Scale

1 (Low) 2 3 4 5 (High)

Financial

Direct loss or cost of up to 0.5 to 1% of Annual Budget / Revenue Target.

Direct loss or cost of up to 1 to 5% of Annual Budget / Revenue Target

Reduction in business opportunities from key clients


Zero return on investment

Potential loss of key business opportunities


Negative return on investment

Loss of key business opportunities

Direct loss or cost of greater than 30% of Annual Budget / Revenue Target

Sustained negative return on investment

Significant loss of key business opportunities

Reputational

Reputation intact, internal knowledge only

Minimal or no impact on customers

Industry knowledge of incident, but no media attention

Client - Customer concerns

Adverse local media coverage

Concerns raised by shareholders

Customers demonstrate willingness to move business

Adverse capital city media coverage

Significant decrease in shareholder support

Loss of a key customer

Adverse global / national media coverage

Parliamentary inquiry

Major public concerns raised

Major loss of shareholder support

Loss of many key customer

Regulatory

Regulatory / Exchange requirement not met No reprimand or special undertaking

Verbal warning from Regulators / Exchange

Regulatory / Exchange formal written warning

Exchange / Regulator requires immediate press statement Regulatory imposed fines

Loss of banking license Suspended from trading on Exchanges

Internal

Events that are absorbed into normal activity

Low staff turnover An event, the impact of which can be absorbed, but management effort is required to minimise the impact Some staff morale problems

Poor reputation as an employer A key employee leaves A significant event which can be managed under normal circumstances

Some key executives leave the company Bank is not perceived as an employer of choice A critical event which can be managed with escalation and significant management effort.

Large number of key executives / directors leave the company An event that Management is not able to impact by increased management

MGL.0010.0003.0673

Frequency: Consider the frequency of the risk event occurring

Rating Category Frequency

1 Low Unlikely in next year

2 Occurs once during the year

3 Occurs up to 5 times a year

4 Occurs up to 20 times per year

5 High Occurs more than 20 times per year

Risk Assessment Calculator – heat map Impact * Frequency = Risk Severity

Fre

qu

en

cy

M H H H H

M H H H H

L M H H H

L L M H H

L L L M M

Impact

MGL.0010.0003.0674

APPENDIX D End to End ORSA requirement – Example with BFS and Technology

BFS Business

BFS Technology ORSA

COG Technology

BFS Technology

ETD Risks

BFS Technology

BFS Business

BFS Business

ETD

Critical

Business Control

Assurance

IT Control

Assuranc

ETD Control

Assurance

Assurance Assurance

MGL.0010.0003.0675

APPENDIX E Alternative approaches to ORSA Workshops Approach Scenarios

Introduction An alternative approach to conducting a conventional workshop is to use a scenario or situation that has occurred elsewhere to assist in identifying and/or quantifying risks. This may include: 1. External events – RMG subscribe to an external event database which

maybe useful in identifying losses incurred by other institutions.

2. Internal Events – RMG may be able to provide information on relevant internal losses.

3. Fictitious Events – It is also possible to design an appropriate fictitious event.

Purpose This approach serves a number of purposes:

Identification of emerging or new risks to be considered in an ORSA;

Confirmation that the control environment will ensure that “it won’t happen here”;

Provides an understanding of how our control environment, and the risk framework, help protect us against ‘big’ events; and

Gives participants an understanding of the role they play in maintaining the control environment.

Pros and Cons + Engaging and different to a standard workshop. + Useful to validate particular risks. – Probably not appropriate for a first time assessment. – Difficult to validate an entire ORSA.

Methodology The scenario should be explained to the participants and then discussed. The following questions may be useful prompters: Understanding The Scenario

What were the key causes of the event?

What controls failed that might have prevented the event?

What would you recommend they do to prevent this from happening again?

Identifying It’s Relevancy

How might the scenario be applicable to us?

What controls do we have in place to prevent this scenario?

What gives us confidence that our controls will work?

Identifying Actions

What practically could we do to ensure this scenario doesn’t happen to us?

Where do we have weaknesses in our control environment that might allow this to affect us?

Fictitious Scenarios Alternatively it may be engaging to ask participants to create a scenario themselves. The BORM should provide some background information and then set the participants the task to identify all the steps in the scenario. For example:

Fraud – How would you commit a fraud against the bank and get away with it?

Business Interruption – How could you stop your business area from operating?

It is important that enough guidance is given on the background and the scope of this task to enable participants to come up with a response.

MGL.0010.0003.0676

Approach Qualitative Review

Introduction A qualitative review of changes to the business and control environment can be useful to identify potential changes to an ORSA.

Purpose This approach serves a number of purposes:

Confirmation that the control environment is operating effectively.

Identification of changes to the business environment and the impact on the ORSA.

Pros and Cons

+ Engaging and different to a standard workshop + Useful to identify how the business changed. + Possible to validate the entire ORSA. – Not appropriate for a first time assessment.

Methodology Instead of going through the ORSA to identify changes, this approach requires the BORM to discuss changes to the business environment to understand the impact on the control environment. These changes are updated in the ORSA. The BORM should lead the discussion. The following prompter questions may prove useful. New Products / Locations

How have new products changed the business and control environment?

How have new locations changed the business and control environment?

Note: A new product and/or location may require a new ORSA to be produced. Scenario Analysis

If there have been changes in scenario estimates, particularly at the 50th percentile, how might they affect the ORSA?

Have the scenario workshops identified links between scenario estimates and risk drivers? Have these risk drivers changed? Have these drivers been considered in the ORSA?

Audit Results

How have recent audit findings been incorporated into the ORSA?

Are there general or specific trends from audits in other areas that may also be applicable to our business area?

Losses

Has the impact or frequency of incidents changed so that new risks need to be considered or existing assessments need to be reassessed?

Has there been a significant breakdown of the control environment which required remedial action? How has the action been incorporated back into the ORSA?

Key Indicators

How have key business indicators changed? What are the drivers for those changes?

MGL.0010.0003.0677

Approach Questionnaire

Introduction A questionnaire can be useful to gauge the confidential opinion of a number of respondents. The approach is most effective when the results are discussed to drill down in more detail and to provide feedback on how respondents compared to their peers.

Purpose The purpose of this approach is to use a questionnaire to understand participant’s assessment of the effectiveness of the control environment. It may be a useful approach if there are a large number of participants or if it is difficult to get the participants together for a workshop.

Pros and Cons

+ Good sense check from wider population. + Responders able to provide answers without manager’s influence. + Careful articulation of questions may allow strong validation of an ORSA. – Difficult to get specific insight into responses. – Responders may not see the wider picture

Methodology The BORM needs to prepare the questions and the answering methodology (e.g. Yes/No, Scaled 1-5, written, etc) and then select the responders. The distribution of the questionnaire should allow respondents to answer confidentiality. It is important that once the process has been completed that some feedback is provided to all respondents.

MGL.0010.0003.0678

version 3.0 june 2015 - financial services royal commission

Documents