EBICS – Opportunities to internationalise

Thomas Stosberg, GTB Product Management, Deutsche Bank AG

After Germany and France, Switzerland is the third country to join the EBICS community, taking the internationalisation of EBICS a step further. Has EBICS got the potential to become an international standard and is this in the interest of customers and banks?


The various committees of a country that deal with the processing of (national) payments are keen to provide a stable and standardised payments solution for their customers and banks. Adapting a new standard always comes from a strong motivation to do so – stemming mainly from problems with technical security and/or costs to the company from the previous solution. Or put another way – countries with a workable solution for all the market players are highly unlikely to think about adapting a new standard. But for any countries considering a new standard, there could be merit in using EBICS.

The customer’s point of view

The customers that EBICS is aiming at – companies of all sizes, ranging from the very small to international concerns – are looking for a payments solution that meets two key requirements. On the one hand, it must be low in cost. And on the other, it must connect their own infrastructure to all the banks in a way that is simple, secure, accountable, automated and standardised (with regard to bank communication and the payment formats used). The latter allows all the banking partners to be integrated the same way. This enables payments to be spread flexibly over various banks and technical problems to be addressed using emergency planning.

EBICS can meet all these requirements set out by the customer. As far as implementation in Germany is concerned, the entire process can be automated with digital signatures without using certificates and a “corporate seal” authorisation.

And now that the CGI-MP-XML format is offered on the German market to make payments globally, this has also laid the foundations for establishing EBICS as an alternative in bank communication to a SWIFT or host-to-host connection for customers.

The bank’s point of view

In future, banks will no longer survive on the market with their own technical solutions. A technical solution (bank communication and payment format) specific to each bank is not considered a USP or sales argument by customers. And using and maintaining one provides no economic gain to the bank either.

Competition between banks will therefore be based solely on the services that they offer and the prices they charge. Customers assume that the technical solution used for payments is standardised – just like electricity coming from different plug sockets.

Introducing EBICS in France has shown that using a common standard tends to have little effect on one’s own customer base or profits. This is due to the fact that the customer interfaces in both countries are different and that customers don’t generally select their banking relationships according to the access channels provided.

In terms of customer interfaces, EBICS allows banks to offer this kind of standardised service for multiple countries. Furthermore, EBICS can also be used as clearing access for SEPA payments.


EBICS an opportunity to internationalise

To customers, EBICS represents an attractive form of bank communication. For banks, EBICS is the means to providing standardised access for many countries on the basis of one infrastructure. This is also particularly the case if a bank mainly operates in just one country because it can then look after its customers with subsidiaries in the SEPA area at no undue expense. With EBICS already adapted in the two largest European countries and Switzerland, there are already considerable numbers of EBICS users outside the core markets. These will continue to rise and also help EBICS become officially established in other countries and with more banks. EBICS spreading further would benefit all market players and, for countries needing to take action, is by far the best option for transforming the processing of payments.

Thomas Stosberg

Read more

How to enhance EBICS, Part 7 – Automatic bank key update: Is this even possible?

According to the EBICS specification, data is always transferred signed and encrypted. This applies to both directions of communication: customer > bank and bank > customer. In Germany, there are theoretically no limitations on the validity of the keys used for this. In France, at least the validity of the certificates is limited. For security reasons, it is absolutely necessary to renew the keys regularly. For the customer side, EBICS already provides functions for an automated key change for an EBICS user that has been initialised. However, the automatic renewal of bank keys is more difficult in practice. A “soft key change” is one solution.

The reason why banks do not like changing their EBICS keys

The EBICS customer system can download the public bank keys so that the file submission can be authenticated (identified by the bank) and encrypted with order type HPB at the bank. If the customer system is using invalid or out of date bank keys, it gets the negative return code EBICS_BANK_PUBKEY_UPDATE_REQUIRED in accordance with the EBICS specification.
This can cause the following problems:

• When the EBICS client receives the return code EBICS_BANK_PUBKEY_UPDATE_REQUIRED, it should download the current bank keys via HPB. This process is not always supported sufficiently by EBICS clients.
• After the bank keys are downloaded again, keys that are not CA- and certificate-based have to be released manually in the EBICS client by entering a hash value.
• The use of EBICS clients is often automated. The need to intercede manually when renewing the bank keys, e.g. to download the keys again or release them, is usually detected too late or not at all. Therefore, malfunctions are inevitable.

For these reasons, the operators of EBICS bank servers are wary of changing the bank keys. The following measures could help here.

The path to problem-free bank key changing

To be able to renew bank keys and certificates regularly without any problems, a “soft key change” should be enabled for starters. This means that not all customers have to update their bank keys from one day to the next.

A soft key change such as this is possible if the EBICS bank server is able to work in parallel with old and new bank key pairs. EBICS clients that detect a change and perform the update (in some cases automatically) use the new key, and the other clients continue to use the old one. In the latter case, the bank can contact the relevant customers.

All further measures must be implemented on the client and server sides by EBICS-CR EB-14-12. The CR has been decreed for the next EBICS specification and stipulates, among other things, that when bank keys are downloaded, the new bank keys are signed with the old bank authentication key (see www.ebics.org). Thus a manual release in the EBICS client is only required for the first bank key download. For every subsequent HPB order, the signature is checked and the bank keys are released automatically in the EBICS client if the check is successful.

With these functions, the renewal of the bank keys can be fully automated.

Michael Lembcke

Read more

SIBOS 2015: Payments in motion

At SIBOS in Singapore traditionally SWIFT is starring and EBICS plays a supporting role. Nevertheless, the interest in the use and the future development of EBICS was great. More than 8000 visitors came to the exhibition at the Sands Expo and Convention Centre. This made SIBOS in Singapore the biggest event in Asia and the second largest in the world. The prevailing topics show that there are going to be even more major changes in payments.

 

EBICS BTF

