PSD2: Step one in the wider API-fication of banking services?
With the January 13 deadline for compliance with PSD2 now in the rear-view mirror, you could be forgiven for thinking that the payment regulation is no longer on the agenda for banks. Far from it. The impact of the next stage of PSD2, regarding third party access, will be even more significant. It might not only affect payments, but banking services in general, says Shahrokh Moinian, global head of cash products, cash management, Deutsche Bank.
By now, the objectives of PSD2 are etched on the brains of all those involved in the payment industry: to better align payment regulation with the current state of the market and technology; to introduce strict security requirements for the initiation and processing of electronic payments; and to protect consumers’ financial data.
Yet the broader impact of a key element of the regulation’s scope – the introduction of so-called Third Party Providers (TPPs) that are permitted to provide certain types of services connected to payments – is yet to be fully appreciated.
With the relevant provisions regarding third party access to online accounts likely to become applicable around September 2019, many banks will now be considering what form that access should take. The use of Application Programming Interfaces (APIs), which allow the products and services of one company to be interconnected with those of others, will likely be a popular route. If so, this may constitute the first step in a broader sweep of API-fication across the banking industry.
API route or direct access?
While the regulation as a whole came into force on January 13, the provisions surrounding the introduction of a third party interface have been delayed by discussions between the European Banking Authority and the European Commission over its content. These discussions have now concluded with a solution that should address the interests of all market participants. However, the relevant provisions face an 18-month implementation period, making them applicable from around September 2019.
In short, banks can establish a third party interface either by means of a dedicated interface – via APIs – or by allowing TPPs direct access through an enhanced webpage which shows only the PSD2-compliant parts. The API option has many advantages, and represents an important step forward in service provision, which could help generate innovative services that benefit customers, as well as the businesses involved. For this reason, industry participants would do well to utilise and exploit Open APIs as soon as they can.
Using APIs would also likely encourage faster take-up by TPPs. It makes business sense for TPPs to adapt to using standardised APIs: this affords them a wider reach than is offered by either direct access or a proprietary interface. Banks could also use standard APIs as a basis for shared services and cost savings – for spreading the cost of testing facilities or of repository or registry services, for instance.
There is a small snag, however. The European Commission has stated that financial institutions offering third parties a dedicated access route via open APIs will also need to set up and maintain a contingency measure in the form of modified direct access. This may make some ask the question: why not simply just adapt the online banking interface which PSD2 requires as a fall-back option anyhow?
The answer could be in the small print. Those that can demonstrate they have fully functional, dedicated interfaces (which satisfy the quality criteria) can be granted an exemption by their competent national regulator from having to maintain the fall-back option. This means that the API-route alone is an option– just as long as it is properly set up and well maintained.
Furthermore, PSD2 presents a chance to test a live use-case for APIs, and therefore seize a head-start in exploring the substantial business opportunities on offer.
The momentum we now see in payments will almost certainly carry over into other banking services. It is plausible that this technology could be used for bank customers to access their stock portfolios, monitor their online securities transactions, or manage their borrowings, for instance. In this environment, the winners are likely to be those exploiting APIs to leverage their existing assets, and possibly collaborating with new partners, to create innovative and convenient new products and services.
The ramifications of this trend will go beyond just Europe. Already, we have seen Japan amend its Banking Act, which, as with PSD2, promotes Open APIs as a means of collaboration between banks and TPPs. Elsewhere, the Hong Kong Monetary Authority is consulting on adopting Open APIs for the territory’s banking industry – seeking feedback on the proposed framework by March this year – while there is also a big push from the regulator to introduce APIs in Singapore.
Clearly, the first step is for APIs to help shape the payments landscape and, to this end in Europe, the whole ecosystem will need to develop further. This is especially pertinent with respect to common standards around APIs, which will be essential for compliance confirmation and take-up by TPPs. The work of the Berlin Group, the only pan-European payments interoperability standards and harmonisation initiative, is crucial in this respect, and widespread adoption of their interface implementation standards should be encouraged.
The ultimate consideration should, of course, be what is in the best interests of customers – after all, the data at the heart of the debate is theirs. We think the API-route offers the best balance between protecting and securely sharing valuable data and establishing an innovation ecosystem that will generate a wealth of exciting new services to benefit them, through competition, as well as collaboration.