Grundlegende und aktuelle Informationen zum EBICS-Schema, zu den DK-ISO-Schemadateien u.v.m. sind auf www.ebics.de veröffentlicht.

Details zu den Datenformaten finden Sie im aktuellen DFÜ-Abkommen (Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und Kreditinstitut, kurz „Spezifikation der Datenformate“) ebenfalls auf www.ebics.de : EBICS - Gültige Version der Anlage 3 

Hinweis: Ab 2026 ändert sich die Versionsnummerierung der Anlage 3 - Es wird nun immer Jahr und Monat des Inkrafttretens der Version angegeben. Das aktuelle DFÜ-Abkommen trägt die Versionsnummer 3.9 und die ab 11/2026  gültige wird folglich die Version 26.11. 

Informationen zum „Format LifeCycle“ der einzelnen Versionen (SEPA-Formatversionen, Elektronische Umsatzinformationen, sonstige Formate) finden Sie hier: EBICS - Format LifeCycle 

Informationen zum „Krypto LifeCycle“ (mit Infos zu sicheren Schlüssellängen) sind hier dargestellt: EBICS - Krypto LifeCycle

Die unterstützen EBICS-Versionen sind im EBICS LifeCycle dokumentiert: EBICS - LifeCycle

Auch die Technischen Validation‑Schemas (TVS) der DK finden Sie unter EBICS - Ergänzende Dokumente. Für alle Zahlverfahren sowie dem Payment Staus Report (PSR) stehen standardisierte Technical Validation Subsets (TVS) bereit. TVS definieren verbindlich, welche Felder, Strukturen und Werte z.B. in SEPA‑Dateien zulässig sind, damit Zahlungen korrekt verarbeitet werden können. Sie werden als xsd-Dateien bereitgestellt.

Eine XSD‑Datei definiert:

• Welche Elemente (Felder) in einer SEPA‑Datei vorhanden sein müssen
• Welche Reihenfolge und welche Struktur die Elemente haben
• Welche Werte (Formate, Längen, Datentypen) zulässig sind
• Ob eine Datei technisch gültig ist (Validierung)

Eine xsd‑Datei ist der „Bauplan“ einer xml‑Zahlungsdatei.

Wer braucht diese Dateien?

• Softwarehäuser (z. B. Zahlungslösungen, ERP‑Hersteller)
• Entwickler und all die, die Validierungen (Tests) durchführen
• Systemanbieter, die pain-/camt‑Dateien verarbeiten

Für normale Anwender sind die Dateien meist nicht direkt relevant, aber für die korrekte Verarbeitung im Zahlungsverkehr sind sie zwingend notwendig.

Die Dateien tragen z. B. das Kürzel GBIC_5 („German Banking Industry Committee“) zur Versionsunterscheidung und entsprechen damit dem DK‑Standard des DFÜ-Abkommens Anlage 3, Version 3.9. 

Beispiele: 

pain.001.001.09_GBIC_5.xsd für SEPA-Überweisungen inkl. SCT inst

pain.001.001.09_AXZ_GBIC_5.xsd für Auslandszahlungen

pain.008.001.08_GBIC_5.xsd für SEPA-Lastschriften 

ISO 20022 ist der weltweit einheitliche Standard für elektronische Zahlungsverkehrsnachrichten. Hiermit wird eine globale Grundlage zur Verfügung gestellt. Mit Hilfe dieser wird beschrieben, wie Zahlungsdaten technisch aufgebaut sind – beispielsweise für Überweisungen, Lastschriften oder elektronische Umsatzinformationen.
Der Standard basiert auf XML als internationalem Datenformat und ermöglicht dadurch die strukturierte und maschinenlesbare Übermittlung aller relevanten Zahlungsinformationen.

Der ISO 20022‑Standard wird u.a. vom European Payments Council (EPC) für SEPA‑Zahlungen genutzt und regelmäßig weiterentwickelt. Die Neuerungen fließen in die aktuelle ISO 20022 2019er-Version ein. Somit ist diese Version derzeit Grundlage für moderne Zahlungsprozesse im SEPA‑ und auch im Auslandszahlungsverkehr (z. B. pain.001.001.09). Sie ermöglicht die Übertragung deutlich strukturierterer Zahlungsdaten. Dies ist z.B. bei den Adressinformationen der Fall. Mit ISO 20022 in der Version 2019 wird die Datenqualität weiter verbessert und die Zahlungsabwicklung wird durch Transparenz und Automatisierung noch effizienter.

Die frühere ISO 20022 2009er-Version (z. B. pain.001.001.03) bildet diese Modernisierungen nicht mehr ab. Am 14. November 2026 wird die Unterstützung demzufolge eingestellt. 

