Security working group meeting 4 – September 15, 2022

This discussion guide is provided to assist security working group members in preparing for the fourth meeting, which builds on the main risks discussed at previous meetings.

For questions or comments, please contact obbo@fin.gc.ca.

On this page:

• Discussion guide
• Outcomes

Discussion guide

Operational risk

Operational risk is commonly understood as the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events^{Footnote 1}. It includes legal risk, but excludes strategic and reputational risk.

Operational risk is inherent in all financial products, activities, processes and systems. While organizations are best placed to identify the causes of operational risk, the following are the most common types:  

• Fraud (for example, internal and external fraud)
• Employment practices and workplace safety
• Clients, products and business practices (for example, sales practices and internal conduct)
• Damage to physical assets
• Business continuity and resilience
• Legal risk
• Third party risk
• Product development
• Change management
• Data quality
• Incident management

Note that this list is not exhaustive and varies by institution, depending on variables such as size, complexity and risk profile of the activities undertaken.

The Advisory Committee on Open Banking noted operational risk as a key area for consideration in the development of a system of open banking. This is critical, as consumers must have trust and confidence that the system is designed with safety and security measures at every level in order for the system to succeed.

Operational risk management is addressed in existing regulations and guidelines. For instance, the Office of the Superintendent of Financial Institutions (OSFI) has developed guidelines applicable to federally regulated financial institutions outlining expectations related to operational risk management. Similar provisions exist at the provincial level. Finally, the Retail Payment Activities Act imposes operational risk management and incident response requirements on payment service providers. While these provisions can be referenced during the working group’s discussions, it is also important to consider their proportional application. 

Outcomes

Operational risk

• Participants listed requirements such as board oversight and visibility, assigning responsibility for risk management to a member of the senior leadership team, documenting policies and an independent audit function, to name a few. 
• The three lines of defence model did not generate consensus, with participants suggesting instead the implementation of segregation of duties in a manner that considers proportionality as well as an organization’s capability and resources.

• While certain participants suggested a prescribed approach based on risks posed by use cases, others proposed that such a model would be short lived given the constant evolution of use cases. In addition, reference was made to the Final Report of the Advisory Committee on Open Banking, which does not favour a use case approach. 
• Baseline requirements that could be expanded on by participants was also suggested as an alternative approach.
• Participants also noted the need to leverage existing legislations and existing guidelines on operational risks, including the Retail Payments Activities Act. 

• Participants identified internal and external fraud, third party risk, data and cyber security, consumer awareness, and technological risks as some of the operational risks that could threaten the open banking system.

• Options suggested by participants included independent assurance from a third party as well as periodic self-assessment attested by senior leadership. 
• Participants also noted the importance of directive guidelines to support self-assessments as well as penalties in the event it is carried on in an improper manner.

• Participants noted the size and resources of an organization, its maturity, the adequacy of implemented controls as well as ensuring proper oversight of risk.
• It was also proposed to have evolving requirements based on organization reaching certain milestones such as size, staff count and volume of API calls.

Security working group attendees