Tips for a smooth transition to EBICS 3.0

EBICS 3.0 has been officially introduced at the financial institutions since November 2021 and can be used by corporate customers. In addition, the last previous version is still valid. One of the changes in EBICS 3.0 concerns the omission of the three-digit order types or the FileFormat parameters in France for operative business transactions. These are now mapped via the so-called business transaction formats (BTFs). BTFs include eight parameters each: Service Name, Service Scope, Service Option, Service Message Name, Service Message Name Version, Service Message Name Format, Service Message Name Variant and Service Container.

Within a customer agreement, it must be possible to take into account the central agreement for the respective business transaction, regardless of the EBICS version. Compatibility and interoperability between the previous versions are predefined for EBICS. If two electronic signatures are agreed for a SEPA credit transfer, it is irrelevant, for example, whether submissions for this are made via BTF, order type or FileFormat parameter. This condition requires an internal mapping of old and new business transactions in the bank server and possibly also in client systems. So far, these mappings have been officially specified for the standard business transactions.

The processing upstream and downstream of EBICS at the financial institutions and at the corporate customers is generally still based on the previous EBICS IDs, such as the three-digit order types and in France on the up to 40-digit FileFormat parameters. As long as a mapping exists, there is no need to change anything. However, what if no more order types/FileFormat parameters are specified for a business transaction and the business transactions apply exclusively with BTF? If one does not want to adapt one's adjacent processing operations to the BTFs, a mapping can of course be retained. For the unspecified mappings, however, custom suitable IDs should then be defined.

In external relations in the customer-bank relationship, it should be noted that the customer or client system is informed of the bank server's specifications regarding business transactions and mappings in various ways. In addition, the different representations from the point of view of the customer, participant and time come into play. A participant always uses a specific EBICS version, while the customer agreement must map all valid versions. In addition, the time of the information plays a role. For example, before the EBICS user is initialised, the financial institution usually does not know which EBICS version the user will use.

The BPD sheet (BPD = bank parameter data), which is created in the bank server when the EBICS user is set up, must therefore map the options of all supported EBICS versions including any BTF mapping specifications. The same applies at least to the order type HKD, with which the client-level agreements can be retrieved by the client. If mapping is no longer offered for certain business transactions in the customer-bank relationship, irrespective of internal use, the information should represent the mapping accordingly exclusively via BTF. For internal administration and maintenance, it is helpful if the individual IDs used exclusively for internal purposes are visible in an internal mapping (e.g. individual order types with their own BTF mapping), but are different from the external IDs. 

In summary, the challenge is to make the transition to EBICS 3.0 as easy as possible for all parties involved with the new variety of information. However, with the right configuration and by observing a few guidelines for operation, the migration to the new EBICS version is not difficult at all. If you need help with the migration to EBICS 3.0 or have any questions, please do not hesitate to contact us.

Author: Michael Lembcke

Read more

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

Read more