Im Gegensatz zur alten ISO-Version 2009 erfordern neue Formate in ISO-Version 2019 bereits seit März 2024 die Übermittlung der Adressdaten in strukturierter Form (ab GBIC_4). 

Dies dient der besseren Automatisierung, einer höheren Datenqualität und der Einhaltung regulatorischer Anforderungen, z. B. im Bereich Sanktionen und Geldwäscheprävention. Der Vorteil hierbei ist, dass Felder wie Straße, Hausnummer, Ort oder Land mit einer strukturierten Angabe eindeutig zuzuordnen sind. 

Viele Marktteilnehmer speichern ihre Kundenadressen derzeit in unstrukturierter oder nur teilweise strukturierter Form ab. Die Überführung aller Adressdaten in ein vollständig strukturiertes Format stellt daher für viele Unternehmungen eine erhebliche Herausforderung dar.

Aus diesem Grund ist mit Einführung der Anlage 3 des DFÜ-Abkommens in der Version 3.9 die hybride Adressbelegung in der ISO 20022‑Version 2019 für den Zahlungsverkehr zugelassen:

• für SEPA‑Zahlungen seit Oktober 2025,
• für EURO-Eil- und Auslandszahlungen seit November 2025.

Neben den verpflichtenden strukturierten Angaben Stadt (<TwnNm>)* und Land (<Ctry>)* können ergänzende Adressinformationen seitdem in bis zu zwei unstrukturierten Adresszeilen (<AdrLine>*, jeweils bis zu 70 Zeichen) übermittelt werden. Unstrukturierte Zeilen dürfen dabei keine Duplikate der bereits strukturiert gelieferten Felder enthalten.

Empfehlungen: Im Falle der Angabe einer Postadresse für Zahlungen mit Auslandsbezug sind immer möglichst alle Angaben zu machen, die Ihnen als Auftraggeber vorliegen. Verwenden Sie die vorgesehenen strukturierten Elemente (z.B. <StrtNm>* für Straße). So werden Ablehnungen vermieden.

* ISO 20022 XML-Elementbezeichnungen
 

Beispiele postalischer Adressen

Unstrukturierte Adresse in SEPA (ISO-Version 2009) 

...

<Nm>Test e.V.</Nm>

<PstlAdr>

    <Ctry>DE</Ctry>

    <AdrLine>Zentrale1, Teststrasse 26/3</ AdrLine>

    <AdrLine>50668 Köln / Ehrenfeld</ AdrLine>

</PstlAdr>

...

Strukturierte Adresse (ISO-Version 2019, ab GBIC_4)

…

<Nm> Test e.V.</Nm>

<PstlAdr>

     <Debt>Zentrale1</Debt>

     <StrtNm> Teststrasse </StrtNm>

     <BldgNb>26</BldgNb>

     <Flr>3</Flr>

     <PstCd>50668</PstCd>

     <TwnNm> Köln </TwnNm>

   <TwnLctnNm>Ehrenfeld</TwnLctnNm>

   <Ctry>DE</Ctry>

</PstlAdr>

…

Hybride Adresse (ISO-Version 2019, ab GBIC_5)

...

<Nm> Test e.V.</Nm>

<PstlAdr>

    <PstlCd>50668</PstlCd>

    <TwnNm>Köln</TwnNm>

    <Ctry>DE</Ctry>

    <AdrLine>Zentrale1</AdrLine>

    <AdrLine> Teststrasse 26/3, Ehrenfeld</AdrLine>

</PstlAdr>

Geltungs- und Anwendungsbereiche

Die genannten Vorgaben gelten für die postalischen Adressen in Auslandsüberweisungen (AXZ), in taggleichen Euro-Eilüberweisungen (CCU) und in SEPA-Zahlungen.  

Wichtig: Die Regeln dafür, wann Adressangaben verpflichtend sind und wann sie ggfs. optional gesetzt werden können, haben sich nicht geändert. Adressangaben – mindestens Stadt und Ländercode – sind immer dann anzugeben, wenn ein Teil der Transaktion außerhalb des eigenen Hoheitsgebiets liegt (z. B. außerhalb einer Region wie EU/EWR). Diese Definition umfasst „klassische Auslandszahlungen“ (die im xml-Format mit der EBICS-Auftragsart „AXZ“ übertragen werden) als auch SEPA-Zahlungen in Drittländer. Bei genau diesen SEPA-Zahlungen außerhalb des EWR (z. B. in die Schweiz oder Großbritannien) lautet die Empfehlung zusätzliche Adressangaben mitzugeben. Bei einem sogenannten Drittlandbezug vermeidet man so Nachfragen bzw. Rückgaben durch die Banken.

