Standardisation and automation in external asset manager relations thanks to EBICS

External asset managers (EAMs) offer their wealthy private customers or institutional customers such as pension funds and insurance companies a multitude of services (for example, tax and real estate consulting as well as trading and investment transactions). The customer accounts are usually held at one or more custodian banks. Interactions with the financial institutions are often neither standardised nor automated. Communication by mail, telephone, e-mail and sometimes even fax dominates everyday business.

Few big asset managers have a SWIFT connection and are using it for treasury and foreign currency transactions (message category 3), securities transactions (message category 5), precious metal transactions (message category 6) or cash management transactions (message category 9). Some have implemented proprietary system-to-system connections, for example via FTP, to exchange financial messages. In Switzerland we are currently observing a trend towards EBICS as an alternative connection type for these use cases.

During the PPI Petit Déjeuner in April 2019 in Lausanne, a representative of Credit Suisse presented the offer "Private swift Network (PsN)". It deals with the extension of the EBICS service scope in the sense that about 20 new EBICS order types (reports for download) based on the EAM use cases mentioned above are available. Thanks to their cooperation with leading software manufacturers of portfolio management systems (such as Allocare or Expersoft), Credit Suisse achieves a significantly higher level of standardisation and automation when interacting with their partners. In concrete terms, the SWIFT messages of the above message categories can now also be transferred via EBICS.

As the EBICS protocol is flexible with regard to the content transferred, Credit Suisse additionally offers other formats like CSV or XML for reporting on the transactions and assets, including the master data of the respective customer depositories. All players stand to profit from the new offer: asset managers can connect more financial institutions via EBICS at low cost and automate their processes, software manufacturers can effectively extend their functional scope, and financial institutions can boost their appeal for EAMs. Viewed across all parties and processes, the error rate decreases and the implementation speed increases through elimination of manual operations.

Swiss financial institutions that are currently implementing projects in this area are already planning the next steps of the EBICS offer extension. In addition to the reporting functions (EBICS download), the order functions (EBICS upload) shall also be offered in the future. Especially orders in the trading business (SWIFT message category 5) are well-suited for uploads via EBICS. Particularly stock exchange orders (like SWIFT MT502) shall be transmitted from the asset manager to the financial institution. In the same way as the known payment order interfaces, the stock exchange interfaces are connected on bank side. The use of an EDS is also conceivable in this context.

In conclusion:

The first financial institutions in Switzerland are extending their EBICS offer beyond the use cases of payments. The Credit Suisse offer for medium and larger asset managers paves the way for EBICS in the EAM customer market and will likely prompt others to follow suit. Software manufacturers of portfolio management systems are slowly but surely learning to understand the EBICS protocol and extending their connectivity options with this connection type. When it comes to formats and standards that may be transferred via EBICS in the future, there are no limits to the possibilities. It is safe to say that for a certain customer segment, EBICS presents a viable alternative to the communication via SWIFT even in domains outside of payments.

Carsten Miehling

You are a bank customer and you are using EBICS: Will your EBICS monitoring still work with EBICS 3.0?

Since EBICS 2.5, EBICS clients cannot only use the purely text-based customer protocol but also an XML-based customer protocol for monitoring EBICS processes and results. The XML-based customer protocol is particularly suitable for automated evaluations. For downloading the protocol from the EBICS server, the EBICS client can use the order type PTK for the text-based protocol and the order type HAC for the XML-based protocol. With EBICS 3.0, the text-based protocol is no longer part of the specification. Moreover, changes of the HAC protocol have to be considered during automated result evaluation. Due to the required overall version interoperability, these changes partly affect EBICS clients of previous EBICS versions too, if an EBICS bank server supports EBICS 3.0.

Hence, software manufacturers and EBICS users must be prepared for changes of EBICS clients that already provide functions for the automated customer protocol evaluation. First, a change from PTK to HAC should be performed for automated evaluations in EBICS clients. Furthermore, users of the HAC protocol must be aware that with EBICS 3.0 the final HAC protocol is displayed differently.

