P2 • Two way notification of revocation

• 1. Version Control
• • 2. Roadmap Definition
  • 3. Market analysis
    • 3.1 OBIE Analysis on Consents and Account Access 
    • 3.2 Customer Research
  • 4. Two-way Notification Models
    • 4.1 Revocation at TPP
      • 4.1.1 Real Time Notification (TPP to ASPSP)
    • 4.2 Revocation at ASPSP
      • 4.2.1 Basic ‘Polling’ / Pull Notification (TPP from ASPSP)
      • 4.2.2 Real Time / Push Notification (ASPSP to TPP) 
        • 4.2.2.1 Push Notification for Offline TPPs (ASPSP to TPP)
      • 4.2.3 Aggregated ‘Polling’ / Pull Notification (TPP from ASPSP)
  • 5. Customer use cases
  • 6. Regulatory Considerations
  • 7. Evaluation criteria
  • 8. Product requirements
  • 9. Considerations
    • 9.1 Assumptions
    • 9.2 Dependencies
    • 9.3 Constraint
  • 10. Measuring adoption
  • 11. Appendix
    •  11.1 Detailed Product Requirements
    • 11.2 Roadmap item definition
    • 11.3 Definitions
    • 11.4 Rationale for real-time notification of revocation 
    • 11.5 Customer Journeys 
      • 11.5.1 “Real-time” notification by TPP to ASPSP on revocation of consent
      • 11.5.2 “Polling” notification by ASPSP to TPP for revocation of access (ASPSP to TPP)
      • 11.5.3 “Real-time” notification by ASPSP to TPP on revocation of access

1. Version Control

2. Roadmap Definition

This proposition paper defines the scope of Roadmap Item P2: Two-Way Notification of Revocation. This dual functionality enables ASPSPs to notify TPPs when PSUs revoke TPP access using their ASPSP dashboards. It also enables TPPs to notify ASPSPs, when PSUs revoke their consent using their TPP dashboard. The ability of each party to notify the other of the revocation status, especially in real-time, ensures PSUs can have consistent view of consent and access at each dashboard. It will also minimise the possibility of subsequent mistaken access by TPPs because they will be alerted if access to the accounts has been revoked by PSUs at their ASPSP access dashboard.

Thus, in the context of this paper, the following definitions apply:

a) Revocation means EITHER or BOTH:

1. PSUs revoking long-lived consent given to a TPP using the TPP dashboard
2. PSUs revoking access given to a TPP using the ASPSP access dashboard

b) Two-Way Notification means:

1. TPPs to notify ASPSPs when PSUs have revoked their consent on TPP dashboards
2. ASPSPs to notify TPPs when PSUs have revoked their access on ASPSP dashboards

The proposition is only applicable in cases of ‘long lived’ consents given by PSUs to either AISPs or CBPIIs which can be revoked by PSUs at any point in time either directly with TPPs or by revoking access at ASPSPs via their relevant dashboard. However, the intention is not to restrict the notification mechanisms to specific types of TPPs but to enable the functionality to any TPPs where long-lived consents are revoked by PSUs, for example, this could be extended to PISPs in the future.

3. Market analysis

The majority of TPPs have indicated they would support implementation of infrastructure to enable real-time notification from ASPSPs, although several also stated they would support both real-time and polling, and some would only be prepared to support polling.

3.1 OBIE Analysis on Consents and Account Access

In the OBIE ecosystem, as of the end of Sep-18, there were approximately 6.7m successful API calls, 99.4% of those being Account Information Services (AIS) calls. Out of these, approximately 126K (2%) were account access authorisations of consents given to AISPs by PSUs. leading to approximately 87K account accesses granted by PSUs. Of this number, approximately 33K account access authorisations were re-authorisations, leaving circa 54K new account access authorisations for the month of Sept-18. It is currently estimated that the number of new account access authorisations is growing at 38% CAGR while the overall number of successful account access authorisations has grown from Mar-18 to Sep-18 at 42% CAGR. With this growth rate, new account access authorisations are expected to reach 140K in December 2018 while the total access authorisations for 2018 (including re-authorisations) is expected to reach 845K. Following this growth, this figure is expected to reach 2m authorisations by 2021. 

Of the total 87K account accesses granted by PSUs, only 185 (0.2%) consents have been revoked via TPP dashboard in the month of Sept-18. For the period Mar-18 to Sept-18, of the 410k total access authorisations (including re-authorisations) there were only 520 (0.13%) revocations of consent taking place on the TPP side via their dashboard. These figures appear to be quite low, so the current assumption is that at this early stage of the service PSUs may have been going to their APSPS to revoke the access to their account from TPPs. Unfortunately, we currently do not have any visibility of these revocations taking place at ASPSPs. 

