Software producers and financial institution promote EBICS in Switzerland

Since 2013, the major Swiss banks have offered their corporate customers the EBICS communication standard. Since May 2015, Switzerland has been an official member of the EBICS committee that aims to promote and maintain the standard throughout all of Europe and beyond. To help EBICS make a definitive breakthrough, the leading EBICS producers and the major Swiss bank Credit Suisse have formed a work committee to promote EBICS in Switzerland (AFES). Swiss software producers benefit from a campaign that enables a smooth start with EBICS.


Submitting payment orders or obtaining electronic account statements are typical EBICS transactions. EBICS is especially popular in multi-banking, because companies can access different banks with just one identification. In the last few years, more and more medium-sized and smaller banks in Switzerland have also joined the EBICS movement, with proprietary interfaces gradually disappearing from the market. Recently discovered cases of internet fraud at companies have given the standard an additional boost, because the EBICS mechanism of the distributed electronic signature (VEU) significantly reduces the risk of an attack.

The AFES initiative offers interested producers the proven EBICS-Kernel from PPI – a software library optionally in Java or C code – as a starting package at very attractive conditions. As soon as the maintenance module and an onboarding package (optionally with access to an EBICS test server) have been agreed, the client is ready to go. Here Credit Suisse assumes the role of an intermediary and makes its infrastructure available for training purposes. This creates a win situation for all participants, and the Swiss banks benefit from the expected standardisation of the corporate banking interfaces.

The initiators anticipate that the standard will proliferate more rapidly in Switzerland. This will be welcomed by all, including foreign financial institutions in Europe that already offer EBICS as an interface. Experience has shown that standardisation is the basis for increased competition, with bank customers ultimately benefiting most of all. This is also borne out by current discussions in Europe that want to see banks increasingly obligated to provide open interfaces. In this context EBICS is certainly an important component, and we can be sure that further software producers and banks will launch joint initiatives.

More information on the initiative: www.ebics-initiative.ch.

Carsten Miehling

Read more

Instant payments at Sibos

This year Sibos took place in the tranquillity of Geneva. The airport was right next door, with the speeding planes leaving the runway in full view. Instant payments took off in similar fashion. It was one of the predominant topics at Sibos. The preparations for its introduction are going full blast.


Instant payments are probably a disruptive technology that will siphon off volumes from other payment methods. These include the mass payments currently running, for example, via EBICS, but also card payments - debit and credit card payments at the POS. Moreover, payments on the internet are expected to be increasingly made via instant payments. An attack on PayPal and Co?

Something that initially looks harmless can revolutionise the world of payments. Instant payments were referred to as “the new normal” at Sibos even though they haven’t really taken off yet, not even in Europe. However, this clearly shows the potential that is seen in instant payments. The “new” players of yesterday, such as PayPal and Co., could be tomorrow’s losers.

Up to now, instant payments solutions have been purely national solutions. Of course, the main volume of transactions with instant payments will be conducted within a local radius. But things will not necessarily stay that way. Instant payments that work throughout Europe could quickly result in the creation of new services. Banks will play a more significant role here than in the case of payments via credit cards or PayPal. In the process, they would defend their claim to be the leaders in the payments business and perhaps even manage to make up ground.

The limit of € 15,000 per instant payments transaction will be quickly increased. There is talk of amounts around the half-million mark. European banking groups are in the starting blocks waiting to lift this limit within their group from the word go. This could also be of interest to corporate customers. Industrial goods, services and other products are still being paid for in a fairly old-fashioned way that is expensive and long-winded. Instant payments could change all that. Of course, a transaction with instant payments may be expected to take a few seconds longer or even a number of minutes, say in the case of an amount in the millions or if embargo checks, AML and settlement are running synchronously. Fundamental, disruptive changes could also take place here.

