Anlage zur SEPA- Kundeninformation

Transcription

Anlage zur SEPAKundeninformation
Technische
Spezifikationen
und Formate
Aktualisierte Auflage
Stand: 09/2013
mit den Neuerungen
ab 04.11.2013
Anzeige
Ohne SEPA-Umstellung fließt
bei Ihnen ab dem 01.02.2014
vielleicht kein Geld mehr.
B SEPA-Che
HV
.hv
K
•
Jetz
t
ww
• w
CHEC
machen!
ck
SEPA
b-sepa.de
Deshalb jetzt mit den
HVB Spezialisten auf
SEPA umstellen und
zahlungsfähig bleiben.
Der HVB SEPA-Check
unterstützt Sie dabei:
unter www.hvb-sepa.de
Inhalt
1.Dateiformate und SEPA-Verfahren –
der aktuelle Stand in Deutschland
5
2.Zusammenhang der Kunden- und
Bankformate (ISO 20022)
6
3.SEPA-Kundenformate
6
4.Änderungen für November 2013
8
11.Reporting-Übersicht
44
11.1 Reporting (Bank – Kunde)
44
11.2 Buchung von SEPA-Dateien
44
11.3 Status/Fehlernachricht pain.002
46
11.4Rückgabegründe
48
11.5 Payment Status Report/
pain. 002-SEPA Credit Transfer
50
5.Nachrichtentypen-Erkennung
10
6. Aufbau der Kundendatei (XML)
12
11.6Payment Status Report/
pain.002-SEPA Direct Debit
52
7. SEPA Credit Transfer (SCT)
14
11.7 Elektronischer Kontoauszug MT940
54
8. Beispiel einer Kundendatei
17
12. Internationale SEPA-Formate
56
9. SEPA Direct Debit (SDD)
18
13.Taggleiche Eilüberweisungen in Euro
via pain.001
61
10.SEPA – häufig genutzte Zahlungsinformationen im Format
22
10.1Verwendungszweck/RemittanceInfo
22
10.2 Zahlungsgrund/Purpose Code
24
10.3 Produktkategorie/Category Purpose
25
10.4 Fünf Beteiligte in einer SEPA-Nachricht
25
10.5 Name, Adresse
26
10.6 IBAN, IBAN-Only
27
10.7Gläubiger-Identifikation/CI
30
10.8Identifikationsnummern
(OrgID/PrivateID)31
10.9Ultimate/Reference Party/On Behalf
32
10.10Mandatsänderung/
Mandate-Amendment33
10.11Lastschriftsequenz
36
10.12 Zeichensatz und Umlaute
38
10.13Konkurrierende Felder XOR
40
10.14SEPA-Referenznummern und
deren Verwendung
41
Um Ihnen einen raschen Überblick über die Änderungen gegenüber der Vorauflage
anzuzeigen, finden Sie am Rand des Textes eine Kennzeichnung.
Für die Umstellung auf SEPA müssen Datenfelder in Ihren Systemen entsprechend angepasst werden.
In der vorliegenden Broschüre erhalten Sie wesentliche Details zu den technischen Spezifikationen und
verschiedenen SEPA-Formaten.
Bei den nachfolgenden Informationen handelt es sich um eine Empfehlung.
Grundlage hierfür ist das DFÜ-Abkommen. Auf den nächsten Seiten dieser Broschüre finden Sie eine
Zusammenfassung der wichtigsten fachlichen Felder, die zur Umstellung auf SEPA erforderlich sind.
Weitere Details oder Angaben zu technischen Feldern entnehmen Sie dem nachfolgenden Link:
Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und
Kreditinstitut gemäß DFÜ-Abkommen Version 2.7 vom 25.03.2013, gültig ab 4. November 2013
www.ebics.de/index.php?id=77
Weitere Informationen zur finalen Beschreibung der Formate erhalten Sie bei folgenden Stellen:
• Deutsche Kreditwirtschaft (DK)
Anlagen zum Kapitel 2, „SEPA-Zahlungsverkehr“ der Version 2.7 der Anlage 3
• XML-Schemata für SEPA: www.ebics.de
4
1. Datenformate und SEPA-Verfahren –
der aktuelle Stand in Deutschland
Datenformate
Die SEPA-Datenformate basieren auf dem ISO-Standard 20022/UNIFI (Universal Financial Industry Message Scheme:
www.iso20022.org) für XML.
• XML ist ein offener Standard.
• Keine feste Vorgabe von Feldbelegungen
• Größer als die bekannten DTA-Formate (z. B. DTAUS und DTAZV)
• Implementation Guidelines (Interbankenverkehr) wurden vom European Payments Council (EPC)
im September 2006 verabschiedet und werden jährlich weiterentwickelt.
• ISO 20022 als XML-basiertes Format bildet die Grundlage für den modernen globalen Zahlungsverkehr
und bietet eine sehr große Bandbreite und dadurch eine entsprechende Variabilität an.
• SEPA macht den Anfang einer durchgängigen ISO 20022-Verarbeitung im Zahlungsverkehrsprozess
hinsichtlich aller SEPA-Produkte. Im SEPA-Umfeld basiert bereits die komplette Prozesskette bis hin
zum Auszug auf XML-ISO20022.
– <CdtTrfTxInf>
– <PmtId>
<EndToEndId>OriginatorID1234</EndToEndId>
</PmtId>
– <Amt>
<InstdAmt Ccy=“EUR“>1234.56</InstdAmt>
</Amt>
– <CdtrAgt>
– <FinInstnId>
<BIC>SPUEDE2UXXX</BIC>
</FinInstnId>
</CdtrAgt>
– <Cdtr>
<Nm>Creditor Name</Nm>
</Cdtr>
– <CdtrAcct>
– <Id>
<IBAN>DE21500500009876543210</IBAN>
Für die Kunde-Bank-Beziehung wurde das pain-Format (Payment Initiation) festgelegt.
5
2. Zusammenhang der Kunden- und
Bankformate (ISO 20022)
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 erhält dann über die
Buchungen als Kontoinformation das camt-Format optional zur Verfügung gestellt. Fehler/Rejects können
optional an den Kunden auch im pain-Format als Datei von der Bank zur Verfügung gestellt werden.
Zahlungsauftrag
Fehlerinformation
pain
• pain = Payment initiation
• Zahlungsverkehrsinitiierung für
• Überweisungen (pain.001)
• Lastschriften (pain.008)
pain
• pain = Payment initiation Fehlernachrichten
• Fehlermeldung/Status-Message
(pain.002)
pacs
• pacs = Payment clearing & settlement
• Clearing für
• Überweisungen (pacs.008)
• Lastschriften (pacs.003)
pacs
• pacs = C&S Fehlernachrichten
• Fehlermeldung/Status-Message
camt
• camt = cash management
• Konto-Informationen
• Avis (camt.052)
• Auszug (camt.053)
• DTI (camt.054)
Kunde
Bank
Kunde
Kundeninformation
3. SEPA-Kundenformate
Format-Evolution
Was ändert sich bei den SEPA-Auftragsdaten?
Januar 2008 (DFÜ Anlage 3 – Version 2.2)
• Start SEPA-Überweisung (Credit Transfer)
• Formatversionen: pain.001.001.02, pain.002.001.02.ct
November 2008 (DFÜ Anlage 3 – Version 2.3)
• Keine inhaltlichen Formatänderungen, aber Berücksichtigung von Gruppierung und Containern:
pain.001.001.02, pain.001.001.02.grp, pain.001.001.02.con, pain.002.001.02.ct, pain.002.001.02.ct.con
6
• Start SEPA-Basislastschrift (Direct Debit Core) und SEPA-Firmenlastschrift (Direct Debit B2B)
• Formatversionen: pain.001.002.02, pain.008.002.01, pain.002.002.02
• Grouping Standard vereinheitlicht – nur noch MIXED analog European-Payments-Council (EPC)-Vorgaben
• Optional: Zahlungsgründe standardisiert (über 100 Purpose-Codes), z. B. Gehalt, vermögenswirksame
Leistungen, öffentliche Kassen
• Optional: zusätzliche Namensfelder für Dritt-Beteiligte: Ultimative Creditor/Debtor
• Optional: Definition der Formate für XML-Auszug (camt.052, camt.053, camt.054)
• Summenfelder (Betrag, Posten und Referenz) auf Sammler-Ebene (PaymentInfo)
• Restrukturierung der Reject pain.002-Nachricht auf Kundenbedürfnisse
• Strukturierte Rückmeldung im MT940/MT942/DTI von Retouren-Gebühren
• Rückgabegrund FOCR aufgrund SCT-Rückruf nach Buchung (Recall)
• Optional: Zahlungsgrund Spende (PurposeCode = CHAR)
• Optional: prüfzifferngerechte CreditorReferenz auf Überweisungsbelegen
November 2011
Keine Formatänderungen
• Keine Formatänderungen
• Rückgabegrund AC13, wenn Zahlungspflichtiger ein Verbraucher ist, und FF05, wenn Lastschrift mit
verkürzter Vorlauffrist COR1 nicht möglich ist
• Verkürzte Vorlauffrist COR1
• IBAN-Only
• Eilüberweisung als pain.001 mit Servicel-Level URGP
Hinweis: Jedes Jahr im November tritt ein neues Rulebook, das die Grundlage für die fortschreitenden Anpassungen an die aktuellen Bedürfnisse bildet, in Kraft. Einzige Ausnahme: Das EPC Rulebook 7.0 wird erst mit dem Migrationsdatum 01.02.2014 umgesetzt. 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ängerversion angenommen werden sollen. Die
HVB nimmt darüber hinaus auch noch ältere Versionen an. Für Nutzung neuer Funktionalitäten müssen allerdings
auch die entsprechenden Formate verwendet werden.
7
4. Änderungen für November 2013
Zum 4. November 2013 wird eine neue DFÜ-Anlage 3, Version 2.7, eingeführt (veröffentlicht seit 25.03.2013):
• Es wird eine neue XML-Version für die Formate auch mit neuen Prüfschemata (XSD) zur Abdeckung der
fachlichen Änderungen (insb. wegen IBAN-Only, COR1 und URGP) notwendig:
Version 2.5/V2.6Version 2.7
• SCT: pain.001.002.03 ->
pain.001.003.03
• SDD: pain.008.002.02
->
pain.008.003.02
• Status:
pain.002.002.03
->
pain.002.003.03
• SEPA-Basislastschrift mit verkürzter Vorlauffrist COR1 (D-1)
• Die COR1-Basislastschrift wird zum 4. November 2013 deutschlandweit eingeführt.
• Für den EBICS-Standard ist die Auftragsart CD1 bzw. C1C (Container) zu verwenden.
• Im Local-Instrument-Code des pain.008.003.02 wird der Code „COR1“ verwendet.
•D
ie HVB nimmt bereits vor der deutschlandweiten Einführung COR1-Basislastschriften im pain.008.002.02
und pain.008.001.02 entgegen, wenn der Zahlungspflichtige bei der HVB ist.
<LclInstrm>
<Cd>COR1</Cd>
</LclInstrm>
• XML-Urgent Payment – Eiliger Zahlungsverkehrsauftrag per XML
• Die XML-EuroEilzahlung ist das Nachfolgeprodukt der bisherigen DTE- und EUE-Zahlungen im XML-Format.
• Diese Zahlungen werden mit gleichtägiger Valuta als Einzelzahlung an die Bank des Begünstigten
via TARGET übertragen.
• Es ist keine Sammler-Zahlung aus dem Massenzahlungsverkehr, sondern eine Individual-Zahlung
und fällt daher nicht unter die SEPA-Produkte.
• Eilzahlungen (XML-Variante für die bisherigen DTE-Zahlungen) können mit der Auftragsart CCU im
pain.001.003.03 und dem Service-Level „URGP“ übertragen werden. Die HVB nimmt bereits vor der
deutschlandweiten Einführung im pain.001.002.03 und pain.001.001.03 entsprechende Eilzahlungen
entgegen. Hierzu sind besondere Feldbelegungen nötig, um alle relevanten Informationen an den Empfänger weiterzuleiten. Felder wie CategoryPurpose, Debtor-ID, UltimateDebtor, Creditor-ID, und UltimateCreditor
können nicht weitergeleitet werden, Felder wie PurposeCode und End2End-ID werden von der HVB in den
Verwendungszweck gestellt.
Die Produktbroschüre und weitere Detailbeschreibungen zur Feldbelegung erhalten Sie bei Ihrem
Cash Management & eBanking-Spezialisten. Siehe auch Kapitel „Taggleiche Eilüberweisungen via pain.001“.
<SvcLvl>
<Cd>URGP</Cd>
</SvcLvl>
8
• IBAN-Only bzw. optionaler BIC
• Die Angabe des BICs wird zum 01.02.2014 optional für Zahlungen innerhalb Deutschlands. Da das DFÜAbkommen Anlage 3 schon für den November 2013 angepasst wird und nicht noch einmal im Februar 2014,
sind die Änderungen bereits hier eingearbeitet. Des Weiteren bietet die HVB ihren Kunden zusätzliche Möglichkeiten an, IBAN-Only möglichst einfach umzusetzen. Siehe Kapitel „IBAN, IBAN-Only“.
• S onstige Änderungen
•A
ltformate werden ab 2/2014 abgeschafft (z. B. DTA-Überweisung/DTA-Lastschrift),
Ausnahme Kartenzahlungen wie ELV sowie elektronische Schecks und DTE.
•W
egfall der EU-Standardüberweisung (Zahlungsart 13) und Wegfall der AWV-Meldeteile
(Datensätze V/W) im Auslandszahlungsverkehr.
•D
eutsche Umlaute Ä, Ö, Ü, ä, ö, ü, ß und verschiedene Sonderzeichen werden zugelassen.
• F ür vermögenswirksame Leistungen sollen der unstrukturierte Verwendungszweck mit „XXJ/Vertragsnummer“
und Purpose-Code CBFF genutzt werden. Siehe Kapitel „Verwendungszweck/RemittanceInfo“.
•R
ückgabegrund-Liste wird erweitert („CNOR“/„DNOR“, wenn die Bank über das Clearing nicht erreichbar ist)
•W
eitere PurposeCodes für Gehalt („PAYR“ – Payroll – mit GVC 153) und Dauerauftragsgutschrift
(„RINP“ mit GVC 152).
• Wenn ein Lastschriftmandat für eine SEPA-Lastschrift am POS/Kartenterminal aus Kartendaten generiert
wird und der Name des Zahlers nicht verfügbar ist, können als Name auch die Kartendaten mit der Konstante /CDGM (Card Data Generated Mandate), gefolgt von „/Kartennummer/Folgenummer/Verfalldatum(JJMM)“
angegeben werden. Die Kartennummer ist links auf 19 Stellen aufzunullen. Ist die Kartennummer nicht
verfügbar, so ist die PAN zu verwenden.
9
5. Nachrichtentypen-Erkennung
Wie erkennen Sie, um welche Nachricht und welche Version es sich handelt?
Aufbau einer XML-Nachrichtenbezeichnung:
pain.001.003.03
Version
V3 ISO-Stand 2009
Variante
Die Deutsche Kreditwirtschaft
Nachricht/Message-Definition
CustomerCreditTransferInitiation
Geschäftsfeld/Business-Area
Payment Initiation
pain.001.003.03
Business-Area
• „pain“ – PAymentINnitiation
Message-Definition
• 001 – Überweisung – CustomerCreditTransferInitiation
• 008 – Lastschrift – DirectDebitInitiation
• 002 – CustomerPaymentStatusReport (Reject)
• 007 – CustomerPaymentReversal (Lastschriftsstorno)
• 009 bis 012 – Mandatsinitiierung, -änderung, -storno und -akzeptanz
Variante
• 003 – ZKA/DK Version 2.7
• 002 – ZKA/DK Version 2.3–2.6
• 001 – IS0 20022/EPC
Version
• 03 – ISO Version 03/2009
• 02 – ISO Version 09/2006
• 01 – ISO Version 09/2005
• „camt“ – CAshMAnagement
• 052 – BanktoCustomerAccountReport – ZV-Avis MT942-Nachfolger
• 053 – BanktoCustomerStatement – Kontoauszug MT940-Nachfolger
• 054 – BanktoCustomerDebitCreditNotification – Sammler DTI-Nachfolger
• 055 – CustomerPaymentCancellationRequest – Kunden-Rückruf
• 086 – Bank Service Billing – (ehem. TWIST-BSB)
10
in Planung
in Planung
in Planung
Beauftragung einer SEPA Credit Transfer – Kundenformat
Folgende Auftragsarten sind über die Übertragungswege (EBICS/HBCI bzw. FinTS) möglich:
SEPA-Auftragsarten Credit Transfer – DK-Format
Namespace/Schema
SCT 2.7 (2013)
EBICS-mixed
urn:iso:std:iso:20022:tech:xsd:pain.001.003.03
CCT
pain.001.003.03
EBICS-mixed Sonderprozess ohne VEU-Details
XCT
pain.001.003.03
EBICSXML-Container
„urn:conxml:xsd:container.nnn.003.02“
(+urn:iso:std:iso:20022:tech:xsd:pain.001.003.03)
CCC
pain.001.003.03
EBICS-Reject
CRZ (Zip-Datei) oder
CRC (XML-Container)
pain.002.003.03
HBCI-Sammel
–
HKCCM, HKCME
HBCI-Einzel
–
HKCCS, HKCSE
Ältere Versionen des DFÜ-Abkommens werden von der HVB weiterhin akzeptiert:
• DFÜ-Abkommen 2.5/2.6 (2010/2012): pain.001.002.03
• DFÜ-Abkommen 2.4 (2009): pain.001.002.02
DFÜ-Abkommen 2.3 (2008): pain.001.001.02.grp, pain.001.001.02.con und pain.001.001.02
bzw. geliefert nach entsprechender Einlieferung:
Beauftragung einer SEPA Direct Debit – Kundenformat
Folgende Auftragsarten sind über die Übertragungswege (EBICS/HBCI bzw. FinTS) möglich:
SEPA-Auftragsarten Direct Debit
Namespace/Schema
SDD Core
2.7 (2013)
SDD B2B
2.7 (2013)
EBICS-mixed
urn:iso:std:iso:20022:tech:xsd:
pain.008.003.02
CDD
pain.008.003.02
CDB
pain.008.003.02
EBICS-XML-Container
uurn:conxml:xsd:container.nnn.003.02
(+urn:iso:std:iso:20022:tech:xsd:
pain.008.003.02)
CDC
pain.008.003.02
C2C
pain.008.003.02
EBICS-Reject
urn:iso:std:iso:20022:tech:xsd:
pain.002.003.03
CDZ (Zip-Container) oder
CBC (XML-Container)
pain.002.003.03
CDZ (Zip-Datei) oder
CBC (XML-Container)
pain.002.003.03
HBCI-Sammel
–
HKDME
HKBME
Ältere Versionen des DFÜ-Abkommens werden von der HVB weiterhin akzeptiert:
bzw. geliefert nach entsprechender Einlieferung:
Die Reject-Nachrichten (pain.002) werden verwendet, wenn die Rücknachricht vor Settlement,
also vor Buchung, erfolgt. Dazu gehören z. B. Rückgaben wegen Formatfehlern etc.
Weitere Informationen erhalten Sie von Ihrem Cash Management & eBanking-Spezialisten.
11
6. Aufbau der Kundendatei (XML*)
• XML-Container
• nur für deutsche DK-Formate
• optional
• Group Header
• Dieser Block muss vorhanden sein und existiert einmal.
• Er enthält Elemente wie Nachrichten-ID, Erstellungsdatum und -zeit.
• Payment Information (Dateiebene)
• Dieser Block muss mindestens einmal vorkommen und ist wiederholbar.
• Er enthält Elemente, die sich auf die Herkunftsseite der Transaktion beziehen, wie z. B. Auftraggeber
oder Zahlungsart-Informationen und einen oder mehrere Transaction-Information-Blöcke.
• Ebene der logischen Datei für die Auftraggeber-Buchung (als Sammler)
• Transaction Information
• Dieser Block muss pro Payment Information mindestens einmal vorkommen und ist wiederholbar.
• Er enthält u. a. Elemente, die sich auf die Empfängerseite
• Zahlungsempfänger bei der Überweisung bzw.
• Zahler (Zahlungspflichtiger) bei der Lastschrift beziehen.
• Er enthält den Betrag und den Verwendungszweck.
* XML = Extensible Markup Language
Auftragsarten Container sowie Aufbau Datei mit GroupHeader, PaymentInfo und TransactionInfo
DK XML-Container
EBICS-Auftragsart CCC
pain.001.
GroupHeader
InitiatingParty Firma-1
PaymentInfo
Debtor: Konto-1
TransactionInfo
Creditor/EUR
PaymentInfo
Debtor: Konto-2
TransactionInfo
Creditor/EUR
EBICS-Auftragsart CCT (mixed)
pain.001.
GroupHeader
PaymentInfo
Debtor: Konto-1
TransactionInfo
Creditor/EUR
EBICS-Auftragsart CCT (mixed)
pain.001.
GroupHeader
PaymentInfo
Debtor: Konto-3
TransactionInfo
Creditor/EUR
12
pain.001.
GroupHeader
PaymentInfo
Debtor: Konto-3
TransactionInfo
Creditor/EUR
PaymentInfo
Debtor: Konto-2
TransactionInfo
Creditor/EUR
Gruppierung von Dateien und was kann gemischt angeliefert werden?
Die Einreichung von SEPA-Dateien erfolgt als Sammler, hierzu müssen Dateien gebildet werden:
• Je physische Datei (Sendung (z. B. XML-Container)/GroupHeader) getrennt nach
• Produkt (SCT, SDD-Core, SDD-COR1, SDD-B2B, CT-Urgent) <XML-Schema>, <PmtInfId>, <SvcLvl>
und <LclInstrm>, da für jedes Produkt eine eigene Sende-Auftragsart verwendet werden muss
• Je logische Datei (PaymentInfo), insbesondere auch getrennt nach
• Auftraggeber-IBAN
• Fälligkeitstag <ReqdColltnDt> bzw. Ausführungstag <ReqdExctnDt>
• Lastschriftsequenz (First, Recurrent, Final, OneOff) <SeqTp>
• Unterscheidung zwischen SCT und SCT-Preferred (gleichtägiges Clearing) <InstrPrty>
• Sammel-/Einzelbuchung der Einreichung <BtchBookg>
• Anzahl der Sätze bzw. Datei-Größenbeschränkung siehe unten
• In einer logischen Datei können gemischt werden z. B. :
• verschiedene Empfänger bzw. Zahlungspflichtige bei Lastschriften
• verschiedene Beträge <Amt>
• Verwendungszweck <RmtInf>, Zahlungsgründe <Purp>, End-To-End-Referenz <EndToEndId>
• verschiedene Mandatsinformationen bei Lastschriften.
* Das bisherige Inlandszahlungsverkehrsformat DTAUS ist sehr viel kleiner als das XML-Datenformat. Eine
Transaktion ohne Header hat im DTAUS bis zu 622 Bytes, während eine SEPA-Transaktion über 2.100 Bytes
beinhalten kann, hinzu kommen noch die Header-Informationen. Um noch verarbeitungsfähige Dateien zu
erhalten (Filetransfer, Mapping, Validierung und Fehlerrecherche, etc.), empfiehlt es sich, die Gruppierung
nicht zu groß zu machen und auf maximal 100.000 Transaktionen pro Datei (bis zu 210 MB) zu begrenzen.
Prüfung auf Doppelverarbeitung von Dateien
Damit Dateien nicht doppelt verarbeitet werden, prüft die HVB logische Dateien (PaymentInf)
nach folgenden Prinzipien:
• Je Auftraggeber-IBAN
• Zeitraum: 15 Target-Tage
• Ermittelte Gesamtsumme in EUR
• Ermittelte Anzahl Posten
• Produkt (SCT, Basislastschrift, Firmenlastschrift)
• Summe der Prüfziffern (Stelle 3–4) aller Empfänger- bzw. Zahlungspflichtigen-IBANs
13
7. SEPA Credit Transfer (SCT)
Grundlegende Merkmale
• Auftraggeberkonto und Empfängerkonto werden im SEPA-Raum geführt
(Kontoinhaber kann auch außerhalb ansässig sein).
• Transaktionswährung ist immer EUR.
Unterschiede gegenüber Inlandsüberweisung (wird abgelöst zum 01.02.2014)
• Verwendung von IBAN/BIC
• Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen)
• Zusätzliche Zahlungsgründe (PurposeCodes) sind optional möglich.
• Verwendung von On-Behalf/Ultimates ist optional möglich.
• Zusätzliche Referenzierungsmöglichkeiten
• Grenzüberschreitend im SEPA-Raum
Unterschiede gegenüber EU-Standardüberweisung (abgelöst seit 01.04.2012)
• Explizit auch nationale Nutzung
• Kein AWV-Meldeteil im Datensatz vorhanden
• Auch Zahlungen in die Schweiz und nach Monaco
14
Wichtige fachliche XML-Felder für SEPA Credit Transfer
Feldnamen
Beschreibung
pain.001.003.03
Befüllung
DFÜ-Abkommen 2.7
GrpHdr
GroupHeader
Absenderdaten
1 x pro logische Datei
MsgId
(Message-Id)
Einreicher-Referenznummer pro Datei
Pflichtfeld (eindeutig)
Max. 35 Zeichen
CreDtTm
(CreationDateTime)
Datum/Zeit der Dateierstellung
Pflichtfeld
ISO-Date
NbOfTxs
(NumberOfTransactions)
Anzahl aller Einzeltransaktionen
Pflichtfeld
Unbegrenzt
CtrlSum
(ControlSum)
Kontrollsumme in Euro der Einreichung
Empfohlen
Unbegrenzt
InitgPty-Nm
(InitiatingPartyName)
Name Einreicher (kann vom Namen des
Auftraggebers abweichen)
Pflichtfeld
Max. 70 Zeichen
25–26
InitgPty-Nm-Id-OrgId/
PrvtId
(InitiatingPartyOrganisation-Id/Private-ID)
Identification
DK nicht empfohlen
Diverse
31
PaymentInstructionInformation
Auftraggeberdaten
beliebig oft möglich,
empfohlen max. 100
PmtInfId
(PaymentInformation-ID)
Referenz der Einreichung
Pflicht
Max. 35 Zeichen
PmtInf
Näheres
siehe Seite
12–13
38–39,
41–42
12–13
38–39,
41–42
PmtMtd (PaymentMethod)
Zahlungsinstrument: Credit Transfer
Pflicht
„TRF“
BtchBookg
(BatchBooking)
Auftraggeberbuchung
Sammler/Einzelsatz
Optional, in Stammdaten
administriert
„false“ – Einzelbuchung
„true“ – Sammelbuchung
NbOfTxs
Empfohlen
Unbegrenzt
CtrlSum
(ControlSum)
Kontrollsumme in Euro der
logischen Datei
Empfohlen
Unbegrenzt
InstrPrty
(InstructedPriority)
Priorität der Ausführung:
„high“ oder „norm“
administriert
„HIGH“ – SCT Preferred
„NORM“ – SCT Normal
40
SvcLvl-Cd
(ServiceLevelCode)
Service Schema
Pflicht
„SEPA“, „URGP“
(siehe Kap. 13)
8, 40, 60
CtgyPurp
(CategoryPurpose)
Zahlungsart der Datei
administriert
Für gleichtägige
Gehaltszahlung „SALA“
25, 40
ReqdExctnDt
Gewünschter Ausführungstermin
(RequestedExecution Date)
Pflichtfeld
ISO-Date
Dbtr-Nm
(DebtorName)
Name Auftraggeber. Ggf. von Bank mit
Kontoinhaber überschrieben
Pflichtfeld
Max. 70 Zeichen
25–26
Dbtr-PstlAdr-Ctry
(DebtorCountry)
Land der Anschrift des Auftraggebers
Optional
Ländercode ISO 3166,
DE für Deutschland
26
Dbtr-PstlAdr-AdrLine
(DebtorAddress)
Anschrift Auftraggeber. Ggf. von Bank
mit Kontoadresse überschrieben
Optional
Max. 2x70 Zeichen
26
Dbtr-Id-OrgId/PrvtId
(DebtorOrganisation-Id/
Private-ID)
Identification
DK nicht empfohlen
Diverse
31, 41
DbtrAcct-IBAN
(DebtorIBAN)
IBAN des Auftraggebers
Pflichtfeld
Max. 34 Zeichen
9, 27–29,
38–39
DbtrAcct-Ccy
(DebtorAccountCurrency)
Währung des Auftraggeberkontos
Optional
Währungscode
DbtrAgt-BIC
(DebtorAgentBIC)
BIC/SWIFT-Code des Auftraggebers
Optional bei DE-Banken (IBANOnly),
sonst Pflichtfeld
8 bzw. 11 Stellen
9, 29,
38–39
DbtrAgt-Othr-Id
(DebtorAgentId)
Kennzeichnung IBAN-Only
Optional, bei Nutzung von
IBAN-Only für Deutschland
„NOTPROVIDED“
29
UltmtDbtr
(UltimateDebtorName)
Vom Kontoinhaber abweichender
Auftraggeber. Rein informatorischer
Charakter
Optional
Max. 70 Zeichen
7, 25–26,
32, 40
UltmtDbtr-Id-OrgId-Othr
(UltimateDebtor-IBAN)
Ultimate Einreicherbelastungs-IBAN
Optional, nur wenn Produkt
„Ultimate Auftraggeber“
Max. 34 Zeichen
27–28, 32,
38-39
ChrgBr (ChargeBearer)
Preis-Verrechnung immer shared
Empfohlen
„SLEV“
40
44–45
15
Fortsetzung
Feldnamen
Beschreibung
pain.001.003.03
Befüllung
DFÜ-Abkommen 2.7
Näheres
siehe Seite
CdtTrfTxInf
CreditTransferTransaction-Information
Transaktions-Information
beliebig oft möglich, empfohlen
max. 100.000
12–13
InstrId
(Instruction-ID)
Technische Referenz zwischen
Einreicher und Bank
Optional, wenn gefüllt: eindeutig
Max. 35 Zeichen
38–39,
41–42
EndToEndID
(End2End-ID)
Referenz, wird bis Begünstigten
durchgereicht
Pflichtfeld
(eindeutig, sonst: „NOTPROVIDED“)
Max. 35 Zeichen
38–39,
41–43
InstrAmt
(Instructed Amount)
Betrag und Währungskennzeichen
Pflichtfeld
Nur Euro erlaubt
UltmtDbtr
(UltimateDebtor)
Abweichender Auftraggeber
Optional. Nicht, wenn auf
PmtInf-Ebene schon gefüllt
Max. 70 Zeichen
7, 25–26,
32, 40
UltmtDbtr-Id-OrgId/PrvtId
(UltimateDebtorOrganisation-Id/Private-ID)
Identification
DK nicht empfohlen
Diverse
31, 40–41
CdtrAgt-BIC
(CreditorAgentBIC)
BIC/SWIFT-Code der Begünstigten-Bank
Optional bei DE-Banken
(IBAN-Only), sonst Pflichtfeld
8 bzw. 11 Stellen.
Zusätzlich bei HVB:
„NOTPROVIDED“, „NOTAVAIL“
9, 29,
38–39
Cdtr-Nm
(CreditorName)
Name Begünstigter
Pflichtfeld
Max. 70 Zeichen
25–26
Cdtr-PstlAdr-Ctry
(CreditorCountry)
Land der Anschrift des Begünstigten
Optional
DE für Deutschland
26
Cdtr-PstlAdr-AdrLine
(CreditorAddress)
Anschrift Begünstigter
Optional
Max. 2x70 Zeichen
26
Cdtr-Id-OrgId/PrvtId
(CreditorOrganisation-Id/
Private-ID)
Identification
DK nicht empfohlen
Diverse
31
CdtrAcct-IBAN
(CreditorIBAN)
IBAN des Begünstigten
Pflichtfeld
Max. 34 Zeichen
9, 27–29,
38-39
UltmtCdtr
(UltimateCreditorName)
Abweichender Endbegünstigter.
Rein informatorischer Charakter
Optional
Max. 70 Zeichen
7, 25–26,
32, 40
UltmtCdtr-Id-OrgId/PrvtId
(UltimateCreditorOrganisation-Id/Private-ID)
Identification
DK nicht empfohlen
Diverse
31, 40–41
Purp
(Purpose)
Art der Zahlung (Textschlüssel), z. B.
SALA (Salary) bei Gehaltszahlung
Optional
ISO 20022
„ExternalPurposeCodeListe“
7, 24, 54
Ustrd-RmtInf
(UnstructuredRemittanceInfo)
Unstrukturierter Verwendungszweck
Empfohlen
Max. 140 Zeichen
22, 40
Strd-CdtrRefInfCdtrRefTp-Cd
(StructuredCreditor
Reference-Code)
Strukturierter Verwendungszweck für
CreditorReference
Nur wenn kein unstrukturierter
Verwendungszweck
„SCOR“
23, 40
Strd-CdtrRefInf-CdtrRef
(StructuredCreditor
Reference)
Strukturierter Verwendungszweck Teil 2
CreditorReference: prüfzifferngerechte
CreditorReference
Nur wenn kein unstrukturierter
Verwendungszweck
„RF“+Prüfziffer+Reference
(ISO 11649)
Max. 35 Zeichen
23, 40
Nicht angegeben sind rein technische Felder oder Felder, die in Deutschland möglich, aber von den Banken nicht empfohlen sind
(z. B. OrgID, weitere strukturierte Verwendungszwecke). Details und Angabe aller Felder finden Sie im DFÜ-Abkommen
„Spezifikation der Datenformate“.
16
8. Beispiel einer Kundendatei
GroupHeader
<?xml version=“1.0“ encoding=“UTF-8“?>
– <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.003.03"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.003.03 pain.001.003.03.xsd">
– <CstmrCdtTrfInitn>
– <GrpHdr>
<MsgId>20121118-105506</MsgId>
<CreDtTm>2012-11-18T10:55:06</CreDtTm>
<NbOfTxs>1</NbOfTxs>
– <InitgPty>
<Nm>MEIER PAYMENT MUENCHEN</Nm>
</InitgPty>
</GrpHdr>
Beschreibung
DTAUS-Feld
• XML-Schema und XSD Location
• GroupHeader
• MessageID – eindeutige Referenz der Datei
• Creation – Date/Time
• NumberOf-Transactions –
• optional Gesamtsumme EUR über alle logischen Dateien
• Name Initiating Party (z. B. DATEV)
(~DTA-A7)
(DTA-A6)
PaymentInformation – logische Datei
– <PmtInf>
<PmtInfId>PAYMENT-20110318-105506</PmtInfId>
<PmtMtd>TRF</PmtMtd>
<BtchBookg>true</BtchBookg>
<NbOfTxs>1</NbOfTxs>
<CtrlSum>1234.56</CtrlSum>
– <PmtTpInf>
<InstrPrty>HIGH</InstrPrty>
– <SvcLvl>
<Cd>SEPA</Cd>
<SvcLvl>
– <CtgyPurp>
<Cd>SALA</Cd>
</CtgyPurp>
</PmtTpInf>
<ReqdExctnDt>2012-11-19</ReqdExctnDt>
– <Dbtr>
<Nm>MEIER CORNELIA MUENCHEN</Nm>
</Dbtr>
– <DbtrAcct>
– <Id>
<IBAN>DE67700202700064535072</IBAN>
<Id>
</DbtrAcct>
– <DbtrAgt>
– <FinInstnId>
<BIC>HYVEDEMMXXX</BIC>
</FinInstnId>
</DbtrAgt>
– <UltmtDbtr>
<Nm>MEIER GEHALTSABTEILUNG</Nm>
</UltmtDbtr>
<ChrgBr>SLEV</ChrgBr>
• PaymentInfID – eindeutige Referenz der log. Datei
• PaymentMethode: Transfer
• Batchbooking – True/False – Sammler/Einzelbuchung
• Anzahl Posten
• Summe EUR
• Priority NORM/HIGH (SCT-Preferred)
(~DTA-A10)
(DTA-E4)
(DTA-E8)
„ServiceLevel“ „SEPA“
• Category-Purpose „SALA“ – gleichtägig beim Empfänger
auch bei nach Cut-off
• Ausführungstag
(DTA-A11b)
• Auftraggeber Name (ggf. mit Adresse)
(DTA-C15)
• Auftraggeber-IBAN
(~DTA-C11)
• Auftraggeber-BIC
(~DTA-C10)
• Ultimate Auftraggebername
• SLEV = Shared bei SEPA
CreditTransferTransaction – Einzeltransaktion
– <CdtTrfTxInf>
– <PmtId>
<EndToEndId>OriginatorID1234</EndToEndId>
</PmtId>
– <Amt>
<InstdAmt Ccy="EUR">1234.56</InstdAmt>
</Amt>
– <CdtrAgt>
– <FinInstnId>
</FinInstnId>
</CdtrAgt>
– <Cdtr>
<Nm>Creditor Name</Nm>
</Cdtr>
– <CdtrAcct>
– <Id>
<IBAN>DE21500500009876543210</IBAN>
</Id>
</CdtrAcct>
– <Purp>
<Cd>PENS</Cd>
</Purp>
– <RmtInf>
<Ustrd>Unstructured Remittance Information</Ustrd>
</RmtInf>
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>
• End2End-Id – Referenz der Zahlung aus Sicht
des Auftraggebers
• Betrag in EUR
(DTA-C12)
• Creditor – Empfänger-BIC
(~DTA-C4)
• Empfängername
(DTA-C14a + Erw)
• Empfänger-IBAN
(~DTA-C5)
• Purpose – Textschlüssel der Zahlung
siehe ISO 20022 external Code list
(~DTA-C7a)
• Remittance-Info – Verwendungszweck 140 Stellen
(~DTA-C16 + Erw)
17
9. SEPA Direct Debit (SDD)
Grundlegende Merkmale
• SEPA-Basislastschrift (SDD-Core)
• ähnlich der Inlands-Einzugsermächtigungs-Lastschrift
• SEPA-Firmenlastschrift (SDD-B2B)
• ähnlich der Inlands-Abbuchungsauftrags-Lastschrift
•M
andat muss zum Abgleich auch bei der Debitorbank vorliegen.
Unterschiede gegenüber Inlandslastschrift (wird abgelöst zum 01.02.2014)
• Angabe der Gläubiger-Identifikationsnummer (vergeben von der Bundesbank)
• Mitgabe von Mandatsinformationen (Mandats-ID und Mandatsunterschriftsdatum)
• Mitgabe von prozessrelevanten Angaben (Sequenz der Einreichung, Fälligkeitstag
mit entsprechenden Vorlaufeinreichungstagen)
• Verwendung von IBAN/BIC
• Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen)
• Zusätzliche Zahlungsgründe (PurposeCodes) sind optional möglich.
• Verwendung von On-Behalf/Ultimates ist möglich.
• Zusätzliche Referenzierungsmöglichkeiten
• Grenzüberschreitende Nutzung im SEPA-Raum
Wichtige fachliche XML-Felder für SEPA Direct Debit
Feldnamen
Beschreibung
pain.008.003.02
Befüllung
DFÜ-Abkommen 2.7
GrpHdr
GroupHeader
Absenderdaten
MsgId
(Message-ID)
Einreicher-Referenznummer
pro Datei
Max. 35 Zeichen
CreDtTm
(CreationDateTime)
Pflichtfeld
ISO-Date
NbOfTxs
Pflichtfeld
Unbegrenzt
CtrlSum
(ControlSum)
Einreichung
Empfohlen
Unbegrenzt
InitgPty-Nm
(InitiatingPartyName)
Name Einreicher (kann abweichen
von Auftraggebernamen)
Pflichtfeld
Max. 70 Zeichen
25–26
InitgPty-Nm-Id-OrgId/
PrvtId
(InitiatingPartyOrganisation-ID/Private-ID)
Identification
DK nicht empfohlen
Diverse
31
Zahlungsempfänger-Daten
empfohlen max. 100
PmtInfId
(PaymentInformationID)
Pflichtfeld
Max. 35 Zeichen
PmtMtd
(PaymentMethod)
Zahlungsinstrument: Direct Debit
Pflichtfeld
„DD“
BtchBookg
(BatchBooking)
Auftraggeberbuchung Sammler/
Einzelsatz
Optional, wenn administriert in Stammdaten
„true“-Sammelbuchung
„false“-Einzelsatzbuchung
NbOfTxs
(NumberOfTransactions
Empfohlen
Unbegrenzt
PmtInf
18
Inhalt des
papierhaften
Mandats
Näheres
siehe
Seite
12–13
38–39,
41–42
12–13
38–39,
41–42
44–45
Fortsetzung
Feldnamen
Beschreibung
pain.008.003.02
Befüllung
DFÜ-Abkommen 2.7
Inhalt des
papierhaften
Mandats
CtrlSum
(ControlSum)
logischen Datei
Empfohlen
Unbegrenzt
SvcLvl-Cd
(ServiceLevelCode)
Service Schema
Pflicht
„SEPA“
40
LclInstrm-Cd
(LocalInstrumentCode)
Lastschriftart: normale SEPA-CoreBasislastschrift oder SEPA-B2BFirmenlastschrift
Pflichtfeld (innerhalb
GrpHdr nicht mischbar)
„CORE“, „COR1“ oder
„B2B“
7–8, 36, 40
SeqTp
(SequenceType)
Sequenz: Erst-, Folge-, Einmal- oder
letztmalige Lastschrift
Pflichtfeld
„FRST“, „RCUR“, „OOFF“
oder „FNAL“
CtgyPurp
(CategoryPurpose)
Optional
Nicht zur Weitergabe an
Endkunden
25, 40
ReqdColltnDt
(RequestedCollectionDate)
Fälligkeitsdatum der Lastschrift
(Datum der Belastung auf Kto. des
Bezogenen)
Pflichtfeld
ISO-Date
36
Cdtr-Nm
(CreditorName)
Name Zahlungsempfänger. Ggf. von
Bank mit Kontoinhaber überschrieben
Pflichtfeld
Max. 70 Zeichen
Pflicht
25–26
Cdtr-PstlAdr-Ctry
(CreditorCountry)
Land der Anschrift des Zahlungsempfängers
Optional
DE für Deutschland
Pflicht
26
(CreditorAddress)
Anschrift Zahlungsempfänger.
Ggf. von Bank mit Kontoadresse
überschrieben
Optional
Max. 2x70 Zeichen
Pflicht
26
CdtrAcct-IBAN
(CreditorIBAN)
IBAN des Zahlungsempfängers
Pflichtfeld
Max. 34 Zeichen
CdtrAcct-Ccy
(CreditorAccount
Currency)
Kontowährung: muss EUR sein
Optional
„EUR“
CdtrAgt-BIC
(CreditorBIC)
BIC/SWIFT-Code des Zahlungsempfängers
(IBAN-Only),
sonst Pflichtfeld
8 bzw. 11 Stellen
9, 29,
38–39
CtrAgt-Othr-Id
(CreditorAgentID)
Optional, bei Nutzung
von IBAN-Only für
Deutschland
„NOTPROVIDED“
29
UltmtCdtr
(UltimateCreditor)
Vom Kontoinhaber abweichender
Zahlungsempfänger. Rein informatorischer Charakter
Optional
Max. 70 Zeichen
UltmtCdtr-Id--OrgIdOthr
(UltimateCreditorIBAN)
Ultimate Einreicher-GutschriftsIBAN
Optional, nur wenn
Produkt „Ultimate
Auftraggeber“
Max. 34 Zeichen
27–28, 32,
38–39
UltmtCdtr-Id-OrgId/
PrvtId
(UltimateCreditorOrganisation-ID/Private-ID)
Identification
DK nicht empfohlen
Diverse
31, 40–41
ChrgBr
(ChargeBearer)
Preis-Verrechnung immer shared
Empfohlen
„SLEV“
40
CdtrSchmeId-Id-PrvtIdOthrId-Id
(CreditorIdentification)
CreditorIdentification. Eindeutiges
Identifikationsmerkmal des
Zahlungsempfängers
(per legal entity)
Pflichtfeld, entweder auf
PmtInf-Ebene oder auf
Transaction-Ebene immer
gleich (empfohlen)
Max. 35 Zeichen
Pflicht
(wiederkehrend
oder einmalig)
Näheres
siehe
Seite
34–37
9, 27–29,
38-39
Optional
Pflicht
7, 25–26,
32, 40
30, 33,
40–42
19
Fortsetzung
20
Feldnamen
Beschreibung
pain.008.003.02
Befüllung
DFÜ-Abkommen 2.7
Inhalt des
papierhaften
Mandats
Näheres
siehe
Seite
Drct
Direct Debit TransacDrctDbtTxInf tion-Information
empfohlen max. 100.000
InstrId
(Instruction-ID)
Technische Referenz zwischen
Einreicher und Bank
Optional, wenn gefüllt:
eindeutig
Max. 35 Zeichen
38–39,
41–42
EndToEndID
(End2End-ID)
Referenz, wird bis Zahlungspflichtigen durchgereicht
Pflichtfeld (eindeutig,
sonst: „NOTPROVIDED“)
Max. 35 Zeichen
38–39,
41–43
InstrAmt
(Instructed Amount)
Pflichtfeld
Nur Euro erlaubt
Mndtld
(MandateID)
Eindeutige Mandatsreferenz
Pflichtfeld
Max. 35 Zeichen
kann nachgeliefert werden
DtOfSgntr
(DateOfSignature)
Datum, zu dem das Mandat
unterschrieben wurde bzw. über
die Mandatsumdeutung informiert
wurde
Pflichtfeld
ISO-Date
Pflicht, im Papiermandat auch Ort
der Unterschrift
und Unterschrift
AmdmntInd
(AmendmentIndicator)
Kennzeichen, ob das Mandat
verändert wurde
Optional
Veränderung = „true“
Standard = „false“
33–35
OrgnlMndtId
(OriginalMandateID)
Eindeutige Referenz des ursprünglichen Mandats, falls sich die
Mandatsreferenz (MndtId)
geändert hat
Nur bei Mandatsveränderung
(AmdmntInd = true)
Max. 35 Zeichen
33–35,
38–39,
41–43
OrgnlCdtrSchmeId-Nm
(OriginalCreditorName)
Ursprünglicher Creditor-Name,
falls sich der Zahlungsempfänger
geändert hat
(AmdmntInd = true)
Max. 70 Zeichen
33–35
OrgnlCdtrSchmeId-IdPrvtId-OthrId-Id
(OriginalCreditorIdentification)
Ursprüngliche CreditorIdentification, falls sich die CreditorIdentification (CdtrSchmeIdI)
geändert hat
(AmdmntInd = true)
Max. 35 Zeichen
30, 33–35,
41–42
OrgnlDbtrAcct-IBAN
(OriginalDebtorIBAN)
Ursprüngliche IBAN des Zahlungspflichtigen, falls sich die IBAN
geändert hat
(AmdmntInd = true)
Max. 34 Zeichen
27–29,
33–35
38–39
OrgnlDbtrAgt-Id
(OrignalDebtorAgentID)
Ursprüngliche Debtorbank hat
sich geändert. Neueinreichung mit
Sequenz „FRST“ nötig
(AmdmntInd = true)
Kennzeichen „SMNDA“
33–35, 37
ElctmcSgntr
(ElectronicSignature)
Elektronisches Mandat eMandate –
elektronische Signatur
Optional. Nicht für
papierhafte Mandate
Max. 1.025 Zeichen; erst
mit eMandate relevant
CdtrSchmeId-Id-PrvtIdOthrId-Id
(CreditorIdentification)
CreditorIdentification. Eindeutiges
Identifikationsmerkmal des
Zahlungsempfängers
(per legal entity)
Pflichtfeld, entweder auf
PmtInf-Ebene oder auf
Transaction-Ebene immer
gleich
Max. 35 Zeichen
30, 33,
40–42
UltmtCdtr
(UltimateCreditorName)
Name abweichender
Zahlungsempfänger
Optional. Nicht, wenn auf
PmtInf-Ebene schon gefüllt
Max. 70 Zeichen
7, 25–26,
32, 40
UltmtCdtr-Id-OrgId/
PrvtId
(UltimateCreditorOrganisation-ID/Private-ID)
Identification
DK nicht empfohlen
Diverse
31, 40–41
DbtrAgt-BIC
(DebtorAgentBIC)
BIC/SWIFT-Code der
Zahlungspflichtigen-Bank
(= Bank des Zahlungspflichtigen)
(IBAN-Only),
sonst Pflichtfeld
8 bzw. 11 Stellen.
Zusätzlich bei HVB:
„NOTPROVIDED“,
„NOTAVAIL“
DbtrAgt-Othr-Id
(DebtorAgentID)
von IBAN-Only für
Deutschland
„NOTPROVIDED“
12–13
Optional bei
DE-Banken
(IBAN-Only),
sonst Pflichtfeld
38–39,
41–43
9, 29,
38–39
29
Fortsetzung
Feldnamen
Beschreibung
pain.008.003.02
Befüllung
DFÜ-Abkommen 2.7
Inhalt des
papierhaften
Mandats
Näheres
siehe
Seite
Dbtr-Nm
(DebtorName)
Name Zahlungspflichtiger
Pflichtfeld*
Max. 70 Zeichen
Dbtr-PstlAdr-Ctry
(DebtorCountry)
Land der Anschrift des
Zahlungspflichtigen
Optional
DE für Deutschland
Optional ab
Feb. 2014
26
(DebtorAddress)
Anschrift Zahlungspflichtiger
Optional
Max. 2 x 70 Zeichen
Optional ab
Feb. 2014
26
Dbtr-Id-OrgId/PrvtId
(DebtorOrganisationId/Private-ID)
Identification
DK nicht empfohlen
Diverse
DbtrAcct-IBAN
(DebtorIBAN)
IBAN des Zahlungspflichtigen
Pflichtfeld
Max. 34 Zeichen
Pflicht
9, 27–29,
38-39
UltmtDbtr
(UltimateDebtor)
Name abweichender Zahlungspflichtiger. Rein informatorischer
Charakter
Optional
Max. 70 Zeichen
Optional
7, 25–26,
32, 40
UltmtDbtr-Id-OrgId/
PrvdtId
(UltimateDebtorOrganisation-ID/Private-ID)
Identification
DK nicht empfohlen
Diverse
31, 40–41
Purp
(Purpose)
Art der Zahlung (Textschlüssel). Im
Kontoauszug MT940/942 werden
nicht alle Codes dargestellt.
Optional
ISO 20022
„ExternalPurposeCodeListe“
7, 24, 54
Ustrd-RmtInf
(Unstructured
RemittanceInfo)
Empfohlen
Max. 140 Zeichen
(StructuredCreditor
Reference-Code)
Strukturierter Verwendungszweck
DK nicht empfohlen
„SCOR“
23, 40
Strd-CdtrRefInf-Cdtr
Ref (StructuredCreditor
Reference)
Teil 2
DK nicht empfohlen
Max. 35 Zeichen
23, 40
9, 25–26
31, 41
Optional
(Vertragsnummer
und Beschreibung)
22, 40
*W
enn ein Lastschriftmandat für eine SEPA-Lastschrift am POS/Kartenterminal aus Kartendaten generiert wird und der Name des
Zahlers nicht verfügbar ist, können als Name auch die Kartendaten mit der Konstante /CDGM (Card Data Generated Mandate),
gefolgt von „/Kartennummer/Folgenummer/Verfalldatum(JJMM)“ angegeben werden. Die Kartennummer ist links auf 19 Stellen
aufzunullen. Ist die Kartennummer nicht verfügbar, so ist die PAN zu verwenden.
21
10. S EPA – häufig genutzte
Zahlungsinformationen im Format
10.1 Verwendungszweck
Verwendungszweck <RmtInf>
• Der Verwendungszweck hat bei SEPA nur 140 Stellen. Im DTAUS-Inlandszahlungsverkehr sind dagegen
bis 14 x 27 Zeichen (= 378 Stellen) möglich.
• In Ergänzung zu dem Verwendungszweck können bei SEPA allerdings noch ein strukturierter Purpose <Purp>
und eine Detaillierung der beteiligten Parteien (Adresse und Identifikationsnummern) sowie die End-To-EndReferenz mit 35 Stellen vorgenommen werden.
<RmtInf>
<Ustrd>1234567890123456789012345678901234567890123456789012345678
9012345678901234567890123456789012345678901234567890123456789012
345678901234567890</Ustrd>
</RmtInf>
Vermögenswirksame Leistungen (VL-Zahlungen)
• Im Falle von vermögenswirksamen Leistungen (VL) wird hier „XXJ/Vertragsnummer“ eingetragen, wobei XX
entweder 00 oder durch den Prozentsatz der Sparzulage ersetzt wird und der Buchstabe J durch die letzte
Ziffer des Leistungsjahres. Der Name des VL-Empfängers kann ggf. im Datenelement „Ultimate Creditor“
hinterlegt werden. Des Weiteren muss als Purpose Code CBFF gesetzt werden.
<Purp>
<Cd>CBFF</Cd>
</Purp>
<RmtInf>
<Ustrd>
003/ABC123456
</Ustrd>
</RmtInf>
22
Strukturierter Verwendungszweck <RmtInf> <Strd>
Strukturierte Creditor-Referenz <CdtrRefInf>
• Belege mit prüfzifferngerechten Verwendungszwecken gibt es analog den BZÜ-Belegen im Inlandszahlungsverkehr, auch in SEPA. Sie werden bei SEPA CreditorReference genannt nach ISO 11649, beginnend mit „RF“
und dann gefolgt von 21 alphanumerischen Stellen. Berechnet wird die CreditorReference mit Modulus 97.
• In SEPA ist nur der strukturierte Verwendungszweck mit dem Codewort SCOR zugelassen.
• Wenn die Prüfziffer nicht korrekt ist, wird die Referenz in den unstrukturierten Verwendungszweck überführt.
• Im papierhaften und elektronischen Kontoauszug MT940 wird die Struktur grundsätzlich nicht mitgegeben,
sondern einfach nur der Inhalt ohne Tags, z. B. „SCOR RF98123456789012345678901“. Im neuen camt.05x
wird die Struktur durchgeleitet.
<RmtInf>
<Strd>
<CdtrRefInf>
<Tp>
<CdOrPrtry>
<Cd>SCOR</Cd>
</CdOrPrtry>
</Tp>
<Ref>RF98123456789012345678901</Ref>
</CdtrRefInf>
</Strd>
</RmtInf>
23
10.2 Zahlungsgrund: Purpose Code <Purp>
• Die strukturierte Information über den Zahlungsgrund pro Zahlung, z. B. Spende oder Gehalt, wird
über den Purpose Code in SEPA abgebildet.
• Der Purpose Code geht grundsätzlich an die Empfänger-Bank und deren End-Empfänger.
• Er kann zu unterschiedlichen Geschäftsvorfall-Codes (GVC) im elektronischen Auszug führen.
• Die Zahlungsgründe sind aufgeführt in www.iso20022.org/external_code_list.page im Reiter „11-Purpose“.
<CdtTrfTxInf>
...
<Purp>
<Cd>PENS</Cd>
</Purp>
</CdtTrfTxInf>
24
PurposeCode Auszug
Erklärung
ADVA
Spezieller Geschäftsvorfall-Code für elektronischen Auszug bzw.
Anmerkungen
PurposeCode Auszug
Erklärung
Vorabzahlung
HSPC
Krankenhausbehandlung
AGRT
Landwirtschaft
INPC
Autoversicherung
AIRB
Luftverkehr
INSM
Ratenzahlung
ALMY
Alimente und Unterhalt
INSU
Versicherung
BECH
Kindergeld
INTC
Intra-Company Übertrag
BENE
Arbeitslosengeld
INTE
Zinsen
BLDM
Gebäudepflege
INTX
Einkommensteuer
BONU
Bonuszahlung
LBRI
Berufsversicherung
BUSB
Busverkehr
LICF
Lizenzkosten
CASH
Cash Management
LIFI
Lebensversicherung
CBFF
Vermögenswirksame
Leistung
LOAN
Kreditzahlung
MDCS
Medizinische Dienste
NWCM
Netzwerkkommunikation
PAYR
Lohn/Gehaltszahlung
GVC Haben 153 (ab DFÜ 2.7)
PENS
Pensions- und Rentenzahlung
GVC Haben 153
GVC Haben 156
GVC Haben 153
GVC Haben 154
CBTV
Kabelfernsehen
CDBL
Kreditkartenabrechnung
CFEE
Stornogebühr
CHAR
Spende
CLPR
Autokredit
PHON
Telefon
COMM
Kommissionszahlung
PPTI
COST
Kosten allgemein
Haus/Grundstücksversicherung
CSLP
Sozialversicherungsabgaben
RINP
Dauerauftragsgutschrift
RLWY
Bahnverkehr
DCRD
Debitkartenzahlung
SALA
Lohn/Gehaltszahlung
DNTS
Zahnarzt-Service
SAVG
Sparerzahlung
ELEC
Stromrechnung
SCVE
ENRG
Energie
Dienstleistungen
allgemein
ESTX
Grundsteuer
SSBE
Sozialleistungen
GASB
Gasrechnung
STDY
Bildung und Unterricht
GDDS
Warenkauf/Verkauf
SUPP
Lieferantenzahlung
GOVI
Staatliche Versicherung
TAXS
Steuerzahlung
GOVT
Zahlung an/von öffentlichen Kassen
TELI
Laut Telefonauftrag
TRAD
Handelsgeschäft
GWLT
Kriegsversehrtenzahlung
VATX
Mehrwertsteuer
HLTC
Gesundheits-Service
WEBI
Laut Auftrag im Internet
HLTI
Krankenversicherung
WTER
Wasser
GVC Soll 119, Haben 169
GVC Haben 156
Spezieller Geschäftsvorfall-Code für elektronischen Auszug bzw.
Anmerkungen
GVC Haben 152 (ab DFÜ 2.7)
GVC Haben 153
GVC Haben 156
10.3 Produktkategorie: Category Purpose <CtgyPurp>
• Der Category Purpose ist eine Anweisung des Einreichers an die Einreicher-Bank.
• Er gilt eine besondere Verarbeitung der Aufträge/der Datei, z. B. mit einer Priorisierung oder Sonderkonditionen.
• Gilt für Datei oder je Zahlung
• Die Information geht nicht an die Empfänger-Bank.
• Es ist eine bilaterale Vereinbarung über Nutzung mit der Bank erforderlich.
• Bei HVB wird derzeit nur „SALA“ (gleichtägige Gehaltszahlungen) auf Dateiebene verwendet. Weitere
Informationen zum Produkt können Sie auch unserem Spezialflyer „Credit Transfer Preferred“ entnehmen.
<PmtInfId>
...
<PmtTpInf>
...
<CtgyPurp>
<Cd>SALA</Cd>
</CtgyPurp>
</PmtTpInf>
...
</PmtInfId>
10.4 Fünf Beteiligte in einer SEPA-Nachricht
Auftraggeber und Empfänger bzw. Zahlungspflichtiger erscheinen in den verschiedenen Ebenen eines SEPAAuftrags bzw. einer Dateieinreichung. Über die Felder Ultimate kann zusätzlich ein abweichender Auftraggeber
und Zahlungsempfänger bzw. -pflichtiger mitgegeben werden.
Beispiel SEPA-Überweisung
GroupHeader
InitiatingParty (Einreicher)
Name (70 Stellen)
PaymentInf – Dateiebene
Debitor (Auftraggeber)
IBAN/BIC (Auftraggeber)
Adresse (2 x 70 Stellen zzgl. Ländercode)*
Organisationsnummer
Personenidentifikation
UltimateDebitor
Transaktion
Creditor (Empfänger)
IBAN/BIC (Empfänger)
Pflichtangabe
Optional
UltimateCreditor
* Adresse nicht möglich bei Initiating Party und den Ultimates
25
Beispiel SEPA-Lastschrift
GroupHeader
InitiatingParty (Einreicher)
PaymentInf – Dateiebene
Creditor (Auftraggeber)
Gläubiger-ID (Creditor)
IBAN/BIC (Creditor)
Name (70 Stellen)
Adresse (2 x 70 Stellen zzgl. Ländercode)*
Organisationsnummer**
Personenidentifikation**
UltimateCreditor
Transaktion
Debitor (Zahlungspflichtiger)
IBAN/BIC (Zahlungspflichtiger)
Pflichtangabe
UltimateDebitor
Optional
* Adresse nicht möglich bei Initiating Party und den Ultimates
** OrgID & PrivId nicht möglich bei Creditor
10.5 Name, Adresse
• In der SEPA-Nachricht gibt es fünf mögliche Beteiligte (Debtor, Creditor, InitiatingParty, Ultimate Creditor
und Ultimate Debtor)
• Der jeweilige Name <Nm> der Beteiligten wird immer mit bis zu 70 Stellen angegeben.
• Optional können bei Debtor und Creditor noch Adressen <PstlAdr> mitgegeben werden. Hierzu sind
2 x 70 Stellen der unstrukturierten Adresse <AdrLine> zu verwenden zuzüglich dem Ländercode <Ctry>.
• Der Auftraggebername und die -adresse (bei grenzüberschreitenden Zahlungen) müssen aufgrund der Auftraggeberdatenverordnung korrekt mitgeliefert werden. Die HVB füllt diese automatisch mit den Kontostammdaten.
<Nm>ABC Handels GmbH</Nm>
<PstlAdr>
<Ctry>DE</Ctry>
<AdrLine>Dorfstrasse 14</AdrLine>
<AdrLine>Muenchen</AdrLine>
</PstlAdr>
26
10.6 IBAN, IBAN-Only
• International Bank Account Number – IBAN ist das eindeutige Identifikationskriterium für Zahlungsempfänger
und Zahlungspflichtige. Die IBAN löst die nationale Kontonummer im SEPA-Zahlungsraum für SEPA-Aufträge
komplett ab.
<Id>
<IBAN>DE40700202700012345678</IBAN>
</Id>
• Der Aufbau ist definiert von ISO 13616-1:2007. Die IBAN beginnt mit zwei Buchstaben, dem Länderkennzeichen,
gefolgt von der numerischen Prüfziffer. Die zweistellige Prüfziffer errechnet sich über die gesamte IBAN nach
ISO 7064 im Modulus 97-10. Anschließend erfolgt eine Bank-/Kontoidentifikation. Diese Bank-/Kontoidentifkation
ist je nach Land unterschiedlich strukturiert und hat bis zu 34 Stellen. Derzeit gibt es IBANs zwischen 15 und 31
Stellen und neben numerischen Werten können ab der 5. Stelle auch alphanumerische Werte enthalten sein.
• In Deutschland bilden die ersten 8 Stellen nach der Prüfziffer die numerische Bankleitzahl und die folgenden 10 Stellen die numerische Kontonummer, sodass die gesamte IBAN in Deutschland 22-stellig ist. Ob die
Kontonummer korrekt ist, lässt sich für viele Banken anhand der letzten Stelle der Kontonummer sagen. Viele
Banken verwenden diese letzte Ziffer für eine Kontrollziffer. Welcher bankenindividuelle Berechnungsmodulus
hierfür notwendig ist, lässt sich im Bankleitzahlenverzeichnis bei der Bundesbank anhand der BLZ ermitteln.
• Eine simple Ermittlung der Prüfziffer anhand der BLZ und Kontonummer führt in Deutschland häufig
zu Fehlleitungen von Zahlungen, da besonders zu beachten ist:
• Einzelne Institute füllen das Kontonummernfeld in der IBAN bei Kontonummern kleiner 10 Stellen
nicht linksbündig mit Nullen auf, sondern füllen die Nullen am Ende der Kontonummer auf.
• Besonders durch Fusionen und Zusammenlegungen von Bankfilialen benutzen Kunden häufig noch
ihre alte Bankleitzahl weiter, obwohl sie bereits in ihrer IBAN eine neue Bankleitzahl erhalten haben.
•D
eshalb sollte eine IBAN-Berechnung immer über die kontoführende Bank oder in Deutschland über den
BankVerlag oder über Verfahren stattfinden, die die institutsindividuellen Besonderheiten berücksichtigen,
welche von der Bundesbank veröffentlicht wurden.
Beispiele für institutsindividuelle Besonderheiten bei der IBAN-Ermittlung
• Spenden- und Pseudokonten werden vor IBAN-Ermittlung in echte Kontonummern umgewandelt, z. B.:
BLZ 701500000 und Konto 70000 wird in IBAN zu Konto 18180018, also DE64 7015 0000 0018 1800 18.
• Konten werden hinten statt vorne auf 10 Stellen mit Nullen aufgefüllt, z. B.:
BLZ 26580070 und Konto 7325022 werden zu IBAN DE32 2658 0070 0732 5022 00.
• Die BLZ wird ausgetauscht, z. B.:
BLZ 30020500 und Konto 40033086 werden zu IBAN DE02 5002 0200 0040 0330 86.
27
IBAN-Beispiele für andere Länder
Im Dokument www.swift.com/dsp/resources/documents/IBAN_Registry.pdf sind alle national vereinbarten
IBAN-Formate aufgeführt, hier ein Auszug:
Österreich (20-stellig):LLPPBBBBBKKKKKKKKKKK
Beispiel:
AT611904300234573201
LL
Länderkennzeichen: AT
Buchstaben
PP
Prüfziffer 2-stellig numerisch
BBB... österreichische Bankleitzahl 5-stellig numerisch
KKK... Kontonummer
11-stellig numerisch
Schweiz (21-stellig):
Beispiel:
LL
Länderkennzeichen: PP
Prüfziffer
BBB... Schweizer Bankleitzahl KKK... Kontonummer
LLPPBBBBBKKKKKKKKKKKK
CH9300762011623852957
CH
Buchstaben
2-stellignumerisch
5-stellig
numerisch
12-stellignumerisch
Italien (27-stellig):
LLPPNBBBBBCCCCCKKKKKKKKKKKK
Beispiel:
IT60X0542811101000000123456
LL
Länderkennzeichen: IT
Buchstaben
PP
Prüfziffer 2-stellig
numerisch
NControl Internal Number (CIN)
1-stellig alphanumerisch
BBB... Associazione Bancaria Italiana (ABI) 5-stellig
numerisch
CCC... Codice di Avviamento Bancario (CAB) 5-stellig
numerisch
KKK... Kontonummer
12-stellignumerisch
28
IBAN-Only
Ab 4. November 2013 kann in Deutschland für innerdeutsche Transaktionen die Angabe des BIC entfallen:
SCT pain.001.003.03
SDD pain.008.003.02
<Id>NOTPROVIDED</Id>
</Othr>
</FinInstnId>
</DbtrAgt>
...
CdtrAgt kann komplett entfallen
<CdtrAgt>
<FinInstnId>
</FinInstnId>
</CdtrAgt>
...
</Othr>
</FinInstnId>
</CdtrAgt>
...
<DbtrAgt>
<FinInstnId>
<Othr>
</Othr>
</FinInstnId>
</DbtrAgt>
...
…
<DbtrAgt>
<FinInstnId>
<Othr>
…
<CdtrAgt>
<FinInstnId>
<Othr>
Um den Kunden den Umstieg auf IBAN-Only zu erleichtern, bietet die HVB ihren Kunden als Sonderlösung seit
April 2013 IBAN-Only auch in den bestehenden XML-Formaten direkt über das BIC-Feld an, ohne das zusätzliche
XML-Feld Other-Id:
SCT pain.001.001.03, pain.001.002.03,
pain.001.003.03
…
<DbtrAgt>
<FinInstnId>
</FinInstnId>
</DbtrAgt>
Oder
...
<BIC>NOTAVAIL</BIC>
<CdtrAgt>
<FinInstnId>
</FinInstnId>
</CdtrAgt>
...
SDD pain.008.001.02, pain.008.002.02,
pain.008.003.02
...
<CdtrAgt>
<FinInstnId>
</FinInstnId>
</CdtrAgt>
Oder
...
<BIC>NOTAVAIL</BIC>
<DbtrAgt>
<FinInstnId>
</FinInstnId>
</DbtrAgt>
...
Beim Payment-Status-Report pain.002 wird IBAN-Only wie folgt berücksichtigt: Bei Überweisungen enthält
der DebtorAgent den BIC der HVB und der CreditorAgent verbleibt so, wie dieser angeliefert wurde.
Bei Lastschriften gilt dies analog für CreditorAgent und DebtorAgent.
29
10.7 Gläubiger-Identifikation (Creditor-Identification/CI)
• SEPA-Lastschrifteinreicher benötigen eine eindeutige Identifikationsnummer. Diese ist bei der Bundesbank
pro Legal-Entity erhältlich www.glaeubiger-id.bundesbank.de
Format: LLPPZZZ0NNNNNNNNNN
LLLändercode
PP
Prüfziffer berechnet nach ISO 13616 (analog IBAN-Prüfziffer)
ZZZGläubiger-Geschäftsbereichskennung, beliebig zu vergeben, z. B. um Überschneidungen
bei Mandatsreferenzen zu vermeiden. Im Standard mit Wert ZZZ belegen
0NN… 11-stellige eindeutige Gläubiger-Identifikation mit führender Null
<CdtrSchmeId>
<Id><PrvtId><Othr>
<Id>DE12ZZZ01234567890</Id>
<SchmeNm>
<Prtry>SEPA</Prtry>
</SchmeNm>
</Othr></PrvtId></Id>
</CdtrSchmeId>
• Die Gläubiger-Identifikation sollte möglichst auf Payment-Informations-Ebene und nicht bei jeder Transaktion
wiederholt angegeben werden.
• Die Gläubiger-Geschäftsbereichskennung wird von der Prüfziffernberechnung ignoriert.
• Wird eine abweichende Gläubiger-Geschäftsbereichskennung beim Einzug verwendet, muss diese auch
auf dem Mandat angegeben werden.
30
10.8 Identifikationsnummern (OrgID/PrivateID)
• Optional kann zum Namen auch eine Identifikationsnummer mitgegeben werden. In Deutschland (DFÜAnlage) wird empfohlen, diese Felder nicht zu belegen, da auch eine Durchgängigkeit, z. B. im MT940, nicht
gegeben ist. In manchen Ländern bzw. für bestimmte Zahlungen, z. B. Steuerzahlungen, sind diese Angaben
allerdings notwendig. Auch das internationale CGI-Format verlangt teilweise diese Identifikationsnummern.
Neben der Identifikationsnummer können noch Daten, wie z. B. die ausstellende Behörde <Issr>, mitgegeben
werden. Es kann entweder eine Organisationsnummer oder eine Personennummer angegeben werden.
• OrganisationsIdentification <OrgID>, z. B. Firmennummer (COID), Kundennummer (CUST), Steuernummer
(TXID), Arbeitgebernummer (EMPL), BIC/BEI, DUNS u. a.
Siehe www.iso20022.org/external_code_list.page im Reiter „9-OrganisationIdentification“
<Id>
<OrgId>
<Othr>
<Id>181/815/08155</Id>
<SchmeNm>
<Cd>TXID</Cd>
</SchmeNm>
<Issr>Finanzamt Muenchen IV</Issr>
</Othr>
</OrgId>
</Id>
• PersonenIdentifikation <PrvtID>, z. B. Geburtsdatum/Ort, Sozialversicherungsnummer (SOSE), Passnummer
(CCPT), Steuernummer (TXID), Kundennummer (CUST), Führerscheinnummer (DRLC), Mitarbeiternummer
(EMPL) u. a.
Siehe www.iso20022.org/external_code_list.page im Reiter ,,10-PersonIdentifcation“
Beispiel (entweder Geburtsdatum/-ort ODER eine Nummer)
<Id>
<PrvtId>
<Othr>
<Id>RA 123445123</Id>
<SchmeNm>
<Cd>CCPT</Cd>
</SchmeNm>
<Issr>Kreisverwaltungsreferat
Muenchen</Issr>
</Othr>
</PrvtId>
</Id>
<Id>
<PrvtId>
<DtAndPlcOfBirth>
<BirthDt>1980-11-07</BirthDt>
<PrvcOfBirth>Bayern</PrvcOfBirth>
<CityOfBirth>Muenchen</CityOfBirth>
<CtryOfBirth>DE</CtryOfBirth>
</DtAndPlcOfBirth>
</PrvtId>
</Id>
31
10.9 Ultimate/Reference Party/On Behalf
• Neben dem Auftraggeber können Namensfelder des abweichenden Auftraggebers „Ultimate“ mitgeliefert
werden. Auch für den Empfänger gibt es die Möglichkeit, einen Ultimate-Endbegünstigten bzw. einen UltimateZahlungspflichtigen im Datensatz mitzugeben.
• Der abweichende Auftraggeber kann entweder auf Dateiebene (PaymentInf) oder auf Transaktionsebene
mitgeschickt werden. Empfohlen wird hier die Verwendung auf Dateiebene.
•W
enn bei einer SEPA-Lastschrift ein Ultimate verwendet wird, muss dieser auch auf dem Mandat angegeben sein.
• Für eine schuldbefreiende Zahlung bei Lastschriften ist auf der Zahlungsempfängerseite ein Konto für fremde
Rechnung notwendig.
• Die Ultimate-Felder haben rein informatorischen Charakter und werden als zusätzlicher Verwendungszweck
interpretiert.
• Nicht jede Bank bietet über alle Kanäle die Durchleitung dieser zusätzlichen Informationen an den Empfänger
an. Besonders im Papier-Kontoauszug werden diese Informationen derzeit nur vereinzelt angedruckt.
Eine zusätzliche Angabe im Verwendungszweck ermöglicht in jedem Fall eine Anzeige beim Endbegünstigten
bzw. Zahlungspflichtigen.
• Im MT940 erfolgt die Weitergabe der Ultimate-Informationen im Feld 86/Subfeld ?20-?29
oder (wenn kein Platz) im Subfeld ?60-?63:
• ABWA+[Abweichender Überweisender (CT) bzw. Zahlungsempfänger (DD)]
• ABWE+[Abweichender Zahlungsempfänger (CT) bzw. Zahlungspflichtiger (DD)]
Überweisung Beispiel Kindergeld
<Dbtr>
<Nm>Firma AG</Nm>
</Dbtr>
<Cdtr>
<Nm>Mutter Meier</Nm>
</Cdtr>
<UltmtDbtr>
<Nm>Kindergeld-Abteilung</Nm>
</UltmtDbtr>
<UltmtCdtr>
<Nm>Kind Meier</Nm>
</UltmtCdtr>
Lastschrift Beispiel Handy-Rechnung
<Cdtr>
<Nm>Mobilfunk AG</Nm>
</Cdtr>
<Dbtr>
<Nm>Mutter Meier</Nm>
</Dbtr>
<UltmtDbtr>
<Nm>Kind Meier</Nm>
</UltmtDbtr>
Abweichendes Retourenkonto
Die Ultimate-Felder können auch dazu verwendet werden, um ein abweichendes Retourenkonto anzugeben.
Hierbei wird das Einreicher- und Belastungskonto in die Feldgruppe UltimateDebtorId bei der Überweisung bzw.
UltimateCreditorId bei der Lastschrift eingestellt. Ein davon abweichendes Retourenkonto, auf dem etwaige
Retouren gesammelt werden, wird dann in die normalen Debitor- bzw. Creditor-Felder eingestellt. Hierzu ist
eine besondere Vereinbarung mit der HVB erforderlich. Nähere Infos zu dem Produkt „Ultimate-Auftraggeber“
erhalten Sie bei Ihrem Cash Management & eBanking-Spezialisten.
32
On behalf Payments über Payment Factory
Werden in einer Unternehmensgruppe über eine Dachgesellschaft Zahlungen für die verschiedenen Gesellschaften durchgeführt (Payment Factory), ist insbesondere bei den SEPA-Lastschriften, den Mandaten und der
Gläubiger-ID zu beachten, wer die Mandate mit welcher Gläubiger-ID zu schließen hat und über welche Konten
der Zahlungsverkehr ausgeführt wird, damit auf der Auftraggeberseite und hinsichtlich einer schuldbefreienden
Zahlung alle Voraussetzungen getroffen sind.
• Grundannahme: Liefergeschäft und Rechnungsstellung erfolgen durch Lieferfirma.
• Creditor ist Zahlungsabwicklungsfirma. Hierbei hat die kontoführende Stelle zu beachten, dass die eingehenden
Gelder auf ein Konto für fremde Rechnung laufen müssen (Treuhandkonto für Lieferfirma). Eine Haftungserklärung durch Zahlungsabwicklungsfirma für Rücklastschriften ist notwendig.
• Zahlungsabwicklungsfirma reicht die Lastschriften ein. Beim Einreicherkonto wird die Gläubiger-Identifikationsnummer (CI) der Zahlungsabwicklungsfirma hinterlegt und bei Einreichungen geprüft. Bei Gutschrift auf ein
Zahlungsabwicklungsfirma-Konto muss also die CI von der Zahlungsabwicklungsfirma hinterlegt werden. Ein
Unternehmen kann nur mit einer CI Lastschriften einreichen, d. h. die Zahlungsabwicklungsfirma kann nicht
mit der CI von der Lieferfirma einreichen.
• Was ist auf dem Mandat anzugeben: Creditor ist Zahlungsabwicklungsfirma, CI von Zahlungsabwicklungsfirma,
als Creditor Reference Party wird Lieferfirma und deren CI als Creditor Reference ID angegeben.
• Das Mandat mit Creditor Lieferfirma und CI Lieferfirma kann aufgrund der Koppelung der Kontonummer
mit der CI nur für die Gutschrift auf ein Lieferfirma-Konto verwendet werden.
Lastschrift
<Cdtr>
<Nm>Zahlungsabwicklungsfirma</Nm>
</Cdtr>
<Dbtr>
<Nm>Meier</Nm>
</Dbtr>
<UltmtCdtr>
<Nm>Lieferfirma</Nm>
</UltmtCdtr>
10.10 Mandatsänderung/Mandate-Amendment
• Wenn sich Änderungen am Mandat ergeben, muss nicht in jedem Fall ein neues Mandat eingeholt werden.
Die Mandatsänderung wird in der nächstfälligen SEPA-Lastschrift mitgeliefert.
• Folgende Felder sind hierfür im pain.008 vorgesehen:
• Creditor-bedingte Änderungen
• Änderung der Mandatsnummer, z. B. weil eine neue Mandatssystematik eingeführt wird
• Mitgabe der neuen Mandatsnummer <MndtId> und der alten Mandatsnummer <OrgnlMndtId>
• Änderung des Creditor-Namens, z. B. aufgrund von Firmenfusionen. Hier wird zumeist auch eine neue
Gläubiger-Identifikationsnummer nötig.
• Mitgabe der neuen Gläubiger-Identifikationsnummer <CdtrSchmeId> und der alten GläubigerIdentifikationsnummer <OrgnlCdtrSchmeId> <Id> sowie des
• neuen Creditor-Namens <Cdtr> und des alten Creditor-Namens <OrgnlCdtrSchmeId><Nm>
33
• Änderungen beim Zahlungspflichtigen
• Änderung der Debitoren-Kontoverbindung bei gleicher Bank
• Mitgabe der neuen IBAN <DbtrAcct> und alten IBAN <OrgnlDbtrAcct>
• Wechselt der Debitor seine Bank, wird nur das Kennzeichen SMNDA (SameMandateNewDebtorAgent)
vergeben, ohne die alte Bankverbindung anzugeben. Damit die neue Bank die korrekte Sequenz der
Einreichung überprüfen kann, muss diese Lastschrift dann als erstmalig „FRST“ geschickt werden
(mit den jeweilig notwendigen Vorlauftagen).
• Ändern sich die Adresse (z. B. Umzug), der Debitor-Name (z. B. Heirat) oder die Bankverbindung des
Gläubigers, muss kein neues Mandat eingeholt werden. Eine besondere Kennzeichnung in der Lastschrift
ist hierbei nicht erforderlich. Ändert sich jedoch die Identität des Zahlungspflichtigen (z. B. Mieterwechsel), muss ein neues Mandat eingeholt werden.
Überblick des Prozesses bei Mandatsänderungen
1
schriftliche Mitteilung über
geänderte IBAN/BIC
Kunde
(Debitor)
4
B2BMandatsauftrag
bzw.
Debtor-Profiling
mit geänderten
Mandatsdaten
2
8
Einzug der
Lastschrift mit
angehängten
Mandatsänderungen
(alt/neu)
Pre-Notification mit
geänderten Mandatsdaten
3
Mandatsänderungen
Debitor-IBAN (alt/neu)
Debitor-BIC
Gläubiger-ID (CI) (alt/neu)
Creditor-Name (alt/neu)
Mandats-ID (alt/neu)
Lieferant
(Creditor)
5
Einreichung der nächsten*
Lastschrift mit angehängten
Mandatsänderungen
6
Debitor-Bank
7
Lastschrift mit angehängten
Mandatsänderungen
(alt/neu) Besonderheit:
bei BIC-Änderung als „FIRST“
Prüfung B2B-Lastschrift auf
gültigen Mandatsauftrag.
Prüfen auf Debtor-Profiling
(z. B. Sperren)
* Falls eine Lastschrift mit Mandatsänderung rejected (pain.002) wird, muss der Folgeeinzug wieder mit Mandatsänderung erfolgen.
34
Archivierung der
Mandatsänderung
• Weiter zu beachten:
•W
enn die Lastschrift mit den Mandatsänderungen vor Buchung zurückkommt (Information z. B. mit
pain.002), muss der folgende Lastschrifteinzug wieder diese Mandatsänderungen enthalten.
• In der Lastschrift mitgegebene Mandatsänderungen führen bei der Zahlungspflichtigen-Bank nicht automatisch zur Änderung der Weisungen. So müssen vom Zahlungspflichtigen hinterlegte SEPA-Firmenlastschrift-Mandate durch den Zahlungspflichtigen ggf. aktiv geändert werden. Gleiches gilt auch für hinterlegte
Mandats-Sperrlisten (Negativ-Liste) bzw. explizit erlaubte Einzüge (Positiv-Liste) von SEPA-Basislastschriften.
Diese müssen ggf. an die Mandatsänderung angepasst werden. Informieren Sie deshalb frühzeitig den
Zahlungspflichtigen über etwaige Änderungen (z. B. besonders hervorgehoben in der Pre-Notification),
um unnötige Retouren zu vermeiden.
•A
rchivieren Sie die Mandatsänderungen und die dazugehörigen Aufträge für den lückenlosen Nachweis,
um bei Mandatsanforderungen eine Lastschrift-Retoure wegen fehlender Autorisierung zu vermeiden.
<MndtRltdInf>
<MndtId>555544</MndtId>
Aktuelle Mandatsnummer und Unterschriftsdatum
<DtOfSgntr>2012-11-12</DtOfSgntr>
Kennzeichen Mandatsänderung wird mitgeliefert
<AmdmntInd>true</AmdmntInd>
<AmdmntInfDtls>
<OrgnlMndtId>444444</OrgnlMndtId>
alte Mandatsnummer
<OrgnlCdtrSchmeId>
<Nm>Schrauben AG</Nm>
alter Creditor-Name
<Id>
<PrvtId>
<Othr>
<Id>DE16HVB00000017432</Id>
<SchmeNm>
alte Gläubiger-Identifikation
<Prtry>SEPA</Prtry>
</SchmeNm>
</Othr>
</PrvtId>
</Id>
</OrgnlCdtrSchmeId>
<OrgnlDbtrAcct>
<Id>
<IBAN>DE84700202700654150818</IBAN>
alte Debtor-IBAN
</Id>
</OrgnlDbtrAcct>
<OrgnlDbtrAgt>
<FinInstnId>
Kennzeichen neue Debtor-Bank
<Othr>
Anmerkung: In diesem Fall
<Id>SMNDA</Id>
wird dann die alte Debtor-IBAN
</Othr>
nicht mehr aufgeführt.
</FinInstnId>
</OrgnlDbtrAgt>
</AmdmntInfDtls>
</MndtRltdInf>
• Wann muss ein neues Mandat eingeholt werden?
• Wenn seit dem letzten Einzug 36 Monate vergangen sind
• Wenn eine Lastschriftrückgabe mit dem Rückgabegrund „NoMandate“ – MD01 erfolgt
•D
er letzte Einzug erfolgte mit Sequenz FNAL-Final oder OOFF-OneOff (und wurde nicht rejected).
• Der Debitor hat gegenüber dem Creditor sein Mandat widerrufen.
• Nach Erfüllung des bezogenen Vertrages, wenn das Mandat mit einem speziellem Bezug
auf einen Vertrag erteilt wurde (Vertragsmandat)
• Nach einem Wechsel des Zahlungspflichtigen (z. B. Mieterwechsel)
35
10.11 Lastschriftsequenz
• Es gibt zwei unterschiedliche SEPA-(Basis-/Firmen-)Lastschrift-Mandate:
• Für WIEDERKEHRENDE Einzüge
• Für EINMALIGE Einzüge
Dieses wird auf dem Mandat angegeben. Außerdem ist für die Sequenz entscheidend, ob ein Mandat bereits
verwendet wurde bzw. auch künftig weiter verwendet wird.
• Der Einzug der Lastschrift muss mit der korrekten Lastschriftsequenz erfolgen. Die Sequenz <SeqTp> muss auf
logischer Dateiebene <PmtInf> sortenrein geliefert werden. Von der Sequenz aus werden auch die korrekten
Vorlauftage zum Fälligkeitstag <ReqdColltnDt> in Abhängigkeit des Lastschriftproduktes
Core/Cor1/B2B <LclInstrm> bei der Einreichung überprüft.
• Arten der Lastschriftsequenzen <SeqTp>:
• E rsteinzug einer WIEDERKEHRENDEN Lastschrift „FRST“ (First)
• Folgeeinzug einer WIEDERKEHRENDEN Lastschrift „RCUR“ (Recurrent)
• Letzter Einzug einer WIEDERKEHRENDEN Lastschrift „FNAL“ (Final)
<SeqTp>RCUR</SeqTp>
• EINMALIGER Einzug „OOFF“ (OneOff)
Übersicht über die Cut-off-Termine pro Lastschriftprodukt auf Basis der Sequenz mit Beispiel
Cut-off auf Basis der Sequenz
FRST – First
RCUR – recurrent
FNAL – Final
OOFF – OneOff
Basislastschrift
(CORE)
Regel Vorlage Debtorbank,
Fälligkeitstag Duedate – x
D -5
D -2
D -2
D -5
Cut-off HVB
D -6, 12 Uhr
D -3, 12 Uhr
D -3, 12 Uhr
D -6, 12 Uhr
Cut-off HVB Beispiel Fällig:
Do 31.07.2014
Mi 23.07.2014,
12 Uhr
Mo 28.07.2014,
12 Uhr
Mo 28.07.2014,
12 Uhr
Mi 23.07.2014,
12 Uhr
D -1
D -1
D -1
D -1
Cut-off HVB
D -2, 12 Uhr
D -2, 12 Uhr
D -2, 12 Uhr
D -2, 12 Uhr
Do 31.07.2014
Di 29.07.2014,
12 Uhr
Di 29.07.2014,
12 Uhr
Di 29.07.2014,
12 Uhr
Di 29.07.2014,
12 Uhr
D -1
D -1
D -1
D -1
Cut-off HVB
D -2, 12 Uhr
D -2, 12 Uhr
D -2, 12 Uhr
D -2, 12 Uhr
Do 31.07.2014
Di 29.07.2014,
12 Uhr
Di 29.07.2014,
12 Uhr
Di 29.07.2014,
12 Uhr
Di 29.07.2014,
12 Uhr
Basislastschrift
mit verkürzter
Vorlauffrist
(COR1)
Firmenlastschrift
(B2B)
Bitte beachten Sie ggf. abweichend vereinbarte Cut-off-Zeiten. Die aktuell gültigen Cut-off-Zeiten der HVB
finden Sie unter www.hvb.de – Geschäftsbedingungen/Konditionen.
Grundlage für die Berechnung:
• Für die Vorlauftage (D -5/D -2/D -1) werden im Interbanken-Clearing TARGET-Tage verwendet, d. h. Montag bis
Freitag ohne die TARGET-Feiertage (1. Januar, Karfreitag, Ostermontag, 1. Mai, 25. und 26. Dezember)
• Fällt ein Fälligkeitstag auf ein Wochenende oder einen TARGET-Feiertag, kann die Zahlungspflichtigen-Bank
die Debitorbelastung auf den nächstmöglichen Bankarbeitstag verschieben.
• Für die Pre-Notification-Regel (mind. 14 Tage) zählen Kalendertage.
• Für die Lastschrift-Retoure (Return D +2 für die B2B bzw. D +5 für die Basislastschrift) zählen TARGET-Tage.
• Für die Cut-off-Tage zählen Bankgeschäftstage.
36
Besonderheiten für die Lastschriftsequenz
• Kommt die Lastschrift vor Buchung zurück (reject/refusal/storno per pain.002), gilt die Lastschrift als nicht
angekommen und es muss die ursprüngliche Sequenz für den Folgeeinzug genommen werden. Es müssen
dann auch die ursprünglichen Vorlauftage eingehalten werden.
• Kommt die Lastschrift nach Buchung zurück (return/refund), gilt die Lastschrift als angekommen.
Es muss die nächste Sequenz für den Folgeeinzug genommen werden bzw. das Mandat gilt bei
einer einmaligen bzw. finalen Lastschrift als abgelaufen.
• Erfolgt eine Mandatsänderung auf eine neue Zahlungspflichtigen-Bank „SMNDA-SameMandateNewDebitorAgent“, muss die Lastschriftsequenz als erstmalig „FRST“ gekennzeichnet werden.
• Erfolgt eine Mandatsänderung auf die gleiche Zahlungspflichtigen-Bank (nur Änderung der Creditor-Daten bzw.
nur neue IBAN des Debitors bei gleicher Bank), muss die normale folgende Lastschriftsequenz verwendet werden.
• Von einem gleichen Fälligkeitstag von der Erstmaligen- und der Folgelastschrift sollte abgesehen werden.
• Wird nach einer ersten CORE-Lastschrift mit der Sequenz „FRST“ eine COR1-Lastschrift eingezogen, muss dies
als Folgelastschrift mit „RCUR“ erfolgen.
Mit welcher Lastschriftsequenz erfolgt der Folgeeinzug, wenn es eine Rückgabe einer Lastschrift gab und
wann sind Mandatsänderungen zu wiederholen?
Aktueller Einzug
Rückgabe des aktuellen Einzugs
Folgeeinzug
FRST – First
Keine Rückgabe
RCUR – Recurrent*
FRST – First
Vor Buchung (pain.002)
FRST – First
FRST – First
Nach Buchung
RCUR – Recurrent*
RCUR – Recurrent
Keine Rückgabe
RCUR – Recurrent*
RCUR – Recurrent
RCUR – Recurrent*
RCUR – Recurrent
Nach Buchung
RCUR – Recurrent*
FNAL – Final
Keine Rückgabe
Kein Folgeeinzug
FNAL – Final
FNAL - final
FNAL – Final
Nach Buchung
Neues Mandat nötig
OOFF – OneOff
Keine Rückgabe
Kein Folgeeinzug
OOFF – OneOff
OOFF – OneOff
OOFF – OneOff
Nach Buchung
Neues Mandat nötig
Mandatsänderung neue Debtorbank SMNDA
mit FRST – First (Pflicht)
Keine Rückgabe
RCUR – Recurrent*
FRST – First
& Mandatsänderung SMNDA wiederholen
Nach Buchung
RCUR – Recurrent*
(Mandatsänderung nicht wiederholen)
Mandatsänderung gleiche Debtorbank
mit RCUR – Recurrent
Keine Rückgabe
RCUR – Recurrent*
RCUR – Recurrent*
& Mandatsänderung wiederholen
Nach Buchung
RCUR – Recurrent*
* Ausnahme: Der Folgeeinzug ist der letztmalige, dann mit „FNAL“ – Final kennzeichnen
37
10.12 Zeichensatz und Umlaute
In SEPA kann ein umfangreicher Zeichensatz verwendet werden (UTF-8) mit vielen länderspezifischen Umlauten.
Alle Banken sind in der SEPA verpflichtet, mindestens einen eingeschränkten Zeichensatz zu unterstützen:
• Numerische Zeichen 0 bis 9
• Buchstaben
A bis Z und a bis z
• Sonderzeichen
: ? , - ( + . )/und Leerzeichen
Seitens EPC und DK wird aber mittlerweile empfohlen, länderspezifische Umlaute und Sonderzeichen zu
unterstützen, um die Einführung und Akzeptanz zu erleichtern. Banken, die die Sonderzeichen und Umlaute
nicht verarbeiten können, ersetzen diese ggf. durch ähnliche Zeichen laut EPC-Empfehlung oder sonst durch
Leerstelle oder Punkt. Zum Zeichensatz hat das EPC grundsätzliche Informationen veröffentlicht:
www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=332
Der definierte Zeichensatz ist in allen Namens-, Adress-und Verwendungszweckfeldern möglich. Bei einigen
Feldern in den verschiedenen Formaten sowie bei Sonderzeichen gibt es Restriktionen, die in der unteren Tabelle
zusammenfasst sind. Insbesondere bei einigen Sonderzeichen verlangt der XML-Standard Maskierungen, z. B.
muss der Verwendungszweck „Fa. O’Hart & Co -> Fr. Meier“ wie folgt ins XML gesetzt werden:
Fa. O'Hart & Co -> Fr. Meier
Erfahrungen aus der Praxis haben gezeigt, dass bei der Datenpflege folgende Fehlerquellen lauern:
• Falsche Zeichen bei IBAN oder BIC können zur Dateiabweisung führen:
• Verwechslungsgefahr von folgenden Buchstaben und Ziffern:
Buchstabe „O“ / Ziffer „0“ oder Buchstabe „I“ / Ziffer „1“ oder Buchstabe „S“ / Ziffer „5“
• Wenn der BIC in den ersten 6 Stellen Zahlen statt Buchstaben enthält, wie z. B. BEV0DEBBXXX mit der
Ziffer „0“ statt BEVODEBBXXX mit dem Buchstaben „O“ für die Berliner Volksbank
Korrekter BIC Aufbau (Schemaprüfung):
• BIC darf nur 8 oder 11 Stellen lang sein
• Sonderzeichen, Umlaute oder Kleinbuchstaben nicht erlaubt
• Stelle 1 - 6: Großbuchstaben
• Stelle 7: Großbuchstaben oder Zahl (ohne Zahlen 0 und 1)
• Stelle 8: Zahlen oder Großbuchstaben (ohne Buchstabe O)
• Stelle 9–11 (wenn verwendet): Großbuchstaben und/oder Zahlen
• Die IBAN enthält an den ersten beiden Stellen Ziffern statt Buchstaben (z. B. N0 statt NO für Norwegen)
oder an Stelle 3 und 4 Buchstaben statt Ziffern (z. B. I0 statt 10 als Prüfziffer)
• Bei der IBAN wird das Papierformat mit Viererblöcken, getrennt durch Leerzeichen, verwendet
statt des elektronischen Formats ohne Leerzeichen.
• BIC oder IBAN enthalten Kleinbuchstaben oder gar Sonderzeichen.
• Falsche Zeichen in Referenzen wie Message-Referenz, Payment-Information-Referenz, Instruction-Referenz,
End-To-End-Referenz oder Mandatsreferenz können zur Dateiabweisung führen, siehe auch die untere Tabelle
mit den erlaubten Zeichen.
• Falsch übernommene Zeichen bei den Referenzen, z. B. wegen Verwechslung von Ziffern und Buchstaben wie
oben beschrieben, können dazu führen, dass eine Transaktion nicht zu einem Geschäft zugeordnet werden kann
und eine aufwendige Nachbearbeitung notwendig wird. Insbesondere die wichtige Mandatsreferenz sollte so gestaltet werden, dass in der Kundenkommunikation Missverständisse vermieden werden, also vorzugsweise keine
führenden Nullen und nur begrenzt Sonderzeichen einsetzen.
38
Unterstützte Zeichen in SEPA
Bezeichnung
Zeichen
pain DK 2.6
pain DK 2.7
pain EPC
Referenznummern1)
Mandatsreferenz
MT940
(DK)
DTAUS
DTAZV
MT101
Ziffern
0–9
X
X
X
X
X
X
X
X
X
Großbuchstaben
A–Z
X
X
X
X
X
X
X
X
X
Kleinbuchstaben
a–z
X
X
X
X
X
X
–
–
X
Space
X
X
X
X6)
–
X
X
X
X
Fragezeichen
?
X
X
X
X
X
–
–
–
X
Kaufmännisches Und
&
–
X3)
X3)
–
–
–
X
X
–
Spitze Klammern
<>
–
Runde Klammern, Apostroph, Doppelpunkt
()':
X
Weitere Sonderzeichen des SEPA-BasicZeichensatzes: Schrägstrich, Minus, Punkt,
Komma, Pluszeichen
/.,+
Leerzeichen
2)
–
X
3)
–
–
–
–
–
–
X
X3)
X
X
X
–
–
X
X
X
X
X
X
X
X
X
X
*$%
–
X4)
X5)
–
–
–
X
X
–
ÄÖÜß
–
X4)
X5)
–
–
–
X
–
–
Deutsche Umlaute (Kleinschrift)
äöü
–
X
X
–
–
–
–
–
–
Zusätzliche Zeichen von UTF-8 empfohlen
für SEPA unter anderem:
oben aufgeführte deutsche Zeichen
plus Ausrufezeichen, Anführungszeichen,
Doppelkreuz, Semikolon, Gleichheitszeichen,
At-Zeichen, eckige Klammern, umgekehrter
Schrägstrich, Unterstrich, senkrechter Strich,
Tilde, Paragraf, Euro und weitere
!“#
;=@
[]\
_|~
§€…
–
–
X3), 5)
–
–
–
–
–
–
Zusätzliche Zeichen des deutschen DTAZeichensatzes: Stern, Dollar-Zeichen,
Prozent-Zeichen
Deutsche Umlaute (Großschrift), scharfes S
4)
5)
Betrifft Message-Referenz <MsgId>, Payment-Information-Referenz <PmtInfId>, End-To-End-Referenz <EndToEndId> und Instruction-Referenz <InstrId>.
Werden als Großbuchstaben behandelt.
3)
Folgende Zeichen müssen gemäß EPC maskiert werden: „&“ = “&“ , „<“ = “<“, „>“ = “>“, Anführungszeichen (“) = “"“, Apostroph (') = “'“.
4)
Zeichen können durch Banken konvertiert werden: Ä/Ö/Ü/ä/ö/ü->AE/OE/UE/ae/oe/ue oder A/O/U/a/o/u; ß->“ss“ oder „s“; */$/%->“.“ (Punkt).
5)
EPC empfiehlt die Unterstützung ohne Konvertierung.
6)
Leerzeichen waren in früheren DK-Formaten bei der Message-Referenz <MsgId> nicht erlaubt. EPC und DK ab Version 2.5 erlauben Leerzeichen.
1)
2)
39
10.13 Konkurrierende Felder – XOR
Häufige Fehler bei der Feldbelegung sind Felder, die mehrfach auf verschiedenen Ebenen vorkommen oder
an Bedingungen geknüpft sind. Dieses wird durch das XML-Prüfschema (XSD) nur eingeschränkt geprüft.
• Einige Felder gibt es auf Dateiebene (PaymentInfo) und auch auf Transaktionsebene, z. B.
PaymentInfo-Ebene
Transaktions-Ebene
entweder oder/Pflichtfeld
CreditorIdentification
(nur SDD)
Empfohlen
Alternativ
Pflicht bei SDD
CategoryPurpose
Empfohlen
(nötig für HVB Produkt
SEPA-Gehaltszahlung)
Alternativ
Optional
ChargeBearer
Empfohlen
Alternativ
Pflicht „SLEV“
Ultimate-Debtor (SCT)
Ultimate-Creditor (SDD)
Variante 1
(nötig für HVB Produkt
SEPA-Ultimate-Auftraggeber)
Variante 2
Optional
ServiceLevel-Code
Pflicht
Nicht erlaubt auf Transaktionsebene bei DK
Pflicht („SEPA“, „URGP“)
InstructionPriority
Optional
Optional
LocalInstrument-Code (nur SDD)
Pflicht
Pflicht bei SDD („B2B“, „CORE“, „COR1“)
• Bei einigen Feldern darf entweder das eine oder das andere verwendet werden. Beide Feldgruppen zu belegen
ist nicht möglich. Das XSD des DK prüft dieses, aber das XSD für EPC-Formate stellt hier keinen Fehler fest:
• Der Verwendungszweck kann entweder strukturiert <Strd> ODER unstrukturiert <Ustrd> angegeben werden.
Beide können nicht gleichzeitig verwendet werden.
• Organisational-ID <OrgId> versus Private-ID <PrvtId>. Hier ist nur eine der beiden Elementgruppen erlaubt.
• Bei Nutzung von der Private-ID kann auch nur entweder eine Identifikationsnummer <Id> mit Issuer <Issr>
und Identifikationsart <SchmeNm><Cd> ODER ein Geburtstag mit Geburtsort <DtAndPlcOfBirth>
verwendet werden.
40
10.14 SEPA-Referenznummern und deren Verwendung
Welche Referenznummern gibt es in SEPA und wo werden diese vergeben?
SEPA-Feld
Beschreibung
Datei/TransaktionsEbene
Verwendung
Einreichung
MessageIdentification (<MsgId>)
Eindeutige technische Referenz der Datei des Dateierstellers
GroupHeader
SCT, SDD
DTI Dateinummer
HVB-Sammlerreferenz
Original MessageIdentification
(<OrgnlMsgId>)
Ursprüngliche Message ID bei Datei-Reject
GroupHeader
PaymentInformationIdentification
(<PmtInfId>)
Referenz der logischen Datei (Sammlerreferenz)
Payment-Information
SCT, SDD
Original PaymentInformationIdentification
(<OrgnlPmtInfId>)
Ursprüngliche Referenz der logischen Datei bei DateiReject
Payment-Information
–
Dateinummer HVB
Eindeutige Dateinummer von HVB vergeben
Payment-Information
–
Transaktionsreferenz HVB
Eindeutige HVB-Referenz der einzelnen Transaktion
Transaktion
SCT, SDD
(Creditor Identifier, <CdtrSchmeId>)
Eindeutige GläubigerIdentification
(von Bundesbank)
Payment-Information oder
Transaktion
SDD
Original CreditorIdentification
(<OrgnlCdtrSchmeID>)
Nur bei Mandatsänderung die ursprüngliche
Transaktion
SDD
InstructionIdentification (<InstrId>)
Technische Point-to-Point-Referenz Transaktionsreferenz, wird nicht weitergegeben
Transaktion
SCT, SDD
Original InstructionIdentification
Ursprüngliche Point-to-Point-Referenz bei Datei-Reject
Transaktion
–
End-to-End Identification (<EndToEndId>)
Fachliche Auftraggeberreferenz – wird an Empfänger
weitergeleitet
Transaktion
SCT, SDD
Original End-to-End-ID
Ursprüngliche Auftraggeberreferenz bei Datei-Reject
Transaktion
–
TransactionIdentification (<TxId>)
Eindeutige Transaktionsnummer vom erstbeteiligten
Institut vergeben
Transaktion
–
Creditor Reference
(CreditorReferenceInformation, <CdtrRefInf>)
Strukturierte Referenznummer im
strukturierten Verwendungszweck
Transaktion
SCT, SDD
MandateIdentification
(Mandate Reference, <MndtId>)
Eindeutige Mandatsreferenz
(bezogen auf GläubigerIdentification)
Transaktion
SDD
Original MandateIdentification
Nur bei Mandatsänderung die ursprüngliche Mandatsreferenz
Transaktion
SDD
OrganisationIdentification (<OrgId>)
Identifikationsnummer einer Organisation (BIC, BEI,
Steuernummer, Kundennummer etc.; siehe ISO 20022
External Code List)
Transaktion
*
PersonIdentification (<PrvtId>)
Identifikationsnummer einer natürlichen Person
(Geburtsdatum/Ort, Sozialversicherungsnummer, Passnummer, Steuernummer, Kundennummer etc.; siehe
ISO External Code List)
Transaktion
*
* in Deutschland Verwendung nicht empfohlen; Ergänzung zu InitiatingParty, Debtor, Creditor, UltimateDebtor, UltimateCreditor
41
Abbildung der SEPA-Referenznummern im MT940/942/camt und pain.002
SEPA-Feld
Reporting pain.002 Reporting MT940/942
Reporting camt.052/camt.053
MessageIdentification (<MsgId>)
pain.002
–
–
–
<AddtlInfInd><MsgId>
–
–
Wenn länger als 16 Chars: :86: mit
Identifier KREF+
Wenn kürzer: :61/7:
<NtryDtls><Btch><PmtInfId>
<NtryDtls><TxDtls><Refs><PmtInfId>
(only initiator entry)
DTI Dateinummer
Original MessageIdentification
(<OrgnlMsgId>)
pain.002
PaymentInformationIdentification
(<PmtInfId>)
42
Original PaymentInformationIdentification
(<OrgnlPmtInfId>)
pain.002
–
–
Dateinummer HVB
–
:61/9:
–
Transaktionsreferenz HVB
–
:61/8:
<NtryDtls><TxDtls><Refs><AcctSvcrRef>
bzw. <NtryDtls><TxDtls><Refs><ClrSysRef>
(Creditor Identifier, <CdtrSchmeId>)
–
:86: mit Identifier CRED+
<NtryDtls><TxDtls> <RltdPties><Cdtr><Id><
PrvtId><Othr><Id>
Original CreditorIdentification
(<OrgnlCdtrSchmeID>)
–
–
–
InstructionIdentification (<InstrId>)
–
–
–
Original InstructionIdentification
pain.002
–
–
End-to-End Identification (<EndToEndId>)
–
:86: mit Identifier EREF+
<NtryDtls><TxDtls><Refs><EndToEndId>
Original End-to-End-ID
pain.002
–
–
TransactionIdentification (<TxId>)
–
–
<NtryDtls><TxDtls><Refs><TxId>
Creditor Reference
(CreditorReferenceInformation, <CdtrRefInf>)
pain.002
Teil des strukturierten Verwendungszwecks
(allerdings ohne Tags)
Teil des strukturierten Verwendungszwecks
MandateIdentification
(Mandate Reference, <MndtId>)
pain.002
:86: mit Identifier MREF+
<NtryDtls><TxDtls><Refs<MndtId>
Original MandateIdentification
–
–
–
OrganisationIdentification (<OrgId>)
–
–
–
PersonIdentification (<PrvtId>)
–
Nur CreditorIdentification (siehe oben)
Nur CreditorIdentification (siehe oben)
End-To-End-Referenz <EndToEndId>
• Die bis zu 35-stellige End-To-End-Referenz ist vom Einreicher zu vergeben. Sie wird an den Endempfänger
weitergeleitet und auch bei Retouren wieder an den Einreicher zurückgegeben.
• Wenn diese nicht vom Einreicher mitgegeben wird, wird sie von der Bank mit „NOTPROVIDED“ belegt.
• Weitergabe im MT940: Feld 86/Subfeld ?20-?29: EREF+[Ende-zu-Ende Referenz] oder wenn kein Platz ist
im Subfeld ?60-?63
<EndToEndId>12345678901234567890123456789012345</EndToEndId>
Mandatsnummer/Mandatsreferenz <MndtId>
• Die Mandatsnummer ist im Zusammenhang mit der Gläubiger-Identifikationsnummer (CI) europaweit eindeutig.
• Die bis zu 35-stellige Mandatsnummer ist vom Einreicher (Creditor) bei SEPA-Lastschriften eindeutig zu
vergeben.
• Die Mandatsnummer dient dem Zahlungspflichtigen zur Abstimmung sowie für etwaige Weisungen gegenüber
der Debitorbank (z. B. zum Sperren oder betragsmäßigen Einschränken der Lastschrift sowie zur Hinterlegung
von Abbuchungsautorisierungen im B2B-Mandat).
• Sie wird an den Zahlungspflichtigen weitergeleitet
• in der Pre-Notification (empfohlen)
• als Pflichtfeld in der SEPA-Lastschrift <MdtId>
• im Mandat zur Unterschrift (kann aber auch nachträglich ergänzt werden)
• im Elektronischen Kontoauszug MT940 (Feld 86/Subfeld ?20-?29: MREF+[Mandatsreferenz])
oder wenn kein Platz im Subfeld ?60-?63 ist
• in der Lastschrift-Retoure
• Wenn sich die Mandatsnummer ändert, kann die Änderung über die standardisierte Mandatsänderung
vorgenommen werden (siehe Kapitel „Mandatsänderung“).
• Für die Vergabe der Mandatsnummer beachten Sie bitte auch das Kapitel „Zeichensatz“.
<MndtId>555544</MndtId>
43
11. Reporting Übersicht
11.1 Reporting (Bank – Kunde)
Welches Bank-Kunde-Format ist für welchen Zweck? In der folgenden Tabelle finden Sie eine Übersicht der
möglichen Varianten von elektronischen Kontoinformationen rund um Kontoauszüge, Avise, Buchungssammler
und Fehlerinformationen.
Empfohlen für
Optionen
Einschränkung/
zu beachten
Format
Erstellungszeitpunkt
MT940
Elektronischen Kontoauszug –
Altsysteme
Nicht alle SEPA-Felder
werden durchgereicht.
MT940
Tagesende Buchungstag
MT942
ZV-Avis –
Altsysteme
MT942
½-stündlich Buchungstag
DTI
Elektronische Weiterverarbeitung von Eingängen und
Retourenverarbeitung –
Altsysteme
Nicht für LastschriftRetouren vor Buchung
DTAUS0
DTAUS1
camt.053
Elektronischen Kontoauszug –
Neu
camt.053.001.02
Tagesende Buchungstag
camt.052
Elektronisches ZV-Avis –
Neu
camt.052.001.02
camt.054
Elektronische Weiterverarbeitung von Eingängen und
Retourenverarbeitung –
Neu
camt.054.001.02
camt.086.001.01
Monatlich oder quartalsmäßig je nach Wunsch des
Kunden
DK:
pain.002.003.03
pain.002.002.02
EPC:
pain.002.001.03
Sofort bei Fehlerfeststellung
• E lektronische Informati-
on über die eingereichte
SEPA-Datei
• S eit Juni 2013 optional
auch: Lastschrift-Retouren vor Buchung
camt.086
Elektronisches Preis-Reporting
pain.002
SEPA-Fehlernachrichten vor
Buchung für das SEPA-MandatsManagement
Optional seit Nov. 2012:
auch SEPA-Fehlernachrichten nach Buchung
Keine Lastschrift-RetourenGebührenausweisung
11.2 Buchung von SEPA-Dateien
Buchung der Datei (Sammler-/Einzelsatzbuchung)
Wie erfolgt die Einreicher-Dateibuchung auf dem Konto?
Die Kontoeinstellung für Dateieinreichungen mit mehr als einem Posten ist standardmäßig die Sammelbuchung.
Auf Kundenwunsch können auch alle Zahlungen auf dem Konto einzeln gebucht werden oder das Konto so
administriert werden, dass Sie pro Datei individuell wählen können, welche Datei gesammelt wird (z. B. Gehaltsdateien) und welche Dateien als Einzelbuchung auf dem Kontoauszug erscheinen sollen. In der eingereichten
SEPA-Datei können Sie individuell pro Datei einstellen, ob die Buchung als Sammel- oder Einzelbuchung erfolgen
soll (Kennzeichen „BatchBooking“):
<PmtInfId> …
<BtchBookg>true</BtchBookg>
…
</PmtInfId>
44
BatchBooking = „true“ (Sammelbuchung)
BatchBooking = „false“ (Einzelsatzbuchung)
Damit dieses Feld „BatchBooking“ in der Verarbeitung berücksichtigt wird, beauftragen Sie dieses bitte im
Vorfeld bei Ihrem Cash Management & eBanking-Spezialisten der Bank.
Einreicher – Bruttoprinzip
• Die Einreicherbuchung erfolgt analog dem DTA im Inlandszahlungsverkehr im Bruttoprinzip, d. h., wenn einzelne
Überweisungen rejected werden (z. B. zwei falsche BICs in einer Datei mit 10 Posten), erfolgt die Belastung auf
dem Einreicherkonto mit der Gesamtsumme der Datei für die 10 Posten. Die fehlerhaften zwei Sätze werden
dem Einreicherkonto zum Ausgleich wieder gutgeschrieben (dies kann nach Wunsch in einer Sammelsumme
oder als Einzelsatz gebucht werden). Die Information über die Detailfehler erfolgt sofort mittels Fehlerprotokoll und – wenn gewünscht – über die elektronische Status-Information „pain.002“. Die Buchung der Einreichung und der fehlerhaften Sätze erfolgt immer zum Buchungstag – dieses ist insbesondere relevant bei
Lastschrifteinreichungen mit z. B. 6 Tagen Vorlauf. Die gebuchten fehlerhaften Sätze werden Ihnen dann am
Buchungstag per MT940 bzw. camt.053/camt.054 zur Verfügung gestellt.
Einreicher – Nettoprinzip
• Das Nettoprinzip (die fehlerhaften Sätze werden überhaupt nicht gebucht) erfolgt nur, wenn die gesamte
Datei abgelehnt wird. Auch hier erfolgt die Information über die Detailfehler mittels Fehlerprotokoll und –
wenn gewünscht – über die elektronische Status-Information „pain.002“.
Wie erfolgt die Empfängerbuchung auf dem Konto?
Eine große Anzahl an Gut- oder Lastschriften können in SEPA auch gesammelt und auf dem Konto in einer Summe
gebucht werden. Die Detailposten können Ihnen dann mittels einer elektronischen Datei zur Weiterverarbeitung
zur Verfügung gestellt werden.
• DTI: Hier werden die SEPA-Eingänge gesammelt und von XML in DTAUS-Format konvertiert und als DTI
zur Verfügung gestellt. Für konkrete Konvertierungsregeln fragen Sie bitte Ihren Betreuer.
• camt.054: Um die umfangreichen Felder des SEPA-XML-Formats auch für die Weiterverarbeitung nutzen zu können.
45
camt.053 (Kontoauszug)
<Umsatz 1>
<Sammelbuchung>
<Umsatz 2>
<Umsatz …>
Auftraggeber
Bank
Auftraggeber
Empfänger
camt.054 (Sammler-Details)
<Sammler-Umsatz 1>
<Sammler-Umsatz 2>
<Sammler-Umsatz …>
Auftraggeber
• Gleichartige Umsätze (z. B. Überweisungseingänge, Rücklastschriften) können beim Empfängerkonto
gesammelt und in einem Betrag gebucht werden.
• Übersichtlichkeit für die Kontodispositionen wird erhöht.
• Sammler-Details werden in einem separaten Prozess des Kunden effizient abgewickelt.
Die Einrichtung einer Sammelverbuchung von Gutschriftseingängen oder Belastungen können
bei Ihrem zuständigen Cash Management & eBanking-Spezialisten der Bank beantragt werden.
11.3 Status/Fehlernachricht pain.002
Mit einer Status-/Fehlerdatei pain.002 erhalten Sie elektronisch im pain-Dateiformat eine genaue Rückmeldung
zu den fehlerhaften Sätzen und die Art der Fehler. Hiermit können Sie ein eindeutiges Matching zu Ihren originalen Einreichungen sicherstellen.
CreditorCreditor-Bank
Debtor-Bank Debtor
Beispiel SEPA-Lastschrift
pain.002 pacsReject
Auftraggeber initiiert
Auftraggeber-Bank initiiert
Zahlungspflichtiger-Bank initiiert
Zahlungspflichtiger initiiert
• ISO-20022-Nachrichten enthalten alle relevanten Informationen von der Einreichung bis zur Rückmeldung.
• Fehler-Report bereits vor Buchung (vergleichbar mit bestehendem Fehlerprotokoll)
• Besonderheit bei SEPA DD:
• Weiterleitung Auftrag an Zahlungspflichtiger-Bank bereits vor Fälligkeit
• Prüfung durch Zahlungspflichtiger-Bank vor Fälligkeit (z. B. Konto aufgelöst)
•R
ückmeldung von Fehlern an Einreicher bereits vor Fälligkeit bzw. vor Buchung
• Ergänzt Information im Kontoauszug (camt.053), da dieser erst nach Buchung vorliegt
46
Auftraggeber
initiierte R-Nachrichten:
Vor Buchung
• Rückruf (Revocation/Recall)
z. B. Bestätigung der Revocation
Einreicher-Bank
Vor Buchung
• Zahlungspflichtiger-Bank für Lastschriften nicht SEPA-ready
•P
flichtfelder fehlen
• IBAN-Check fehlerhaft
Zahlungspflichtiger-Bank
initiierte R-Nachrichten bei Lastschriften:
Vor Buchung
• Reject, z. B.
• Zahlungspflichtiger-Konto besteht nicht
• Z ahlungspflichtiger-Konto gesperrt
Zahlungspflichtiger
Vor Buchung
•M
andatssperre durch Zahlungspflichtigen
•K
omplette Lastschriftsperre
•W
iderspruch bereits vor Buchung
Unterscheidung der Rückgabe vor oder nach Buchung?
Relevant ist hier immer der Interbanken-Settlement-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 ja für LastschriftFolgeeinreichungen 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.
Vor Buchung
Nach Buchung
Buchung
Storno
Mit folgenden GVC im Kontoauszug:
• 108 SEPA-Reject (Soll, B2B),
• 109 SEPA-Reject (Soll, CORE/COR1) bzw.
• 159 SEPA-Reject (Haben, Überweisung)
Retoure
Mit folgenden GVC im Kontoauszug:
• 108 SEPA-Lastschrift-Rückrechn. (Soll, B2B),
• 109 SEPA-Rückrechn. (Soll, CORE/COR1) bzw.
• 159 SEPA-Rückgabe (Haben, Überweisung)
pain.002
Ja
Optional
Option pain.002 auch für Retouren nach Buchung
• Dies kann sinnvoll sein, wenn für das Mahnwesen zu den Lastschrift-Retouren nur 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).
• Wenn die Option pain.002 genutzt wird, ist folgendes zu beachten:
• Die Unterscheidung der pain.002-Nachricht vor und nach Buchung lässt sich derzeit nur anhand der Referenznummer <MsgId> bei der HVB durchführen. Die pain.002-Vor-Buchung hat in der <MsgId> an 3. Stelle ein
„F“, die pain.002-Nach-Buchung an der 3. Stelle ein „I“.
• 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>.
47
11.4 Rückgabegründe
Die HypoVereinsbank stellt ihren Kunden die Rückgabegründe in den Kontoauszügen sowohl papierhaft
als auch elektronisch in den Datenträgerinformationen zur Verfügung.
48
SEPA
Reason
Code
MT940/ HVB als Bank
DTI Text- des Einreichers
SL-Erg.
(SCT und SDD)
HVB als Creditor-Bank (SCT)
bzw. Debtor-Bank (SDD)
Auszug von wichtigen
Codes von Fremdbanken
Handlungsempfehlung
für den Einreicher
AC01
901
IBAN nicht vorhanden
oder nicht eindeutig
IBAN fehlerhaft
IBAN korrigieren
AC04
902
Konto erloschen
Konto aufgelöst
Kunden wegen neuem
Konto kontaktieren
AC06
903
SDD: Gesamt-Lastschriftsperre
Konto gesperrt
Kunden wegen Grund
für Sperre kontaktieren
AC13
930
SDD-B2B: Zahlungspflichtiger ist
ein Verbraucher
Als CORE einreichen
AG01
904
Zahlungsart für Konto unzulässig
Kunden wegen anderem
Konto kontaktieren
AG02
905
SDD: Falscher Sequence Type
Transaktion korrigieren
AGNT*)
923
Fälschlicherweise eingeschaltetes
Kreditinstitut
Siehe Fußnote *)
AM01
911
Betrag ist null
Betrag ist null
AM02
911
Betrag ungültig,
unzulässig
Betrag ist unzulässig
AM03
911
Währung ungültig
Währung ungültig
AM04
906
Deckung fehlt
SDD: Deckung fehlt (Belastung)
Eigenes Konto eindecken
bzw. Kunden kontaktieren
AM05
907
Doppelverarbeitung
Doppeleinreichung
Prozess der Dateierstellung
überprüfen
AM07
911
Betrag gesperrt
Kunden kontaktieren
AM09
911
Betrag ungültig,
nicht korrekt
Betrag ist nicht korrekt
AM10
911
Falsche Kontrollsumme
Falsche Kontrollsumme
Datei korrigieren
BE01
911
Kennung des Endkunden passt
nicht zum Konto
Kunden kontaktieren
BE04
908
Name/Id/Adresse
fehlerhaft
Name/Id/Adresse fehlerhaft
Adresse korrigieren
oder Kunden kontaktieren
BE05
928
Stammdaten/CI fehlt
oder fehlerhaft
CI falsch, Absender unbekannt
CI überprüfen und
Datei korrigieren
BE06
911
Auftraggeber/Zahlungsempfänger
unbekannt
BE07
914
SDD: Adresse des Zahlers
(Zahlungspflichtigen) fehlt
oder unvollständig
CNOR
933
SCT: Die Bank des Creditors ist
(im CSM) nicht registriert
BIC überprüfen; andere
Bankverbindung von Kunden
einholen
CURR*)
924
Falsche Währung
Siehe Fußnote *)
CUST*)
925
Rückruf durch Kunden
Siehe Fußnote *)
CUTA*)
926
Rückruf durch Ermittlungsersuchen
Siehe Fußnote *)
DNOR
932
SDD: Die Bank des Debtors ist
(im CSM) nicht registriert
BIC überprüfen; andere
Bankverbindung von Kunden
einholen
DUPL*)
920
Doppelzahlung
Siehe Fußnote *)
DT01
916
Datum fehlerhaft
Datum korrigieren
IBAN-Prüfziffer fehlerhaft
Fehlerhafter OperationCode
SCT: Die Bank des
Creditors ist nicht im
EBA-/SCL-Directory
SDD-Core: Die Bank des
Debitors ist nicht im
EBA-Directory
Datum fehlerhaft bzw.
nach Cut-off
Doppelte Zahlung
Fortsetzung
SEPA
Reason
Code
MT940/ HVB als Bank
DTI Text- des Einreichers
SL-Erg.
(SCT und SDD)
ED05
914
FF01
HVB als Creditor-Bank (SCT)
bzw. Debtor-Bank (SDD)
Auszug von wichtigen
Codes von Fremdbanken
Handlungsempfehlung
für den Einreicher
HVB: korrekte Transaktion
innerhalb Gesamtdateiablehnung
Die Begleichung der Transaktion
ist fehlgeschlagen
Ggf. Hausbank kontaktieren
911
Formatfehler
Formatfehler
Datei korrigieren
FF05
931
SDD: BIC nicht COR1-fähig
SDD: BIC nicht COR1-fähig
Als CORE einreichen
FOCR
919
SCT: Rückgabe aufgrund
eines Rückrufs (Recall)
durch Einreicher bzw.
einreichende Bank
SCT: Rückgabe aufgrund eines
Rückrufes (Recall) durch Einreicher
bzw. einreichende Bank
–
FRAD*)
922
Zahlung erfolgt in betrügerischer
Absicht
Siehe Fußnote *)
MD01
909
SDD: Kein gültiges Mandat
Kunden kontaktieren und ggf.
ein neues Mandat einholen
MD02
910
SDD: Mandatsdaten fehlerhaft
Mandatsdaten korrigieren
MD06
912
SDD: Widerspruch bis 8 Wochen
Kunden zur Klärung des
Mandatsstatus kontaktieren
MD07
913
Kontoinhaber verstorben
Kundenvertrag überprüfen
MS02
914
Sonstige Gründe
Kunden kontaktieren
MS03
914
Nur SDD: kein Mandat, bei B2B oder
Core-Refund bis 13 Monate oder
unwiderrufliche Lastschriftsperre
SDD: Mandatsdaten
fehlerhaft
SDD: Widerspruch bis 8 Wochen
Sonstige Gründe
Sonstiges, u. a. anonymisiert wegen: rechtlicher Vorschriften,
Kontosperre, mangels Deckung, verstorben
Kunden bzw. Vertragspartner
kontaktieren
RC01
915
BIC fehlerhaft
BIC fehlerhaft
RF01
907
Referenz ungültig/fehlt
Referenz ungültig/fehlt
Transaktion bzw.
Datei korrigieren
RR01
RR02
RR03
RR04
917
Aufsichtsrechtliche Gründe:
01: f ehlendes Konto/fehlende
ID des Zahlers
02: f ehlender Name/fehlende
Adresse des Zahlers
03: N
ame/fehlende Adresse
des Zahlungsempfängers
04: Sonstige
bzw. Kunden kontaktieren
SL01
918
Spezifische Dienstleistungen der
Bank des Zahlers
Kunden kontaktieren,
damit er die Mandatsdaten
des Einreichers bei seinem
Konto so einträgt, dass SDD
akzeptiert werden
TECH*)
921
Zahlung erfolgt irrtümlich wegen
technischer Probleme
Siehe Fußnote *)
TM01
916
Cut-off-Zeit überschritten
Ausführungsdaten anpassen
UPAY*)
927
Zahlung nicht berechtigt
Siehe Fußnote *)
SDD: Positiv-/Negativ-Liste
*W
iedergutschrift aufgrund eines Lastschriftrückrufs vor Settlement auf dem Konto des Zahlers (Request for Cancellation)
Die genaue Feldbelegung stellt Ihnen auf Anfrage Ihr Cash Management & eBanking-Spezialist
gerne zur Verfügung.
49
11.5 Payment Status Report/pain.002-SEPA Credit Transfer
Wichtige fachliche XML-Felder für pain.002-SEPA Credit Transfer
Feldnamen
GrpHdr
OrgnlPmtInf
50
Beschreibung
pain.002.003.03
Befüllung DFÜ-Abkommen 2.7
GroupHeader
Absenderdaten
MsgId
Bankreferenznummer pro Datei
Pflichtfeld
max. 35 Zeichen
CreDtTm
Pflichtfeld
ISO-Date
DbtrAgt
BIC des Kreditinstituts
Pflichtfeld nur SCT
8 bzw. 11 Stellen
OrgnlMsgId
Ursprüngliche Referenznummer der Kundeneinreichung
Originaldaten
OrgnlMsgNmId
Ursprünglicher XML-Dateityp
Originaldaten
OrgnlNbOfTxs
Ursprüngliche Anzahl aller Einzeltransaktionen
Originaldaten
OrgnlCtrlSum
Ursprüngliche Kontrollsumme in Euro
der Einreichung
Originaldaten
GrpSts
Status auf Dateiebene
Ein Status muss entweder auf Group-,
PmtInf- oder Transaction-Ebene
angegeben sein
RJCT-Reject
HVB: Status nur auf TransactionEbene. Bei Dateiablehnung werden
alle Transaktionen zurückgeliefert
StsRsnInf-Orgtr-Nm
Initiator Rückgabe Kunde
Nur zusammen mit GrpSts. Wenn
Orgtr-BICOrBEI gefüllt ist, nicht erlaubt
Name (max. 70 Zeichen)
= kundeninitiiert
StsRsnInf-Orgtr-Id-OrgIdBICOrBEI
Initiator Rückgabe Bank
Orgtr-Nm gefüllt ist, nicht erlaubt
BIC = bankinitiierte Rückgabe
StsRsnInf-Rsn
Rückgabegrund
Siehe Anhang mögliche Rückgabegründe lt. ISO 20022 Code-List
Original-PaymentInstruction-Information
und Status
Original-Auftraggeberdaten und Status
auf logischer Datei
Anzahl je nach Originaldaten
OrgnlPmtInfId
Ursprüngliche Referenz der Einreichung
Originaldaten
OrgnlNbOfTxs
Originaldaten
OrgnlCtrlSum
Ursprüngliche Kontrollsumme in Euro der
logischen Datei
Originaldaten
PmtInfSts
Status auf logischer Dateiebene
angegeben sein
RJCT-Reject
HVB: Status nur auf TransactionEbene. Bei Dateiablehnung werden
alle Transaktionen zurückgeliefert
StsRsnInf-Orgtr-Nm
Nur zusammen mit PmtInfSts.
Wenn Orgtr-BICOrBEI gefüllt ist,
nicht erlaubt
= kundeninitiiert
Nur zusammen mit PmtInfSts.
Wenn Orgtr-Nm gefüllt ist, nicht
erlaubt
StsRsnInf-Rsn
Rückgabegrund
pain.001
Abschnitt optional, wenn GrpSts
gefüllt
Fortsetzung
Feldnamen
CdtTrfTxInf
Beschreibung
pain.002.003.03
Abschnitt optional,
wenn PmtInfSts gefüllt
StsId
Bankreferenz der Rückgabe
Optional
Max. 35 Zeichen
OrgnlInstrId
Ursprüngliche technische Referenz zwischen
Einreicher und Bank
Originaldaten
OrgnlEndToEndID
Ursprüngliche Kundenreferenz
Originaldaten
TxSts
Status auf Transaktionsebene
angegeben sein
RJCT-Reject
StsRsnInf-Orgtr-Nm
Nur zusammen mit TxSts.
Wenn Orgtr-BICOrBEI gefüllt ist,
nicht erlaubt
= kundeninitiiert
Nur zusammen mit TxSts.
erlaubt
StsRsnInf-Rsn
Rückgabegrund
HVB: ED05 bei korrekter Transaktion innerhalb Gesamtdateiablehnung. Grundsätzlich wird nur ein
Rückgabegrund angegeben.
InstrAmt
Ursprünglicher Betrag und
Währungskennzeichen
Originaldaten
ReqdExctnDt
Ursprünglich gewünschter Ausführungstermin
Originaldaten
InstrPrty
Ursprüngliche Priorität der Ausführung
Originaldaten
„HIGH“ oder „NORM“
SvcLvl
Ursprüngliches Servicelevel
Originaldaten
„SEPA“
CtgyPurp
Ursprüngliche Zahlungsart der Datei
Originaldaten
PmtMtd
Ursprüngliches Zahlungsinstrument:
Credit Transfer
Originaldaten
„TRF“
Ustrd-RmtInf
Ursprünglicher unstrukturierter
Verwendungszweck
Originaldaten
Max. 140 Zeichen
Ursprünglicher strukturierter Verwendungszweck für VL-Leistung oder CreditorReference
Originaldaten
Strd-CdtrRefInf-CdtrRef
Ursprünglicher strukturierter VWZ Teil2
a) VL-Leistung: Bezugsjahr der vermögenswirksamen Leistung und Referenz alternativ
b) CreditorReference:
prüfzifferngerechte CreditorReference
Originaldaten
UltmtDbtr
Ursprünglicher, vom Kontoinhaber abweichender Auftraggeber
Originaldaten
Dbtr-Nm
Ursprünglicher Name Auftraggeber
Originaldaten
Dbtr-PstlAdr-Ctry
Ursprüngliches Land der Anschrift des
Auftraggebers
Originaldaten
Ursprüngliche Anschrift Auftraggeber
Originaldaten
DbtrAcct-IBAN
Ursprüngliche IBAN des Auftraggebers
Originaldaten
DbtrAgt-BIC
DbtrAgt-Id
Ursprünglicher BIC/SWIFT-Code der
Auftraggeber-Bank bzw. DbtrAgt-Id
bei IBAN-Only
Originaldaten
CdtrAgt-BIC
CdtrAgt-Id
Ursprünglicher BIC/SWIFT-Code der
Begünstigten-Bank bzw.CdtrAgt-Id
bei IBAN-Only
Originaldaten
Cdtr-Nm
Ursprünglicher Name Begünstigter
Originaldaten
Ursprüngliche Anschrift Begünstigter
Originaldaten
Cdtr-PstlAdr-Ctry
Begünstigten
Originaldaten
CdtrAcct-IBAN
Ursprüngliche IBAN des Begünstigten
Originaldaten
UltmtCdtr
Ursprünglicher abweichender Endbegünstigter
Originaldaten
51
11.6 Payment Status Report/pain.002-SEPA Direct Debit
Wichtige fachliche XML Felder für pain.002-SEPA Direct Debit
Feldnamen
GrpHdr
OrgnlPmtInf
CdtTrfTxInf
52
Beschreibung
pain.002.003.03
GroupHeader
Absenderdaten
MsgId
Bankreferenznummer pro Datei
Pflichtfeld
Max. 35 Zeichen
CreDtTm
Pflichtfeld
ISO-Date
CdtrAgt
Kreditinstitut-BIC
Pflichtfeld nur SDD
8 bzw. 11 Stellen
OrgnlMsgId
Ursprüngliche Referenznummer der Kundeneinreichung
Originaldaten
OrgnlMsgNmId
Ursprünglicher XML-Dateityp
Originaldaten
OrgnlNbOfTxs
Originaldaten
OrgnlCtrlSum
Einreichung
Originaldaten
GrpSts
Status auf Dateiebene
Ein Status muss entweder auf
Group-, PmtInf- oder TransactionEbene angegeben sein
RJCT-Reject
HVB: Status nur auf TransactionEbene. Bei Dateiablehnung
werden alle Transaktionen
zurückgeliefert
StsRsnInf-Orgtr-Nm
Orgtr-BICOrBEI gefüllt ist, nicht
erlaubt
= kundeninitiiert
Nur zusammen mit GrpSts.
erlaubt
StsRsnInf-Rsn
Rückgabegrund
Original-PaymentInstructionInformation und Status
Original-Auftraggeberdaten und Status auf
logischer Datei
OrgnlPmtInfId
Ursprüngliche Referenz der Einreichung
Originaldaten
OrgnlNbOfTxs
Originaldaten
OrgnlCtrlSum
logischen Datei
Originaldaten
PmtInfSts
Status auf logischer Dateiebene
RJCT-Reject
HVB: Status nur auf TransactionEbene. Bei Dateiablehnung
werden alle Transaktionen
zurückgeliefert
StsRsnInf-Orgtr-Nm
Nur zusammen mit PmtInfSts. Wenn
= kundeninitiiert
Nur zusammen mit PmtInfSts. Wenn
StsRsnInf-Rsn
Rückgabegrund
CreditTransfer-TransactionInformation
Abschnitt optional, wenn
PmtInfSts gefüllt
StsId
Bankreferenz der Rückgabe
Optional
Max. 35 Zeichen
OrgnlInstrId
Ursprüngliche technische Referenz zwischen
Einreicher und Bank
Originaldaten
OrgnlEndToEndID
Ursprüngliche Kundenreferenz
Originaldaten
TxSts
Status auf Transaktionsebene
RJCT-Reject
StsRsnInf-Orgtr-Nm
Nur zusammen mit TxSts. Wenn
= kundeninitiiert
Nur zusammen mit TxSts. Wenn
pain.008
Abschnitt optional, wenn
GrpSts gefüllt
Fortsetzung
Feldnamen
Beschreibung
pain.002.003.03
StsRsnInf-Rsn
Rückgabegrund
Siehe Anhang mögliche
Rückgabegründe lt.
ISO 20022 Code-List
InstrAmt
Ursprünglicher Betrag und
Währungskennzeichen
Originaldaten
ReqdColltnDt
Ursprünglich gewünschter Fälligkeitstermin
Originaldaten
CdtrSchmeId-Id-PrvtId-OthrId-Id
Ursprüngliche CreditorIdentification
Originaldaten
Prtry
Ursprüngliche Identifikation des Schemas
Originaldaten
„SEPA“
SvcLvl
Ursprünglicher Service
Originaldaten
„SEPA“
LclInstrm-Cd
Ursprüngliche Lastschriftart: Basislastschrift
oder Firmenlastschrift
Originaldaten
„CORE“, „COR1“ oder „B2B“
SeqTp
Ursprüngliche Sequenz: Erst-, Folge-, Einmaloder letztmalige Lastschrift
Originaldaten
„FRST“, „RCUR“, „OOFF“ oder „FNAL“
CtgyPurp
Ursprüngliche Zahlungsart der Datei
Originaldaten
PmtMtd
Ursprüngliches Zahlungsinstrument: Direct Debit
Originaldaten
Mndtld
Ursprüngliche Mandatsreferenz
Originaldaten
DtOfSgntr
Ursprüngliches Datum, zu dem das Mandat
unterschrieben wurde
Originaldaten
AmdmntInd
Ursprüngliches Kennzeichen, ob das Mandat
verändert wurde
Originaldaten
OrgnlMndtId
Ursprüngliche Referenz des alten Mandats,
falls sich die Mandatsreferenz (MndtId)
geändert hat
Originaldaten
OrgnlCdtrSchmeId-Nm
Ursprünglicher alter Creditor-Name, falls sich
der Zahlungsempfänger geändert hat
Originaldaten
OrgnlCdtrSchmeId-Id-PrvtIdOthrId-Id
Ursprüngliche alte CreditorIdentification, falls
sich die CreditorIdentification (CdtrSchmeIdI)
geändert hat
Originaldaten
OrgnlDbtrAcct-IBAN
Ursprüngliche alte IBAN des Zahlungspflichtigen, falls sich die IBAN geändert hat
Originaldaten
OrgnlDbtrAgt-Id
Ursprüngliche alte Debitor-Bank
Originaldaten
ElctmcSgntr
Ursprüngliches elektronisches Mandat –
eMandate-Signatur
Originaldaten
Ustrd-RmtInf
Ursprünglicher unstrukturierter
Verwendungszweck
Originaldaten
UltmtDbtr
Ursprünglicher vom Kontoinhaber
abweichender Zahlungspflichtiger
Originaldaten
Dbtr-Nm
Ursprünglicher Name Zahlungspflichtiger
Originaldaten
Dbtr-PstlAdr-Ctry
Zahlungspflichtigen
Originaldaten
Ursprüngliche Anschrift Zahlungspflichtiger
Originaldaten
DbtrAcct-IBAN
Ursprüngliche IBAN des Zahlungspflichtigen
Originaldaten
DbtrAgt-BIC
DbtrAgt-Id
Ursprünglicher BIC/SWIFT-Code der Zahlungspflichtigen-Bank bzw. DbtrAgt-Id bei IBAN-Only
Originaldaten
CdtrAgt-BIC
CdtrAgt-Id
Ursprünglicher BIC/SWIFT-Code der Zahlungsempfänger-Bank bzw. CdtrAgt-Id bei IBAN-Only
Originaldaten
Cdtr-Nm
Ursprünglicher Name Zahlungsempfänger
Originaldaten
Cdtr-PstlAdr-Ctry
Zahlungsempfängers
Originaldaten
Ursprüngliche Anschrift Zahlungsempfänger
Originaldaten
CdtrAcct-IBAN
Ursprüngliche IBAN des Zahlungsempfängers
Originaldaten
UltmtCdtr
Ursprünglicher abweichender Zahlungsempfänger
Originaldaten
HVB: ED05 bei korrekter Transaktion innerhalb Gesamtdateiablehnung. Grundsätzlich
wird nur ein Rückgabegrund angegeben.
„DD“
Veränderung = „true“
Standard = „false“
Kennzeichen „SMNDA“
Max. 140 Zeichen
53
11.7 Elektronischer Kontoauszug MT940
Obwohl die bisherigen SWIFT-Strukturen bei elektronischen Kontoauszügen und Vormerkposten im MT940
und MT942 unverändert bestehen bleiben, haben sich die Felder 61 und 86 im Format geändert. Mit den
SEPA-Produkten ergeben sich auch neue Geschäftsvorfallcodes.
54
Geschäftsvorfallcodes
Geschäftsvorfallcodes
GVC
Bezeichnung
GVC
Bezeichnung
1XX
ZAHLUNGSVERKEHR
191
SEPA Credit Transfer (Sammler-Soll)
104
SEPA Direct Debit (Einzelbuchung-Soll, B2B)
192
SEPA Direct Debit (Sammler-Haben, Core)
105
SEPA Direct Debit (Einzelbuchung-Soll, Core)
193
SEPA Direct Debit (Soll, Reversal)
108
SEPA Direct Debit (Soll; Rückbelastung, B2B)
Vor Buchung: SEPA-Reject (Soll; B2B)
194
SEPA Credit Transfer (Sammler-Haben)
109
SEPA Direct Debit (Soll; Rückbelastung, Core)
Vor Buchung: SEPA-Reject (Soll; Core)
195
SEPA Direct Debit (Sammler-Soll, Core)
196
SEPA Direct Debit (Sammler-Haben, B2B)
116
SEPA Credit Transfer (Einzelbuchung-Soll)
197
SEPA Direct Debit (Sammler-Soll, B2B)
119
SEPA Credit Transfer (Einzelbuchung-Soll,
Spendenzahlung)4
152
SEPA Gutschrift aus Dauerauftrag
(Einzelbuchung-Haben)5
153
SEPA Credit Transfer (Einzelbuchung-Haben,
Lohn-, Gehalts-, Rentengutschrift)1
154
vermögenswirksame Leistungen)2
156
Überweisung öffentlicher Kassen)3
159
SEPA Credit Transfer Retoure (Haben) für unanbringliche Überweisung (Rücküberweisung).
Vor Buchung: SEPA-Reject (Haben; Überweisung)
Struktur des Feldes 61/7 (Kundenreferenz) für
SEPA-Transaktionen
166
SEPA Credit Transfer (Einzelbuchung-Haben)
169
Spendenzahlung)4
171
SEPA Direct Debit Einreichung
(Einzelbuchung-Haben, Core)
Aus SCT oder SDD: Payment
• Wenn länger als 16 Stellen:
Information/Identification,
„KREF+“ und kompletter
falls bei der Einreichung nicht
Feldinhalt im Feld 86
gefüllt, Bulk-Message-ID
• Wenn leer: „NONREF“
174
SEPA Direct Debit (Einzelbuchung-Haben, B2B)
177
SEPA Credit Transfer Online (Einzelbuchung-Soll)
181
SEPA Direct Debit
(Haben; Wiedergutschrift, Core)
184
SEPA Direct Debit (Haben; Wiedergutschrift, B2B)
Generell gilt: „Core“ beinhaltet CORE und COR1.
1
Wird verwendet für folgende ISO-Codes aus dem Feld „Purpose“:
BONU, PENS, SALA und PAYR. Die Belegung des Feldes „Category Purpose“
wird ignoriert.
2
Wird verwendet für den ISO-Code CBFF aus dem Feld „Purpose“.
Die Belegung des Feldes „Category Purpose“ wird ignoriert.
3
Wird verwendet für folgende ISO-Codes aus dem Feld „Purpose“: GOVT,
SSBE, BENE. Die Belegung des Feldes „Category Purpose“ wird ignoriert.
4
Wird verwendet für den ISO-Code aus dem Feld „Purpose“: CHAR.
Die Belegung des Feldes „Category Purpose“ wird ignoriert.
5
Wird verwendet für den ISO-Code aus dem Feld „Purpose“: RINP (ab
Nov. 2013). Die Belegung des Feldes „Category Purpose“ wird ignoriert.
Inhalt
Bemerkung
Struktur des Feldes 61/9
Bei SDD-Rückgaben:
Einstellung des Ursprungsbetrages mit „OCMT“
(Ursprungsbetrag) und „CHGS“
(Summe aus Gebühren und ggf. Zinsausgleich)
Struktur des Feldes 86 für SEPA-Transaktionen
Pos. bzw.
Feldschl.
Bezeichnung
Die ersten
3 Zeichen
Länge/Format*,
bisher
Länge/Format*,
neu
Bemerkung
Geschäftsvorfallcode 3 n
Keine Änderung
Für SEPA werden spezifische GVCs
vergeben (1xx)
?00
Buchungstext
27 a
Keine Änderung
Für SEPA werden spezifische Buchungstexte
vergeben
?10
Primanoten-Nr.
10 x
?20–?29
Verwendungszweck
10 mal 27 x
Keine Änderung
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 + [RUECKUEBERWEISUNG
bzw. RUECKLASTSCHRIFT und Rückgabegrund
im Klartext]
?30
BLZ Überweisender/
Zahlungsempfänger
12 n
12 x
?31
Kto.-Nr. Überweisender/Zahlungsempfänger
24 n
34 x
IBAN anstelle der Kontonummer
?32–?33
Name Überweisender/Zahlungsempfänger
2 mal 27 x
Keine Änderung
SEPA-Länge 70; gekürzt auf 54 (2 x 27)
?34
Textschlüsselergänzung
3n
Keine Änderung
Nutzung einer Mapping-Tabelle zur Umwandlung des vierstelligen SEPA-Rückgabecodes in
einen dreistelligen Code
?60–?63
Verwendungszweck
4 mal 27 x
Keine Änderung
Ggf. Fortsetzung von ?20–?29
* n = numerisch, a = alphabetisch, x = alphanumerisch
55
12. Internationale SEPA-Formate
Die Länderformate
Wenn Sie nicht (nur) in Deutschland SEPA-Dateien einreichen wollen, bietet das ISO-20022-XML-Format hierzu
mehrere Möglichkeiten:
• Länderspezifische Varianten (Multi-Banken-Standard), z. B.
Deutschland – DK:
www.ebics.de/index.php?id=77
Österreich – STUZZA:
www.stuzza.at/461_DE?active2=10680
Italien – CBI:
www.cbi-org.eu/Engine/RAServePG.php/P/255010010407/T/Technical-Standards
• Die Länder-Subsets basieren auf dem ISO-20022-Standard.
• Sie werden meist von allen nationalen Banken angenommen.
• Die Formate haben detailliertere Prüfschemata (XSD) für korrekte SEPA-Feldbelegung.
• Auch mit den Länder-Subsets können selbstverständlich SEPA-Transaktionen europaweit abgewickelt werden.
Oder Sie verwenden internationale Formate auf Basis ISO 20022, wenn Sie nicht länderindividuell die jeweiligen
Kunde-Bank-Formate einsetzen möchten:
Das europäische SEPA-Basisformat EPC
Folgende Besonderheiten ergeben sich bei der Verwendung des SEPA-EPC-Formats:
• Es definiert lediglich die SEPA-Produkte (SEPA CT, SEPA DD CORE/COR1 und SEPA DD B2B).
• Akzeptanz bei der Einreicherbank muss für jede Formatvariante neu geprüft werden.
56
Unterschiede zwischen EPC und dem deutschen DK-Format:
• Im Gegensatz zu der DK-DFÜ-Anlage 3 mit den detaillierten Formatbeschreibungen und den XML-Schemata
zur direkten Dateiprüfung gibt es für das EPC-Format nur grobe Beschreibungen.
• Für das EPC-Format sind die allgemeinen XML-Schemata auf www.iso20022.org/payments_messages.page
zu verwenden, mit der fachlichen Formatbeschreibung aus den EPC-Implementierungsregeln
(Customer-to-Bank Inplementation Guidelines) unter www.europeanpaymentscouncil.eu
• E PC basiert wie beim DK-Format auf ISO 20022, es werden nur Felder im Rahmen des SEPA-Spektrums genutzt.
• Vom DK-Format abweichender Name-Space/Header:
• S CT: pain.001.001.03 statt pain.001.003.03
• SDD: pain.008.001.02 statt pain.008.003.02
• S tatus-Info: pain.002.001.03 statt pain.002.003.03
•K
eine Container-Varianten möglich
• Die fachliche Formatbeschreibung bzw. Feldbelegung weicht zwischen EPC und DK nur geringfügig
voneinander ab.
CGI – Common Global Implementation (Format) Initiative
Ziel der Initiative ist es:
• einen gemeinsamen globalen Standard
• auf Basis von ISO 20022 Payment-Nachrichten
• für die Kunde-Bank-Schnittstelle
• für alle Zahlungsverkehrsprodukte
zu definieren.
Die Kernpunkte sind:
• Gleiche Satzstrukturen für alle Arten von Zahlungen bei allen Banken – weltweit
(Schaffen eines Multi-Banken-Standards, aber nur im Kunde-Bank-Umfeld)
• Das richtige Format für die zukünftige Planung für weltweit tätige Konzerne,
die Inlandszahlungsverkehr und Auslandszahlungsverkehr auf XML umstellen wollen
• Es können alle Währungen und sonstige Informationen mitgegeben werden,
müssen aber mit jeder Bank bilateral abgestimmt werden.
• CGI-XML basiert auf ISO 20022 XML ohne Beschränkungen, aber unter Berücksichtigung
nationaler Regeln und/oder Regeln einer Community (z. B. SEPA).
• Forum für Banken und Bankenverbände, Corporates, Verbände und Händler entwickeln diesen
Standard weiter (derzeitige Teilnehmer: 45 Corporates und 35 Banken (darunter auch die UniCredit).
• www.swift.com/cgi
57
• Das CGI-Format ist allerdings extrem komplex und eignet sich derzeit nur für einzelne Großkunden:
• derzeit nehmen nur wenige Banken das Format entgegen.
• die vielfältigen Felder (über 500 nutzbare ISO-Felder) im Interbankenverkehr werden auf weniger als
150 Felder reduziert und somit ist die Information für den Zahlungsempfänger nur sehr eingeschränkt.
• eine bilaterale Vereinbarung mit Banken bei etwa 20 % der Feldbelegungen notwendig ist.
• eine bilaterale Vereinbarung über die Berücksichtigung von Codewörtern auch mit den Banken bzw. den
Zahlungsempfängern notwendig ist.
• vom DK-Format abweichender Name-Space/Header:
• SCT: pain.001.001.03 statt pain.001.003.03
• SDD: pain.008.001.02 statt pain.008.003.02
• Status-Info: pain.002.001.03 statt pain.002.003.03
• keine Container-Varianten möglich
• die fachliche Formatbeschreibung bzw. Feldbelegung weicht zwischen CGI und DK sehr stark voneinander ab.
Der File-Header zeigt, um welches Format es sich handelt
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.003.03"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-> DK-Version 2.7
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-> ISO-Version V3 von 2009
58
Grafischer Überblick ISO-20022-Payments-Formate
ISO 20022
Basis-Standard
CGI
Empfohlenes
Format vom
EPC
DK
Länder-Varianten-XSD
ISO-20022-XSD
EPC
STUZZA
CBI
Länder-Subsets
Kurzvergleich der DK/EPC/CGI-Formate
Ziel-Produkte
Deutsches DK-Format
Europäisches EPC-Format
Internationales CGI-Format
Verwendungszweck
oder ein Teil der strukturierten Verwendungszwecke. Max. 140 Stellen
oder ein Teil der strukturierten Verwendungszwecke. Max. 140 Stellen
700 Stellen unstrukturierter Verwendungszweck und große Variation von
strukturierten Verwendungszwecken
Adressangaben
Unstrukturierte Adresszeilen
(2 x 70 Zeichen)
Unstrukturierte Adresszeilen
(2 x 70 Zeichen)
Strukturierte und Unstrukturierte
Adresszeilen (bis 7 x 70 Zeichen)
Organisational und Person IDs
Optional
Teilweise verpflichtend
Teilweise verpflichtend
Interbankendurchgängigkeit der
Informationen (z. B. Adressangaben,
Verwendungszweck, IDs …) bei SEPAZahlung. Kommt die Information bei der
Empfänger-Bank an?
Ja, gewährleistet, da alle DK-Felder
auf Basis des EPC-Formats entwickelt
wurden
Ja, gewährleistet, da im SEPAInterbankenverkehr das EPC-Format
angewendet wird
Nein, nur EPC-Felder und EPC-maximale
Feldbelegungen werden durchgeleitet
Bankenerreichbarkeit
Alle deutschen Banken
Viele europäische Banken
Hauptsächlich die 35 CGI-Banken
Bankenstandard
Deutscher Multi-Banken-Standard
Annahme ist mit Bank abzustimmen
Über 20 % der Felder sind bilateral zu
vereinbaren.
Prüfschema (XSD)
Ja, eigenes vorhanden
Nur ISO 20022
Nur ISO 20022
59
Welches Format ist für Sie sinnvoll?
Vorgehen/Entscheidungskriterien:
• Definieren Sie, welche Produkte umgesetzt werden sollen (SEPA, Auslandszahlungsverkehr, Urgent, Auszüge, …)
bzw. mit welchen Zahlungsverkehrsprodukten Sie anfangen möchten.
• Definieren Sie dann, welche speziellen Informationen Sie über die Zahlung transportieren möchten:
• Reicht Ihnen der unstrukturierte Verwendungszweck oder benötigen Sie auch den strukturierten
Verwendungszweck?
• Benötigen Sie die Durchleitung von Ultimates oder zahlen Sie „On Behalf“?
• Wollen Sie die besonderen Organisational IDs oder Private IDs nutzen?
• Wir empfehlen Ihnen, auf jeden Fall die Standardfelder unabhängig vom Format zu nutzen:
• Unstrukturierte Adresszeilen
• Maximale Belegung berücksichtigen: Adresse (2 x 70), Name (70), Verwendungszweck (140)
• Starten Sie auf Basis der EPC-Felder bzw. Interbankendurchgängigkeit (mit EPC und DK gewährleistet).
• Für die Bestimmung des technischen Formats ist auch wichtig:
• Bankenerreichbarkeit. Ist Ihre Bank mit dem Format erreichbar? (Die HVB nimmt neben dem DKauch seit 2012 die EPC- und CGI-Formate an.)
Für weitere Informationen und für genaue Spezifikationen der Felder, die bei der HVB für die DK-, EPC- und CGIFormate angenommen werden, wenden Sie sich bitte an Ihren Cash Management & eBanking-Spezialisten.
60
13. T aggleiche Eilüberweisungen
in Euro via pain.001
Mit V2.7 des DFÜ-Abkommens können taggleiche Eilüberweisungen in der Währung EUR (innerhalb Deutschlands oder grenzüberschreitend in alle EU/EWR-Länder) auch über das ISO-20022-Format pain.001 mit der
EBICS-Auftragsart CCU eingereicht werden.
Da grundsätzlich Eilüberweisungen als Individualzahlungen verarbeitet werden, wird für bestimmte Felder die
Nutzung auf Transaktionsebene empfohlen statt auf Dateiebene in PaymentInformation, wie es im SEPAMassenzahlungsverkehr üblich ist. Die HVB ermöglicht auch bei Eilüberweisungen die Nutzung von IBAN-Only,
sofern es sich um rein innerdeutsche EUR-Transaktionen ohne Sonderweisungen handelt (Feldbelegung siehe
Kapitel zu „IBAN, IBAN-Only“).
Wichtige fachliche XML-Felder für SEPA Credit Transfer
Feldnamen
Beschreibung
pain.001.003.03
Befüllung
DFÜ-Abkommen 2.7
GrpHdr
GroupHeader
Absenderdaten
MsgId
(Message-Id)
Einreicher-Referenznummer pro Datei
Max. 35 Zeichen
CreDtTm
(CreationDateTime)
Pflichtfeld
ISO-Date
NbOfTxs
Pflichtfeld
Unbegrenzt
CtrlSum
(ControlSum)
Kontrollsumme in Euro der Einreichung
Empfohlen
Unbegrenzt
InitgPty
(InitiatingParty)
Einreicher
Pflichtfeld
Name Einreicher (kann vom Namen des
Auftraggebers abweichen)
Auftraggeberdaten
empfohlen max. 100
PmtInfId
(PaymentInformation-ID)
Pflicht
Max. 35 Zeichen.
Falls InstrId auf Transaktionsebene nicht
gefüllt ist, dann werden die ersten 27 Zeichen
der PmtInfId im Zielformat übernommen.
PmtMtd
(PaymentMethod)
Zahlungsinstrument:
Credit Transfer
Pflicht
„TRF“ – Credit Transfer
NbOfTxs
Optional
Unbegrenzt
CtrlSum
(ControlSum)
Kontrollsumme in Euro der logischen Datei
Optional
Unbegrenzt
SvcLvl-Cd
(ServiceLevelCode)
Service-Schema
Pflicht
„URGP“ – Urgent Payment
PmtInf
61
Fortsetzung
Feldnamen
Beschreibung
pain.001.003.03
Befüllung
DFÜ-Abkommen 2.7
PmtInf
Auftraggeberdaten
Beliebig oft möglich,
empfohlen max. 100
CtgyPurp
(CategoryPurpose)
Optional
„INTC“ – Intra Company Payment
„CORT“ – Trade Settlement Payment
Alle anderen Codes werden ignoriert.
ReqdExctnDt
(RequestedExecution Date)
Gewünschter Ausführungstermin
Pflichtfeld
ISO-Date, max. 15 Tage in die Zukunft.
Ein Datum in der Vergangenheit wird auf
den nächstmöglichen Arbeitstag gesetzt.
Dbtr-Nm
(DebtorName)
Name Auftraggeber, wird von der Bank mit den
Stammdaten des Kontoinhabers überschrieben
Pflichtfeld
Max. 70 Zeichen
Dbtr-PstlAdr-Ctry
(DebtorCountry)
Land der Anschrift des Auftraggebers
Optional
Ländercode ISO 3166, DE für Deutschland
(DebtorAddress)
Anschrift Auftraggeber, wird von der Bank
mit den Stammdaten des Kontoinhabers
überschrieben
Optional
Max. 2 x 70 Zeichen
DbtrAcct-IBAN
(DebtorIBAN)
IBAN des Auftraggebers
Pflichtfeld
Max. 34 Zeichen
DbtrAcct-Ccy
(DebtorAccountCurrency)
Währung des Auftraggeberkontos
Optional
Währungscode
„EUR“
DbtrAgt-BIC
(DebtorAgentBIC)
BIC/SWIFT-Code des Auftraggebers
(IBAN-Only), sonst
Pflichtfeld
8 bzw. 11 Stellen
HYVEDEMM(XXX).
DbtrAgt-Othr-Id
(DebtorAgentId)
von IBAN-Only für
Deutschland.
„NOTPROVIDED“
ChrgBr
(ChargeBearer)
Preis-Verrechnung
Optional
Empfohlen auf Ebene CdtTrfTxInf.
„SHAR“ – Shared
Wenn unbelegt, dann ist Default „SHAR“.
Weisungen hier gelten für alle Transaktionen.
empfohlen max. 10.000
InstrId
(Instruction-ID)
Technische Referenz zwischen Einreicher
und Bank
Empfohlen, wenn
gefüllt: eindeutig
Max. 35 Zeichen.
Wenn gefüllt, dann werden die ersten 27
Zeichen in die Einzeltransaktion im Zielformat
übernommen. Siehe auch PmtInfId
EndToEndID (End2End-ID)
Referenz wird bis Begünstigten über den
Verwendungszweck durchgereicht
Pflichtfeld
(eindeutig, sonst:
„NOTPROVIDED“)
Max. 35 Zeichen.
Wird in die erste Zeile des Verwendungszwecks
des Zielformats übernommen, siehe *.
Steht „NOTPROVIDED“ in diesem Feld, erfolgt
kein Mapping.
InstrAmt
(Instructed Amount)
Pflichtfeld
Betrag und Währungscode, wobei nur 10
Vorkommastellen möglich sind
ChrgBr
(ChargeBearer)
Preis-Verrechnung
Empfohlen
„SHAR“ – Shared
Wenn unbelegt, dann ist Default „SHAR“.
CdtTrfTxInf
62
Fortsetzung
Feldnamen
Beschreibung
pain.001.003.03
Befüllung
DFÜ-Abkommen 2.7
CdtTrfTxInf
empfohlen max.
100.000
CdtrAgt-BIC
(CreditorAgentBIC)
BIC/SWIFT-Code der Begünstigten-Bank
(IBAN-Only), sonst
Pflichtfeld
8 bzw. 11 Stellen.
Zusätzlich bei HVB auch möglich:
„NOTPROVIDED“ oder „NOTAVAIL“
Cdtr-Nm
(CreditorName)
Name Begünstigter
Pflichtfeld
Max. 70 Zeichen, wird mit den nachfolgenden
Feldern Ctry sowie AdrLine zusammengesetzt
und auf 140 Zeichen im Zielformat gekürzt
Cdtr-PstlAdr-Ctry
(CreditorCountry)
Land des Begünstigten
Pflichtfeld
Ländercode ISO 3166.
Siehe auch Cdtr-Nm
(CreditorAddress)
Anschrift Begünstigter
Optional
Max. 2 x 70 Zeichen.
Siehe auch Cdtr-Nm
CdtrAcct-IBAN
(CreditorAccount)
IBAN des Begünstigten
Pflichtfeld
Max. 34 Zeichen
InstrForDbtrAgt
(InstructionForDebtorAgent)
Instruktionen an die Bank des Einreichers für
Zahlungsbestätigung an Begünstigten
Optional
Wegen des Zielformats max. 25 Zeichen
Freitext, z. B. „FAX-NR 12345“
Ustrd-RmtInf
(UnstructuredRemittanceInfo)
Empfohlen
Zusammen mit EndToEndIdentification
werden nur max. 140 Zeichen in das Zielformat
übernommen, siehe *.
Strd-RmtInf
(Structured RemittanceInfo)
Nur wenn kein unstrukturierter Verwendungszweck
Zusammen mit EndToEndIdentification werden
nur max. 140 Zeichen Inhalt ohne XML-Tags
in das Zielformat übernommen, siehe *.
*U
m so viele Informationen wie möglich zu transportieren, wird seitens der HVB folgendes durchgeführt: Wenn EndToEndIdentification benutzt wird und ungleich „NOTPROVIDED“ ist, dann wird diese in die ersten 35 Zeichen der 4 x 35 Zeichen des Verwendungszwecks des Zielformats gestellt, und der Rest wird mit den ersten 105 Zeichen des Verwendungszwecks gefüllt (beim strukturierten Verwendungszweck nur der Inhalt ohne XML-Tags). Wenn nicht, dann werden alle 140 Zeichen übernommen. Des Weiteren wird
der PurposeCode übernommen, falls am Ende noch Platz ist.
63
50062040
Hinweis
Diese Kundeninformation dient lediglich zu Informationszwecken und bietet einen allgemeinen Überblick über das geplante Leistungsangebot zu SEPA. Die allgemeinen
Angaben in diesem Informationsschreiben beziehen sich auf SEPA-Produkte, wie sie zum Zeitpunkt der Erstellung dieses Schreibens (September 2013) 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.
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
Volker Oppermann
80538 München
E-Mail: sepa@unicreditgroup.de
E-Mail
sepa@unicredit.de
E-MAIL
Online
www.hvb.de/SEPA
ONLINE
UniCredit Bank AG
Corporate & Investment Banking
Global Transaction Banking
Am Tucherpark 1
80538 München
Stand September 2013. Alle Angaben beruhen auf der bei Drucklegung geltenden Gesetzes- und Rechtslage.
BRANCH
Filiale
Alle Filialen finden Sie im Internet unter
www.hvb.de/filialfinder

Anlage zur SEPA- Kundeninformation

Transcription

Similar documents

SEPA-Leitfaden

Handbuch SEPA Datenformate (pdf 2,4MB)

SEPA - Bank Austria

Service-orientierte Architektur für einen eCommerce B2B Marktplatz

Preis- und Leistungsverzeichnis

Amtsblatt Nr. 3 vom 23. Februar 2007

GVC-Langtexte in COINFOIM

Technische Spezifikationen der Deutschen Bundesbank für die

Juni 13 - Sparkasse Neuwied

Präsentation Bawag P.S.K.

Nr. 01/2015 - Gemeinde Mühlenbecker Land

Anleitung Erfassung von SEPA-Lastschriften im Onlinebanking