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