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

All goes ISO 20022

The title refers to the general migration to ISO 20022 in all payment transactions and the associated reporting. In this context, my colleague René Keller wrote about the plans of TARGET2 and SWIFT to now also implement the ISO 20022 standard, which is already familiar from SEPA, in individual and cross-border payments. The changes described there, especially in interbank payments, now also affect the customer-bank interface.

Just as the Corona pandemic has negative effects in many other places, consequences are also found by way of postponed migration schedules. The changes are coming – just a little later. The time should be used well, as the aspects are not purely IT-related. With the new standard, many processes in payments and associated fields will see fundamental changes and the impact must be considered for the architecture as a whole. This applies for both financial institutions and corporate customers, who will have to deal with a number of changes in the coming releases. The information in the announcements is now available in Appendix 3 of the DFÜ agreement and extends several years into the future – which is completely necessary.

Some make a point of saying that "the forthcoming changes are not that massive; after all, we are familiar with the XML format from SEPA". If the format used in SEPA is "well known", then that is indeed a very good starting point for preparing for the changes. However, there is much more to be considered. On the one hand, SEPA is about to make a release leap. On the other hand, especially in individual and cross-border payments, there is a whole range of special features that do not occur at all in mass payments. Moreover, for regulatory reasons, there will be a switch to structured address information. The challenge lies in the sheer sum of the changes.

camt.053 – version change

With the introduction of SEPA and the Europe-wide uniform format based on ISO 20022, the camt.053 account statement was also introduced alongside the previously common MT940. It was the ideal format for SEPA payments, as data from a uniform data dictionary could now also be transported as account statements via the formats pain (customer-bank) and pacs (interbank). But in addition to bookings in mass payments, there were also individual and cross-border payments. For this reason (and various others), quite a few companies stuck with the old familiar format.

However, the introduction of ISO 20022 in all interbank payments is now taking place on a current ISO release, the one from 2019. SEPA is still using the ISO release from 2009. As with any standard, there are of course various reasons for the further development of the ISO 20022 format, and there will continue to be. New fields will be introduced or code words will be extended. The account statement, which is to pass on all the new information to the end customer without any loss of data, must therefore also comply with the new standard, and so the conversion from camt.053.001.02 to the new release camt.053.001.08 is unavoidable (similarly for camt.052 and camt.054). As corporate customers have been informed at an early stage, sufficient time is now available for often lengthy ERP release cycles. Particularly as it is to be expected that a postponement of the TARGET2 migration to ISO 20022 will also delay the migration here.

MT940 discontinuation

SWIFT will discontinue the MT messages of categories 1, 2 and 9 in interbank communication as of November 2025. At the customer-bank interface (especially with SCORE), this restriction should not apply; in this respect, financial institutions worldwide are not forced to switch off MT101 or even MT940 in their service. However, the German Banking Industry Committee (DK) has decided this is necessary for our "multi-bank standard" – and that is a good thing. Financial institutions may still offer MT940 if they wish, but the advantages of the new standard are already obvious: entire XML structures can be transported from pain via pacs to camt without conversions. It is no big leap to the analogy of containers in logistics. And all corporate customers should be "pushed" towards these advantages.

DTAZV becomes pain.001

With the introduction of pain.001 as a customer order for a SEPA credit transfer, the question was quickly raised: why can't this format also be used for currency payments? The CGI-MP (Common Global Implementation - Market Practice) initiative of corporates, banks and manufacturers soon came together to harmonise the use of this global standard in order to establish a standardised mapping. But the CGI version of pain.001 is based, like the SEPA version, on the ISO release from 2009 – meaning pain.001.001.03. The CGI-MP is working on a new version (ISO release 2019) of the harmonised mapping. The new cross-border payment upload in Annex 3 will also be based on ISO 2019 – meaning pain.001.001.09.

And, as is so often the case, "all goes ISO 20022" also presents a great opportunity. An opportunity for continuous processes on the same data basis which can be handled without conversions. The basis for further digitisation remains standardisation. With "all goes ISO 20022", a continuous standard is available which can also be used for adjacent processes such as "exception & investigation" (queries), notifications, bank fee messages (camt.086 bank service billing) as well as for BAM (bank account management) as eBAM messages. This in turn means that payments (including account statements) are only a small part of the entire ISO universe.


Author: Mario Reichel

Don't fear standard software in the payments industry

Those who want to distinguish themselves from the competition develop their own software. This rule is becoming increasingly widespread among companies – and more and more "experts" advise financial institutions to increase in-house development of their own applications, or even to become tech companies. This philosophy starts to falter no later than when it comes to the payments platform.