Incidentally, instant payments are not initiated by PSD II. What a missed opportunity. The ECB took the lead here and did not venture the first step towards European instant payments. As yet, the interoperability with national instant payments solutions is not clear. Perhaps PSD III, which has already been announced in PSD II, will provide the required legal framework. At present, everything is voluntary and the effects – including those on mass payments with EBICS – are as yet uncertain. What is certain is that the Europeanisation of instant payments provides opportunities. And we should take them.

Michael Lembcke

Read more

EBICS and PSD2 – how will they work together?

The European Parliament’s Payment Services Directive PSD is the legal basis for the EU-wide uniform internal market for payments. The current version, PSD2, was published on 23/12/2015 in the Official Journal of the European Union and must be implemented in national legislation by 13/01/2018. How does the PSD2 affect EBICS?


The main aims of PSD2 are:

• Stricter security requirements for electronic payments
• Protection of consumers’ financial data
• Opening the market for payment service providers, particularly in the case of services for consumers and companies
• Strengthening of consumer rights, e.g. with regard to liability for unauthorised payments and refunds in the case of direct debits in euros
• Prohibition on charging surcharges, regardless of the payment instrument

Stricter security requirements of electronic payments demand that access to customer accounts be secure. The identification of a payment service user or a transaction requires strong authentication. EBICS fulfils these requirements with the asymmetrical user-related key procedures. There is thus nothing standing in the way of strong authentication.

The three basic pillars of strong authentication are known to be possession, inherence and knowledge. At least two of these criteria are to be offered to users when providing access to the EBICS authorisation. For example, a smartcard (possession) could allow authorisation as an EBICS key medium via a smartcard reader and PIN entry (knowledge). This must therefore be implemented on the client side of the interface.

In addition to the EBICS means of providing clear identification and authentication of the person, the bank can also include additional strengthening tests (inherence), e.g. whether the previously agreed IP addresses must be used for communication. An IP address that does not match will then prevent access even if the rest of the authentication does match.

The required dynamism in the authentication is formed by EBICS by means of the electronic signature procedure, as the signature is always formed using the hash value of the original file and a timestamp.

Furthermore, the EBICS function of the distributed electronic signature (VEU) allows the infrastructures for payment submissions and authorisations to be separated by the payment service user. For example, submission via an automatic device by EBICS may take place without authorisation and the required authorisations can be submitted separately via mobile app, an EBICS portal or other EBICS clients, i.e. separated in terms of both space and time. Furthermore, the authorisation conditions may require several people to be involved. Today’s EBICS solutions such as EBICS portals, EBICS browser solutions, EBICS mobile clients and other EBICS clients already offer this. This technology must be offered and used consistently for the PSD2.

Opening the payment market for payment service providers means that banks must provide the applications of third parties with access to customer data – if the customer agrees. In order to implement this requirement, interfaces are required. The EBICS standard offers its own usable interface. If the third-party supplier cannot obtain the information directly via the standard EBICS access, fast and flexible APIs are required that exchange the data as and when it is required. Uniformity and multiple usability are desirable.

In practice, user activities and, in particular, authorisations are already recorded in e-banking and payment applications. The strengthening of consumer rights pursued by PSD2 does, however, also require that service providers and banks make the payment processes and authorisations transparent and verifiable as well as log and store them as fully as possible in the user context. Within the context of EBICS, this applies to banks, but also to service providers that operate e.g. EBICS client applications.

In summary, PSD2 will not immediately have a direct effect on the EBICS specification itself. However, EBICS users must take the PSD2 into account within the usage context. The requirements of PSD2 must therefore be defined and implemented in good time for the operation and use of EBICS solutions. Time is ticking away.

Michael Lembcke

Read more

“Offline payment software in the sights of hackers – Swiss companies affected”

The above headline is taken from a statement by the Reporting and Analysis Centre for Information Assurance (MELANI) from July of this year. The statement describes a new type of hack on companies in Switzerland.

To process mass payments, especially in the case of multibank accounts, companies today generally use offline software for the transmission, approval and execution of electronic payment orders. Transfers are triggered automatically directly from within the ERP software and are transmitted to the bank via secure protocols. This type of payment processing accounts for the majority of the electronic payment orders executed in Switzerland today.


