Open Banking Concept

More documents

Recommendations

Info

Creating an Open Banking Framework for Canada Momentum: Efficiently leveraging the various participants in the ecosystem to minimize the duplication of effort. Given the variety of concurrent efforts regarding the oversight of financial institutions and system infrastructure (e.g., RPOF), the governance framework should be designed to minimize the duplication of responsibility between parties. Economies of scale could be realized by centralizing governance responsibilities but should be considered on a caseby-case basis to decrease the total cost of the system. For example, managing liability issues or cost recovery through a singular central entity may be helpful in simplifying these processes (at a lower cost) for all participants in the Open Banking system. How should oversight be structured? Ultimately, while the specific allocation of oversight functions between regulators, data generators, data consumers, and industry bodies that represent the customer are not outlined, there are two choices on how responsibilities should be structured: consolidated to a central body or delegated to individual market participants. For the functions that are centralized into a single “Open Banking Oversight Body”, the entity could take one of three forms: 1. Regulator-led: The entity (and thus the Open Banking framework) is led by regulation, with input from industry participants. 2. Consortium-led: The entity is led by a collaborative effort between a defined set of institutions (e.g., Interac), separated from the business-as-usual operations of those institutions to prevent conflicts of interest. 3. Industry-led: The entity is a collaborative and open entity that allows any institution meeting certain criteria (e.g., offers financial products and services) to participate in the design and oversight of Open Banking. This report is designed to offer considerations for Open Banking in Canada, regardless of which model of governance and oversight is selected in Canada, but the possible outcomes differ based on the chosen method of oversight. For example, the scope of data generators would be dependent on the type of central entity selected (if any). A regulator-led central entity would have the authority to mandate that a broad set of participants (e.g., credit unions, trusts) be included as data generators; however, both a consortium-led and an industry-led effort would rely on voluntary participation from financial institutions. As a result, the scope of data generators would likely be more limited. Ultimately, as Open Banking in Canada is explored further, the choice or the role and structure of the central body will be a key question with many follow-on effects; it is a choice that should be made early in the process of defining a framework for Canada. How do data recipients gain access to generators’ data? Two models could be used to facilitate access: 1. Commonly agreed-upon accreditation requirements and standard contracts between data generators and data recipients: Access to the ecosystem would require data recipients to receive certification that demonstrates their compliance to a pre-set criteria 12.
Creating an Open Banking Framework for Canada (e.g., regarding data privacy and security). Certain elements that concern the data generators’ and data recipients’ relationship (e.g., method and terms of cost recovery, liability) would be defined by a standardized contract with some flexibility to accommodate the unique circumstances of the datasharing arrangement. [SH(-T13] The intended “use case” of data is a hotly debated topic in other jurisdictions with more advanced Open Banking systems. Including use case as a criteria would be helpful in protecting consumers from malicious actors; however, it may limit the scope of third party providers with novel business models, potentially limiting innovation in the marketplace. 2. Bilateral commercial agreements (between data generators and data recipients): Both access to the ecosystem and specific elements would be defined through one-on-one agreements between data generators and data recipients, where parties have complete flexibility to negotiate the terms of the agreement. A commonly agreed-upon accreditation framework would simplify the process of gaining access to data, ultimately allowing more third parties to participate in the Open Banking ecosystem. However, it would be less flexible to changes in marketplace dynamics, and would require continuous updating in order to accurately reflect the broader environment in Canada. Commercial agreements would more rapidly adapt to changing conditions, but may limit the efficiency of the system (e.g., financial data aggregators would be required to negotiate individual bilateral contracts with every financial institution participating in Open Banking as a data generator). If a central-accreditation-based system is selected, criteria observed in other jurisdictions could serve as inspiration for a Canadian system. Some of these criteria could include: .. Security and privacy protocols: to ensure that sensitive personal and financial data is responsibly managed, and that data recipients are not introducing undue security risks to the system. .. Indemnity insurance: to provide data generators with some reasonable certainty that data recipients will be able to pay out if a liability issue occurs. .. Defined customer complaint management process: to provide customers with some reasonable certainty that accredited third parties will be able to support them in case of any issue. .. Defined mitigation measures for material disruptions: to ensure appropriate protocols are in place in the event of system failures, security breaches and other blockages to continuity How should liability be managed? Generally, Open Banking should decrease total risk in the system by reducing the need for customers to share their banking credentials with screen scrapers to benefit from services that require their financial data. However, it may result in a shift of liability from customers (who are in breach of their contract with banks by screen scraping) to other participants in the system. As a result, a clearly defined liability framework is critical to the development of an Open Banking framework that garners buy-in from data generators and data recipients alike. However, the liability framework is highly contingent on a variety of other framework choices; included below are several principles that may be helpful in guiding its design: .. Liability for data in general should be designed to be compatible with other existing relevant regulations (e.g., PIPEDA), not supersede them. This prevents the development of overlapping/conflicting requirements, ensuring that all participants have a common understanding of the roles and responsibilities of each player; additionally: .. For unintentional data breaches, liability should be assigned to the party responsible for the breach itself (the data recipient in the vast majority of cases). The data recipient should have adequate liability coverage for data breaches, and any accreditation program for data recipients should include both a security standard and a liability coverage standard. This will raise customer trust in Open Banking, even after a hypothetical data breach incident occurs. .. For companies intentionally misusing customer data (e.g. malicious actors acquiring accreditation), liability should be assigned to the body that a) granted that accreditation and/or b) extended that accreditation most recently. 13 .
Page 1 and 2: Creating an Open Banking Framework
Page 22: www.deloitte.ca Deloitte provides a

Open Banking Concept

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?