Up to now, the HAC end flag with the identifiers ORDER_HAC_FINAL_POS and ORDER_HAC_FINAL_NEG has provided information on whether the submission was positive or negative. With EBICS 3.0, only the HAC end flag ORDER_HAC_FINAL is still available which informs on the submission’s result in conjunction with the last reasons code only. The final code DS04, for example, stands for the order’s rejection whereas code DS05 proves that the order was successfully submitted and forwarded to the bank system. Further reason codes have to be considered.

To make sure that your EBICS monitoring will still provide the correct results, I recommend to rely on the HAC customer protocol and to focus on the evaluation of the reason codes. This way, you can easily keep track of the EBICS communication with your financial institution.

Michael Lembcke

Migration to EBICS 3.0 in France

EBICS 3.0 entered into force in France on 27 November last year. A good two months have passed since then and we think this is a good time to assess the progress of the migration to the new version.

The aim of this new version is to harmonise EBICS and thus ensure the following: 

  • a uniform EBICS version in all countries in which EBICS is used
  • uniform identification of BTF (Business Transaction Formats)
  • a uniform X.509 format for filing the key

The date of entry into force only applies to French financial institutions and is not mandatory for corporate customers. The latter can decide for themselves when they would like to migrate.

The big French financial institutions have been working on the migration projects for several months and most of them are now able to offer their customers the EBICS 3.0 channel. The others are in the final testing phase and will soon be opening the EBICS 3.0 channel.

The smaller financial institutions have not reached this stage yet. Only a few have started their migration projects and much suggests that they will only be able to offer the EBICS 3.0 channel in a few months' time, possibly even in 2020.

However, these differences in time implementation should not pose a hindrance to corporate customers keen to migrate to EBICS 3.0 in the near future. For in a transition phase of some length, even financial institutions that have already migrated to EBICS 3.0 will continue to support the 2.4.2 version that has been in force since EBICS was introduced in France (version 2.5 is currently used in Germany). This transition phase will give corporate customers time to update their client software.

Due, however, to a lack of interest in the new version, particularly on the part of corporate customers, the transition phase could drag on. To prevent this from happening, the financial institutions can offer their corporate customers additional services that will become possible with the extensions of the new version. These include simpler setup of transfers and the electronic distributed signature. The latter allows corporate customers to sign orders asynchronously after file transfer (in version 2.4.2, the electronic signature had to be sent together with the order file), thereby offering them greater mobility.

The impact of this will be particularly felt when the X.509 certificates are completely virtual and the mobile signature can really be used. Experts are working on this subject and efficient solutions can therefore be expected in a few months...

Marc Dutech 

How EBICS can be improved (Part 10) - EBICS downloads based on date and time specifications

In payments, it is becoming increasingly important for bank customers to be kept up to date on intraday payment movements, especially since the introduction of new procedures such as instant payments. This development also poses new challenges for the EBICS standard in the corporate customer business. EBICS customers usually have to actively retrieve information on payment movements from the bank server. The so-called historical download with date specification is the suitable method, especially for corporate customers using several EBICS clients. As, however, the historical download through EBICS is only specified to the day, in practice large volumes of data are downloaded several times intraday. Moreover, business timestamps for EBICS depend on the provision format and are therefore at best specified to the day and at worst simply not available on the bank server. The downloading clients then have the task of automatically filtering the redundantly downloaded data. Such behaviour currently places significant additional burdens on all systems involved, both on the part of the customers as well as the banks.

This situation could be remedied by extending the EBICS specification by defining specified time-controlled downloads.

In this case, the EBICS server would support an additional variant of the historical download. Unlike the previous standardised historical EBICS download, the time would now also be taken into account for the start and end times. Moreover, the stated times and dates should always refer to the time and date of provision. This would enable the EBICS server to deliver all data records that had been provided within the specified time period. For more flexible handling, it should also be permissible when making download requests to specify in each case only one of both times and dates. Otherwise, the download would behave in the same way as the previous standard download in the acknowledgement phase.

I think specifying such a uniform solution for all EBICS users in the EBICS standard could refine the download process for EBICS, reduce the burden on servers and significantly improve the process, especially given the growing need to be kept up to date. This would make the proprietary solutions already used in EBICS products superfluous.

Michael Lembcke

EBICS and the API discussions – a status update from Switzerland

