The Bircher muesli of keys

As was already mentioned on a blog post on 25/07/14, "EBICS has arrived in Switzerland", the Swiss financial centres are moving in on the EBICS community of the country's two biggest neighbours, France and Germany. The perception of EBICS in France has proved to be somewhat different than in Germany, while Swiss stakeholders are unsure about which variant would be the best for them. In terms of order types, the trend is currently leaning towards France, i.e. FUL/FDL in conjunction with the use of format parameters, instead of the multitude of order types in Germany. But when it comes to the application of electronic signatures, things get a little more complicated. Precisely how should these be implemented for customers? 

The German variant, featuring automatic key pair generation for encryption (E002), authentication (X002) and for signatures (A005/A006), is currently the variant in use in Switzerland, while the German VEU system (distributed digital signature) is in the first planning stages. This enables the use of signature models with several personally identifiable signatures, which can be created and submitted with or after the order dispatch. The big Swiss banks, however, currently use the individual and transport signatures. The role of the individual signature is usually to establish a "corporate seal". This is where a company is identified instead of the person who actually approved the order. The customer's software system is used to regulate and manage the usage of these "corporate seals". For transport signatures, the approval is transferred over a separate channel, but not like in France, where an accompanying document is still sent manually, but rather via access to online banking.

On the other hand, this practice is increasingly subject to criticism by the legal and security departments of the Swiss financial institutions, who require precise authentication of the person who signed off the order. In this case VEU would be a useful tool to help the banks shorten the current lengthy processing times caused by the banks' administration of signature rules.

