Consent Dashboard & Revocation

User Journey

AISPs must provide PSUs with a facility to view and revoke on-going consents that they have given to that AISP. They may have consented to share data from several ASPSPs with a single AISP. This section describes how these consents should be displayed and how the customer journey to revoke them should be constructed.

Wireframes

CX Considerations 1

AISP should offer functionality ( e.g. search, sort, filter) to enable a PSU to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a PSU to TPPs increases.

CEG Checklist Requirements 2

AISPs must describe the data being shared through each consent using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure this request is specific to only the information required for the provision of their account information service to the PSU. AISPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission.

CX Considerations 3

The AISP should make the exact consequences of cancelling the consent clear to the PSU - i.e. they will no longer be able to provide the specific service to the PSU

CX Considerations 4

The AISP should make the exact consequences of cancelling the consent clear to the PSU - i.e. they will no longer be able to provide the specific service to the PSU

CEG Checklist Requirements 5

AISPs must inform the ASPSP that the PSU has withdrawn consent by making a call to DELETE the account-access-consent resource as soon as practically possible (as described in Version 3 of the API specifications). This will ensure that no further account information is shared. ASPSPs must support the Delete process as described in the Version 3 API specifications. (This is not visible to the PSU but will ensure no further account information is provided by the ASPSP to the AISP).

CX Considerations 6

ASPSPs should inform the PSU that no further account information will be provided by the ASPSP to the AISP as the PSU has withdrawn its access given to the AISP. After the Delete endpoint is called by the AISP to remove the account-access-consent resource, the ASPSPs are advised to inform the PSU via their own channels (for example via sms or via a notification on their mobile phone) that AISP will no longer have access to their account. This is an additional confirmation to the PSU that the AISP has completed the delete endpoint process correctly.

CEG Checklist Requirements & CX Considerations

AISP should offer functionality ( e.g. search, sort, filter) to enable a PSU to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a PSU to TPPs increases.

AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the PSU.

If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP’s full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. 

AISPs must also, populate the Agent company name in the ‘On behalf of’ field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU (please refer to item #5). Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ‘ On behalf of’ field with the details of their TSP.

The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off).

For examples of what names should be displayed, please refer to Consent Dashboard & Revocation, Examples.

8

AISPs must describe the data being shared through each consent using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure this request is specific to only the information required for the provision of their account information service to the PSU.

AISPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission.

The Consent Dashboard should also describe:

  • A description of the account information service that is being provided (including whether any other parties will have access to the information). 
  • Where the request is for multiple product types, the detail should explain to the customer the product type to which it applies or state that it is shared across multiple product types.
  • The date when consent was first granted. It is recommended to also show the date when the customer last refreshed their access as part of the 90 days re-authentication.
  • The length of time for which this consent is valid (e.g. one-off use, for a set period of time e.g. one year, or with no end date and the date of expiry).
  • The period for which the account information has been requested (e.g. transactions for the last 12 months).

The consent dashboard must allow a PSU to view or cancel the access they have given consent to. The functions “Cancel Permission” and “back” should be displayed with equal prominence to the PSU.

13b

The AISP should make the exact consequences of cancelling the consent clear to the PSU – i.e. they will no longer be able to provide the specific service to the PSU

AISPs must inform the ASPSP that the PSU has withdrawn consent by making a call to DELETE the account-access-consent resource as soon as practically possible (as described in Version 3 of the API specifications). This will ensure that no further account information is shared.

ASPSPs must support the Delete process as described in the Version 3 API specifications. (This is not visible to the PSU but will ensure no further account information is provided by the ASPSP to the AISP).

9

ASPSPs should inform the PSU that no further account information will be provided by the ASPSP to the AISP as the PSU has withdrawn its access given to the AISP.

After the Delete endpoint is called by the AISP to remove the account-access-consent resource, the ASPSPs are advised to inform the PSU via their own channels (for example via SMS or via a notification on their mobile phone) that AISP will no longer have access to their account. This is an additional confirmation to the PSU that the AISP has completed the delete endpoint process correctly.

Examples

Customer-facing entity name /Trading Name (Client Name in Software Statement)Registered Legal Entity Name (Company Name/ Organisation Name)‘On Behalf of’ Name (‘On Behalf of’ field in Software Statement)What to display
ABC TradesABC Company LtdABC Trades
ABC Company LtdABC Company LtdABC Company Ltd
ABC Company LtdABC Company LtdOBO LtdOBO Ltd on behalf of ABC Company Ltd
ABC TradesABC Company LtdOBO LtdOBO Ltd on behalf of ABC Trades

What the research says:

“In addition, consumer research has shown that respondents prefer confirmation of a revocation in writing via email in addition
to text on the website.”

Click for Customer Research