Switzerland joining the EBICS community means that the spread of EBICS continues apace. Until now, two EBICS dialects have been used: in Germany and in France. The Swiss will now add another one. To open up EBICS to other countries, a harmonisation will take place: EBICS BTF.
The background to EBICS BTF is the intent of all three countries to develop a uniform EBICS standard. Work on it is proceeding full speed ahead. Watch this space for more information on EBICS BTF.

Digitalisation

Payment transactions are highly automated in some countries. The processes for payments are almost completely digitalised, include one or more partners and reach far beyond their own system boundaries. Typical examples are SWIFT and EBICS, which can be used to exchange structured information between partners.

Other areas of banking could also benefit from the experience gathered in payments. The high degree of digitalisation could be used for loans, guarantees or documentary transactions, for example. This seems set to be the trend for the next few years.

Backing up payment flows

The amounts of money in payment transactions are astronomical. TARGET 2 handles nearly a quadrillion euros each year – that’s a one with fifteen zeroes! Obviously, the wheels of payment cannot stand still.

That’s why calls for backing up payment flows are growing. EBICS is pretty much the natural partner for SWIFT. The first rumours are circulating that recommendations will be made – and these will only be recommendations at present – to back up the digital transfer of money with a second transport mechanism.

Regulatory changes

In the past, payment has been dominated by regulatory requirements. The best examples are SEPA and ISO 20022. We estimate that in the next two years, there will be around 30 new trends and projects in payments – most of them driven by the regulators. The impacts on IT range from the deposit systems to the clearing system to the core banking system. In fact, all systems involved in payments will be affected. So it will not become boring.

Michael Lembcke

Read more

How to enhance EBICS, Part 6 – Unique identification of the acting person

Is it possible for a payment order that actually has to be authorised by two different persons in EBICS to be released by only one person? Yes, under certain circumstances this is possible. For certain contract constellations between the financial institution and the corporate customer, it is not possible to uniquely identify the acting person. 


The pitfall is in the EBICS data model

The corporate customer authorisation model for EBICS communication is based on the data model from EBICS. This differentiates between the customer and its employee as an EBICS user.
Corporate customers communicate with their bank via EBICS by means of an EBICS customer ID that is valid company-wide and the user ID of the acting employee. The bank assigns the IDs for the customer and its employees during the set up process; the customer requires the IDs to connect to the bank server for the accesses of the EBICS clients. However, this user ID is not always unique. How is this possible?

Corporate customers use different EBICS clients

Larger corporate customers sometimes use multiple EBICS clients from different producers. Depending on the functional scope involved, an employee may use different clients in parallel. One example is the employee who authorises and submits payments with one EBICS-PC product – and at the same time uses an EBICS-Mobile solution to authorise payments that have been sent directly to the bank from an ERP solution for the distributed electronic signature commonly used in Germany.

Keys and certificates are often not reusable


As the user-related keys and certificates are stored differently depending on the customer system and the EBICS country, in most cases an employee cannot use them for all EBICS clients. This means that the EBICS-PC product and the EBICS-Mobile solution each require their own keys for the user. Therefore, the employee has a different user ID in every client for his EBICS access to the bank, and this user ID secures the connection for his corresponding keys and certificates.

However, because the EBICS data model defines the EBICS user as a unique acting person, theoretically one person can use multiple user IDs to release payments that actually have to be authorised by multiple persons. The EBICS data model does not allow for the assignment of a person to multiple user IDs.

To prevent such misuse, EBICS bank servers now have additional individual authorisation functions, but it would still be desirable to have a standardised solution in the EBICS standard itself.

Standardised exchange format for keys and certificates

One option, for example, would be to prescribe a standard exchange format or a standard storage of the keys and certificates in the EBICS standard, e.g. a software token and storage in PKCS12 format. In this case, the user ID can be used uniquely to identify the acting person. Thus, keys and certificates can be used in combination with the user ID on multiple clients.

Michael Lembcke

Read more

What about EBICS in Morocco?

The rise of EBICS in Europe hardly needs to be demonstrated any longer. But what about its development outside the borders of the European Union? There is one continent that to me seems perfectly suited to the adoption of a modern, high-performing and universal protocol for final flow exchanges such as EBICS: Africa. To be more precise, Morocco is the first place I think of, for reasons explained below.


For a long time now, banks and financial institutions in Morocco have taken their inspiration from European banking practices; to be more precise, from French banking practices. Then, in the 1990s, Moroccan banks joined forces with French banks in choosing the ETEBAC protocol for telematic exchanges between businesses and banks, thus offering Moroccan businesses the option of implementing efficient cash management solutions.

All the same, the exchange formats used by the Moroccan banking industry have been greatly inspired by the CFONB formats, whether it comes to account statements or transfers and debits.
The ETEBAC protocol is still being used in Morocco. However, it works on X28 via private PADs and businesses must use asynchronous analogue modems, which are becoming more and more scarce. It is therefore becoming almost impossible to increase the number of businesses using ETEBAC. The proposed replacements are:

• Internet banking, which is not suitable for businesses with multiple banking relationships or with a large volume of transactions;
• SWIFT, which incurs significant and repeated additional charges;
• other lesser-used protocols such as PeSIT, which will not satisfy future requirements.

Morocco’s legal framework with regard to digital exchange of information and the protection thereof would indicate in favour of the adoption of data exchange protocols secured by means of electronic signature(s). This will offer bank transactions with the required security functions such as authentication, unalterability and integrity, privacy, no signature repetition and no repudiation. These are offered as standard by the EBICS protocol.

Moroccan banks, which are pioneers in Africa and which are present in 22 countries on that continent, need reliable, proven systems for transferring financial information between banks and across borders to ensure, among other things, that Morocco becomes a bank transfer hub capable of managing a maximum number of transactions in a secure and modern manner. EBICS is the right protocol to achieve this.

What is more, EBICS will not only allow the existing range of services to businesses to be fleshed out; it will also be a real opportunity for innovation for Moroccan banks, who will be able to use it to open up new services (such as e-invoicing).

And let us not forget two other usage areas where EBICS would be perfect:

