API opens doors for banking applications

The abbreviation API seems to be everywhere at the moment. The three letters stand for application programming interface. All APIs are associated with the hope of being able to implement many banking use cases as simply and quickly as possible via a standardised interface. The number of use cases for this is growing steadily. A variety of players are fuelling this development, meaning that APIs could fundamentally change the banking market.

The PSD2 as a focal point for APIs in recent years has led to various initiatives in Europe specifying an access-to-account API. The most important of these initiatives are undoubtedly "The Berlin Group", "STET" and "PolishAPI". But the PSD2 has also had an impact outside Europe. In Switzerland, the "OpenBankingProject" was launched, with its SwissNextGenAPI being based on the Berlin Group's API. In the United Kingdom, the "Open Banking" initiative has emerged. All initiatives and their APIs rely on the PSD2, and all are united by the desire for high efficiency gains.

Reality dampens this hope somewhat. The standardisation initiatives described above do exist, of course. However – firstly, there is no single "true" specification. Secondly, banks are not obliged to adhere to the available specifications, either. And thirdly, the specifications grant plenty of liberties in terms of implementation (think implementor options). Now if a market participant, be it a bank or a third-party service provider, wants to use the banks' access-to-account APIs, they face a challenge. PPI has taken on this challenge and with the product TRAVIC-Payment-Client-API created a library that conceals the outlined heterogeneity behind a single interface. By using TRAVIC-Payment-Client-API, risks can be minimised and development time reduced while connecting the banks' access-to-account interfaces. The product is in productive use at Atruvia AG. Read more about this and how Atruvia AG has benefited from it at (https://www.ppi.de/banken/success-stories-banken/success-story-atruvia/).

From PPI's point of view, it is impossible to imagine payments without APIs. Driven in part by the PSD2, the first steps on the banking side have already been taken. But it will likely not stop there. The Berlin Group has long since specified the openFinance API framework, which extends the use cases of the access-to-account interface. As far as we know, further extensions to the specification are planned for 2022. These value-added services, which are of course provided via APIs, are being offered to an increasing extent on the developer portals of major banks. Some of these APIs are no longer only aimed at third-party service providers, but also directly at companies. This makes it clear that the topic of APIs is not limited to PSD2-relevant use cases, but will increasingly establish itself as an independent channel for different stakeholders. Consequently, there will probably be other APIs in addition to EBICS, FinTS and access-to-account sooner or later.

The Berlin Group is not alone in its API activities. The European Payments Council (EPC) has set up a working group for the European sphere to develop a rulebook for accessing SEPA payment accounts via APIs (https://www.europeanpaymentscouncil.eu/news-insights/news/call-candidates-sepa-payment-account-access-multi-stakeholder-group-spaa-msg), in which PPI participates. Furthermore, in the recently published announcement on the "SEPA Request to Pay scheme rulebook 2.0", the EPC even stated that the exchange of SRTP messages via APIs will be mandatory in the future. 

There is lot of movement in the market, but one thing is clear: the list of existing and future initiatives around APIs is long, and a number of innovations are conceivable in this environment. PPI has taken the first step with the product TRAVIC-Payment-Client-API and offers it particularly as a service. In addition, PPI is designing further offers around the topic of API.

Author: Christian Wenz