Skip to main content
Version: v3

Overview of Consents in PSD2 Open Banking

Consent in the context of PSD2 (Payment Services Directive 2) refers to the permission a user grants to third-party providers (TPPs) to access their bank account information. This is a crucial aspect of open banking, where customers control who can access their banking data and for what purpose.

In our implementation, consent is gathered through two key mechanisms: ConsentWizard and ConsentUrl. Each method provides a structured approach to acquiring user consent, ensuring compliance with PSD2 requirements for security and transparency.

General Information About Consents​

  • Where does a consent flow start and how?
  • When is the consent flow completed?
  • Where is a Consent recorded?
  • What information is recorded?
  • What can you do with a consent?
  • How does a consent proceed, and can it be revoked?

Once a user gives consent, the third-party provider (TPP) can access the user's bank account information (e.g., balances, transactions). The consent specifies:

  • The accounts the user allows access to.
  • The duration or validity period of the consent (typically specified by the bank and currently set to 180 days).
  • User Interaction: The user must actively give permission through a secure channel, typically via a web interface or app.
  • Bank Selection: Users can select specific banks for which they wish to grant access.
  • Account Details (IBANs): Depending on the method used, the user may need to select or specify which accounts (IBANs) consent applies to.

  • ConsentCollectionID: The ConsentCollectionID is a unique identifier provided before the user grants consent. It is generated during the initiation of the consent flow (e.g., via the /api/v1/Consents/generateConsentWizardUrl endpoint). This ID allows the TPP to retrieve account information or transaction data to serve as input for our data services.

  • Account Information (via API): Once consent is given, the AccountInfo endpoint can be called to retrieve detailed information about the bank accounts associated with the given ConsentCollectionId. This includes details about the consent status, validity, and account specifics, rather than direct transaction histories or balances.

  • Redirection: After completing the consent process, the user is typically redirected to a specified ReturnUrl.

1. ConsentWizard​

The ConsentWizard is an interactive web portal that allows users to grant consent for access to their bank accounts. It supports the selection of specific banks and accounts. This method is initiated through a generated URL, which is valid for the duration of the session (capped at 10 minutes).

How it Works:​

  • A new session is initiated from the Partner’s system using the /api/v1/Consents/generateConsentWizardUrl endpoint.

  • The user is presented with an interface where they can select multiple banks and accounts (via IBANs) for which they want to provide consent.

  • Upon completing the process, the user is redirected to a specified ReturnUrl, where they can continue or confirm the flow. The granted consents are then accessible to the Partner via the AccountInfo endpoint.

Input (provided when initiating the call to ConsentWizard)​

  • consentCollectionId: A unique identifier for the consent collection (GUID format), ensuring traceability for the specific set of consents being managed.

  • returnUrl: The URL to which the user is redirected after completing the consent process (e.g., https://mywebsite.org/callback).

  • customerSubType: An optional field specifying a customer segment or subtype. This parameter can help tailor the consent flow to specific customer groups or account types, reducing ambiguity during the consent process.

  • collectionType: Indicates the type of consent collection (default is 1). This field specifies the purpose or category of consent being collected, allowing for a more organized handling of various consent types. Leave empty for default.

  • ExpectedIbans: A JSON-formatted list of valid IBANs. When provided, these IBANs automatically appear in the ConsentWizard to show the user which accounts require consent.

Output:​

  • Generated Consent Wizard URL: A unique URL for the user session is generated, valid for up to 10 minutes. This URL directs the user to the ConsentWizard interface, where they can review and provide consent for the selected accounts.

  • Redirection to ReturnUrl: Once consent is given, the user is redirected to the specified ReturnUrl, allowing the process to continue with the agreed-upon consents.

  • Access to Account Information and Data Services: Once consent is granted, the resulting consents can be used to retrieve account information via the AccountInfo endpoint. Additionally, the granted consents may be applied to other data services, such as Convert.

2. ConsentUrl​

The ConsentUrl endpoint generates a direct bank URL where the user can give consent. This method is less interactive than the ConsentWizard but allows the user to go directly to their bank's portal to approve access to their accounts.

How it Works:​

  • A new consent session is initiated using the /api/v1/Consents/generateUrl endpoint.
  • The user is redirected to the bank’s consent portal where they can provide access to their accounts by confirming the consent.
  • Once the process is complete, the user is redirected back to the provided ReturnUrl. (This process can be repeated as needed.)

Input: (provided when initiating the call to ConsentUrl)​

  • consentCollectionId: A unique identifier for the consent collection (GUID format), which ensures traceability.
  • returnUrl: The URL to which the user is redirected after the bank consent process is completed.
  • bankId: The unique identifier for the bank with which the user will give consent (GUID format).
  • collectionType: Indicates the type of consent collection (default is 1).
  • Ibans: A list of valid IBANs in JSON format, required for some banks. This ensures the specific accounts for which consent is required are presented at the bank portal.

Output:​

  • Generated Bank Consent URL: A URL is generated that directs the user to their bank’s portal to give consent.
  • Redirection to ReturnUrl: Upon completing the consent process at the bank’s portal, the user is redirected to the specified ReturnUrl.
  • Access to Account Info: Once consent is given, account information can be retrieved using the AccountInfo endpoint, provided the consent token is valid.

Input and Output Summary​

Input:​

The inputs for initiating consent include key parameters such as:

  • consentCollectionId: A unique identifier for the consent collection in GUID format, ensuring traceability for the specific set of consents being managed.

  • returnUrl: The URL to which the user is redirected after the consent process is completed (e.g., https://mywebsite.org/callback).

Depending on the method, other optional parameters such as:

  • IBANs: A list of valid IBANs in JSON format, ensuring that specific accounts for which consent is required are presented at the bank portal.

  • customerSubType: This optional field specifies a customer segment or subtype. Providing this can help tailor the consent experience to the user’s profile.

  • collectionType: This indicates the type of consent collection (default is 1). Clarification on its use can help prevent confusion among users.

Output:​

  • Account Data Retrieval: The AccountInfo endpoint can be used to retrieve various types of account data, including:

    • Account Details: Information such as account holder name, account type, and bank details.
    • Account Status: Current status of the consented accounts, indicating whether the consent is valid, expired, or withdrawn.
    • Transaction History Availability: Information on whether historical transactions can be downloaded for the consented accounts.
    • Last Download Date: The last date when account information was retrieved.

  • Access to Other Data Services: The granted consent can also enable access to additional data services.

Key Use Cases​

  • Account Information Retrieval: After consent is granted, third-party providers can retrieve account balances, transaction details, and other financial data as authorized by the user.