All articles

Swiss banking · Swiss banking, file by file, Part 1

EBICS explained: how a Swiss firm talks to its bank

Published 2026-10-06 · Updated 2026-10-28 · 12 min read

Note, as of 14.10.2026: TILL is now a public beta (version 1.0.0-beta.1). The EBICS client in this article is built, but the module that makes the connection to the bank is not published yet; it will come under MIT. Where the article calls TILL pre-alpha, it describes the state when it was written.

What is EBICS?

EBICS, the Electronic Banking Internet Communication Standard, is a standardised internet protocol for exchanging files between a company and its bank. SIX describes it as freely available. Payment orders go up; statements and reports come down. German and French banks founded EBICS SC, the company that maintains the standard, and the Swiss and Austrian banking sectors joined later (SIX on EBICS).

In Germany, banks have had to support EBICS since January 2008. In Switzerland it is optional: each bank decides whether to offer it. The Swiss banks that do have supported version 3.0 on the server side since November 2021. Which version you use is agreed with your bank.

EBICS 3.0, called H005 in the protocol, merged the old country variants into one standard. Instead of national order-type codes, an order now says what it carries with BTF parameters: a service, a scope, a message name, a container. The Swiss rules for all of this are the SIX Swiss Market Practice Guidelines EBICS 3.0, version 1.3. What TILL does for Swiss books in general is on the Swiss page.

Which three IDs does an EBICS connection have?

Every EBICS connection is addressed by three identifiers, plus the address of the bank’s EBICS server. In this article the customer is Muster Werkstatt GmbH in Seldwyla, and every ID, address and hash is invented.

Requests go to an HTTPS address such as https://ebics.example.com/ebicsweb. The keys in the next section belong to the subscriber. The bank’s customer protocol, its record of everything sent, fetched and signed, is kept per partner ID.

Which three keys does EBICS use?

EBICS uses three key pairs per subscriber, and each has one job. X002 authenticates every request, A005 or A006 signs orders (the electronic signature), and E002 encrypts. The Swiss guidelines name 2048 bit as the key length, and you agree the exact procedures with your bank.

In Switzerland, the public keys travel as X.509 certificates under EBICS 3.0. Self-signed and CA-issued certificates are both accepted, only the format is mandatory, and the validity can be unlimited (9999-12-31). The order type H3K is not supported there, and no certificate revocation (CRL) checks are done.

Keys created under an older EBICS version only have to be re-initialised with certificates if they are shorter than 2048 bit.

How do you set up an EBICS connection?

Setting up an EBICS connection takes eight steps in the Swiss guidelines (SMPG section 6.1):

1. You sign the EBICS contract with your bank.
2. The bank sends you the access data, including the hash values of its own keys.
3. Your software sends your public keys with the order types INI and HIA.
4. You sign the initialisation letter with your hash values and send it by post.
5. The bank compares the hash values and checks the signatures.
6. The bank accepts the keys and activates the contract.
7. Your software fetches the bank’s keys with HPB, and you compare their hash values with the ones from step 2.
8. You accept the bank’s keys in your software. From here on, files can flow.

Why does EBICS still need a paper letter?

EBICS still needs a paper letter because the keys reach the bank online, and anyone can send a key online. A letter in the post sounds quaint for an internet protocol, but it is a second route. The EBICS 2.5 specification calls this “two independent communication paths”. One way to read it: your signature on paper ties the keys that arrived online to you, the customer. The bank compares the hash values on the letter with the keys it received through INI and HIA, and activates the contract only when they match.

A hash value is a fingerprint: 32 bytes of SHA-256, computed over a certificate or a key. TILL prints it as uppercase hexadecimal pairs. For a key registered as an EBICS 3.0 certificate, TILL computes SHA-256 over the certificate’s DER bytes. TILL also prints the classic EBICS key hash defined in the 2.5 specification: SHA-256 over the ASCII string “exponent modulus”, both in lowercase hex without leading zeros. Both values go on the letter, labelled.

EBICS initialisation letter
Customer:        Muster Werkstatt GmbH, Seldwyla
Host ID:         EXAMPLEHOST
Partner ID:      PARTNER0001
User ID:         USER0001
EBICS version:   H005
Key format:      X.509, self-signed

Electronic signature (A005), certificate, SHA-256:
  E0 46 FE E3 95 58 4C CD
  4E 86 A0 E8 07 5E C2 F8
  0A C8 63 2D 5B 3E E3 E4
  25 50 C1 76 8F 90 97 3C

Authentication (X002), certificate, SHA-256:
  F8 B3 D5 AC 66 BB 24 81
  E5 CF AB FC C1 E1 03 15
  25 A7 F7 1E DB 2F FB 6E
  82 B0 A5 D5 AA 7D 5B A1

Encryption (E002), certificate, SHA-256:
  23 58 57 80 DE A3 2A 38
  AF 6A 7A 06 04 83 D4 1E
  88 7E 53 94 8C C1 B0 ED
  4E 8A 35 F3 CC A5 C0 57

