Blog series: How to enhance EBICS, Part 3 – EBICS is now also on-line

Is it really true that the requirements for corporate clients in e-banking are only geared towards file-based data exchange? Or are on-line administrative operations also affected? Why else do small corporate clients in particular often use e-banking solutions which are designed for private costumers?


The EBICS protocol was originally developed from file-transfer systems, and is outstanding in the secure and reliable exchange of large files between corporate clients and banks, as well as in internet bank transactions. The files being transferred are, according to the administrative operation, identified with order types or format parameters, which will then determine each process.

When submitting data via EBICS, the data connection where a user has been successfully authenticated is kept open only for the duration of the data transfer. The actual processing is usually carried out off-line. The processing results must then be downloaded via a separate administrative operation (PTK/HAC). Similarly, data being retrieved from the bank server, information on revenues for example, are routinely provided off-line for retrieval. This data can then be obtained as a file via EBICS.

The EBICS standard is currently not designed for the on-line acquisition of payment transaction orders and their authorisation, as well as the on-line retrieval of account information. These functionalities are supported by proprietary web-portals in consumer business and by national standards, such as HBCI and FinTS in Germany. If a corporate client today wants to use the preferences of on-line administrative operations and EBICS equally, he must, under certain circumstances, apply different solutions using various login data.

It might therefore be useful to extend the EBICS standard to the relevant on-line processes. For example:

• Account balance information: Via the EBICS protocol, on-line information could be provided detailing current account balances, while the connection in EBICS is kept open for data retrieval. The corporate client will thereby be kept up-to-date with current account information.
• Information on status and process results for submission orders: The customer needs to be aware of the status of each order. In conjunction with a customer order reference, which would have to be introduced (see blog post from 18 Dec 2014), an on-line individual request on order status will make the evaluation process for the corporate client considerably clearer and easier. Calling up the bank to inquire on the status of an order might then become unnecessary.

Of course, there would be other possible areas of application. It's important to note, however, that this doesn't mean competition with other standards or procedures in the private client sector. Rather, we should strive to adapt the EBICS standard to the needs of the banks and corporate clients, and thereby make EBICS future-proof.

Michael Lembcke

Read more

Blog series: How to enhance EBICS, Part 2 – delegating authorisations with EBICS and the Distributed Electronic Signature (VEU)

In this article, we shall continue the series we began in December on possible improvements to the EBICS standard. This post will focus mainly on the following issue: If one were to submit a payment transaction order today, the submitter wouldn't – at least with the standard features – have the option of managing additional authorisation procedures. In some cases, you only know who is eligible for the additional authorisation when you make the submission, so that it might be beneficial to delegate the authorisation on a case-by-case basis.

In the currently specified EBICS configuration, various authorisation models on the banking server end can be utilised for the submission and authorisation of order files by corporate clients. In practice, these models are always based on the signature categories E, A, B and T, the number of required signatures and the personal authorisations for a physical file. Moreover, credit institutions and software developers have extended the authorisation models so that they are appropriate for various usage scenarios. Such extensions include:

• Authorisations relating to an individual and an order, in conjunction with signature category, order type (i.e. specific administrative operations) and accounts.
• Various limit concepts, indexed by amounts, number of transactions, time frames, persons applicable, accounts and/or customers, as well as signature categories.
• Group concepts in conjunction with signature categories, such as approving authorisation rights for persons in exclusively different or exclusively the same groups.
• Proprietary signature categories which take their own evaluations for an authorisation into account.
• Procedures for service data centres (SRZ procedures), in which submission and authorisation processes run separately on the customer end.

All these models should be considered relatively static. This means, when an EBICS customer submits an order, he has very few possibilities to influence how the bank processes the business transaction. The master data established by the bank will always be the basis for approval, format verification and authorisation. Where a clear derivation of approvals in the EBICS environment on the bank's end is possible, this is generally reasonable and desirable. However, submission orders which require different processes depending on the circumstances cannot be processed in any other way in EBICS. For equivalent SEPA submissions with the order type CCT relating to a specific account, all persons approved for this account and this order type in the bank server for VEU would always be approved for authorisation.

Would it not be useful if a customer could, when submitting via EBICS, nominate specific persons to whom authorisation rights can be delegated? Of course, these individuals must have the correct basic authorisations on the bank's end. The upshot would be that individuals who are not nominated with the otherwise equivalent basic authorisations would not receive the order ready for VEU and therefore wouldn't be able to see it. This model can, for example, apply to cases in which a) arbitrary payments, salaries or honorarium-esque payments are processed from a certain account, and b) the payments are not given special transaction IDs. These IDs, however, remain dependent on format and country. With the right extensions to the EBICS standard, a solution independent of format may be viable.

Michael Lembcke

Read more