EBICS Order Types and BTF: INI, HIA, STA, C53, CCT

An EBICS order type is a three-character code that says what one request does: INI and HIA send your public keys to the bank, HPB fetches the bank's, STA downloads an MT940 statement, C53 a ZIP of camt.053 statements, CCT uploads a SEPA credit transfer and CDD a SEPA direct debit. Those last four are German codes. EBICS 3.0 keeps the administrative codes and replaces the file codes with BTF — two order types, BTU for upload and BTD for download, plus a five-part description of the file. This page lists both, by country, from the banks' own parameter sheets.

If you want to know what EBICS is and when to pick it, that is the EBICS explainer. This is the page for the moment after that: the bank has sent a parameter sheet, your TMS or payment hub wants order types in a configuration screen, and the two lists don't quite match.

A word on sourcing, because it shapes the page. The EBICS specification sits behind a terms-of-use gate on ebics.org, so I did not build this from it. Everything below is printed in one of three open documents: Deutsche Bank's order type list (March 2026), Zürcher Kantonalbank's connection parameters (November 2025) and CFONB's implementation guide for France. What I could not find in an open document is listed at the end rather than filled in from memory.

Versions: 2.5 is H004, 3.0 is H005

A bank states two things about the version it speaks: the EBICS version and the schema version that goes on the wire. Zürcher Kantonalbank's sheet prints the pair plainly: EBICS 2.5 is schema version H004, EBICS 3.0 is schema version H005, and it accepts both.

On the specification side, EBICS SC lists V 3.0.2 as the current valid version, in force since 30 December 2022, and describes it as a revision with minor changes against V 3.0.1. Two annexes — the BTF External Code List and the TLS and KMS annex — are maintained separately and do not depend on a specific EBICS version.

The keys have versions too. The same sheet accepts A005 and A006 for the electronic signature, X002 for authentication and E002 for encryption. Three keys, one per use, which is why initialisation takes two uploads and a download.

The administrative order types

These manage the connection itself. They are the same idea in every country, and EBICS 3.0 keeps them as they are — Deutsche Bank's list marks HAC, HVT and HVZ as "Technical Order Type" where every file code has a BTF.

Three of these earn their keep on day two, not day one. HEV tells you which versions the bank's server speaks before you argue about it. HAA, HKD and HTD tell you what you are actually set up for — which is the fastest way to settle "the bank says we have C53" against "the client says not authorised". And HAC is the acknowledgement your system should be reading after every upload; Deutsche Bank's list gives its format as a pain.002 message, so it parses with the same code as your payment status reports. PTK is the customer protocol beside it; CFONB's guide calls it by its German name, Kunden Protokoll.

Initialisation: INI, HIA, a letter, then HPB

The sequence is the same everywhere, and the codes above are its steps.

1. Your system generates three key pairs: signature, authentication, encryption.
2. INI sends the public signature key. HIA sends the public authentication and encryption keys.
3. The bank cannot yet know those keys are yours. So the same keys are confirmed over a second channel. CFONB's guide describes it for a self-signed certificate: a printed document carrying the certificate, the user and partner IDs and the certificate's hash, signed by an authorised person — and in France three documents, one per certificate, are mandatory. These are the initialisation letters, and they are why EBICS onboarding has a signed document in it, sent outside EBICS.
4. The bank validates by matching the document against what arrived electronically.
5. HPB downloads the bank's public keys. You compare their hash values with the ones the bank published — Zürcher Kantonalbank prints them on its parameter sheet — and only then is the channel trusted in both directions.

Keys do not last for ever — CFONB's guide has self-signed certificates renewed after five years — and HCA, HCS and PUB are the order types for sending the new ones. The bank connectivity security page covers what to do about the keys once you hold them.

Germany: one code per file

Germany is where the three-letter file codes come from. Each names a file type and a direction. From Deutsche Bank's list, with the BTF it gives for EBICS 3.0 (service name, scope, service option, message name, container — an empty position is left empty):

Reading the table sideways is more useful than reading it down. The files are ones this site already takes apart: STA is the MT940, VMK the MT942, C52, C53 and C54 the camt.052, camt.053 and camt.054, CCT a pain.001, CDD and CDB a pain.008, RFT an MT101. EBICS adds nothing to their content. It names the envelope.

Two details in that list catch people.

• The downloads are ZIP files. C52, C53, C54 and the three status reports arrive as a ZIP with one to many messages inside. An importer that expects one XML document per download is wrong on the first busy day.
• The status report has its own order type. Uploading a CCT does not return the pain.002. You fetch it with CRZ — and CDZ for direct debits, CIZ for instant payments. A setup that sends payments and never schedules the matching Z download has no rejects, only silence.

