EBICS in “private banking” – use cases beyond payments

EBICS is widely regarded as secure transfer protocol for the exchange of payment files (orders and statements). For corporate customers in particular, it is certainly the most commonly used protocol. At this point I would like to present a different use case that is very relevant in Switzerland: EBICS in the private banking sector.


The private banks here are currently going through an even rougher patch than before and are under a lot of pressure from various sources. Regulations, margin pressure, better informed customers, breaking up the value chain, and the digitalisation process are only some of the many topics currently found on the agenda of private banks' boards. In the area of automation, we are observing a noteworthy initiative in Switzerland – the use of EBICS as an interface for stock market transactions.

At the suggestion of big institutional investors and professional asset managers, who, for their part, also have an interest in higher automation, more and more EBICS transaction types from the order business are being offered recently. Typically, these are order types for submitting and processing stock market orders (upload) and for order confirmations, invoices and deposit statements (download). The formats used are SWIFT (MT5xx) and PDF. They are implemented as institution-specific order types (XYZ).

Now, if we take a look at the entire value chain of a stock market transaction, it can ideally be performed in a fully automated manner. The portfolio management system of an asset manager detects an imbalance between the investment strategy and the customer's portfolio, and generates the stock market order for a reallocation. By means of the standards EBICS and SWIFT (for example, MT502), the order is triggered automatically at the institution, and the confirmation is reported back via EBICS, as well (for example, MT509). The automation substantially reduces the processing work on all sides. Additionally, the error quota is lowered significantly compared with the manual processes that are still widely used to this day.

In summary, innovative private banks are already offering EBICS or planning to join the market with their respective offers shortly. As, traditionally, payments take a less dominant role in the private banking business than in universal banks, the focus of EBICS shifts to stock market transactions and asset reporting. As asset managers and institutional investors also strive for higher automation, it's a win-win situation. It would be ideal if the standardisation bodies agreed on universal and uniform order types (or, as of EBICS 3.0, the so-called BTF specifications) and defined formats as soon as possible.

Carsten Miehling

Read more

EBICS 3.0 with BTF clears the way

European payment transactions are converging thanks to SEPA and EBICS. With the help of EBICS 3.0, various EBICS dialects are now merging. The concept behind this process is called BTF. BTF stands for Business Transaction Format. BTF standardises the description of the formats to be transferred in Germany, France and Switzerland. This harmonisation clears the way for a growing EBICS community.


The new EBICS 3.0 specification is valid as of 27 November 2018. The launch dates can vary in the individual countries. EBICS 3.0 will bring about the following standardisations:

• A standardised EBICS version in the individual three EBICS countries
• A unified identification of the business processes and formats (BTF)
• A standardised X.509 format for the key deposition

This is how the compatibility of the EBICS dialects will be guaranteed.

Optional features

Up to the present, not all of the EBICS features were offered in all of the countries, whereas now, with EBICS 3.0, banks can offer their clients all optional EBICS features individually.
These include:

• Certificates
  CA-signed certificates
  Self-signed certificates
• Model of authorisation
  German T, A, B and E authorisations
  French T and TS authorisations
  Elimination of the fax authorisation
• Distributed electronic signature (VEU)
  The use of the VEU is mandatory in Germany but otherwise optional

Innovations

The EBICS 3.0 specification includes innovations which have to be taken into account upon introduction.

• Mapping
  The adjustment of format parameters and order types to BTF standards is simplified by assignment overviews (mappings). These mappings for order types and format parameters are defined on a national scale. The EBICS clients have to put these assignments into action. In the meantime, there might be some variances: bank A already supports BTF while bank B only offers EBICS 2.x.

• Extended control
  With the aid of BTF, it is now possible for the EBICS client to control the bank server. Up to the present, the bank server exclusively controlled these processes, but with this client control a new chapter opens up. The EBICS user can decide if his assignment goes directly into the VEU or if the authorisation should be checked. The EBICS specification defines the action in case of any differences between the BFT specification and the rights on the bank server.

• Standard protocol
  The strategic customer protocol in the EBICS 3.0 specification is the HAC. By that, the old text-based customer protocol PTK will be replaced entirely. The HAC protocol is machine-readable because it is based on XML. Throughout the transitional period, PTK and HAC will co-exist given a mix of EBICS versions. According to the EBICS 3.0 specification, BTF orders won’t be displayed in the old PTK anymore. Nonetheless, for all those who would still like that, the PTK format can be extended proprietarily.

