EBICS Society · the channel
EBICS is how the file travels. The format is what it says.
EBICS is a transport: a signed, encrypted conversation between your systems and your bank over the internet, used to send instructions up and pull reports down. It carries whatever file the two of you agreed on and has no opinion about what is inside. Which is why the channel and the format are two separate conversations with a bank, and only one of them is about what the file says.
The account every page here reads
EUR- Published by
- EBICS Society
- What it carries
- Any file the bank and the customer agreed on, signed and encrypted in both directions.
- Account
- ES21 0049 0001 5323 4567 8901
Closing balance · Aug 14, 2026EUR 2,990,901.67
The definition
What EBICS actually is
A banking transport standard used across Germany, France, Switzerland and Austria, and the answer to how the file gets there rather than to what is inside it.
EBICS is the Electronic Banking Internet Communication Standard: an XML protocol over HTTPS in which a customer’s system uploads orders to a bank and downloads reports from it. Every order is wrapped in an envelope the bank authenticates, and the payload is encrypted separately, so the file is never readable in transit and its integrity never rests on the transport. The customer holds its own key pairs — one for signing an order, one for identification and authentication, one for encryption — and the bank holds its own, exchanged once at setup and confirmed against printed hash letters signed by hand.
- Who sends it
- Both sides. That is what separates a channel from a format: the same EBICS connection carries the pain.001 going up and the camt.053 coming down, and adding a second file type to it is a permission on the channel you already have rather than a new connection.
- When it arrives
- Continuously, on the schedule you set. Uploads go when a run is released; downloads run on a timer, which is how an account that reports several times a day gets read several times a day without anybody opening a portal.
- What it looks like
- EBICS defines no file to read. What it defines is the envelope, the key material, the order parameters and the acknowledgment — never the content. The file inside is an MT940, a camt.053, a pain.001 or whatever the two sides agreed on, and it is exactly the same bytes it would be on any other channel.
What its parts are called
- EBICS T vs EBICS TS
- EBICS BTF
- EBICS INI HIA HPB
- EBICS 3.0 order types
- EBICS vs host-to-host
What it settles
What EBICS decides, and what it leaves to the format
A channel decides who may send what, and proves who sent it. Everything about meaning stays inside the file.
Two profiles, and the difference is where the payment is authorized. Under EBICS T the transport is authenticated but the order carries no payment signature, so a file that arrives is transported rather than approved: releasing it happens outside the file, in whatever channel the bank keeps for that. Under EBICS TS the order carries the electronic signatures of the people entitled to release it, distributed across as many signers as the bank’s rules require, so the instruction and its authorization are one object and the bank can act on what it received. Which profile a bank offers, and above which amounts, is part of the same conversation as the keys.
The order parameters are the other half. Older bank documentation lists a three-letter order type per file and direction — one code to download a statement, another to upload a credit transfer — and a customer had to know the code before it could ask for anything. EBICS 3.0 replaced that list with business transaction parameters: a service name, a scope, a message name with its version, and the container the payload arrives in. It is the same request described by what the file is rather than by a code somebody has to look up, and it is why a bank can add a new report to an existing channel without a new order type being invented for it.
So the two decisions stay apart, and they are worth keeping apart. A bank that changes channel does not change what its statements say, and a bank that starts sending a new format has not changed how it reaches you. We take the channel each bank already runs and read whatever it puts on it.
Next
What travels on it
pain.001 is what goes up. CAMT.053 and MT940 are what come down. ISO 20022 is the standard most of them belong to, and not one of them is a property of the channel.
Formats to read beside it
- pain.001 The ISO 20022 payment initiation, and the total a bank checks first
- CAMT.053 The ISO 20022 closed statement, every reference in its own element
- MT940 The SWIFT end-of-day statement, and the free-text field under every line
- ISO 20022 The name grammar behind camt, pain and pacs, version included
The same day written in four formats, side by side, is on Format library
Asked about EBICS
The questions a connectivity team actually types
- 01What is the difference between EBICS T and EBICS TS?
- Where the payment is signed. EBICS T authenticates the transport, so the file arrives proven to be yours but not yet approved: the release happens afterwards, in whatever channel the bank keeps for it. EBICS TS carries the electronic signatures of the approvers inside the order itself, distributed across as many people as the bank requires, so the instruction and its authorization are the same object. Both are EBICS, and which one you get is settled with the bank when the keys are exchanged.
- 02Is EBICS a file format?
- No. EBICS is how a file travels between you and your bank; the format is what the file says. The same channel carries a pain.001 up and a camt.053 down, and that camt.053 would be identical arriving over host-to-host, over SWIFT or as an upload. Naming your channel tells nobody which fields your bank fills in, which is the question a reconciliation actually depends on.
- 03What replaced EBICS order types?
- Business transaction parameters, in EBICS 3.0. Instead of a three-letter code per file and direction, an order names the service, its scope, the message and its version, and the container the payload comes in. The older codes are still what most bank documentation calls them and plenty of connections still run on them, so both descriptions of one request are in circulation and a profile has to know which of them a given bank speaks.
- 04What keys does an EBICS connection need?
- Three of yours and one set of the bank’s. You hold a signature key for authorizing orders, an authentication key that proves the request came from you, and an encryption key for the payload. Setup sends the public halves to the bank and then confirms them out of band: you sign a printed letter carrying the hashes, and you check the bank’s own hash against the letter it gives you. None of that changes what a statement contains, and all of it decides whether one arrives.
- 05Do you connect over EBICS?
- Yes, alongside SWIFT, host-to-host and the banks’ own APIs, and the choice belongs to the bank rather than to us. A channel is opened in your name with whatever that bank asks for — a signed mandate, a certificate, an EBICS key exchange — and you can withdraw it later without touching anything already loaded. If one of your banks runs something that is not here, we add it.
Tell us which channel each bank runs.
One list of banks and the channels they answer on. You get back what each one can send, what it can take, and which of them can be read today.
A channel is opened in your name, and you can withdraw it whenever you want.