1. It is already used in Europe for domestic inter-bank transfers to great satisfaction. Moroccan financial institutions would be able to do the same, which would give them the ability to improve the resilience and the high degree of availability of these inter-bank exchanges and, additionally, to optimise the costs thereof.
2. It may be used for data transfer for governmental digitisation projects, with regard in particular to social, medical and inter-service data.

Given what I have said, the EBICS protocol, which – as all readers of the blog will note – is spreading rapidly in Europe thanks to its universality, its ease of deployment, its high level of security and the absence of recurring costs, would seem to me to be an alternative choice for business-to-bank and bank-to-bank transfers. If, furthermore, the adoption of the ISO 20022 standard were to be considered by Moroccan banks, a great step would have been taken towards harmonisation and standardisation of financial flow exchanges which would also bring simplification and optimisation of transactions with Europe. This point seems to me to be particularly important, as the proximity of Morocco to the European continent has benefited the Moroccan economy due to the fact that the country has been able to profit from many relocations of European companies.

The question of migrating to EBICS thus arises. Would this be such a complex project that it could constitute an obstacle to adopting the protocol? If we think back to how the migration happened in France, I don’t think so. The experience gained when that happened, not only by software programmers for banks and companies, but also by the French banks that operate in Morocco, would be proof of a “soft” migration without the risk of having to be “guinea pigs”.

Marc Dutech

Read more

Migration of payment transactions in Switzerland: genuine end-to-end tests with EBICS

Banks in Switzerland are working hard on projects to implement the harmonisation of Swiss payment transactions in accordance with ISO 20022. Software manufacturers and corporate customers demand opportunities to test the new payment formats. What they are looking for is an end-to-end testing scenario that optimally reflects real-life processing by the bank. Very few banks in Switzerland can offer this type of test. This is where EBICS can help.


SIX Interbank Clearing, which is responsible for publishing the Swiss implementation, offers what is known as a validation platform. It can be used for validating the messages (pain and camt) according to syntax and simple business rules. This is generally the first port of call for tests in the new ISO system. However, this test is not enough for manufacturers and customers if they then want to convert day-to-day payment processes with their bank.

Usable end-to-end tests include orders as transactions in electronic account statements (e.g. MT940 or camt.053) and notifications (e.g. MT942 or camt.052) with balance tracking and errors that replicate real life (generating corresponding status reports and cancellations). “The difficulty with tests is often notification, which takes place based on the data supplied”, says Christoph Schenker of PostFinance. “The testing platform http://isotest.postfinance.ch offers all the options for deposits and withdrawals that software manufacturers need in order to get their software ISO-ready for customers.”

Customers are particularly keen to simulate errors before implementation so that they can see how their internal processes cope with exceptional situations. Typically these are errors such as insufficient funds, incorrect beneficiary account or similar problems that will occur in day-to-day use.
To expand the end-to-end concept a little further, it would be ideal if corporate customers could send payment processes to a test infrastructure directly from their ERP software using EBICS and then download the associated data, also using EBICS. Only then is a genuine “proof of the pudding” possible. What must be simulated in particular are error messages and processing realistic file sizes – in other words the kind of creditor process with several hundred payments that takes place in real life, and not just a test payment. This provides the necessary reassurance before putting the system into use. Direct connection to a testing platform via EBICS makes it possible to automate testing cycles and transfer large files using the EBICS protocol. This is very difficult on a testing platform that only has a manual web upload interface.

Innovative Swiss banks see ISO 20022 and EBICS as an ideal combination to help their customers harmonise payment. Institutions that can also offer end-to-end testing provide a genuinely valuable service for their customers. “SAP has supported credit transfer with ISO 20022 for several years. Good testing platforms and direct contact persons at financial institutions support the ongoing implementation of ISO20022 messages in Switzerland”, says Rainer Hofmeister from the manufacturer SAP.

Carsten Miehling

Read more

The Luzerner Kantonalbank AG offers corporate customers advanced solutions for EBICS and ISO 20022

Raphael Häfliger, Cash Management Services, Luzerner Kantonalbank AG

Since 2014, the Luzerner Kantonalbank AG (LUKB) has offered the EBICS communication standard in Switzerland, thus positioning a comprehensive service for professional payment transactions on the market. After the successful introduction of EBICS, it’s now time for the next step: As the first financial institution on the Swiss financial market, from autumn 2015 the LUKB will begin with the pilot phase of the launch of the “distributed electronic signature” (VEU). 
 
The VEU construct is the answer to an ever-increasing need of Swiss corporate customers. Customers can use the VEU to transfer payment orders to the LUKB and, depending on the authorisation construct, can have them finally approved by the persons responsible in the company. This additional process step differs from the EBICS arrangement normally used in Switzerland, whereby the interface works with an individual signature and the authorisations are regulated within the company’s own ERPs. In Germany the VEU is already standard, whereas in Switzerland it’s still a novelty.

By offering the VEU, the LUKB sees an opportunity to position itself as a flexible, customer-oriented financial institution. To implement an EBICS VEU, the LUKB engages with the customer in order to evaluate the suitable signature model. The specifics planned include the following:

• Two parties collectively
• Three parties collectively
• Groups with A and B signatures
• Further individual roles for accounts receivable and/or accounts payable
• Flexible assignment / exclusion of individual order types

However, there are additional reasons for working with the VEU. Due to operational risks, it can make sense to identify the persons responsible for the order assignment in EBICS. With the widely used corporate seals, in which only the company itself is identified, this is not possible. Additionally, in the future there could also be increasing pressure from the regulator or the auditing firms with regard to this issue.

In the starting phase, those customers with European software solutions in particular can be expected to use this service. Furthermore, the LUKB assumes that the local software manufacturers will also be integrating VEU solutions into their clients.

In its corporate customer communication, LUKB is going a step further and will be transporting the ISO 20022 format via EBICS from December 2015. Specifically, the pain.001, pain.002, camt.052 and camt.053 messages will be implemented. Camt.054 is expected to follow in spring 2016, thus completing the ISO range. With this scheme the LUKB will be among the first providers of a productive solution in the project for “harmonising payment transactions in Switzerland”. Along with the Swiss recommendations, the LUKB will also support the ISO and DK schemas (Germany) for the order assignment in ISO 20022. Depending on customer requirements, further schemes such as the French or Austrian formats will be analysed individually.