The malware described in the MELANI statement, “Dridex”, which spreads through malicious Microsoft Office documents in e-mails from ostensibly legitimate senders, has recently started focusing on precisely these kinds of offline software solutions. Manufacturers that enjoy a certain popularity in Switzerland are being targeted. Many companies are still somewhat uncertain as to how secure their solution really is and how they can guard against similar hacks.

To begin with, the security instructions that MELANI has been publishing for a long time – using dedicated computers, ignoring e-mails with suspicious attachments, regularly updating operating systems and anti-virus programs etc. – still apply when it comes to ensuring that your own infrastructure is protected. One instruction is of particular note, namely that collective rather than single signatures are to be used. How does that work in practice? After all, it is not as though we still use paper orders that can be physically signed by the company representatives and sent to the bank.
The banks offer two basic solutions (sometimes combined). On the one hand, approval via one channel is possible. This means that the file with the payment orders is sent directly from the offline software to the bank via the EBICS (Electronic Banking Internet Communication Standard) protocol, but the order has not yet been authorised for execution. Approval in the bank’s online banking system then allows the orders to be approved definitively by a second person.

Another secure and flexible type of collective signature is the use of the “distributed electronic signature” (VEU) contained within the EBICS standard. The standard is based on the signature models “transport” (no authorisation), “individual”, “collective A” and “collective B” signatures. For each order, the bank may also define a daily limit (per customer, per account or per order type, depending on requirements). VEU allows customers to mirror 1:1 the signature arrangements in place in their companies and, due to using several channels (e.g. issuance of second signature via a mobile device) results in a very high level of security.

More and more banks in Switzerland are introducing EBICS VEU as an offering within their e-banking solutions. Find out more about it from your bank or direct your questions to info@ppi.ch if you would like more information about EBICS VEU.

Original MELANI statement: https://www.melani.admin.ch/melani/de/home/dokumentation/newsletter/offline-payment-software.html

Carsten Miehling

Read more

EBICS mobile – any time, any place

Michael Schunk, Product Manager, PPI AG

The EBICS protocol is designed to transfer large data volumes, call up account information and authorise orders. These are the basic requirements of a treasurer and they are fulfilled by EBICS, guaranteeing the success of EBICS.

In the age of digitalisation, more and more information is provided at increasing speeds. Even EBICS must fulfil this requirement, and its response consists of mobile EBICS apps that inform the customer fast.

The speed advantage of EBICS apps is the result of two aspects:

• Push messages
  Targeted push messages remove the need for user queries. The user is actively informed about an event, e.g. an activation or a payment receipt.
• Independence of location
  Smartphones enable practically unlimited access to information. For example, one can submit an EBICS signature during a meeting.

The first EBICS apps contained serious defects that made them impractical to use:

• Download
  For a file to be signed, the entire file must be downloaded. This can involve a large number of megabytes. This makes signing a chore, and the monthly download volume is quickly used up.
• Performance
  When the account information is being called up, an XML-CAMT message first has to be parsed. The smartphone’s small CPU uses so much power for this that the battery quickly runs down. You can’t even check your e-mails while you wait because the entire capacity of the phone is being used.
• Security
  All three EBICS keys are kept on the smartphone or on a server. If the smartphone is stolen, everything is wide open to attack. Storing the keys on the server goes against all security requirements.

Be aware of these teething problems when buying EBICS apps. There are still too many of these problems on the market.

But back to the treasurer. What do they need?

• Current information about incoming and outgoing payments
• Authorisation of payments
• Active notification, e.g. for activations or expected payment receipts

The treasurer wants and needs to be informed at all times. What still seems impossible with classic EBICS customer systems will become a reality with EBICS apps. Push services actively inform the customer. If the customer is not on the move or does not want to receive any push messages, they can be informed by e-mail.

The figure shows HSH Nordbank’s new EBICS app for its corporate customers. More and more banks are using these digital options, making EBICS even more attractive.