SEPA-Zahlungen innerhalb EU/EWR benötigen weiterhin keine Adressangaben. 

Neu sind lediglich die Angaben wie die Daten bei Verwendung auszusehen haben–im strukturierten oder hybriden Format. 

Konkrete Fragen zu Länderbesonderheiten bei Auslandszahlungen richten Sie bitte per Mail an den Fachbereich mit den Kontaktdaten: zahlungsverkehr@sozialbank.de

^{Abb.: ISO-Versionsmatrix (Adressarten vs. Formatversion) und Vergleich der Angaben}

Der EBICS-Auslandszahlungsverkehr umfasst alle beleglosen Zahlungen (Überweisungen und Scheckzahlungen), die von Deutschland aus in Länder außerhalb des Europäischen Wirtschaftsraums (EWR) oder in Fremdwährungen innerhalb des EWR ausgeführt werden. Für die elektronische Einreichung stehen aktuell zwei Formate zur Verfügung:

1. ISO 20022 / pain.001 (neues Format)
2. DTAZV (altes Format, Übergangsphase bis 11/2026)

Die Deutsche Kreditwirtschaft (DK) stellt das bisherige Format DTAZV zum November 2026 vollständig ein. Das DTAZV-Format ist ein textbasiertes und unstrukturiertes Format und somit nicht mehr zeitgemäß. Moderne Anforderungen – etwa strukturierte Daten, umfangreichere Angaben (z. B. zusätzliche Datenfelder, strukturierte Angaben) oder regulatorische Informationen – sind damit nicht mehr abbildbar. 

Die Umstellung ist aber nicht nur eine nationale DK‑Initiative.
Sie wird global durch SWIFT* und die weltweite Harmonisierung im Zahlungsverkehr vorgegeben. 

Damit ist klar:
Die Umstellung im deutschen Auslandszahlungsverkehr folgt einer globalen Vorgabe und sorgt dafür, dass die Kundendaten auch international korrekt und vollständig mit einer höheren Geschwindigkeit verarbeitet werden können.

Am 14. November 2026 stellt die SozialBank die Annahme und Verarbeitung von DTAZV-Einreichungen ein.
 
^{*SWIFT ist das weltweit genutzte Kommunikationsnetzwerk für sichere Zahlungs‑ und Finanznachrichten zwischen Banken. Es führt selbst keine Zahlungen aus, stellt aber die technische Infrastruktur und internationale Standards für den Nachrichtenaustausch bereit. SWIFT hat für den grenzüberschreitenden Zahlungsverkehr die Umstellung auf ISO 20022 verbindlich vorgegeben.}

Von DTAZV zum ISO 20022-Standard

Das langjährig genutzte Format DTAZV wird wie beschrieben im November 2026 vollständig durch das XML-basierte ISO 20022 pain.001.001.09-Format abgelöst.  Es unterscheidet sich technisch von den SEPA‑Formaten und den Nachrichten für taggleiche Euro‑Überweisungen (ebenfalls pain.001).

Das ISO 20022‑Format (pain.001) kann für den Auslandszahlungsverkehr seit November 2022 optional genutzt werden und wird ab November 2026 zum einheitlichen und verbindlichen Branchenstandard der Deutschen Kreditwirtschaft.

Nähere Informationen zum ISO 20022-Standard im Auslandszahlungsverkehr finden Sie in der aktuellen Version der Anlage 3 des DFÜ-Abkommens in Kapitel 3 EBICS - Gültige Version

EBICS-Informationen

Zur Übertragung über EBICS werden genutzt:

1. Auftragsart: AXZ (bei der SozialBank bereits aktiv und zugeordnet)
2. BTF‑Parameter: XCT/DE//pain.001/
3. Nachrichtentyp: pain.001.001.09
4. DK-TVS: pain.001.001.09_AXZ_GBIC_5.xsd (s.a. EBICS - Ergänzende Dokumente)
5. DFÜ-Abkommen Anlage 3 aktuelle Version, Kapitel 3 (s.a. EBICS - Gültige Version)
6. Adressdaten sind in strukturierter oder hybrider Form anzugeben
7. Hinweise zum LifeCycle sonstiger Formate (s.a. EBICS - Format LifeCycle)

Sonstige relevante EBICS-Infos:

• Zur besseren Verständlichkeit hat die Deutsche Kreditwirtschaft ein XML-Illustrationsbeispiel zu Kapitel 3 (Auslandszahlungsverkehr) mit dem zugehörigen TVS veröffentlicht EBICS - Ergänzende Dokumente.
• Während der Übergangszeit (11/2022–11/2026) kann es aufgrund der weltweiten Migration vereinzelt zu Einschränkungen bei einzelnen Datenfeldern und somit zu Informationsverlusten kommen.