With its extensive product range for the EBICS VEU and ISO 20022, the LUKB is excellently prepared for the coming challenges on the Swiss corporate customer market.
www.lukb.ch/harmonisierung-zv
www.lukb.ch/direkt-ebics

Raphael Häfliger

Read more

Blog series: How to enhance EBICS, Part 5 – Customers manage accounts and subscribers themselves

EBICS itself provides useful order types for obtaining customer and subscriber information (note that not all manufacturers offer this consistently in their products). This is referring to, for example, order types HKD (call up customer data) and HTD (call up subscriber data). The major Swiss banks would like it to be possible to not only query this master data, but also manage and even change it oneself.

An anomaly of the Swiss implementation is the current restriction to signature types “T” and “E”. In the first case it is necessary to perform an additional approval via a separate channel (e.g. online banking). In the second case the order is processed immediately as the clients must themselves ensure that the necessary security measures are taken. Usually the person who has signed is not known in case “E”, rather only the customer or the contracting company.

The most important reason cited for not using the VEU in Switzerland is that the administration of the VEU rights for subscribers and accounts involves too much work. As the bank’s customer master data is often not directly linked to the EBICS product, data must be entered twice, and this becomes a significant overhead when you have a certain number of customers and changes to authorisations. What is needed is a mechanism along the lines of Electronic Bank Account Management (eBAM).
In the ISO 20022 standard, fifteen messages have already been modelled for these purposes (see acmt message category). The ISO messages can be used as a basis to expand the EBICS protocol so that customers can at least partially manage the accounts and subscribers themselves. Depending on the security requirement, multiple confirmations by the customer via signatures could be combined with a dual control principle on the bank’s side. For example, a delicate transaction would have to be checked twice by the customer and, in a final step, the bank would have to manually approve the transaction (but no longer create it from scratch).

This would already be possible today with a bank-specific order type (XYZ) for transferring XML account and subscriber data. The authorisations would be checked by the bank and applied automatically using the interface to the EBICS product (e.g. web services). From the Swiss perspective the mood is currently somewhat reserved on this matter, although many Swiss order types have already been introduced in this way, and the intention is to replace these in the near future with a general concept based on the French usage of FUL/FDL. We would welcome the inclusion of this requirement in a future order description in EBICS. Both customer and bank would benefit from increased automation.

Carsten Miehling

Read more

EBICS – on the way to the European market standard

Axel Weiß, Chairman of Board of Directors EBICS

Since 1995, corporate customers in Germany have handled payment transactions securely with every bank via a standard product and an electronic signature.

Already in 2003, the enhancement of the DFÜ Agreement was initiated by an internet-based version This variant of the DFÜ procedure was called EBICS “Electronic Banking Internet Communication Standard”. With this extension, the German banking industry met the requirement of customers and institutes for internet-based solutions in electronic banking.


The objective of this extension was to add internet protocol based transfer options to the uniform, multi-bank-capable bank standard “DFÜ with customers”, and thus extend the related range of application options. The current security requirements for corresponding securing mechanisms such as HTTPS are used here, with an additional strong authentication for the communication security.
EBICS is characterised by the following features:

• one standard for all banks and customers, i.e. corporate customers can use one software to access any bank that offers EBICS
• open standard, i.e. corporate customers can use standard products or individual software
• modern technology and license-free international standards such as XML, HTTPS, TLS, ZIP
• the highest security standards, e.g. encryption on the transport level and end-to-end
• one means of transport for all business processes such as direct debits, bank transfers, bank statements, cash management, stock orders and much more
• inclusion of service providers via multi-step signature concept
• approval of orders regardless of location
• the price and performance determine the competition, not the technology and the effort involved in changing the bank

Besides customer-bank communication, EBICS is used in Germany and increasingly in other EU countries for the secure, very cost-effective exchange of payment transactions between banks. Not least, the provision of a delivery channel for EBICS transactions at EBA Clearing led to a significant increase in the number of inter-bank transactions via EBICS, with around five per cent of all SEPA transactions processed by EBA Clearing now being processed via EBICS communication. As well as being used in the bilateral clearing of payments, EBICS is increasingly also being used as a backup solution to the existing communication channels, such as those provided by SWIFT.

In 2003, the English term “EBICS” was chosen to underline the desire to not only use this communication standard on a national level, but also to provide an alternative to existing approaches on European level for banks and their customers.

In Germany, banks were already obliged to support EBICS from 1 January 2008 onwards. The old FTAM standard has now completely replaced by EBICS.

In 2008, a cooperation agreement about EBICS was made between Germany and France. The French banking industry conducting a comprehensive make-or-buy analysis had recognised in advance that EBICS most comprehensively covers the requirements of French banks and their customers, and thus had the greatest potential to replace the ETEBAC communication standard used up to this point. It quickly became obvious to the participating banks and associations that the legally secure use of EBICS by all users would be by establishing a joint EBICS company. The purpose of the EBICS company lies primarily in the further development and maintenance of the EBICS standard and keeping the trademark.

After intensive negotiations between the German and French banking industries, the EBICS company was founded in June 2010. In setting up the EBICS SCRL based on Belgian law, close attention was paid to making the community non-profit-oriented and very lean, with minimal running costs. Additionally, it was ensured that the company is open to other banks interested in EBICS.
Therefore, the establishment of the company created the basis for the Europe-wide usage of the EBICS and its further development into a European market standard. In April this year, the declaration of membership of the SIX Interbank Clearing as the representative of the Swiss banking industry marked a further important step toward the Europeanisation of EBICS.

The declared aim is now to convince banking industries in other EU countries of the benefits of using, and in particular co-designing, EBICS – the doors are wide open to new participants in the EBICS community.

Axel Weiß

Read more

EBICS and mobile payments in France