Michael Schunk

Read more

Hacker attacks on SWIFT payments

81 million US dollars – criminals have stolen this enormous sum from the central bank of Bangladesh, not in a movie-style heist but very quietly via hacking. The thieves made more than 30 bank transfers from the account of the Bangladesh Bank at the New York Federal Reserve Bank (Fed) to Philippine accounts. This case and others show that inter-bank payments are a lucrative target, and that the security of the cinternational financial network is vulnerable. Penetrating this network certainly requires a lot of effort, however the loot that can be expected is even greater. In view of such professional attacks, the security of payments is at the top of the agenda once again.



The Bangladesh Bank was attacked on two levels in February 2016. Clearly the IT security mechanisms were inadequate: Supposedly the central bank has no firewall and only obsolete network technology. The thieves entered the bank network by this door and obtained the access data for bank transfers. In the SWIFT Alliance Access client they were able to use this data to authorise themselves as the ordering party for the transactions. For the Fed, the central bank of Bangladesh appeared as the originator.

According to BAE Systems, the security gap also allowed the attackers to install malware that they had programmed themselves on the SWIFT Alliance server. This software manipulated the confirmation messages of the SWIFT network and deactivated the access protection for the database. The transactions that were executed were not logged correctly, so that the thieves’ tracks were covered.

The hacker attacks completely disabled SWIFT’s security mechanisms and opened up almost unlimited opportunities for the thieves. The total amount of all of the requested transactions was actually 951 million US dollars. An unusual typing error in one message caused an involved bank in Bangladesh to query the bank transfer. This alone revealed the entire fraud. However, the 81 million had already been transferred and had disappeared into Philippine casinos and private hands. As a result, Atjur Rahman, head of the central bank of Bangladesh, and his deputies were forced to resign in March 2016.

SWIFT itself has conceded that multiple fraudulent messages were sent via the network in recent months. In May 2016, a commercial bank was the victim of a similar case of fraud: Criminals broke into the IT systems, accessed user data and manipulated messages. Now updates are to close the security gaps in the SWIFT software.

Even though SWIFT stresses that the attack has not called the security of the network into question but rather that of the access system, the case illustrates the dilemma posed by closed international networks. They cannot be completely walled off no matter how much technical know-how is applied. Aside from the software of the network operator, the surrounding bank systems can also present vulnerabilities. Not to mention criminal employees aiding and abetting fraud. And once the attackers are inside, the whole world is in their hands. This creates an incentive. A procedure such as EBICS uses the open internet and applies a security concept that is mainly based on keys for cryptography and authentication. This can provide an alternative to a closed network.

In view of the potentially enormous damage, inter-bank and corporate customer payments must be protected comprehensively. Cyber-attacks such as the ones described here can be expected to increase. Ultimately, the security mechanisms for the procedure and the bank IT, and those for employees, must mesh without any gaps.

Michael Lembcke

Read more

How to enhance EBICS, Part 8 – Preventing double submissions using EBICS tools: What’s going on?

It happened in a blink. The payment orders were accidentally transferred to the bank twice via EBICS. Nobody noticed. A number of such error cases are possible:

1. A payment was entered and sent twice in the order input.
2. The file with the payment orders was transferred again - for the second time.
3. For technical reasons, the payment file was transferred twice because the transfer status of the first transfer was not clear.

A double submission is basically a case of a customer submitting a payment or file with identical data to the bank again within a defined period of time. However, is an identical submission always a double submission that generally must be rejected? No, because some payments are deliberately prepared and transferred multiple times by the submitter.


So how can the bank side reliably detect real double submissions and prevent any damage to the customer?

It is possible to detect and reject obvious double submissions in the EBICS bank server already at the point of submission.

