Blog series: How to enhance EBICS, Part 1 – Customer order reference

In this new blog series I would like to create a regular opportunity to reflect on potential or desirable extensions to EBICS. Suggestions will have a specifically technical and specialised background, from which various solutions can be identified. To begin with, this first article in the series deals with customer order references.

Customers have often requested a reference to be sent with the order, e.g. a file name or randomly-assigned ID. This reference must be unique. In this way, the customer would be able to query the status of a specific order by using the reference, regardless of whether the order is still being processed or has been complete for days. In addition, a check can be carried out on the reference to ensure it was not submitted more than once.

At this point it should be clear that the existing four-digit order ID is not a satisfactory way to fulfil the above-mentioned requirements. Since EBICS version 2.5 the order ID has been issued by the EBICS server and is not unique.

The challenges can be met by introducing a customer order reference as an extension to the EBICS standard. In concrete terms, it could be implemented thus:

• An individual customer order reference is introduced, with a length of e.g. 512 characters. The customer order reference can be freely allocated by the customer. For instance, the file name, a random ID or a combination of both could be used. The customer order reference must be recorded in a log (PTK/HAC).
• The order reference would, for example, be tested for uniqueness in the EBICS server within 90 days for each customer. If an order is submitted with a customer order reference for which there has already been a successful upload, the new order will be declined. However, if a second upload with the same order reference initialises while the first upload is still running, the first (older) upload will be terminated with an error. In this way, the customer order reference can also be used if a transfer becomes unresponsive. This failure will always be logged in PTK/HAC.
• If the PTK/HAC entries of the bank's EBICS server are supplemented by entries e.g. from Clearing, the supplementing PTK/HAC entries should also contain the corresponding customer order reference insofar as they concern submissions.

The following orders would be possible as queries:

• The customer can specifically call up PTK/HAC for one or several customer order references. The PTK/HAC completed to that point in time will thereby be given back to the customer. The access status of PTK and HAC will remain unchanged.
• All customer order references which have already been submitted can be queried. The timespan here can be limited in a similar way to historic access. This would be a service function for the customer order references.

Introducing a customer order reference, individual query functionalities according to particular customer order references and the resulting double submission check would create a very powerful tool. The customer could search for individual submissions and would have the ability to establish an effective double submission checking system. The bank could extend the search capabilities for customers and thereby reduce queries to the bank. A double submission check would even be assigned to customers. Introducing the customer order reference concept would therefore be a win-win situation for both banks and customers. What more could we want?

Michael Lembcke

Read more

Initial difficulties in onboarding Swiss EBICS customers

In earlier posts we reported that the spread of EBICS in Switzerland has already begun. The first credit institutions have since started to offer the multibank-capable standard, with others still in negotiations. The focus is now slowly shifting towards corporate clients, who would benefit from the new interfaces. More precisely, the focus is now on the EBICS software to be installed on the client's end.

The first survey at the beginning of this year in the Swiss software development community for the support of EBICS in their clients' products, was thoroughly positive. The majority of suppliers has already implemented EBICS as protocol and can maintain productive links with both of the large banks. In order to allow customers to easily switch to another interface, some software solutions offer the so-called EBICS profile in their installation programs for each institution. Before initialising the installation, the customer decides which bank they want to connect with and the program automatically verifies key connection and configuration parameters according to the institution (version, EU procedure, host name, certificate issuer, supported order types, URL etc.).

If the customer then wishes to connect to another bank which also offers EBICS, they often need a new software version which, in accordance with the procedures just mentioned, will include the configuration specific to the institution. The once customer-friendly setup at once becomes much more complex; who wants to update the entire system each time you connect to a new bank? At this point a configuration-based approach would be desirable, in which the customer can register for themselves the relevant EBICS parameters for the new connection.