Finally, polling has been used by TPPs to check the status, although it has been optional to be implemented by ASPSPs before V3 OBIE standards. In September 2018, there were 802 polling requests (0.01% of total API calls) making a total of 2793 polling status calls since Mar-18. 

3.2 Customer Research

OBIE has performed customer research through Ipsos (Report: “Exploring Responses to Revocation Journeys”, 2018). The key findings from this research are shown below:

1. There is some mistrust in companies when cancelling or amending contracts. Many customers have had bad experiences in the past
2. When cancelling contracts, customers are looking for reassurance that their actions have been successful
3. Customers are most likely to cancel with their TPP, then check up with their ASPSP
4. When revoking via their TPP, customers need confirmation from their bank to feel certain the revocation has worked. Receiving written confirmation from their bank helps reassure them and means they are less likely to have to double-check with their bank
5. The TPP needs to fully highlight the implications of revoking access. Customers would expect to be able to access a thorough list of implications of cancelling access – especially from the TPP. The bank has less responsibility for this but ideally would highlight some generic potential implications to make sure customers consider the impact of revocations.

OBIE’s customer research clearly indicates that customers feel a need for “real-time” revocation systems.

4. Two-way Notification Models

4.1 Revocation at TPP

4.1.1 Real Time Notification (TPP to ASPSP)

This functionality enables the TPP to notify the ASPSP in real-time (i.e. immediately) after the PSU revokes their consent at their TPP consent dashboard, provided that the TPP takes immediate action upon the PSU revocation. The current Open Banking V3 Read/Write specifications enable a TPP to use the ‘DELETE’ API endpoint and notify the ASPSP that the PSU has revoked their consent. For more details, please refer to sections 11.3 and 11.5.1.

4.2 Revocation at ASPSP

4.2.1 Basic ‘Polling’ / Pull Notification (TPP from ASPSP)

This is the provision of pull notification (polling) for TPPs to poll the status of their account access at relevant ASPSPs. This functionality enables TPPs 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 TPP to use the ‘GET’ API endpoint to poll the ASPSP and check the status of their account access. For more details, please refer to sections 11.3 and 11.5.2. 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 TPPs 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. 

4.2.2 Real Time / Push Notification (ASPSP to TPP)

This functionality enables an ASPSP to notify the TPP in real-time (i.e. immediately) after the PSU revokes their access at their ASPSP dashboard. Upon receipt of this notification, TPPs can notify the PSUs, if required, that their access at the ASPSP is no longer valid. For more details, please refer to sections 11.3 and 11.5.3.

4.2.2.1 Push Notification for Offline TPPs (ASPSP to TPP)

This functionality enables ASPSPs to use push notification mechanisms to notify TPPs whose systems are offline that PSUs revoked their access using the ASPSPs’ dashboards. This removes the requirement for TPPs to have systems up and running 24×7 in order to receive real-time push notifications from ASPSPs. Once the TPPs’ systems are available again, ASPSPs will push any notifications required to the TPPs, so that TPPs can update their systems and notify the PSUs appropriately, if required.  

This will be covered by product requirements in this paper.

4.2.3 Aggregated ‘Polling’ / Pull Notification (TPP from ASPSP)

Similar to basic polling, Aggregated Polling is about the provision of notification of revocations from ASPSPs to TPPs, upon TPP request, enabling TPPs 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 consent resource’s status (via a GET request on that specific resource), aggregated polling allows a TPP to request an aggregated set of consent revocations and other account access events related to multiple access consents from multiple PSUs during a specific period. This functionality makes much more efficient usage of the ASPSPs and TPPs network bandwidth as multiple single polls, especially with no change of access status, are avoided. Moreover, it allows TPPs 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 TPPs about the timing they want to receive the notifications based on their business models.  Again, TPPs are able to notify PSUs immediately after they poll ASPSPs, if required.

This will be covered by product requirements in this paper.

5. Customer use cases

The following are some example use cases which have been considered for this proposition.

6. Regulatory Considerations

If a PSU revokes their consent or access at either their TPP or ASPSP dashboards, there is no regulatory requirement for either party to inform the other party. Please note however, that if this functionality is implemented, upon receipt of notification of a revocation of consent or access, each party must consider both their regulatory and contractual obligations with the PSU. This is relevant to the TPP functionality in particular – see assumptions.

7. Evaluation criteria

Key evaluation criteria that OBIE have applied for this proposition for effectiveness and proportionality:

• Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
• Is the proposition implementable at a reasonable cost?

8. Product requirements

OBIE understands that this proposition needs to support the following high-level requirements:

• When PSU revokes access given to a TPP for a specific account(s) at the ASPSP access dashboard, then the ASPSP should be able to notify the TPP about the revocation in real time, provided that TPP systems are available. The TPP then may need to notify the PSU that the access is no longer valid.
• When PSU revokes access given to a TPP for a specific account(s) at the ASPSP access dashboard, then the ASPSP should be able to notify the TPP about revocation even if the TPP systems are not available at the time of the revocation. Once TPP systems are available again, they should be able to receive the revocation notifications from the ASPSP without having to poll the ASPSP. TPPs can then take appropriate actions notifying the PSU, if required.  
• When ASPSP suspends the token or has expired or the token is invalidated for other reasons, then the ASPSP should be able to notify the TPP that the access to the account(s) is no longer available via the TPP, using push notifications and providing the reason code if appropriate.
• When PSUs revoke access given to a TPP for multiple consents via the ASPSP dashboard, then the ASPSP should be able to notify the TPP immediately when the TPP requests to know the status of access for all consents of all PSUs with the specific ASPSP. This should be done using a single call (aggregated polling) to get an aggregated set of consent revocations for a specific period.

9. Considerations

9.1 Assumptions

• For TPPs, when the PSU revokes their consent at the consent dashboard,  TPPs must notify the ASPSP “immediately”, by using the “DELETE” endpoint. From a technical perspective, if the TPP fails to use the “DELETE” endpoint and accordingly the ASPSP does not receive the notification, the TPP would still be able to access the PSU’s account for the remaining duration of their consent (notwithstanding any SCA requirements). We note that failure of deletion and subsequent use of the access consent could have implications under both GDPR and PSRs. As, such, we would expect TPPs to have robust controls in place to ensure that the use of the “DELETE” endpoint occurs seamlessly upon revocation of the consent at their dashboard by the PSU and that no further access to the account takes place. TPPs wishing to regain access to the PSU’s account, must agree new consent parameters with the PSU.
• Similarly, when the PSU revokes access at their ASPSP and the TPP receives the notification of the revocation, TPPs are expected to align their consent dashboard based on the result of the notification message(s) received from the ASPSP. While the consent agreed with the PSU remains valid, the notification will serve as a clear instruction that the PSU has revoked access. As such, TPP should consider either contacting the PSU to ask whether they wish to revoke their consent or the TPP could remove the consent automatically and notify the PSU. TPPs should consider the most appropriate approach based on their terms and conditions with the PSU, as well as, their service offering. 
• After access revocation by the PSU at the ASPSP, if the PSU wants to re-establish access, they would need to start a new customer journey with their TPP to re-establish or agree new consent parameters and would also require authentication with their ASPSP. 
• OBIE will need to consider any relevant outputs from two-way notification of revocation on the customer journey and consider any applicable changes in the Customer Experience Guidelines.
• In all the two-way notification models (mentioned in section 4), there is an assumption that the notified parties (TPPs or ASPSPs) will act upon the notification received and confirm back to PSUs or provide additional information to PSUs if required.

9.2 Dependencies

Dependency on EBA Q&A ID 2018_4309

We are aware of the recent EBA Q&A ID 2018_4309 relating to the revocation of consent by the ASPSP. We are considering this internally and its potential implications for the access dashboards and the categorisation of requirements, where appropriate. However, this has also dependency on the overall evaluation of the efficacy of the Consent and Access Dashboards as per roadmap item P15. Once a clearer position is stated as the outcome of the P15 evaluation, we will aim to provide an update to this paper.

• ASPSPs will optionally support various notification methods including real-time notification and pull notification (i.e. individual resource polling, or aggregated polling) to enable TPPs to use a suitable method as it may not be feasible for some TPPs to make highly expensive infrastructure available in real-time.
• However, some ASPSPs are not capable from both technical and information security governance perspective to send outbound push requests to TPPs

9.3 Constraint

• Notifications are only available to long-lived consents and thus is currently not available to PISPs.

10. Measuring adoption

The following metrics will be required to measure adoption:

1. Number of TPPs using push and pull (basic and aggregated) notification methods
2. Volume of successful and failed notifications of revocation of consent at TPPs – (received by ASPSPs)
3. Volume of successful and failed notifications of revocation of access at the ASPSPs using basic polling – (requested by TPPs)
4. Volume of successful and failed notifications of revocation of access at the ASPSPs using aggregated polling – (requested by TPPs)
5. Volume of successful and failed notifications of revocation of access at the ASPSPs using real-time push notifications – (pushed by ASPSPs to TPPs)
6. Volume of successful and failed notifications of revocation of access at the ASPSPs using push notifications for offline TPPs – (pushed by ASPSPs to TPPs)

Note: MI must be provided for the implemented model.

11. Appendix

11.1 Detailed Product Requirements