In the case of technical double submissions (see 3.), the EBICS protocol up to EBICS version 2.4 detects when a customer re-uses an order ID assigned by the EBICS client within a defined time period. From EBICS V2.5 onwards, the EBICS bank server already assigns a unique order ID when the communication is being set up. Therefore, a duplicate effect cannot occur as with EBICS V2.4.
However, the case of a file or order being re-sent accidentally in a new transfer operation, and thus with a new order ID (see 2.), cannot be ruled out at present with the existing EBICS tools on the EBICS bank server. To enable an effective double-submission check on the file level for this scenario, the EBICS-CR EB-14-08 DoubleUploadControl is being implemented with the next EBICS version.

This CR obligates the EBICS client to transfer a hash value relating to the payment file to the EBICS bank server. The client creates this hash value in any event for the signature creation. The EBICS bank server must check whether the hash value has already occurred in the relevant time period and reject the order if there is a double submission.

A more advanced double-submission check, e.g. on the single transaction level (case 1.), is more complicated and must still be implemented outside EBICS. If applicable, a bank employee must contact the customer to determine whether the double submission is actually deliberate.

The planned EBICS-CR EB-14-08 DoubleUploadControl further improves EBICS by adding another useful function. This is also necessary. It enables accidental double submissions to be prevented early. However, it is not a cure-all. It is still the case that bank applications cannot forego more advanced duplication checks.

Michael Lembcke

Read more

UBS goes EBICS

Patrik Giger, Head Payment Connectivity Services, UBS Switzerland AG
For the fifth time in a row, UBS was named “Best Domestic Cash Manager Switzerland” in the Cash Management Survey 2015 conducted by Euromoney. This success is a result of many years of focussing on customers’ needs and optimal product and service quality. 

One component of this range of services is the infrastructure for connecting customer systems directly, for which an interface based on proprietary data exchange has proven itself over the years. This direct connection is used by customers in Switzerland. Internationally, customers mostly use a connection via SWIFT for Corporates or multi-bank services to exchange payment data and reports with their financial institution. 

It is already possible now for UBS customers to execute their global financial transactions securely - in particular for international branches. A major goal of the new infrastructure is to make the connection to financial institutions more secure, convenient and standardised.


Harmonising payments as an opportunity – and a challenge

