XS2A without third-party providers – well, why not?

As part of the PSD2 an interface for third-party service providers (XS2A API) was introduced across Europe. As the initiator, the EU aims to open the access to the customers' bank accounts to third parties and thus wants to promote competition in the market. By the due date on 14/09/2019 the XS2A API was put into operation by the financial institutions in Europe. Since then, market participants have been reorganising, adjusting the XS2A API to the needs of stakeholders and working intensively on services for both consumers and companies.

As a regulatory must-have, the XS2A API is initially a cost factor for financial institutions. However, value-added services have been considered right from the start and have already been specified by the Berlin Group, for example, in order to provide financial institutions with a source of income. But in the current API hype there are no limits to the fantasies about the sources of income.

So we are riding the hype wave for now and imagining the XS2A API as an alternative access channel for companies. And why not? From a technical point of view, the hurdles should be low. A company could identify itself as a third-party service provider by means of an eIDAS certificate. The certificate would only differ in the specific fields for third-party service providers. Similar to EBICS, submitted orders or enquiries can be provided with a signature which the recipient can use to check the integrity of the message. A secure transport channel is guaranteed by the use of TLS.

From a business point of view, you can use the use case "Initiate payment" to execute both individual and collective payments. For the release, consumers are offered the usual authorisation procedures known from online banking (e. g. photoTAN, pushTAN). This would probably be unsuitable for companies. Therefore, the use of corporate seals would be more likely, which has to be specified. The query of account information (balances, transactions, details) is also possible via the XS2A API. In this particular case, where a relationship of trust exists between the company and the financial institution, the consent required for this could be given via a permanently valid consent.

Seen from an average vantage point, the XS2A API would thus be a valid alternative, which is already being considered in various forums. Here, the idea is assigned attributes such as "cheaper, more convenient, real-time capable and more flexible in adjustments". However, the status quo brings us down to earth. The defining specification of the Berlin Group gives the financial institutions a lot of freedom to implement the API. In the effort to reach all financial institutions in Europe via XS2A, this freedom is currently a challenge for all market participants. A state that is not inviting for companies, not yet. However, the foundation for an alternative has been laid.


Author: Christian Wenz