1. Introduction

This paper sets out some of the unintended consequences reported by ecosystem participants due to the requirement for the PSU to re-authenticate with their ASPSP at least every 90 days so that the AISP can maintain access for the provision of account information services. It also defines a number of possible solutions which could be used to reduce friction, reduce drop-off/churn and thereby mitigate potential customer detriment.

The PSRs require Strong Customer Authentication (SCA) 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.​ A PSU having given long-lived consent to an AISP to avail account information services, has to undergo SCA if it is accessing its account information via the AISP online for the first time, or if more than 90 days have elapsed since the last time the PSU accessed the information and SCA was applied. Irrespective of the duration of the consent agreed between the AISP and the PSU for the provision of the account information service, the PSU would still need to undergo SCA with their ASPSP at least every 90 days. This frequency may also increase if the PSU holds multiple payment accounts with various ASPSPs as they would need to undertake SCA for each of those ASPSPs on an individual basis.

The 90 days re-authentication process has been shown to cause a significant drop-off, even when the user is still interested in ongoing usage (i.e. has given long-lived consent to the AISP) for an account information service. This may be because the PSU is either unwilling or unavailable to undergo SCA with the ASPSP every 90 days.

Ever since open banking APIs started to become available in the UK (from Jan 2018), there has been significant and growing interest among ASPSPs and TPPs to create a more seamless process that reduces this burden on having to authenticate with their ASPSP(s) every 90 days and supports the provision of uninterrupted account information services from the AISP to the PSU. 

This paper is looking to address the aforementioned drop off the issue by enabling:

• the PSU to re-authenticate seamlessly with less friction; and
• the AISP to thereby provide uninterrupted account information services to the PSU, avoiding any unintended or undesirable consequences due to service disruption.

2. Market analysis

During the period May 2018 to July 2019, Open Banking AIS consent request endpoint calls across the CMA9 reached a total of 6.1m. Out of these, the authorised consents were 4.9m and represent year-on-year growth of 490%. It should be noted that 4.2m of these endpoint calls were using v1 endpoints of the standards, while 680K calls were based on the v3 implementation of the standards.

Since there was no re-authentication journey implemented by the AISPs for v1 standards, a portion of the 4.2m v1 authorised account consent request endpoint calls were related to creating a new consent request after 90 days. This is estimated to be around 2.3m, i.e. circa 55% of the total authorised v1 consent calls.

V3 of the standards enable re-authentication journeys to be implemented by AISPs and ASPSPs. Thus far, the number of re-authentications which have taken place for these v3 endpoint consent calls are estimated to be circa 2k in the month of April 2019, however, data for re-auth numbers since May 2019 are not available yet.

2.1 OBIE analysis on 90 days re-authentication

The section below presents information received and issues identified by OBIE in relation to the current 90-days re-authentication process.  

Customers

Open Banking customers want the authentication process to be as frictionless as possible and do not want the burden of having to re-authenticate on a frequent basis with both AISPs and ASPSPs in order to continue to use AISP services. While there is no specific customer research relating to the friction of 90-day re-authentication, there is substantial evidence which shows that additional steps or delays in an online process result in customers abandoning that process:

