API authentication during PSD2: Towards an inclusive approach

The PSD2 API Evaluation Group recently released an “Authentication Guidance” document talking about redirection, embedded and decoupled approaches; what is that about? 

The API Evaluation Group (API EG) had discussed the various authentication methods and processes in use today and felt the need to clarify the differences and recommend that the API initiatives should support them all, rather than prescribe just one.

What are the differences between redirected and embedded authentication?

Redirection means that users, when shopping online and wanting to pay by credit transfer, are redirected to the website of their bank, or more generally their Account Servicing Payment Service Provider (ASPSP), to enter their credentials there to authenticate and then click through pre-populated credit transfer screens to authorize the payment. The best known examples for that are iDEAL, MyBank, P24, PayU, giropay, eps, etc. These are not Payment Initiation Service Providers (PISP) in the sense of PSD2, because the process is only half-automated, i.e. users are controlling the flow and essentially initiating the payment themselves. So there is no PSD2 license required to provide or use such services.

Embedded authentication means that the process if fully automated and the payment is therefore initiated on behalf of the user. To enable this, users have to share their credentials with a third party provider (TPP), who then authenticates and initiates the payment in the background, i.e. embedded into their interaction with the ASPSP. Prominent examples of such TPPs are Sofort, Trustly and InstantTransfer. To strengthen the security of such services, in particular de-risking the credential sharing, it was decided to bring such TPPs under the PSD regulation and PSD2 was born. So now any PISP, in the sense of PSD2, has to proof their security standards and processes to obtain a license and is then supervised and audited on an ongoing basis. They are not allowed to store the shared credentials and have to identify themselves vis-à-vis the ASPSP, which therefore can and must refuse access by any non-licensed provider. PISPs are liable for any wrong doing within their remit and have to take out an insurance to cover any potential damage. In addition, PSD2 requires strong customer authentication (SCA), e.g. the use of an additional one-time-password as a second factor to disable fraud even if the shared credentials were compromised for some reason.

What is decoupled authentication then; is that a middle way?

No, decoupled means that the second factor of the authentication is decoupled from the first one and can therefore be provided on a different device. This is necessary if a credential cannot be transmitted, e.g. biometrics, and for many new payment devices, e.g. wearables. Therefore, decoupled is not a different third approach, but a variation of the other two.

Decoupled-redirect means that the user is redirected to the ASPSP for identification and simple (first factor) authentication, but can then use a fingerprint via the ASPSPs mobile app as the second factor.

Decoupled-embedded means that the user shares their static credentials with the TPP to handle everything on the payment device, but can then still use a fingerprint via the ASPSPs mobile app as the second factor.

But were APIs not meant to end all the screen scraping and credential sharing?

I guess many banks were hoping so, but this is a misunderstanding. Direct access via the online banking user interface – using screen scraping – and indirect access via a TPP-dedicated interface – using an API – are about how the customer data is accessed, whereas redirection vs. embedded is about how the customer is authenticated. So, please don’t mix up the terms indirect and redirect, they are two completely different kettle of fish in this context.

Why has this been such a hot topic at the API EG?

The pros and cons of credential sharing have been a hot topic for all the years and it is arguably the main reason for revising the PSD as I described above. PSD2 and the RTS are now regulating it and TPPs – if licensed – cannot be prevented from using the credentials of users consenting to it.

Nevertheless, several countries, in particular many of those, which did not have PISPs up to now, were using iDEAL as their role model and thereby planning to impose the redirection approach when designing their API standards. UK Open Banking being a prime example of that.

No doubt, many customers may prefer a redirect type service to avoid the sharing of their credentials, but many others may prefer the increased convenience of the embedded approach. 

This is not about which way is better, but about providing choice. A good TPP should offer both and also the decoupled variants in addition. And a good bank should also support all these to cater for all preferences. Consequently, the API initiatives must support all methods to enable that.

Talking about UK Open Banking, are they ahead or behind the game compared with PSD2?

Both. I think there are many things they got right, but also many they have wrong. There are of course advantages in a centrally managed, very prescriptive, almost scheme-like model, but there are also downsides to that. PSD2 is deliberately staying away from prescribing too much to allow for competition at many levels and a more future proof flexibility.

Making them compatible, i.e. making UK OB compliant to PSD2 is quite a daunting task I think. As it stands, I would compare UK OB more to iDEAL or Vocalink’s pay-by-bank app. It offers redirection only, i.e. TPPs cannot wrap their own service around it and have very little room for innovation and to differentiate themselves from each other.

I can’t understand, actually, why UK OB requires a PSD2 license at all at the moment. Why should a fintech get burdened with obtaining and sustaining a license and holding expensive insurances for providing a service in the UK, which they could do without in the Netherlands or many other countries in Europe?

UK OB is trying to argue that redirection – if done well – is not necessarily an obstacle, as prohibited by the RTS. I think this is flawed, because it assumes that all customers have the same preferences and would want what they call “positive friction”, i.e. going through some extra steps in the payment flow to be more on the safe side. I think the opposite is true. Rightly or wrongly, many if not most customers prefer convenience over safety and the extra steps don’t even add safety, but rather more risk.

Their view is misguided by customer surveys asking the wrong questions and a false perception of phishing risks. Asking questions like “would you prefer a 1-click payment” instead of “do you like to share your credentials” would have given a completely different outcome. And the main phishing problem today are not fake TPPs but fake bank websites, so that redirecting users to another website will not lower, but increase the phishing risk and user concerns.

In addition, without enabling the decoupled-embedded approach their API could not support PISP use cases at the point of sale or using wearables or voice AIs like Alexa, where there is no way to redirect the user to the ASPSP in any form. Hence this is not just creating obstacles, but actually road blocks.

If the embedded approach is not enabled by the time the RTS goes live in September next year, I think UK banks could be obliged to use another API standard to be PSD2 compliant and certainly to attract the TPPs needed to qualify for the exemption from providing a fallback to their online banking user interface.

What exactly is the API EG now recommending?

The common ground across all parties represented there is the customer. Therefore, at the end of the day it has to be the customer view that must be taken in all these discussions and that is where the often different interests of TPPs and banks do meet.

We have to ensure that customers will see bigger and better TPP services and certainly no less than what is available today. This means more choice, not less choice and more options, not less.

To allow ASPSPs as well as TPPs to prove that APIs can do better than screen scraping, the API standard initiatives should provide the broadest set of functionality they can provide and this includes the various authentication methods and processes available now and foreseeable in the near future. This is what the API EG recommended in this document.

It is then up to the individual ASPSPs to choose which functionality they will implement and whether they would like to take a minimalistic approach to just be compliant or offer the whole range and thereby maximise the potential for their – and the TPPs’ – customers. 

About Ralf Ohlhausen

Ralf Ohlhausen, MSc in mathematics and Master of Telecommunications Business, has over 25 years’ experience in ecommerce, financial services, mobile telecommunications and IT. Before joining PPRO Group, he was President Europe at SafetyPay. Other management positions on his international career path took him to Digicel, O2, British Telecom and Mannesmann-Kienzle. At PPRO, Ralf is responsible for increasing PPRO’s global reach, focusing in particular on the addition of new payment choices to the company’s portfolio.

About PPRO Group:

Cross-border e-payment specialist, PPRO Group, (PPRO) removes the complexity of international ecommerce payments by acquiring, collecting and processing an extensive range of alternative payments methods for Payment Service Providers (PSPs) under one contract, through one platform and one single integration. PPRO supports international payment methods across more than 100 countries, allowing PSPs to expand their merchants’ ecommerce reach, arrange hassle-free collection and achieve higher conversion rates.