Signature: ______________   Date: __________

You can recompute a certificate hash yourself: openssl x509 -in cert.pem -outform DER | openssl dgst -sha256 prints the same 32 bytes, in lowercase and without spaces.

How do you check the bank’s keys?

You check the bank’s keys with HPB. Your software fetches the bank’s public keys, you compare their hash values byte by byte with the values the bank sent with the access data, and only then do you accept them (SMPG section 6.1, steps 7 and 8). Trust has to run both ways.

TILL keeps to that order. It pins the bank’s keys only after a person has reviewed them against a fresh HPB. If the bank’s keys change later, the feed stops until someone checks them again.

What happens in one download?

A download in EBICS 3.0 is the order type BTD, and the BTF parameters say which file you want. For the Swiss end-of-day statement, camt.053, they are:

OrderType     BTD
ServiceName   EOP        end of period (here: end of day)
Scope         CH         Swiss Payment Standards (CH and LI)
Container     ZIP
MsgName       camt.053   version 08

The bank answers with a ZIP. In Switzerland and Liechtenstein, camt.052, camt.053 and camt.054 always come as ZIP files. When there is nothing new, the bank answers with the return code 090005 (EBICS_NO_DOWNLOAD_DATA_AVAILABLE) instead. TILL treats that as a quiet day, not as an error.

Then comes the part that decides whether a statement can be lost. The client confirms a download with a receipt that carries the bank’s TransactionID. TILL first writes the container and every file in it to its own store in one commit. Then it imports the statements from those stored bytes, and only after that does the receipt go out: code 0, because the commit held. If the commit fails, TILL sends code 1 at once. After a negative receipt the bank does not mark the data as fetched, so it is normally offered again.

TILL reads the ZIP from its central directory. It checks the member count, each member’s CRC-32 and size, and refuses encrypted or unusual members.

Store first, receipt second: that is TILL’s rule. The 2.5 specification defines code 0 as a successful download and processing. TILL reads “processing” as a durable store: it sends 0 once the commit holds, even if a statement then fails to import, because the stored bytes are processed again at the next sync.

What changes in Switzerland in November 2026?

In Switzerland, two different things end in November 2026, and they are easy to mix up: the old ISO 20022 message versions, and EBICS 2.5 on a date each bank sets itself. As of 28.09.2026 the sources say:

SIX gives no calendar date for EBICS 2.5 itself. Its guidelines say the market supports version 2.5 officially “until the end of the parallel phase for SPS 2021”. The SIX factsheet puts that end on 14.11.2026. Each bank announces its own switch-off (Raiffeisen: 13.11.2026; AKB: November 2026). The same guidelines say the 2019 ISO 20022 messages require EBICS 3.0. In practice: a company that stays on EBICS 2.5 cannot fetch camt.053.001.08, and from 14.11.2026 that is the only statement version. Ask your bank for its own date.

What can’t a download-only client do?

A download-only client fetches files and nothing more, and TILL’s EBICS client is one. Its order types are HEV (which asks the bank for its EBICS versions), INI, HIA, HPB and BTD, and the only file it fetches is the camt.053 statement.

• It cannot sign a payment. TILL generates the A005 pair, self-signs its certificate with it and deletes the private key before anything is stored. It keeps only the X002 and E002 private keys, to authenticate requests and to decrypt downloads.
• It does not upload. TILL writes a pain.001 file, and you upload and release it in your e-banking.
• That is also how EBICS itself treats unsigned files: without the SignatureFlag, an uploaded file has to be released outside the EBICS channel, for example in e-banking (SMPG section 4.2.3).
• It fetches on demand only, when you press the button or ask for it. There is no scheduled sync, no date range and no camt.054.
• It cannot block your contract at the bank. Blocking happens at the bank, with the order type SPR or, for example, by phone (SMPG section 6.2).

And TILL itself is pre-alpha. The code is public under MIT, but it is not ready for real books. What TILL protects against, and what it does not, is on the security page. How the ledger itself refuses double postings and edits after the fact is in MCP meets the ledger.

Before you sign the EBICS contract: questions for your bank

Before you sign an EBICS contract, ask your bank these questions. They hold whatever software you connect, and they save a round of letters:

1. Do you offer EBICS 3.0 (H005) for my contract, and until when do you support EBICS 2.5?
2. Which signature procedure and key length do you expect: A005 or A006, 2048 bit?
3. Which hash value do you compare on the initialisation letter, and do you need a letter at all?
4. Are your own hash values in the access data, so I can check HPB against them?
5. Which BTF do you use for the end-of-day statement, and is camt.053.001.08 switched on for my accounts?
6. Do you support the DateRange parameter for downloads?
7. How do I block access if a key is lost: SPR, phone, or both?
8. Does my software have to sign uploads, or do I release payments in e-banking?