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