BTF (Business Transaction Formats)

Last updated: 11 September 2026

The business transaction formats, BTF for short, describe in EBICS from version 3.0 onwards what is being transmitted. They have replaced the previously national order types for business transactions – not with new codes, but with a structured set of parameters.

Before: the order types

In earlier versions a three-letter order type determined the subject. CCT stood for the SEPA credit transfer, CDD for the core direct debit, C53 for the end-of-day statement, STA for the statement in the legacy format. That was memorable and worked reliably for years.

Two weaknesses grew over time. First, every new format and every new variant needed a new code – the supply of meaningful three-letter codes is limited, and the lists grew long. Second, each country issued its own: what was CCT in Germany was called something else elsewhere. That runs against the idea of a common standard which EBICS has pursued since several countries joined forces.

After: BTU, BTD and the parameters

EBICS 3.0 separates the two. Exactly two business order types remain for transport: BTU to submit to the bank and BTD to collect from it. The business meaning moves into the BTF parameters that describe the message.

The parameters in detail

• ServiceName – the service concerned, such as SCT for the SEPA credit transfer or EOP for the end-of-day statement.
• Scope – the governing rulebook, as a country code such as DE or CH, or as an overarching code.
• ServiceOption – the sub-variant, such as COR or B2B for direct debits.
• MsgName – the message itself, such as pain.001 or camt.053.
• Version and Variant – version and variant of the message, where these are not the current ones.
• Format – the encoding, such as XML, PDF or CSV.
• Container – whether the data travels packaged, for instance as a ZIP archive.

Not every parameter is always populated. In many cases ServiceName and MsgName suffice; the rest stays empty or follows from the rulebook.

Old order type and new parameters compared

The overview below shows for common business cases what used to be a code and how it is expressed in parameters today. The values are example populations; what is binding is the mapping list of the German banking industry, which is updated annually.

The comparison makes the real gain visible: information that used to be hidden in a code and could only be decoded with a list now sits legibly in the message.

What was not replaced

A common misunderstanding: BTF has not replaced all order types. The administrative order types remain – the codes for initialisation and key exchange, for retrieving the customer log, for blocking a user or for collecting the bank parameters. They describe no payment content but steer the procedure itself; there is nothing to parameterise for them.

In practice this means anyone building an EBICS connection still works with order types – only now for administration, while the business side runs through BTU, BTD and the parameters.

How to know what a bank supports

Which BTF combinations an institution offers is not something to be guessed. The bank makes its supported business cases available for retrieval, and the customer software reads from it what is possible. That is an advance on the earlier practice of copying the admissible order types out of a PDF from the respective bank.

The transition in practice

EBICS 2.5 and 3.0 exist side by side; not every user and not every institution has migrated. For the transition the German banking industry publishes a mapping list between BTF and order types, updated annually – the current version has applied since February 2026.

Three points follow for implementation:

• Master both worlds. As long as counterparties run on 2.5, an application has to serve order types and BTF alike.
• Maintain the mapping. The list changes annually; hard-wiring it once creates a legacy burden.
• Do not map back onto codes. It is tempting to translate BTF internally back into the familiar three-letter codes. That gives away precisely the precision the parameters were introduced for – between format versions, for instance, which would share a single code.

Sources for specifications

• EBICS – specification and annexes, including the BTF external code list
• EBICS – mapping BTF / order types
• SIX – EBICS 3.0: structure of the BTF parameters (PDF)
• CPG Finance Systems – EBICS BTU, BTD and BTF