# EBICS Explained: European Bank Connectivity Source: https://gravam.com/blog/ebics-european-bank-connectivity Author: Tan Gravam Published: 2026-07-24 Updated: 2026-10-22 Reviewed: 2026-10-22 Summary: What EBICS is — an internet-based European standard for exchanging payment and statement files with banks — and where it fits alongside SWIFT and host-to-host. **EBICS is an internet-based standard for exchanging payment and statement files between a company and its banks, used mainly in parts of Europe.** It is strong in Germany and France and also used in Switzerland and Austria, and where your banks support it, one standardized channel reaches many of them. If you have read the [bank connectivity options overview](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), EBICS is one of the four channels there; this is the deep dive on what it actually is and when I reach for it. ## What EBICS is EBICS stands for the Electronic Banking Internet Communication Standard. Strip away the acronym and it is a **secure way to move files between a corporate and its banks over the internet** — payment instructions going out, account statements coming back. It originated in Germany, evolved from the earlier German banking-communication lineage that predated it, and was then adopted in France; those two markets are where you meet it most, with Switzerland and Austria also using it. EBICS is one of those standards that is simply a fact of life if your bank landscape sits in its home markets. You do not choose it in the abstract — you choose it because your German or French banks speak it, and speaking it well is cheaper than building something bespoke to each. ## How it works, conceptually At the level that matters for architecture, EBICS is straightforward. There is a **secure HTTPS connection** between your systems (or your connectivity layer) and the bank. Over that connection you **upload and download structured files** — typically [ISO 20022 XML](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002): `pain` messages for payments going out, `camt` for [statements coming back](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2). The transport carries the file; the file carries the content. Those are two separate concerns, and keeping them separate in your head saves a lot of confusion. The part I find genuinely useful is the **authorisation model**. EBICS uses electronic signatures to authorise orders, and it supports a **distributed electronic signature** — several authorised people can sign off an order independently, from wherever they are. That is not a cosmetic feature. It means the standard has segregation of duties built into the channel itself: the person who prepares a payment run does not have to be the person who releases it, and you can require two approvers on a high-value file without inventing a workflow around the bank connection. For payments, where the whole point is that no single hand moves the money alone, that is a real advantage. Those signatures rest on keys and certificates that have to be initialised, stored and rotated properly — the [security layer under bank connectivity](https://gravam.com/blog/bank-connectivity-security) is its own discipline, whatever the channel. > EBICS carries the file; the file carries the content. Keep the channel and the format separate in your head and half the confusion disappears. > **Figure — EBICS as one channel between a company and its banks** > > You on the left, your banks on the right, and one secured channel labelled EBICS between them. A pain file travels from you to the banks, and a camt file travels back. > > EBICS carries the file; the file carries the content — pain going out, camt coming back. ## What you actually set up: version, keys and the INI letter The conceptual picture fits on a napkin. The setup is a page of parameters, and every bank publishes one — the [PostFinance](https://developer.postfinance.ch/content/dam/pfch/doc/0_399/01765_en.pdf) and [Zürcher Kantonalbank](https://www.zkb.ch/media/zkb/dokumente/en/ebics_verbindungsparameter_eng.pdf) sheets are good public examples. They all carry the same handful of things. - **The version.** Two are live today: **EBICS 2.5**, whose scheme version is **H004**, and **EBICS 3.0**, which is **H005**. Your software asks for one of those strings, so it helps to know they are the same thing under two names. Order type `HEV` asks the bank which versions it supports. - **Three key pairs per user.** One for the **electronic signature** that authorises orders (`A005` or `A006`), one for **authentication** (`X002`) and one for **encryption** (`E002`). Each signer has their own; that is what makes the distributed signature mean something. - **The INI letter.** The software generates the keys and sends the public halves over the channel — `INI` for the signature key, `HIA` for the other two. The same keys are printed on the INI/HIA letters, which the user signs and posts to the bank. The bank verifies the keys against the letter, and only then switches the access on. Yes, on paper, by post, in a standard built for the internet: it is how the bank knows the keys really came from you. - **The bank's keys.** In the other direction, `HPB` downloads the bank's public keys, and you check their hash values against the ones printed on the bank's parameter sheet before you trust them. EBICS 3.0 adds the option of CA-issued certificates, [per SIX](https://www.six-group.com/en/products-services/banking-services/payment-standardization/standards/ebics.html). - **What you may send and fetch.** In EBICS 2.5 that is a list of three-letter order types (`CCT`, `C53` and many bank- or country-specific ones). EBICS 3.0 replaces them with **Business Transaction Formats** (BTFs), which name the service, scope and message type and version instead. The [order types reference](https://gravam.com/blog/ebics-order-types-and-btf) has both lists side by side. Two details from those sheets I would not have guessed. Zürcher Kantonalbank requires **keys of at least 2048 bits for every EBICS version** and warns that users with shorter keys can be blocked. Renewing keys is itself an order type, `HCS`, if your software supports it; otherwise it is a new INI letter. ### Switzerland moves to EBICS 3.0 in November 2026 If you have Swiss banks, this one has a date on it. [Zürcher Kantonalbank's changeover notice](https://www.zkb.ch/media/zkb/dokumente/en/FS_EBICS_3.0_EN.pdf) says that **from 14 November 2026** the 2019 ISO 20022 versions — `pain.001` version 09 and `camt.052/053/054` version 08 — are supported **only over EBICS 3.0**. EBICS 2.5 stays, but only for a short list of things such as PDF documents and direct debits. SIX gives the reason: the message versions in the Swiss rules (SPS 2022) are not backward-compatible with the older EBICS versions. The practical order is the bank's: move the channel to 3.0 first, then the file formats. Other Swiss banks publish their own dates, so check each bank's notice rather than assuming they match. ## Where it fits versus SWIFT and host-to-host The three channels are easiest to place by their footprint. - **SWIFT** is the global network — one standardized connection that reaches banks across the world. Its strength is breadth across regions. - **Host-to-host** is a bilateral, direct file link to one specific bank — efficient for a few strategic, high-volume relationships, but every link is its own setup. - **EBICS** sits in between for its region: a **standardized protocol that many European banks support**, so one channel reaches many banks without building a bespoke link to each. That is its whole appeal — the standardisation of host-to-host-style file exchange, but shared across the banks in its markets rather than negotiated one relationship at a time. The [connectivity options overview](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) has the fuller side-by-side on reach, cost and real-time capability. The short version: EBICS is the natural in-region channel where your banks support it, and it coexists happily with SWIFT for anything outside its footprint. ## Why a corporate would choose it Three reasons come up again and again. - **Regional bank coverage.** In Germany and France especially, EBICS is a mainstream corporate channel. If that is where your banks are, the coverage is already there — you are joining an established standard, not pioneering. - **Standardisation.** One protocol across many banks beats a separate bespoke arrangement per bank. It reduces the variation you have to manage. - **Native fit with modern formats and approval.** EBICS pairs naturally with ISO 20022 files and has multi-signer approval built in. If your target state is `pain`/`camt` with proper segregation of duties, the channel is already aligned with that. ## The caveats None of that makes it a universal answer, and I would be doing you a disservice to pretend otherwise. - **It is regional.** EBICS is excellent in-region and largely irrelevant outside it. It is not a global connectivity strategy on its own — pair it with SWIFT or another channel for banks beyond its markets. - **National variants have differed.** Historically the German, French and Swiss flavours were not identical. EBICS 3.0 harmonises the standard across the countries, [per SIX](https://www.six-group.com/en/products-services/banking-services/payment-standardization/standards/ebics.html), but banks move to it on their own timetables, and many still run 2.5 alongside it. Check which version each bank supports and which BTFs your contract with it actually activates. - **Every bank still onboards its own way.** The standard narrows the variation; it does not erase it. Each bank has its own onboarding, its own set of supported order types, its own quirks in what it will and will not accept. The [EBICS order types reference](https://gravam.com/blog/ebics-order-types-and-btf) lists the codes — INI, HIA, STA, C53, CCT — and the BTF names that replace them in EBICS 3.0, by country. ## EBICS still means bank-by-bank onboarding Here is the lesson I keep relearning. On paper, EBICS looks like _one standard_ — implement it once and you are connected to everyone. In practice you still **onboard and test bank by bank**. The signature setup, the initialisation, the exact order types, the formats each bank expects in each direction — those get agreed and proven per relationship, the same as every other channel. That is not a criticism of EBICS. It is the universal truth of bank connectivity, and it is the same warning I give about SWIFT, host-to-host and APIs: the standard reduces the variation, it does not remove it. A standardised channel gets you most of the way, and then each bank's onboarding gets you the last mile. Plan for that last mile, budget the testing, and start early. The teams that get burned are the ones who read "standard" as "plug and play" and discover at go-live that bank number four needed a different order type than the three before it. Treat EBICS for what it is — a genuinely useful, standardised European channel with proper multi-signer approval baked in — and it earns its place in the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury). Just hold it to the same discipline as any other connection: agree the formats, onboard bank by bank, and monitor every link. *** _See also [bank connectivity security](https://gravam.com/blog/bank-connectivity-security) for the keys and certificates behind the channel, and [straight-through processing in treasury](https://gravam.com/blog/straight-through-processing-in-treasury) for what the channel is meant to enable._ ## Primary sources - EBICS — Electronic Banking Internet Communication Standard — accessed 2026-07-29 — https://www.ebics.org/en/home - PPI — EBICS Compendium (history, versions, EDS) — accessed 2026-07-29 — https://www.ppi-group.eu/en/products/banking-clients/ebics-compendium.html - SIX — EBICS: Payment Standards for Switzerland — accessed 2026-07-29 — https://www.six-group.com/en/products-services/banking-services/payment-standardization/standards/ebics.html - PostFinance — EBICS parameter datasheet (01765) — accessed 2026-10-22 — https://developer.postfinance.ch/content/dam/pfch/doc/0_399/01765_en.pdf - Zürcher Kantonalbank — EBICS connection parameters — accessed 2026-10-22 — https://www.zkb.ch/media/zkb/dokumente/en/ebics_verbindungsparameter_eng.pdf - Zürcher Kantonalbank — Client information for the changeover to EBICS 3.0 — accessed 2026-10-22 — https://www.zkb.ch/media/zkb/dokumente/en/FS_EBICS_3.0_EN.pdf ## Questions this article answers **Q: What is EBICS?** EBICS — the Electronic Banking Internet Communication Standard — is an internet-based protocol for exchanging payment and statement files between a company and its banks. It originated in Germany, was adopted in France, and is also used in Switzerland and Austria. Files (commonly ISO 20022 XML) travel over a secure HTTPS connection, and electronic signatures authorise the orders, including a distributed-signature capability where several people can approve independently. **Q: How is EBICS different from SWIFT?** SWIFT is the global bank-messaging network — one standardized connection that reaches many banks worldwide. EBICS is a mainly European protocol: where your banks support it, one channel reaches many of them without a bespoke link each, but its relevance is regional rather than global. Many European treasuries use EBICS in-region and SWIFT for broader reach. They solve the same problem — moving statements in and payments out — in different footprints. **Q: Which countries use EBICS?** EBICS is strongest in Germany and France, where it is a mainstream corporate channel, and is also used in Switzerland and Austria. It grew out of Germany's earlier banking-communication lineage and was adopted in France, which is why those two markets dominate. Outside its European home markets it is generally not the channel you would reach for. **Q: What is the difference between EBICS 2.5 and EBICS 3.0?** EBICS 2.5 (scheme version H004) identifies what you send or fetch with three-letter order types, many of them country- or bank-specific. EBICS 3.0 (H005) replaces those with Business Transaction Formats, which name the service and the message type and version, harmonises the standard across countries and adds the option of CA-issued certificates. In Switzerland the 2019 ISO 20022 message versions travel only over EBICS 3.0. **Q: What is an INI letter in EBICS?** When a new EBICS user is set up, the software generates the user's signature, authentication and encryption keys and sends the public keys to the bank with the order types INI and HIA. The same keys are printed on the INI/HIA letters, which the user signs and posts to the bank. The bank verifies the keys against the letter and only then activates the access. In the other direction, HPB downloads the bank's public keys, whose hash values you check against the bank's parameter sheet.