• The most widely seen examples of abandonment can be seen in e-commerce statistics (see https://www.barilliance.com/cart-abandonment-rate-statistics/#tab-con-1/ ).
• Overall delays (e.g. additional steps in a process) also have a significant impact on abandonment (see https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/).
• Information supplied from CMA9 in Sep 2019 shows a c50% average completion rate for all PSU authentications (AIS and PIS journeys), with some more complex journeys (e.g. where there are multiple steps) being close to 0% conversion. While this information does not relate specifically to re-authentication, it can be deduced that many customers who intend to re-authenticate every 90 days (i.e. because they are actively using the TPP service) will end up dropping off and losing this service due to the extra friction. 

There are also several examples being shared with OBIE where there is a risk of significant customer detriment if the PSU has to re-authenticate every 90 days, for example:

• A vulnerable customer who uses a TPP monitoring service which allows a delegated representative (who may not have direct access to the customer’s actual bank account) to monitor their account via for unusual transactions. They could be exposed to greater risk if required to re-authenticate every 90 days.
• A small business accountant who has, say, over 100 SME customers, and uses a cloud accounting package on a regular basis to prepare accounts. They will now have to ask each of their 100 customers to re-authenticate every 90 days in order that they can continue to provide a service.

TPPs

TPPs prefer a seamless 90-days re-authentication process with less involvement of the PSU, in order to reduce friction and complexity. They are also suggesting that shifting the re-authentication burden from the ASPSP to the AISPs will reduce the overall friction. Their feedback also suggests that PSUs may stop using AISP services if the 90-day re-authentication process creates a burden for continued use of the service, especially if they have already given a long-lived consent to the AISP. 

Based on Impact Analysis from one of the TPPs with a significant number of active PSUs over the last 6+ months, there is a drop off of approximately 13% of active customers every 90 days. Moreover, around 30% of their customer connections are broken due to 90 days re-auth as compared to screen scraping, where there are no 90 days re-auth.

The diagram is for illustrative purposes only

One of the TPPs conducted a customer survey with a set of customers who completed 90 days re-authentication. This indicated that:

• 30.4% of their customers feel the journey is too long and too obstructive.
• 15.4% feel it is confusing and don’t understand why it is required every 90 days and what security features it provides to the customer.
• 12.9% feel that the journey is off-putting and would be less likely to use a service if they are asked to renew access every 90 days.

Furthermore, several TPPs (including tech giants with tens of millions of personal customers and major business accounting firms) have stated a strong reluctance to enter the market and offer services on top of APIs which require SCA at both the TPP and the ASPSP end in order to maintain connectivity. 

ASPSPs

So far, OBIE has received limited feedback from ASPSPs in relation to the 90-days re-authentication. However, we are expecting ASPSPs who are also looking to introduce AIS services to their customers, to take a positive position in relation to streamlining the re-authentication process for reduced friction and to enable further AIS adoption.

3. Customer use cases

The majority of the use cases identified are primarily focused around reducing friction related to re-authentication for ongoing use of account information services. For example, personal financial management, where the PSU has regular interactions to utilise the service, accountancy packages for SMEs or alternative overdraft offerings, etc.

4. Proposed options

OBIE has explored a number of options with industry stakeholders, including ASPSPs, TPPs, and TSPs. All these options can mutually coexist.

4.1 Option 3: SCA by AISP on behalf of ASPSPs

When the AISP requires the PSU to undergo SCA within or at the expiry of the 90 day period for account information access, the AISP will alert the PSU either within the session or outside of it (e.g. via SMS or push notification) that specific payment account(s) access across multiple ASPSPs are due for refresh. 

The PSU will then undergo SCA at the AISP, as per the agreed parameters with the ASPSP(s). The AISP will then send a message to each ASPSP confirming that SCA has been performed successfully and requesting the ASPSPs to reset the 90-days re-authentication counter for the selected payment account accesses.

The benefit of this option is to reduce the friction of the PSU going through multiple re-authentication journeys with multiple ASPSPs for the same AISP. 

This option is likely to require a contract between the AISP and each ASPSP. 

Customer journey

5. Evaluation criteria

Key evaluation criteria that OBIE has applied for this proposition (that respect the objectives of meeting regulatory requirements, as well as being effective and proportionate) are:

1. Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
2. Is the proposition implementable at a reasonable cost?
3. Does the proposition comply with all relevant regulations? 

6. Considerations

6.1 Assumptions

• Options 3 are expected to require a contract between the AISP and each ASPSP.

6.2 Dependencies

• None. 

6.3 Constraints

• None.

7. Measuring adoption

The following metrics will be required to measure adoption:

1. The volume of successful re-authentication by PSU via the AISP, including PSU, calls to action (i.e. SCAs) and actual access refreshes.
2. The volume of re-authentication overdue for renewal where the PSU did not re-authenticate.
3. The volume of re-authentication cancelled by the PSU when reminded for re-authentication due.

8. Appendix

8.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 the 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.

8.2 Relevant regulatory references

RTS -SCA

Article 10(2)(b)

2. For the purpose of paragraph 1, payment service providers shall not be exempted from the application of strong customer authentication where either of the following condition is met:

(a) the payment service user is accessing online the information specified in paragraph 1 for the first time;

(b) more than 90 days have elapsed since the last time the payment service user accessed online the information specified in paragraph 1(b) and strong customer authentication was applied.

EBA opinion paper – 13th June 2018

37. Article 97(5) of PSD2 states that the ASPSP shall allow PISPs and AISPs to rely on the authentication procedures provided to its PSUs and Article 67(2)(b) states that the security credentials are accessible to the AISPs and PISPs. Recital 30 of PSD2 also states that ‘The personalised security credentials used for secure customer authentication by the payment service user or by the payment initiation service provider are usually those issued by the account servicing payment service providers.  

38. The articles mentioned above are to be read in conjunction with one another, which means that the PSP applying SCA is the PSP that issues the personalised security credentials.It is consequently also the same provider that decides whether or not to apply an exemption in the context of AIS and PIS. The ASPSP may, however, choose to contract with other providers such as wallet providers or PISPs and AISPs for them to conduct SCA on the ASPSP’s behalf and determine the liability between them.The EBA also notes that a number of governmental (national) agreements on universal sets of personalised security credentials that can be used by PSUs with multiple PSPs already exist in some Member States.

39. The EBA notes that PISPs and AISPs sometimes wish to issue their own credentials for accessing their own platform (e.g. app or online website) and may therefore also wish to decide whether or not to perform authentication procedures for accessing this platform.However, only the ASPSP can apply SCA or decide whether or not an exemption applies to a PSU’s payment account in the context of AIS and PIS.For instance, only the ASPSP can decide whether or not to apply the transaction risk analysis exemption under Article 18 of the RTS. The PISP may have access to the list created and/or amended by the PSU in the ASPSP’s domain but the decision whether or not to apply the exemption remains with the ASPSP

44. Article 10 of the RTS on SCA and CSC provides an exemption from SCA when a PSU or AISP accesses limited payment account information (namely the balance or data on the last 90 days of payment transactions) for a period of 90 days after the first initial access using SCA. The 90-day period is specific to each AISP and is also separate from the 90-day period for the PSU directly accessing its account information. When the period of 90 days has lapsed, the exemption no longer applies and SCA needs to be performed again for the new 90-day period to start. The ASPSP can reset the 90-day counter whenever SCA is applied, regardless of the channel (e.g.  web browser or app) the PSU uses to access its account. Making a payment directly or via payment initiation and performing SCA will not restart the 90-day counter for the purpose of Article 10. Providers, as well as API initiatives where applicable, need to accommodate a counter for these 90 days; alternatively, a response code indicating that the 90-day limit has been exceeded could be put in place.

FCA Approach Document

Application of strong customer authentication in the context of payment initiation services and account information services.

20.24 As noted in the EBA Opinion, it is possible for a PISP and an AISP to issue their own credentials to be used by the payment service user to access the PISP’s or AISP’s own platform (such as an application or website). However, only the credentials issued by the ASPSP can be used to meet the requirement for strong customer authentication. It is open to the ASPSP to allow a PISP, an AISP or another party (such as a merchant or mobile wallet provider) to apply strong customer authentication on the ASPSP’s behalf as part of a bilateral contract or arrangement. We would expect the parties to ensure that the contract addresses the allocation of liability between the parties.

20.46 The EBA Opinion also states that application of strong customer authentication for the purposes of payment initiation (directly by a payment service user or via a PISP) during this period does not restart the 90-day count. Consequently, it will be necessary to keep track of how many days have elapsed since an individual AISP accessed the payment service user’s payment account using strong customer authentication. The EBA Opinion suggests that generation of a response code to indicate when the 90-day limit has been exceeded is an option.

20.47 The intention behind these provisions is to ensure that all AISPs need to ask customers to provide strong customer authentication periodically, in order to prompt customers to reassess whether they still wish to consent to their data being accessed. In our view there is no reason why the AISP and ASPSP cannot agree a process for this purpose (see 20.24). We strongly encourage firms and API initiatives to look for ways to facilitate and to streamline this process to minimise the impact on customers, AISPs and ASPSPs.

17.77 As stated in SCA-RTS Article 36(5), AISPs are permitted to access account information from designated payment accounts whenever the payment service user actively requests such information. In our view, in line with the EBA Opinion, an active request requires the payment service user to be actively viewing the data or executing an action to refresh the data to be displayed. In the absence of the active involvement of the payment service user, access is restricted to no more than four times a day unless more frequent access is agreed between the AISP and ASPSP, with the customer’s consent. Such a bilateral arrangement could also involve an agreement whereby the ASPSP will push information to the AISP, subject to the customer’s consent.

8.3 Other Options for future references.

8.3.1 Option 1: SCA by ASPSP for multiple AISPs

When any of the payment account(s) access given to multiple AISP(s) reach the 90 day SCA limit, the ASPSP will alert the customer, either from within the online banking session or outside of it (e.g. via SMS or push notification), that the specific access is due for ‘refresh’. When the PSU selects multiple AISP accesses for refreshing, the ASPSP will apply SCA within the same session to reset the 90 days re-authentication counter for all the selected AISP accesses, irrespective of whether they are due for a refresh or not. The ASPSP may also notify the relevant AISPs that their access has been refreshed.

The benefit of this option is to reduce the friction of the PSU going through multiple re-authentication journeys with several AISPs when multiple consents are given for the payment accounts of the same ASPSP.

Customer journey

8.3.2 Option 2: SCA by ASPSP for multiple accesses of a single AISP

When the AISP requires the PSU to undergo authentication within or at the expiry of the 90 day period for account information access, the AISP will alert the PSU, within the session or outside the session (e.g. via SMS or push notification) that one or more payment account(s) access with a single ASPSPs are due for refresh. The AISP will then redirect the PSU to the ASPSP where the PSU performs SCA. The AISP will present to the ASPSP other accesses which are subject to refresh for the same PSU (e.g. when access to different payment accounts was given at different times). The ASPSP will then reset the 90-days re-authentication counter for all the presented payment account(s) accesses for the AISP and notify the AISP that they have been refreshed. 

It may be an edge case for the AISP to take the PSU through ‘basket’ authentication, as there may be other ways the AISP could initiate a new authentication, such as enabling the PSU to select all the accounts for the ASPSP and structuring a new consent. 

The benefit of this option is to reduce the friction of the PSU going through multiple separate re-authentication journeys with the same ASPSP.

Customer journey

8.3.3 Option 4: SCA with authentication device shared by AISP and ASPSP

During the initial set up, the ASPSP shares an encrypted unique identifier of the PSU with the AISP. This unique identifier can also be bound to a unique identifier associated with the PSU’s device (e.g. mobile handset)  at the time of setup process and could thus be used by the ASPSP to identify the PSU and serve as one of the factors to support the application of the SCA (1st factor). The PSU’s device could be considered a ‘trusted platform’ for the ASPSP, i.e is the same known device of the PSU that the ASPSP would trust if the PSU was authenticated via its own app/web site. The device would then request the PSU to log-in using a biometric and/or password before being able to use the device for accessing any AISP services (2nd factor). 

The above 2 factors could be used to support the requirements of SCA performed by the AISP on behalf of the ASPSP. This option relies on leveraging existing device hardware and operating system capabilities that the ASPSP may already be relying today to identify the PSU while applying SCA on their own existing channels.

The benefit of this option is to make the re-authentication journey seamless to the PSU. This option is also likely to require a contract between the AISP and the ASPSP.

Customer journey

8.3.4 Option 5: SCA with an authentication service shared between the AISP and ASPSP

The PSU is issued with a digital identity by a shared service (e.g. register with brand x) which also allows the PSU to authenticate via SCA (e.g. login with brand x). When the AISP requires the PSU to undergo authentication within or at the expiry of the 90 day period for account information access, the AISP may alert the customer within the session or outside the session (e.g. via SMS or push notification) when any payment account(s) access are due for a refresh. The AISP will then require the PSU to use this authentication service to undergo SCA for accounts that need to be ‘refreshed’. This action would then notify the ASPSP that SCA has been successfully completed, enabling the ASPSP to refresh access and for the 90 days counter to be reset by both AISP and ASPSP.

This method could be used by a PSU across multiple AISPs and ASPSPs if they all shared the same authentication service. Examples of this option include:

• an ASPSP or TPP providing both an identity service and an authentication service which the other party trusts;
• an independent 3rd party (e.g. Apple or Google) offering an identity service with an authentication mechanism; and
• an ecosystem-wide ‘BankID’ service, as used in the Nordics. 

The benefits of this option is a seamless application of SCA which could also reduce costs for the relying party. This could also enable allow for a single SCA to refresh multiple AISP and/or ASPSP accounts. This option is likely to require a contract between the AISP, ASPSP and/or any 3rd party service. 

Customer journey

8.3.5 Option 6: ASPSP real-time push notifications to AISP

After the initial SCA by the PSU with the ASPSP to set up account access, all subsequent refreshes of data are using the AISP’s API via a ‘webhook’, whereby the ASPSP pushes account data updates (e.g. balances, and transactions) to the AISP in real-time as each change takes place to the account. This method is currently used by several corporates and accounting software providers as a form of ‘direct’ access.

The benefits of this option are first to enable the AISP to provide to the PSU some (or all) of the AIS services in real-time, and secondly is a much more efficient (i.e. less load on networks and servers for both ASPSPs and TPPs) method of transferring data versus polling.

This option is also likely to require a contract between the AISP and ASPSP. It may also need to be used in conjunction with one of the other options above, as the AISP is still accessing the PSU’s account, albeit via a push rather than a pull and the application of SCA at least every 90 days will need to be considered accordingly.

9. Version control