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.

Read more

Blog series: How to enhance EBICS, Part 4 – Every person gets their own bank statement

A large proportion of the data that I get from a bank computer as a corporate client relates to an account. But how can I control, already at the point of access, which of my employees can obtain which bank statements for this data? Controls on the bank’s side can be helpful here.


EBICS regulates the provision and collection of any data via order types and format parameters. The data format relating to the order type ultimately determines the processing options in the EBICS bank computer. However, the actual content of the data provision and collection is not regulated via EBICS; therefore, this can differ from one EBICS bank computer to another, and from bank to bank.

Which EBICS subscriber receives which account information?

The data that employees obtain as EBICS subscribers is usually provided for each customer as a download on the bank computer. Every EBICS subscriber of the customer’s that has the relevant order type receives all the data available for the customer. This also applies to account-related data such as bank statements and interim transactions. When an EBICS data collection is performed, the account authorisation of the EBICS subscriber is not checked, but it is checked when payment transaction orders are submitted in the customer-bank relationship. EBICS itself does not provide for any account details in the EBICS message. Account-related checks and processing depend on the implementation of the bank computer – and essentially also on whether the account details for the data to be provided are complete and the accounts are found.

Account authorisation for obtaining data

In certain cases, an EBICS subscriber should only receive information for certain accounts. An obvious solution would be to provide the data per subscriber instead of per customer. However, because the data relates to the corporate customer, when there are multiple subscribers per customer this leads to redundant data and therefore an increased data volume. Therefore, it is preferable to store the data per customer as usual and control the collection of the data by means of the subscriber’s account authorisation (if the data is actually account-related). In this way, the subscriber always obtains precisely the data for all the accounts for which they are authorised.

It would make sense to also have an EBICS enhancement that allows one or even multiple accounts to be entered in the EBICS request – similarly to entering a time period in the historical request. With this EBICS function, an EBICS subscriber could optionally also obtain data for specific accounts. It is not always important to the subscriber for the account information for all accounts to be up-to-date. A corresponding EBICS enhancement enables a more targeted data collection and ultimately provides the customer with more flexibility when accessing accounts.

Michael Lembcke

Read more

“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

Read more