These are stated as requirements of the OBIE solution to enable support for key customer use cases.

Requirements marked as ‘M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is ‘mandatory’, ‘conditional’ or ‘optional’ for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.

11.2 Roadmap item definition

The following table is taken ‘as-is’ from the original published roadmap:

11.3 Definitions

In the context of this paper, 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 TPP, or vice versa, immediately after the PSU revokes consent or access at the respective dashboard.
4. ‘Polling’ requires the TPP 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.

11.4 Rationale for real-time notification of revocation

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

1. The PSU sees consistent status at both the TPP and ASPSP which builds PSU confidence.
2. It enables TPPs to immediately provide PSUs with information about the consequences of revocation, ensuring that action can be taken before a service “fails” if necessary.
3. It reduces the chance of a PSU receiving confusing messaging (e.g. reminders or marketing) after revocation but before the TPP is aware of it.
4. It “future proofs” the system against potential use cases or business models that are extremely time sensitive.
5. It protects the broader system from artificially inflated usage due to repeat “polling” simply for the sake of checking consent.

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 TPPs 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 TPPs.
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.

11.5 Customer Journeys

11.5.1 “Real-time” notification by TPP to ASPSP on revocation of consent

Notes:

• “Users are most likely to cancel with their TPP, then check up with their bank” (OBIE customer research*)
• If the PSU views their TPP consent dashboard or their ASPSP access dashboard (step 5), they will see the same consistent view – i.e. access is revoked
• The ASPSP may message the PSU immediately after step (4) to confirm access has been revoked. This is in the competitive space but recommended by OBIE customer research*
  • “Receiving written confirmation from their bank helps reassure them and means they are less likely to double check with their bank”
  • This is reassuring and helps PSUs feel in control, building trust over the Open Banking service
• Defining the usage of ‘Delete’ API as mandatory, creates an obligation for TPP to immediately notify the ASPSPs of the revocation. If the TPP fails to notify the ASPSP to delete the access at the ASPSP, then by error the TPP could potentially continue to access the PSU account(s). TPPs must ensure they have robust systems in place to ensure this happens immediately. 
• There is low probability for unintended consequences, since the TPP is able (and expected) to present the PSU with the consequences of their revocation. As recommended by OBIE customer research*:
  • “The TPP needs to fully highlight the implications of revoking access”

*Ipsos, Exploring Responses to Revocation Journeys, 2018

11.5.2 “Polling” notification by ASPSP to TPP for revocation of access (ASPSP to TPP)

Notes:

• “Users felt that if they wanted to know for certain that access has been revoked, they would go via their bank” (OBIE customer research*)
• Provided the TPP polls the ASPSP status endpoint (step 6a) before the PSU views the consent dashboard in step (6). The PSU will always see the same consistent view on ASPSP and TPP dashboards in step 7)
• TPP messaging the PSU after revocation is in the competitive space but recommended by OBIE customer research*
  • “They (i.e. PSUs) would expect to be able to access a thorough list of implications of cancelling access – especially from the TPP”
• The TPP may not know immediately and thus may not be able to message the PSU until they poll, which could happen automatically when the user logs in to the TPP, if not happened earlier
• “Ideally the bank should prompt PSUs to check the potential implications of cancelling” (OBIE customer research*). However, the bank is only able to highlight some generic potential implications, which cannot be detailed.
• There is some probability of unintended consequences, as the TPP may not be able to contact the PSU immediately and provide a thorough list of the implications of revocations. However,
  • unintended consequences may not be applicable in many cases
  • Immediately finding out about the unintended consequences may not be required in many cases
  • there is an assumption that the TPP, if required, will act upon the notification received as per the OBIE recommendation (this is still in the competitive space)

*Ipsos, Exploring Responses to Revocation Journeys, 2018

11.5.3 “Real-time” notification by ASPSP to TPP on revocation of access

Please Note:

If the PSU views their TPP consent dashboard (step 6) or their ASPSP access dashboard, they will see the same consistent view – i.e. access is revoked

• TPPs are expected to present the PSU with the consequences of their revocation. As recommended by OBIE customer research*:
  • “The TPP needs to fully highlight the implications of revoking access”
• “There would be value in the ASPSP alerting TPP in real time about revocation because it would allow the TPP to do the ‘unintended’ consequences’ communications” (OBIE customer research*)
• There is low probability for unintended consequences, since the TPP after receiving the notification has the ability to contact the PSU immediately and, if required, provide a thorough list of the implications of revocations. However,
  • there is an assumption that the TPP will act upon the notification received as per the OBIE recommendation, if required (this is still in the competitive space for TPPs)
  • unintended consequences may not be applicable in many cases

*Ipsos, Exploring Responses to Revocation Journeys, 2018