Account Information Services

Access Status Notifications by ASPSPs

This version is:

Published 3 years ago 31 Mar 2021

In addition to the mandatory notifications between AISPs and ASPSPs (refer to section Mandatory notification mechanisms between AISPs and ASPSPs), OB Standards have been extended to provide additional notification mechanisms.

Other pages in this section

User Journey

 

This content is best viewed on a desktop browser.

1

CX Considerations A
PSU revokes access from the ASPSP Access Dashboard The PSU follows the journey shown in section 3.1.4 to revoke access to their account for a specific AISP. ASPSP should confirm to the PSU that access to the account(s) has been revoked.

2

CX Considerations B
Real Time Push Notification from ASPSP to AISP The ASPSP should notify the AISP in real time (i.e. immediately) after the PSU revokes their access at their ASPSP Access dashboard. The implementation of the real-time mechanism is defined in the OBIE technical specifications.

3

CX Considerations C
Push Notification for Offline AISPs (ASPSP to AISP) ASPSPs should also be able to use push notification mechanisms to notify AISPs whose systems are offline that PSUs revoked their access using the ASPSPs’ access dashboards. This removes the requirement for AISPs to have systems up and running 24×7 in order to receive real-time push notifications from ASPSPs. Once the AISPs’ systems are available again, ASPSPs should push again any notifications required to the AISPs, so that AISPs can update their systems. In addition to PSU revocation of access, ASPSPs should be able to notify the AISPs when access to account(s): has been suspended by ASPSP due to changes in the account access resource for any valid reason (e.g. CASS by PSU, joint holder revoking access, account closed, etc.) and could provide the reason code, if appropriate. is no longer available due to changes in the state of the access token for any valid reason (e.g. token has expired, token has been suspended by the ASPSP due to fraud etc.) and could provide the reason code, if appropriate.

4

CX Considerations D
Notification to PSU by AISP Upon receipt of the notification by the ASPSP, the AISP should notify the PSU, if required, that the access to their ASPSP account(s) is no longer possible. AISPs should present the PSU with the implications of the access revocation in case there are ‘unintended’ consequences’. However, unintended consequences may not be applicable in many cases. PSUs could then take their preferred actions such as continuing to use the service or stop. If the former, they will be required to authenticate again with their ASPSPS in order to provide access to the AISPs. If the latter, PSUs may also want to remove their consent with the AISPs.

5

CX Considerations E
Multiple PSUs revoke access from the ASPSP Access Dashboard Multiple PSUs, during a period of time, follow the journey shown in section 3.1.4 to revoke access to their account for a specific AISP. For each PSU access, revocation, the ASPSP should confirm to the PSU that access to the account(s) has been revoked.

6

CX Considerations F
ASPSP updates the access status on events Repository For all PSUs access revocations, the ASPSP should update the status of the access resources in an events Repository organised per each AISP.

7

CX Considerations G
Aggregated ‘Polling’ / Pull Notification of ASPSP by AISP Similar to basic polling, aggregated Polling is about the provision of notification of revocations from ASPSPs to AISPs, upon AISP request, enabling AISPs to update their records and contact the PSUs, if required, at the point in time of the request. However, the key difference is that rather than focusing on a specific access resource’s status (via a GET request on that specific resource), aggregated polling allows an AISP to request an aggregated set of access revocations and other account access events related to multiple access consents from multiple PSUs during a specific period. ASPSPs should provide to the polling AISP all the access resource status and other information stored in the repository for that specific AISP, upon AISP request. In addition to PSU revocation of access, ASPSPs should be able to notify the AISPs when access to account(s): has been suspended by ASPSP due to changes in the account access resource for any valid reason (e.g. CASS by PSU, joint holder revoking access, account closed, etc.) and could provide the reason code, if appropriate. is no longer available due to changes in the state of the access token for any valid reason (e.g. token has expired, token has been suspended by the ASPSP due to fraud etc.) and could provide the reason code, if appropriate. Note: This functionality makes much more efficient usage of the ASPSPs and AISPs network bandwidth as multiple single polls, especially with no change of access status, are avoided. Moreover, it allows AISPs to receive all the required notifications without the need to implement systems with high availability (e.g. systems running 24×7) or systems based on real-time push notifications, providing full flexibility to AISPs about the timing they want to receive the notifications based on their business models.

8

CX Considerations H
Notification to multiple PSUs by AISP Upon receipt of the aggregated polling information by the ASPSP, the AISP should notify all the PSUs, when required, that their access to their ASPSP account(s) is no longer possible. AISPs should present to all PSUs the implications of the access revocation in case there are ‘unintended’ consequences’. However, unintended consequences may not be applicable in many cases. PSUs could then take their preferred actions such as continuing to use the service or stop. If the former, they will be required to authenticate again with their ASPSPS in order to provide access to the AISPs. If the latter, PSUs may also want to remove their consent with the AISPs.