Since SIX Interbank Clearing (SIC) became an official member of the EBICS SCRL as a representative of the Swiss financial market in spring 2015, a lot has happened with regard to corporate communication interfaces for banks. Considering the growing commotion in the area of electronic interfaces, the time seems right for this blog to take a closer look at the current situation.

Naturally, such an exploration must also broach the subject of APIs (application programming interfaces) – an acronym that is being proclaimed as the great salvation of digitalisation strategy in some bank management circles. Do APIs, particularly those for account information and payment order services, have the potential to render long-serving file transfer protocols like EBICS obsolete? This question especially arises when taking into account that start-up and fintech companies tend to prefer these streamlined APIs to the rather complex implementation process of EBICS.

To find an answer with regard to Switzerland, the reader less familiar with the Swiss financial market needs up-to-date background information. First of all, we should keep in mind that Switzerland is not a member of the EU and as such is in no way bound by the PSD2 (second payment services directive). This means that financial institutions are not obligated to offer APIs, which eliminates one major driving force. Unlike FinTS in Germany, there is also no standardised online banking interface in Switzerland. Nonetheless, the good news coming from the European Union has been heard in Switzerland, as well.

Before diving deeper into the hot topic of API initiatives, let us once again acknowledge how widely the use of EBICS has spread. In the past five years, following the example of the German implementation, the EBICS protocol has made its way into all larger institutions as a standard service offer for electronic data exchange with corporate customers. The ability of the protocol to transfer very large volumes and, more recently, the use of the EDS (electronic distributed signature) are highly appreciated by medium-sized and large corporate customers. All notable Swiss software providers with electronic banking solutions have made EBICS part of their product offer.

So far, so good, one might think. As mentioned before, the API discussion in Switzerland is in equally full swing. There are currently two initiatives worth noting, which we will briefly discuss in a moment. To be clear upfront, the author does not consider these initiatives a replacement for EBICS, but rather an additional option in the range of bank interfaces that is suited for a specific customer segment (usually smaller corporate customers that use cloud solutions for bilateral data exchange with financial institutions).

A highly promising initiative appears to be "Corporate API" by SIX and the Swiss financial institutions. The name refers not only to a freely accessible standard, but also to a suitable platform for that standard. Both are being developed by SIX in collaboration with representatives of financial institutions and software providers. The platform enables easy participation in a newly unfolding ecosystem that is set to provide services far beyond the PSD2 scope (AIS, PIS).

The formats offered by "Corporate API" are JSON and ISO 20022 XML. The JSON variant will be extremely easy and fast to implement and is intended for software providers who do not require the complexity of ISO 20022 messages. The ISO 20022 XML variant supports the entire spectrum of possibilities known from the CH payments migration. The end of 2018 will already see the first tests with piloting financial institutions and providers.

Another current project is called "Common API". The "Common API" by SFTI (Swiss Fintech Innovations) is based more heavily on the PSD2 and the implementation of the Berlin Group. In contrast to the "Corporate API", the specification of the SFTI defines the API in more general terms and leaves the selection of the target group to the service provider. According to information by SFTI, the big banking application providers are involved in the development of this standard. SIX has accompanied the development process of the SFTI specification from the beginning and will carry forward the results of the SFTI working group in the future. It is hence entirely possible that the two standards will turn out to be at least partly compatible.

The situation for software developers in Switzerland is not exactly simple, with EBICS as an established productive protocol on the one hand and new initiatives waiting in the wings on the other. Depending on the customer segment and the business model, solution providers are faced with the question which implementation they should offer – or whether perhaps it should be more than one. What's more, some financial institutions have by now released proprietary interfaces (such as the Hypothekarbank Lenzburg, which presents itself as a highly innovative fintech bank). If the application area is extended to Europe, already well-known initiatives like "Berlin Group", "STET" or "Open Banking" are added to the mix. As to be expected, the Swiss financial market has not adopted any of the existing standards, the "Swiss finish" remaining rather popular in these parts.

Carsten Miehling


Equality for EBICS – use case instant bulk payments

