New data formats and the need for an EBICS update in Switzerland – what should be considered?

With the SIX EBICS V3.0 publication Swiss Market Practice Guidelines EBICS from June 2020, which contains recommendations for the implementation of the EBICS standard for the Swiss financial market, Switzerland is now also adapting the standard to the European harmonised protocol. The main drivers of the harmonisation were the members of the EBICS society, in particular the financial markets of Germany, France and Switzerland (the newest member is Austria).

By definition, two versions of EBICS are also supported in Switzerland, i.e. version 2.5 and version 3.0 in the future. At first glance, one could think that there is no urgent need for action on the part of customers and software manufacturers since the previous version is still being offered. If only in Switzerland the SIX document did not include the paragraph 2.2.1 EBICS Timeline with the following note: "To support the ISO 20022 schema migration to version 2019, the use of EBICS 3.0 is required."

As well-informed experts know, the ISO version 2019 is to be introduced for the customer-bank interface as of 2022. The current versions shall no longer be supported by 2024. This corresponds to the trend of global migration to this new version, e.g. in the projects SEPA, SWIFT MX or TARGET2 migration. This migration is of great importance, not least in view of the planned introduction of instant payments in Switzerland as of 2023.

The Swiss financial market has therefore decided to link the upgrade of the EBICS version with the upgrade of the ISO version. Against this background, customers and software manufacturers are faced with a few questions and challenges that should not be underestimated. The most important points are examined in the following paragraphs, and solutions are shown – wherever possible.

EBICS 3.0 will be available in Switzerland as of November 2021 at the latest

EBICS communication has now been fully established in Switzerland and is an indispensable part of the financial sector. So far, the EBICS version 2.5 is offered by the majority of financial institutions in Switzerland.