The TS model (Transport and Signature) of France in combination with CA-based certificates for the electronic signature is seen as an attractive solution because it alleviates the problem of unrestricted validity of the encryption key and the central blocking seems to minimise the security risks. Ideally this will then be combined with a security token which can be used only by the person who created the order. "In for a penny, in for a pound!", one might be tempted to say, but this is how we Swiss are; if a standard offers these kinds of functionalities, why not use them? Also, in terms of regulation, the current trend seems to be that financial institutions will not easily be able to deny the risks of using "corporate seals" in a contract disclaimer in the future (see also the ECB's „Assessment Guide for the Security of Internet Payments“).

A consistent recipe is needed 

The key issue here is the current diversity of EBICS variants and the confusion over which variant should be implemented for the market to suit the needs of those involved, i.e. the customer, software developer and bank. Are there now CA-based certificates and if there are, for what type of key? Which CAs are accepted across multiple banks? What properties should this kind of certificate have? Does the application of security tokens apply only to the signature (A005/A006) or also to the other authentication and encryption keys? Could security tokens conceivably be used without a CA, therefore requiring only external retention of the key by the signing-off contractee?

With its similar diversity in variants and recipes, the whole thing somehow brings Bircher muesli to mind. The EBICS community strives to establish the standard in Europe, but a consistent recipe for this key-muesli would certainly be an advantage from which users would also benefit. If not, it will become more and more difficult to establish this international standard. I believe that this should be one of the first items on the EBICS working group's agenda.

Carsten Miehling

Read more

Portugal in the age of EBICS

Just like the French banks in 2009 and the German banks in 2008, numerous Portuguese banks have decided to use the EBICS protocol for their exchange of financial flows with companies.

Two principal reasons have motivated this change:

1. The planned cessation of network X25 by Portugal Telecom from 30th June 2014,
2. The inability of certain protocols, utilised until now, to transfer files comprising records of varying sizes, as is the case with SEPA formats.

The Portuguese banks therefore had to suggest to their client companies a substitute exchange channel which was accessible, secure, inexpensive and operated across borders.


With their knowledge of the positive feedback about the migration and daily use of the EBICS protocol in Germany and France, these Portuguese banks decided to add the EBICS channel to their service portfolio. Moreover, some of them have decided to use the TRAVIC-Corporate software, the banking server edited by PPI.

The implemented EBICS version is version 2.4, identical to that currently in use in France. Up till now, only profile T has been operational.

The types of information exchanged via the EBICS channel are multifarious: domestic payments in PS2 format, Swift MT101 transfer orders, SEPA credit transfers (SCT) and direct debits (SDD), account statements, confirmations, rates and quotations for  currencies, proprietary formats for cheque letters and factoring, etc.

Furthermore, for some months now, some editors located in Portugal have been proposing company software supporting the EBICS protocol. This is particularly the case with METACASE, the Portuguese partner of PPI which implemented the management of the EBICS Target One protocol in the management platform of which METACASE is the editor. Implementing the EBICS protocol even before the Portuguese banks opened their channel was justified by the request from some Portuguese companies to be able to exchange financial flows with German and/or French banks.
The choice made by a majority of Portuguese banks therefore shows that the EBICS protocol is set to become a protocol widely deployed in Europe, thus contributing to exchanges between companies and banks within the SEPA zone which are secure, easier and inexpensive.

Marc Dutech

Read more

Standardisation of payment transactions is still a distant reality

In Europe we have now already introduced SEPA for the standardised payment transfer system. However, SEPA payments cannot be made electronically to just any European bank of one's choice. In Germany companies use the order type CCT for submitting SEPA transactions (SEPA Credit Transfer) to financial institutions. Why are SEPA transfers from any Euro country with this order type not automatically possible?

The XML-based SEPA data formats have now been comprehensively adopted in the European countries involved. The goal was, and remains, to standardise data formats and regulations surrounding payment transactions after the introduction of the single currency, thus allowing a simpler electronic payment medium for within Europe.


Based on ISO20022 XML formats and the guidelines of the European Payments Council (EPC), implementation in the Eurozone has alas been carried out separately according to regionally-specific payment transaction conventions. As a result, we now have differing, country-specific SEPA formats for the same business transactions.

They differ first and foremost in the namespace of the format. While, for example, Germany has introduced their own data format variant for SEPA transfers with "pain.001.002.03 ", other countries use the EPC's "pain.001.001.03". National differences are also prevalent in XML namespaces. Moreover, we are subject to assignment regulations which are different for each country.

In Germany, SEPA payments, via EBICS, are designated with the three-digit order types and then transferred (e.g. CCT for SEPA transactions). With format associated with order type, we have a system which is built according to the specifications of the German credit services sector. But what happens if a foreign client sends a SEPA transaction in their native format to a German bank? Neither the order type nor the XML namespace offer a reliable definition of the formatting characteristics. The bank must, however, respond to these irregularities if they wish to process payment transactions internationally. So how can banks recognise the differing formatting specifications and process them accordingly?

Possible solution: Issuer ID for EBICS

As long as no proper standardisation of SEPA formats, which are traded amongst companies and credit institutions, is in effect at a European level, the solution must be found elsewhere. There are various ways to achieve this. One approach challenges the software developer to create an intelligent format parser or specialised core data extensions in the bank's computers. Another more sensible solution in the long-term is to take advantage of the EBICS standard.

In France, the problem has already been solved by the usage of format parameters and the country codes transferred. From the country code, an EBICS-compliant bank computer can infer the country-specific formatting rules and consequently initialise specific processing workflows. In Germany, however, the application of format parameters is not generally common. So in Germany, the possibility of introducing the EBICS issuer ID is currently under debate. This would also equip the business transaction with the issuer of the format, and hence the associated formatting rules. A bank computer could then recognise whether, for example, there are agreements and/or regulations for the declared formatting configuration. If the French model of format parameters and country codes is not also introduced in Germany, at least the issuer ID to order type system should soon be implemented with EBICS. A solution of this kind makes sense and hopefully will be available soon with EBICS. Until then banks and their clients will have to settle for ad-hoc solutions.

I will discuss the features of three-digit EBICS order types in Germany and of format parameters in France in a follow-up article.

Michael Lembcke

Read more