Even if it might appear strange at first sight: in Germany, instant payments use cases for the file-based EBICS transfer protocol are also currently being discussed and specified for the customer-bank relation.
In this case, the use cases focus on the corporate customer business. Particularly larger corporate customers are required to be able to transmit bulk uploads to the financial institutions. Hence, for SEPA credit transfer uploads, for example, the German banking industry has agreed on the special form of a bulk instant payments upload (instant bulk payments) based on the XML format ISO pain.001. Equivalent business transactions and formats (payment status in the pain.002 format, for instance) are also being defined for the return direction of payment information in the payment chain – from the recipient or the financial institutions. The business transactions and format specifications thus defined are expected to become officially valid in Germany from November 2019 and can be offered by the financial institutions as an option.

What is special about instant bulk payments?

The key feature distinguishing instant bulk payments via EBICS from, for example, pure instant payments processes that are synchronously executed at the "point of sale" lies in the fact that the upload itself is not considered "instant" but is taken to be an upload for execution as instant payments (SCTINST).
The submitter's executing financial institution breaks the collection file down into single transactions and executes the payments as SCTINST provided the creditor can be reached in this way. The terms and conditions of SCTINST only become applicable from this point in time.
The return-direction data is then transmitted back to the submitter by the submitter's financial institution again using the EBICS channel. In this case for the default, this means that the data is provided by the financial institution for downloading in the EBICS bank server. In the corporate customer business, the financial institution exclusively assumes the familiar passive role in the relation between customer and financial institution defined for EBICS. Therefore an active notification of the sender via EBICS is currently not planned. 

Instant bulk payments due to urgency? 

Corporate customers want to use the new business transactions to enable payments to be collected and simultaneously submitted at short notice. In this way, the money can be used for longer periods until submission. The payments are then also immediately guaranteed and executed.
As with the recipient side, immediate notification is also desired for the return direction. As no provisions have been made in the EBICS role model for financial institutions to actively notify the customer, various interfaces (APIs) and procedures (such as e-mail push) are currently being discussed for this in Germany. 

Yet it is actually quite simple: why not make use of the bilateral EBICS that has already been established for interbank payments? Both parties, customer and financial institution, have equal roles as sender and recipient. All that is needed is to extend the EBICS customer applications by adding simplified EBICS server functions. Corporate customers uploading instant bulk payments could then also actively receive data from these processes. Applications of this kind are already available on the market. The new business transactions are therefore fully implementable using the existing standard and based on existing solutions. This could put an end to the time-consuming and costly discussions about additional interfaces, protocols and agreements.

Michael Lembcke

10 years of EBICS – a success story

At the start of 2008 it was finally time: From this point onwards, every corporate client in Germany could be sure of being able to reach all banks and savings banks via the Internet by means of a standardised, secure electronic banking procedure in order to send bank transfers, direct debits and other orders and obtain account information. Multibank capability, very important for corporate clients, was guaranteed by the DFÜ agreement of the German banking industry (DK), which, starting from 1 January 2008, obligated all financial institutions in Germany to support a new, standardised procedure known as EBICS (Electronic Banking Internet Communication Standard) for their data exchange with corporate clients.

Even though it was already clear at that time that EBICS was going to be successful, there was no predicting the scale of the EBICS success story. EBICS is now a European standard for secure data exchange, not only in electronic banking with corporate clients but also in interbank payments, and it is additionally in line to become the standard for current developments such as instant payments. But more on this later.

The pre-history: the road to EBICS

EBICS, to be precise, is more than 10 years old, as it came into being on 18 July 2003. This was the day on which SIZ GmbH presented an Internet-based electronic banking procedure at a special meeting of the ZKA (Central Credit Committee = old name of the DK) with the aim of promoting this procedure, or at least the design basis of this procedure, as the basis of a new, multibank-capable Internet standard for the entire German banking industry. Since 1995, the DFÜ agreement of the ZKA guaranteed a multibank-capable procedure, BCS-FTAM, for the corporate client business. However, this file transfer procedure was based on the OSI standard FTAM for X.25 and ISDN connections, and in the Internet age it was no longer state-of-the-art. Despite a number of attempts since then, it was not possible to establish a common IP-based standard. There were manufacturer-specific (e.g. MultiWeb, MCFT) and association-based solution approaches (BCS-FTP), but they lacked the decisive element: multibank capability. On 18 July 2003, the time seemed ripe for a new standard. A DK working group formed spontaneously at the special meeting, and its mission was to develop a common, IP-based, multibank-capable communication and security standard. EBICS was created based on the design of WOP. The draft concept created by the working group was the basis forthe EBICS specification, version 1.0 of which was already presented in the middle of 2005.