In addition to the mandatory notifications between AISPs and ASPSPs (refer to section Mandatory notification mechanisms between AISPs and ASPSPs), OB Standards have been extended to provide the following additional notification mechanisms:

A. Real Time / Push Notifications: Functionality to enable ASPSPs to notify AISPs in real time (i.e. immediately) when a PSU revokes their access at their ASPSP dashboard or other account access changes events take place.

B. Aggregated ‘Polling’ / Pull Notification: Provision of notification of revocations from ASPSPs to AISPs, upon AISP request. It allows an AISP to request an aggregated set of access revocations and other account access events related to multiple access consents from multiple PSUs during a specific period.

CX and other processing requirements
Real-time / Push Notifications

A

PSU revokes access from the ASPSP Access Dashboard The PSU follows the journey shown in section AIS Access Dashboard & Revocation to revoke access to their account for a specific AISP. ASPSP should confirm to the PSU that access to the account(s) has been revoked.

B

Real Time Push Notification from ASPSP to AISP The ASPSP  should  notify the AISP in real time (i.e. immediately) after the PSU revokes their access at their ASPSP Access dashboard. The implementation of the real-time mechanism is defined in the OBIE technical specifications.

C

Push Notification for Offline AISPs (ASPSP to AISP) ASPSPs should also be able to use push notification mechanisms to notify AISPs whose systems are offline that PSUs revoked their access using the ASPSPs’ access dashboards. This removes the requirement for AISPs to have systems up and running 24×7 in order to receive real-time push notifications from ASPSPs. Once the AISPs’ systems are available again, ASPSPs should push again any notifications required to the AISPs, so that AISPs can update their systems. In addition to PSU revocation of access, ASPSPs should be able to notify the AISPs when access to account(s):

  • has been suspended by ASPSP due to changes in the account access resource for any valid reason (e.g. CASS by PSU, joint holder revoking access, account closed, etc.) and could provide the reason code, if appropriate.

is no longer available due to changes in the state of the access token for any valid reason (e.g. token has expired, token has been suspended by the ASPSP due to fraud etc.) and could  provide the reason code, if appropriate.

Aggregated Polling / Pull Notifications

D

Notification to PSU by AISP

  • Upon receipt of the notification by the ASPSP, the AISP should notify the PSU, if required, that the access to their ASPSP account(s) is no longer possible. AISPs should present the PSU with the implications of the access revocation in case there are ‘unintended’ consequences’. However, unintended consequences may not be applicable in many cases.
  • PSUs could then take their preferred actions such as continuing to use the service or stop. If the former, they will be required to authenticate again with their ASPSPS in order to provide access to the AISPs. If the latter, PSUs may also want to remove their consent with the AISPs.

E

Multiple PSUs revoke access from the ASPSP Access Dashboard Multiple PSUs, during a period of time, follow the journey shown in section AIS Access Dashboard & Revocation to revoke access to their account for a specific AISP. For each PSU access, revocation, the ASPSP should confirm to the PSU that access to the account(s) has been revoked.

F

ASPSP generates access revocation events in their events repository For all PSUs access revocations, the ASPSP should generate an access revocation event in the events Repository organised per each AISP. In cases where the AISP has subscribed to access revocation events for aggregated polling (or push notifications), the ASPSP should generate an access revocation event in the events Repository organised per each AISP.

G

Aggregated ‘Polling’ / Pull Notification of ASPSP by AISP

  • Similar to basic polling, aggregated Polling is about the provision of notification of revocations from ASPSPs to AISPs, upon AISP request, enabling AISPs to update their records and contact the PSUs, if required, at the point in time of the request. However, the key difference is that rather than focusing on a specific access resource’s status (via a GET request on that specific resource), aggregated polling allows an AISP to poll for the outstanding or awaiting events in the ASPSP’s events repository related to multiple access consents from multiple PSUs.
  • ASPSPs should provide to the polling AISP all the access resource status and other information stored in the repository for that specific AISP, upon AISP request. Please note that in case of in case of access revocation, there is no change to underlying consent resource. However, the event type, is same for both events, i.e. consent-authorization-revoked.

In addition to PSU revocation of access (event UK.OBIE.Consent-Authorization-Revoked), ASPSPs should be able to notify the AISPs for the below 2 events:

  1. UK.OBIE.Resource-Update – An event that indicates a resource has been updated.
  2. UK.OBIE.Acount-Access-Consent-Linked-Account-Update – An event that indicates an account linked to a consent has move in/out of scope of the consent.

Note: This functionality makes much more efficient usage of the ASPSPs and AISPs network bandwidth as multiple single polls, especially with no change of access status, are avoided. Moreover, it allows AISPs to receive all the required notifications without the need to implement systems with high availability (e.g. systems running 24×7) or systems based on real-time push notifications, providing full flexibility to AISPs about the timing they want to receive the notifications based on their business models.

H

