Account Information Consent

User Journey

In this journey the AISP presents to the PSU a description of the data that it requires in order to support its service proposition.
PSU selects the ASPSP(s) where their payment account(s) is held. The PSU is then directed to the domain of its ASPSP for authentication and to select the account(s) they want to give access to. Once the PSU has been authenticated, their ASPSP will be able to respond to the AISP’s request by providing the account information that has been requested.

When considering AISP requests submitted by a PSU acting with delegated user authority on behalf of a corporate entity, the PSU may only be able to use AISP services, if this is permitted within the parameters of that delegated user authority. If the PSU does not have the appropriate delegated user authority, please refer to journey  AIS Access for PSUs from Corporate Entities.

Note: This refers to individuals in the Corporate / BCP space that have the authority to share data or any other entity that has credentials with the ASPSP and have the authority to access the corporate accounts under their profile permissions.

Wireframes

CEG Checklist Requirements 1

AISPs must ask the PSU to identify their ASPSP before requesting consent so that the consent request can be constructed in line with the ASPSP's data capabilities (which the ASPSP must make available to all TPPs). ASPSP Implementation guides, which are located on the Open Banking Developer Zone will have information about the ASPSP's data capabilities.

CEG Checklist Requirements 2

AISPs must provide PSUs with sufficient information to enable PSUs 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 on-going or one-off).

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.

CEG Checklist Requirements 3

The AISP must provide the PSU with a description of the data being requested using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure that this request is specific to only the information required for the provision of their account information service to the PSU.
The AISP must present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission. The AISP should only present those data clusters relevant for the product type in question. Where the request is for multiple product types then the detail shown in the data cluster should explain to the customer the product types to which it applies or state that it is shared across multiple product types.
Once PSU has consented, the PSU will be directed to their ASPSP. Please refer section Effective use of redirection screens for relevant messaging.

CX Considerations 4

AISP should make the PSU aware on the inbound redirection screen that they will be taken to their ASPSP for authentication for account access.

CX Considerations 5

ASPSPs must display the TPPs' trading name/brand name (i.e. the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different.

If there is an Agent acting on behalf of the TPP, ASPSPs must also display the Agent company name (as captured in the 'On behalf of' field of the software statement) to the PSU. (Please note that ASPSPs can only show the Agency/On Behalf field only in cases where this information has been provided by AISPs).

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

CEG Checklist Requirements 6

If the ASPSP provides an option for the PSU to view the data they have consented to share with the AISP as supplementary information, this must be done using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below). Display of such information must not be provided to the PSU as a default.

CEG Checklist Requirements 7

ASPSPs must not seek confirmation of the consent that has already been provided by the PSU to the AISP.
Once the PSU has selected the account(s), refer to section Effective use of redirection screens for redirection messaging.

CX Considerations 8

ASPSP should have an outbound redirection screen which indicates the status of the request and informs the PSU that they will be automatically taken back to the AISP.

CEG Checklist Requirements 9

The AISP should confirm the successful completion of the account information request to the PSU.

CEG Checklist Requirements & CX Considerations

AISPs must ask the PSU to identify their ASPSP before requesting consent so that the consent request can be constructed in line with the ASPSP’s data capabilities (which the ASPSP must make available to all TPPs). ASPSP Implementation guides, which are located on the Open Banking Developer Zone will have information about the ASPSP’s data capabilities.

8

 

AISPs must provide PSUs with sufficient information to enable PSUs 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 on-going or one-off).

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.

12

The AISP must provide the PSU with a description of the data being requested using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure that this request is specific to only the information required for the provision of their account information service to the PSU.

The AISP must present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission. The AISP should only present those data clusters relevant for the product type in question. Where the request is for multiple product types then the detail shown in the data cluster should explain to the customer the product types to which it applies or state that it is shared across multiple product types.

Once PSU has consented, the PSU will be directed to their ASPSP. Please refer section Effective use of redirection screens for relevant messaging.

13b
AISP should make the PSU aware on the inbound redirection screen that they will be taken to their ASPSP for authentication for account access.

ASPSPs must display the TPPs’ trading name/brand name (i.e. the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different.

If there is an Agent acting on behalf of the TPP, ASPSPs must also display the Agent company name (as captured in the ‘On behalf of’ field of the software statement) to the PSU. (Please note that ASPSPs can only show the Agency/On Behalf field only in cases where this information has been provided by AISPs).

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

If the ASPSP provides an option for the PSU to view the data they have consented to share with the AISP as supplementary information, this must be done using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below). Display of such information must not be provided to the PSU as a default.
13a

ASPSPs must not seek confirmation of the consent that has already been provided by the PSU to the AISP.

Once the PSU has selected the account(s), refer to section Effective use of redirection screens for redirection messaging.

2
ASPSP should have an outbound redirection screen which indicates the status of the request and informs the PSU that they will be automatically taken back to the AISP.
The AISP should confirm the successful completion of the account information request to the PSU.
18

NOTE:

Note: “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services.

When an agent acts on behalf of the AISP, the PSU must in the case of requirement #2 and should in the case of requirement #5 be made aware of this within the consent journey.

Please see details in requirements #2 and #5.

For more examples on how to display, refer to Consent Dashboard & Revocation

    What the research says:

    Click for Customer Research