For example, the supervisory authorities stipulate uninterrupted operation if the financial institution wants to process instant payments. We have experienced the resulting architectural challenges first-hand in our TRAVIC-Payment Hub. Add to this the numerous surrounding systems such as anti-money laundering or embargo and sanction lists, not to mention routing. Doing all of that in-house results in such high costs that many financial institutions would rather prefer not to do any payment processing at all and instead to have it done by a central institution within a large association. However, that is not an option if payments are to become a strategically important line of business.

Roundabout for payments

We have thus asked ourselves: what exactly is the "special ingredient" that financial institutions need to add to their payments systems in order to distinguish themselves from other competitors and be able to offer payment processing as their own product? This question is especially relevant if an institution applies as a service provider for corporate customers to process their payments in a specific region of the world. And lo and behold: in their core, many processes are quite similar from one financial institution to another. They mostly only differ with regard to the order the financial institutions perform them in. Following this insight, we have designed a payments platform that works like a roundabout. For each special function, there is an opportunity to "hop on" the platform in a different place, just like children on a fairground may hop on the roundabout anywhere they like (see Fig. 1).




TRAVIC-Payment Hub enables a financial institution to define any conceivable configuration. This applies both to the routing administration (which allows for almost any complexity of rule sets) and to the connected surrounding systems. But how does TRAVIC-Payment Hub know what is supposed to happen if, for example, the compliance system returns a certain status? Usually it is the surrounding systems that have to follow what the main system commands – so why should a financial institution, after possibly getting rid of one monolith in core processing, now acquire another in payments processing? The answer to this is an integrated workflow engine that has its own script language to connect the other systems comparatively easily – while also being independent of the manufacturer, i.e. of us.

The "Hub" in TRAVIC-Payment Hub is thus both a product name and a performance promise.

Software development inside out

In terms of technicality, we turn what would otherwise develop into "legacy" outwards. The implemented script language enables a financial institution to add its own business processes to TRAVIC-Payment Hub without having to open up the source code of the software. As technology and business aspects are separated, a significant part of software development thus moves from the sphere of the manufacturer into the sphere of the user. This means that the payments platform stays fit for release even though TRAVIC-Payment Hub may have to coordinate a complex network of surrounding systems. Additionally, the IT departments are not even tempted to develop too closely to the core payments processing and to run the risk of trying to modify something in one place and, in doing so, provoking a problem in another.

In practice, the procedure is as follows: TRAVIC-Payment Hub receives various statuses by the surrounding systems. The script language is used by in-house IT employees or the integration partner to define how payments with the respective statuses shall be handled. As soon as the workflow is fully defined, the system compiles the code so that TRAVIC-Payment Hub can start working. To this end, the workflow engine generates tasks which are then processed by an internal task engine. Here is a very simple example of how the script language developed by PPI for TRAVIC-Payment Hub handles OUR charges, i.e. determines whether the charges due may be enclosed with a payment and retained or whether a payment request must be created.  

