EBICS security – when is the time to update your customer system?

With EBICS communication, various security features and regulations are specified that must be adhered to by customers and financial institutions alike. The financial institutions must always ensure that the current specifications are available and supported in their EBICS bank server. EBICS customers themselves and each individual EBICS users are, however, also responsible for ensuring the use of customer software that is continuously up to date and that meets the current EBICS security standards. It is therefore paramount both due to functional adjustments and for security reasons to frequently update the software of the EBICS client systems.

Once an existing EBICS client software has been brought up to date via updates, however, it does not mean that the EBICS software in question automatically starts to communicate with the financial institution using the most recent EBICS version and the latest security procedure. Depending on the previously used EBICS version and client functionality, this requires an update of the various application keys for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006) and of the new EBICS version to be used, followed by an exchange of this data with the EBICS bank servers. It may also be necessary to update the Internet encryption (TLS) to a more recent and secure version by means of a renewed certificate exchange. Such updates usually require a proactive approach and manual adjustments by the EBICS user.

Why are these updates important?

EBICS communication via the Internet has its own specifications for security procedures. The EBICS society continuously updates and adapts them to current security requirements by means of new EBICS versions. One example are key lengths. Older EBICS versions still permit key lengths of 1024 bits for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006). That length no longer meets the current security requirements as too short key lengths are considered unsafe. Newer EBICS versions only permit keys with a minimum length of 2048 bits. Another example is evident in the procedures and versions of the TLS encryption that are in use. To be able to follow security recommendations such as the ones by the BSI in Germany more flexibly, the EBICS society has created a separate annex of the EBICS 3.0 specification called Transport Layer Security, which contains the respective guidelines. As the EBICS 2.5 specification could not be adapted retroactively, the DK (Deutsche Kreditwirtschaft) has additionally issued its own recommendation document in 2019 titled Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen (recommendations on EBICS security procedures and key-lengths). It contains information on the security procedures to be used in EBICS communication. See also www.ebics.de and www.ebics.org.

To allow EBICS users a smooth transition to newer EBICS versions and security standards, most financial institutions still offer their customers the older procedures in parallel with the new ones. Unfortunately, it has become clear that in many cases this leads to customers not taking the opportunity to update their EBICS communication. Many keep using older systems and procedures. This, in turn, makes it hard for the financial institutions to discontinue those old procedures.

In the end, every participant in EBICS communication expects a secure data exchange to be ensured. Nobody wants to sustain losses. Which means that everyone should take care to contribute their part. Of course, EBICS security is not the only thing financial institutions need to keep an eye on. Ultimately, all parties involved must take all possible security measures in their infrastructure and software solutions to prevent misuse and losses.

So why wait any longer? Let's do this.

Author: Michael Lembcke

Read more

Open banking: EBICS versus API

Open banking is one of the mega trends that many banks supposedly risk missing out on. As hardly any PSD2 interface seems to be market-ready, the banking supervisory authorities have granted a transition period until December 2020. However, the problem is elsewhere: many institutions are not too keen on spending their money to make the lives of open banking interface providers easier – especially considering that established protocols like FinTS and EBICS have much more to offer than has been brought to the table by the "APIsation" of banking so far.

Both protocols, FinTS and EBICS, already cover almost all areas of banking, from payment transactions and securities trading to credit business. Overall, far more than 200 processes are available which bindingly describe both the business interfaces and the technical communication between the participating partners. HBCI and FinTS have been leading the way regarding open standards in communication with financial institutions since the 90s. EBICS was introduced by the Deutsche Kreditwirtschaft (DK), or its predecessor, more than ten years ago as a binding standard for communication with corporate customers. Open banking has thus been a reality in Germany for many years already.

No uniform PSD2 interface in sight

As good as the idea of open banking may be; the debate forced by PSD2 (among other things) leaves many financial institutions at a loss, including the willing ones. On the one hand, PSD2 is supposed to bring about an open banking standard for all of Europe. Then again, legal authorities have deliberately left open the question of how exactly communication should take place and how it should be secured. As a result, providers of open banking APIs are urging the banks to implement their solutions and adopt their own interpretations of open banking, just so they won’t be left behind. On top of that, various initiatives in various countries are developing protocols for technical/business application aspects, which is bound to lead to an uncontrolled number of API dialects. Cross-country concepts, on the other hand, are still a long way off.

All of this could develop into a bottomless pit for the institutions unless a uniform PSD2 specification that every bank can follow becomes available soon. As long as this does not happen, many open banking dreams will likely remain unfulfilled. After all, by law, the opening must be free of charge and free of discrimination. Earning money with it is for others. So what should be a bank’s motivation to keep adding new API dialects free of charge, just so that third-party providers can more easily spread their apps among the people? This would reduce the institutions themselves to the status of mere service providers. It is much more reasonable to fall back on long established standards.

EBICS: open banking for corporate customers

One such standard is EBICS. It is widely spread: aside from Germany, EBICS is also popular in France. A cooperation agreement exists between the Deutsche Kreditwirtschaft and its French counterpart, the CFONB. These two largest payments markets in the Euro zone use EBICS for the corporate customer and interbank business. Switzerland (SIX) is also a fan of EBICS, and Austria (STUZZA) is thinking about joining in. Instead of drowning in the API swamp, the question should be how EBICS can be expanded to comply with PSD2. And the answer is: with a remote signature (see Fig. 1). A modern EBICS portal can generate the signature from incoming data such as the code of a PhotoTAN or a QR TAN using hardware-based methods and send it to the EBICS bank server.

Fig. 1: How remote signatures expand EBICS towards a PSD2 compliant open banking solution

EBICS offers many advantages for corporate customers. Companies that have an EBICS client can conduct secure multibanking and also use the electronic distributed signature (EDS). This enables the use of roles and rights concepts (T, A, B and E signatures) to determine, for example, whether submitted payment orders originate from authorised persons and whether the respective person has the appropriate rights to release these payment orders. Similar to FinTS, the following also applies for EBICS: the necessary infrastructure to implement open banking already exists. For this reason alone it is understandable that many institutions are reluctant to invest at the moment. There is no guarantee that they will choose the right API provider or that legislators will not issue new regulations that will render existing investments obsolete.

Author: Michael Schunk

Read more