EBICS isn’t just EBICS – on order types and format parameters

Even though there is a standardised specification for EBICS, it is used differently across Europe for submission and for authorisation checks by the bank with regard to payment transaction orders. For example, only order types are used in Germany, whereas the French use the format parameters. But do customers have to know these differences? As I promised in my last post, here's more on the subject.


With the EBICS order type, the client indicates which administrative operation they wish to submit using the banking server. If the order type is recognised by the banking server and the individual submitting the order is authorised, a format process specified for this order type will be initialised.
For three-figure order types in EBICS there is a distinction between initialising uploads and downloads. Order types can also be either operative or administrative. The latter refers to order types which operate the EBICS protocol themselves, for example, HIA and INI for key exchange, or HVU for retrieving the VEU (distributed electronic signature) overview. On the other hand, operative order types refer to the technical content of a data transfer, such as CCT for payments in the SEPA Credit Transfer format. In this way, the type of format-specific processing can be determined for operative order types.

With EBICS, a list of the operative order types and the accompanying administrative operations or formats to be used is specified. These operative order types are at present predominantly used in Germany.

In France, only one order type is generally used for uploads (FUL) and one for downloads (FDL) for operative orders, regardless of data content. In order to then send information on the receivable format to the banking server, a format parameter of up to 40 characters is provided with the order type by the client. this format parameter is determined by EBICS.

Does the banking server communicate well with the client?

In both the German and French variants of order type usage, format-specific authorisation checks are stored by the bank. On the one hand, this allows the format parameters a detailed agreement between the customer and bank on the type of content exchange (e.g. SEPA versions, national variants), but the order types for a customer are potentially more easily managed because there would be no need to be concerned with format details in EBICS. However, it is imperative that EBICS banking servers and clients can communicate with each other. The customer must therefore be well aware of what the banking server understands.

Both exchange methods of operative data between the EBICS client and server have advantages and disadvantages. The corporate client will make the eventual decision, possibly having accounts with several credit institutions in various countries. Such customers will require a standardised process. The success of EBICS will therefore depend largely on both the consistency of EBICS usage and the interoperability of EBICS usage varieties. For this purpose, input of the specifier will be requested. As demonstrated in Carsten Miehling's post on 9 September, this process is already underway.

Michael Lembcke

Read more

Renewing the EBICS certificates for servers

Written by Christophe Garnier – Technical director of PPI FRANCE

The vast majority of EBICS servers, for the French version of this protocol, were put into production at the end of 2009 and during 2010. Many of them use self-signed X.509 certificates, which are valid for 5 years. Some institutions have therefore already started renewing them and others are preparing for it.


If, to renew the client certificates, the protocol envisages dedicated messages (PUB, HCA and HCS messages) and an automatic mechanism suppressing manual interventions (signed messages do not require additional authentication), the same does not apply to the renewal for the server. Only the HPB message is available and authentication of the certificates received includes a manual stage: matching with their digital fingerprint. Another notable difference is the scope of the operation which may concern several thousand client accesses at the same time.

It therefore seems obvious that a minimum of organisation and precautions are needed to facilitate this intervention.

Due to our expertise in developing and implementing EBICS software, on both the client and server side, we have learnt lessons from our first experiences in renewing these certificates and therefore feel able to make the following recommendations to those in charge of the administration of the EBICS servers:

- Enquiring at the provider about the operating mode for generating and updating the certificates.
- Choosing a good date and time which avoids periods that are usually stressful (end of the month, cut-off, etc.) or when few staff are available at the client (late evening, night-time, weekend, school holidays, etc.). Regarding the dates when the certificates expire, it is possible to anticipate when they need renewing and this will provide a little more leeway.

- Informing clients, well before time, about the date and time retained for setting up the new certificates. It would seem wise to send a reminder a few days beforehand. Here are a few elements that we think would be useful to integrate in this communication:

• Encouraging the client to contact their provider to ensure that their software supports the renewal of the EBICS certificates for the server and to obtain the operation mode, if they do not already have it. It should be noted that we have identified two distinct client software versions that do not allow this operation. In both cases, the clients have had to completely set up their access again.
• Inviting the client to send the mail to any providers to whom they have assigned remote transmission access. The point before also applies to them.
• The digital fingerprint (to aid comprehension, we also recommend mentioning the other denominations currently in use: condensate and hash) of each new certificate must, of course, be specified in the mail to allow it to be authenticated through matching. In addition to the usual presentation with a matrix of 4 rows of 8 bytes, it can also be presented in a line (the 32 bytes on the same row without a separator character) to allow it to be copied and pasted in the client’s software.
• Pointing out to the client that, if they do not update the parameters in time, the first transfer will fail with a reserved error code of value 091008 and with the words EBICS_BANK_PUBKEY_UPDATE_REQUIRED. The new certificates will therefore have to be recovered before restarting the transfer or transfers that have failed.
• A final point could also mention the digital fingerprints of certificates currently in use. This would enable those clients wishing to do so, to familiarise themselves with the steps to be performed in their software, by carrying out a simulation based on these certificates.

Management of the renewal of the server EBICS certificates is one of the last elements of the protocol lacking fluidity. We are confident that, just as with the OrderID, the EBICS company will be able to remedy this in the next 5 years by developing the standard.

Christophe Garnier

Read more