If the developer still then charges release fees for these updates, one cannot help feeling that there is profit being made here at the customer's expense from a relatively trivial problem. It is now the role of the banks to provide an overview for all the available solutions and to ensure this information is included in the counselling of clients, when it deals with the question of which EBICS software would be the most suitable for connecting to a specific institution.

For Swiss developers who have not installed an EBICS protocol, here is a final tip: Configuring a new EBICS connection should not be rocket science if it is ensured from the beginning that, for example, the customers themselves will control the process using a dialog window. For the integration of the EBICS protocol, we make reference at this point to the PPI EBICS-kernel (see software modules on the PPI homepage), which provides the full range of EBICS functionality in the form of a software library.

Carsten Miehling

Read more

SEPA Card Clearing – What does it have to do with EBICS?

Card payments, in addition to the Credit Transfer and Direct Debit administrative operations, are affected to a certain extent by the standardisation of payment transactions within the SEPA Single Euro Payment Area, whereas they were previously exchanged in national formats. The following article explains what this has to do with EBICS.

At the Point-of-Sale, two general types of card payments can be distinguished:

1. EDDP* direct debit authorised by manual signature of the customer
2. direct debit authorised by entering a PIN into a card reader
The EDDP direct debits are processed as normal SEPA direct debits. Those involving entering a PIN into a card reader are not automatically controlled by SEPA. However, it would also be more useful to replace the national formats with ISO20022 formats. These ISO formats are specified in SEPA Card Clearing (abbreviated SCC), which is subdivided as follows:

• Corporate Clients - Banking - Business
• Interbank Payment Transactions

In both fields particular requirements for the process, clearing and settlement mechanisms, as well as the data formats to be exchanged, must be taken into account. The EPC (European Payments Council) has specified certain targets for SEPA Card Clearing. The Berlin Group (www.berlin-group.org), a payment system and organisation initiative encompassing all of Europe, has specified detailed and coherent targets based on ISO20022. This specification, currently at version 2.0, also supports the requirements of the EPC on SEPA Card Clearing.

The delegates of the Berlin Group include participants from: Belgium, Bulgaria, Denmark, Germany, Estonia, Finland, France, Greece, the United Kingdom, Ireland, Iceland, Italy, Croatia, Latvia, Lithuania, Luxembourg, the Netherlands, Norway, Portugal, Sweden, Serbia, Spain, Turkey and Hungary. The SCC specifications of the Berlin Group is therefore a Europe-wide initiative. Work is currently under way to implement the SCC. In Germany the DK (Deutsche Kreditwirtschaft – German Banking Industry Committee) resolved to shift the balancing of card-based sales which are not based on EDDP from the old formats to the SCC formats and processes of the Berlin Group. Corporate clients, card issuers, card accepters, technical service providers (e.g. network operators), credit institutions and payment transaction processors will all be affected by the move from old formats to SCC. Because SCC – as with SEPA – deals with much larger volumes of data, the architecture of the IT systems should be reviewed and, if necessary, reconfigured before migrating to the new format.

What does all this have to do with EBICS? The DK resolved that EBICS should be used in conjunction with SCC. As of 23 April 2014, the administrative operations were extended to those of the SCC in appendix 2 of the EBICS specifications. This extension concerns interbank transactions and the corporate client sector. New administrative operations for data exchange were incorporated into the EBICS specifications in the form of new order types and formats. For example, the order types and formats in interbank transactions are included for the Deutsche Bundesbank via EBICS for the new SEPA-clearer SCC service. The Deutsche Bundesbank is also planning to abandon the old format, DTA. Additional extensions have also been made to EBICS for the European SCC in interbank payment transactions. For interbank payment transactions, EBA-Clearing offers STEP2 Card Clearing via EBICS with these administrative operations across Europe. Widespread testing of SCC is currently underway. Acceptance tests with the clearing houses EBA-Clearing and the Deutsche Bundesbank should be concluded by Spring 2015. A full migration from DTA to SEPA and thereby to SEPA Card Clearing should be complete by 2016. Time will only tell of how much interest this will be for banks in other European countries. The diversity of members in the Berlin Group is, however, promising.