Notification to multiple PSUs by AISP

  • Upon receipt of the aggregated polling information by the ASPSP, the AISP should notify all the PSUs, when required, that their access to their ASPSP account(s) is no longer possible. AISPs should present to all PSUs the implications of the access revocation in case there are ‘unintended’ consequences’. However, unintended consequences may not be applicable in many cases.
  • PSUs could then take their preferred actions such as continuing to use the service or stop. If the former, they will be required to authenticate again with their ASPSPS in order to provide access to the AISPs. If the latter, PSUs may also want to remove their consent with the AISPs.

Additional Information

Mandatory notification mechanisms between AISPs and ASPSPs

Real Time Notification from AISP to ASPSP on revocation of consent

This functionality enables the AISP to notify the ASPSP in real time (i.e. immediately) after the PSU revokes their consent at their AISP consent dashboard, provided that the AISP takes immediate action upon the PSU revocation. The current Open Banking V3 Read/Write specifications enable an AISP to use the ‘DELETE’ API endpoint and notify the ASPSP that the PSU has revoked their consent.

The implementation of the ‘DELETE’ API endpoint is mandatory for ASPSPs.

Note: For AISPs, when the PSU revokes their consent at the consent dashboard, AISPs must not call any protected data resource which falls within the scope of the consent originally granted. This AISP must delete the account-access-consent resource with the ASPSP by using the ‘DELETE’ end point as soon as practically possible. We note that subsequent use of the access consent could have implications under both GDPR and PSRs. As, such, we would expect AISPs to have robust controls in place to ensure that upon revocation of the consent at their dashboard by the PSU that no further access to the account takes place. AISPs wishing to regain access to the PSU’s account, must agree new consent parameters with the PSU.

Basic ‘Polling’ / Pull Notification of ASPSP from AISP

This is the provision of pull notification (polling) for AISPs to poll the status of their account access at relevant ASPSPs. This functionality enables AISPs to update their records and to notify PSUs, if required, that their access at the ASPSP is no longer valid. The current Open Banking V3 Read/Write specifications enable the AISP to use the ‘GET’ API endpoint to poll the ASPSP and check the status of their account access. It should be noted that, this simple mechanism of checking the account access using basic polling is very inefficient in its use of network bandwidth for both AISPs and ASPSPs. Basic polling may not be scalable enough to support the growing ecosystem of Open Banking, especially when the volumes of account access consents grow significantly during the following few years.

The implementation of the ‘GET’ API endpoint is mandatory for ASPSPs.

Note: When the PSU revokes access at their ASPSP and the AISP receives the notification of the revocation,. while the consent agreed with the PSU remains valid, the notification will serve as a clear indication that the PSU has revoked account access. As such, the AISP should consider either contacting the PSU to ask whether they wish to revoke their consent or request access to the account or the AISPs could decide to remove the consent automatically and notify the PSU. AISPs should consider the most appropriate approach based on their terms and conditions with the PSU, as well as, their service offering. 

 

Definitions

In the context of this document, the following definitions apply:

1.Pull notification (also referred to as polling) is where the initial request for data originates from the client and then is responded by the server.

2.Push notification is when server will notify client when there is an update in real time.

3.’Real-time’ notification of revocation is a system which triggers a message from ASPSP to AISP, or vice versa, immediately after the PSU revokes consent or access at the respective dashboard.

4.’Polling’ requires the AISP to call the relevant ASPSP API end-point to determine whether their access to the PSU’s account(s) at a specific ASPSP is valid.

Rationale for real-time notification of revocation

‘Real-time’ notification enables the best conceivable customer experience:

1.It enables AISPs to immediately provide PSUs with information about the consequences of access revocation, ensuring that action can be taken before a service “fails”, if necessary.

2.It reduces the chance of a PSU receiving confusing messaging (e.g. reminders or marketing) after revocation of access but before the AISP is aware of it.

3.It “future proofs” the system against potential use cases or business models that are extremely time sensitive.

4.It protects the broader system from artificially inflated usage due to repeat “polling” simply for the sake of checking access is available.

However, enabling only ‘real-time’ revocation presents certain challenges as outlined below:

1.’Real-time’ systems require potentially significant build and maintenance resources that may not be required for many use cases where ‘polling’ might be more than adequate. In these cases, forcing the use of ‘real time’ revocation may reduce active use of the system.

2.There is no ability to mandate that AISPs implement specific infrastructure to receive “real-time” messages, nor to set or measure performance SLAs of these.

3.Even where ‘real time’ is the optimal solution, the ability to fall back on ‘polling’ significantly adds to the robustness, and availability levels of the service offered, especially by AISPs.

4.’Polling’ is a significantly simpler mechanism (one that is already enabled).

In conclusion, enabling both methodologies ensure that the system is flexible enough to accommodate all use cases and business models, enabling participants to tailor their systems to best suit the needs of their PSUs and adds to the stability of the overall system.

What the research says

 

Click for customer research