Consent Flows

There are 3 main types of consent flows:

1. Redirect

In the Redirect Approach the browser session of the account holder is redirected from your software to the bank. In that case the bank provides all the pages required for Strong Customer Authentication (SCA). Once the authorisation is complete, the account holder is being redirected back to your software.

2. Decoupled

In the Decoupled Approach no redirection takes place. Instead, the bank notifies the account holder that they need to authenticate themselves, for example using mobile banking app. The authentication is executed by the app. Since this approach is asynchronous, you need to check consent status to know when the authentication process has been finished.

3. Embedded

In the Embedded Approach you have to provide all the screens required for the authentication process and fulfil all necessary steps over the API of the Open Banking Service.

Depending on the consent flow you will need to implement a different sequence of API calls. Please check below sequence diagrams to understand each flow.

You can indicate your preferred SCA method by using PreferredScaMethod (Embedded, Decoupled, Redirect) parameter of POST consent endpoint, but there is no guarantee that the bank will actually use it to authenticate the PSU. 

For faster integration and better user experience we offer the Bank Selection Interface, it will then always become a redirect flow from you to this interface. This interface can be customised with your branding allowing to choose the account holder's bank and handling the complexity of different PSD2 authorization flows, so that you will be able to focus on your product and leave the boring stuff to us. 

The selected flow with which authentication will go through, is being identified by the name of a hyperlink, provided in the response to the POST consent API call.

Redirect Flow

The sequence diagram below is an example of a typical redirect account data flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the account holder (PSU).

Redirect back to the Initiating Party

Once the account holder finished the interaction with the bank, the session will be redirected back to you. Here, the Open Banking Service appends the Initiating Party Return URL with the Service Name and the consent ID so that the session can be recognised. This enables the Initiating Party to display the correct screen to the PSU.

An example of a return URL is as follows: https://www.example.org/?scope=QUlTOjc1NDQzMTY3
The Initiating Party would need to base64 decode this string : QUlTOjc1NDQzMTY3
The example above results in: {ServiceName}:{paymentId}, i.e. AIS:75443167

Decoupled Flow 

Below is a sequence diagram showing a typical decoupled flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the account holder.

Embedded Flow 

Below is a sequence diagram showing a typical embedded flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the account holder.

Flow steering by links

The table below includes every possible step with the corresponding approach. In the response of each request the named link informs about the next request to be sent according to the actual state in the flow.