EBICS

Last updated: 11 September 2026

EBICS stands for Electronic Banking Internet Communication Standard and denotes the procedure for exchanging payment data over a secured internet connection. One distinction is decisive and often blurred in practice: EBICS is a transport channel, not a data format. What travels over it are the established formats – pain.001, pain.008, the camt family and the pacs family.

Governance and reach

EBICS was developed by the German banking industry and has been binding in Germany since the beginning of 2008. The standard is now owned by EBICS SCRL, a company held by the banking industry of four countries: Germany through the Deutsche Kreditwirtschaft, France through CFONB, Switzerland through SIX and Austria through STUZZA, which joined as a shareholder in 2020. The rights to amend the specifications rest exclusively with that company.

Its reach goes further than its ownership suggests. Banks in Spain, Portugal, the Netherlands and Scandinavia offer EBICS connections, and first institutions in Poland have been added. Those offerings do not rest on a national rulebook but on bilateral arrangements – outside the four owner countries the picture is considerably less uniform. For internationally active corporates this means EBICS covers the European core but does not replace worldwide connectivity.

Two worlds: customer to bank and interbank

EBICS is used in two quite different constellations, and anyone who knows only one of them routinely underestimates the standard.

In customer-to-bank traffic a corporate submits its instructions as a file and collects account information. That is the familiar side. Because the same standard applies at every participating institution, a company can serve several banking relationships from one program – the much-quoted multibank capability, which in practice counts for more than any individual feature.

In interbank traffic EBICS is a submission route into clearing. In Germany the Deutsche Bundesbank offers payment service providers access to the SEPA Clearer through EBICS – alongside Swift FileAct and dedicated lines. No pain messages travel on that leg; the interbank formats do: pacs.008 and pacs.003 for submission, plus the clarification messages camt.056 and camt.029.

One difference between the two worlds is easily overlooked and has operational consequences: in customer-to-bank traffic the customer always opens the connection. The bank never calls on its own; it makes data available and the customer collects it. In interbank traffic, by contrast, either side can open the connection and transmit data actively. Anyone who knows only the customer-to-bank case therefore plans a retrieval route where delivery would be possible – and loses time in processes where minutes count.

The same bank therefore stands in both roles: towards its corporate customers it is the receiving party, towards clearing the submitting one. Both legs use the same standard, but different formats, deadlines and operational requirements.

Point to point instead of a central network

Architecturally EBICS differs fundamentally from a network operation such as Swift. An EBICS connection is a direct relationship between two parties over the open internet – between customer and bank, or between institution and clearing house. There is no central intermediary through which all connections run.

The consequence is a different distribution of risk. If one EBICS route fails, that one relationship is affected; the customer’s other banking connections carry on. A centrally intermediated network, by contrast, concentrates reachability in one place – with all the advantages of uniformity and the known drawback of concentration. That the Bundesbank offers access to the SEPA Clearer through several routes in parallel is precisely the practical answer: whoever keeps both routes operational has a genuine fallback.

Since DORA this consideration is no longer an architectural question but part of supervisory expectations for fallback and contingency arrangements. Fairness requires the other side too: a central network brings global reachability and a single rulebook, whereas EBICS ends at the borders of the respective national arrangements.

Set-up and security

Initialisation comes before the first transmission. The user generates key pairs – separately for signature, authentication and encryption –, sends the public parts to the bank and collects the bank’s keys. In parallel a signed initialisation letter goes to the institution on paper or in equivalent form, and the keys are only activated after comparison. This media break is deliberate: it prevents a compromised line alone from being enough to set up access.

Transport encryption is added in operation. The corresponding annex to the specification was extended in spring 2026 with requirements for key management – an indication that security requirements keep being tightened even without a new main version.

Release: the distributed electronic signature

What makes EBICS hard to replace in corporate banking is not the transmission but the release model. Orders can be submitted by one user and released by another; processing only follows once the required signatures are in place. The four-eyes principle is therefore not a matter for the accounting software but part of the banking procedure.

Order types and business transaction formats

What is transmitted is determined not by the file content but by the order type chosen. With EBICS 3.0 the previously divergent national codes were replaced by the business transaction formats, which describe scheme, format and variant in a structured way. The corresponding mapping list is updated annually; the current version has applied since February 2026.

Instant payments

EBICS counts as a file-based procedure and is therefore often deemed unsuitable for instant payments. That assessment is too crude: the specification documents include a dedicated schema for instant payment clearing. On this point the standard is further along than its reputation suggests.

Current developments

• Format changeover in November 2026. With the new version of the data format specification, older format versions fall away; newer versions are to be submitted in future. The move to structured address data takes effect in parallel.
• Verification of payee. Verification of Payee reaches into the customer programs; the EBICS site provides its own guidance document for consistent handling in Germany.
• A successor version in preparation. Besides approved change requests, requests for a next version are already being collected. No date has been published – but the assumption that the current state is frozen for years does not hold.
• Security recommendations for corporates. The current version describes what precautions are needed inside the company for the security features of the procedure to take effect at all – a document that achieves more in customer conversations than any protocol description.

Sources for specifications

• EBICS – specification and annexes
• Die Deutsche Kreditwirtschaft – data format specification (Appendix 3 of the DFÜ agreement)
• EBICS – guidance for manufacturers and customers
• Die Deutsche Kreditwirtschaft – the EBICS procedure
• Deutsche Bundesbank – EBICS procedural rules