EBICS 3.0 – a set of parameters instead of the order type. What must be taken into account when identifying business transactions?

With EBICS 3.0, the different business transactions are no longer mapped via order types, but via the new BTF parameters.

In order to enable the use of customer contracts with EBICS clients of different EBICS versions in combination with EBICS 3.0, special mapping rules were developed by the national specification bodies. These rules are generally oriented toward the five BTF parameters Service Name, Service Scope, Service Option, Service Message Name and Service Container. The important thing is that the combination of these BTF parameters must be unique in the EBICS bank server. This ensures that an order type can be assigned to the business transaction via BTF and vice versa.

In practice, identical orders of a certain format can be created for an order type in different format versions and submitted to the bank server. Although format adjustments are made regularly by the specification bodies, the format version used by the client system also depends on the software version of the client solution. Since the format version should be transparent to them in the clients, users have no influence on the submission in a particular format version when compiling their order files. In addition, financial institutions generally accept different format versions of a business transaction. Finally, for bank-side processing, the respective format version can also be read out from the namespace of the XML file, at least for XML formats. So far, bank servers are flexibly designed for different format versions.

The other usable BTF parameters in EBICS 3.0 are Service Message Name Format, Service Message Name Variant, and Service Message Name Version. If a financial institution also includes these other parameters in the order type mappings and agreement details with the customer, a number of things should be taken into account. If not previously used more intensively via FileFormat parameters or necessary for processing reasons, these additional parameters should be considered in a more measured manner on the bank side for EBICS tests.

Ultimately, this additional parameter information is already part of the order file itself and can be read from it anyway. What to do with conflicting statements? The additional management in the bank server also means more time and effort in master data management. There would have to be a separate customer agreement for each format version of a business transaction. What's more, these format details are visible to the customer in the client software, and some of them cannot be controlled.

What would happen if, for example, the bank server supports versions 03 and 04 of an XML format for submissions, but the customer submits version 04 to the BTF instead of submitting a format in version 03? Taking into account the version, the order would be rejected, although the bank system could process the format version; the actual version is recognisable by the namespace.
It is even more complicated with provisions of download files. In this case, the provision would have to be generated synchronously in the requested version at the time of download and output as a file. The same applies to historical downloads.

Conclusion: financial institutions should not be too restrictive in their definitions of BTF agreements with the customer. This enables financial institutions to be more flexible and saves additional time and effort in contract and master data management.


Author: Michael Lembcke