BTF (Business Transaction Formats)

Veröffentlicht am

11.09.2026

Aktualisiert am

11.09.2026

Lesezeit

3 min

Stand: 11. September 2026

Die Business Transaction Formats, kurz BTF, beschreiben in EBICS ab Version 3.0, was übertragen wird. Sie haben die zuvor national vergebenen Auftragsarten für bankfachliche Geschäftsvorfälle abgelöst – nicht durch neue Kürzel, sondern durch einen strukturierten Satz von Parametern.

Vorher: die Auftragsarten

In den Vorgängerversionen bestimmte eine dreistellige Auftragsart, worum es geht. CCT stand für die SEPA-Überweisung, CDD für die Basislastschrift, C53 für den Tagesauszug, STA für den Auszug im Altformat. Das war eingängig und funktionierte jahrelang zuverlässig.

Zwei Schwächen wuchsen mit der Zeit. Erstens brauchte jedes neue Format und jede neue Variante ein neues Kürzel – der Vorrat an sprechenden Dreibuchstabencodes ist begrenzt, und die Listen wurden lang. Zweitens vergab jedes Land seine eigenen: Was in Deutschland CCT hieß, hieß anderswo anders. Genau das steht dem Gedanken eines gemeinsamen Standards entgegen, den EBICS seit dem Zusammenschluss mehrerer Länder verfolgt.

Nachher: BTU, BTD und die Parameter

EBICS 3.0 trennt beides. Für den Transport bleiben genau zwei bankfachliche Auftragsarten übrig: BTU für das Einreichen zur Bank und BTD für das Abholen. Das Fachliche wandert in die BTF-Parameter, die die Nachricht beschreiben.

bis EBICS 2.5CCTCDDCDBC52C53STABankCCTCCT – SEPA-Überweisung einreichenwelche Fassung der pain.001 gemeint ist, sagt das Kürzel nichtCDDCDD – SEPA-Basislastschrift einreichendieselbe Nachricht wie die Firmenlastschrift, anderer CodeCDBCDB – SEPA-Firmenlastschrift einreichendie Variante steckt im Kürzel statt in einem FeldC52C52 – Zwischensaldenbericht abholenuntertägig, mehrmals am TagC53C53 – Tagesauszug abholennach GeschäftsschlussSTASTA – Kontoauszug im Altformat abholeneigenes Kürzel für dasselbe Anliegenab EBICS 3.0KundeBankBTU · Upload zur BankBTD · Download von der BankZwei Transportaufträge bleiben: BTU lädt zur Bank hoch, BTD holt von ihr abab EBICS 3.0KundeBankBTU · Upload zur BankBTD · Download von der BankServiceNameSCTScopeDEMsgNamepain.001Version09Das Fachliche steht in den Parametern – hier eine SEPA-Überweisung

Die Parameter im Einzelnen

  • ServiceName – der Dienst, um den es geht, etwa SCT für die SEPA-Überweisung oder EOP für den Tagesauszug.
  • Scope – das maßgebliche Regelwerk, als Ländercode wie DE oder CH oder als übergreifender Code.
  • ServiceOption – die Untervariante, etwa COR oder B2B bei Lastschriften.
  • MsgName – die Nachricht selbst, etwa pain.001 oder camt.053.
  • Version und Variant – Fassung und Variante der Nachricht, sofern nicht die jeweils aktuelle gilt.
  • Format – die Codierung, etwa XML, PDF oder CSV.
  • Container – ob die Daten verpackt übertragen werden, etwa als ZIP-Archiv.

Nicht jeder Parameter ist immer belegt. In vielen Fällen genügen ServiceName und MsgName, der Rest bleibt leer oder ergibt sich aus dem Regelwerk.

Alte Auftragsart und neue Parameter im Vergleich

Die folgende Übersicht zeigt für gängige Geschäftsvorfälle, was früher als Kürzel stand und wie es sich heute in Parametern ausdrückt. Die Werte sind Beispielbelegungen; verbindlich ist die Zuordnungsliste der Deutschen Kreditwirtschaft, die jährlich fortgeschrieben wird.

ParameterBeispielbelegung
SEPA-Überweisung  bisher CCT  ab 3.0 BTU
ServiceNameSCT
MsgNamepain.001
SEPA-Basislastschrift  bisher CDD  ab 3.0 BTU
ServiceNameSDD
ServiceOptionCOR
MsgNamepain.008
SEPA-Firmenlastschrift  bisher CDB  ab 3.0 BTU
ServiceNameSDD
ScopeDE
ServiceOptionB2B
MsgNamepain.008
Zwischensaldenbericht  bisher C52  ab 3.0 BTD
ServiceNameSTM
ScopeDE
MsgNamecamt.052
Tagesauszug  bisher C53  ab 3.0 BTD
ServiceNameEOP
ScopeDE
MsgNamecamt.053
Auszug im Altformat  bisher STA  ab 3.0 BTD
ServiceNameEOP
ScopeDE
MsgNamemt940

An der Gegenüberstellung wird der eigentliche Gewinn sichtbar: Die Information, die früher in einem Kürzel verborgen lag und nur mit einer Liste zu entschlüsseln war, steht jetzt lesbar in der Nachricht.

Was nicht abgelöst wurde

Ein verbreitetes Missverständnis: BTF hat nicht alle Auftragsarten ersetzt. Die administrativen Auftragsarten bleiben bestehen – die Kürzel für Initialisierung und Schlüsselübergabe, für den Abruf des Kundenprotokolls, für die Sperrung eines Teilnehmers oder für das Abholen der Bankparameter. Sie beschreiben keinen Zahlungsverkehrsinhalt, sondern steuern das Verfahren selbst; für sie gibt es nichts zu parametrisieren.

Praktisch heißt das: Wer eine EBICS-Anbindung baut, arbeitet weiterhin mit Auftragsarten – nur eben für die Verwaltung, während das Fachliche über BTU, BTD und die Parameter läuft.

Woher man weiß, was die Bank unterstützt

Welche BTF-Kombinationen ein Institut anbietet, ist nichts, was man raten müsste. Die Bank stellt ihre unterstützten Geschäftsvorfälle zum Abruf bereit, und die Kundensoftware liest daraus aus, was möglich ist. Das ist ein Fortschritt gegenüber der früheren Praxis, in der die zulässigen Auftragsarten aus einem PDF der jeweiligen Bank abgetippt wurden.

Übergang in der Praxis

EBICS 2.5 und 3.0 bestehen nebeneinander; nicht jeder Teilnehmer und nicht jedes Institut hat umgestellt. Für die Übergangszeit veröffentlicht die Deutsche Kreditwirtschaft eine Zuordnungsliste zwischen BTF und Auftragsarten, die jährlich fortgeschrieben wird – die aktuelle Fassung gilt seit Februar 2026.

Für die Umsetzung ergeben sich daraus drei Punkte:

  • Beide Welten beherrschen. Solange Gegenstellen auf 2.5 laufen, muss eine Anwendung Auftragsarten und BTF gleichermaßen bedienen.
  • Die Zuordnung pflegen. Die Liste ändert sich jährlich; wer sie einmalig fest verdrahtet, baut eine Altlast.
  • Nicht auf Kürzel abbilden. Verlockend ist, BTF intern wieder auf die gewohnten Dreibuchstabencodes zu übersetzen. Damit verschenkt man genau die Trennschärfe, für die die Parameter eingeführt wurden – etwa zwischen Formatversionen, die dasselbe Kürzel trügen.

Quellen für Spezifikationen