1. Overview

This section covers a critical step of the customer journey where Users grant consent to TPPs to allow them access their accounts for the provision of Data Sharing or Service Initiation. It is essential that Users are clearly informed about the consent they are providing and the service they are receiving.

2. Consent Codification

Consent codification refers to creating a specific structure for Data Sharing or Service Initiation Consents so that they are standardized when presented to Users by TPPs. This enforces consistency in the information required to be presented to Users and ensures an increased level of understanding of the Consent details by Users.

2.1 Data Sharing Consent

When obtaining consent from Users for the provision of a Data Sharing services, TPPs MUST make it very clear why it’s needed, what’s being shared and for how long.

2.2 Service Initiation Consent

When obtaining consent from Users for performing Service Initiations (e.g. payment initiations) TPPs MUST make it very clear why it’s needed, what type of service is being initiated, and for how long.

3. Consent types

There are 2 different types of consent that Users will be requested to agree to:

4. Consent States

Open

During its lifecycle, each Consent moves between a finite number of Consent states. At high-level, these are the following:

• Awaiting Authorization: This is the first possible state for each consent. The TPP requests the LFI to create a Consent object and set it to this initial state. The Consent is in a pending state waiting for the User to authenticate with the LFI and authorize the Consent. If multiple authorizers are required, the Consent MUST be authorized by all authorizers (one or more) as per the standard account authorization matrix of the LFI. The Consent will remain in this state until all required authorizations are completed. Only after authorizing the Consent, requests from TPPs for Data Sharing or Service Initiation can be granted.

• Authorized: In this state, the Consent has been fully authorized and it is now ready to use or it is in use. The TPP can initiate requests to the LFI referencing this Consent. The Consent will remain in this state until:

  • a) it has been fully used (consumed)

  • b) it reached the end of its lifecycle and its validity has expired

  • c) it was been revoked by the User or

  • d) the User updated its parameters.

• Finished: This is a terminal state. The Consent has expired its time duration or all its authorized requests (for example payments) have now been used. Moreover, the Consent may also get to the terminal state if the User requested it to be revoked or decided to update its parameters. A Consent in the terminal state cannot be used for initiating any further requests by the TPP. Further requests from the TPP will require a new Consent to be created. The TPP MUST be able to still make inquiries in relation to the Consent or any of its related requests (for example payments) until the Consent is defined to be closed for any activity.

• Rejected: Consents can move from the Awaiting Authorization to the Rejected state, which is also a terminal state. This is due to either the User deciding not to authorize the Consent or due to erroneous circumstances in the processing and validation of the Consent parameters by the LFI. A Consent in the terminal state of Rejected cannot be used by the TPP for initiating any Data Sharing or Service Initiation requests. Also, Consents in this state cannot be updated. The TPP MUST generate a new Consent as this is a terminal state and the Consents cannot move to another state.

4.1 Consent Suspension

A Consent may be suspended by the LFI in case that fraudulent activities are suspected in relation to the User account associated with the Consent.

5. General Consent Rules