Privacy working group meeting 4 – September 22, 2022

This discussion guide is provided to assist working group members in preparing for the privacy working group’s fourth meeting. The wireframe provided in the Annex is intended to serve purely as a visual guide for the discussion of the consent process.

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

On this page:

• Discussion guide
• Outcomes

Discussion guide

Consent standardization

While consent will form the cornerstone of the open banking system, the manner in which it will be granted and displayed will contribute to awareness and adoption. Cumbersome and demanding processes may add additional layers of complexity, discouraging consumers from completing their requests and fully leveraging the benefits of their financial data. An inefficient process may also leave consumers with the feeling of less control over their own information, preventing them from making informed decisions. These factors could culminate in low consumer uptake and create headwinds for the growth of the system.

Standardization may address this issue. The Advisory Committee Report on Open Banking recommended that as part of the common rules, consumers must have a clear standardized process to provide and revoke consent. Creating visual familiarity in this and in closely related journeys is intended to create a common and consistent approach across ecosystem participants. In addition to contributing to a positive customer experience, standardization can improve the consumer’s ability to understand how their data will be used as well as the value of the data they are sharing.

Experiences from other jurisdictions support the benefits of standardization. The United Kingdom’s Open Banking Implementation Entity (OBIE) has conducted research showing the high likelihood of consumers failing to complete a journey when they are required to complete unnecessary steps or additional screens, namely in the context of low-risk transactions or access requests^{Footnote 1}. The OBIE developed consumer experience guidelines to address these issues^{Footnote 2}. On a similar note, the Australian regime recognized the importance of consumer adoption as a success metric for the Consumer Data Right (CDR). Australia therefore developed experience guidelines in support, and referred to the work conducted by the OBIE^{Footnote 3}.

The annex to this discussion guide is an initial step in the same direction. The wireframe proposes an approach where a consumer grants a data recipient consent to collect information, authenticates with the data holder and authorizes the financial information to be shared. The goal of this working group meeting will be to discuss the steps involved in the journey as well as the information to be provided along each step.

It is noted that both the OBIE and CDR guidelines were supported by working groups, market research, consumer testing and deep-dives into the customer journey, namely by providing greater detail regarding how financial information is displayed and grouped together in “clusters”. As such, the wireframe takes reference from the work conducted in these jurisdictions and proposes a first step. Future journeys may form part of the open banking system as it grows and matures.  

Discussion

1. Other than consent, authentication and authorization, is there another customer journey that merits standardization? Similarly, is there any other wording/information that should be standardized?
2. Is the wireframe journey proposed in Annex A appropriate and complete? Are any steps missing or unnecessary? Note that certain steps are proposed to be mandatory (must) whereas others optional (should).
3. What authentication method would best be suited for the customer journey (for example, app-to-app redirection, push notification, web based)?
4. Are the authentication principles listed in step 6 sufficient or are others necessary?
5. Would any steps be materially different if a SME client was completing the journey?
6. Would any steps be materially different if the process was conducted on a digital channel other than mobile (for example, a web browser)?

Annex A

Consent collection

1. Data recipient must ask the consumer to identify their account provider before requesting consent.
2. Data recipient must provide sufficient information to allow a consumer to make an informed decision, namely in consideration of the fundamental elements of valid consent discussed during the first meeting of the privacy working group.
3. Data recipient must provide the consumer with a description of the data being requested using clear, simple and not misleading language (for instance, in a drop down menu, in alignment with the data-minimization principle discussed during the second meeting of the privacy working group).
4. Data recipient must provide the date on which the consumer’s consent will need to be refreshed in line with the principles discussed during the first meeting of the privacy working group.

Authentication

5. Data recipient should make the consumer aware that they will be redirected to their account provider for account authentication.
6. Data provider must authenticate the user in-line with the following principles:
1. The experience to authenticate when redirected from the data recipient should mirror that of the data holder’s digital channels in that the customer journey should be no more onerous or time consuming than if the customer were accessing the data holder directly;
2. The customer should only be authenticated once in order to access their account information; and
3. The data holder should not create unnecessary delays or obstacles in the process and should avoid anything that would discourage the customer from completing the process.

Authorization

7. Data provider should display the name of the data recipient making the request on the inbound screen and must provide the types of account that the consumer can access their data from.
8. Data provider should display the term of the consent granted by the customer as well as the name of the data recipient.
9. Data provider must confirm the sharing request with the consumer without seeking additional consent.
10. Data provider should have an outbound redirection screen which indicates the status of the request and informs the consumer that they will be automatically taken back to the data recipient page.

Information consent

11. Data recipient should confirm the successful completion of the request.
12. * The consent dashboard will be discussed in the next working group meeting.

Outcomes

Consent standardization

Discussion 1

Other than consent, authentication and authorization, is there another customer journey that merits standardization? Similarly, is there any other wording/information that should be standardized?

• There was general consensus that consent, authentication and authorization are prime candidates for standardization. In addition, participants emphasized the importance of clear and easy to understand language.
• Participants noted that there should be flexibility given to authentication methods as many organization have their own process of authenticating customers. 

Discussion 2

Is the wireframe journey proposed in Annex A appropriate and complete? Are any steps missing or unnecessary? Note that certain steps are proposed to be mandatory (must) whereas others optional (should).

• Participants suggested a range of potential changes to the flow of the journey, but were generally supportive of the steps involved. It was noted that certain cases, particularly with joint accounts, may raise additional considerations for the customer journey.
• There was general consensus regarding the need for transparency and simplicity for consumers. Moreover, concerns from some stakeholders were raised regarding having a consent expiry date as some use cases may not warrant it.

Discussion 3

What authentication method would best be suited for the customer journey (for example, app-to-app redirection, push notification, web based)?

• There was general consensus that an entity’s existing authentication methods and procedures would be sufficient in an open banking context.

Discussion 4

Are the authentication principles listed in step 6 sufficient or are others necessary?

• There was general consensus that the principles were generally sufficient though some participants suggested making them mandatory as opposed to optional.

Discussion 5

Would any steps be materially different if a SME client was completing the journey?

• Participants noted that SMEs present challenges in an open banking context that require additional time and consideration to sort out prior to being included in the framework. Cases of shared credentials or how to ensure appropriate access rights for different users were given as examples.

Discussion 6

Would any steps be materially different if the process was conducted on a digital channel other than mobile (for example, a web browser)?

• There was general consensus that save for channel specific authentication methods, the steps would not be materially different.

Privacy working group attendees