In the “EBICS – a European standard for mobile payments” series, we will examine the situation in France.
A mobile solution allowing all users to sign for transactions remotely – in compliance with the EBICS TS protocol – would satisfy the requirements of the increasing number of “nomadic” signatories who are hoping that mobile banking with EBICS will soon finally become a reality.


This is on condition, however, that the solution is sufficiently flexible, meaning that it works on as wide a range of mobile phones and tablets as possible, regardless of their operating system (offering at least iOS, Android and Windows Mobile) and that it offers the same level of security as the EBICS TS signature software for PCs that is already used by thousands of signatories daily.

Mobile applications have certainly come of age courtesy of this or that editor, but they remain unsatisfactory and therefore little used since they don't possess the necessary flexibility or ease of use. Let us remember that, in order to conform to the specifications described by the CFONB in the implementation guide, each signature needs to have a personal signature certificate on a physical carrier delivered by a CA recognised by the bank. And that is what it is all about, because although it is possible to connect a USB token to certain tablets, it is still impossible to do so with all mobile devices, regardless of the brand. Or, if it is possible, it involves large and varying fees for adaptors and connections, may or may not work well and, worst of all, forces users to turn their device into a labyrinthine system, which dissuades even those with the best will in the world to use it regularly.
Furthermore, it seems neither reasonable nor opportune to oblige signatories to obtain an additional smartphone or tablet whose token connection is sufficiently convenient to be used whenever necessary.

One solution would be to replace the use of a physical carrier for storing the certificate with an ad hoc certificate for once-off use. But, apart from the fact that that would require the indispensable agreement of the CFONB, it would be necessary to re-register the certificate for a CA for each use, which would negate the flexibility of the system and thus its appeal.

This leaves the problem of the absence of standardisation for the distributed signature process, such as that enjoyed by our neighbours across the Rhine in the form of the Distributed Electronic Signature (VEU). Although it is regrettable, the fact that EBICS DS has not yet been realised does not mean that we cannot offer a coverage service that is functionally equivalent: one that allows travelling signatories to confirm orders before they are carried out. This management of signatory and signature book colleges is achieved by an upstream platform used by the company or by trusted providers and operators. Once the necessary number of signatures has been reached, only using the EBICS format (A005 or A006), the order and the retained signatures are forwarded to the server establishment via an EBICS file with a TS profile. It should be noted that this solution allows more comprehensive signature rights to be managed than those proposed by the EBICS (1+1 or 2) standard, which makes them potentially closer to users’ requirements.

Marc Dutech

Read more

High-availability payment transactions with EBICS and SWIFT

European inter-bank payment transactions move several trillion euros a day. This gigantic volume is processed bilaterally via national and European clearers such as TARGET2, STEP2 and SEPA-Clearer. The unobstructed flow of money is essential for the economy and for our entire way of life. For this reason, the IT systems involved are highly security-critical. Only the redundant use of the two transport protocols EBICS and SWIFT provides the necessary high-availability transport.


Astonishingly, the redundancies required are not applied consistently in the overall process. High availability is usually enabled by redundant in-house systems. However, a single point of failure remains: the electronic transport procedure; this must also be designed redundantly for system failures.

SWIFT and EBICS are the most widely-used transport protocols in international payment transactions. They guarantee high transfer security and a large volume – the two prerequisites for a dual-transport strategy. Additionally, the systems must be independent of each other. This is only fulfilled by a dual-vendor strategy. Therefore, the key to high availability is the combination of a dual-vendor strategy and a dual-transport strategy.

The dual-vendor strategy is already being used in highly security-critical scenarios to increase the failure safety. This rules out the manufacturer’s system from being the single point of failure.
Let us consider the dual-transport strategy with SWIFT and EBICS: The network topologies of the two transport protocols are complementary:

	SWIFT	EBICS
Topology	Star-shaped	Intermeshed
Management	Managed	Self-managed
Failure	Central	Self-healing
Mode of transfer	Cable	Cable and satellite

With EBICS, failures are resolved through self-healing, i.e. the data is rerouted automatically. With SWIFT, on the other hand, the star-shaped network is managed centrally. This complementarity is an advantage in the case of failures, as it inherently rules out a single point of failure. Due to the dual-vendor strategy, SWIFT and EBICS are independent of each other and are therefore predestined for the dual-transport strategy.

In the case of a failure, with EBICS the bank or clearing company can influence the technical transfer path. If the terrestrial lines are down, they can switch to radio or extra-terrestrial systems, i.e. to satellites. The entire populated globe can be reached via satellite. This is an advantage of EBICS over managed networks such as SWIFT.

But how does this look in practice? Considering the risks of inter-bank payment transactions, the combination of the dual-transport strategy with EBICS and SWIFT and the dual-vendor strategy is appropriate. Therefore it comes as no surprise that services such as STEP2 from EBA Clearing and the SEPA-Clearer of the German Bundesbank offer both EBICS and SWIFT as well as the dual-vendor strategy. It will soon be possible to switch between the two transport protocols in the background. German banks and one French bank are already using EBICS and SWIFT to minimise the damage caused by failures. Additional European and also American banks are sure to follow.
However, it is astonishing that the authorities have not entered this field as yet. The consequences of a failure would be incalculable.

Michael Lembcke

Read more

EBICS as the European standard for mobile payments?

With all the developments currently taking place in mobile payments, it's easy to get lost. New solution providers are almost sprouting like mushrooms and there's a whole maze of technical standards. In a growing field of business, banks risk being left behind. Could a European standard such as EBICS be an answer?


The same rules apply for mobile payments as for transaction-based EBICS payments: there has to be secure communication, unique authentication and the confidentiality of order and master data. In the case of mobile payments this means a “secure element” (SD card, SIM, HCE, etc.), and encompassing the various transfer techniques (QR code, barcode, NFC, BLE, etc.). At the moment, there seem to be no rules in place, with all types of players entering the market. From large credit card providers, hardware producers (Apple, Samsung) to specialised service providers – they are all currently vying with the banks for transferring payments. For banks the task is very challenging because institutions will be able to opt for some services but not all.

