SEPA-Reporting
Aktualisierte Auflage mit den Neuerungen
ab 20. November 2016
Oktober 2016
2
Inhaltsverzeichnis
1 Vorwort 3
2 Auftragseinreichung und Reporting
4
3 Entstehungsgeschichte von SEPA
6
4 Änderungen für November 2016 8
5 Optionen für Reporting
11
5.1 camt.052/053/054 – Kontoinformation
11
5.2 pain.002 – Status Information
14
5.3 camt.029 – Status Information zum elektronischer Rückruf
18
5.4 MT940, MT942 – Kontoinformation
19
5.5 DTI – Datenträgerinformation
20
6 Die Report-Formate in der Praxis
21
7Anhang
30
7.1 Technische Formatbeschreibungen 30
7.1.1 camt.052/053/054 – Kontoinformation
30
7.1.2 pain.002 – Status Information
30
7.1.3 camt.029 Status Information zum elektronischen Rückruf
35
7.1.4 MT940, MT942 – Kontoinformation
37
7.1.5 DTI – Datenträgerinformation
39
7.2 Geschäftsvorfall- und Rückgabecodes
41
7.3EBICS-Auftragsarten
42
3
1 Vorwort
Mit Einführung des SEPA haben Kunden verschiedene Optionen, Reports für Kontoinformationen sowie Statusreports von Auftrags­einreichungen abzurufen. In der vorliegenden Broschüre erhalten Sie wesentliche Details zu
den Optionen mit Verweis auf die zugehörigen technischen Spezifikationen und verschiedenen SEPA-Formate. Bei
den nachfolgenden Informationen handelt es sich um Empfehlungen, deren Grundlage das DFÜ-Abkommen der
Deutschen Kreditwirtschaft ist.
Weitere Details und Angaben zu technischen Feldern sowie XML-Schemata (XSD) entnehmen Sie der Anlage 3
der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und Kreditinstitut gemäß
DFÜ-Abkommen Version 3.0 vom 11. Januar 2016, gültig ab 20. November 2016:
www.ebics.de/spezifikation/dfue-abkommen-anlage-3-formatstandards
4
2 Auftragseinreichung und Reporting
Mit SEPA wurde der Standard für Zahlungen und Kundenreporting auf ISO 20022 (XML) gehoben. Für die
Einreichung von Inlands- und EU-Zahlungen im Kunde-Bank-Prozess wurde mit der EU-Migrationsverordnung
260/2012 das ISO 20022-Format obligatorisch. Für die Bank-Kunde-Seite ist dieses optional. Vorteilhaft ist bei
einem durchgängigen ISO 20022-Format – vom Einreicherkunden bis zum Zahlungsempfänger –, dass in diesem
Fall auch alle Zahlungsinformationen durchgeleitet werden.
Kunden reichen bei Banken das pain-Format für Zahlungsdateien ein. Im Interbankenverhältnis werden die
Zahlungen dann zwischen den Banken mit dem pacs-Format ausgetauscht. Der Kunde kann Reports über den
Verarbeitungsstand seiner Einreichung abrufen. Als Kontoinformation über die Buchungen wird das camt-Format
optional zur Vefügung gestellt. Fehler/Rejects können optional an den Kunden auch als Datei im pain-Format von
der Bank zur Verfügung gestellt werden.
Die HypoVereinsbank (HVB) bietet ihren Kunden an, Kontoinformationen und Reports auch noch in den
Alt-Formaten MT940 und DTI bereitzustellen. In den nächsten Kapiteln werden die verschiedenen Formate
vorgestellt, damit auf dieser Basis die optimale Entscheidung für die SEPA-Umsetzung getroffen werden kann.
Nachrichtenaustausch im Format ISO 20022 (XML)

pain
• pain = payment initiation
• Zahlungsverkehrsinitiierung für
• Überweisungen (pain.001)
• Lastschriften (pain.008)
pacs
• pacs = payment clearing & settlement
• Clearing für
• Überweisungen (pacs.008)
• Lastschriften (pacs.003)
camt
• camt = cash management*
• Kontoinformationen
• Avis (camt.052)
• Auszug (camt.053)
• Sammelbuchungsdatei (camt.054)
Kunde
Bank
Kunde
Zahlungsauftrag
 Kundeninformation 

pain
pacs
Status Informationen
• pain = payment initiation Status
Information**
• positive und negative Status
Information (pain.002)
• pacs = C&S Fehlernachrichten
• Fehlermeldung/Status Message
(pacs.002)
* Optional auch als MT940 oder DTI
** Optional auch als DTI
5
Erweitert wird die Nutzung des Standards ISO20022 durch die elektronische Rückrufanfrage camt.055. Kunden
reichen zu einem ursprünglichen Zahlungsauftrag eine Rückrufanfrage ein. Die Rückrufanfrage kann entweder
zeitnah durch die HVB mit einer Status Information camt.029 beantwortet werden oder muss im Fall einer Überweisung zwischen den beteiligten Zahlungsverkehrsdienstleistern unter Beteiligung des Zahlungsempfängers
geklärt werden.

pain
Kunde
camt
Zahlungsauftrag/Rückruf
Bank
Status Informationen
• pain = payment initiation
• Zahlungsverkehrsinitiierung für
• Überweisungen (pain.001)
• Lastschriften (pain.008)
• camt = cash management
• Kundenrückruf (camt.055)
Kunde
camt

