EBICS
Introduction
EBICS (Electronic Banking Internet Communication Standard) is a secure communication protocol designed to facilitate file exchange between businesses and banking institutions.
This multi-bank protocol allows a business to communicate with all European banks that have adopted this standard, without depending on a provider or solution specific to a single institution.
Data exchanges are carried out in XML format, ensuring a standardized structure that is readable by different information systems.
Before using EBICS, the company must enter into a contract with the concerned bank(s). This document specifies the types of authorized transactions, the levels of access, and the rights assigned to each user. It also contains detailed information on the associated bank accounts, thus ensuring a clear and secure framework for all transactions carried out via the protocol.
The main flows of the EBICS protocol
With the EBICS protocol, all transactions are initiated by the customer. This applies both to exchanges made from the customer to the bank (e.g., sending transfer or direct debit orders) and to those made from the bank to the customer (e.g., sending account statements).
Retrieving statements: EBICS offers the option of automatically retrieving bank statements made available by the bank. This feature facilitates the tracking of transactions and the integration of banking data into the company's accounting or management systems.
Sending bank orders: The protocol also allows bank orders (transfers, direct debits, etc.) to be sent from the customer's system to the bank.
When these orders are signed electronically, the bank then executes them, ensuring the security, traceability, and compliance of the transaction.
The different EBICS protocol requests
The different EBICS requests available on AOS:
INI: allows the public key of the signature certificate to be sent to the bank. This certificate can be self-signed and allows the user to be identified by the bank.
HIA: allows the public keys of the authentication and encryption certificates to be sent to the bank. These certificates enable transactions to be carried out with the bank.
HPB: allows the public keys of the bank's certificates to be retrieved. These certificates enable exchanges with the bank.
FDL: this request allows files made available by the bank to be retrieved. This request is used in particular to receive bank statements or acknowledgments of receipt.
FUL: this request allows a file to be sent to the bank. This request is used in particular to send bank orders.
HTD: allows user information to be retrieved.
PTK: allows user logs to be retrieved.
The difference between EBICS T and TS
EBICS T (Transport): EBICS T (Transport) mode is used for the secure exchange of files between the customer and the bank. In this mode, the transmitted files are first received and stored by the bank, then placed on hold until they are validated by electronic signature.
Each transfer requires a unique transport signature, thus ensuring the integrity of the data exchanged. The use of self-signed signature certificates is permitted, which simplifies the implementation of the protocol while maintaining an appropriate level of security.
However, it is important to note that the EBICS T signature has no enforcement value. The transmitted order must be confirmed by another communication channel before it can be processed.
Thus, the files remain pending validation until a confirmation signed by an authorized person within the organization is received. Only this confirmation, transmitted via a separate channel, triggers the actual execution of the order by the bank.
EBICS TS: the EBICS TS (Transport + Signature) mode is intended for the validation and secure execution of payment and collection orders. It enables the complete automation of banking exchanges while guaranteeing a high level of security. Each transfer includes a transport signature associated with one or two TS (Transport + Signature) signatures. These signatures are created using signature certificates stored on a physical medium, such as a USB token, thus ensuring the authenticity and integrity of the orders transmitted.
In this mode, the signature has execution power: the electronically signed order is processed directly by the bank upon receipt, without the need for additional confirmation. This mechanism, also known as “joint validation,” enables fast and reliable execution of transactions.
The EBICS TS protocol thus represents the highest level of security in the EBICS standard. On the other hand, its implementation is more complex and requires the user entity to have a certificate issued by a recognized certification authority, guaranteeing the compliance and reliability of the electronic signature process.
Bank and contract configuration
Configure the application
From version 8.0 onwards: Application config → Apps management → EBICS
For earlier versions: Application config → Apps management → Bank payment → activate the EBICS option Once EBICS is activated, a new menu entry will appear in the Accounting module.
Prerequisites
Access: Accounting → Configuration → EBICS
In order to use EBICS, the following prerequisites must be met:
-
The customer must have an EBICS contract with their bank.
-
EBICS TS: signature certificates on physical media (USB token)
Configure a bank
Access: Accounting → Configuration → EBICS → EBICS Banks
In the general information section, enter the following information:
-
Bank: the bank allows you to establish a link between the EBICS account and the bank configured in Axelor Open Suite (AOS), in order to facilitate and secure the automated exchange of banking data.
-
Host ID: the host ID generally corresponds to the bank's BIC (Bank Identifier Code) and is provided directly by the bank. This code uniquely identifies the bank within the EBICS protocol.
-
Protocol: this refers to the type of security protocol used for exchanges. There are two options: SSL or TLS. Today, most banks use the TLS protocol, which guarantees a higher level of security.
-
URL: this is the address of the bank's EBICS server, to which requests are sent to carry out transactions and file exchanges.
-
Language: this parameter is only used for communication with foreign EBICS servers to define the language of exchange.
-
Fax, email, and certificate validity period: this information is purely indicative and is used to document the configuration of the bank link.
-
X509 extensions: these options concern the configuration of self-signed certificates used for authentication and exchange signing. The associated settings depend on the bank's requirements and can, in most cases, be left at their default values.
Configure a contract
Access: Accounting → Configuration → EBICS → EBICS partners
When configuring an EBICS contract in Axelor Open Suite (AOS), several parameters must be defined in the partner file to ensure correct and secure communication with the bank.
-
Partner ID: this is the bank account code assigned by the bank when the EBICS contract is signed. This code identifies the client company in EBICS exchanges.
-
EBICS bank: this field refers to the bank previously configured in AOS, to which the EBICS contract is linked.
-
Mode: this parameter indicates the type of EBICS protocol subscribed to with the bank, namely EBICS T (Transport) or EBICS TS (Transport + Signature), depending on the desired level of security and automation.
-
Test mode: some banks offer a test EBICS mode, allowing orders to be simulated before they go into production. Check with the bank to see if this option is available.
-
EBICS transport user: this field designates the EBICS user responsible for transporting orders. It must be filled in once the transport user is activated, bearing in mind that only one transport user is authorized per EBICS partner. Please note that a user can only be activated if the partner has been created. So first you have to create the partner, then the user, and then select the user on the partner.
-
Default signatory: this corresponds to the EBICS user designated to sign bank orders by default. Several signatory users can be associated with the same contract, each with specific signature rights according to the company's internal policy.