The list also shows the standard moving. Since verification of payee arrived, the plain SEPA credit transfer has two codes — CCT without it and CTV with it — and a new download, VPZ, for its status report.

Switzerland: the same idea, different letters

Swiss banks use their own codes for Swiss formats. From Zürcher Kantonalbank's sheet:

The sheet also lists STA, VMK, CCT and RFT — the German letters — with a Swiss or global scope: STA there is EOP / CH / – / mt940, where Deutsche Bank's is EOP / DE / – / mt940. Same code, same file format, a different BTF. That one line is the whole argument for asking each bank for its sheet rather than copying the last bank's configuration.

It adds delivery notes the code alone does not tell you: VMK is provided as a file every 15 minutes during the day, as a delta; STA, HAC and PTK arrive concatenated in one file.

France: FUL and FDL, and a file-format parameter

France took a different route, and CFONB's guide says so in one sentence: the order types tied to a specific file format are not used in France. Instead there are two, for everything:

The type travels as a FileFormat parameter with a country code. The guide's own example is pain.xxx.cfonb160.dct with CountryCode="FR". The list of file-format names is a separate CFONB annex.

The guide also defines the two French profiles, by what they replaced:

• EBICS T (transport), the successor of ETEBAC 3. The file is sealed and sent over EBICS; the execution order is confirmed over another channel. Signatories sit in user class T.
• EBICS TS (transport and personal signature), the successor of ETEBAC 5. The electronically signed execution order travels with the file. Each signatory needs a personal signature certificate, issued by a certificate authority the bank recognises, and sits in user class E.

One caution on dates. The open English guide is version 2.1.4 from February 2012 and describes EBICS 2.4. It is the document that defines T, TS, FUL and FDL, so it is the right source for what they mean; it is not evidence of what a French bank offers on EBICS 3.0 today. Ask the bank.

BTF: how to read one

Deutsche Bank's list states the rule in its first paragraph: for EBICS 2.x the identifiers apply; as of 3.0, BTF are used instead, described by ServiceName, Scope, ServiceOption, MsgName and Container; and both versions can run in parallel. Zürcher Kantonalbank's sheet shows where the BTF goes: under order type BTU for an upload and BTD for a download.

So an EBICS 3.0 request for German camt.053 statements is not "C53". It is BTD with:

ServiceName    EOP
Scope          DE
ServiceOption  (empty)
MsgName        camt.053
Container      ZIP

Read down the tables above and the positions explain themselves. The service name is the business: SCT, SDD and SCI on SEPA credit transfers, direct debits and instant payments, XCT on foreign and urgent payments, EOP on the end-of-day statements, STM on the intraday reports and notifications, REP on status reports. The scope is whose rules the file follows — DE, CH, GLB, or empty. The service option narrows it: COR against B2B on a direct debit, SCT against SDD on a status report. The message name is the format, and the container says whether it is wrapped.

What this buys is one way to name a file across countries, which the three-letter codes never were. What it costs during migration is a mapping table: the same file has two names for as long as both versions run, and Swiss banks even print a third, a short description such as EOP_CH_camt.053_08_-_ZIP.

What goes wrong in practice

• Copying order types from the last bank. The codes are national lists with bank-specific additions. Deutsche Bank's own sheet has a page of X-prefixed codes it describes as proprietary. Run HAA and HTD against each bank and configure from the answer.
• Treating 2.5 and 3.0 as the same configuration. The file is identical; the request is not. A connection moved to H005 needs the BTF for every file it used to name with three letters.
• Forgetting the downloads that close the loop. HAC after every upload, the pain.002 order type for every payment type you send. They are separate requests on a schedule, and nobody misses them until a reject goes unseen.
• Budgeting initialisation as a technical task. It includes paper, a signature from someone authorised, and the bank's processing time. Start it before the testing window, not in it.

What this page leaves out

Named, so nobody mistakes an omission for a fact:

• The EBICS specification's own order type and BTF tables. They are behind ebics.org's terms-of-use gate. The lists above are what three institutions publish, not the full standard.
• The schema versions before H004, and what A005, A006, X002 and E002 each specify. The open documents I used name them and go no further.
• The French file-format names. They are in a separate CFONB annex I did not parse.
• Austria, and any bank's proprietary codes.
• The other distributed-signature order types. Deutsche Bank's list prints HVZ and HVT; the rest of that family is in the specification.

The code lookup has every code on this page beside the SAP, SWIFT and ISO 20022 ones, and the practice sets will drill them if you have a go-live coming.

See also the EBICS explainer for when to choose the channel, and the bank connectivity options overview for how it compares with SWIFT, host-to-host and APIs.