It feels like a long time since we started working on the second financial services directive (PSD2). Even though the directive officially comes into force in January 2018, many important details still have not been finalised.
Most significantly, the regulatory technical standards (RTS) for banking APIs, which Third Party Providers (TPPs) will use to interface with customers’ accounts are not yet available. There will actually not be a single prescriptive standard anyway, but the most debated PSD2 RTS will at least define some high-level principles, when it will finally be published towards the end of this month. This RTS will have a huge impact on the future of European fintech. Here’s my vision for banking APIs under PSD2.
As good an experience as the customer could possibly get
The fundamental principle that must underlie how fintechs work with banks in the future, is that the new regulations brought in by PSD2 should not hurt the customer experience. For this to happen, the bank APIs must work as well and allow TPPs to offer as good an experience as the customer would get if he or she used the bank’s own services directly.
For this to happen, the API shouldn’t place any restriction on how TPPs design their customer experience, over which they should have complete control from A to Z. The API must also be device-agnostic, able to work as well on a POS terminal, wearable, smartphone or tablet as they do on a PC. Among other things, this means that the API can’t force a redirection to the bank’s website as part of the authentication process.
Technology must not become a barrier
Redirecting to the bank’s website isn’t the only way in which the API could enable banks to erect barriers that effectively shut out fintechs. If API specifications permit banks to implement and insist on non-standard authentication processes — this can also shut TPPs out, and this applies especially to strong customer authentication methods.
Similarly, the bank should not incorporate a redundant layer of consent management in its API. The regulatory standards should leave consent management for their services with the TPP, supervised by the national competent authorities, rather than allowing banks to arrogate this supervisory role and thereby giving them the opportunity to discourage customers from using third parties. Not to do so would completely undermine the TPP’s ability to provide a seamless customer experience. Banks should only be able to refuse a transaction if authentication fails or if there is a reasonable suspicion of fraud or other illegal activity.
Nor should the bank be able to limit the role a TPP can fulfil within any single session. Under PSD2, third-party providers can be both account information service providers (AISPs) and payment initiation service providers (PISPs). The former aggregate customer transactions from many accounts and provide extra financial intelligence. The latter initiate and handle payments on the customer’s behalf.
Many existing and future services require TPPs to act as both a PISP and an AISP and they should be able to, both simultaneously and separately. Anything else would, again, undermine the TPP’s ability to provide customers with choice and a competitive service.
Finally, where a customer has given the TPP permission to access certain data on his or her accounts — for instance, to guarantee the payment to the merchant for immediate delivery — the bank should give the payment provider access to this data without any further and unnecessary complications. This is particularly relevant for banks executing payments in batches overnight, rather than in real time, and where such information is therefore needed for risk management.
The devil is in the technical details
At the eleventh hour, as we are now, it can often seem — particularly to those who aren’t technical specialists in the field — that the great bulk of the hard work has been done. It is tempting to believe that what remains is merely a tidying exercise, allowing us all to sit back, take the pressure off, and relax.
In this case, that could not be further from the truth. How Regulatory Technical Standards say the banking API will work — and even what it doesn’t specify — is absolutely fundamental to the future of fintech in Europe. Get it wrong, and in a very short time there may not be much of an industry left to regret the error.
About Ralf Ohlhausen
Ralf Ohlhausen, MSc in Mathematics and Master of Telecommunications Business, has over 25 years of experience in ecommerce, financial services, mobile telecommunications and IT. At PPRO, Ralf is responsible for increasing PPRO’s global reach, focusing on the addition of new payment choices to the company’s portfolio.
About PPRO Group
Cross-border e-payment specialist since 2006, PPRO Group (PPRO) removes the complexity of international ecommerce payments by acquiring, collecting and processing a range of alternative payment methods for Payment Service Providers under one contract, through one platform and one integration. PPRO supports international payment in over 100 countries.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now