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:
Michael Lembcke
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.
Michael Lembcke