Consent Management for Open Banking

With the introduction of the Revised Payment Service Directive (PSD2), banks face many changes amid intensifying competition. PSD2 enables banks and customers to benefit from third-party APIs to obtain a better experience for their financial activities. However, this means that banks will have to share sensitive data, such as a customer’s financial information (with consent) to third-party companies, while also making sure that the customer's data and other information are secure. This article covers the basic concepts around consent management, tips for successful implementation, and how banks should prepare for it.

How important is consent management?

Within the open banking domain, account servicing payment service providers (ASPSPs) and third-party providers (TPPs) are strictly guided by open banking-specific regulations and other data guidelines — e.g., strong customer authentication regulated technical standards (SCA RTS) and the General Data Protection Regulation (GDPR). These regulations mandate that proper security measures and guidelines must be followed not only when gathering consumer data but also when sharing this data with TPPs — one of the main stakeholders in open banking. However, this data should only be shared under the explicit consent of the user, without which the service provider will be violating the GDPR, which was introduced in May 2018.

If an ASPSP shares data without a user’s consent, it could also mean that the shared data is not secure, is shared with unauthorized services, or is used to impersonate an individual by stealing their information.

The impact on banks

When it comes to consent management, the consent gathering phase must be followed by proper consent gathering and data-sharing techniques, as outlined in regulated technical standards. Since these can be region dependent, the methodologies and technologies used in developing such a consent management module can differ. As ASPSPs, banks must develop their infrastructures to adhere to these guidelines.

Especially owing to the rising popularity of open banking, the amount of information shared between banks and third-party providers (TPP) is increasing. Consumers are choosing open banking as it gives them the opportunity to manage their financial activities with multiple banks with a few taps on one interface, instead of going to each bank or using several applications. According to EU GDPR Article 7, banks must not only ensure that data retrieved from users are secure, but they should also provide users the opportunity to change their minds and revoke consent. This is true for almost all use cases regardless of the region. Note that consent management is not only about gathering consent or sharing data. It also focuses on a consumer’s right to revoke consent.

The GDPR has impacted global banks owing to their use of third-party APIs to provide services to customers. Even if banks had gathered customer data, with the introduction of the GDPR, they are not allowed to use these consents, as Article 5 states that customer data should not be retained for a longer period than necessary. Therefore, consent has to be gathered periodically. The GDPR also mandates that consent cannot be gathered from users as a result of them agreeing to the general terms and conditions of service. As stated in Article 7, consent must be gathered explicitly stating clearly in a way it is distinguishable among other matters.

Banks and banking customers can sometimes have different opinions on which data is important or not. Since the smallest mistake on the bank’s side can affect the bank’s brand negatively, banks should also be patient with their customers and educate them on exactly what kind of information will be gathered, and justify why it is required.

Consent management in a technical perspective

In the open banking context, consent management can be divided into three phases.

1. The consent phase.
2. The authentication phase.
3. The authorization phase.

The consent phase

In the consent phase, the interface shows the user what information is requested and for what purposes. During this phase, a user should be able to explicitly opt-out. If they are providing consent, then they should be accurately informed of the time-bound permission they are providing. This is an important lesson to be learned especially while working with the OBIE UK because they are adamant on the best UX practices in consent management. Therefore this consent phase must be built while keeping the customer experience in mind. This phase will be utilized by both the TPP and banking interfaces. It is in the TPP interface that the customer is first provided with the consent details that he/she is going to provide consent with. When it comes to the banking backend, the consumer must be first authorized by the bank in order to provide the consent details. Therefore, this order of the consent flow is subject to the perspective of the TPP and the bank.

TPPs are responsible for initializing the flow with accurate details shown to the user and the bank is responsible for verifying and providing with the consent details that the user is about to accept or deny.

The authentication phase

After the user is informed about providing consent, it is the bank’s responsibility to take over and engage the user in authentication mechanisms to ensure the security of the customer’s data. Both the UK and Berlin open banking specifications mention that this stage should be separate from the TPP user flow to ensure that the banking credentials are secure with the bank and not exposed to the TPP. The upcoming Australian CDR specification lists this as a best practice.

