Two-Way Notification of Revocation 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.
Other pages in this section
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:
b) Two-Way Notification means:
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.
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.
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.
OBIE has performed customer research through Ipsos (Report: “Exploring Responses to Revocation Journeys”, 2018). The key findings from this research are shown below:
OBIE’s customer research clearly indicates that customers feel a need for “real-time” revocation systems.
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.
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.
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.
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.
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.
The following are some example use cases which have been considered for this proposition.
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.
Key evaluation criteria that OBIE have applied for this proposition for effectiveness and proportionality:
OBIE understands that this proposition needs to support the following high-level requirements:
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.
The following metrics will be required to measure adoption:
Note: MI must be provided for the implemented model.
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.
The following table is taken ‘as-is’ from the original published roadmap:
In the context of this paper, the following definitions apply:
‘Real-time’ revocation enables the best conceivable customer experience:
However, enabling only ‘real-time’ revocation presents certain challenges as outlined below:
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.
*Ipsos, Exploring Responses to Revocation Journeys, 2018
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
P1 • Open Data for standardised back-book products Previous
P3 • Efficacy of consumer authentication step Next