EBICS 3.0 paves the way for a growing EBICS community

EBICS 3.0 Europeanises the use of EBICS. That’s a good development because this way, banks can win over new markets and clients. The user profits from this flexibility by gaining new possibilities. EBICS now uses established standards exclusively.

The existing interfaces and contract conditions can almost remain unchanged. The BTF can be configured in the background. As far as bank servers and EBICS clients are concerned, business standards are still a priority. This is supported by the EBICS 3.0 specification and the mapping defaults.

The introduction of EBICS to new markets and countries has been simplified enormously by EBICS 3.0. The advantages of EBICS 3.0 are obvious. Therefore, a near-term introduction in the existing EBICS countries is recommended.

Michael Lembcke

Read more

EBICS 3.0 in the starting blocks

On 19 May 2017 in the auditorium of the Fédération Bancaire Française (French Banking Federation), a workshop was held by CFONB to present version 3.0 of the EBICS protocol.

More than 120 people from various industries - banking, manufacturing, business etc. - took part in the event at which different speakers discussed the basic concept of this new version.


After the CEO and a number of representatives of EBICS SCRL (www.ebics.org) had provided an overview, a selection of important historical dates for EBICS was presented. They reminded us that the EBICS standard is well out of its infancy by now, as the implementation in Germany started 12 years ago and EBICS had its début in France more than 7 years ago. The Swiss financial institutions only started along this path in 2015. One presentation showed the current prevalence of EBICS, extending from the Iberian peninsula to the Baltic and from Ireland to Italy. However, aside from Germany, France, Switzerland and Portugal, the degree of usage in the countries of this region differs very significantly.

We were then presented with the reasons for the success of EBICS in the four countries (you will find numerous articles on the topic in this blog) and the barriers to its rapid expansion throughout Europe. The most significant of these are:

• The differences in the identification of the payment flows between German, French and Swiss variants
• The use of X.509 certificates in France and key pairs in Germany
• The use of the distributed electronic signature in Germany and Switzerland, but not in France

This list was followed by a description of the profound changes that version 3.0 will bring, in particular with regard to the harmonisation through the integration of the BTF (Business Transaction Format) concept and the possible generalisation of the distributed electronic signature. You will find more detailed information on these topics on the EBICS SCRL website.

The second part of the workshop was a discussion on the topic: Why do we need a standardised EBICS version?

This presented stakeholders from the EBICS area with the opportunity to raise and discuss the following topics:

• The advantages of EBICS and the limitations of version 2.x due to a lack of harmonisation
• The expectations for the new version and the advantages provided by the harmonisation
• The opportunities to expand geographically, even to other continents
  Africa in particular was mentioned here because a number of its banks already offer the EBICS service in several French-speaking countries.
• The opportunities to use EBICS beyond the company-bank relationship
  Particular mention was made of the use of EBICS for STEP2 and RT1 (instant payments) with EBA Clearing.
• Migration modalities
• Aspects of the future development of the protocol under discussion that can be put on the agenda, such as the standardisation of the AC certificate and the option to use certificates that are not saved on physical media in order to simplify the industrialisation of EBICS signature solutions for mobile devices.
• The current use of the distributed electronic signature in Germany and Switzerland, and the advantages that its use in France could bring

So this event comprised the official introduction of version 3.0. It will be available from November 2018, from which point all banks must offer the new version in addition to version 2.x, which is valid in the various communities.

There is no obligation for companies to also migrate at this time. There is no plan for them to perform a sudden migration from 2.x to 3.0. However, the new communities could start using this new version immediately.

Manufacturers and banks are faced with the prospect of a lot of work. In July 2017 an implementation guide will be provided by EBICS SCRL and CFONB to help with this process.
I give many presentations on EBICS in various European countries and beyond, and I believe that the harmonising will make this product significantly easier to promote. I am convinced that it is the key to success, and that the first letter of EBICS will come to signify “European”.

What if the developments currently being tested led to the next step being a Worldwide EBICS?...

Marc Dutech

Read more

EBA CLEARING to introduce EBICS as additional connectivity option for its instant payment system