Die SozialBank stellt Ihnen die elektronischen Kontoinformationen im modernen ISO‑20022‑Standard als CAMT.053 in der Version 08 bereit (camt.053.001.08).

Die früheren MT94x‑Formate und die ältere Camt-Version 02 werden nicht mehr unterstützt.

Wir stellen Ihnen sowohl den ISO Bank Transaction Code (BTC) und den bekannten GVC Code in den elektronischen Kontoinformationen zur Verfügung. Der GVC Code wird seitens der DK nicht mehr weiter fortgeschrieben und ist gemäß aktuellem DFÜ-Abkommen Anlage 3 in der Verwendung nur noch optional. Obwohl es noch kein offizielles Enddatum für den GVC gibt, wird empfohlen den BTC mit seinem größeren Informationsgehalt als führendes Kriterium zu betrachten.

Die DK veröffentlicht auf ihrer EBICS-Webseite zu Kapitel 7 (XML-Formate für Kontoinformationen) eine Mappingtabelle mit Zuordnungen von GVC zu BTC und weiteren Erläuterungen: Ergänzende Dokumente - EBICS

AZV-Abrechnungsdaten im camt-Auszug

Seit dem 20.11.2025 gilt:

Bei bestimmten AZV-Zahlungen (Kundenzahlungen, Bankzahlungen, Scheckeinreichungen) werden neben den Buchungsdaten auch die Abrechnungsdaten (Gebühren, Kurse, Steuern usw.) in die dafür bestimmten Felder ausgegeben. Die bisherige Auflistung im Verwendungszweck bleibt davon unberührt. 

Die entscheidenden Informationen liegen in der Tag-Gruppe <AmtDtls> (Detailinformationen zum Betrag) sowie in der Gebührengruppe <Chrgs> (Charges = Gebühren).  

Beispiel Tag-Gruppe <AmtDtls>

          <Amt Ccy="EUR">203.38</Amt>
          <CdtDbtInd>DBIT</CdtDbtInd>
          <AmtDtls>
              <InstdAmt>
                  <Amt Ccy="USD">240.54</Amt>
                  <CcyXchg>
                      <SrcCcy>USD</SrcCcy>
                      <TrgtCcy>EUR</TrgtCcy>
                      <UnitCcy>EUR</UnitCcy>
                      <XchgRate>1.1827</XchgRate>
                  </CcyXchg>
              </InstdAmt>
          </AmtDtls>

Beispiel Tag-Gruppe <Chrgs>

          <Chrgs>
              <Rcrd>
                  <Amt Ccy="EUR">8</Amt>
                  <CdtDbtInd>DBIT</CdtDbtInd>
                  <ChrgInclInd>true</ChrgInclInd>
                  <Agt><FinInstnId><BICFI>BANKDEFFXXX</BICFI></FinInstnId></Agt>
              </Rcrd>                                
          </Chrgs>

Textschlüsselergänzungen bei Rückgaben im camt-Auszug

Die Darstellung der im MT940-Auszug üblichen Textschlüsselergänzungen bei R-Transaktionen ist auch in der camt-Nachricht in der Elementgruppe <Prty> unter dem „Bank Transaction Code (BkTxCd)“ zu finden:

<Prtry>

    <Cd>NRTI+109+9250+914</Cd>

</Prty> 

Es gilt eine 1:1 Zuordnung/Weitergabe des bei der Rückgabe verwendeten SEPA-Returncodes. Somit lassen sich die Gründe für Rückgaben bereits aus dem „BkTxCd“ auslesen. 

Weitere Informationen finden Sie in der aktuellen Anlage 3 des DFÜ-Abkommens, Kapitel 7 (7.1.8.5.1). 

Am 21.11.2024 wurde für das camt.053 Format Folgendes geändert:

• Der Zeichenvorrat des Verwendungszwecks (Tag <Ustrd>, je max. 140 Zeichen) wird von vier Tags mit insgesamt 540 Zeichen auf sechs Tags mit insgesamt 810 Zeichen erweitert. Einschränkung: Dies gilt nur für bestimmte Entgeltbuchungen und AZV-Zahlungen.
   
• Der Tag <Btch>, innerhalb von <NtryDtls>, kann für alle eingereichten Kunden-Zahlungen (Kundensammler) folgende Tags zur Identifizierung des Sammlers enthalten:
  • <PmtInfId> ID des logischen Sammlers der Nachricht (Payment Information Identification)
  • <NbOfTxs> Anzahl der Transaktionen des Sammlers
  • <TtlAmt> Gesamtsumme des Sammlers
  • <CdtDbtInd> Indikator für Soll- bzw. Haben-Buchung