The level of digitalisation in a treasury process is not determined by whether software is available for every step. What matters much more is whether data moves from one system to another without someone having to download, upload and check files.
Connectivity between a company and its bank is therefore more than an IT matter. It is part of the treasury operating model, bringing together automation, approval workflows and financial controls.
Why was EBICS developed?
EBICS – Electronic Banking Internet Communication Standard – was developed at the initiative of the German banking sector. Its predecessor, the BCS/FTAM standard, needed to be adapted for internet-based operation while preserving secure corporate data exchange and the ability to work with multiple banks.
Development began in 2003, broader adoption in Germany started in 2006, and support became mandatory for German banks in 2008. EBICS subsequently gained wider use in France, while Switzerland and Austria also joined the organisation responsible for maintaining the standard.
The starting point was therefore not a new banking interface, but a common communication standard on which companies can build their own financial systems. This approach remains one of the most important strengths of EBICS today.
Hungary: expanding availability across six major banks
According to the market information available to InFoRex, EBICS connectivity is already available at six major banks in Hungary. This is an important development for treasury digitalisation in the country: it makes EBICS a practical option in the bank connectivity strategies of a growing number of companies.
What does EBICS deliver in its own right?
Two-way data exchange that can be automated. Payment files can be sent directly from the corporate system to the bank, while bank statements can be retrieved on a schedule. Manual file transfers can therefore be eliminated from daily operations.
Support for corporate approval workflows. Electronic signatures support controlled authorisation of payment files. Implementation should align internal permissions, the signing mandates registered with the bank, and the controls applied within the system.
More consistent management of multiple banks. Supporting banks can connect to a common corporate system. This enables treasury to organise its operations around its own processes rather than separate banking interfaces.
The key distinction is that EBICS provides the communication channel; reconciliation, liquidity planning and management information must be delivered by the connected corporate system. In InFoRex, bank connectivity is complemented by payment status tracking and reconciliation of bank statement transactions against planned payments.
EBICS versus SWIFT: where does the cost advantage arise?
As a corporate bank connectivity solution, SWIFT offers broad international reach through a common communication channel. For companies operating across several countries and many banks, this has substantial value.
A direct EBICS connection, however, does not require a separate SWIFT connection for this exchange of data. This is where a cost advantage can arise: the cost components associated with SWIFT access and, where applicable, an additional service provider can be avoided. Where the required banks are accessible through EBICS, this may result in a lower total cost.
This does not mean that EBICS is free. Bank onboarding and monthly fees, as well as software, integration and operating costs, may still apply. In our experience, however, these are not on the same scale as the costs of establishing and operating a SWIFT connection.
EBICS versus PSD2: the distinction is not whether payments are possible
PSD2 is a regulatory framework; EBICS is a communication standard. The practical comparison is therefore between EBICS connectivity and PSD2-based banking APIs.
In a corporate environment, the decisive question is how well the connection fits actual operations: whether bulk payments can be handled, how multiple approvals work, what status information is returned, and how much user intervention is required. For PSD2-based banking APIs, it is important to note that most banks do not support bulk payments through these interfaces, despite this being theoretically possible and particularly important for corporate banking. The strength of EBICS is that these specific corporate requirements are built into its design.
For treasury, the end-to-end process is what matters
An EBICS implementation should therefore not be treated as a standalone interface project. Start with the intended operating model: where payment instructions originate, who approves them, how receipt by the bank is monitored, and how bank statement transactions feed back into reconciliation and liquidity forecasting.
Alongside security, the real benefit is minimising human intervention.