EBICS was not a revolution, being based from the start on an evolutionary concept. The elements of BCS-FTAM that had proven themselves for more than 10 years were kept, and only those elements that were no longer state-of-the-art were redesigned. Therefore, the concept of order types, and thus application-neutrality, was kept on board along with the authorisation of payment data via electronic signatures (ES). What was new about EBICS in particular was the replacement of the X.25- and ISDN-based communication of BCS-FTAM with a state-of-the-art XML communication protocol based on Internet standards. Additionally, the EU was extended to the distributed electronic signature (EDS), which enables corporate clients to authorise orders which, for example, are transferred automatically from the accounting department to the bank, at any time and from any location, and to also use mobile terminal devices.

SIZ GmbH initiated the development of EBICS in 2003, and has been accompanying it continuously ever since. In 2005 SIZ became the control centre of the German banking industry for EBICS (Appendix 1 of the DFÜ agreement) and for the data formats in electronic banking and payments (Appendix 3 of the DFÜ agreement).

In 2006, the savings bank financial group became the first institution group in Germany to support EBICS comprehensively. Then, in 2007, the associated and public institutions followed, along with the big banks and other private banks.

EBICS: the secure tunnel in insecure networks

The basis for the development of EBICS was above all a detailed security concept. Because data in electronic banking and payments requires special protection, the potential threats were used to derive security requirements and security measures for EBICS that use various cryptographic measures to guarantee the confidentiality, integrity and authenticity of the data in potentially insecure networks (e.g. the Internet). The confidentiality and integrity of the data was ensured by means of an EBICS-specific encryption procedure which, in addition to the TLS encryption on the transport level, also offers end2end encryption of the sensitive data in electronic banking. The authenticity of the communication is provided by the authentication signature of every data package. The authorisation of payments is ultimately given via electronic signatures, whereby depending on the contractual agreement between customer and bank, different authorisation models can be used (single and multiple signatures, ES classes, limits etc.). The security concept has been checked regularly ever since, with EBICS being further developed if required in order to adapt the procedure to new or altered threat situations and/or technical standards. Over the years, EBICS has proven to be an extremely secure standard: To date, no successful attacks on EBICS have been confirmed.

The ground-breaking features of EBICS for the secure transfer of sensitive data:

2008: introduction in Germany

On 1 January 2008 the time had come: With the DFÜ agreement of the German banking industry, all banks and savings banks in Germany committed to supporting EBICS on the bank side from this date onwards. EBICS was accepted by the corporate clients faster than expected: in the first year already, a majority of corporate clients switched from BCS-FTAM to EBICS. Clearly the advantages of the new procedure were just too big. The runaway success of EBICS was mainly due to the fact that the transmission speed of the IP-based EBICS was many times faster than that of FTAM, that the use of Internet standards greatly simplified the incorporation into company and banking networks, and that EBICS offered new features such as the distributed electronic signature. It was decisive, however, that the DFÜ agreement of the DK guaranteed the multibank capability that was crucial for corporate clients from the very beginning. The switch was made easier by the fact that migration scenarios were already implemented in the procedure which made it possible to convert the keys for the electronic signature from BCS-FTAM to EBICS practically at the touch of a button.

EBICS develops into an interbank procedure

Word travelled quickly that EBICS is a very secure procedure especially designed for safe, fast transmission of large data volumes. So it was no surprise that EBICS also became the communication standard in interbank payments. The trailblazer here was the German Central Bank, which introduced EBICS in 2008 as the communication procedure for the SEPA Clearer within the scope of the the RPS (Retail Payment System). At this point it is impossible to imagine a secure exchange between banks and clearing houses without EBICS. Along with the Central Bank, the EBA clearing in the STEP2 payment system also uses EBICS, and EBICS has also been established in bilateral clearing between banks, so-called "garage clearing”, for many years now.

EBICS was also very quickly introduced for the delivery of data by service data centres. In 2009 the corresponding DK guideline relating to the support of EBICS was issued.

