Refreshing AISP access

User Journey

The PSRs require strong customer authentication to be performed each time the PSU accesses its online payment account, either directly or using the services of an AISP. The frequency of authentication can be reduced if an ASPSP applies the exemption relevant to account information access (RTS, Article 10).  However, this will still require the PSU to be authenticated at least every 90 days. This section describes the customer journey when a PSU needs to refresh AISP access, so the AISP can continue to provide the service previously consented to by authenticating again at their ASPSP. All other elements of the consent (data permissions required, purpose for which the data will be used, transaction history period and consent expiration date) remain unchanged.

(It should be noted that the API specification allows the AISP to inform the ASPSP that the request is a refresh rather than a new request).

Wireframes

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
AISPs should alert the PSU when authentication needs to be performed to refresh AISP access.

2

CX Considerations 2
AISPs should make it clear that the PSU is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g. the data permissions required, the purpose for which it will be used etc.) will change.

3

CEG Checklist Requirements 3
IAISPs must present a high level summary of the data that is being requested and make it clear that this data and the purpose for which it will be used are the same as when originally requested. This should be done using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) . AISPs must ensure that this request is specific to only the information required for the provision of their account information service to the PSU. AISPs 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. 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.

4

CEG Checklist Requirements 4
ASPSPs must not replay the data requested (as a default) or seek re-confirmation of consent.

5

CX Considerations 5
As part of the authentication journey, the ASPSP could have a call to action, for example, to an expandable section that the PSU can click on for information purposes only. If the ASPSP provides this option for the PSU as supplementary information, it will enable the PSU to view the data they have chosen to share with the AISP. This should be done using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below). If the customer facing entity is acting as an agent for the AISP and this information is made available to the ASPSP, the ASPSP should make the PSU aware that the agent is acting on behalf of the AISP. This can be presented to the PSU by displaying both the agent’s name and the regulated AISP name as: The information will be shared with , who is acting on behalf of

6

CEG Checklist Requirements 6
AISPs should confirm the successful completion of the account information request to the PSU.

Select to scroll left Select to scroll right

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 #3, and should in the case of requirement #5  be made aware of this within the consent journey.

Please see details in requirements #3 and #5.

90 day access period

With the PSU’s consent, the AISP can access account information covering any period of time going back, provided that the information is available to the PSU in their direct channels and the AISP does not request more account information then they need to support their service proposition. Article 10 requires SCA to be performed by the ASPSP prior to the AISP’s first access and subsequently re-performed at least every 90 days (where the ASPSP is applying the Article 10 exemption) or otherwise where required by the ASPSP.

For example, let’s say the PSU (on 14 September 2019) consents to AISP1 accessing the last three years’ of account information (i.e. from 15 September 2016 – 14 September 2019) from ASPSP2 with the consent validity lasting until 14 September 2020. If ASPSP2 is applying the Article 10 exemption, AISP1 can then continue to access either or both of the account balance and/or the last 90 days’ of executed payment transactions without SCA having to be performed again until 13 December 2019, when the 90  day period expires, unless otherwise where required by the ASPSP.

Practically, within the 90 day period after the PSU has been authenticated with SCA, when an ASPSP2 applies the Article 10 exemption, the AISP1 may request periodic account information, using the 90 day access token within the parameters of Article 10 i.e. balances and/or transactions executed within the last 90 days). However, when an AISP1 request includes account information which falls outside the parameters of the 90 days and Article 10 (e.g. scheduled payments) using the 90 day access token, the OBIE Standard supports application of SCA to receive any additional account information (other than balance(s) and transactions executed within the last 90 days).

Upon the expiry of the 90 day access token period, the application of SCA by the ASPSP is the only step required by the ASPSP refreshing AISP access and the PSU must not be required to go through the same account(s) selection process to confirm the access.

In this example, the PSU will need to provide a new consent for the AISP to access the account information after 14 September 2020.

Amending Consent

In situations where a PSU wants to amend the access they have given to an AISP (e.g. they want to allow the AISP access to additional data elements) the AISP will have to take the PSU through a new consent process (as in section 3.1.1) as the API specifications do not support the ability to edit specific elements of a consent. It is in the domain of the AISP to clearly explain this process to the PSU and develop customer journeys for each scenario where this might apply.

Accounts associated with AISP long lived consent

From a technical perspective, the consent given by the PSU with respect to account information is bound to the data clusters requested by the AISP and the period over which access has been requested (including any expiry date).

The actual selection of the designated payment account(s) then happens in the ASPSP space.

The designated payment account(s) could subsequently change for the following reasons:

• The ASPSP offers a dashboard functionality which allows a PSU to manage the designated payment accounts to which an AISP has access.
• A designated payment account is no longer available as it has been closed or temporarily suspended etc.

In these circumstances, the consent given to the AISP is still valid (provided it is “long-lived”), and the AISP should check the most updated list of designated payment accounts during subsequent requests for data access.