With the shared goal of “harmonising payments”, Swiss banks have agreed upon a plan to bring payments in Switzerland up to the international ISO 20022 standard by 2020 (for details see http://www.paymentstandards.ch/en/home.html)

Specifically, in the next 4 years the existing formats and processes will be changed in order to sustainably exploit synergies in the value chain between payment service providers, financial institutions and consumers. These synergies will ultimately benefit all parties involved in the payments. The path to this goal is not only steep. The time specifications set for achieving it are also ambitious. The effects that this transformation is going to have on the customer are often underestimated. The format change is almost certainly also going to be accompanied by changes in the procedures for corporate customers.

Software partners as a platform for the harmonization

The customers’ IT departments and the IT consultants and software firms play a decisive role in the migration of Swiss payments. Thus over 90 percent of UBS customers use the standard software of a producer established on the market for the direct connection to their banks. Customers have the clear expectation here that the corresponding ERP (Enterprise Resource Planning) and TMS (Treasury Management Software) programs will be able to handle the new ISO formats reliably and on schedule. To ease the path to the new ISO 20022 formats for the software producers, UBS has provided a dedicated test platform. It can be used to upload test files via a manual upload or an EBICS channel and to validate them. Along with the standardised error codes, the test results contain very detailed information on any errors or sub-optimal message configurations. The test platform also offers software providers a “readiness test” that verifies ISO 20022-compatibility for them and their customers.

Replacement of time-tested proprietary solution

UBS has offered EBICS to its customers as a communication channel since 2013. This product was selected by isolated customers with very specialised financial software. The majority of customers continue to use the proprietary solution. The main reason for this is that payments in Switzerland are very stable and have changed very little for decades. There was no reason for customers or local software providers to adapt the existing, effective solutions in the payments sector. The same applied to banks.

EBICS as ideal channel for ISO 20022

So why now also change the communication channels at the same time as the formats? Analyses have shown that the workload involved for the customers, as well as for the software partners and the banks, is similarly high for implementing the new formats in the old (proprietary) channel as for providing it via the new standardised EBICS channel.

Leading Swiss financial service providers already offer the connection via EBICS, or are planning to offer this connection in the near future.

The advantage of the EBICS standard is clear: customers will benefit from “banks speaking the same language”. In Switzerland, we also have the advantage of being able to count on a proven solution, as EBICS has established itself as a stable, reliable communication standard in the 10 years since it was introduced in Germany. With Switzerland becoming the third country to join the EBICS committee (along with Germany and France), a clear signal has been sent that the Swiss financial service providers support EBICS not as an auxiliary product but as a strategic communication channel.

Competition between standardised order types

With regard to order types, the German approach has established itself in Switzerland (providing the content with the order type), compared with the French approach that only has “upload” and “download” as order types. The order types in the “Swiss recommendation” will be harmonised to the greatest possible extent. The migration of the payments provides the great opportunity to go one step further. Thus, the Swiss EBICS order type “XE2” is currently valid for domestic bank transfers and for SEPA and foreign bank transfers. UBS advocates the extension of the order types in the future so that the full synergy effect of ISO 20022 and EBICS can be achieved. Specifically, separate EBICS order types are being discussed for domestic payments, foreign payments and SEPA payments. This proposal is being discussed intensively within the relevant committees, and UBS hopes that a standardisation can be achieved here with an additional synergy effect.

UBS goes EBICS – globally!

UBS has decided to replace the existing communication infrastructure for mass payments in Switzerland with a standardised EBICS infrastructure. UBS is now going one step further, in planning to also make EBICS a future protocol for their customers in the global booking centres in Europe, Asia and the USA. For this implementation, it is important for the infrastructure to be stable and standardised. Through our close collaboration with the PPI company, we are also in a position to recommend to customers without EBICS-compatible software a plugin that will perform the communication for the customer’s software in the future. We will also be offering the option of the “UBS KeyPort Web” EBICS portal in the future as an alternative for when customers want to upload their transactions as files or download the reporting messages manually via an Internet portal.
The EBICS products offered by UBS are primarily tailored to customers who want a direct connection to their ERP and TMS systems, and secondarily to customers who require a “multi-booking centre”-compatible portal for their mass payments. For individual transactions and additional information, our customers can continue to use the modern, very flexible UBS e-banking.

EBICS must continue developing

UBS will support both the German (DK) and French standards. The urgency of further harmonising is a given, because even with just three members on the EBICS committee, there is a wide range of different implementations. A corresponding further harmonization is being promoted by the EBICS committee under the BTF project name (see article in this blog by Sabine Wenzel, EBICS SCRL,  http://www.ebicsblog.com/en/internationally-in-harmony-with-ebics-btf/). From the author’s viewpoint, it is essential for this harmonization to be promoted as a very high priority. We are confident that EBICS will continue to enjoy global growth as a communication standard. UBS is present at the very forefront here, backing EBICS in Switzerland, in Germany, in Europe, in Asia and in the USA.

Patrik Giger

Read more

EBICS and TLS 1.2 – somewhat more secure but not without its snags

Curd Reinert, Project Manager EBICS-Kernel, PPI AG

Anyone looking at the EBICS specification might be surprised to learn that it still prescribes version 1.0 for the Transport Layer Security (TLS). At one time that was a very wise choice – when the EBICS specification was published, TLS 1.0 was the latest technology. So this was mainly a decision against SSL, which put manufacturers and operators in a nice position e.g. concerning POODLE. EBICS ruled out SSL and so EBICS applications were safe from POODLE. It wouldn’t have had much of a chance with an EBICS client anyway: the attacker makes the client send thousands of requests to the HTTPS server so that, for example, it can access the session cookie. But EBICS doesn’t use session cookies, and the clients aren’t web applications that would execute malicious JavaScript code to send thousands of requests. But try explaining that to the auditors!


And that was just one of the malicious attacks with the cute names – HEARTBLEED exploited a fault in the TLS implementation of OpenSSL. And then there’s BEAST. As with POODLE, EBICS should not be susceptible to a BEAST attack. But the reputation of TLS 1.0 has been permanently damaged and everyone is advising the use of its secure successor, TLS 1.2.

This was also recognised with EBICS and relevant change requests were planned for the next version so as to support TLS 1.2. Unfortunately, there’s a delay with this next version and, in the meantime, the auditors are asking: Why are you still using TLS 1.0 with EBICS? “Because that’s what it says in the specification” is hardly a valid reason anymore when the Federal Office for Information Security (BSI) is officially warning against this version. Therefore the Deutsche Kreditwirtschaft has published security recommendations on the official EBICS website advising the use of TLS 1.2 – with no explanation of how that fits in with the specification.

We tested 82 EBICS servers in Germany and France – only 52 servers could communicate with us using TLS 1.2. If, therefore, you are a customer product manufacturer and you decide today not to support TLS 1.0 anymore, you can no longer connect to around a third of the EBICS servers. It might be even worse for server operators with customer products in all kinds of versions.

So what can you do? You can offer TLS 1.2 without prohibiting TLS 1.0. This applies to both client and server, and in the TLS handshake both sides agree on the safest common variant – so the theory goes. And with 28 of the servers tested this did indeed work. But unfortunately, we also found two servers that abruptly break off communication when the client suggests TLS 1.2. For manufacturers of customer products this is very inconvenient because the clients cannot simply propose TLS 1.2 “on spec” – unless they accept that communication will fail with a few servers.

We notified the operators of the two EBICS servers. But because our test didn’t include every EBICS server, all operators should check the behaviour of their EBICS server themselves.

Another question comes to mind: How dangerous would the decryption of the TLS layer in EBICS actually be; what data would be visible? The order data itself is encrypted a second time and remains invisible to the attacker. So what remains is the XML frame around the order data or, as you would call it in the post-Snowden era, metadata. These are mainly the order type or the file format, customer and user ID. In other words, not a great deal. But whether this makes people happier is a completely different matter altogether.

Curd Reinert

Read more

EBICS on the Iberian peninsula

In 2014, the majority of Portuguese banks opened an EBICS channel based on version 2.4.2 of the protocol. Only the T profile is really used at the moment, however many companies would like to use the personal signatures that foreshadow the operation of the TS profile in the short term.
At the moment, very few Spanish banks offer their business customers the option of managing their financial transactions by means of the EBICS protocol. However, demand is getting more and more significant, as demonstrated by the presence of several participants at an event organised in Madrid by the Spanish Association of Corporate Finance Officers and Treasurers (ASSET) on 20 January.

Read this article in spanish (PDF)

This can be explained by such factors as Spanish companies, just like other European companies, having an increased need to carry out transactions with banks located outside of the peninsula.
Within the framework of this event, headed by Gerardo de la Mata, Director of ASSET and responsible for the payments commission, various presentations allowed the spotlight to be placed on EBICS and to make it familiar to the companies, banks and editors present. To this end, the participants tackled various and complementary topics such as:

• Axel Weiß, EBICS Chairman, detailed the development of EBICS, presented its main characteristics and benefits and went on to describe how EBICS SCRL functions.
• Notably, Thomas Stosberg, Deutsche Bank, presented the reasons why EBICS was developed and the experience gained, as well as its future evolution as part of BTF[1].
• The aim of my presentation was to describe in more detail certain subjects such as security and the use cases in France and Germany in the areas of both company/bank transactions and inter-bank transactions. I also highlighted the modalities of implementing EBICS as well as the migration progress in France.

The questions posed by the audience essentially dealt with a possible choice to operate between various exchange protocols currently used in Spain (Editran, Swift) and EBICS. The criteria of the choice seem rational.

Editran is admittedly a widely used protocol in Spain. However, it is only rarely, if at all, supported by banks and companies located outside Spain. It therefore does not respond to the requirements of companies and banks that need to carry out cross-border transactions.

These requirements thus need to be met by the use of one or more protocols that allow cross-border transactions. Depending on the context, as is already the case in France, for example, the use of EBICS and SWIFT is perfectly conceivable; EBICS can be used for communications with a growing number of banks located in various European countries, and SWIFT can be used with the others.
The costs of use also constitute an important deciding factor that could (should) encourage companies to optimise costs by using the most economical protocol.

One topic that also seems to have grabbed the attention of participants is the distributed electronic signature with EBICS, particularly on mobile devices, as is currently used in Germany (VEU). There is nothing surprising about that. What is more surprising is the fact that VEU is not really in operation in France.

A similar event will take place in Barcelona on 24 February and a number of participants have already confirmed their attendance. This is one more piece of evidence indicating that the financial industry demands a standardised, universal and efficient means of exchange, as is the case with EBICS.

[1] Business Transactions & Formats

Marc Dutech

Read more

Internationally in harmony with EBICS BTF

Sabine Wenzel, EBICS Secretary, EBICS SCRL


In 2010, the French CFONB and German DK banking authorities created a joint EBICS committee. One of its visions is to harmonise EBICS. The different procedures that already existed in these countries influenced the EBICS specification and are making it more difficult to implement EBICS. Germany and France use different approaches for the (short) identifiers for business transactions and for the formats to be used. This topic was given further momentum when Switzerland joined the EBICS SCRL. A harmonisation project was initiated with the goal of a standardised procedure for all of EBICS. This consolidation is known as EBICS BTF.


As a secure communication protocol, EBICS primarily ensures that all data is correctly authenticated, encrypted and authorised when it is being transferred.

Banks and corporate customers must be able to recognise which service is actually to be provided for the order. Accordingly, the EBICS server must check, for example

• whether the customer is using the correct data format and, if applicable, the suitable version (variant) of the standard and/or the relevant special implementation directives
• whether delivery rules have been observed and processing indicators have been set
  • the indicator for the number of electronic signatures that have been added to the order, and whether the customer can provide an additional required signature by means of VEU
  • the indicator for whether the order has been packed into a container
• whether additional options are specified for the service, e.g. for the DK the reference to the SDC procedure, or for France the customary test mode

These checks require compact information about the business transaction involved and whether the transfer was delivered in the correct format. This “label” on the EBICS order still has a different appearance in the different countries.

In Germany, three-letter codes are used. France has defined only two standard order types (for uploads and downloads), with an added file format parameter. Neither procedure is sufficient for international usage, i.e. in Switzerland currently. This non-standard approach is obstructing the proliferation of EBICS.

Therefore, the EBICS Board of Directors (BoD) has assigned the EBICS Working Group (made up of EBICS experts from Germany, France and Switzerland) the task of preparing a standard, structured solution for identifying “Business Transactions & Formats” (BTF). EBICS BTF is to be a component of the next EBICS version.

At present, the BTF concept consists of three blocks (element groups):

• Content – format/format standard used (if applicable, version used)
• Processing – indicator for EU and VEU for container used
• Service – information about the target system (if applicable, with 1..n options)

The advantage of this joint development: All participants have the same information about the values used for the XML elements and attributes. Thus, the “label” for standard business transactions (e.g. for the SEPA bank transfer) contains the same values in all countries. For country-specific versions, the BTF elements have different settings. This makes any differences transparent and easy to detect.
To achieve this standardised thinking, intensive specialist discussions were necessary – including discussions about the information that is really required for the identification and correct forwarding of the order. This information is to be complete and free of redundancies and contradictions. In particular, it was agreed to use external code lists where possible (corresponding codes for the data elements are to be agreed jointly and maintained in the EBICS SCRL).

In the EBICS Working Group, this solution is seen as very stable and has a high acceptance level. Ultimately, the EBICS communities must decide on the form and the time scale for the use of EBICS BTF in the coming years. To this end, national consultations are planned for the start of 2016 which will also involve the EBICS Working Group.

Sabine Wenzel

Read more