Liability working group meeting 6 – April 14, 2023

This discussion guide is provided to assist working group members in preparing for the meeting. This will be the last liability working group meeting as the two remaining topics will be covered on April 14.

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

Discussion guide

Service levels

The availability of information will underpin the growth and performance of open banking in Canada. For consumers to fully benefit from the system and for participants to build services, they must have confidence that information can be retrieved in a timely, dependable and consistent manner. Baseline metrics supporting data availability can be helpful in this regard. Additionally, defining such metrics can contribute to uniform requirements applicable to all system participants and offer a measure of system health which can highlight areas for improvement and provide key performance measurement indicators.

Metrics related to availability can be referred to as service levels. The concept is familiar in financial services where technology vendor contracts are complemented by a service level agreement, commonly known as “SLA”. Among the key points addressed by these agreements are performance levels and expectations for the delivery of services as well as remedies in the event they are not met.

While these service level requirements may appear only technical in nature, they are also relevant in the context of liability. At the last working group meeting, the discussion focused on liability between participants, namely the source of the legal relationship between them. In the case of Australia, this is addressed by the Consumer Data Right (CDR) regime. It establishes a deemed contract between data holders and accredited parties^{Footnote 1} as the basis of the relationship between them. The content of that contract is outlined in the data standards which the parties undertake to follow. Therefore, where a party does not meet its obligations under the standard, including with regards to service levels (which the CDR describes as “non-functional requirements^{Footnote 2}”), judicial redress may be sought^{Footnote 3}. As such, service levels must define availability requirements, as they form a critical element of liability by prescribing parties’ obligations.

The “non-functional requirements” of the CDR data standards include:

Minimum performance and availability expectations for data holders. For example, service availability requirements of 99.5% per month as well as prescribed response times;
Maximum traffic expectations for data holders which vary depending on whether the information is requested from an authenticated customer or related to public information;
Limitations on the number of API calls that a data recipient can make;
Requirements for data latency^{Footnote 4} such that data presented via API endpoints^{Footnote 5} should be commensurate to data presented via other digital channels; and
Requirements for data quality, such that it is accurate, up to date and complete.

While the data sharing regime under the United Kingdom framework does not explicitly address liability between participants, service level requirements were established by the Open Banking Implementation Entity (OBIE), the body in charge of implementation. As part of the “Open Data Participation Conditions^{Footnote 6}”, the OBIE documented certain service levels^{Footnote 7}:

Each API endpoint must be available 95% of the time during each 24 hour period;
Each API provider must comply with availability under a peak load of 500 requests per minute across all APIs for that provider;
Each provider must comply with availability under a load of 15,000 requests in an 8 hour window across all APIs for that provider;
API providers must provide OBIE with notice 60 days prior to the creation deletion or updating of an endpoint;
API providers may provide different versions for each API endpoint. When a version is updated, it is in the competitive space as to how providers should notify users and manage migration (except for security issues); and
A commitment that any change in data contained in an endpoint, such as interest rate change, is updated within 1 business day or as otherwise required by the Competition and Markets Authority Order.

Discussion

With reference to the requirements under the Australian and British systems, which service level elements are critical to the success of Canada’s open banking system?
Which elements would pose a challenge to implement?
Should service level requirements apply uniformly? Alternatively, should certain participants be dispensed from them?

Reciprocal data access

In their final report, the Advisory Committee on Open Banking recommended that the initial scope of the system include reciprocity. This means that all accredited participants within an open banking system would be equally subject to consumer-permissioned data mobility requests. In addition, reciprocity needs to be driven by express consumer consent and should not be used by market participants as a precondition for sharing data.

Discussion

What challenges would arise in implementing reciprocity among system participants?
Does reciprocity create a barrier to entry for some potential participants? If so, how can this be offset?

Outcomes

Service levels

Discussion 1

With reference to the requirements under the Australian and British systems, which service level elements are critical to the success of Canada’s open banking system?

While some participants warned against detailed requirements, preferring general obligations, such as data sharing according to scope and tech standards, most agreed that the system would benefit from the implementation of service levels.
Justifications for the inclusion of service levels included the potential for enforcement against system participants that fail to meet them, as well as the importance such metrics will play as the system evolves to new offerings.
Participants suggested service level metrics related to availability, latency and data quality. The importance of publicly reporting these was also stressed.
A few participants proposed parity as a service level, meaning third parties can access data on the same terms that customers enjoy.

Discussion 2

Which elements would pose a challenge to implement?

While acknowledging their importance in the open banking system, most participants identified data quality, availability, and latency as challenging to implement.
It was also proposed to start by requiring parity with digital channels before outlining other service level requirements.

Discussion 3

Should service level requirements apply uniformly? Alternatively, should certain participants be dispensed from them?

There was general consensus that service levels should apply uniformly across participants, with a caveat that certain metrics would have to factor the size and capabilities of a participant.

Reciprocal data access

Discussion 1

What challenges would arise in implementing reciprocity among system participants?

The major challenges identified included technology and resource limitations for smaller organizations.
Participants also warned of the impact on reciprocity where system scope is not clearly defined.