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

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


The pitfall is in the EBICS data model

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

Corporate customers use different EBICS clients

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

Keys and certificates are often not reusable


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

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

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

Standardised exchange format for keys and certificates

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

Michael Lembcke

What about EBICS in Morocco?

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


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

All the same, the exchange formats used by the Moroccan banking industry have been greatly inspired by the CFONB formats, whether it comes to account statements or transfers and debits.
The ETEBAC protocol is still being used in Morocco. However, it works on X28 via private PADs and businesses must use asynchronous analogue modems, which are becoming more and more scarce. It is therefore becoming almost impossible to increase the number of businesses using ETEBAC. The proposed replacements are:
  • Internet banking, which is not suitable for businesses with multiple banking relationships or with a large volume of transactions;
  • SWIFT, which incurs significant and repeated additional charges;
  • other lesser-used protocols such as PeSIT, which will not satisfy future requirements.
Morocco’s legal framework with regard to digital exchange of information and the protection thereof would indicate in favour of the adoption of data exchange protocols secured by means of electronic signature(s). This will offer bank transactions with the required security functions such as authentication, unalterability and integrity, privacy, no signature repetition and no repudiation. These are offered as standard by the EBICS protocol.

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

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

And let us not forget two other usage areas where EBICS would be perfect:
  1. It is already used in Europe for domestic inter-bank transfers to great satisfaction. Moroccan financial institutions would be able to do the same, which would give them the ability to improve the resilience and the high degree of availability of these inter-bank exchanges and, additionally, to optimise the costs thereof.
  2. It may be used for data transfer for governmental digitisation projects, with regard in particular to social, medical and inter-service data.
Given what I have said, the EBICS protocol, which – as all readers of the blog will note – is spreading rapidly in Europe thanks to its universality, its ease of deployment, its high level of security and the absence of recurring costs, would seem to me to be an alternative choice for business-to-bank and bank-to-bank transfers. If, furthermore, the adoption of the ISO 20022 standard were to be considered by Moroccan banks, a great step would have been taken towards harmonisation and standardisation of financial flow exchanges which would also bring simplification and optimisation of transactions with Europe. This point seems to me to be particularly important, as the proximity of Morocco to the European continent has benefited the Moroccan economy due to the fact that the country has been able to profit from many relocations of European companies.

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

Marc Dutech