This space is deprecated and no longer supported. Please use the latest available version here.
Consent Setup
- Chris Michael
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.
| Agreement Parameter | Description |
|---|---|---|
1 | Purpose Statement | Why we need you to share your data with us |
2 | Direct Benefit Statement | What you will get from us in return |
3 | Data Request Statement | What we need you to share with us |
4 | Duration Period Statement | How long we will need access to your data (unless you revoke access) |
5 | Agreement | Do you agree to share your data with us on the terms above? |
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.
| Agreement Parameter | Description |
|---|---|---|
1 | Purpose Statement | Why we need to perform a Service Initiation for you |
2 | Direct Benefit Statement | What will you get from us in return |
3 | Service Initiation Request Statement | What Service Initiation specifically we are going to perform with your agreement |
4 | Duration Period Statement | How long we will need access to your account for Service Initiation (unless you revoke access) |
5 | Agreement | Do you agree to give us access to your account for performing Service Initiation on the terms above? |
3. Consent Types
There are 2 different types of consent that Users will be requested to agree to:
A. Single-Use Consent
A one-off consent that a User provides to a TPP which MUST be used for a single Data Sharing or Service Initiation, which will take place immediately after User Authorization at the LFI.
This consent supports the following functionality:
Customer Data (one-off requests)
B. Long-Lived Consent
Consent that a User provides to a TPP for an ongoing Data Sharing access or for (one or more) Service Initiations in the future.
This consent supports the following functionality:
Customer Data (ongoing requests)
4. Consent States
A Consent moves between these states in its lifecycle:
AwaitingAuthorization: This is the initial state for all consents. The TPP initiates a Rich Authorization Request (RAR) with the OFP - this creates the Consent object. 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 as per the authorization matrix of the LFI. The Consent will remain in AwaitingAuthorization until all required authorizations are completed. Requests from TPPs for Data Sharing or Service Initiation MUST be rejected where the Consent is in the AwaitingAuthorization state.
Authorized: In this state, the Consent has been fully authorized and it is now ready to use. The TPP can initiate requests to the OFP referencing this Consent. The Consent will remain in this state until:
a) it has been fully used (Consumed); or
b) it reached the end of its lifecycle and its validity has expired (Expired); or
c) it was been revoked by the User (Revoked); or
d) it has been suspended by the LFI (Suspended)
Rejected: A Consent MUST move from the AwaitingAuthorization to the Rejected state when either the User rejects the Consent, or the LFI rejects the processing of the Consent. Rejected is a terminal state.
Suspended: A Consent MUST move from an Authorized state to a Suspended state when the LFI suspends the Consent - e.g., in case that fraudulent activities are suspected in relation to the User. If the LFI clears the suspension, the Consent MUST move from Suspended back to Authorized. Suspended is not a terminal state.
Consumed: A Consent MUST move from Authorized to Consumed when the action associated with the granted Consent has been fully used. Consumed is a terminal state.
Expired: A Consent MUST move from an In Use state (Authorized or Suspended) to Expired when the Consent has expired its time duration. Expired is a terminal state.
Revoked: A Consent MUST move from an In Use state (Authorized or Suspended) to Revoked when the User has revoked the Consent. Revoked is a terminal state.
5. General Consent Rules
TPPs MUST:
5.1 Provide to Users, OFP and LFIs their trading/brand name clearly and the name of the User-facing entity, if the TPP is not the User facing entity. It is the responsibility of TPPs to ensure that User-facing entities are identified and included in the Consent and the Consent Management Interface (CMI) information available to Users.
5.2 Ensure that Users clearly understand the different elements of the Consent requested to provide.
5.3 Check the Consent state at the OFP and keep in sync their systems and Consent Management Interfaces (CMIs).
5.4 Notify the OFP when the User has Revoked a Consent via the TPP.
OFP MUST:
5.5 Maintain the golden record of the Consent object and the state of the Consent.
5.6 Check the current date against the Consent Expiration Date. In case of expiration, OFP MUST set the Consent state to the Expired terminal state.
5.7 Check the time elapsed from the Consent creation time against the Consent Authorization Time Window as defined in Common Rules and Guidelines | 8. Authorization Time Window . In case of expiration, if the Consent is still in AwaitingAuthorization state, OFP MUST set the Consent state to the Rejected terminal state.
5.8 Check the time elapsed from the Consent creation time against the Limits and Constants | Max Submitter Authorization Time Window . In case of expiration, if the Consent is still in AwaitingAuthorization state, OFP MUST set the Consent state to the Rejected terminal state, setting the appropriate error code for the TPP.
5.9 In the case the Consent has been fully used, the OFP MUST set the Consent state to Consumed.
5.10 Allow TPPs to check the status of the Consent and the Consent object.
5.11 Allow LFIs to check the status of the Consent and the Consent object.
5.12 Reject any Data Sharing or Service Initiation requests in relation to a Consent that is not in the Authorized state.
5.13 NOT allow updates to a Consent state once the Consent has reached a terminal state.
LFIs MUST:
5.14 NOT allow Users via the Consent Management Interface (CMIs) to change any of the Consent parameters of a Consent in any state.
5.15 Notify the OFP when the User has Revoked a Consent via the LFI
5.16 Notify the OFP when the Consent has been Suspended or moved out of Suspended
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.