Even though there is a standardised specification for EBICS, it is
used differently across Europe for submission and for authorisation
checks by the bank with regard to payment transaction orders. For
example, only order types are used in Germany, whereas the French use
the format parameters. But do customers have to know these differences?
As I promised in my last post, here's more on the subject.

With the EBICS order type, the client indicates which administrative operation they wish to submit using the banking server. If the order type is recognised by the banking server and the individual submitting the order is authorised, a format process specified for this order type will be initialised.
For three-figure order types in EBICS there is a distinction between initialising uploads and downloads. Order types can also be either operative or administrative. The latter refers to order types which operate the EBICS protocol themselves, for example, HIA and INI for key exchange, or HVU for retrieving the VEU (distributed electronic signature) overview. On the other hand, operative order types refer to the technical content of a data transfer, such as CCT for payments in the SEPA Credit Transfer format. In this way, the type of format-specific processing can be determined for operative order types.
With EBICS, a list of the operative order types and the accompanying administrative operations or formats to be used is specified. These operative order types are at present predominantly used in Germany.
In France, only one order type is generally used for uploads (FUL) and one for downloads (FDL) for operative orders, regardless of data content. In order to then send information on the receivable format to the banking server, a format parameter of up to 40 characters is provided with the order type by the client. this format parameter is determined by EBICS.
Does the banking server communicate well with the client?
In both the German and French variants of order type usage, format-specific authorisation checks are stored by the bank. On the one hand, this allows the format parameters a detailed agreement between the customer and bank on the type of content exchange (e.g. SEPA versions, national variants), but the order types for a customer are potentially more easily managed because there would be no need to be concerned with format details in EBICS. However, it is imperative that EBICS banking servers and clients can communicate with each other. The customer must therefore be well aware of what the banking server understands.
Both exchange methods of operative data between the EBICS client and server have advantages and disadvantages. The corporate client will make the eventual decision, possibly having accounts with several credit institutions in various countries. Such customers will require a standardised process. The success of EBICS will therefore depend largely on both the consistency of EBICS usage and the interoperability of EBICS usage varieties. For this purpose, input of the specifier will be requested. As demonstrated in Carsten Miehling's post on 9 September, this process is already underway.
Michael Lembcke
With the EBICS order type, the client indicates which administrative operation they wish to submit using the banking server. If the order type is recognised by the banking server and the individual submitting the order is authorised, a format process specified for this order type will be initialised.
For three-figure order types in EBICS there is a distinction between initialising uploads and downloads. Order types can also be either operative or administrative. The latter refers to order types which operate the EBICS protocol themselves, for example, HIA and INI for key exchange, or HVU for retrieving the VEU (distributed electronic signature) overview. On the other hand, operative order types refer to the technical content of a data transfer, such as CCT for payments in the SEPA Credit Transfer format. In this way, the type of format-specific processing can be determined for operative order types.
With EBICS, a list of the operative order types and the accompanying administrative operations or formats to be used is specified. These operative order types are at present predominantly used in Germany.
In France, only one order type is generally used for uploads (FUL) and one for downloads (FDL) for operative orders, regardless of data content. In order to then send information on the receivable format to the banking server, a format parameter of up to 40 characters is provided with the order type by the client. this format parameter is determined by EBICS.
Does the banking server communicate well with the client?
In both the German and French variants of order type usage, format-specific authorisation checks are stored by the bank. On the one hand, this allows the format parameters a detailed agreement between the customer and bank on the type of content exchange (e.g. SEPA versions, national variants), but the order types for a customer are potentially more easily managed because there would be no need to be concerned with format details in EBICS. However, it is imperative that EBICS banking servers and clients can communicate with each other. The customer must therefore be well aware of what the banking server understands.
Both exchange methods of operative data between the EBICS client and server have advantages and disadvantages. The corporate client will make the eventual decision, possibly having accounts with several credit institutions in various countries. Such customers will require a standardised process. The success of EBICS will therefore depend largely on both the consistency of EBICS usage and the interoperability of EBICS usage varieties. For this purpose, input of the specifier will be requested. As demonstrated in Carsten Miehling's post on 9 September, this process is already underway.
Michael Lembcke