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.

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.

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:

• Consent State (“Awaiting", "Authorized", "Rejected", "Canceled" or "Consumed")

• Account Provider Name (Trading Name/nickname if used)

• Account type and the last 4 digits of account number (if provided)

• The expiry date for when the Consent will end (Note: A countdown is an optional element. If provided, it SHOULD be used in addition to an expiry date and not instead of it)

• The date and time of the last occasion when Data Sharing or Service Initiation occurred from the connected account

• Warnings or alerts if the Consent is close to expiry. TPPs can define how close to the expiry date they SHOULD start to alert Users depending on their business models.

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.

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.

The User-facing TPPs MUST provide the following minimum set of filters in the Consent Management Interface (CMI) Overview page:

• Users' LFI Name

• Connected Account Number

• Consent Type

• Consent State

• Consent Date

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."

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.

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.

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.

TPPs MUST offer a copy option that allows Users to copy the complete consent ID easily.

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.

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.

The User-facing TPPs MUST provide records of all past connections, including any previously granted Consents which had previously been:

• Canceled at the LFIs or TPPs

• Expired

• Authorization Time Window Elapsed

• Rejected

• Consumed

TPPs MUST use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory.

The Consent Management Interface (CMI) Detailed page MUST allow Users to cancel the Consent they have provided easily and without obstruction or excessive barriers.

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.

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).

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.

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.

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.

The Consent Management Interface (CMI) Detailed page MUST allow Users to Pause the Consent they have provided easily and without obstruction or excessive barriers.

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.

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).

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.

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.

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.

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.

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.

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.

The Consent state “Active” MUST be reflected to the User on the Consent Management Interface (CMI) Overview page.

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.

The Consent Management Interface (CMI) Detailed page SHOULD allow Users to initiate a Consent update easily and without obstruction or excessive barriers.
It is in the TPPs discretion whether they will provide Users the capability to update their Consent details or not, based on the TPPs' supported use cases.

Once Users have clicked “Update” in the Consent Management Interface (CMI) Detailed page, TPPs SHOULD provide one page with all the Consent details, clearly highlighting which parameters of the Consent Users are allowed to change.

It is at the TPPs' discretion which parameters to allow Users to update and also whether to allow Users to propose (or set) new values for these updated parameters or alternatively provide Users with a range of allowable or proposed values.

3.1 For Data Sharing Consents, TPPs SHOULD enable Users to amend one or more of the parameters of the long-lived Consent, as defined in Customer Data | 5. Consent Updates

3.2 For Service Initiation Consents, TPPs SHOULD enable Users to amend one or more of the parameters of the long-lived Consent, as follows:

• For Multi-Payment Consents, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft3/pages/321227125/Multi-Payments#7.-Consent-Updates

• For International Payment Consents, as defined in International Payments | 3.2.6 Consent Updates

• For Delegated Authentication Consents, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft3/pages/321228758/Payments+with+Delegated+Authentication#7.-Consent-Updates-with-LFI

4.1 TPPs MUST enable Users to provide explicit consent for the forwarding of the new Consent update to the LFIs as per the parameters specified in the consent. TPPs will request Users to authenticate with their LFIs and authorize the Consent update.

4.2 TPPs MUST set the status of the original consent to ‘Revoked’ before forwarding the new Consent update to the LFIs.

Remaining steps for Authentication, Authorization, and Confirmation are as per the existing steps for the equivalent long-lived Consents for Data Sharing (Customer Data | 3.1 Rules & Guidelines , Multi-Payments (Multi-Payments | 3.2 Rules & Guidelines, International Payments (International Payments | 3.2.3 Consent Setup) and Delegated Authentication Payments (https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft3/pages/321228758/Payments+with+Delegated+Authentication#3.1.-Consent-Setup) as defined in the CBUAE Open Finance Standard.

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]