Why banks should phase out older versions of EBICS

Do you have any idea how many versions of EBICS are available? Do you know the status of your EBICS client? Which versions does the banking server allow? This article summarises the situation and explains how a proliferation of versions affects users.


EBICS came into official use in Germany on 1 January 2008, with version 2.3. Before that, some financial institutions had offered EBICS services using version 2.0 onwards. The first version developed jointly with France was 2.4, of which the final release 2.4.2 has been in use since 16 February 2010. The latest version of EBICS is version 2.5 of 16 May 2011, which is mainly offered by financial institutions in Germany and Switzerland. A new version 2.6 is currently being prepared likely for 2016. If we count all the versions that have been released and for which there have been implementations for banking servers and client systems, we come to a total of six (not including 2.6, which is yet to come).

Customers and banks need to use the same version of EBICS

The EBICS protocol is based on XML structures. New EBICS versions are characterised not only by new features and changes to the content, but also by a new version of the XML schema. Using the HEV job type based on the neutral H000 schema version, EBICS client systems can query the versions supported by the banking server, and when compatibility is established, continue communicating using the latest shared version. This means the EBICS banking server and the EBICS client system can only communicate without errors if their dialogue takes place using the same EBICS version. If too many versions are supported, there is a greater risk of the communication partners not having the same version. Data could not then be exchanged.

At the very least, an EBICS banking server which always supports every possible EBICS version would need a lot of maintenance. As well as this, all the improvements in new versions, including important security functions, would be undermined by the use of older versions. For this reason, when EBICS was specified it was agreed that banks should only have to support the latest EBICS version and its immediate predecessor.

Updates are missed – and that poses risks

In practice, things can be different. Partially through unawareness, customers fail to update their EBICS system to the latest version. Banks fail to notify their customers and continue to allow them to use older versions of EBICS. They lose track of the situation and the risks described above increase.
This is why we recommend that financial institutions keep an eye not only on their own EBICS versions but also the ones used by their corporate customers, and remind their customers to update them in good time. The financial institutions should deliberately stop supporting older versions and even phase them out completely. Corporate customers themselves should make sure they always have the latest EBICS software versions and plan regular updates.

It is important to keep track of the EBICS versions used and to minimise the risks by regularly updating. Because next year, probably it will be time for EBICS 2.6.

“EBICS as a service” – An operating model for small and medium-sized financial institutions

It is actually undisputed that EBICS will establish itself as a transaction banking protocol in Switzerland. Major banks and larger cantonal banks already offer EBICS or are in the process of implementing an EBICS interface for their business customers. The next step would be a shared-use "EBICS as a service" platform, for which there is currently no provider.


The advantages of secure, standardized, and cost-effective point-to-point communication are so apparent that the topic is now cropping up on the agendas of even small and medium-sized financial institutions. Depending on the particular institute and the number of customers to be connected up to EBICS, the management of some banks consider the initial costs for purchasing, installing, and running an EBICS product to be prohibitive.

Product providers should take these concerns very seriously, especially when we consider that implementing an EBICS project entails costs on a five- to six-figure scale, which accounts for a sizeable chunk of many smaller banks' budgets. Particularly in Switzerland, where there are around a hundred institutes in this segment, such as smaller cantonal and private banks, the following question arises: Why is there no provider offering "EBICS as a service" yet in the local market? Shared use of an EBICS platform actually has clear advantages, and there are also providers in the market who seem ready-made for the role and would be capable of getting such an offer off the ground.
A multi-client enabled EBICS model could be implemented along the lines of outsourcing services for operating banking platforms. Once even a small number of bank participants are on board, the business case pays off, resulting in a win-win situation for everyone involved. The provider of the solution can present an expanded service portfolio to the market while quickly recouping the initial investment costs as use of the standard grows and spreads. Customers, in this case banks, can offer their business clients access at low investment costs and reduced operating costs, allowing them to catch up with the big banks in terms of the connectivity opportunities they provide.

What else is needed? Well, the right product of course, one that is designed for multi-client operation and that is optimized for running in data centres with respect to operating functionalities. Furthermore, an innovative banking IT solutions provider who is ready to be first into the breach is also required. As mentioned above, there are a few candidates in Switzerland, including the operators of Avaloq or Finnova solutions, classical data centres, and the insourcing solutions of larger institutes.

We are curious to see who will seize this opportunity in the Swiss market.

Carsten Miehling