For uniform and secure payment transactions, app developers and clients would need a standard protocol such as EBICS or FinTS. Such standards are well established in the rest of the payments sector. And with rules set out with ISO 20022 and SEPA, it'd be possible to reach around 400 million European account holders immediately. The first standards for mobile payments are provided, for example, by Jiffy from SIA Italy, a solution based entirely on SEPA.

This would also be beneficial to consumers and banks in that no third parties are involved with transactions fees, as is particularly the case with credit card payments – and additionally with ApplePay. The institutions would regain control of the market. Organisations such as the European Payments Council (EPC) could introduce and refine the standard in Europe.

Perhaps it's pushing it a bit, calling EBICS the standard for mobile payments, because EBICS has been developed primarily for asynchronous processing. However, my fellow bloggers have already pointed out where there is potential to extend EBICS here: Interactions would have to be performed in real time. One synchronous response per single transaction would be necessary. If, in the near future, real-time clearing also becomes established throughout Europe, this might all be worthwhile. I wonder what your feedback will be.

Carsten Miehling

Read more

Why banks should phase out older versions of EBICS

Do you have any idea how many versions of EBICS are available? Do you know the status of your EBICS client? Which versions does the banking server allow? This article summarises the situation and explains how a proliferation of versions affects users.


EBICS came into official use in Germany on 1 January 2008, with version 2.3. Before that, some financial institutions had offered EBICS services using version 2.0 onwards. The first version developed jointly with France was 2.4, of which the final release 2.4.2 has been in use since 16 February 2010. The latest version of EBICS is version 2.5 of 16 May 2011, which is mainly offered by financial institutions in Germany and Switzerland. A new version 2.6 is currently being prepared likely for 2016. If we count all the versions that have been released and for which there have been implementations for banking servers and client systems, we come to a total of six (not including 2.6, which is yet to come).

Customers and banks need to use the same version of EBICS

The EBICS protocol is based on XML structures. New EBICS versions are characterised not only by new features and changes to the content, but also by a new version of the XML schema. Using the HEV job type based on the neutral H000 schema version, EBICS client systems can query the versions supported by the banking server, and when compatibility is established, continue communicating using the latest shared version. This means the EBICS banking server and the EBICS client system can only communicate without errors if their dialogue takes place using the same EBICS version. If too many versions are supported, there is a greater risk of the communication partners not having the same version. Data could not then be exchanged.

At the very least, an EBICS banking server which always supports every possible EBICS version would need a lot of maintenance. As well as this, all the improvements in new versions, including important security functions, would be undermined by the use of older versions. For this reason, when EBICS was specified it was agreed that banks should only have to support the latest EBICS version and its immediate predecessor.

Updates are missed – and that poses risks

In practice, things can be different. Partially through unawareness, customers fail to update their EBICS system to the latest version. Banks fail to notify their customers and continue to allow them to use older versions of EBICS. They lose track of the situation and the risks described above increase.
This is why we recommend that financial institutions keep an eye not only on their own EBICS versions but also the ones used by their corporate customers, and remind their customers to update them in good time. The financial institutions should deliberately stop supporting older versions and even phase them out completely. Corporate customers themselves should make sure they always have the latest EBICS software versions and plan regular updates.

It is important to keep track of the EBICS versions used and to minimise the risks by regularly updating. Because next year, probably it will be time for EBICS 2.6.

Read more

Blog series: How to enhance EBICS, Part 4 – Every person gets their own bank statement

A large proportion of the data that I get from a bank computer as a corporate client relates to an account. But how can I control, already at the point of access, which of my employees can obtain which bank statements for this data? Controls on the bank’s side can be helpful here.


EBICS regulates the provision and collection of any data via order types and format parameters. The data format relating to the order type ultimately determines the processing options in the EBICS bank computer. However, the actual content of the data provision and collection is not regulated via EBICS; therefore, this can differ from one EBICS bank computer to another, and from bank to bank.

Which EBICS subscriber receives which account information?

The data that employees obtain as EBICS subscribers is usually provided for each customer as a download on the bank computer. Every EBICS subscriber of the customer’s that has the relevant order type receives all the data available for the customer. This also applies to account-related data such as bank statements and interim transactions. When an EBICS data collection is performed, the account authorisation of the EBICS subscriber is not checked, but it is checked when payment transaction orders are submitted in the customer-bank relationship. EBICS itself does not provide for any account details in the EBICS message. Account-related checks and processing depend on the implementation of the bank computer – and essentially also on whether the account details for the data to be provided are complete and the accounts are found.

Account authorisation for obtaining data

In certain cases, an EBICS subscriber should only receive information for certain accounts. An obvious solution would be to provide the data per subscriber instead of per customer. However, because the data relates to the corporate customer, when there are multiple subscribers per customer this leads to redundant data and therefore an increased data volume. Therefore, it is preferable to store the data per customer as usual and control the collection of the data by means of the subscriber’s account authorisation (if the data is actually account-related). In this way, the subscriber always obtains precisely the data for all the accounts for which they are authorised.

It would make sense to also have an EBICS enhancement that allows one or even multiple accounts to be entered in the EBICS request – similarly to entering a time period in the historical request. With this EBICS function, an EBICS subscriber could optionally also obtain data for specific accounts. It is not always important to the subscriber for the account information for all accounts to be up-to-date. A corresponding EBICS enhancement enables a more targeted data collection and ultimately provides the customer with more flexibility when accessing accounts.

Michael Lembcke

Read more

“EBICS as a service” – An operating model for small and medium-sized financial institutions

It is actually undisputed that EBICS will establish itself as a transaction banking protocol in Switzerland. Major banks and larger cantonal banks already offer EBICS or are in the process of implementing an EBICS interface for their business customers. The next step would be a shared-use "EBICS as a service" platform, for which there is currently no provider.