The authorization phase

In this phase, the consumer is presented with the details about the consent required on the bank-user interface and is asked to allow or deny the request from TPP to access the shown data. The response from the user is then sent to the bank backend, and the data must be recorded accordingly.

Important points to remember when implementing a consent management flow

Consent must be gathered explicitly

When seeking consent, financial institutions should avoid using blanket terms and conditions or lengthy privacy policies. Consumers must be made aware of who they are granting access to their data, for what period of time, for what purpose, and for which specific data. They also have the right to revoke this consent. In an open banking context, the above parameters can be defined as follows:

1. Who they are granting rights to: TPPs identity
2. For what purpose: Payment/account details
3. For what period of time: Number of days
4. Expiration process: When it will expire and how can the user revoke consent

Other information, such as customer address, gender, and date of birth, is not included in the consent-gathering process. These details are not required in the open banking consent flow; the required details are explicitly presented to the customer in a simple and straightforward manner.

Once consent is granted, the user will be able to use services provided by the TPP.

Unlike the UK’s and the Berlin Groups’ approaches, the Australian CDR aims to seek consent without using a separate consent API. This means that there will be no consent API that is explicitly implemented to gather consent and related data in V1 of the Australian specification for open banking. Instead, (Open ID Connect) OIDC scopes and claims will be used to define consent and share data.

“Consent requirements will be communicated between the Data Recipient and Data Holder via the authorization request object. The primary mechanism for capturing consent will be scopes and claims under [OIDC].”

Data protection laws and the bigger data picture

The GDPR empowers users to be in control of their data. According to this regulation, it is a bank’s responsibility to securely store any data provided by the customer and also to take necessary actions, such as providing security mechanisms before gathering consent.

The GDPR also mandates that the user should be able to view, edit, or delete some or all of their details stored on behalf of them. The bank is responsible for providing ways to take the above action.

Having a simple and straightforward mechanism to gather and use consent

According to PSD2, banks must enable access to TPPs by using the same interface they use to interact with their users. In case the bank’s existing infrastructure does not support this, the bank must then provide a separate new interface for this purpose.

Because of this, we are seeing not only banks but also different specifications such as the UK and the Berlin Group provide a basic consent API. However, these consent APIs do not follow a common standard as there is no current international standard for a consent API.

At the time of writing this article, Australia is still in the process of finalizing its OB specification. Currently, the country has identified three approaches to implement consent management.

According to the Consumer Data Standards (CDS), they are,

Option 1: Defer inclusion of a Consent API until a requirement exists In this option, the inclusion of a Consent API will be deferred until a later date when a specific requirement is introduced that requires such a pattern to be adopted. Until this time the profile would be managed to ensure that the inclusion of the Consent API would be a non-breaking change and therefore able to be easily accommodated.

Option 2: Include a Consent API as an optional mechanism In this option, the specifics of a CDR Consent API would be defined but would be defined as optional. No mandated CDR requirements would be dependent on the Consent API to function. The operation of the Consent API in the context of the CDR would, however, be clearly defined and if a Data Holder wished to include the pattern to support extension functionality (such as payment initiation) this could be accommodated.

Option 3: Include a Consent API as a mandatory mechanism Equivalent to option 2 except that the implementation of the Consent API would be mandatory. The initial definition of the Consent API payload would, however, be minimalistic until a specific need is identified that would result in fields being added to the payload.

Conclusion

Consent management is one of the core aspects of the open banking ecosystem. Strong customer authentication, fraud detection, and customer user experience are key pillars that consent management is built upon. Even though the implementation aspects can be different in each specification, the core aspects remain the same. As described in this article, understanding and managing these aspects while managing the above key pillars is key to developing a comprehensive consent management module for any solution.

References

1. https://consumerdatastandardsaustralia.github.io/standards/#consent
2. https://github.com/ConsumerDataStandardsAustralia/standards
3. https://static.treasury.gov.au/uploads/sites/1/2018/02/180208-CDR-Fact-Sheet-1.pdf