Within a customer agreement, it must be possible to take into account the central agreement for the respective business transaction, regardless of the EBICS version. Compatibility and interoperability between the previous versions are predefined for EBICS. If two electronic signatures are agreed for a SEPA credit transfer, it is irrelevant, for example, whether submissions for this are made via BTF, order type or FileFormat parameter. This condition requires an internal mapping of old and new business transactions in the bank server and possibly also in client systems. So far, these mappings have been officially specified for the standard business transactions.
The processing upstream and downstream of EBICS at the financial institutions and at the corporate customers is generally still based on the previous EBICS IDs, such as the three-digit order types and in France on the up to 40-digit FileFormat parameters. As long as a mapping exists, there is no need to change anything. However, what if no more order types/FileFormat parameters are specified for a business transaction and the business transactions apply exclusively with BTF? If one does not want to adapt one's adjacent processing operations to the BTFs, a mapping can of course be retained. For the unspecified mappings, however, custom suitable IDs should then be defined.
In external relations in the customer-bank relationship, it should be noted that the customer or client system is informed of the bank server's specifications regarding business transactions and mappings in various ways. In addition, the different representations from the point of view of the customer, participant and time come into play. A participant always uses a specific EBICS version, while the customer agreement must map all valid versions. In addition, the time of the information plays a role. For example, before the EBICS user is initialised, the financial institution usually does not know which EBICS version the user will use.
The BPD sheet (BPD = bank parameter data), which is created in the bank server when the EBICS user is set up, must therefore map the options of all supported EBICS versions including any BTF mapping specifications. The same applies at least to the order type HKD, with which the client-level agreements can be retrieved by the client. If mapping is no longer offered for certain business transactions in the customer-bank relationship, irrespective of internal use, the information should represent the mapping accordingly exclusively via BTF. For internal administration and maintenance, it is helpful if the individual IDs used exclusively for internal purposes are visible in an internal mapping (e.g. individual order types with their own BTF mapping), but are different from the external IDs.
In summary, the challenge is to make the transition to EBICS 3.0 as easy as possible for all parties involved with the new variety of information. However, with the right configuration and by observing a few guidelines for operation, the migration to the new EBICS version is not difficult at all. If you need help with the migration to EBICS 3.0 or have any questions, please do not hesitate to contact us.
Author: Michael Lembcke