PSD2

Does PSD2 support fair competition?

PSD2 and the SCA exemptions - tipping the scales of fairness

TL;DR - the Regulatory Technical Standards on Strong Customer Authentication and common and secure open standards of communication (RTS, SCA) set down a series of exemptions from the application of SCA. Communications from the EBA have indicated that banks/ASPSPs have an absolute discretion on how these are applied, countering previous market assumption that a level of parity was expected. This means that banks have control over the availability of smoother / better customer journeys, and can discriminate on whether these are available to third parties (TPPs) integrating with their API platforms.

Context

I have written on the challenges presented by decoupling of identity, and on the lack of clarity on the application of SCA to direct access to data. One further area for consideration is the exemptions to the requirement to apply SCA detailed in the RTS (Chapter III). These are particularly pertinent given that the EBA has started to respond to questions posed on its Single Rulebook Q&A Tool (albeit with a 3-month SLA), particularly in relation to question on the application of SCA exemptions. Of particular note are the responses here and here - to quote;

...as stated in the EBA Opinion on the implementation of the regulatory technical standards on strong customer authentication (SCA) and common and secure communication, EBA-Op-2018-04, June 2018, the payment service provider (PSP) applying SCA is the PSP that issues the personalised security credentials, namely the ASPSP. Consequently, it is also the same provider that decides whether or not to apply an exemption, such as the beneficiary list exemption, and not the AISP or PISP.

Discussion among OBIE participants, and more broadly, had led some to the belief that the application of exemptions would have to be on the basis of parity - simply put that exemptions to SCA would have to be commonly available, and not restricted to a range of TPPs, or indeed an ASPSP’s own application. The responses from the EBA suggest that ASPSPs retain an absolute discretion on the application of an exemption to the requirement to SCA. This is confirmed by the FCA at para. 20.10 of its Opinion consultation paper 18-25, and further at paras. 20.38 and 20.40. 

This creates a competition issue - ASPSPs could favour particular providers, or develop their own applications to which exemptions to SCA were applied, and force customers using other TPP applications to perform the more onerous full SCA every time an interaction was performed. The additional level of friction that this presents may vary - it could involve reliance on device possession and some form of biometric, meaning a less frictional process, as the customer would only be required to be redirected to their banking app and used a fingerprint or facial scan service. However, if ASPSPs continue to rely on methods such as PinSentry, the experience would result in poor customer acquisition rates. Whatever solution implemented, the additional friction will necessarily result in a poorer customer experience, and business loss for third parties, than if no SCA was required. 

The exemptions

The competitive disadvantage facing TPPs becomes clearer when two examples are considered in isolation;

Payment Account information (Article 10) - potentially the most relevant to AISPs, this states that no SCA is required if - provided SCA has been performed in the last 90 days and the information is not being accessed for the first time - an AISP access balances, or transactions from the last 90 days. The implications of this are significant if applied inflexibly. 

a. It means that an ASPSP could force an AISP to push the customer to SCA every time account information was accessed, effectively killing the concept of a long-lived consent. Even the simple use case of being able to ask Alexa for balance and get an immediate response would disappear.

b. At para. 2(b) of the article the need to re-authenticate any account information consent every 90 days is generated. This is potentially damaging for all participants. Customers are forced to perform SCA for every integrated service, with every ASPSP they have an account with, every 90 days. If a customer had 7 integrations with 3 different account providers, this would mean an additional 63 SCA journeys every year just to maintain service, over and above the 21 SCA journeys they had to perform to create the service integrations in the first place. The casual observer might suggest that continuing access to a TPP application should serve as sufficient indication of the customer’s intent to allow data access, particularly in view of the obligations on both TPP and ASPSP to implement dashboards allowing the customer to revoke access at any time. To perform this SCA they will need to be in online coverage - if a renewal date occurs when they’re out of coverage for some reason, then the service would cease. For a sole contractor whose accountant lost the ability to complete a tax return due to cessation of data access, this could be costly.

From the TPP and ASPSP point of view, both will be forced to manage an exponentially increasing number of transactions purely to ensure the continuation of a service already agreed to.

A very compelling argument against this requirement is when we compare this with a payment initiation journey. If a customer consents to any kind of future dated payment, whether single or recurring, beyond the point of initial consent authentication, they will never be asked again whether they remain sure for the payment to go ahead (single) or continue (recurring). From a risk point of view, it is illogical to require reconfirmation every 90 days that a TPP should continue to have access to balance information, but not to require any confirmation that they can continue to debit an account.


Trusted Beneficiaries (Article 13) - this prescribes that (1) trusted beneficiaries can only be added by the PSU through the ASPSP interface (i.e. not via a PISP) and that (2) SCA need not be applied should a payment be made to a trusted beneficiary. Para. 1 is interesting - whilst PISPs are allowed to initiate payments using SCA, they are not allowed to create, or even access a list of trusted beneficiaries. In this response, the EBA made clear that ‘A list that is accessible to a PISP or to an AISP in write mode does not fulfill the requirements of the exemption under Article 13(2) of the Delegated Regulation.’ As with the application of SCA, the ASPSP retains complete control of trusted beneficiary management.

This exemption is potentially extremely powerful. If applied correctly, it could enable the Amazon 1-click model, with an extremely smooth authentication journey and overall customer experience. It could empower the variable recurring payments (VRP) model, essential for so many business cases in the PISP domain. It is widely recognised that this is the most enabling functionality of payment initiation, so giving ASPSPs an absolute discretion on how it is applied, particularly when they have complete control on the creation and management of trusted beneficiaries, is at odds with the goal of enabling competition. In a worst case scenario, a bank might not enable this service at all - given the implications of PSD2 on e-commerce, the impact of this could be catastrophic for online transactions. 

The compelling argument for a blanket application of the exemption (subject to transaction risk analysis) stems from consideration of customers, as opposed to the legislation. When a customer goes through the relatively laborious process of creating a trusted beneficiary, they are doing so to enable an easier journey with less friction, when they make payments to that account. This is likely the result of some form of  relationship of trust, as would be the lodging of a payment token with a PISP through an initial, SCA-based consent journey. If the ASPSP doesn’t apply the exemption for any TPP which the customer has been through these steps to add as a trusted beneficiary, it doesn’t respect the will or authority of the customer to manage their account, suggesting that, as the provider, it knows better. This is particularly pertinent should the ASPSP not require the customer to perform SCA when initiating a payment to the same beneficiary using the ASPSP mobile app or website. This preventative approach, or failure to improve customer journeys through innovation, is exactly why PSD2 was enacted, so to allow it to continue is counterintuitive. It is additionally confusing given the statement of the EBA in their response to this question, where they state that the regulation does not distinguish between payments the PSU initiates through a PISP, or those they do directly. If this were truly the case, the regulation would not leave open the possibility of an ASPSP making this distinction for reasons of competitive advantage.


Conclusion

The SCA exemptions provide for better customer outcomes in certain circumstances, but giving absolute discretion to ASPSPs on whether they are applied has the potential to damage fair and open competition in the marketplace. At this stage, it is very unlikely that the wording of the articles governing the exemptions will change. Whether or not they impact the degree of competition on the playing field of open banking will depend on how they are approached by ASPSPs in market. Whilst it is hoped that they will approach the fintech participants in a manner of openness, equality, fairness, and  prioritising the interests of the customer (which they advocate publicly) - it is clear that the success of open banking shouldn’t have to rely on ASPSPs’ goodwill to achieve the outcome of a competitive landscape, which is central aim of the regulation which governs them.