This space is deprecated and no longer supported. Please use the latest available version here.
TPP Consent Management Interfaces
1. Overview
TPPs MUST provide Users with Consent Management Interfaces (CMIs) to view and revoke ongoing Consents that they have given to the TPPs. This section describes:
How to make these Consent Management Interfaces (CMIs) effective tools for Users
How the revocation journey should be constructed
Consent Management Interfaces (CMIs) play an important role in clearly and transparently setting out what Consents a User has provided for a TPP. Therefore, Consent Management Interfaces (CMIs) play a role in multiple user journeys, including:
Checking that the Consent is live (i.e. valid)
Reminding a User where they are providing Data Sharing or Service Initiation access from and for how long
Informing a User how long the access will continue for
Clarifying what level of access the TPP has
Revoking access
Pausing access
Reactivating Paused access
The TPP Consent Management Interface (CMI) SHOULD therefore be easy to find and easy to understand, which plays a key role in building trust with Open Finance-enabled services.
2. TPP Consent Management Interfaces (CMIs) examples
2.1 Wireframes
The following are example wireframes of TTP Consent Management Interfaces (CMIs), illustrating information that must be provided to Users for Data Sharing and Service Initiation Consents.
2.1.1 Data Sharing Consent Management Interface (CMI)
2.1.2 Service Initiation Consent Management Interfaces (CMI)
2.2 Rules & Guidelines
ID | Rules & Guidelines |
---|---|
1 | The User-facing TPPs that offer both Data Sharing and Service Initiation MUST keep these Consent types separated to ensure clarity and prevent any misunderstandings by Users. |
2 | To aid clarity whilst providing detailed information when Users need it, Consent Management Interfaces (CMIs) MUST provide an Overview page that lists high-level information for all Consents, and a Detailed page for each Consent. |
3 | The User-facing TPPs MUST provide Users with sufficient information to enable them to make informed decisions on the Consent Management Interfaces (CMIs) Overview page. As a minimum, TPPs MUST show the following details: Consent Summary:
|
4 | The User-facing TPPs MUST provide Users with sufficient information to enable them to make informed decisions on the Data Sharing or Service Initiation Consent given. These details MUST include all the values which are defined within the specific Data Sharing or Service Initiation Consent, when it was requested. These details are covered within the Rules & Guidelines for each of the areas of functionality covered by the Standard. |
5 | The User-facing TPPs MUST offer functionality (such as search, sort, filter etc.) to enable Users to search for the relevant Consent. This will be of particular benefit as the number of Consents for different LFI accounts given by Users to TPPs increases. |
6 | The User-facing TPPs MUST provide the following minimum set of filters in the Consent Management Interface (CMI) Overview page:
|
7 | The User-facing TPPs SHOULD allow Users to edit their LFI account names by replacing the account name with a nickname such as "Household Account" or "Holiday Savings Pot." |
8 | The User-facing TPPs SHOULD provide extra explanatory text to help Users understand complicated topics like how to cancel their Consent. Using information bubbles helps to keep information manageable. |
9 | TPPs offering Service Initiation MUST provide the Service Initiation transaction details within the transaction log depending on the type of Service initiated. For details see the Rules & Guidelines for each of the areas of functionality covered by the Standard. |
10 | The Consent ID that is presented at the User-Interface (UI) MUST be user-friendly. TPPs MUST present the first and last four digits of the consent ID: 1234…….6789. |
11 | TPPs MUST offer a copy option that allows Users to copy the complete consent ID easily. |
12 | The User-facing TPPs MUST provide Users with a Transactions Log for every Service Initiation Consent. The Transactions Log SHOULD be easily accessible to Users by placing it on the Consent Management Interface’s Detailed page. |
13 | The User-facing TPPs MUST also provide a cancel (disconnect) button that allows Users to revoke their Consent. This is not applicable for irrevocable single-use Consents for Service Initiations such as Single Immediate Payments. |
14 | The User-facing TPPs MUST provide records of all past connections, including any previously granted Consents which had previously been:
|
15 | TPPs MUST use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory. |
3. Consent Revocation Journey
One of the most important functionality of the Consent Management Interfaces (CMIs) is to cancel a Long-lived Consent. The below journey illustrates the main steps involved:
Additionally, it is essential that TPPs make clear to Users of what will happen to the already-obtained data in their possession once the Consent is cancelled by the Users.
3.1 Wireframes
Below are example wireframes of the Consent Revocation journeys for Data Sharing and Service Initiation.
3.1.1 Data Sharing Consent Revocation Journey
3.1.2 Service Initiation Consent Revocation Journey
3.1.3 Rules and Guidelines
ID | Rules & Guidelines |
---|---|
1 | The Consent Management Interface (CMI) Detailed page MUST allow Users to cancel the Consent they have provided easily and without obstruction or excessive barriers. |
2 | Once Users have clicked “Cancel” in the Consent Management Interface (CMI) Detailed page, TPPs MUST only provide one page before cancelling/revoking the Consent, which clearly sets out the implications of cancelling to ensure that Users want to proceed with the cancellation. The Consent Cancellation Confirmation page MUST be provided after this to confirm that the connection is no longer active. |
3 | The User-facing TPPs MUST make the exact consequences of cancelling the Consent clear to Users in the Consent Cancellation Confirmation page (i.e., they will no longer be able to provide the specific service to Users). |
4 | For Data Sharing Consent, the Consent Cancellation Confirmation page MUST confirm what happens to any existing data that TPPs have already retrieved. TPPs MUST ensure that they are fair and transparent about how existing data is processed and that no longer required data is deleted, where appropriate, in accordance to any relevant laws and regulations. For Data Sharing Consent, TPPs MUST present the data at a Data Cluster level and allow Users to expand the level of detail to show each Data Permission. For Service Initiation Consents, TPPs MUST present the conditions and controls related to the Consent and allow Users to expand the level of details to show each Service Initiation Consent details. |
5 | The User-facing TPPs MUST inform LFIs that Users have withdrawn their Consents, and the Consent state “Canceled” MUST be reflected to the User in the Consent Management Interface (CMI) Overview page. |
6 | In the Consent Cancellation Notification page (i.e. the last page) the User-facing TPPs MUST inform Users that the connection to their account has been cancelled and no further Data Sharing will be provided or no further Service Initiations are to be performed by the LFIs as the LFIs have withdrawn the Consent given to the TPPs. After TPPs set the state of the Consent to ‘Canceled’, the LFIs are advised to inform Users via their own channels (for example via SMS or a notification on their mobile phone) that TPPs will no longer have Data Sharing or Service Initiation access to their account. |
4 Consent Pause Journey
This capability allows the User to put a temporary pause on the Long-Lived Consent from the TPP and reactivate it again at a later period. The below journey illustrates the main steps involved:
Additionally, it is essential that TPPs make clear to Users any consequences of pausing the Long-Lived consent given their inability to offer functionality dependent on the Long-Lived consent.
4.1 Wireframes
The below are example wireframes of the Consent Pause journeys for Data Sharing and Service Initiation.
4.1.1 Data Sharing Consent Pause Journey
4.1.2 Service Initiation Consent Pause Journey
3.1.3 Rules and Guidelines
ID | Rules & Guidelines |
---|---|
1 | The Consent Management Interface (CMI) Detailed page MUST allow Users to Pause the Consent they have provided easily and without obstruction or excessive barriers. |
2 | Once Users have clicked “Pause” in the Consent Management Interface (CMI) Detailed page, TPPs MUST only provide one page before pausing the Consent, which clearly sets out the implications of pausing to ensure that Users want to proceed. The Consent Pause Confirmation page MUST be provided after this to confirm that the connection is temporarily inactive. |
3 | The User-facing TPPs MUST make the exact consequences of pausing the Consent clear to Users in the Consent Pause Confirmation page (i.e., they will not be able to provide the specific service to Users while the Pause is active). |
4 | For Data Sharing Consents, TPPs MUST present the data at a Data Cluster level and allow Users to expand the level of detail to show each Data Permission. For Service Initiation Consents, TPPs MUST present the conditions and controls related to the Consent and allow Users to expand the level of details to show each Service Initiation Consent details. |
5 | The User-facing TPPs MUST inform LFIs that Users have Paused their Consents, and the Consent state “Suspended” MUST be reflected to the User in the Consent Management Interface (CMI) Overview page. |
6 | In the Consent Pause Notification page (i.e. the last page) the User-facing TPPs MUST inform Users that the connection to their account has been paused and no further Data Sharing will be provided or no further Service Initiations are to be performed by the LFIs till the pause is active. After TPPs set the state of the Consent to ‘Paused’, the LFIs are advised to inform Users via their own channels (for example via SMS or a notification on their mobile phone) that TPPs will no longer have Data Sharing or Service Initiation access to their account until the pause is active. |
5 Reactivating a Paused Consent Journey
This capability allows the User to reactivate a previously paused Long-Lived Consent from the TPP’s Consent Management Interface (CMI). The below journey illustrates the main steps involved:
5.1 Wireframes
The below are example wireframes of the Consent Reactivation journeys for Data Sharing and Service Initiation.
5.1.1 Data Sharing Consent Reactivation Journey
5.1.2 Service Initiation Consent Reactivation Journey
5.1.3 Rules and Guidelines
ID | Rules & Guidelines |
---|---|
1 | The Consent Management Interface (CMI) Detailed page MUST allow Users, easily and without obstruction or excessive barriers, to reactivate the Consent they had previously Paused. |
2 | For Data Sharing Consents, TPPs MUST present the data at a Data Cluster level and allow Users to expand the level of detail to show each Data Permission. For Service Initiation Consents, TPPs MUST present the conditions and controls related to the Consent and allow Users to expand the level of details to show each Service Initiation Consent details. |
3 | Once Users have clicked “Activate” in the Consent Management Interface (CMI) Detailed page, the TPPs MUST inform LFIs that Users have requested to Reactivate the Paused Consent. This MUST not require authentication of the User with the LFI or the Centralized Authentication and Authorization App. |
4 | The Consent state “Active” MUST be reflected to the User on the Consent Management Interface (CMI) Overview page. |
5 | The LFIs are advised to inform Users via their own channels (for example via SMS or a notification on their mobile phone) that their Long-Lived consent with the TPPs has been reactivated. |
4. Consent Management Interfaces (CMIs) when customer-facing service provider and TPP are different entities
If there are customer-facing service providers (e.g. Merchants) who are not TPPs but have commercial relationships with TPPs, the TPPs MUST ensure that the Consent reflects this information correctly so that it can be displayed accurately to Users on the LFI Consent Management Interfaces (CMIs).
These entities are referred to as customer-facing service providers, as they are providing the end service to the end-Users, whereas TPPs in these cases are only undertaking the Data Sharing or Service Initiation activities. This could occur in merchant journeys for example, where a merchant contracts with a TPP to provide Variable Recurring Payments as a payment option on their platform.
4.1 Examples
TPP Trading Name | Registered Legal Entity Name (Company Name/Organization Name) | Customer-facing entity name (‘via’ field in the APIs) | What to display on Dashboards |
---|---|---|---|
ABC Trades | ABC Company Ltd |
| ABC Trades |
ABC Company Ltd | ABC Company Ltd |
| ABC Company Ltd |
ABC Company Ltd | ABC Company Ltd | OBO Ltd | OBO Ltd via ABC Company Ltd |
[TPP Trading Name] | [TPP Company name] | [Merchant Trading name] | [Merchant Trading name] via [TPP Trading Name] |
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.