---

* Electronic Direct Debit Procedure

Michael Lembcke

Read more

The Zürcher Kantonalbank takes on EBICS

For their electronic payment transactions, the Zürcher Kantonalbank has opted for a particularly stable and multibank-capable software solution. The largest of the Swiss Cantonal Banks will offer their corporate clients the internet-based electronic banking standard EBICS, which the Swiss credit institutions have agreed as a multibank-capable standard. In a request for proposal, PPI AG was able to prevail over numerous competitors with their electronic banking system TRAVIC-Corporate.

After the decision of the Swiss credit services sector for the particularly secure Electronic Banking Internet Communication Standard (EBICS), Switzerland opted into the European EBICS community in order to join France and Germany in its further development. Even for other European financial centres, EBICS is currently gaining more acceptance as the payment transaction standard in the corporate client segment.

The EBICS protocol is used by companies as an integral component of their payment systems to process electronic payment transactions. Transactions are typically the issuance of payment instructions or obtaining account statements, status reports and payment advice. Electronic signatures are used for approvals. As a highly available and inexpensive standard, EBICS can handle very large volumes of data quickly and securely.

For companies, the procedure has the advantage that more and more banks across Europe are offering EBICS, which, in addition to the single European payment format SEPA, is prevailing as a congruent transmission protocol.

Already by early 2014, the Luzerner Kantonalbank had opted for PPI's TRAVIC-Corporate system. Other large Swiss banks are showing an increased interest in the system used by market leaders for EBICS solutions. The Zürcher Kantonalbank uses PPI AG's new transmission protocol on the basis of TRAVIC-Corporate. "We are working closely with the bank and providing a bespoke integration solution to the existing banking systems" said Michael Lembcke, product manager at PPI, responsible for the integration project of the Zürcher Kantonalbank and RECON.

"The Zürcher Kantonalbank will link the system directly to the central user management, reducing administration costs and optimising the security of the entire system landscape" explains Carsten Miehling, managing director of RECON, the sales partner of PPI AG in Switzerland.

Michael Lembcke

Read more

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

More security, lower costs: STEP2 Clearing with EBICS

Since the end of last year, EBA Clearing has offered EBICS alongside SWIFT as an access channel for STEP2. The blueprints of this system came from the German Bundesbank, which in 2008 had already integrated its SEPA clearer to SWIFT and EBICS. For what reasons does EBA Clearing offer EBICS access along with SWIFT? The motivation for this came from a few financial institutions and savings banks in Germany. Costs were a significant factor: With EBICS, there are no transaction costs associated with transmission.


In bilateral clearing between banks, known as "garage clearing" and used extensively in Germany, there are no costs incurred for clearing or transmission. Each bank involved in the transmission assumes the costs of transmission and clearing itself. Costs will obviously arise in terms of clearing when migrating to a centralised clearing system. To avoid further escalating costs, the expenses for transmission covered by every credit institution should be kept as low as possible. Since there are no transaction costs associated with transmission – apart from the actual running costs – the decision went in favour of EBICS.

A second aspect is even more important: Security! For interbank payment transactions the daily sums of money transferred are within the billions. Any interruptions of cash flow of a mere few hours can lead to faults which can have drastic economic ramifications. Therefore, the need for a backup transmission procedure for clearing in interbank payment transactions is rising. EBICS would also be an excellent solution to this, for example as a backup for SWIFT. EBICS and SWIFT are already used in parallel at a few banks for clearing. It also seems unlikely that regulators will be content with only one transmission procedure for much longer. In almost all areas of banking, security obligations have been tightened, such as through the PSD II. Further security measures on interbank payment transactions in the future are therefore unlikely to be out of the question.

Michael Lembcke

Read more

EBICS Working Group Meeting: Switzerland secures new momentum in EBICS