Future service participants can use SIANet or EBICS to connect to the new pan-European real-time payment infrastructure from November 2017 on – other options may follow later.

EBA CLEARING announced today that the future participants in its pan-European instant payment infrastructure service will be able to use, in addition to SIANet, the Electronic Banking Internet Communication Standard (EBICS) for the exchange of transaction messages with the platform. The Company will introduce EBICS as an additional connectivity option from the start of the service in November 2017 and make it available in the test environment from June 2017.


Read the press release from 9 March 2017 here: EBA CLEARING press release

Michael Lembcke

Read more

How to enhance EBICS, Part 9 – EBICS is ideal for transferring files of all sizes. – Yes, but …

The data behaviour for payments also continues to change with SEPA. New processes mean that the files exchanged between customers and banks and in bilateral exchanges keep getting bigger. In the customer-bank relationship in particular, the download function for data downloads (e.g. account statements) via EBICS plays an important role. And here at least there seems to be a need for optimisation. For particularly large files, various factors make it difficult to perform a successful download.


To describe the problem more precisely, one first has to take a closer look at the EBICS protocol. Downloads via EBICS are performed in segments, always for all of the data that is relevant to the client request. When it receives a request, an EBICS client always puts all of the data for a download in exactly one physical file.

In the EBICS download process, after a download order is received the EBICS-Server first determines the number of segments in which the file to be transferred will be transferred to the client. This number is returned to the client with the first segment. It is mandatory in EBICS. Then the client calls up every subsequent segment sequentially and creates the file in the client.

Depending on the file size and the delivery type (e.g. ZIP archive), even the operation of compiling the first segment with the total number on the EBICS-Server can take some time. First, the complete file must be created in a compressed and encrypted form so that in the first EBICS response the correct number of segments can be delivered to the EBICS client. Therefore, until the client receives feedback on the number of segments in the initialisation phase, timeout situations and thus terminations can occur in the EBICS connection when large data volumes are involved.

This is the problem. In future, therefore, it must be possible to speed up the EBICS response to the EBICS initialisation request.

It is currently seen as imperative for the number of segments, which is returned to the client with the first segment, to be correct so that the transfer can be started. However, according to EBICS specification 2.5 (see section 7.2 Implementation in the EBICS messages, page 159), if the segment number specified is incorrect the EBICS client should behave tolerantly. In such a case, the EBICS client should proceed with the ongoing transaction with the acknowledgement phase, even if the EBICS-Server delivers fewer segments than it specified in the initial EBICS response. It should be possible to determine and return an estimated number of segments so that the EBICS-Server provides feedback to the client faster and avoids a timeout in the case of large files.

Fundamentally, it would be desirable to extend the EBICS specification with the following two partial solutions.

The EBICS client initiates a download of an unspecified size to avoid timeouts due to large data volumes

In its response, the bank server returns a number of segments for the expected data along with the first segment. If the data involved enables a faster compilation procedure, the bank server can deliver the exact number of segments as it has done up to now. However, if a larger data volume is involved, and possibly a longer preparation time (e.g. ZIP), it is permissible to return an approximate number of segments.

In any case, the EBICS client must keep calling up segments until it receives the end message.
In order to avoid timeouts during downloads in the collection/preparation phase of the EBICS bank server, when calling up a subsequent segment the EBICS bank server should also be permitted to return a value that indicates that it has not yet completed the data compilation. The EBICS client can keep requesting the required segment until it receives this segment.

Optional limitation of the data volume to be downloaded by the EBICS client in order to avoid files that are too big

At the same time, downloading large data volumes can also be problematic due to conditions outside the sphere of influence of the EBICS-Server or its operators. The problems can be caused by the system design of the client or the infrastructure. In such cases, it can be helpful if the data volume to be called up on the customer side can be restricted further than the current options allow (historical call up).

For example, it would be desirable for the EBICS client to be able to specify a maximum size when initiating a download. A possible solution would be a new optional parameter for the size of the download data. During the download, the EBICS bank server then always delivers complete data blocks (e.g. an account statement), and at least one of these data blocks. The size restriction should always be interpreted as a guideline value that the bank server is also permitted to exceed. This would provide an additional possibility, aside from the historical download, to control the size of the download data on the client side.

With these two extensions, EBICS will be equipped to deal with the growing data volumes in the future as well.

Michael Lembcke

Read more