Open Banking Consent

Open banking is changing the way financial companies do business in the modern world. By allowing seamless and more open data exchange between parties, open banking can help improve service delivery and quality. However, in order to provide open banking services, businesses have to get consent from the clients, and the service can then, be initiated and delivered.

Open Banking Consent Management

Open banking consent management is a very delicate matter that requires diligence, tech & legal know-how as well as stable technological architecture. So, managing consent isn’t just as simple as enabling the client to press a simple ‘Agree’ button or to tick a box. It has to be done in accordance with the GDPR and PSD regulations. Both the bank and the TPP need to know that the client has authorized access.

Usually, the open banking consent model works like this

  1. The TPP asks the client for consent
  2. The client agrees and authenticates the agreement (digital authentication methods)
  3. Confirmation is seen by both ends and the data from the AISP is transmitted to the TPP or from the PISP to the bank.

However, this is just the most common example. There can be many more different variants of open banking consent that can work in different ways. For example, instead of requesting confirmation and authentication for every transaction, the open banking system could ask for renewing the confirmation every 12 months. During those 12 months after confirmation, there can be no need for further authentication of the client.

Open Banking Consent Flow

The open banking consent flow is heavily linked to the consent model and shows how data and information travels during the process of requesting consent.

First and foremost, open banking consent flow starts from the setup. This process should clearly indicate that by agreeing, a client will transfer some of their data to third parties and will allow them to initiate payments or collect certain data on the behalf of service providers. Every region has different regulations in terms of how authentication is done, but it’s usually a two-step verification process or a universally approved identification method like mobile identification service, logging in to a bank account, digital signature, etc.

During the consent flow, a few parties are involved. The client, the resource owner, the authorization server, and the resource server. They all communicate with one another in order to initiate, manage and end the flow of consent.

To give more detail, we will explain the step-by-step of open banking consent management in-depth, giving even more information on how a model OAuth 2.0 Flow (used by UK open banking systems) works. It’s an 11-step process, so pay close attention to not miss anything!

  1. Resource owner and client communicate via access service
  2. The client redirects with the resource owner
  3. The resource owner sends to the authorization server a request with a scope for a dedicated code
  4. The server requests consent from the client
  5. The client confirms the request to the authorization server
  6. The authorization server redirects with the resource owner
  7. The resource owner issues an authorization code to the client
  8. The client exchanges the authorization code to the authorization server
  9. The server then, gives back an access token
  10. Client’s access token is presented to the resource server
  11. The resource server returns data to the client
Get started now!

No trial period. No credit card. Free forever.

Join our Newsletter

We frequently share industry news and Nordigen product updates to our closest friends, fintech innovators and industry experts. Sign up to our newsletter to hear more from us.

By providing your email, you accept
Nordigen's Privacy Policy.