The Swiss EBICS Working Group intends to put forward its ideas, particularly on order types, in September. This was one of the main results of the EBICS Working Group meeting held on 28 August. For the first time since the start of the German-French EBICS cooperation, the event was held in Switzerland. The reason is that Switzerland is preparing for its participation in the EBICS community. At the Hotel Renaissance in Zurich, within walking distance of the Swiss applicant SIX Interbank Clearing, experts from each of the three countries discussed the current situation in Switzerland and the planned extension of the new payment transaction standard.


The debate kicked off in spectacular fashion, again set off by the question whether Switzerland should adopt Germany's order type model or the French file parameter variant (FUL/FDL) for national usage. Albert Apolloner, head of the Swiss EBICS Working Group explored the pros and cons of each solution from a Swiss vantage point. He concluded in favour of the file parameter variant, which already covers the basic demands of the Swiss financial market and is deemed more flexible than the order type model. The German delegates outlined their solution, whereby each transaction type can be allocated an issuer, for example Switzerland or a larger bank.

From this discussion, the idea arose to translate all German transaction types according to the logic of the file parameter model. The client software developer would then exclusively implement this logic into their clients' systems, which would be an interesting prospect for the extension to other markets like Switzerland, Spain, Portugal and other candidates. In order to minimise costs on the part of the German institutions (familiar three-figure order types are currently passed on to the late processing stages), a mapping in the bank computer products could be a feasible solution. The transaction type AZV would then become "pain.xxx.azv", for example. In combination with the country code and the so-called "name/value pair", the requirements of each country and even other characteristics of major market players could be covered, for example the feature "This file has the specification Credit Suisse".

Unsurprisingly, the idea was not exactly met with a storm of enthusiasm on the German side. As a prospective vision for EBICS harmonisation, however, such a migration is not entirely inconceivable. During implementation, both models could surely continue to operate as standard for a transitional period. New markets would directly settle on the more universal FUL/FDL variant, to their own advantage.

In the second part of the conference, the issue of security was broached, in which Germany and France also have different approaches. Alain Hiltgen (UBS) suggested that there should be a recommendation in the EBICS Implementation Guide for using security tokens for retention of keys and certificates.

After lunch, Sabine Wenzel (SIZ) introduced the Swiss attendees with the EBICS community, the organisation and the decision-making processes for prospective expansion. According to the current plan, until the end of November 2014 it will be possible to submit a change request for the 2.6 release (to be put in effect in 2016). The Swiss Working Group intends to meet again in September to put forward further ideas, particularly on order types. Ideally, this can then already be discussed at the next conference of the international EBICS Working Group in Paris in November.

Conclusion: A very interesting forum for all EBICS enthusiasts. It left us with the impression that another player added to the team provides an additional boost to the further development of EBICS. More to follow.

Carsten Miehling

Read more

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

EBICS has arrived in Switzerland

Let us firstly take a look back at the seventh Petersberg Electronic Banking Forum held on 10 November 2011. Christian Schwinghammer from SIX Interbank Clearing Switzerland gives a presentation there on the topic "EBICS goes Europe - where is Switzerland?". Schwinghammer, an expert in the Swiss banking arena, was already rather confident that the standard will be implemented across all the Swiss financial institutions, particularly with two of the biggest heavyweights, UBS and Credit Suisse, already working with the EBICS communications channel.

However, the rapprochement often announced between the EBICS organisation and the Swiss delegates has been repeatedly delayed and has been progressing at glacial pace. Amid intensive tax dispute with Europe (on flat-rate withholding tax) and the US (FATCA), the topic of EBICS has taken a back seat on the part of the bank managers. Nevertheless, in early 2012, the EBICS working group, along with delegates of the Swiss banking giants were able to deliver an initial draft of the "EBICS Implementation Guide" to review.

Switzerland going solo in implementation guidelines