• camt = cash management
• Rückruf auf Interbankebene
(camt.056)
pain
pacs
• camt = cash management
• Status Information an Kunden (camt.029)
• camt = cash management
• Negativantwort auf Interbankebene (camt.029)
• Rückgabe durch Zahlstelle/Rückgabe durch
Zahlungspflichtigen (pacs.004)
6
3 Entstehungsgeschichte von SEPA
Jedes Jahr im November tritt ein neues Rulebook in Kraft, das die Grundlage für die fortschreitenden
Anpassungen an die aktuellen Bedürfnisse bildet. Für Sie bedeuten diese jährlichen Rulebook-Änderungen, dass
Sie gegebenenfalls auch Anpassungen in den Formaten vornehmen müssen. Die Deutsche Kreditwirtschaft
hat vereinbart, dass grundsätzlich immer die aktuelle Formatversion und die Vorgänger­version angenommen
werden sollen. Die HVB nimmt darüber hinaus auch noch ältere Versionen an und stellt dann auch die Status
Informationen pain.002 passend zur älteren Version bereit. Für Nutzung neuer Funktionalitäten müssen allerdings
auch die entsprechenden Formate verwendet werden.
November 2015 (DFÜ-Anlage 3 – Version 2.9)
• Anpassungen bei den elektronischen Kontoauszügen
November 2014 (DFÜ-Anlage 3 – Version 2.8)
• Keine Formatänderungen
• Anpassungen in den Kontoauszugsformaten
November 2013 (DFÜ Anlage 3 – Version 2.7)
• Formatversionen: pain.001.003.03, pain.008.003.02, pain.002.003.03
• camt unverändert camt.05x.001.02
November 2012 (DFÜ Anlage 3 – Version 2.6)
• Keine Formatänderungen
• Rückgabegrund AC13, wenn Zahlungspflichtiger ein Verbraucher ist, und
FF05, wenn Lastschrift mit verkürzter Vorlauffrist COR1 nicht möglich ist
November 2011
• Keine Formatänderungen
November 2010 (DFÜ Anlage 3 – Version 2.5)
• Formatversionen: pain.002.002.03
• camt unverändert camt.05x.001.02
• Restrukturierung der Reject pain.002-Nachricht auf Kundenbedürfnisse
• Strukturierte Rückmeldung im MT940/MT942/DTI von Retouren-Gebühren
November 2009 (DFÜ Anlage 3 – Version 2.4)
• Start SEPA-Basislastschrift (Direct Debit Core) und SEPA-Firmenlastschrift (Direct Debit B2B)
• Formatversionen: pain.002.002.02
• Optional: Definition der Formate für XML-Auszug camt.052.001.02, camt.053.001.02, camt.054.001.02
7
November 2008 (DFÜ Anlage 3 – Version 2.3)
• Keine inhaltlichen Formatänderungen, aber Berücksichtigung von Gruppierung und Containern: pain.002.001.02.
ct, pain.002.001.02.ct.con
Januar 2008 (DFÜ Anlage 3 – Version 2.2)
• Start SEPA-Überweisung (Credit Transfer)
• Formatversionen: pain.002.001.02.ct
• MT940 mit SEPA-Informationen
• Noch keine Definition der Formate für XML-Auszug (camt.05x)
8
4 Änderungen für November 2016
Zum 20. November 2016 wird eine neue DFÜ-Anlage 3, Version 3.0, eingeführt, welche folgende Änderungen
bzgl. des Reporting mit Konto- und Status Informationen enthalten wird (siehe auch Veröffentlichung unter
www.ebics.de):
Anpassungen im Reporting generell
• Neuer GVC:
• 117 SEPA Dauerauftrag (Sollbuchung)
• Umstellung des Scheck-Clearings auf XML. Im Wesentlichen werden die GVCs aus der Gruppe 0XX abgelöst
durch folgende neue GVCs in der Gruppe 1XX:
• 101 Inhaberscheck (Sollbuchung)
• 102 Orderscheck (Sollbuchung)
• 103 Reisescheck (Sollbuchung)
• 111 Rückrechnung von Schecks (Sollbuchung)
• 112 Zahlungsanweisung zur Verrechnung (Sollbuchung)
• 122 Währungsscheck auf Euro (Sollbuchung)
• 170 Gutschrift aus Scheckeinreichung E.v.
• 183 Scheckrückgabe (Habenbuchung)
• 185 Scheckbelastung Sammler (Sollbuchung)
Die von der HVB bisher für Schecks verwendeten GVCs 001 und 070 entfallen ab dem 21. November 2016.
Für die Rückrechnung von Schecks (GVC 111) werden folgende ReturnReasonCodes verwendet:
ISO Code (camt.05x)
TxErgänzung (MT94x, DTI)
Text
AC01
901
IBAN fehlerhaft
AG02
905
TACODE/DATEIFORMAT ungültig
AC04
902
Konto aufgelöst
CUST
925
Durch Kunden / Schecksperre
MS03
914
Sonstige Gründe
• Die im Rahmen der Umstellung der Scheckabwicklung auf ISO 20022 ab November 2016 notwendig werdenden Anpassungen in DTI sind nicht in der Anlage 3 des DFÜ-Abkommens spezifiziert, werden aber von der HVB
sinngemäß analog der übrigen ISO 20022 Transaktionen (SEPA Überweisungen/SEPA Lastschriften) umgesetzt.
Es wird Kunden empfohlen, frühzeitig auf das XML Format camt.054 umzusteigen.
• Ab November 2017 ist im DFÜ-Abkommen der Deutschen Kreditwirtschaft vorgesehen, DTI als Service
zugunsten camt.054 komplett einzustellen.
9
Das neue ISO 20022 basierte Scheckclearing wirkt sich neben den neuen GVCs auch auf die Darstellung von
Scheckbuchungen im elektronischen Kontoauszug (MT940/MT942, camt.052, camt.053 und camt.054) aus.
Details und Beispiele siehe nachfolgend.
MT940/MT942
:61:161121121D123,45NCHK0000123456789//987654321
:86:101?00Inhaberscheck?109208?20EREF+SCHECK-NR. 00001234567?2189?30HYVEDEMMXXX?31
DE90700202701234567892
camt.052, camt.053, camt.054
<Ntry>
<Amt CCy="EUR">123.45</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<StS>BOOK</StS>
<BookgDt>
<Dt>2016-11-21</Dt>
</BookgDt>
<ValDt>
<Dt>2016-11-21</Dt>
</ValDt>
<AcctSvcrRef>987654321</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>ICHQ</Cd>
<SubFmlyCd>CCHQ</SubFmlyCd>
</Fmly>
</Domn>
<Prtry>
<Cd>101</Cd>
<Issr>DK</Issr>
</Prtry>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<EndToEndId>SCHECK-NR. 0000123456789</EndToEndId>
<TxId>373013024623CTD130911KMVE</TxId>
<ChqNb>0000123456789</ChqNb>
</Refs>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>ICHQ</Cd>
<SubFmlyCd>CCHQ</SubFmlyCd>
</Fmly>
</Domn>
<Prtry>
<Cd>NCHK+101+100</Cd>
<Issr>DK</Issr>
</Prtry>
</BkTxCd>
10
<RltdPties>
<Dbtr>
<Nm>SCHECKAUSSTELLER</Nm>
</Dbtr>
<DbtrAcct>
<Id>
<IBAN>DE99700202707777777777</IBAN>
</Id>
</DbtrAcct>
<Cdtr>
<Nm>SCHECKEINREICHER</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>DE90700202701234567892</IBAN>
</Id>
</CdtrAcct>
</RltdPties>
<RltdAgts>
<DbtrAgt>
<FinInstnId>
<BIC>HYVEDEMMXXX</BIC>
</FinInstnId>
</DbtrAgt>
<CdtrAgt>
<FinInstnId>
<BIC>HYVEDEMMXXX</BIC>
</FinInstnId>
</CdtrAgt>
</RltdAgts>
<Purp>
<Cd>BCDM</Cd>
</Purp>
</TxDtls>
</NtryDtls>
<AddtlNtryInf>Inhaberscheck</AddtlNtryInf>
</Ntry>
Erweiterungen in den camt.052, camt.053 und camt.054 Nachrichten
• Für alle Geschäftsvorfallcodes (GVC) wurde ein Mapping auf ISO Domain/Family/Subfamily definiert. Dieses
Mapping wird nun als gesondertes Dokument (Anhang 1 der Anlage 3 des DFÜ-Abkommens) geführt.
• Der Proprietary BankTransactionCode (GVC) wird für alle Buchungen künftig auf Entry-Level als 3-stelliger
numerischer Code (im Beispiel „101“) ausgewiesen. Dies erfolgt parallel zur bisherigen Darstellung auf
TransactionDetails-Level (im Beispiel „NCHK+101+100“).
• Der Issuer ändert sich von „ZKA“ auf „DK“.
Im Rahmen des Mappings wurde die GVC-Liste aktualisiert (Änderungen, Erweiterungen) und teilweise auch
bereinigt (Löschungen). Siehe auch die Broschüre Geschäftsvorfall- und Rückgabecodes.
11
5 Optionen für Reporting
Welcher Report ist für welchen Zweck? In der folgenden Tabelle finden Sie eine Übersicht der möglichen Optionen
elektronischer Kontoinformationen rund um Kontoauszüge, Avise, Buchungssammler und Statusreports.
Empfohlen für
Optionen
Einschränkung/
zu beachten
Format
Mögliche
Bereitstellung*
MT940
Elektronischen Kontoauszug –
Altsysteme
Nicht alle SEPA-Felder
werden durchgereicht.
MT940
Tagesende Buchungstag
MT942
ZV-Avis – Altsysteme
Nicht alle SEPA-Felder
werden durchgereicht.
MT942
½-stündlich Buchungstag
DTI
Elektronische Weiterverarbeitung
von Eingängen und Retouren­
verarbeitung – Altsysteme
Nicht alle SEPA-Felder
werden durchgereicht.
DTAUS0
DTAUS1
½-stündlich Buchungstag
camt.052
Elektronisches ZV-Avis – Neu
camt.052.001.02
½-stündlich Buchungstag
camt.053
Elektronischen Kontoauszug – Neu
camt.053.001.02
Tagesende Buchungstag
camt.054
Elektronische Weiterverarbeitung
von Eingängen und Retouren­
verarbeitung – Neu
• Elektronische Information
über die eingereichte SEPADatei
• Seit Juni 2013 optional auch:
Lastschrift-Retouren vor
Buchung
camt.054.001.02
½-stündlich Buchungstag
pain.002
Positive und negative Status
Information auf Datei und
Transaktions-Ebene für ein zeitnahes
Statustracking der eingereichten
Zahlungsaufträge
Optional seit November 2012:
auch SEPA-Fehlernachrichten
nach Buchung
Optional seit November 2015:
Positive Status Information
DK:
• pain.002.001.03
• pain.002.003.03
• pain.002.002.03
• pain.002.002.02
EPC:
• pain.002.001.03
Zeitnah bei
Fehlerfeststellung
camt.029
Verpflichtend bei elektronischen
Rückrufanfragen camt.055
• camt.029.001.06
Zeitnah bei Vorliegen eines
Ergebnisses für die Rückrufanfrage
Keine LastschriftRetouren-Gebühren­
ausweisung
* Weitere Details zu den Konfigurationsmöglichkeiten der Bereitstellungszeiten stellt Ihnen auf Anfrage Ihr Cash Management & eBanking-Spezialist gerne zur Verfügung.
5.1
camt.052/053/054 – Kontoinformation
SEPA-Zahlungsaufträge und -Lastschriftaufträge werden im international gültigen, normierten ISO 20022
XML-Standard abgewickelt. Dies erlaubt es, weitere Informationen wie die IBAN (International Bank Account
Number), den BIC (Business Identifier Code) für die Bank­identifikation, verschiedene Referenzen und zusätzliche
abweichende Auftraggeber- und Empfängerangaben mitzugeben. Um diese weiteren Informationen strukturiert
auch im elektronischen Kontoauszug und im Avis zur Verfügung zu stellen, bietet ISO 20022 den camt.053Kontoauszug, das camt.052-Avis und die camt.054-Sammel­buchungsinformationen an.
Der XML-Kontoauszug camt.053 ersetzt den MT940 im SWIFT-Format, das XML-Avis camt.052 ersetzt den
MT942, die XML-Sammelbuchungsinformationen camt.054 ersetzt den DTI im DTA-Format. Eine Umstellung auf
den camt.052, camt.053 bzw. camt.054 ist von Seiten des Gesetzgebers nicht verpflichtend. Neben den Kontoinformationen im neuen XML-Format werden von der HVB weiterhin die bestehenden SWIFT- und DTI-Formate
alternativ angeboten.
12
ISO 20022
Cash
Management
Nachricht
Auftragsart
camt.052
C52
camt.053
C53
camt.054
C54
Definition
Untertägige
Avise
Kontoauszug
Sammler-Details
Äquivalent
SWIFT MT942
SWIFT MT940
DTI
camt.052 und camt.053
Avise als camt.052 enthalten alle Detailinformationen zu den Buchungen, die dem Konto untertägig belastet
oder gutgeschrieben wurden. Der camt.052 ergänzt daher optimal den im camt.053 bereitgestellten Konto­
auszug durch zusätzliche untertägige Informationen. Die Verarbeitung von camt-Nachrichten auf Kundenseite in
bestehenden ERP-Systemen erfordert eine Anpassung der bisherigen Routinen. Um einen reibungslosen Übergang
zu gewährleisten, können bestehende SWIFT-Formate (MT94x) und die neuen camt.05x-Formate je Konto parallel
bereitgestellt werden.
Anfang Buchungstag
CAMT.053
<?xml version=“1.0“ ?>
<Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
XMLSchema-instance“>
<BkToCstmrStmt>
<GrpHdr>
<MsgId>20120327215510798007</MsgId>
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<MsgRcpt>
<Nm>Test Name</Nm>
<PstlAdr>
<AdrLine>Am Tucherpark 1</AdrLine>
<AdrLine>80538 München</AdrLine>
…
<Stmt>
<Ntry>
<Amt Ccy=“EUR“>2.18</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>BOOK</Sts>
…
<Cdtr>
<Nm>Counterpart Name</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>DE74700202700000001234</IBAN>
…
Buchungstag
CAMT.052
CAMT.052
Ende Buchungstag
Anfang nächster Tag
CAMT.053
<?xml version=“1.0“ ?>
<Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<?xml version=“1.0“ ?>
XMLSchema-instance“> <Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<BkToCstmrStmt>
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<GrpHdr>
XMLSchema-instance“> <?xml version=“1.0“ ?>
<Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<MsgId>20120327215510798007</MsgId>
<BkToCstmrStmt>
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<?xml version=“1.0“ ?>
<GrpHdr>
XMLSchema-instance“> <Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<MsgRcpt>
<MsgId>20120327215510798007</MsgId>
<BkToCstmrStmt>
<Nm>Test Name</Nm>
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<GrpHdr>
<PstlAdr>
XMLSchema-instance“>
<MsgRcpt>
<MsgId>20120327215510798007</MsgId>
<AdrLine>Am Tucherpark
1</AdrLine>
<BkToCstmrStmt>
<Nm>Test
Name</Nm>
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<AdrLine>80538 München</AdrLine>
<GrpHdr>
<PstlAdr>
<MsgRcpt>
…
<MsgId>20120327215510798007</MsgId>
<AdrLine>Am Tucherpark
1</AdrLine>
<Nm>Test Name</Nm>
<Rpt>
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<AdrLine>80538 München</AdrLine>
<PstlAdr>
…
<MsgRcpt>
…
<AdrLine>Am Tucherpark
1</AdrLine>
<Ntry>
<Nm>Test
Name</Nm>
<Rpt>
<AdrLine>80538 München</AdrLine>
<Amt Ccy=“EUR“>2.18</Amt>
<PstlAdr>
…
…
<CdtDbtInd>DBIT</CdtDbtInd>
<AdrLine>Am Tucherpark 1</AdrLine>
<Ntry>
<Rpt>
<Sts>PDNG</Sts> <Amt Ccy=“EUR“>2.18</Amt>
<AdrLine>80538 München</AdrLine>
…
…
…
<CdtDbtInd>DBIT</CdtDbtInd>
<Rpt>
<Sts>PDNG</Sts> <Ntry>
<Amt Ccy=“EUR“>2.18</Amt>
…
…
<CdtDbtInd>DBIT</CdtDbtInd>
<Ntry>
<Sts>PDNG</Sts> <Amt Ccy=“EUR“>2.18</Amt>
…
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>PDNG</Sts>
…
CAMT.052
CAMT.052
Kunde
<?xml version=“1.0“ ?>
<Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
XMLSchema-instance“>
<BkToCstmrStmt>
<GrpHdr>
<MsgId>20120327215510798007</MsgId>
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<MsgRcpt>
<Nm>Test Name</Nm>
<PstlAdr>
<AdrLine>Am Tucherpark 1</AdrLine>
<AdrLine>80538 München</AdrLine>
…
<Stmt>
<Ntry>
<Amt Ccy=“EUR“>2.18</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>BOOK</Sts>
…
<Cdtr>
<Nm>Counterpart Name</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>DE74700202700000001234</IBAN>
…
13
camt.054
camt.054-Nachrichten enthalten die Einzelpositionen für Ein- und Ausgänge von Überweisungen oder
Lastschriften, welche im camt.053 als Sammler gebucht werden. Dabei entspricht ein Buchungsposten
(Sammelbetrag) jeweils einer camt.054-Nachricht.
Alternativ bietet die HVB ihren Kunden auch an, die Einzeltransaktionen in den camt.053-Kontoauszug zu
integrieren.
CAMT.054
CAMT.054
Ende Buchungstag
CAMT.053
<?xml version=“1.0“ encoding=“UTF-8“ ?>
<Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<?xml version=“1.0“ encoding=“UTF-8“ ?>
camt.054.001.02“ xmlns:xsi=“http://www.w3.org/2001/
XMLSchema-instance“> <Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<?xml version=“1.0“ encoding=“UTF-8“ ?>
camt.054.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<BkToCstmrDbtCdtNtfctn>
XMLSchema-instance“> <Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<GrpHdr>
<?xml version=“1.0“ encoding=“UTF-8“ ?>
camt.054.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<BkToCstmrDbtCdtNtfctn>
<MsgId>DDY130109AC54000001</MsgId>
XMLSchema-instance“> <Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
<GrpHdr>
<CreDtTm>2013-01-09T07:30:00.000+02:00</CreDtTm>
camt.054.001.02“ xmlns:xsi=“http://www.w3.org/2001/
<BkToCstmrDbtCdtNtfctn>
<MsgId>DDY130109AC54000001</MsgId>
<MsgRcpt>
XMLSchema-instance“>
<GrpHdr>
<CreDtTm>2013-01-09T07:30:00.000+02:00</CreDtTm>
<Nm>Test Name</Nm>
<BkToCstmrDbtCdtNtfctn>
<MsgId>DDY130109AC54000001</MsgId>
<MsgRcpt>
<PstlAdr>
<GrpHdr>
<CreDtTm>2013-01-09T07:30:00.000+02:00</CreDtTm>
<Nm>Test
Name</Nm>
<AdrLine>Am Tucherpark 1</AdrLine>
<MsgId>DDY130109AC54000001</MsgId>
<MsgRcpt>
<PstlAdr>
<AdrLine>80538 München</AdrLine>
<CreDtTm>2013-01-09T07:30:00.000+02:00</CreDtTm>
<Nm>Test
Name</Nm>
<AdrLine>Am
Tucherpark
1</AdrLine>
…
<MsgRcpt>
<PstlAdr>
<AdrLine>80538
München</AdrLine>
<Ntfctn>
<Nm>Test
Name</Nm>
<AdrLine>Am
Tucherpark
1</AdrLine>
…
…
<PstlAdr>
<AdrLine>80538
München</AdrLine>
<Ntfctn>
<Ntry>
<AdrLine>Am Tucherpark 1</AdrLine>
…
…
<Amt Ccy=“EUR“>10.22</Amt>
<AdrLine>80538 München</AdrLine>
<Ntfctn>
<Ntry>
<CdtDbtInd>DBIT</CdtDbtInd>
…
…
<Sts>BOOK</Sts> <Amt Ccy=“EUR“>10.22</Amt>
<Ntfctn>
<Ntry>
<CdtDbtInd>DBIT</CdtDbtInd>
…
…
<Sts>BOOK</Sts> <Amt Ccy=“EUR“>10.22</Amt>
<Dbtr>
<Ntry>
<CdtDbtInd>DBIT</CdtDbtInd>
…
<Nm>Counterpart Name</Nm>
<Amt Ccy=“EUR“>10.22</Amt>
<Sts>BOOK</Sts>
<Dbtr>
</Dbtr>
<CdtDbtInd>DBIT</CdtDbtInd>
…
<Nm>Counterpart
Name</Nm>
<DbtrAcct>
<Sts>BOOK</Sts>
<Dbtr>
</Dbtr>
<Id>
… Name</Nm>
<Nm>Counterpart
<DbtrAcct>
<IBAN>DE74700202700000001234</IBAN>
<Dbtr>
</Dbtr>
<Id>
…
<Nm>Counterpart Name</Nm>
<DbtrAcct>
<IBAN>DE74700202700000001234</IBAN>
</Dbtr>
<Id>
…
<DbtrAcct>
<IBAN>DE74700202700000001234</IBAN>
<Id>
…
<IBAN>DE74700202700000001234</IBAN>
…
CAMT.054
CAMT.054
Kunde
<?xml version=“1.0“ encoding=“UTF-8“ ?>
<Document xmlns=“urn:iso:std:iso:20022:tech:xsd:
camt.053.001.02“ xmlns:xsi=“http://www.w3.org/2001/
XMLSchema-instance“>
<BkToCstmrStmt>
<GrpHdr>
<MsgId>20120327215510798007</MsgId>
<CreDtTm>2012-03-27T19:00:00.000+02:00</CreDtTm>
<MsgRcpt>
<Nm>Test Name</Nm>
<PstlAdr>
<AdrLine>Am Tucherpark 1</AdrLine>
<AdrLine>80538 München</AdrLine>
…
<Stmt>
<Ntry>
<Amt Ccy=“EUR“>10.22</Amt>
…
<AddtlInfInd>
<MsgNmId>camt.054</MsgNmId>
<MsgId>DDY130109AC54000001</MsgId>
</AddtlInfInd>
…
<Stmt>
<Ntry>
<Amt Ccy=“EUR“>14.22</Amt>
…
<AddtlInfInd>
<MsgNmId>camt.054</MsgNmId>
<MsgId>DDY130109AC54000002</MsgId>
</AddtlInfInd>
…
Sammelbuchungsinformationen
Informationen zu den Einzeltransaktionen
Untertägig
14
5.2
pain.002 – Status Information
Der pain.002 stellt Ihnen elektronisch die Status Informationen zu Ihren eingereichten Transaktionen zur
Verfügung. Das Datenformat des pain.002 basiert auf dem internationalen XML-Standard ISO 20022.
Mit der pain.002 Status Information erhalten Sie positive Rückmeldungen an definierten Verarbeitungspunkten
und eine genaue Rückmeldung zu den fehlerhaften Dateien, Einzelsätzen sowie zur Art der Fehler. Hiermit können
Sie die eindeutige Zuordnung zu Ihren originalen Einreichungen sicherstellen. Die folgende Darstellung zeigt die
wesentlichen Verarbeitungspunkte im Gesamtprozess.
Auftraggeber
Bank des
Auftraggebers
Bank des
Empfängers
Empfänger
Beispiel
SEPA-Lastschrift
pain.002
Auftraggeber initiiert
Auftraggeber-Bank initiiert
pacs
Rückruf
Fachlich akzeptiert
Rückweisung
Zahlungspflichtiger-Bank initiiert
Rückweisung
Zahlungspflichtiger initiiert
Settlement
Reject
Rückweisung
Zur Buchung gegeben
Durch die Nutzung der pain.002 Status Information ergeben sich folgende Aspekte:
• Durch die vollständige Nutzung von ISO 20022-Nachrichten bleiben alle relevanten Informationen von der
Einreichung bis zur Rückmeldung erhalten.
• Die positive Status Information ermöglicht Ihnen die zeitnahe Statusermittlung an den definierten
Verarbeitungspunkten im Prozess.
• Die pain.002 Status Information liefern Ihnen wertvolle Information vor dem Kontoauszug (camt.053), der am
Folgetag nach der Buchung vorliegt.
• Der Fehler-Report erfolgt bereits vor Buchung (vergleichbar mit bestehendem Fehlerprotokoll).
Das ist insbesondere bei SEPA Direct Debit interessant, da hier die Weiterleitung des Auftrags an die Bank des
Zahlungs­pflichtigen vor Fälligkeit erfolgt und dessen Bank den Auftrag auch vor Fälligkeit prüfen kann (z. B. ob
das Konto existiert). Die Abweisung mit Fehlergrund kann dann auch schon vor Fälligkeit bzw. Buchung an den
Einreicher erfolgen (z. B. wenn das Konto aufgelöst ist). Ein Reklamationsprozess auf Seiten des Einreichers kann
also sofort beginnen und nicht erst ab Fälligkeits­datum.
15
In der folgenden Übersicht werden mögliche Gründe für Abweisungen von Lastschriften durch R-Nachrichten vor
der Buchung aufgeführt:
Auftraggeber
initiierte R-Nachrichten:
Vor Buchung
• Rückruf (Revocation / Recall)
z. B. Bestätigung der Revocation
Einreicher-Bank
initiierte R-Nachrichten:
Vor Buchung
• Zahlungspflichtiger-Bank für Lastschriften nicht SEPA-ready
• Pflichtfelder fehlen
• IBAN-Check fehlerhaft
Zahlungspflichtiger-Bank
initiierte R-Nachrichten bei Lastschriften:
Vor Buchung
• Reject, z. B.
• Zahlungspflichtiger-Konto besteht nicht
• Zahlungspflichtiger-Konto gesperrt
Zahlungspflichtiger
initiierte R-Nachrichten:
Vor Buchung
• Mandatssperre durch Zahlungspflichtigen
• Komplette Lastschriftsperre
• Widerspruch bereits vor Buchung
Seit April 2016 bietet die HVB zwei Varianten der pain.002 Status Information an. Die pain.002 Standard Variante
entspricht dem bisherigen pain.002 mit Rückweisungen auf Transaktions-Ebene und entspricht der aktuellen
Spezifikation der Deutschen Kreditwirtschaft. Zusätzlich bietet die HVB einen erweiterten pain.002 mit positiven
Status Informationen auf Dateiebene an. In diesem erweiterten pain.002 werden bei Dateirückweisung auch
keine Einzeltransaktionen angegeben. Die führende Status Information befindet sich damit immer auf Ebene der
logischen Datei (Payment Information).
Die erweiterte pain.002 Status Information unterstützt dabei folgende ISO Status Codes.
Status Code
Langtext
Verwendung
ACCP
Accepted Customer Profile
Die eingereichte Datei wurde für die Verarbeitung im Zahlungsverkehrssystem der HVB freigegeben;
Kundendaten und -berechtigungen sind vollständig und korrekt.
ACWC
Accepted with Change
Die eingereichte Datei wurde für die Verarbeitung im Zahlungsverkehrssystem der HVB angepasst und freigegeben.
Aktuell nur bei Anpassung des Ausführungsdatums bei Lastschriften.
ACSC
Accepted Settlement Completed
Die eingereichte Datei wurde verarbeitet und am Ausführungstag gebucht.
RJCT
Rejected
Die eingereichte Datei (dann PmtInf-Ebene) oder einzelne Zahlungen (dann Transaktions-Ebene) wurden
zurückgewiesen.
PART
Partially Processed
Einzelne Zahlungen der eingereichten Datei wurden zurückgewiesen.
Nur auf PmtInf-Ebene.
16
Folgende Beispiele sollen das Vorgehen und die Belegung bei Standard bzw. erweiterten pain.002 bei unterschiedlichen Arten der Rückweisung verdeutlichen:
pain.002 Status Reason Information auf Ebene …
Original Group
Information and Status
Original Payment
Information and Status
Doppelte Message Identification
auf Ebene Group Header
–
• Erweiterter pain.002: RJCT
mit Reasoncode AM05, Doppelverarbeitung
• Standard pain.002: leer
• Erweiterter pain.002: keine Transaktionen
• Standard pain.002: alle Transaktionen werden aufgeführt
und erhalten, Reason Code ED05
Falsche Kontrollsumme
auf Ebene Payment Information
–
• Erweiterter pain.002: RJCT
mit Reasoncode AM10,
falsche Kontrollsumme
• Standard pain.002: leer
• Erweiterter pain.002: keine Transaktionen
• Standard pain.002: alle Transaktionen werden aufgeführt
und erhalten, Reason Code AM10, falsche Kontrollsumme
Anzahl der fehlerhaften
Transaktionen innerhalb Ebene
Payment Information überschreitet
konfigurierten Schwellwert
–
• Erweiterter pain.002: PART
• Standard pain.002: leer
• Erweiterter pain.002/Standard pain.002: Alle
Transaktionen der Ebene Payment Information werden
aufgeführt, die fehlerhaften erhalten den zum jeweiligen
Fehler passenden Reason Code, z. B. AC01, IBAN
fehlerhaft, und die fehlerfreien erhalten ED05, korrekte
Transaktion innerhalb einer Gesamtdateiabweisung
Eine Transaktion enthält eine
fehler­hafte IBAN
–
• Erweiterter pain.002: PART
• Standard pain.002: leer
• Erweiterter pain.002/Standard pain.002: Nur die fehlerhafte Transaktion wird aufgeführt mit Reason Code AC01,
IBAN fehlerhaft
Rückweisungsgrund
Transaction Information and Status
Die folgende Darstellung zeigt dazu exemplarisch die Unterschiede in der Struktur zwischen den beiden Varianten:
Für Verarbeitung akzeptiert
pain.002 UC
GrpStst leer
StsRsnInf leer
PmtInf A
PmtInfSts = ACCP
StsRsnInf leer
Rückweisung Einzeltransaktion
pain.002 UC
GrpStst leer
StsRsnInf leer
Erweiterter pain.002
Standard pain.002
pain.002 UC
GrpStst leer
StsRsnInf leer
Dateirückweisung
PmtInf B
PmtInfSts = PART
StsRsnInf leer
pain.002 UC
GrpStst leer
StsRsnInf leer
Tx B 2
TxSts = RJCT
StsRsnInf = AC01
PmtInf C
PmtInfSts = RJCT
StsRsnInf = AM05
PmtInf B
PmtInfSts leer
StsRsnInf leer
Tx B 2
TxSts = RJCT
StsRsnInf = AC01
pain.002 UC
GrpStst leer
StsRsnInf leer
PmtInf C
PmtInfSts leer
StsRsnInf leer
Tx C 1
TxSts = RJCT
Tx C 2 = ED05
StsRsnInf
TxSts = RJCT
Tx C 3 = ED05
StsRsnInf
TxSts = RJCT
Tx C 4 = ED05
StsRsnInf
TxSts = RJCT
Tx C 5 = ED05
StsRsnInf
TxSts = RJCT
StsRsnInf = ED05
17
Unterscheidung der Rückgabe vor oder nach Buchung?
Relevant für die Entscheidung, ob die Rückgabe vor oder nach Buchung erfolgte, ist immer der InterbankenSettlement-Zeitpunkt. Rückgaben vor diesem Zeitpunkt werden dem Einreicher als „Storno“ gebucht und
Rückgaben danach als Retoure. Bei der Empfängerbank kann es sein, dass auch Rückgaben vor Buchung aus
Transparenzgründen dem Kunden gebucht und gleich wieder zurückgebucht werden. Die Unterscheidung auf
der Einreicherseite ist insbesondere relevant, da für Lastschrift-Folgeeinreichungen die richtige Sequenz gewählt
werden muss.
Wie kann der Einreicher jetzt die richtige R-Nachricht identifizieren? Anhand der Rückgabegründe lässt sich keine
eindeutige Zuordnung treffen, stattdessen müssen die Informationen gemäß folgender Tabelle herangezogen
werden (siehe auch Abschnitt 7.1 auf Seite 30):
Vor Buchung
Nach Buchung
camt.052/053
und MT940
Storno
Mit folgenden GVCs im Kontoauszug:
• 108 SEPA Reject (Soll, B2B),
• 109 SEPA Reject (Soll, CORE/COR1) bzw.
• 159 SEPA Reject (Haben, Überweisung)
Retoure
Mit folgenden GVCs im Kontoauszug:
• 108 SEPA Lastschrift-Rückrechn. (Soll, B2B),
• 109 SEPA Lastschrift-Rückrechn. (Soll, CORE/COR1) bzw.
• 159 SEPA-Rückgabe (Haben, Überweisung)
DTI
Storno
Im Verwendungszweck des C-Satzes mit Bezeichner „SVWZ+“,
Konstante „SEPA-Reject“ und Rückgabegrund als Klartext sowie mit
dem Textschlüssel 09 bzw. 59 bei SEPA DD bzw. SEPA CT R-Nachricht.
Retoure
Im Verwendungszweck des C-Satzes mit Bezeichner “SVWZ+”,
Konstante “RUECKUEBERWEISUNG” bzw. “RUECKLASTSCHRIFT” und
Rückgabegrund als Klartext sowie mit dem Textschlüssel 09 bzw. 59 bei
SEPA DD bzw. SEPA CT R-Nachricht.
pain.002
Reject
In der MessageId steht an 3. Stelle ein „F“.
Retoure optional für Kunden der HVB
In der MessageId steht an 3. Stelle ein „I“.
Option pain.002 auch für Retouren nach Buchung
Es kann sinnvoll sein, den pain.002 auch für Retouren nach Buchung zu nutzen, wenn für den Reklamationsoder Mahnprozess zu den Lastschrift-Retouren ein einheitliches Format genutzt werden soll (der Standard wäre
pain.002 für Rückgaben vor Buchung und camt.054 für Retouren nach Buchung).
Da im pain.002 die Felder für Interbankpreise und Zinskompensationen nicht erlaubt sind, werden diese im
pain.002 nicht explizit ausgewiesen. Der Brutto-Rückgabebetrag (inkl. Retourenpreise und Zinskompensationen)
ist eingestellt in <InstrAmt>.
XML-Version entspricht der Einlieferung, was zu verschiedenen Versionen innerhalb eines XML-Containers
führen kann
Die Version des Rejects ist immer die, die der Kunde eingereicht hat, z. B. SCT pain.001.001.03 → pain.002.001.03
und bei alten Formate pain.001.003.03 → pain.002.003.03. Dies ist insbesondere zu berücksichtigen, wenn bei
Einreichungen verschiedene Versionen verwendet werden oder wenn nach der Umstellung auf die neue Ver­sion
noch alte Transaktionen retourniert werden.
18
Damit nur ein XML-Container – selbst bei unterschiedlichen pain.002-Versionen – abgeholt werden muss, fasst die
HVB in ihren Containern die unterschiedlichen pain-002-Versionen zusammen, siehe folgendes Beispiel:
<?xml version="1.0"?>
<con:conxml xmlns:con="urn:conxml:xsd:container.hvb.002.02" …>
…
<con:MsgPain002>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
…
</Document>
</con:MsgPain002>
…
<con:MsgPain002>
</Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
…
</Document>
</con:MsgPain002>
</con:conxml>
5.3
camt.029 – Status Information zum elektronischer Rückruf
Der camt.029 stellt Ihnen elektronisch die Status Informationen zu Ihrer eingereichten Rückrufanfrage camt.055
zur Verfügung. Das Datenformat des camt.029 basiert auf dem internationalen XML-Standard ISO 20022.
Der camt.029 ist eine ISO20022 Nachricht aus dem Bereich der Nachforschung „Exception&Investigation“. Als
Antwort auf einen elektronisch eingereichten Rückruf camt.055 ist sie gekennzeichnet durch eine eindeutige Id
des Rückrufs und jeweils einen Ersteller und Empfänger der Nachforschung. Zu einer Rückrufanfrage können dabei
mehrere camt.029 bereitgestellt werden, die neben einen endgültigen Status auch Zwischenstände reporten
können.
Auftraggeber
Auftraggeber initiiert
Auftraggeber-Bank antwortet
Auftraggeber-Bank leitet weiter
Empfänger-Bank antwortet
Empfänger-Bank antwortet nicht
Bank des Auftraggebers
Bank des Empfängers
Empfänger
camt.055
camt.029 negativ
camt.029 positiv
Interbank camt.056
Interbank camt.029
Interbank pacs.004
nicht regelkonform
19
Status Code
Langtext
Verwendung
CNCL
CancelledAsPerRequest
Rückruf erfolgreich
RJCR
RejectedCancellationRequest
Ablehnung des Rückrufes
PDCR
PendingCancellationRequest
Nur bei SCT. Rückrufanfrage wurde an den ZDL des Empfängers weitergeleitet, Ergebnis noch offen
UWFW
UnableToApplyWillFollow
Auf Originaltransaktion wird noch gewartet. Falls Frist abgelaufen ist, wird in einer weiteren camt.029 der Fall per
RJCR abgeschlossen.
Im Fall der Ablehnung einer Rückrufanfrage wird ein entsprechender Reason Code zur Verfügung gestellt. Dabei
sind einige Codes in ihrer Verwendung auf ein bestimmtes Level oder Zahlungsverkehrsinstrument beschränkt.
Reason
Langtext
Ebene
Verwendung
ARDT
AlreadyReturned
Datei/Transaktion
Sammler ist bereits storniert
NOOR
NoOriginalTransactionReceived
Datei/Transaktion
Kein entsprechender Sammler gefunden
CUST
CustomerDecision
Transaktion
Nur SCT: Geldrückgabe wurde vom Zahlungsempfänger abgelehnt
AC04
ClosedAccountNumber
Transaktion
Betreffendes Zielkonto aufgelöst
AGNT
AgentDecision
Transaktion
Nur SCT: Rückrufanforderung nicht beantwortet vom Zahlungs-dienstleister des Zahlungsempfängers
AM04
InsufficientFunds
Transaktion
Nur SCT: Deckung ist für eine Rückgabe nicht ausreichend
LEGL
LegalDecision
Transaktion
Aus regulatorischen Gründen kein Rückruf möglich
NOAS
NoAnswerFromCustomer
Transaktion
Nur SCT: Keine Antwort vom Zahlungsempfänger
Im Fall einer notwendigen Weiterleitung der Rückrufanfrage an den ZDL des Empfängers wird der entsprechende
Reason Code aus der Antwort weitergegeben.
5.4
MT940, MT942 – Kontoinformation
Die Kontoinformationen im internationalen SWIFT-Format sind ideal für Organisationen, deren Muttergesellschaft
sich in einem anderen Land befindet. Im Zusammenhang mit SEPA birgt das SWIFT-MT-Format allerdings einige
Nachteile:
• Hoher Implementierungsaufwand auf Seiten des Firmenkunden, verursacht durch viele unterschiedliche länderund bankspezifische Varianten wegen eingeschränkter Standardisierung.
• Beeinträchtige Darstellung der Transaktionsdaten, da der SWIFT-MT-Zeichensatz deutlich weniger Zeichen
darstellen kann als der in der SEPA genutzte UTF-8-Zeichensatz
• Erschwerte automatische Verarbeitung, weil bei SEPA-Transaktionen die Detailinformationen zu Lastschriften
sowie zu Auftraggeber und Empfänger aus Platzgründen nur unvollständig transportiert werden können.
Daher wird die Nutzung der Formate camt.05x empfohlen, mit denen eine durchgängige Verarbeitung mit einem
hohen Automatisierungsgrad ohne Informationsverlust ermöglicht wird.
Unter Berücksichtigung der oben aufgeführten Nachteile stellt sich das Reporting per MT94x im SEPA wie folgt
dar: MT940-Kontoauszugsinformationen enthalten Informationen über alle Buchungen auf Ihrem Konto und
MT942-Elektronische Avise enthalten alle Informationen zu den Buchungen, die Ihrem Konto untertägig belastet
oder gutgeschrieben wurden.
20
Zusätzlich zu den obligatorischen Feldern enthält der MT940 und MT942 das optionale Feld 86 mit Informationen
für den Kontoinhaber. Die HVB nutzt eine Substruktur für die Bereitstellung zusätzlicher Detailinformationen für
SEPA in strukturierter Form, wie in Abschnitt 7.1 auf Seite 30 dar­gestellt.
Anfang Buchungstag
MT940
:20:110727
:25:70020270/4421736
:28C:28/2
:60M:D110727EUR16358,43
:61:1107270727D13,06NDDTFABCD
EF1234567890//0934490026000015
:86:105?00SEPA direct debit
basic?100050?20EREF+ETE TestA 1.03
Standar?21dpreis Core 6?22MREF+M2345
67?23CRED+DE98ZZZ09999999999?24S
VWZ+RI TestB 1.03 Standard?25preis Core
6?26ABWA+Test Joshua?30HYVEDEMM480?
31DE94783200760001407325?32EndToEnd
Test Heute?34990
:61:1107270727D13,07NDDTCUSTR
EF123456789//0934490026000014
:86:105?00SEPA direct debit
basic?100050?20EREF+ETE TestA 1.03
Standar?21dpreis Core 7?22MREF+M2345
67?23CRED+DE98ZZZ09999999999?24S
VWZ+RI TestA 1.03 Standard?25preis Core
7?26ABWA+Test Joshua?30HYVEDEMM480?3
1DE94783200760001407325?32Peter Smith,
Test User?34990
:62F:D110727EUR16384,56
Ende Buchungstag
Buchungstag
MT942
Anfang nächster Tag
MT940
MT942
:20:110728
:25:70020270/4421736
:28C:90/2
:34F:EURD0, :20:110728
:25:70020270/4421736
:34F:EURC24200,
:28C:90/2
:13D:1006250720+0100
:34F:EURD0,
:61:1006250625C24200,NMSCNONR
:34F:EURC24200,
EF//0960299172000005
:13D:1006250720+0100
:86:835?00AVAL?109999?20Import
:20:110728
:61:1006250625C24200,NMSCNONR
LC?21Erledigung?22UnsereRef
411940000510
:25:70020270/4421736
EF//0960299172000005
?23Ihre Ref. TEX
2984741
:28C:90/2
:90D:0EUR0, :86:835?00AVAL?109999?20Import
:34F:EURD0,
LC?21Erledigung?22UnsereRef
411940000510 :20:110728
:90C:1EUR24200,
?23Ihre Ref. TEX 2984741 :34F:EURC24200,
:25:70020270/4421736
:13D:1006250720+0100
:90D:0EUR0,
:28C:90/2
:61:1006250625C24200,NMSCNONR
:90C:1EUR24200,
:34F:EURD0,
EF//0960299172000005:34F:EURC24200,
:86:835?00AVAL?109999?20Import
:13D:1006250720+0100
LC?21Erledigung?22UnsereRef 411940000510
:61:1006250625C24200,NMSCNONR
?23Ihre Ref. TEX 2984741
EF//0960299172000005
:90D:0EUR0,
:86:835?00AVAL?109999?20Import
:90C:1EUR24200,
LC?21Erledigung?22UnsereRef 411940000510
?23Ihre Ref. TEX 2984741
:90D:0EUR0,
:90C:1EUR24200,
MT942
MT942
:20:110727
:25:70020270/4421736
:28C:28/2
:60M:D110727EUR16358,43
:61:1107270727D13,06NDDTFABCD
EF1234567890//0934490026000015
:86:105?00SEPA direct debit
basic?100050?20EREF+ETE TestA 1.03
Standar?21dpreis Core 6?22MREF+M2345
67?23CRED+DE98ZZZ09999999999?24S
VWZ+RI TestB 1.03 Standard?25preis Core
6?26ABWA+Test Joshua?30HYVEDEMM480?
31DE94783200760001407325?32EndToEnd
Test Heute?34990
:61:1107270727D13,07NDDTCUSTR
EF123456789//0934490026000014
:86:105?00SEPA direct debit
basic?100050?20EREF+ETE TestA 1.03
Standar?21dpreis Core 7?22MREF+M2345
67?23CRED+DE98ZZZ09999999999?24S
VWZ+RI TestA 1.03 Standard?25preis Core
7?26ABWA+Test Joshua?30HYVEDEMM480?3
1DE94783200760001407325?32Peter Smith,
Test User?34990
:62F:D110727EUR16384,56
Kunde
5.5
DTI – Datenträgerinformation
Das deutsche DTI-Format (Datenträgerinformation) für Kontoinformationen war für den deutschen DTA-basierten
Inlandszahlungsverkehr optimal ausgerichtet und ist daher weit verbreitet. Das DTI-Format kann zwar auch in
SEPA weiter genutzt werden, allerdings müssen wie beim MT94x-Format teilweise erhebliche Einschränkungen in
Kauf genommen werden:
• Unvollständige Anzeige der Kontoverbindung, da IBAN und BIC der SEPA-Transaktionen nicht 1:1 in die
DTI-Felder für Kontonummer und Bankleitzahl übertragen werden können
• Beeinträchtige Darstellung der Transaktionsdaten, da der DTA-Zeichensatz deutlich weniger Zeichen darstellen
kann als im SEPA genutzte UTF-8-Zeichensatz
• Erschwerte automatische Verarbeitung, weil bei SEPA-Transaktionen die Detailinformationen zu Lastschriften
sowie zu Auftraggeber und Empfänger aus Platzgründen nur unvollständig transportiert werden können.
Daher gilt wie beim MT94x-Format auch hier die Empfehlung, die Formate camt.05x zu nutzen, damit eine
automatische Verarbeitung ohne Informationsverlust ermöglicht wird.
Ist dennoch der Entschluss zu Gunsten der Beibehaltung von DTI gefallen, gilt für SEPA Folgendes: Alle Buchungsinformationen zu SEPA-Transaktionen (Sammelbuchung von Gutschriften, Lastschriften oder auf Purpose-Codes
basierende Sammelbuchungen sowie Rückgaben von Gutschriften und Lastschriften vor und nach Buchung)
können elektronisch in einer SEPA-DTI-Datei zur Verfügung gestellt werden. Diese Daten können bei der HVB bis
zu 29-mal täglich (halbstündlich) abgerufen werden.
Hinweis:
Im DFÜ-Abkommen der Deutschen Kreditwirtschaft ist vorgesehen, ab November 2017 DTI als Service zugunsten
camt.054 einzustellen.
21
6 Die Report-Formate in der Praxis
In dem folgenden Beispiel sollen die oben aufgeführten Möglichkeiten der Kontoauszüge und Statusreports
aufgezeigt werden. Dabei wird von einer vollständigen Nutzung der ISO 20022 XML-Formate ausgegangen,
d. h. der Kunde hat SEPA-Transaktionen als ISO 20022 XML pain.001 oder pain.008 eingereicht und erhält
Kontoinformationen camt.052/053/054 sowie Statusreports pain.002 ebenfalls als ISO 20022 XML. So wird
der Kreislauf ohne Formatbruch geschlossen, alle SEPA-Informationen werden vollständig durch die gesamte
Finanzkette hindurchtransportiert und der Abstimmprozess optimal vorbereitet.
Kreislauf SEPA-Transaktionen
SEPA-Überweisung (pain.001)
SEPA-Lastschrift (pain.008)
XML
XML
HypoVereinsbank
Kunde
XML
Clearing
XML
Statusreport (pain.002) /
Kontoinformation (camt.052/053/054)
In den folgenden Abschnitten wird eine Einreichung und Verarbeitung von Aufträgen eines Firmenkunden
beispielhaft dargestellt.
Die Stammdaten des Firmenkunden sind bei der HVB für die Auftragsverarbeitung wie folgt konfiguriert:
• Eingereichte Dateien pain.001 und pain.008 werden in Summe gebucht.
• Rückweisungen werden per pain.002 quittiert.
• Rückweisungen werden im Bruttoprinzip als Sammler per camt.053 gebucht, d. h. eine Summenbuchung je
Datei und eine Gegenbuchung in Summe je zurückgewiesene Sätze je Datei.
• Zusätzliche detaillierte Informationen zu den Sammelbuchungen werden per camt.054 mitgeteilt
(Auflösung von Sammlern).
22
Der Firmenkunde als Auftragseinreicher
Am Einreichungstag
Der Firmenkunde reicht am Einreichungstag zwei Auftragsdateien bei der Bank ein, wobei die zweite Einreichung
aus zwei logischen Dateien besteht (Payment Information PI-B1 und PI-B2).
Eingereichte Datei A
Group Header GH-A
+ Payment Information PI-A1
++ Transaktionen:
+++ #1
+++ #2
Eingereichte Datei B
+++ #3
Group Header GH-B
+++ #4
+ Payment Information PI-B1
…
++ Transaktionen:
Firmenkunde
+++ #1
+++ #2
+++ #3
+++ #4
…
+ Payment Information PI-B2
++ Transaktionen:
+++ #1
+++ #2
+++ #3
+++ #4
…
Bank
Bei der Einreichung über EBICS erfolgt im Rahmen des EBICS Protokolls ein technisches OK mit dem
HAC Protokoll. Neben dem HAC Protokoll stellt die HVB einen erweiterten pain.002 als Status Information zur
Verfügung.
Die erweiterte pain.002 Status Information bietet optional zwei positive Statuscodes zur Bestätigung der
fachlichen Prüfung an. Damit kann auch eine (optionale) automatische Anpassung des Ausführungsdatums bei
Lastschriften an den Kunden reportet werden. In obigen Beispiel wird das für die logische Datei PI-B1 dargestellt.
pain.002 zur logischen Datei PI-A1
Original Group Header GH-A
Original Payment Information PI-A1
<PmtInfSts> = ACCP
…
pain.002 zur logischen Datei PI-B1
Firmenkunde
Original Group Header GH-B
Original Payment Information PI-B1
<PmtInfSts> = ACWC
<RsnCd> = DT06
…
pain.002 zur logischen Datei PI-B2
Original Group Header GH-B
Original Payment Information PI-B2
<PmtInfSts> = ACCP
…
Bank
23
Unter bestimmten Umständen kann die komplette Datei am Einreichungstag durch die Bank abgelehnt werden.
In der Standard-Variante werden alle Transaktionen geliefert. In der erweiterten Variante wird in diesem Fall
die Ablehnung der Datei nur im Header angegeben. Damit kann der Firmenkunde allein durch Analyse eines
Fehlercodes die Situation erkennen und in seinem Systemen geeignete Prozesse anstossen. Die Datei wird bei der
kompletten Ablehnung auch nicht verbucht. Weitere Beispiele zu dieser Fehlerbehandlung sind oben in Abschnitt
5.2 auf Seite 14 beschrieben.
pain.002 zur logischen Datei PI-A1
Original Group Header GH-A
Original Payment Information PI-A1
<PmtInfSts> = RJCT
<RsnCd> = AM05
…
pain.002 zur logischen Datei PI-B1
Firmenkunde
Original Group Header GH-B
Original Payment Information PI-B1
<PmtInfSts> = RJCT
<RsnCd> = MS03
…
pain.002 zur logischen Datei PI-B2
Original Group Header GH-B
Original Payment Information PI-B2
<PmtInfSts> = PART
<TxSts> = RJCT
++ #1 → ED05
++ #2 → AC01
++ #3 → FF01
++ #4 → ED05
…
Bank
Der Fall einer kompletten Dateiablehnung wird im Folgenden nicht weiter betrachtet, sondern statt­dessen nur die
Ablehnung einzelner Transaktionen.
pain.002 zur logischen Datei PI-A1
Firmenkunde
Original Group Header GH-A
Original Payment Information PI-A1
+ Transaktionen:
++ #1 → ED05
pain.002 zur logischen Datei PI-B1
++ #2 → ED05
++ #3 → AC01
Original Group Header GH-B
++ #4 → AM05
Original Payment Information PI-B1
…
+ Transaktionen:
++ #1 → RC01
pain.002 zur logischen Datei PI-B2
++ #2 → MS03
++ #3 → ED05
Original Group Header GH-B
++ #4 → ED05
Original Payment Information PI-B2
…
+ Transaktionen:
++ #1 → ED05
++ #2 → AC01
++ #3 → FF01
++ #4 → ED05
…
Bank
24
Falls die Auftragsdateien einzelne fehlerhafte Transaktionen enthalten, werden diese direkt am Einreichungstag
vor der Buchung per pain.002 je logische Datei durch die Bank negativ quittiert, also vor dem Ausführungsdatum
bei SCT bzw. vor dem Fälligkeitsdatum bei SDD. Die abgewiesenen Transaktionen werden mit einem passenden
Reason Code wie z. B. AC01 für „Kontonummer fehlerhaft“ versehen. Die fehlerfreien Transaktionen werden von
der Bank weiterverarbeitet.
pain.002 zur logischen Datei PI-A1
Firmenkunde
Original Group Header GH-A
Original Payment Information PI-A1
+ Transaktionen:
++ #3 → AC01
pain.002 zur logischen Datei PI-B1
++ #4 → AM05
Original Group Header GH-B
Original Payment Information PI-B1
+ Transaktionen:
++ #1 → RC01
pain.002 zur logischen Datei PI-B2
++ #2 → MS03
Original Group Header GH-B
Original Payment Information PI-B2
+ Transaktionen:
++ #2 → AC01
++ #3 → FF01
Bank
Nach dem Einreichungstag, aber vor dem Buchungstag, also vor dem Fälligkeitsdatum bei SDD
Im weiteren Verlauf wird davon ausgegangen, dass die Auftragsdateien angenommen und nur einzelne
Transaktionen der Einreichung abgelehnt wurden. Bei Lastschrifteinreichungen kann es nun wegen der Vorlaufzeit
von bis zu 14 Tagen vorkommen, dass Lastschriften nach dem Einreichungstag, aber vor dem Buchungstag, also
der Fälligkeit der Lastschrift, abgelehnt werden, z. B. weil der Zahler der Lastschrift vor Fälligkeit widerspricht. Der
Firmenkunde wird hierüber per pain.002 mit Listung der betroffenen Transaktion und zugehörigem Reason Code
SL01 „Spezifische Dienstleistung, Positiv/Negativ Liste des Zahlers“ informiert.
pain.002 zur logischen Datei PI-A1
Firmenkunde
Original Group Header GH-A
Original Payment Information PI-A1
+ Transaktionen:
++ #1 -> SL01
Bank
Bank des
Zahlers
Zahler
25
Am Buchungstag, also Ausführungsdatum bei SCT bzw. Fälligkeitsdatum bei SDD
Am Buchungstag erfolgt die Buchung der Dateisummen per Kontoauszug camt.053 sowie die Gegenbuchung der
zurückgewiesenen Transaktionen in Summe je eingereichter Datei.
camt.053 am Buchungstag
Firmenkunde
…
Entry für Einreichung PI-A1 als Summe
#1+#2+#3+…
Entry für Rückweisung aus PI-A1 als Summe
#1+#3+#4
Entry für Einreichung PI-B1 als Summe
#1+#2+#3+…
Entry für Rückweisung aus PI-B1 als Summe
#1+#2
Entry für Einreichung PI-B2 als Summe
#1+#2+#3+…
Entry für Rückweisung aus PI-B2 als Summe
#2+#3
…
Bank
Des Weiteren werden die Details der abgelehnten Transaktionen per Sammelbuchungsinformation camt.054 zur
Verfügung gestellt.
camt.054 zu Rückweisungen
Firmenkunde
Rückweisungen aus A
Entry für #1 (SL01) aus PI-A1
Entry für #3 (AC01) aus PI-A1
Entry für #4 (AM05) aus PI-A1
Rückweisungen aus B
Entry für #1 (RC01) aus PI-B1
Entry für #2 (MS03) aus PI-B1
Entry für #2 (AC01) aus PI-B2
Entry für #3 (FF01) aus PI-B2
Bank
Generell werden alle Transaktionen in einem camt.054 gebündelt, allerdings werden unter folgenden Um­ständen
mehrere camt.054 erstellt:
• Für eingereichte SCT, SDD CORE, SDD COR1, SDD B2B und SCC werden jeweils separate camt.054 erstellt.
• Falls in den Stammdaten mehrere Ausgangsläufe konfiguriert sind, kann dies zu mehreren korrespondierenden
camt.054 führen.
• Rückweisungen vor Settlement und Rückgaben nach Settlement werden in separaten camt.054 bereitgestellt.
26
Nach dem Buchungstag
Rückweisungen nach dem Buchungstag der eingereichten Dateien werden im Kontoauszug camt.053 sowie
als Sammelbuchungsinformation camt.054 am Buchungstag der jeweiligen Rückweisung vermerkt, z. B. wenn
der Zahler nach Belastung einer Lastschrift widerspricht, wird dies unter Angabe des Reason Code MD06
„Lastschriftwiderspruch durch den Zahlungspflichtigen“ im camt.053 und camt.054 aufgeführt.
camt.053 am Buchungstag + X
Entry für Eingänge als Summe, u. a. mit EinzelpostenRETURN #2 (MD06) aus PI-A1
…
camt.053 am Buchungstag + X
Firmenkunde
Entry X
Entry Y
…
Entry für RETURN #2 (MD06) aus PI-A1
…
Entry Z
…
Bank
Der elektronische Rückruf der Auftragseinreichung durch den Firmenkunden
Ein elektronischer Rückruf kann bis zu 10 Tage nach Einreichung initiiert werden. Der camt.055 als Format für den
Rückruf enthält dabei die relevanten Informationen der ursprünglichen Einreichung und einen Indikator, ob die
logische Datei oder einzelne Transaktionen zurückgerufen werden.
Vor dem Interbanken Clearing kann der Rückruf von der Bank bearbeitet werden. Bei einer Lastschrift kann der
Rückruf auch nach dem Clearing von der Bank beantwortet werden. Bei einer Überweisung muss eine Rückruf­
anfrage pro Transaktion an die empfangende Bank gesendet werden. Ein camt.029 auf Basis einer SCT-Rückrufanfrage nach Buchung vom Begünstigten bzw. der Bank des Zahlungsempfängers erfolgt im Rahmen der in den
SEPA Rulebooks vorgesehenen Prozesse.
Mit der Status Information camt.029 erhält der Kunde eine positive oder negative Rückmeldung zu seinem
Rückruf.
27
Rückruf von Kunden – camt.055
Überweisung SCT
-10
Targettage
Einreichung
Freigabe
Soll­
buchung
pain.001
1a
Clearing
Haben­
buchung
+10
Targettage
pacs.008
2a
3a
4a
camt.055 kann vor
Zahlung an Bank
geschickt werden
Interbank:
camt.056/camt.029
bzw. pacs.004-FOCR
5a
6a
Zustimmung
Begünstiger
erforderlich
Lastschrift SDD
-10
Targettage
1b
2b
camt.055 kann vor
Zahlung an Bank
geschickt werden
Einreichung
Freigabe
Clearing
Haben­und Soll­
buchung
pain.008pacs.003
3b
4b
Interbank: camt.056
+5
Targettage
5b
Korrekturbuchung
pacs.007
Reversal
6b
28
Für die Verarbeitung und den Nachfolgeprozess eines camt.055 ist der Zeitpunkt der Einreichung entscheidend:
Prozess­
zeitpunkt
Status
Aktion
Kunden camt.029
1a/b 6a/b
Die Bank erhält eine Rückrufanfrage (camt.055),
aber findet keine dazugehörige Überweisung
(pain.001) bzw. Lastschrift (pain.008) innerhalb
des definierten Zeitraumes.
Der camt.055 wird bis zu 10 Targettage vorgehalten.
Wenn bis dahin die dazugehörige Überweisung (pain.001)
bzw. Lastschrift (pain.008) nicht eintrifft, wird der
camt.055 deaktiviert und der Kunde darüber informiert.
Der Kunde erhält den Zwischenstatus
UWFW.
2a/b
Die Bank erhält einen camt.055 vor der dazugehörigen pain.001/pain.008 (die Rückrufanfrage
kommt vor der eigentlichen Zahlungsanweisung).
Die dazugehörige pain.001 bzw. pain.008 wird innerhalb des definierten Zeitraumes nachgereicht.
Sobald die pain.001 oder pain.008 eintrifft, wird die
betroffene Datei bzw. die entsprechende Transaktion
zurückgewiesen (rejected).
Vor Eintreffen der pain.001/008 erhält
der Kunde den Zwischenstatus UWFW
Nach dem Eintreffen der referenzierten
Datei folgt der positive Status CNCL.
3a/b
Die Bank kann den erhaltenen camt.055 auf
eine pain.001/pain.008 anhand der Referenzen
eindeutig zuordnen. Die Zahlung wurde im Interbankenclearing aber noch nicht an die Fremdbank
weitergeleitet.
Die Datei bzw. Transaktion wird zurückgewiesen (rejected).
Der Kunde erhält den positiven Status
CNCL.
4a
Die Überweisung wurde bereits ins Interbankenclearing weitergeleitet.
Die Bank schickt eine Anfrage zur Rücküberweisung an die
Empfängerbank. Je nach Entscheidung des Begüngstigten
bzw. Begünstigtenbank erfolgt eine Überweisungsrückgabe (pacs.004) oder eine Negativ-Nachricht (camt.029).
Je nach Rückmeldung erfolgt ein positiver oder negativer Status CNCL oder
RJCR mit dem Grund aus der NegativNachricht der Begünstigtenbank.
4b
Die Bank hat die zugeordnete pain.001/pain.008
bereits ins Interbankenclearing weitergeleitet aber
beim Empfänger wurde noch keine finale Buchung
ausgelöst
Die Bank schickt an das Clearinghaus bzw an die Fremdbank einen Request-for-Cancellation (camt.056). Die
Zahlung wird an den Auftrag­geber wieder zurückgebucht.
Bei Lastschrift erhält der Kunde immer
positiven Status CNCL.
5a
Die Überweisung wurde dem Begünstigten bereits
gut­geschrieben. Die Zustimmung des Begünstigten
ist erforderlich.
Die Bank schickt eine Anfrage zur Rücküberweisung
camt.056 an die Empfängerbank. Je nach Entscheidung
des Begünstigten erfolgt eine Überweisungsrückgabe
(pacs.004) oder eine Negativ-Nachricht (camt.029).
Je nach Rückmeldung erfolgt ein positiver oder negativer Status CNCL oder
RJCR mit dem Grund aus der NegativNachricht der Begünstigtenbank.
5b
Die Lastschrift wurde bereits dem Zahlungs­
pflichtigen belastet.
Die Bank belastet das Zahlungsempfängerkonto und
schickt eine Korrekturgutschrift/Reversal an die Zahlungspflichtigenbank. Diese veranlasst eine Wiedergutschrift.
Bei Lastschrift erhält der Kunde immer
positiven Status CNCL.
6a/b
Die Bank erhält den camt.055 nach dem Cutoff für
eine automatisierte standardisierte Rückrufverarbeitung. Im gültigen Zeitraum wird keine zuordenbare pain.001/pain.008 gefunden.
Die Bank weist den camt.055 ab. Der Rückruf muss durch
den Kunden auf alternativen Wegen versucht werden
• Überweisung (pain.001):
Reklamation beauftragen bzw.
Rücksprache mit Begünstigten
• Lastschrift (pain.008):
mittels Überweisung (pain.001)
Nach der Wartefrist erfolgt eine Rückmeldung RJCR mit Grund NOOR.
Der Kunde erhält den negativen Status
RJCR mit dem Grund NOOR.
29
Der Firmenkunde als Empfänger
Auf der Empfängerseite des Firmenkunden gilt das Zusammenspiel zwischen Sammelbuchung im Kontoauszug
camt.053 und Sammelbuchungsinformation camt.054 analog, wobei sich dies deutlich einfacher darstellen lässt,
da die Berücksichtigung des pain.002 entfällt:
camt.053 (Kontoauszug)
<Umsatz 1>
<Sammelbuchung>
<Umsatz 2>
<Umsatz …>
Auftraggeber
<?XML>
Auftraggeber
Bank
Auftraggeber
Emp­
fänger
camt.054 (Sammler-Details)
<Sammler-Umsatz 1>
<Sammler-Umsatz 2>
<Sammler-Umsatz …>
30
7 Anhang
7.1
Technische Formatbeschreibungen
7.1.1 camt.052/053/054 – Kontoinformation
Die HVB stellt Kontoinformationen im internationalen ISO 20022-Standard zur Verfügung, der auf der Syntax von
XML (EXtensible Markup Language) basiert. Das XML-Format ist ein weltweit gültiger Standard zur Abbildung von
Daten in einer hierarchischen Struktur. Als Zeichensatz wird die international standardisierte Kodierung UTF-8
verwendet, ein umfangreicher Zeichensatz mit vielen länderspezifischen Umlauten, welcher auch im XML-Header
vermerkt ist: <?xml version="1.0" encoding="UTF-8"?>.
Die Deutsche Kreditwirtschaft (DK) gibt den deutschen Kreditinstituten darüber hinaus verbindliche Regularien
hinsichtlich von Feldbelegungen vor, die vollumfänglich kompatibel zum ISO 20022 Standard sind. Die von der
HVB bereitgestellten camt.052, camt.053 und camt.054 Nachrichten folgen diesen in der Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und Kreditinstitut gemäß DFÜ-Abkommen
„Spezifikation der Datenformate“ hinterlegten Regularien der DK.
Darüber hinaus erfüllen die Nachrichten der HVB die Vorgaben der CGI-MP (Common Global Implementation
Market Practice) Initiative, die sich zum Ziel gesetzt hat, einen weltweit einheitlichen Implementierungsstandard
für ISO 20022 Nachrichten zu definieren.
Die HVB erstellt aktuell die Kontoinformationsformate camt.052, camt.053 und camt.054 in den folgenden
Versionen:
ISO 20022 Nachricht
Für
Version
Ersetzt
camt.052
Untertägige elektronische Avise
camt.052.001.02
MT942
camt.053
Tagesauszug
camt.053.001.02
MT940
camt.054
Sammelbuchungsinformationen
camt.054.001.02
DTI
Die umfangreichen technischen Formate sind in unserer Broschüre „Reporting, camt-Formate“ beschrieben,
welche Ihnen auf Anfrage Ihr Cash Management & eBanking-Spezialist gerne zur Verfügung stellt.
7.1.2 pain.002 – Status Information
Mit der pain.002 Status Information im ISO 20022 XML-Format erhalten Sie eine genaue Rückmeldung zu den
eingereichten Dateien und Transaktionen, bei fehlerhaften Einreichungen inklusive Art des Fehlers.
Auch im pain.002 wird als Zeichensatz die international standardisierte Kodierung UTF-8 verwendet, ein
umfangreicher Zeichensatz mit vielen länderspezifischen Umlauten, welcher auch im XML-Header vermerkt ist:
<?xml version="1.0" encoding="UTF-8"?>.
31
Da der pain.002 so strukturiert ist, dass alle Daten der ursprünglichen Original-Einreichung vorhanden sind, wird
die eindeutige Zuordnung zur Original-Transaktion anhand der ursprünglichen Referenznummern erreicht.
Group Header (1..1)
pain.002
Original Group Information and Status (1..1)
Original Payment Information and Status (1..n)
Transaction Information and Status (1..n)
Original Transaction Reference (1..1)
In der folgenden Tabelle werden die wichtigen fachlichen XML-Felder für den pain.002 für SEPA Credit Transfer
(SCT) und SEPA Direct Debit (SDD) aufgeführt.
Mit der Einführung des erweiterten pain.002 Status Information („HVB Erweitert“) zusätzlich zum Standard
pain.002 nach DK Empfehlungen („HVB Standard“) ergeben sich auch Unterschiede in der Belegung. Diese
sind detailliert in der letzten Spalte beschrieben. Zusätzlich folgt im Anschluß eine Übersicht der wichtigsten
Unterschiede.
Feldnamen
GrpHdr
Beschreibung pain.002.001.03
Befüllung HVB Standard/HVB Erweitert
GroupHeader
Absenderdaten
1 × pro pain.002
MsgId
(MessageId)
Bankreferenznummer pro Datei
Pflichtfeld
Max. 35 Zeichen
HVB:
3. Stelle „F“ = Rückgabe vor
Buchung
3. Stelle „I“ = Rückgabe nach
Buchung
CreDtTm
(CreationDateTime)
Datum/Zeit der Dateierstellung
Pflichtfeld
ISO-Date
SCT: DbtrAgt
SDD: CdtrAgt
(ServicingDebtor/CreditorAgent)
BIC des kontoführenden Kreditinstituts
Pflichtfeld
8 bzw. 11 Stellen
32
Feldnamen
OrgnlGrp
InfAndSts
OrgnlPmt
InfAndSts
Beschreibung pain.002.001.03
Befüllung HVB Standard/HVB Erweitert
OriginalGroupInformation­
AndStatus
Originaldaten und Status der ursprünglichen
physischen Datei (Ebene Group Header)
1 × pro pain.002
OrgnlMsgId
(OriginalMessageId)
Ursprüngliche Referenznummer der Kundeneinreichung
Originaldaten
OrgnlMsgNmId
(OriginalMessageNameId)
Ursprüngliche XML-Dateityp
Originaldaten
OrgnlNbOfTxs
(OriginalNumberOfTransactions)
Ursprüngliche Anzahl aller Einzeltransaktionen
Originaldaten
OrgnlCtrlSum
(OriginalControlSum)
Ursprüngliche Kontrollsumme in Euro der
Einreichung
Originaldaten
GrpSts
(GroupStatus)
Status auf Dateiebene
Ein Status muss entweder auf
Ebene GrpHdr,
OrgnlPmtInfAndSts oder
TxInfAndSts angegeben sein
• HVB Standard: Status nur auf
Transaktions-Ebene. Bei Dateiablehnung werden alle Transaktionen zurückgeliefert.
• HVB Erweitert: Führender Status
immer auf logischer Dateiebene
PmtInf
StsRsnInf-Orgtr
(StatusReasonInfoOriginator)
Initiator der Rückgabe
Nur zusammen mit GrpSts.
Optional, entweder Nm mit
Namen oder Id-OrgId-BICOrBEI
mit BIC angeben
Name (max. 70 Zeichen) für
Kunden-initiierte oder BIC für Bankinitiierte Rückgabe.
StsRsnInf-Rsn-Cd
(StatusReasonInfo­Code)
Rückgabegrund
Rückgabegründe gemäß separatem Dokument zu Geschäftsvorfall- und Rückgabecodes*
OriginalPayment
­Information­AndStatus
Originaldaten und Status der ursprünglichen logischen Datei(en) (Ebene PaymentInformation)
Anzahl je nach Originaldaten
OrgnlPmtInfId
(OriginalPaymentInfoId)
Ursprüngliche Referenz der Einreichung
Originaldaten
OrgnlNbOfTxs
(OriginalNumberOfTransactions)
Ursprüngliche Anzahl aller Einzeltransaktionen
Originaldaten
OrgnlCtrlSum
(OriginalControlSum)
Ursprüngliche Kontrollsumme in Euro der
logischen Datei
Originaldaten
PmtInfSts
(PaymentInfoStatus)
Status auf logischer Dateiebene
Ein Status muss entweder auf
Ebene GrpHdr,
OrgnlPmtInfAndSts oder
TxInfAndSts angegeben sein
• HVB Standard: Status nur auf
Transaktions-Ebene. Bei Dateiablehnung werden alle Transaktionen zurückgeliefert.
• HVB Erweitert: Führender Status
immer auf logischer Dateiebene
(PmtInfSts). „ACCP“, „ACWC“,
„ACSC“, „PART“, „RJCT“. Bei
Rückweisung von Einzeltransaktionen hier „PART“ und „RJCT“
im TxSts.
StsRsnInf-Orgtr
(StatusReasonInfoOriginator)
Initiator der Rückgabe
Nur zusammen mit PmtInfSts.
Optional, entweder Nm mit
Namen oder Id-OrgId-BICOrBEI
mit BIC angeben
Name (max. 70 Zeichen) für
Kunden-initiierte oder BIC für Bankinitiierte Rückgabe.
StsRsnInf-Rsn-Cd
(StatusReasonInfoCode)
Rückgabegrund
Rückgabegründe gemäß separatem Dokument zu Geschäftsvorfall- und Rückgabecodes*
SCT: „pain.001“
SDD: „pain.008“
Abschnitt optional wenn GrpSts
gefüllt
33
Feldnamen
TxInfAndSts
OrgnlTxRef
Beschreibung pain.002.001.03
Befüllung HVB Standard/HVB Erweitert
TransactionInformation
­AndStatus
Referenznummern und Status der
ursprünglichen Transaktion(en)
(Ebene TransactionInformation)
Anzahl je nach Originaldaten
Abschnitt optional wenn
PmtInfSts gefüllt
HVB Standard: immer gefüllt
HVB Erweitert: Nur bei PmtInfSts
„PART“
StsId
(StatusId)
Bank-Referenz der Rückgabe
Optional
Max. 35 Zeichen
OrgnlInstrId
(OriginalInstructionId)
Ursprüngliche technische Referenz zwischen
Einreicher und Bank
Originaldaten
OrgnlEndToEndId
(OriginalEndToEndId)
Ursprüngliche Kunden-Referenz
Originaldaten
TxSts
(TransactionStatus)
Status auf Transaktions-Ebene
Ein Status muss entweder
auf Ebene GrpHdr,
OrgnlPmtInfAndSts oder
TxInfAndSts angegeben sein
• HVB Standard: „RJCT“ (Reject)
Status nur auf TransaktionsEbene. Bei Dateiablehnung
werden alle Transaktionen
zurückgeliefert.
• HVB Erweitert: Nur bei Ablehnung
von Einzeltransaktionen.
Ausnahme: Dateiablehnung
wegen Überschreitung max.
Anzahl Einzelfehler
StsRsnInf-Orgtr
(StatusReasonInfo
Originator)
Initiator der Rückgabe
Nur zusammen mit TxSts.
Optional, entweder Nm mit
Namen oder Id-OrgId-BICOrBEI
mit BIC angeben
Name (max. 70 Zeichen) für
Kunden-initiierte oder BIC für Bankinitiierte Rückgabe.
StsRsnInf-Rsn-Cd
(StatusReasonInfoCode)
Rückgabegrund
Rückgabegründe gemäß
separatem Dokument
zu Geschäftsvorfall- und
Rückgabecodes*
HVB: „ED05“ bei korrekter Trans­aktion
innerhalb Gesamtdatei­ablehnung.
Grundsätzlich wird nur ein Rückgabegrund angegeben.
OriginalTransactionReference
Originaldaten der ursprünglichen Transaktion
1 × je Transaction
InformationAndStatus
InstrAmt
(InstructedAmount)
Ursprünglicher Betrag und
Währungskennzeichen
Originaldaten
SCT: ReqdExctnDt
(RequestedExecutionDate)
SDD: ReqdColltnDt
(RequestedCollectionDate)
Ursprünglich gewünschtes Ausführungsdatum
(SCT)/Fälligkeitsdatum (SDD)
Originaldaten
Nur SDD:
CdtrSchmeId-Id-PrvtId-OthrId-Id
(CreditorIdentification)
Nur SDD: Ursprüngliche GläubigerIdentifikationsnummer
Originaldaten
Nur SCT: InstrPrty
(InstructedPriority)
Nur SCT: Ursprüngliche Priorität der
Ausführung
Originaldaten
Nur SCT: „HIGH“ oder „NORM“
SvcLvl
(ServiceLevel)
Ursprüngliches ServiceLevel
Originaldaten
„SEPA“
Nur SDD: LclInstrm-Cd
(LocalInstrumentCode)
Nur SDD: Ursprüngliche Lastschriftsart:
Basislastschrift oder Firmenlastschrift
Originaldaten
Nur SDD: „CORE“, „COR1“ oder
„B2B“
Nur SDD: SeqTp
(SequenceType)
Nur SDD: Ursprüngliche Sequenz: Erst-, Folge-,
Einmal- oder Letztmalige-Lastschrift
Originaldaten
Nur SDD: „FRST“, „RCUR“, „OOFF“
oder „FNAL“
CtgyPurp
(CategoryPurpose)
Ursprüngliche Zahlungsart der Datei
Originaldaten
PmtMtd
(PaymentMethod)
Ursprüngliches Zahlungs¬instrument: Credit
Transfer (SCT) / Direct Debit (SDD)
Originaldaten
Nur SDD: Mndtld
(MandateId)
Nur SDD: Ursprüngliche Mandatsreferenz
Originaldaten
Nur SDD: DtOfSgntr
(DateOfSignature)
Nur SDD: Ursprüngliches Datum zu dem das
Mandat unterschrieben wurde
Originaldaten
Nur SDD: AmdmntInd
(AmendmentIndicator)
Nur SDD: Ursprüngliches Kennzeichen, ob
Mandatsdaten geändert wurden
Originaldaten
SCT: „TRF“
SDD: „DD“
Nur SDD: „true“, wenn geändert,
sonst „false“ oder Feld nicht
aufgeführt
34
Feldnamen
Beschreibung pain.002.001.03
Befüllung HVB Standard/HVB Erweitert
Nur SDD: OrgnlMndtId
(OriginalMandateId)
Nur SDD: Ursprüngliche Referenz des alten
Mandats, falls geändert
Originaldaten
Nur SDD: OrgnlCdtrSchmeId-Nm
(OriginalCreditorName)
Nur SDD: Ursprünglicher alter Creditor Name,
falls geändert
Originaldaten
Nur SDD: OrgnlCdtrSchmeId-IdPrvtId-OthrId-Id
(OriginalCreditorIdentification)
Nur SDD: Ursprüngliche alte GläubigerIdentifikationsnummer, falls geändert
Originaldaten
Nur SDD: OrgnlDbtrAcct-IBAN
(OriginalDebtorIBAN)
Nur SDD: Ursprünglicher alte IBAN des
Zahlungspflichtigen, falls sich der IBAN
geändert hat
Originaldaten
Nur SDD:
OrgnlDbtrAcct-Othr-Id
(OrgnlDbtrAcctOthrId)
Nur SDD:
Ursprüngliche Kontoverbindung hat sich
geändert
Nur SDD:
OrgnlDbtrAgt-FinInstnId-BIC
(OrignalDebtorAgentBIC)
Nur SDD:
Ursprüngliche alte Debtorbank.
Nur SDD:
OrgnlDbtrAgt-FinInstnId-Othr-Id
(OrignalDebtorAgentId)
Nur SDD:
Ursprüngliche alte Debtorbank.
Nur SDD: ElctrncSgntr
(ElectronicSignature)
Nur SDD: Ursprüngliches elektronisches
Mandat eMandate-Signatur
Originaldaten
RmtInf
(RemittanceInfo)
Ursprünglicher Verwendungszweck
(unstrukturiert oder strukturiert)
Originaldaten
UltmtDbtr
(UltimateDebtor)
Ursprünglicher vom Kontoinhaber
abweichender Auftraggeber (SCT)/
Zahlungspflichtiger (SDD)
Originaldaten
Dbtr-Nm
(DebtorName)
Ursprünglicher Name Auftraggeber (SCT)/
Zahlungspflichtiger (SDD)
Originaldaten
Dbtr-PstlAdr-Ctry
(DebtorCountry)
Ursprüngliches Land der Anschrift des Auftraggebers (SCT) / Zahlungspflichtigen (SDD)
Originaldaten
Dbtr-PstlAdr-AdrLine
(DebtorAddress)
Ursprüngliche Anschrift Auftraggeber (SCT)/
Zahlungspflichtiger (SDD)
Originaldaten
DbtrAcct-IBAN
(DebtorAccountIBAN)
Ursprüngliche IBAN des Auftraggebers (SCT)/
Zahlungspflichtigen (SDD)
Originaldaten
DbtrAgt-BIC
(DebtorAgentBIC)
Ursprünglicher BIC der Bank des Auftraggebers
(SCT)/Zahlungspflichtigen (SDD) bzw. Id bei
IBAN-Only
Originaldaten
CdtrAgt-BIC
(CreditorAgentBIC)
Ursprünglicher BIC der Bank des Begünstigten
(SCT)/Zahlungsempfängers (SDD) bzw. Id bei
IBAN-Only
Originaldaten
Cdtr-Nm
(CreditorName)
Ursprünglicher Name Begünstigter (SCT)/
Zahlungsempfänger (SDD)
Originaldaten
Cdtr-PstlAdr-Ctry
(CreditorCountry)
Ursprüngliches Land der Anschrift des
Begünstigten (SCT)/Zahlungsempfängers (SDD)
Originaldaten
Cdtr-PstlAdr-AdrLine
(CreditorAddress)
Ursprüngliche Anschrift Begünstigter (SCT)/
Zahlungsempfänger (SDD)
Originaldaten
CdtrAcct-IBAN
(CreditorAccountIBAN)
Ursprüngliche IBAN des Begünstigten (SCT)/
Zahlungsempfängers (SDD)
Originaldaten
UltmtCdtr
(UltimateCreditor)
Ursprünglicher abweichender Endbegünstigter
(SCT)/Zahlungsempfänger (SDD)
Originaldaten
Nur SDD: „SMNDA“
ab November 2016
(pain.002.001.03)
Originaldaten
Nur SDD:
ab November 2016
(pain.002.001.03)
Nur SDD: „SMNDA“
bis November 2016
(pain.002.003.03)
Max. 140 Zeichen
* Unsere Broschüre „Geschäftsvorfall- und Rückgabecodes“ stellt Ihnen Ihr Cash Management & eBanking-Spezialist auf Anfrage gerne zur Verfügung.
35
Die folgende Tabelle stellt die wesentlichen Unterschiede zwischen HVB Standard und HVB Erweitert pain.002
Status Information dar.
Tag
HVB Standard (bisher)
HVB Erweitert (neu)
GrpHdr/MsgId
19-stellig
19-stellig; Kennzeichen vor/nach Buchung weiter an dritter Stelle
GrpHdr/DbtrAgt/FinInstnId/BIC
BIC8 HYVEDEMM
BIC11 HYVEDEMMXXX
OrgnlGrpInfAndSts/OrgnlMsgNmId
pain.001
Kompletter Namespace der ursprünglichen Einreichung pain.001.001.03
OrgnlGrpInfAndSts/OrgnlNbOfTxs
OrgnlPmtInfAndSts/OrgnlNbOfTxs
führende Nullen,
z. B. 000000000000002
Keine führenden Nullen, z. B. 2
OrgnlGrpInfAndSts/OrgnlCtrlSum
OrgnlPmtInfAndSts/OrgnlCtrlSum
Bei Beträgen kleiner 1.00 EUR wird keine
führende Null angegeben, z. B. .56
Bei Beträgen kleiner 1.00 EUR wird eine führende Null angegeben, z. B. 0.56
OrgnlPmtInfAndSts/PmtInfSts
nicht verwendet
Immer gefüllt ACCP, ACWC, ACSC, PART, RJCT
OrgnlPmtInfAndSts/StsRsnInf/Rsn/Cd
nicht verwendet
Bei RJCT immer spezifischer Grund angegeben.
Bei ACWC nur für Lastschrift bei Anpassung Ausführungsdatum: DT06
TxInfAndSts
immer verwendet
Nur bei Ablehnung von Einzeltransaktionen – PmtInfSts = PART.
Sonderfall:
Dateiablehnung wegen Überschreitung max. Anzahl fehlerhafter Einzeltransaktionen
7.1.3 camt.029 Status Information zum elektronischen Rückruf
Mit der camt.029 Status Information im ISO 20022 XML-Format erhalten Sie eine Rückmeldung zu einem eingereichten elektronischen Rückruf von einer Datei oder Transaktionen, bei negativen Ergebnis (Rückruf konnte nicht
erfolgreich ausgeführt werden) inklusive Angabe des Grundes.
Auch im camt.029 wird als Zeichensatz die international standardisierte Kodierung UTF-8 verwendet, ein umfangreicher Zeichensatz mit vielen länderspezifischen Umlauten, welcher auch im XML-Header vermerkt ist:
<?xml version="1.0" encoding="UTF-8"?>.
camt.055
camt.029
Assignment (1..1)
Assignment (1..1)
UnderlyingCase (1..1)
ResolvedCase (1..1)
StatusConfirmation (1..1)
• CNCL camt.055 Rückruf erfolgreich
• PDCR/UWFW: Zwischenstatus
• RJCT: camt.055 nicht erfolgreich
pain.001/pain.008
CancellationDetails (1..1)
CancellationDetails (1..1)
PaymentInformation (1..n)
OriginalPayment
InformationAndCanellation
OriginalPayment
InformationAndStatus (0..1)
TransactionInformation
TransactionInformation
AndStatus (0..n)
TransactionInformati(1..n)
on (1..n)
TransactionInformation
TransactionInformatiAndStatus (0..n)
TransactionInformation (1..n)
on (1..n)
TransactionInformation
TransactionInformation
AndStatus (0..n)
TransactionInformation
(1..n)
(1..n)
GroupHeader (1..1)
36
Feldnamen
Assgnmt
RslvdCase
Beschreibung camt.029
Assignment
Beteiligte der Nachricht
Id
Identification der Nachricht
Assgnr – Agt – FinInstnId – BICFI
Ersteller der Nachricht – hier BIC der Bank
Assgne – Pty – Nm
Empfänger der Nachricht
CreDtTm
Erstellungsdatum und -zeit der Nachricht
Befüllung HVB
eindeutige Id pro camt.029
wird aus dem zugrunde liegenden camt.055 befüllt
Resolved Case
Id
ursprüngliche Case Id des Rückrufs
wird aus dem zugrunde liegenden camt.055 befüllt
Cretr – Pty – Nm
ursprünglicher Ersteller des Rückrufs
wird aus dem zugrunde liegenden camt.055 befüllt
Cretr – Pty – Id – OrgId – Othr
– Id
Einreicher IBAN der Rückrufanfrage
wird aus dem zugrunde liegenden camt.055 befüllt
Status
Resultat für den Rückruf, gilt die Datei oder aufgeführte
Transaktionen
Conf
Status Code
• CNCL: Request for Cancellation successful,
• RJCR: Request for Cancellation not successful
• PDCR: Pending (in case of required Interbank Recall
camt.056)
• UWFW: Unable To Apply Will Follow
CxlDtls
Cancellation Details
Details zum Ergebnis für den Rückruf, bei einer
Rückweisung mit Angabe des Grundes
hauptsächlich die Informationen aus dem eingereichten
camt.055
OrgnlPmt
InfAndSts
Original Payment Information
And Status
NUR bei Antwort auf Dateiebene. Wird nicht geliefert,
wenn ein Dateirückruf nur auf Einzelsatz beantwortet
werden kann, z.B. CT nach Clearing.
OrgnlPmtInfId
wird aus dem zugrunde liegenden camt.055 befüllt
CxlStsRsnInf – Rsn – Cd
Bei Status RJCR wird hier der Grund angegeben.
TransactionInformationAnd
Status
Immer bei Antwort auf Einzelsatz-Ebene. Auch bei Dateirückruf mit Antwort zu Einzelsätzen.
OrgnlInstrId
wird aus dem zugrunde liegenden camt.055 befüllt*
OrgnlEndToEndId
wird aus dem zugrunde liegenden camt.055 befüllt*
OrgnlTxId
Interbank Id der ursprünglichen Transaktion zu Informationszwecken
CxlStsRsnInf – Rsn – Cd
Bei Status RJCR wird hier der Grund angegeben.
Sts
TxInfAndSts
OrgnlTxRef
OriginalTransactionReference
IntrBkSttlmAmt
Interbank Amt der ursprünglichen Transaktion zu Informationszwecken
Amt – InstdAmt
wird aus dem zugrunde liegenden camt.055 befüllt*
IntrBkSttlmDt
Interbank Settlement Date der ursprünglichen Transaktion
zu Informationszwecken
ReqdColltnDt
ursprüngliches Ausführungsdatum bei DD
wird aus dem zugrunde liegenden camt.055 befüllt*
ReqdExctnDt
ursprüngliches Ausführungsdatum bei CT
wird aus dem zugrunde liegenden camt.055 befüllt*
RmtInf – Ustrd
RmtInf – Strd
Verwendungszweck
wird aus dem zugrunde liegenden camt.055 befüllt*
Dbtr – Nm
nur bei DD
wird aus dem zugrunde liegenden camt.055 befüllt*
DbtrAcct – Id – IBAN
nur bei DD
wird aus dem zugrunde liegenden camt.055 befüllt*
DbtrAgt – FinInstnId – BICFI
nur bei DD
wird aus dem zugrunde liegenden camt.055 befüllt*
CdtrAgt – FinInstnId – BICFI
nur bei CT
wird aus dem zugrunde liegenden camt.055 befüllt*
Cdtr – Nm
nur bei CT
wird aus dem zugrunde liegenden camt.055 befüllt*
CdtrAcct – Id – IBAN
nur bei CT
wird aus dem zugrunde liegenden camt.055 befüllt*
*bei Dateirückrufen, die nur für Einzelsätze beantwortet werden können, werden diese Daten aus den Transaktionsdetails der ursprünglichen Einreichung angereichert.
37
7.1.4 MT940, MT942 – Kontoinformation
Über die SWIFT-Nachrichten MT940 für Kontoauszüge und MT942 für Vormerkposten können ebenfalls
Kontoinformationen abgerufen werden. Die HVB stellt diese Nachrichtentypen konform zur
Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und Kreditinstitut gemäß
DFÜ-Abkommen „Spezifikation der Datenformate“ bereit.
Der SWIFT-MT-Zeichensatz bietet trotz seiner internationalen Nutzung im Gegensatz zum umfangreichen
UTF‑8-Zeichensatz nur einen sehr begrenzten Zeichenvorrat bestehend aus den Ziffern 0 – 9, den Buchstaben a – z
und A – Z, den Sonderzeichen / - ? : ( ) . , ' + sowie dem Leerzeichen. Bei SEPA-Transaktionen mit Zeichen außerhalb des SWIFT-MT-Zeichensatzes erfolgen daher Zeichenkonvertierungen, die eine automatische Ver­arbeitung
erschweren.
Für SEPA bleiben zwar die SWIFT-Strukturen im MT940 und MT942 unverändert, allerdings sind die Felder 61 und
86 inhaltlich angepasst worden.
Für das obligatorische Feld 61 ergeben sich folgende Ergänzungen:
Struktur des Feldes 61
Inhalt
Bemerkung
61/7 (Kundenreferenz)
Aus SCT oder SDD: Payment Information Identification, falls
bei Einreichung belegt, sonst Bulk-Message-Id
• Wenn länger als 16 Stellen: „KREF+“ und
kompletter Feldinhalt im Feld 86
• Wenn leer: „NONREF“
61/9 (Weitere Informationen)
Bei SDD-Rückgaben: Einstellung des Ursprungsbetrages
mit „OCMT“ (Ursprungsbetrag) und „CHGS“ (Summe aus
Gebühren und ggf. Zinsausgleich)
Zusätzlich zu den obligatorischen Feldern enthalten der MT940 und MT942 das optionale Feld 86 mit Informationen für den Kontoinhaber. Die HVB nutzt eine Substruktur für die Bereitstellung zusätzlicher Detailinformationen
in strukturierter Form, wie unten dargestellt. Zur Identifizierung des Typs der zugrunde liegenden Trans­aktionen
wird ein dreistelliger Geschäftsvorfallcode in Kombination mit dem entsprechenden Buchungstext bereit gestellt.
38
Struktur des Feldes 86 für SEPA-Transaktionen
Position
bzw. Feldschlüssel
Bezeichnung
Länge / Format*,
bisher
Länge / Format*, Bemerkung
neu
Die ersten
3 Zeichen
Geschäftsvorfallcode
3n
Keine Änderung
Für SEPA werden spezifische GVCs
vergeben (1xx)
?00
Buchungstext
27a
Keine Änderung
Für SEPA werden spezifische Buchungstexte
vergeben
In der Transaktion vorhandene SEPA-Attribute
werden via Bezeichner dargestellt:
EREF+[Ende-zu-Ende-Referenz]
KREF+[Kundenreferenz]
MREF+[Mandatsreferenz]
CRED+[Creditor Identifier] oder
DEBT+[Originators Identification Code]
SVWZ+[SEPA-Verwendungszweck]
ABWA+[abweichender Auftraggeber]
ABWE+[abweichender Empfänger]
Jeder Bezeichner muss am Anfang eines Subfeldes (z. B. ?21) stehen, Fortsetzung des Inhalts ggf. im nachfolgenden Subfeld ohne
Wiederholung des Bezeichners.
Bei Rückgabe SVWZ+[SEPA-REJECT bzw. RUECKUEBERWEISUNG bzw.
RUECLLASTSCHRIFT und Rückgabegrund im Klartext]
?10
Primanoten-Nr.
10x
?20–?29
Verwendungszweck
10 × 27x
Keine Änderung
?30
BLZ Überweisender/
Zahlungsempfänger
12n
12x
?31
Kto.-Nr. Überweisender/
Zahlungsempfänger
24n
34x
IBAN anstelle der Kontonummer
?32–?33
Name Überweisender/
Zahlungsempfänger
2 × 27x
Keine Änderung
SEPA-Länge 70; gekürzt auf 54 (2 × 27)
?34
Textschlüsselergänzung
3n
Keine Änderung
Nutzung einer Mapping-Tabelle zur Umwandlung des
vier­stelligen SEPA-Rückgabecodes in einen dreistelligen Code
?60–?63
Verwendungszweck
4 × 27x
Keine Änderung
Ggf. Fortsetzung von ?20–?29
* n = numerisch, a = alphabetisch, x = alphanumerisch
39
7.1.5 DTI – Datenträgerinformation
Eine DTI-Datei im DTAUS0/DTAUS1-Format besteht aus folgenden Teilen:
• Datensatz A: Datenträger-Vorsatz
• Datensatz C: Zahlungsaustauschsätze
• Datensatz E: Datenträger-Nachsatz.
Der Zeichensatz einer DTI-Datei ist im Gegensatz zum internationalen UTF-8-Zeichensatz des XML-Formats auf
die begrenzte Nutzung in Deutschland ausgerichtet und enthält nur Ziffern 0 – 9, Großbuchstaben A – Z, deutsche Umlaute ÄÖÜ und ß, die Sonderzeichen . , & - / + * % $ sowie das Leerzeichen. Bei SEPA-Transaktionen mit
Zeichen außerhalb des DTI-Zeichensatzes erfolgen daher Zeichenkonvertierungen, die eine automatische Ver­
arbeitung erschweren.
Das DTI-Format ist im DTA-basierten Inlandszahlungsverkehr weit verbreitet, so dass im Nachfolgenden nur die
Felder aufgeführt werden, die sich durch die Aufnahme der SEPA-Transaktionen ändern. In den Datensätzen A und
E gibt es keine Änderungen bei der SEPA-DTI-Datei gegenüber der DTA-basierten DTI-Datei. Im Datensatz C er­
geben sich folgende Änderungen durch SEPA-Transaktionen:
Feld
Länge
Name
Inhalt
C6a
1
Kennzeichen für Referenz
„9“ für SEPA-Zahlung
C7a
2
Textschlüssel
51 – SCT
52 – SCT Dauerauftrag (Purpose: RINP)
53 – SCT Gehaltszahlung (Purpose: BONU, PENS, SALA, PAYR)
54 – SCT VL-Zahlung (Purpose: CBFF)
56 – SCT öffentliche Kassen (Purpose: GOVT, SSBE, BENE)
69 – SCT Spende (Purpose: CHAR)
67 – SCT mit strukturierter Referenznummer im Verwendungszweck
59 – SCT R-Message
05 – SDD Core
04 – SDD B2B
09 – SDD R-Message
C7b
3
Textschlüsselergänzung
000 – SCT
990 – SDD Änderung Mandatsreferenz
991 – SDD Erstlastschrift
992 – SDD Folgelastschrift
993 – SDD Einmallastschrift, SCC Wiedervorlage
Bei R-Transaktionen wird eine zum SEPA Code korrespondierende
Textschlüsselergänzung verwendet, siehe separates Dokument zu
Geschäftsvorfall- und Rückgabecodes.*
bei SCC Kartenlastschriften:
003 – Auszahlung
011 – POS Kartenzahlung
023 – Auszahlung mit Kundenentgelt
024 – gemischer Kartensammler
030 – POS Cashback
073 – Laden Mobilfunk
201 – Summeneinzug Geldkarte
210 – Entgelteinzug Geldkarte
240 – Laden Geldkarte
40
Feld
Länge
Name
Inhalt
C10
8
Auftraggeber-BLZ
Bei deutschen IBAN die BLZ aus Stelle 5 – 12 der IBAN, sonst
„9999999999“ sowie zusätzlich im Verwendungszweck „IBAN+[IBAN]“
C11
10
Auftraggeber-Konto
Bei deutschen IBAN das Konto aus Stelle 13 – 22 der IBAN, sonst
„9999999999“ sowie zusätzlich im Verwendungszweck „IBAN+[IBAN]“
C14a und Erweiterungsteile
mit Kennzeichen 01
je 27
Name des Zahlungsempfängers bei
Überweisungen/Zahlers bei Lastschriften
Name bis Länge 54 und ggf. Fortsetzung bis SEPA-Länge 70 im
Erweiterungsteil 01
C14b
8
Valuta
Lieferung individuell je Kunden konfigurierbar
C15 und Erweiterungsteile mit
Kennzeichen 03
je 27
Auftraggeber-Name
Name bis Länge 54 und ggf. Fortsetzung bis SEPA-Länge 70 im
Erweiterungsteil 03
C16 und Erweiterungsteile mit
Kennzeichen 02
je 27
Verwendungszweck
SEPA-Daten mit Bezeichnern in folgender Reihenfolge, wobei jeder
Bezeichner am Anfang eines Erweiterungsteils stehen muss:
Für SCT:
IBAN+[IBAN des Auftraggebers]
BIC+[BIC des Auftraggebers]
EREF+[Ende-zu-Ende Referenz]
DEBT+[Auftraggeber-CI, wenn belegt]
SVWZ+[SEPA-Verwendungszweck]
ABWA+[Abweichender Überweisender]
ABWE+[Abweichender Zahlungsempfänger]
PURP+[Purpose]
Für SDD:
IBAN+[IBAN des Auftraggebers]
BIC+[BIC des Auftraggebers]
EREF+[Ende-zu-Ende Referenz]
MREF+[Mandatsreferenz]
CRED+[Auftraggeber CI]
SVWZ+[SEPA-Verwendungszweck]
ABWA+[Abweichender Zahlungsempfänger]
ABWE+[Abweichender Zahlungspflichtiger]
PURP+[Purpose]
ORCR+[Mandatsänderung: alte CI]
ORMR+[Mandatsänderung: alte Mandatsref ]
Bei R-Transaktionen:
IBAN+[IBAN des Auftraggebers]
BIC+[BIC des Auftraggebers]
EREF+[Ende-zu-Ende Referenz]
SVWZ+[Konstante: SEPA-REJECT bzw. RUECKUEBERWEISUNG bzw.
RUECKLASTSCHRIFT und Rückgabegrund im Klartext]
Aufgrund der Feldlängenbegrenzung im DTI-Format wird der Rückgabegrund teilweise abgeschnitten oder umformuliert. Die Rückgabegründe
und deren Klartexte sind in unserer Broschüre „Geschäftsvorfall- und
Rückgabecodes“ beschrieben.*
MREF+[Mandatsreferenz]
OAMT+[Originalbetrag der Ursprungszahlung]
COAM+[ggf. ZINSAUSGLEICH U ENTGELT FREMD xxxxx,xx ENTGELT EIGN
xxxxx,xx]
CRED+[Auftraggeber CI] bzw. DEBT+ bei SCT
DDAT+[ursprünglicher Settlement-Tag]
ABWA+[Abweichender Überweisender]
*U
nsere Broschüre „Geschäftsvorfall- und Rückgabecodes“ stellt Ihnen Ihr Cash Management & eBanking-Spezialist gerne auf Anfrage zur Verfügung.
41
7.2
Geschäftsvorfall- und Rückgabecodes
Die HVB stellt Ihnen SEPA Reason Codes, Geschäftsvorfallcodes (GVC), SWIFT-Transaction-Codes und
Buchungstexte in den Reports camt.053/052/054, pain.002, MT940/942 sowie DTI zur Verfügung zur Verfügung.
In Abhängigkeit von der zum Konto konfigurierten Sprache wird der Buchungstext in Deutsch, Englisch oder
Französisch angezeigt.
Eine Tabelle aller Codes und Buchungstexte sowie weitere Details finden Sie in unserer Broschüre
„Geschäftsvorfall- und Rückgabecodes“, welche Ihnen Ihr Cash Management & eBanking-Spezialist auf Anfrage
gerne zur Verfügung stellt.
Die Erfahrungen* zeigen, dass die Rückgabequote bei SEPA-Überweisungen (SCT) mit deutlich unter 1 % sehr
gering ist und hauptsächlich wegen falscher IBAN (AC01) und gelöschtem Konto (AC04) zurückgewiesen wird. Die
Rückgabequote* bei SEPA-Firmenlastschriften (SDD-B2B) liegt im 1-%-Bereich, wobei hier am häufigsten sonstige
Gründe (MS03, enthält auch anonymisiert mangels Deckung AM04) und kein gültiges Mandat (MD01) bemängelt
werden.
Bei Einreichungen von SEPA-Basislastschriften (SDD-Core) sind mit gut 2 % am häufigsten Rückgaben zu
erwarten*. Auch hier verdichten sich die möglichen SEPA Reason Codes der Rückgaben aber auf wenige Codes.
In der unteren Tabelle sind die häufigsten Codes aufgeführt, auf deren Verarbeitung man sich vorbereiten sollte,
wenn möglich sogar automatisch.
SEPA Reason Code
Rückgabegrund im Klartext
Bemerkung
MS03
Sonstige Gründe
Rückgabe durch die Bank, wobei hier auch anonymisierte Gründe enthalten sind
u. a. Rückgabe wegen rechtlicher Vorschriften (LEGL), Kontosperre (AC06), mangels
Deckung (AM04) oder Kontoinhaber verstorben (MD07).
AC04
Konto aufgelöst
AC01
Kontonummer fehlerhaft (ungültige IBAN)
MD06
Lastschriftwiderspruch durch den Zahlungspflichtigen
MD01
Kein gültiges Mandat
AC06
Konto gesperrt
MS02
Sonstige Gründe
Kein Mandat bei B2B oder Core-Refund bis 13 Monate oder unwiderrufliche
Lastschriftsperre
Rückgabe durch den Kunden
* Berechnungen durchschnittlicher Rückgabequoten bei der HVB im März 2016
42
7.3
EBICS-Auftragsarten
Für die Abholung der Reports stehen folgende EBICS-Auftragsarten gemäß Anhang 2 der EBICS-Spezifikation zur
Verfügung, siehe auch EBICS der Deutschen Kreditwirtschaft: www.ebics.de/index.php?id=30
Auftragsart
Text
Für*
CBC
Abholen Payment Status Report for Direct Debit via XML-Container
XML-Container mit n Nachrichten pain.002
CDZ
Abholen Payment Status Report for Direct Debit
Zip-Datei mit 1-n Nachrichten pain.002
CRC
Abholen Payment Status Report for Credit Transfer via XML-Container
XML-Container mit n Nachrichten pain.002
CRZ
Abholen Payment Status Report for Credit Transfer
Zip-Datei mit 1-n Nachrichten pain.002
C29
Abholen Answer to Recall / Antwort auf Rückrufanfrage camt.055
Zip-Datei mit 1-n Nachrichten camt.029.001.06
C52
Abholen Bank To Customer-Account Report
Zip-Datei mit 1-n Nachrichten des Typs camt.052.001.02
C53
Abholen Bank To Customer-Statement Report
Zip-Datei mit 1-n Nachrichten des Typs camt.053.001.02
C54
Abholen Bank To Customer-Debit Credit Notification
Zip-Datei mit 1-n Nachrichten des Typs camt.054.001.02
STA
Abholen Swift-Tagesauszüge
MT940
VMK
Abholen kurzfrsitige Vormerkposten
MT942
* Varianten entsprechen den für die Einreichung von Aufträgen zugehörigen Versionen
Für den erweiterten pain.002 Status Information mit optionalen positive Status Codes stehen bis auf weiteres
folgende HVB spezifischen Auftragsarten zur Verfügung.
Auftragsart
Text
Für*
XDZ
Abholen Payment Status Information for Direct Debit
Zip-Datei mit 1-n Nachrichten pain.002
XDX
Abholen Payment Status Information for Direct Debit via XML-Container
XML-Container mit n Nachrichten pain.002
XTZ
Abholen Payment Status Information for Credit Transfer
Zip-Datei mit 1-n Nachrichten pain.002
XTX
Abholen Payment Status Information for Credit Transfer via XML-Container
XML-Container mit n Nachrichten pain.002
* Varianten entsprechen den für die Einreichung von Aufträgen zugehörigen Versionen
43
Hinweis
Diese Kundeninformation dient lediglich zu Informations­zwecken
und bietet einen allgemeinen Überblick über das geplante
Leistungs­angebot zu SEPA. Die allgemeinen Angaben in diesem
Informationsschreiben beziehen sich auf SEPA-Produkte, wie sie
zum Zeitpunkt der Erstellung dieses Schreibens (Oktober 2016)
geplant sind. Zukünftige Änderungen sind vorbehalten.
Haftungsausschluss
Die in dieser Veröffentlichung enthaltenen Angaben basieren auf
sorgfältig ausgewählten Quellen, die als zuverlässig gelten. Wir
geben jedoch keine Gewähr für die Richtigkeit oder Vollständigkeit
der Angaben. Hierin zum Ausdruck gebrachte Meinungen geben
unsere derzeitige Ansicht wieder und können ohne vorherige
Ankündigung geändert werden. Die hierin bereitgestellten Berichte dienen nur allgemeinen Informationszwecken und sind kein
Ersatz für eine unabhängige Finanzberatung.
Kein Bestandteil dieser Veröffentlichung soll vertragliche
Verpflichtungen aufseiten der Division Corporate & Investment
Banking der UniCredit Bank AG, München, betrachten.
Inhalt und Aufbau dieser Broschüre der UniCredit Bank AG sind urheberrechtlich geschützt. Die Vervielfältigung von Informationen
oder Daten, insbesondere die Verwendung von Texten, Textteilen
oder Bildmaterial, bedarf der vorherigen Zustimmung der
UniCredit Bank AG.
© UniCredit Bank AG, München. Alle Rechte vorbehalten.
© Titelbild HGEsch 2016
Die UniCredit Bank AG untersteht der Aufsicht der Bundesanstalt
für Finanzdienstleistungsaufsicht. UniCredit Bank AG, Rechtsform:
Aktiengesellschaft, Sitz: München.
Impressum
UniCredit Bank AG
Corporate & Investment Banking
Arabellastraße 12
81925 München
E-Mail: [email protected]
Filiale
Alle Filialen finden Sie im Internet unter
hvb.de/filialfinder
E-Mail
[email protected]
Online
hvb.de/SEPA
Stand 10 / 2016
/hypovereinsbank

ISO Readiness Stufen Management

Zeitplan Veränderungen im Zahlungsverkehr Schweiz

Liste der Finanzinstitute, die ISO 20022 unterstützen

Druckansicht

PDF herunterladen

Anlage 3 - Postbank

Liste der Finanzinstitute, die ISO 20022 unterstützen - Migration PT

Literaturverzeichnis zum Artikel „Kurse zum

Die Deutsche Kreditwirtschaft - SEPA Zahlungsverkehr 2016

Flyer - Deutsche Kontinenz Gesellschaft