Status CHECKINBOUNDCHRGS {
    if payment is inbound and (payment is ourCharges) then {
        if payment is ourChargesReceived then {
            just set status VALIDATERECEIVCHGS and leave step
        }
        if payment is correspondentChargeExpected then {
            if payment is debitAuthorized then {
                just set status CREATEADVICEOFCHGS and leave step
            }
            just set status CREATECHARGEREQ and leave step
        }
    }
    just set status DONE and leave step



Introducing TRAVIC-Payment Hub

With the TRAVIC product suite, PPI covers the entire payments process of a financial institution, from incoming payments over interbank communication up to clearing. TRAVIC-Payment Hub handles the core processing of payments. Our solution works as customer bank and as clearing bank – even in parallel operation – and can process instant payments. Moreover, the solution can be operated on site and as outsourced high-availability software in cooperation with our infrastructure partners.

Author: Thomas Riedel


Further information:





SEPA 2.0: the ISO 20022 update could lead to a triple migration

SEPA and the ISO 20022 standard it's based on can well be considered a pioneer amongst the global ISO 20022 initiatives. Very early on, they presented themselves as the rulebook for many different payment formats in the Euro zone, using a common format standard to enable cross-border and cross-system interoperability. Despite some local dialects, SEPA has enabled continuous end-to-end processing without media discontinuities and conversions over the past years - not least by harmonising national characteristics with a uniform EPC specification. End-to-end, in this case, refers not only to the interbank relationship but also to the relationship between ordering party and recipient. This is made possible by the consistent use of the uniform data dictionary in the ISO 20022 format standard, which provides a uniform basis for data exchange by transporting data elements from customer-bank messages (pain) to interbank messages (pacs) and all the way to bank-customer messages (camt) without conversions.

Where SEPA is evolving (for example, due to the introduction of instant payments), the ISO 20022 standard used for SEPA still needs to catch up: namely regarding the 2009 basis defined by the EPC. As this ISO standard is also constantly evolving to reflect current developments, the EPC working group responsible for further development of the SEPA scheme plans to migrate all schemes (SCT, SCT Inst, SDD Core, SDD B2B) to version 2019 of the ISO 20022 standard. The transition is to be announced in 2020 and will come into final effect in November 2022 within the scope of a big bang migration (of the interbank formats). This change, amongst others, is currently subject to public consultation as a major change request. During this phase, remarks are requested from the circle of parties participating in the consultation.

One of the reasons for deeming this CR important is the future support of Request to Pay, which cannot be provided with the current ISO version as future required elements are not available in its format. However, an up-to-date version of the ISO standard is also required for other future developments, especially in light of the TARGET2 and SWIFT MX migrations, which are also based on the 2019 version of the ISO standard.

The good news is: the ISO 20022 standard is already well established in the world of SEPA. Unlike with the SEPA introduction, there is no need to introduce a new format and no need to replace old formats on a large scale. Existing systems must "only" be adjusted and learn to process changes such as new data elements. Nevertheless, the challenge is to master a big bang migration with effects on interbank payments and formats at the customer-bank interface.

The bad news: due to current developments, the SEPA migration date now coincides with the beginning of the SWIFT transition phase from MT to MX. The original approach of setting the date for the SEPA migration to 2022 had been chosen in order to avoid having to carry out the three major migrations – TARGET2, SWIFT MX and SEPA ISO 20022 version 2019 – almost simultaneously and to distribute the necessary efforts onto different time frames. Should TARGET2 now also postpone the planned big bang migration by one year, as first demands from the market suggest, all migrations will once again coincide in time. This will pose immense challenges for the financial service providers involved and wreck the original approach of distribution. The blame for this is easily placed on the global coronavirus pandemic, which is currently putting a severe strain on our lives and the economy.

In this situation, financial institutions must keep an eye on further developments and adapt to the forthcoming changes. We will also closely monitor ongoing events and will continue to report on the SEPA ISO changes after the market consultation is completed.

Author: René Keller

PSD2: securing bulk payments via EBICS

The security of bulk payments has always been an issue. The early attempts to establish a simple protection against manipulation for this were rather half-hearted and therefore never led to reliable security. For example, the total of all recipient account numbers was formed to prevent criminals from subsequently changing the payments. But when the IBAN came along, even this extremely simple method was no longer useful – the financial institutions eventually abandoned it altogether simply because of the mathematical challenges involved.

All that remains to this day is the number of included payments and the total amount. Nobody claims that such values offer an effective protection.

More promising was the use of the PSD2 and RTS to provide more security for payments. However, they did not lead to a breakthrough for the bulk payments which are particularly common among corporate customers. The reason: displaying the recipient, account and amount and having the client check all the data contained, for example via dynamic linking, is hardly feasible for salary payments in a company with more than 10,000 employees. This is impossible from an organisational point of view alone and can hardly be realised using the established channels on the technical side.

So how do you make sure that the payment file, once created, is executed unchanged by the financial institution?

EBICS!

EBICS has been the standard in European corporate customer payments for years – available in all major countries with high transaction volumes, such as Germany, France, Austria and Switzerland. More countries will follow.

So why does the EBICS company not define a general and mandatory auditing standard based on international hash value procedures (e.g. SHA-256) and establish the corresponding set of rules? The principle: all applications which generate payment bulk files always generate the matching hash value and pass it to the financial institution together with the payment file. There, this check value can be recalculated as soon as the payment file arrives and presented to the customer for checking before release. That's it.

Simple and very effective, because the identical hash value guarantees that no manipulation has taken place between the creation of the bulk file and the processing of the bulk by the financial institution.

If, for the definition of the hash value procedure by the EBICS company, we then also consider the end customer, instead of the 32-double-value comparison an algorithm could be found which turns the hash value into a number consisting of 8-10 digits – similar to a TAN. Customers and users are already using these types of values today. A comparison of the check values only requires a minimal amount of time and is easy to do.

By the way, simply leaving the establishment of this definition to the market is not a good idea. If all of the players involved do their own thing, a multitude of different procedures are created, which confuse customers rather than provide additional security.

Therefore, it is one of the tasks of the EBICS company to provide a binding solution at this point and to, that way, also meet the demands of the PSD2 for bulk payments.

Author: Michael Schunk