EBICS becomes the international standard

By the end of 2006 the French banking industry (CFONB) became aware of EBICS when looking for a new, secure, IP-based communication procedure. Similarly to Germany, France was faced with the situation of replacing an old standard (ETEBAC) with a future-oriented procedure. After intensive evaluation of various alternatives, EBICS emerged as the suitable procedure, and in 2008 a co-operation between the French and German banking industries was initiated. In summer 2010, EBICS SCRL, the European EBICS association based on Belgian law, was founded in Brussels. EBICS has now been introduced just as widely and successfully in France as in Germany. With the foundation of the EBICS association, the SIZ became the official technical office of the association (European EBICS control centre) and has since coordinated the EBICS working group, i.e. the committee responsible for the further development of EBICS.

However, with the introduction of EBICS in France, different “dialects” became established in the two countries. For practical reasons, it was accepted that due to the different requirements in the two countries, there would also be different versions of the EBICS standard. This related in particular to the representation of business transactions, for which the three-character order type ID is used in Germany, whereas in France they are identified by means of format parameters. There were also other differences, e.g. in France the cryptographic keys used are based on the X.509 standard, while Germany continues to employ a proprietary format that comes from BCS-FTAM. And while both countries were basically “speaking” EBICS, the inter-country compatibility faced some problems because of the different “accents” being used.

This shortcoming became really apparent in 2015 when Switzerland became the third country to join the EBICS association. Switzerland was presented with the dilemma of choosing between the “dialects” or even adding a third, Swiss “accent”.

If was obvious that different EBICS dialects were not conducive to the desired proliferation of the standard in Europe. The only solution was to harmonise EBICS, and this need was finally addressed in the new EBICS 3.0. In particular, the introduction of BTFs (Business Transaction and Formats) enabled a future-oriented, flexible and above all standardised identification of business transactions for EBICS. It was also possible to achieve further important harmonisations in the EBICS standard, thus making EBICS a uniform international standard. With electronic payments it is especially important for partners to be able to reach, understand and trust each other. The understanding is achieved mainly by the common SEPA data formats and the standardised EBICS identification via BTFs, the accessibility and trust is given with EBICS as a common communication and security standard. EBICS 3.0 has been released and can be introduced in autumn 2018. In Germany, EBICS 3.0 will be mandatory for all institutions of the German banking industry from 2021, as per the DFÜ agreement of the DK.

10 years of EBICS: review and outlook

It’s time to look back on 10 years of EBICS in Germany. What began as an attempt to contain different, incompatible developments in electronic banking in Germany, and ensure the multibank capability for corporate clients in the Internet age, has developed into a success story that has long traversed the nation’s borders. EBICS is known worldwide as an open standard for the secure exchange of files, and is also used in countries that are not (yet) members of the EBICS association. EBICS is now not only a customer-bank procedure but an established standard in interbank payments, and it is also expected to play an important role in both the submission and clearing of instant payments.

But what are the reasons for this long-running success? It seems to me that the following points in particular have been decisive:
  • The application-neutrality of EBICS
    EBICS is application-neutral and can transfer the widest range of data types, because neither formats nor bank-technical specifications were incorporated into the design of the transfer protocol. This is why EBICS can be used so easily in different countries and different application scenarios.
  • The security features of EBICS
    Because EBICS combines mutually independent cryptographic procedures for data confidentiality, the authenticity of the partners and the communication, and for the authorisation of orders, it offers a secure tunnel in insecure networks.
  • The multibank capability
    Both in Germany and in France, EBICS is a multibank-capable procedure. In Germany, multibank capability is guaranteed by the DFÜ agreement of the DK.
  • The adaptability of EBICS
    As an open standard, EBICS has an architecture that can be adapted to different requirements, and it is continuously being developed further by the EBICS association.
EBICS has a lot of history behind it, even more than the 10 years since its mandatory introduction in Germany. But the story is far from over: As an open, secure communication standard, EBICS has a bright future ahead. With the experience of seeing that the fundamental design decisions are still holding up today and that the flexibility of the procedure enables EBICS to be adapted to new requirements, we can be confident that EBICS will continue to be an important element of electronic payments in Europe.

Dieter Schweisfurth

Head of Electronic Banking