Account Information Services

AIS Access for PSUs from Corporate Entities

This version is:

Published 5 years ago 23 Sep 2019
User Journey   PSUs, with delegated user authority on behalf of corporates who are authorised…

Other pages in this section

User Journey

 

PSUs, with delegated user authority on behalf of corporates who are authorised to receive corporate account information via AISPs, will be able to provide consent to the AISPs using the standard AIS journey shown in section Account Information Consent.

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 appropriate message to inform the corporate PSU that request to access via AISP is received but is subject to further authorisation. Please note that it is in the domain of the ASPSPs to determine how to do this in alignment with their own corporate journeys.

 

Wireframes

To demonstrate an app based redirection part of the journey we have used one variation of PIS journey (section Single Domestic Payments – a/c selection @ PISP) as an example, where the ASPSP receives all the details of the payment order from the PISP.

This redirection flow applies to other variations of PIS journeys covered in detail under section Payment Initiation Services (PIS).

 

This content is best viewed on a desktop browser.

1

CX Considerations 1
AISP should ask 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.

2

CEG Checklist Requirements 2
The AISP must provide the PSU sufficient information to enable the PSU 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). If the customer-facing entity is acting on behalf of an AISP as its agent the PSU must be made aware that the agent is acting on behalf of the AISP.

3

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 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 type 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 2.2.5 for relevant messaging.

4

CEG Checklist Requirements 4
The AISP should confirm to the PSU: the successful completion of the account information request The request for access has been received by their ASPSP but is subject to further internal authorisation.

 

Requirements and Considerations

CEG Checklist Requirements & CX Considerations

1

AISP should ask 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.

2

The AISP must provide the PSU sufficient information to enable the PSU 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).

If the customer-facing entity  is acting on behalf of an AISP as its agent the PSU must be made aware that the agent is acting on behalf of the AISP.

8 12

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 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 type 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

4

The AISP should confirm to the PSU:

  • the successful completion of the account information request
  • The request for access has been received by their ASPSP but is subject to further internal authorisation.

13a

What the research says

 

Click for customer research