As already mentioned at the beginning, the Swiss Market Practice Guidelines EBICS (version 1.0 from 01/06/2020 by SIX, will officially introduce the new EBICS version 3.0 in Switzerland for corporate customer business with financial institutions as of November 2021.

Specifications by Switzerland for handling the new business transactions in EBICS

With the introduction of the new EBICS version 3.0, the previous version EBICS 2.5 will still be officially supported by financial institutions until the end of 2024. In addition, the acceptance of the new Swiss ISO 20020 formats in version 2019 requires EBICS 3.0. For corporate customers, this means that once they have updated their Swiss ISO formats, they can no longer easily use EBICS 2.5 for this purpose.

It is time to plan

These upcoming updates require that an adaptation of the software solutions be planned and implemented in good time. This is where financial institutions, corporate customers and software manufacturers must act.

Updating the ISO 20022 data formats to version 2019 is just one aspect. However, the changes to the EBICS protocol that are to be implemented with version 3.0 should not be underestimated. The most important requirements are:
  • The new business transaction format (BTF) replaces the previous order types and FileFormat parameters.
  • The transport of the public keys is now carried out uniformly with certificates.
  • The cryptographic procedures are improved.
  • The handling of bank keys is improved.
  • There are additional control parameters for electronic signatures.
  • A double submission check at file level is introduced.
So how to deal with these new requirements?

It is not only the financial institutions but also the software manufacturers of EBICS clients who have the task of extending their software solutions by EBICS 3.0, so that corporate customers can carry out updates and put them into production at an early stage.

All special features of EBICS 3.0 must be taken into account in the client, and it may be necessary to enable a mixed operation with different EBICS versions depending on the bank access and the EBICS users. In addition, the user should be offered migration options for the EBICS migration which avoid reinitialisation if possible (keyword increase of minimum key lengths).

The EBICS API – decoupling of business aspects and technology

From our own experience, we know that the migration to version 3.0 is not simply a matter of mapping order types to BTF combinations. There are many more challenges to overcome and aspects to reprogram respectively. This is especially the case if the financial institution, the software manufacturer and the customer want the migration to be as automated as possible. PPI has long been offering TRAVIC-EBICS-Kernel, an API solution for integration into proprietary EBICS clients. It is the central component for the handling of EBICS communication in almost every second EBICS client software in Europe.

With the latest version, the new specifics of EBICS 3.0 are, of course, already implemented. Correctly connected, the API transparently handles e-banking in all its variants and versions for the client. TRAVIC-EBICS-Kernel thus relieves the software manufacturers of e-banking and payments applications in the implementation of the standard protocol and its syntax as well as in security procedures. This solution fully reflects the EBICS specification and provides an easy-to-integrate interface that software manufacturers can connect to their software products as a convenient and quickly usable communication component.

Considering the cost/income ratio for the integration of TRAVIC-EBICS-Kernel, it is not surprising that this product is such a bestseller. Software manufacturers who do not use the TRAVIC-EBICS-Kernel can contact us at any time and request a test licence. The time for it has never been better than now, before the upcoming migration to EBICS 3.0.

Authors: Carsten Miehling and Michael Lembcke

Further information: Do you speak EBICS 3.0?

Setting up EBICS in no time

If you want to use EBICS, there is no room to make mistakes or forget anything. From users to accounts to rights: EBICS users have to keep in mind and configure many things. PPI has developed a wizard for its proprietary EBICS client (TRAVIC-Port) in order to compile the required data faster and, above all, centrally.

Granted, if you want to create a new EBICS user, you will have to go through quite a few clicks. The same is true for the PPI product world, i.e. TRAVIC-Port. The system requires an ID from each individual user, the master data, the initial password and a security medium which will be used for login later on. On top of that, the user takes on different roles, has different authorisations and often more than one bank connection. As TRAVIC-Port is multi-bank capable, the respective bank accesses must also be set up. Often the main bank takes over this task for its EBICS corporate customers - and this usually means long phone calls during which the bank employee has to query all this information.

Banks that have ordered the setup wizard will find a new entry directly on the start page (see Fig. 1) that makes their life much easier. Via a series of dialogs, the wizard queries all necessary data in order to create a new EBICS user.

The wizard also ensures that the data is entered in the correct places. This is particularly convenient because the system sets up the download agents via a different menu item than bank accesses and users, for example. Although this makes sense logically, it complicates quick input and makes new setups error-prone and tedious. Dialogs prevent important data from being omitted and enable you to see at a glance what information is actually required. For instance, the first thing to do is to set up a new bank account - whether this is done by the bank or an administrator on the customer side is irrelevant. The dialogue asks for all required information and shows how much work still lies ahead. As many as seven dialogs come together for the setup of a new bank access (see Fig. 2).

Once all bank accesses are set up, it's usually time for the individual users. For example, a small law firm wants to set up account authorisations for the owner, two employed lawyers and an assistant - specifically different ones for each individual. The owner naturally wants to have all rights, be able to order and release transactions without limits and, for example, issue releases for her colleagues via an electronic distributed signature. The two employed lawyers, on the other hand, are only allowed to release transactions up to a certain amount on their own - and the assistant may create payments but not release them. All four in turn should be able to see the account statements which are downloaded from the EBICS bank server. All these configurations are facilitated by a dialog that can create new colleagues for an already created corporate client (see Fig. 3).

You want to give yourself and your customers an edge when it comes to setting up EBICS? Get in touch with us. The setup wizard can be easily ordered via a CR and is subsequently available in TRAVIC-Port.

Author: Christian Veith 

SWIFT gpi – from obligation to opportunity

For November of 2020, the SWIFT release does not require any format changes for payment transactions for once. These were postponed until next year because of COVID-19. Still, the requirement for the so-called "universal confirmation" as part of SWIFT gpi remains. In simplified terms this means: for the credit in the MT103 format on the account of the beneficiary all FIN participants must send a response to SWIFT, specifically to the tracker. Rejections must also be reported, however, this does not replace the actual return. Thus, the payment sector once more has to cope with a (regulatory) mandatory project, which results in less resources for customer projects. But does it have to be like that? To answer this question, let us first look at what SWIFT gpi means.

Since 2016 the topic SWIFT gpi (global payment innovation) has become increasingly important. The core is a unique end-to-end reference, the UETR, which is given to the payment at the beginning of the correspondent banking chain and is maintained throughout all stages. This enables the tracking & tracing of payments, which had long been demanded for cross-border payments. The information is collected in the tracker. The tracker is a central database in the FIN cloud at SWIFT, which automatically reads the necessary information for each payment in FIN and is completed by further messages from the gpi financial institutions.

At first, UETR existed only within the CUG (closed user group) of the financial institutions participating in the gpi initiative, and only for customer payments (MT103). The standard service is also called gCCT (gpi for Customer Credit Transfer), which was soon completed by gCOV (gpi for Cover Payments). As of 2018, all FIN financial institutions are required to support the UETR, in addition to customer payments (MT103), for all bank-to-bank payments (MT202/205) – i.e. for all payments. First positive effects can be reported. With the UETR it is now possible to make statements such as "40 % of all gpi payments are final within 5 minutes" or "75 % of all gpi payments are final within 6 hours". Previously, there were only examples of payments that arrived very late (or not at all) or with no remittance information, but with high deductions for fees (including OUR), which led to many complaints with corresponding enquiries. A somewhat unexpected effect of the introduction of gpi was the drastic reduction in investigations.

If possible, a gpi financial institution undertakes to process the data on the same day, to waive the deduction of fees for OUR, to pass on the remittance information in full and unchanged (analogous to SEPA) – which should all go without saying – and of course to exchange information with the tracker (as soon as possible) not only on the status but also on fees and exchange rates. This information is then available to the payer bank as gpi bank. In this way, a further shortcoming of the cross-border payments – the lack of fee transparency – can be reduced. These benefits and in particular this information can then be communicated to the payer.

And then there is the issue of recalls. If need be, it should be possible to stop payments along the executing bank chain. However, same as the payment along the chain, the recall message is processed step-by-step by each involved financial institution. This is where the gpi additional service gSRP (gpi Stop and Recall Payments) comes in. The recall is reported to the tracker and the next attempt to transfer a payment to FIN with the relevant UETR is rejected. The long chain is skipped.

Now, with the "universal confirmation" the transparency is completed. This means that the payer bank not only receives the information "payment arrived at the last bank in the FIN chain", but also the status "payment arrived at the recipient". An acknowledgement was an integral part of the definition of SEPA instant payments from the beginning, but that was almost 50 years after the first SWIFT messages.

The FIN financial institutions are now required to report a "universal confirmation". This only applies to customer payments (MT103) and not to all payment receipts (M202/205). Reports must also be submitted for TARGET2 incomings, as these are transported via FINCopy. A "goodie" is the (manual) web access to this tracker, which was previously only available to gpi financial institutions.

The financial institution has up to 2 working days to report the "universal confirmation" (own public holidays are therefore excluded). This SLA will also be measured and the conduct of other financial institutions will be reported, but this will not start until mid-2021. Web access to the tracker is also made dependent on good behaviour.

Financial institutions with the smallest volume could consider manual reporting in the tracker. For automated solutions the payments platform should, for example, support one of the routes offered by SWIFT (MT199 or API). In addition, there is a so-called CSV solution in which corresponding messages are then generated to the tracker from a specific CSV report in the SWIFT interface.

Thus, a non-gpi bank must meet almost all the requirements that a gpi bank must fulfil. The missing step is no longer a big one, but the benefit for your own customers can be enormous. And with the options for gpi bank-to-bank payments (MT202/205 – called gFIT, which stands for Financial Institution Transfer service, an option for gpi banks), the financial institution's internal departments like treasury or money trading can also be given the security that the "payment has arrived".

However, for a financial institution it is not as important to receive the status messages from the tracker for sent payments, but rather to provide the customer with added value – in the best case the receipt "Payments received" (including information on fees and exchange rate). The service levels that a financial institution can offer range from the minimal version of manual access to the tracker via an own (corporate customer) hotline, to self-service offers in the online banking portal, to active information through notification with status reports to the corporate customer. And this is actually only possible by taking the step from the "universal confirmation" to the gpi standard service and opting for gpi. In the future, financial institutions with corporate banking will have to measure themselves against this.

Cross-departmental cooperation is required here; the services cannot be provided by the central administration department alone or even only by IT itself, as is often expected in "regulatory" projects during a SWIFT release. This can be achieved with a consultation that focuses on the overall process.

In summary, one can therefore state that it is not a long road from the mandatory requirements to enormous opportunities, and the prospects for additional services for corporate customers and also for internal bank departments are exiting.

Author: Mario Reichel

ISO 20022 – more topical than ever despite the dates being postponed

The decision has been made: on 27/07/2020, the European Central Bank has agreed with the vote of the European banking community to postpone the go-live date for the T2 and T2S consolidation by one year to November 2022. Similarly, the migration date for the Eurosystem Collateral Management System (ECMS) was postponed from November 2022 to no earlier than June 2023.

In the survey conducted in May, the European banks had declared themselves in favour of postponing the migration. In addition to the effects of the Corona pandemic, the main reasons for this include the postponement of the ISO migration for cross-border payments already announced by SWIFT. At many financial institutions, both migration scenarios converge in one project, since it is simply not possible to separate payments via TARGET2 from cross-border payments. Large financial institutions with extensive correspondent banking operations in particular saw major risks in the divergence of migration dates. With this decision both events have now been synchronised again. EBA Clearing has also joined in and postponed its migration to 2022.

The relief about the postponement was certainly great – but what does this decision mean for the financial institutions and their projects? The last thing that should happen now is for financial institutions to sit back and slow down their projects, as there is now an extra year’s time to implement them. That would be the worst solution at this stage. Many financial institutions have underestimated the effort that the TARGET2 migration entails. On the contrary, the postponement now offers the opportunity to continue with the projects at full speed in order to make up for lost time. Leaning back and leaving off now only to pick up the process in early 2021 is not an option. It should also be noted that the start phase of the user tests was only postponed by nine months from March 2021 to December 2021. Releasing external resources will mean that the people who previously worked in the projects and acquired knowledge will no longer be available.

It should also be borne in mind that the specifications, which have already undergone two new adjustments this year, will continue to be adapted. The ECB still has pending change requests which were not yet relevant for the November 2021 migration. This will certainly change with the postponement. It can be expected that with the new UDFS in November further functionalities will be offered, which will have to be evaluated and implemented.

The objective of SWIFT is also not yet clearly defined. So far, it is known that a transaction management platform is to be built, which will act as a central "hub" to handle cross-border payments. There are no published specifications for this yet. In addition, new ISO message types are currently being defined, for example for fees and cheques, which must also be considered and implemented. Thus, there is still much movement and uncertainty in the upcoming ISO migration. As such, might one not wonder whether there could be an even further postponement for SWIFT? How would the ECB react then? Could there also be a further postponement of TARGET2, or would we then have to accept that the migration dates diverge? How does one deal with changes in already harmonised message formats, such as pacs.004?

And as if that were not enough, the ECB's decision on instant payments is also causing a stir. Based on discussions with market participants of the AMI-Pay, the ECB council has decided that, on the one hand, all PSPs with TARGET2 that have subscribed to the SCT Inst scheme (i.e. instant payments) must be reachable in TIPS. On the other hand, all ACHs offering instant payments should move their technical accounts from TARGET2 to TIPS. The implementation is scheduled for the end of 2021. The ECB will thus make TIPS virtually obligatory for those who are already participating in the instant payments procedure. This is important because a large number of financial institutions today are using the EBA's RT1 procedure.

Also, so far only the decision itself has been made and announced. Further descriptions such as technical details are still unknown and will be published sometime later. One must also ask what a future pricing model will look like, especially if fees are charged for cross-ACH transactions. What can a transaction fee look like and what effect does this have on the pricing of the clearing houses? The question also arises whether there is an increased settlement risk for the settlement of positions such as RT1, as TIPS involves an additional participant in the chain.

What's more, SEPA will also switch to the new 2019 ISO version in 2023 - according to the currently announced plans of the EPC. The current gap of more than one year with regard to the migration of TARGET2 and SWIFT may seem a long time off. However, it has to be considered that a lot needs to be done before: reading specifications, writing business concepts and preparing systems. Despite the migration being postponed to 2023, it may not be underestimated and we recommend to deal with this issue as early as possible.

As is evident, the next three years will bring many topics related to ISO 20022 for financial institutions, and every institution would be well advised to use the time gained by the postponement to realign its priorities.

This requires highly specific know-how, and one should not indulge in short-term budget considerations and cut back on resources that will then be urgently needed again in 2021.

Authors: Sabine Aigner, Thomas Ambühler

Less stress with an “EBICS self-service”?

In my last EBICS blog post, I wrote about the difficulties that new EBICS customers face during initialisation (and how they could be alleviated). What makes it even more cumbersome is that new customers have to deal with the whole ordeal not just once – the same procedure has to be repeated for every single EBICS user.

Does it have to be like that? How about granting the first registered EBICS user, let's call them User 0, the right to create further EBICS users – and to authenticate them immediately? What would that look like?

Let us imagine a new administrative EBICS order type to which we give the exemplary name HUC (EBICS User Create). HUC would be an upload; the included EBICS message would contain the necessary master data of the new EBICS user as well as that user’s three certificates. The message is signed by User 0. With the data and the signature, the EBICS server can immediately set up the user; INI and HIA orders, letters and waiting times are eliminated. We get another ready-to-go user without any initialisation hassle. There are signs of a customer-side need for such an "EBICS self-service": after all, efforts are being made with EBAM to promote a very similar service for accounts.

If it were that simple, we would probably have done it already. However, one is immediately faced with two questions:

1. How do we control such a powerful EBICS user as User 0?

2. What kind of master data is actually necessary?

The first question is surprisingly easy to answer: because if there is one thing EBICS is really good at, it is checking authorisations. In order to prevent an overly powerful User 0, a User 1 is set up at the very beginning and it is specified that a HUC order requires several signatures. Thus a four-eyes principle is in place and the familiar mechanisms of E, A and B signatures enable a very precise configuration of who can set up additional employees along with whom.

The much more difficult question is: what kind of master data is required? Most people will agree that a name is probably necessary, but after that it becomes tricky. Do we want to know the address, telephone number and e-mail address of the user? Are they perhaps even mandatory? Or is it better not to burden oneself with unnecessary personal data considering the GDPR? So far, every financial institution can decide for itself, but HUC would set a standard for everyone. And nobody is helped if a standard essentially consists of a vast number of optional fields. The financial institutions would be called upon to agree on a meaningful set of binding data.

The difficulty of this can be seen in EBICS itself – with the order types HKD and HDT. Designed to enable a customer system to obtain information on the customer, the associated EBICS users and their authorisations from the financial institution, these two order types lead a rather shadowy existence as it was not possible to reconcile the historically developed authorisation models of the various financial institutions. On the contrary, many financial institutions see their special degrees of freedom in the allocation of rights as a unique selling point. This is not compatible with standardisation.

Therefore it seems that the inconsistent rights models mean the premature and certain death of an EBICS self-service. However, it really only seems that way. In reality, a financial institution needs the many ways of assigning rights to do justice to all its customers; the individual customer does not tend to need them or at least not all at once: how many roles are there for a typical corporate customer anyway? There are those who may submit orders but are not allowed to authorise them, those with limited or extensive signing authority for this or that account, and then there are those who may set up new EBICS users. All in all, about a handful of roles which are created at the same time as the EBICS agreement is set up and which can be used to play around with the full range of the financial institution's authorisation configuration. The role is then given a name which the customer can use (e.g. authorised signatory) and which can then be easily specified in the HUC request for the new authorised signatory.

Such a role model has even more advantages. It is possible to adapt the role to the new conditions of the company (an account has been added) without having to look at the authorisations of all EBICS users. The roles can also be reassigned. And it is easier to get an overview of who actually has which role and therefore which authorisation.

While the definition of the roles will inevitably remain a manual task, the assignment of the roles can be carried out in the EBICS self-service. Aside from creation, the service would then still be missing the possibility to read, update and delete the EBICS user, i.e. the R, the U and the D from CRUD. The corresponding order types could be called HUR, HUU and HUD. That would make for a nice first draft for the EBICS self-service.

And all the initialisation troubles would almost completely disappear into thin air.

Author: Curd Reinert

EBICS and EDS: weaknesses of salary payments with confidential information

For many years the electronic distributed signature (EDS) has been an important functionality used by various people to upload and release payments even from different locations.
The order types and their business content intended for this from the EBICS protocol permit a release based on the total data available – via the accompanying note – or based on the content payment data. For this purpose, the EBICS servers provide the most important information for each of the contained single payments already in prepared form. A customer system that shall display this data must not even know the specific payment format. That is what makes the software so convenient. As an exception, even a complete payment file can be transmitted. However, especially for large bulk payments this counters the convenience just described.
In payments practice, not only are simple payments and direct debits included in the ES folder but special payments with very personal data that requires special protection must be included as well. This includes pension and salary payments as well as bonuses and gratuities which are not intended for the general public and certainly not for inspection by the staff of a company.
This is exactly where a weakness of the EBICS specification becomes apparent: the business transaction code or purpose code that specifies the type of payment is missing when the single payments are transferred. That is why the EBICS products used by the customer are not able to protect the confidential data in a payment order, even if this was what the company wanted. The software lacks the criterion to decide whether payment details should be displayed or hidden.
Without an identifier in the specific payment order, it is not possible to distinguish confidential from normal payments. This means that the EDS is in principle unsuitable for checking and releasing salary payments by EDS because it cannot be ruled out that unauthorised employees will take a look at the possibly confidential information.
The EBICS society should therefore consider an extension to the XML for the HVT, which will also transmit this important information for the payment type. As long as this does not happen, the EDS can only be used for salary payments to a limited extent.
Author: Michael Schunk

EBICS: every beginning is hard

It is the nature of things that new customers’ first contact with EBICS is usually the initialisation process. This is somewhat unfortunate, because it means that right at the beginning of their EBICS experience, they are confronted with what is probably the most complicated and least intuitive part. And once new customers have successfully struggled through their own network technology, proxies, firewalls and the TLS, have properly and obediently transferred the data from the BPD sheet into the application – which hopefully guided them as simply and intuitively as possible through sending the two initialisation messages – they will be surprised to find that they are by no means ready to finally use EBICS. Instead, they must first print out, sign and send a multi-page INI letter to their financial institution. And then they wait. They wait until the letter has arrived and a bank employee has entered the 192 hex digits of the hash values of the three EBICS keys into the bank server. Possibly even involving a four-eyes principle process.

Once that is dealt with – and there is usually no clue as to if and when exactly it happens – the new customers can at last use EBICS. Almost. Before that they must download the bank keys and confirm their hash values, which they compare hopefully carefully with those on the BPD sheet.

After this trauma of initial initialisation, the rest is almost a walk in the park. Own keys can be renewed in many applications at the push of a button. New bank keys can now be signed with the old ones and accepted automatically. Things only become really unpleasant if – for whatever reason – a complete reinitialisation becomes necessary.

France, you are (a little) better off

French EBICS customers who read this blog may wonder what I am going on about. Network and TLS may not be any easier to handle in France than elsewhere and the BPD sheet must also be typed out, but at least the actual EBICS key exchange is as simple as one could wish for thanks to CA-based certificates: EBICS users send their keys as certificates, which the financial institution can validate and release directly based on the signature of the issuing certificate authority. The EBICS client can thus download the bank keys as certificates immediately afterwards. And if these certificates were also issued by a CA and the client trusts this CA, then nothing stands in the way of starting an EBICS communication.

This apparent effortlessness is a little deceptive, of course, as the certificates do not just drop from the sky either. The certification process is not necessarily simpler than the EBICS initialisation, because in this case, too, a person and that person's digital identity have to be matched securely. The main advantage is that the process is not regarded as part of EBICS and is therefore not blamed on the protocol. And of course, a certificate can be used for many purposes – the EBICS initialisation, on the other hand, is only ever valid for exactly one EBICS user at exactly one financial institution.

I will only mention in passing the fact that certificates bring with them other problems, such as regular renewal costs, the problem of agreeing on a list of trustworthy CAs as globally as possible, and interesting failure scenarios if there is only one generally recognised provider for the online verification of certificates.

In other words, the process remains a struggle, but we believe that it need not stay that way. In a brainstorming session, we came up with two ideas that we want to present here – even at the risk that they may prove to be entirely lacking in practicality.

Option 1: face to face

Our first idea is based on the assumption that the future EBICS users will sit down with a bank advisor in order to have the advisor activate EBICS for them. While the bank advisor enters the necessary data such as name, address, customer and EBICS user ID into the system, at one point he or she passes the keyboard to the EBICS user, who enters a freely chosen one-time password – and repeats it, as usual, to rule out typos. The EBICS user must remember the password until logging in to the EBICS client and then enter it again when setting up the bank access. With the help of the password, a symmetrical key is generated and used to encrypt the initialisation message – which contains all three EBICS keys. Since the bank server knows the password, it can generate the same symmetric key and communication is protected against interception, manipulation and even man-in-the-middle attacks. Therefore, the server can also return the bank keys directly as part of the response. The initialisation password is no longer required (and must not be reused for later reinitialisations either).

The result: after a single EBICS message, the EBICS user is completely initialised and ready for EBICS. On the bank side, once the setup is complete, the manual steps are eliminated. The customer does not have to send a letter and – most importantly – does not have to wait!

Two possible problems come to mind with this scenario:

  1. An attacker who knows both the financial institution and the EBICS user well enough could guess the customer ID and EBICS user ID as well as the password that the customer has come up with and log in before the legitimate user does. The process can, for example, be protected by a PIN, which is generated and given to the EBICS user during setup, as well as by a lock after n failed attempts.
  2. The errors that the server reports back when someone wildly guesses the key could allow oracle attacks. This problem could also be helped if the EBICS user is completely locked after n failed attempts.

The issues could thus be solved.

Option 2: all digital

Option 1 is still a little bit stuck in the traditional way: the customer gets a piece of paper, the data from it must be typed into the application ... But why? Why not give the customer the data digitally instead? E.g. on a USB drive, on which the bank advisor directly stores the data before handing it over to the customer, who is then free to keep it – naturally with the bank's advertising imprint. The USB drive would then contain a file that includes everything needed for the setup:

  • The URL
  • The IDs
  • A symmetric key, which is used to secure the initial communication in the same way as with option 1

Obviously, there is no need to take into account how much a person can remember or is willing to type; the key can be as long as desired. Attacks by means of guessing the key are no longer an issue. The biggest risk is still that the customer loses the USB drive on the way home. But again, a password protection of the file can help.

Once, however, the EBICS user makes it home safely with the drive, he or she imports the file into the EBICS application. The latter recognises the format and can thus immediately and autonomously set up the complete bank access – as described in option 1.

What if my system has no USB port? Then it may be a smartphone on which I want to register for a signature app, for example. In that case, it may not have much use for USB, but it can do a lot with QR codes. So the data can be provided this way. Or perhaps it is company policy that does not allow the use of USB drives, not even from such a trustworthy source as my financial institution. Then one could of course consider simply sending the file by e-mail. And once the thought has crossed one's mind, one wonders whether it needs a USB stick at all. And the answer is probably no, if (a) the file is cryptographically secured with a sufficiently good password and (b) the password is not included in the same e-mail, but is transmitted in a different, secure way. That should be manageable.

Achieving the goal

The initialisation can be simplified. But for this simplification to be of any use, it is not enough for just one financial institution to implement it or – even more absurdly – just one customer system (provider). Only if such a change becomes part of the EBICS specification can it make life easier for customers and financial institutions. But then, the improvement will be considerable: for the customer, setting up a bank access is no longer a nuisance, and the financial institutions can save themselves the hassle of typing in hash values. There are employees in call centres who in fact do nothing else.

If the initialisation is simplified this much, it is perhaps no longer a problem that it must be carried out individually for each EBICS user. Still, we have given thought to ways of simplification for that aspect, as well – which I will happy to share in a later blog post.

Author: Curd Reinert