The Swiss implementation guidelines were created independently of the EBICS working group. This has been – and will continue to be – a topic of much debate. The working group for Swiss EBICS order types drew on the German prototype when dealing with freely available three-digit order types. For example, the order type "XKD" was allocated to the Swiss data carrier transfer process. Because UBS and Credit Suisse have primarily oriented their implementation to the German example and the three-digit order types are already in usage with customers, this model has become the de facto standard for Switzerland.

However, it seems that the Swiss often view the "FUL/FDL" model as a more flexible and architecturally elegant alternative. It has no connection to the German legacy of three-digit order types, which were already used in the previous protocol, FTAM. Moreover, it seems that in the expansion of the EBICS system across additional European countries and the world, the supply of three-digit combinations is dwindling. A changeover to the French model, however, would mean enormous costs.

Despite this prevailing discord, the Swiss seem to have definitively adopted EBICS. Its introduction across cantonal banks in Luzern this year and in Zurich early next year will deliver the much-needed impetus for distribution of the model across Switzerland. By all accounts, other cantonal banks are already at the starting line, evaluating EBICS-based solutions for their clients. In terms of joining the EBICS community, Switzerland has also made a lot of progress. There are specific offers on the table for entry into the community and the first tri-national summit of the EBICS working group is planned for August in Zurich.

It will be exciting to see how the “ménage-à-trois” will fare in practice. The Swiss could play an important role here, especially given their flair for diplomacy and multilingualism - rumour has it that the relationship between key stakeholders in Germany and France hasn't always been harmonic. The usage of the above-mentioned freely available order types in Switzerland is also a catalyst for a definitive change request directed toward the EBICS community (EB-14-DK-int04 OrderType with issuer). The use of an Issuer ID for each order type should facilitate the use of the same order types in another community. The Swiss order type for an order in the format "pain.001" (CCT) can easily be distinguished from the French and German formats, while an Issuer ID for the Swiss would be appended.

Carsten Miehling

Read more

The Luzerner Kantonalbank invests in EBICS

For the first time, EBICS is now fully supported by a Swiss cantonal bank. By using EBICS, the Luzerner Kantonalbank (LUKB) causes a stir in Switzerland. EBICS should be going live at LUKB in 2014. I am pleased to see that EBICS has expanded further and has now clearly accelerated in Switzerland. In this new change of pace, LUKB has acted as the prime mover.

From my point of view, Switzerland has adopted the system so quickly because of the following reasons:

1. EBICS uses the internet as a mode of communication which, in principle, is available at every company, meaning lower transfer costs for businesses. Moreover, EBICS products can be acquired in a relatively large market, which again offers a better price/performance ratio.


2. In Switzerland there has hitherto been no coherent standard for electronic communications between corporate clients and banks. If they had decided to develop their own standard, the result would probably have been very similar to EBICS. Thus it was advisable to make use of the original.

3. EBICS is a standard which was created by banks, for banks, so the EBICS process is fundamentally suited for Swiss financial institutions. Entry into the EBICS community also opens up the possibility of suggesting ways to improve the system.

4. The most innovative of all EBICS features is surely its multibank capablities. Even if the pros and cons are discussed here at great length, the decisive factor was ultimately the improvement of services for clients, which are a high priority for the Swiss banks.

5. Equally controversial debate surrounds the "Distributed Electronic Signature" (VEU). In contrast to Germany, Swiss banks can decide for themselves whether they would like to offer their customers this service or not. That the financial institutions can choose freely either way will surely facilitate the introduction of EBICS.

6. Obviously it was a decisive factor for Switzerland that Germany and France would also implement EBICS, and that other corporations active in Europe would be curious about the EBICS project. Moreover, new international clients can be won without having to change the infrastructure of corporate clients.

I believe these are the principle reasons that LUKB opted to implement the EBICS model. Particular attention should now be turned to the Distributed Electronic Signature system. It will be very interesting to see how it develops when the first banks and their customers begin to utilise it.

Michael Lembcke

Read more