The advantages of secure, standardized, and cost-effective point-to-point communication are so apparent that the topic is now cropping up on the agendas of even small and medium-sized financial institutions. Depending on the particular institute and the number of customers to be connected up to EBICS, the management of some banks consider the initial costs for purchasing, installing, and running an EBICS product to be prohibitive.

Product providers should take these concerns very seriously, especially when we consider that implementing an EBICS project entails costs on a five- to six-figure scale, which accounts for a sizeable chunk of many smaller banks' budgets. Particularly in Switzerland, where there are around a hundred institutes in this segment, such as smaller cantonal and private banks, the following question arises: Why is there no provider offering "EBICS as a service" yet in the local market? Shared use of an EBICS platform actually has clear advantages, and there are also providers in the market who seem ready-made for the role and would be capable of getting such an offer off the ground.
A multi-client enabled EBICS model could be implemented along the lines of outsourcing services for operating banking platforms. Once even a small number of bank participants are on board, the business case pays off, resulting in a win-win situation for everyone involved. The provider of the solution can present an expanded service portfolio to the market while quickly recouping the initial investment costs as use of the standard grows and spreads. Customers, in this case banks, can offer their business clients access at low investment costs and reduced operating costs, allowing them to catch up with the big banks in terms of the connectivity opportunities they provide.

What else is needed? Well, the right product of course, one that is designed for multi-client operation and that is optimized for running in data centres with respect to operating functionalities. Furthermore, an innovative banking IT solutions provider who is ready to be first into the breach is also required. As mentioned above, there are a few candidates in Switzerland, including the operators of Avaloq or Finnova solutions, classical data centres, and the insourcing solutions of larger institutes.

We are curious to see who will seize this opportunity in the Swiss market.

Carsten Miehling

Read more

EBICS event in Luxembourg met with great interest

The EBICS standard is currently gaining ground in Europe. That’s why experts are also taking an interest in the financial centre, Luxembourg. Payment transaction experts from the field and IT departments of Luxembourg banks met there on 28th January 2015 to learn more about EBICS. They had been invited to the event, entitled “EBICS – A New Communication Protocol for Payment Activities”, by the Luxembourg banking association, ABBL.


The main subject was whether EBICS could be of interest to Luxembourg. The agenda was geared towards this question, with the following speakers taking part and these topics discussed:

• Welcome, Serge Wagener, Banque et Caisse d’Epargne de l’Etat
• EBICS at a Glance - Security, Use and Implementations, Hermann Fürstenau, PPI AG
• EBICS - a chance to harmonise customer-to-bank communication standards for electronic banking in Europe, Axel Weiß, EBICS Chairman
• EBICS Strategy of Deutsche Bank, Thomas Stosberg, Deutsche Bank
• STEP2 and EBICS, Katja Heyder, EBA Clearing

EBICS was examined more closely as regards customer-bank and interbank communication, focusing particularly on secure data transfer with EBICS over the internet. The Luxembourg experts were also keen to learn more about the Distributed Electronic Signature and differences between the French and German EBICS versions.

The Luxembourg banking community was equally interested in the STEP2 access via EBICS to the European payment transfer hub because it allows costs cutting and back-up security. Each bank has to decide for itself how it can use STEP2 and EBICS. If, however, regulations should stipulate back-ups – which currently seems possible – EBICS is the best solution. For safety reasons, some banks are already operating two different infrastructures: SWIFT and EBICS. The complementary network topologies of EBICS and SWIFT are excellently suited for providing mutual back-up. But a main reason for using EBICS is also often costs.

A key motivation for the Luxembourg banks is, of course, that Germany and France have developed an EBICS standard together. And what is more, the EBICS standard is being further developed and promoted by a small, but efficient, EBICS community based in Brussels. Switzerland is currently taking its place in the EBICS community. Perhaps Luxembourg could then become the 4th member.
The idea of a “Global EBICS” is of strategic importance for some banks, and this was also borne out during discussions in Luxembourg. “Global EBICS” – or GBICS for short – goes hand-in-hand with a uniform ISO20022 format à la CGI (Common Global Implementation). CGI is the uniform format standard, and GBICS represents the transferral standard – worldwide! There was also great speculation as to whether there is a standard competing with EBICS: Is there a standard comparable to EBICS in the world, for example in Asia or America? The answer is a definite “no”. There seem to be, if any, just national standards and which are largely past their sell-by date. The outstanding technical and specialist capabilities of EBICS are undeniable. That’s why EBICS – or rather GBICS – really does have the potential to become a standard worldwide.

Michael Lembcke

Read more

EBICS and bank/company exchanges using SEPAmail™

On the initiative of large French banks (BPCE, CM-CIC, Société Générale, BNP Paribas, Crédit Agricole), SEPAmail™ has been designed to facilitate electronic exchanges between economic institutions of non-accounting documents for payments such as invoices, mandates, advices etc., using flows. This secure messaging system between banks therefore allows traditional payment operations (transfers, debits, etc.) to be carried out with new payment services geared towards client use.

This includes:

• Settlement by paperless invoice
• Reliability of IBAN and combating fraud on IBAN

For detailed information on SEPAmail™, please visit the website at www.sepamail.eu.
Using the 4-corner model forming the basis of the SEPAmail™ standard, exchanges can be divided into two main types:

• interbank exchanges performed solely in message mode (known as “missives” in SEPAmail™ terminology): web service or S/MIME
• bank/company exchanges, for which the exchange of files is specially adapted.

It is this exchange channel of files that PPI France became interested in, at a very early stage, with SEPAmail™. From December 2012 it actively participated in experiments aiming to prove the adequacy of EBICS in sending SEPAmail™ bi-directionally.
The trials particularly consisted of:

• Sending a missive and a batch of missives for transferring orders using the FUL order type,
• Recovering a missive and a batch of missives of processing acknowledgements from the transfer of a file of type pain.002, via the PSR order type.
• And up- and downloading a batch of missives of operation statements using the FDL order type.

With the usual configurations having been performed for the client installation and the bank server (TRAVIC software), the exchanges could be carried out and therefore demonstrated the possibility for both banks and clients to use their EBICS installations to proceed to SEPAmail™ exchanges.
These experiments enabled us to make some proposals, notably:

• drafting a document simplifying the naming of files,
• drafting an implementation guide for SEPAmail™ with EBICS, for use by banks, companies and service providers.

Certain providers and trusted operators have also recognised very quickly the interest in suggesting a SEPAmail™ offer supporting the EBICS channel. This is particularly the case with GFI which proposes the first complete solution complying with the standard for its bank or company clients.

“The strategy of our offer revolves around three fundamental principles:

• simplicity: minimum impact on the information system of our clients
• efficiency: optimised time to market
• cost control: minimising clients’ initial investments to make it easier to put the ecosystem in place

From this, the benefits of using the EBICS channel can be seen clearly. This channel guarantees, in effect, the levels of security and traceability needed for SEPAmail™ exchanges, while also relying on the mechanisms known and mastered by our clients with regard to exchanges between the bank and the company”, explains Lionel Chemla, director of the SEPAmail™ offer of Gfi.

And just like EBICS – which is now being widely used, not only in Germany and France, but also in Portugal, Switzerland, Austria and, soon, other European countries – SEPAmail™, conforming to ISO20022, will no doubt in future be of interest to European economic institutions situated outside France...

Marc Dutech

Read more

Blog series: How to enhance EBICS, Part 3 – EBICS is now also on-line

Is it really true that the requirements for corporate clients in e-banking are only geared towards file-based data exchange? Or are on-line administrative operations also affected? Why else do small corporate clients in particular often use e-banking solutions which are designed for private costumers?


The EBICS protocol was originally developed from file-transfer systems, and is outstanding in the secure and reliable exchange of large files between corporate clients and banks, as well as in internet bank transactions. The files being transferred are, according to the administrative operation, identified with order types or format parameters, which will then determine each process.

When submitting data via EBICS, the data connection where a user has been successfully authenticated is kept open only for the duration of the data transfer. The actual processing is usually carried out off-line. The processing results must then be downloaded via a separate administrative operation (PTK/HAC). Similarly, data being retrieved from the bank server, information on revenues for example, are routinely provided off-line for retrieval. This data can then be obtained as a file via EBICS.

The EBICS standard is currently not designed for the on-line acquisition of payment transaction orders and their authorisation, as well as the on-line retrieval of account information. These functionalities are supported by proprietary web-portals in consumer business and by national standards, such as HBCI and FinTS in Germany. If a corporate client today wants to use the preferences of on-line administrative operations and EBICS equally, he must, under certain circumstances, apply different solutions using various login data.

It might therefore be useful to extend the EBICS standard to the relevant on-line processes. For example:

• Account balance information: Via the EBICS protocol, on-line information could be provided detailing current account balances, while the connection in EBICS is kept open for data retrieval. The corporate client will thereby be kept up-to-date with current account information.
• Information on status and process results for submission orders: The customer needs to be aware of the status of each order. In conjunction with a customer order reference, which would have to be introduced (see blog post from 18 Dec 2014), an on-line individual request on order status will make the evaluation process for the corporate client considerably clearer and easier. Calling up the bank to inquire on the status of an order might then become unnecessary.

Of course, there would be other possible areas of application. It's important to note, however, that this doesn't mean competition with other standards or procedures in the private client sector. Rather, we should strive to adapt the EBICS standard to the needs of the banks and corporate clients, and thereby make EBICS future-proof.

Michael Lembcke

Read more

Blog series: How to enhance EBICS, Part 2 – delegating authorisations with EBICS and the Distributed Electronic Signature (VEU)

In this article, we shall continue the series we began in December on possible improvements to the EBICS standard. This post will focus mainly on the following issue: If one were to submit a payment transaction order today, the submitter wouldn't – at least with the standard features – have the option of managing additional authorisation procedures. In some cases, you only know who is eligible for the additional authorisation when you make the submission, so that it might be beneficial to delegate the authorisation on a case-by-case basis.

In the currently specified EBICS configuration, various authorisation models on the banking server end can be utilised for the submission and authorisation of order files by corporate clients. In practice, these models are always based on the signature categories E, A, B and T, the number of required signatures and the personal authorisations for a physical file. Moreover, credit institutions and software developers have extended the authorisation models so that they are appropriate for various usage scenarios. Such extensions include:

• Authorisations relating to an individual and an order, in conjunction with signature category, order type (i.e. specific administrative operations) and accounts.
• Various limit concepts, indexed by amounts, number of transactions, time frames, persons applicable, accounts and/or customers, as well as signature categories.
• Group concepts in conjunction with signature categories, such as approving authorisation rights for persons in exclusively different or exclusively the same groups.
• Proprietary signature categories which take their own evaluations for an authorisation into account.
• Procedures for service data centres (SRZ procedures), in which submission and authorisation processes run separately on the customer end.

All these models should be considered relatively static. This means, when an EBICS customer submits an order, he has very few possibilities to influence how the bank processes the business transaction. The master data established by the bank will always be the basis for approval, format verification and authorisation. Where a clear derivation of approvals in the EBICS environment on the bank's end is possible, this is generally reasonable and desirable. However, submission orders which require different processes depending on the circumstances cannot be processed in any other way in EBICS. For equivalent SEPA submissions with the order type CCT relating to a specific account, all persons approved for this account and this order type in the bank server for VEU would always be approved for authorisation.

Would it not be useful if a customer could, when submitting via EBICS, nominate specific persons to whom authorisation rights can be delegated? Of course, these individuals must have the correct basic authorisations on the bank's end. The upshot would be that individuals who are not nominated with the otherwise equivalent basic authorisations would not receive the order ready for VEU and therefore wouldn't be able to see it. This model can, for example, apply to cases in which a) arbitrary payments, salaries or honorarium-esque payments are processed from a certain account, and b) the payments are not given special transaction IDs. These IDs, however, remain dependent on format and country. With the right extensions to the EBICS standard, a solution independent of format may be viable.

Michael Lembcke

Read more