PSD2: Is Open Banking suffering from API sprawl?

By Andy Mills, VP of EMEA, Cequence Security

One in nine UK citizens now use open banking, with payment volumes doubling during the first six months of last year, according to the Open Banking Impact Report. But provider adoption has not been as fast paced as expected, despite the Payment Services Directive (PSD2) aims to improve authentication and regulate third parties. Contrary to expectations, the market has morphed, resulting in fragmentation and jeopardising the viability of PSD2 to the extent that the European Commission felt compelled to step in, publishing its findings in a report on the application and impact of PSD2.

What’s of particular interest is the report’s analysis of how application programming interfaces (APIs) are integral to authentication and enable access to the back-end data required by open banking services. APIs have seen a move away from screen scraping, which made it difficult to determine who was accessing the account and made it much easier to provide richer data sources. However, the way the industry has chosen to implement APIs is now cause for concern.

A damning verdict

The report describes how “APIs vary greatly from bank to bank, even though they sometimes claim to use the same standard” revealing a lack of cohesion and cooperation in the market. It goes on to say many of these APIs sometimes “do not work properly. For example, third-party providers often do not receive the correct status feedback for scheduled PISP (Payment Initiation Service Provider) payments,” and some say regulators have failed to act on deficiencies in APIs which is then preventing them from providing services which they should be able to offer under PSD2 regulations. Ultimately, it concludes that “the availability of APIs remains patchy, the scope of the data being accessed remains unclear, and the eIDAS certification’s reliability is inconsistent across the EU.”

PSD2 sets a performance criterion for APIs, but the standards used are left up to the industry and far from facilitating access, resulting in interoperability issues. Banks are free to adopt different API standards and modify them, which results in multiple variants of a standard API. When a third-party deals with these banks, they then need to set up unique connections, which is a resource-intensive process. This has given rise to aggregators who build a single API on top of multiple APIs and then market this to the third parties, a solution that the report concedes has come about due to “the absence of a PSD2 API standard and the large number of APIs”.

Two-tier system

The emergence of Premium APIs has made the situation even more complicated. These enable the provision of AIS (access to transaction data) or PIS (the ability for third parties to initiate payment). However, they can result in unlicensed third parties obtaining access to similar data to licensed APIs that comply with PSD2, effectively undermining the standard. In addition, unlicensed third parties can even use a license-as-a-service offering from an aggregator to offer AIS and PIS. This creates an “uneven playing field” that sees two parties providing the same service under different conditions and potentially sees the unlicensed party at a competitive advantage because Premium APIs can offer services beyond those defined in PSD2.

A survey conducted for the report found that 58% of those questioned favoured of a global API standard to facilitate payments, with only 9% against it. But the quantitative data differed from the qualitative interviews that were also carried out. That research revealed that the move to a single API standard was viewed as contentious for numerous reasons. It was feared that it could stymy innovation and prevent banks from developing their interfaces. It was viewed as too late in the day to introduce and while there are several competing API standards these have limited rather than impeded progress. Others suggested the market needs to be opened up commercially to allow Premium APIs to take over and compete to create de facto APIs. This makes sense given that some are finding the PSD2 requirements too restrictive in terms of the access provided and so have continued to scrape data that is less secure. However, the problem of unlicensed third parties being able to connect to banks would still need to be addressed.

The need to add carrot and stick

If we look at the business model for API development, the problem we have today is that there isn’t an incentive for banks to invest in well-performing APIs which means we won’t see security continue to improve. Account Servicing Payment Service Providers (ASPSPs) i.e., banks are the ones that must invest in APIs to provide access, whereas the third parties effectively get access to that data for free. With no financial incentives, lax enforcement and the regulations themselves open to interpretation, it’s no wonder banks are choosing to “limit or at least complicate access to their data” and that third parties are reporting implementations have “mostly been poor [by banks] … with a significant number of obstacles built in.”

While the jury may be out on whether a single standard is needed, what is clear is that the current model isn’t working, and the sector is suffering from API sprawl due to fragmentation of the standard. Failing to provide banks with a reason to improve API connectivity is causing third parties to rely on aggregators and the whole system has enabled rival offerings to flourish, resulting in unlicensed providers and non-standard alternative APIs that offer more functionality. Consequently, we can expect the European regulators to take matters in hand this year. They’ll actively seek to explore how they can get PSD2 back on track and so all the providers involved should prepare for the regulations to become more stringent and to be rigorously enforced.