Anlage zur SEPAKundeninformation

Technische Spezikationen und Formate

Aktualisierte Auage Stand 02/2013

Inhalt
1.  Dateiformate und SEPA-Verfahren der aktuelle Stand in Deutschland 2.  Zusammenhang der Kunden- und Bankformate (ISO20022) 3. SEPA-Kundenformate 4.  Ausblick neue DF-Version 2.7/ November 2013 5. Nachrichtentypen-Erkennung 6. Aufbau der Kundendatei (XML*) 7. SEPA Credit Transfer (SCT) 8. Beispiel einer Kunden-Datei 9. SEPA Direct Debit (SDD) 10.   SEPA hug genutzte Zahlungsinformationen im Format 10.1 Verwendungszweck/RemittanceInfo 10.2 Zahlungsgrund/Purpose Code 10.3 Produktkategorie/Category Purpose 10.4 Fnf Beteiligte in einer SEPA-Nachricht 10.5 Name, Adresse 10.6 IBAN 10.7 Glubiger-Identikation/CI 5 6 6 7 9 11 13 16 17 21 21 23 24 24 25 26 27 11. Reporting (Bank-Kunde) 11.1 Reporting (Bank-Kunde) 11.2 Buchung von SEPA Dateien 11.3 Status/Fehler Nachricht pain.002 11.4 Rckgabegrnde 11.5  Payment Status Report/ pain. 002-SEPA Credit Transfer 11.6  Payment Status Report/ pain.002-SEPA Direct Debit 11.7 Elektronischer Kontoauszug MT940 12. Internationale SEPA Formate 40 40 40 42 44 46 48 50 52

10.8 Identikations-Nummern (OrgID/PrivateID)28 10.9  Ultimate/Reference Party/On Behalf 29 10.10 Mandatsnderung/ Mandate-Amendment30 10.11 Lastschriftsequenz 10.12 Zeichensatz und Umlaute 10.13  Konkurrierende Felder XOR 10.14 Referenz-Nummern und deren Verwendung 33 35 36 37

4 Fr die Umstellung auf SEPA mssen Datenfelder in ihren Systemen entsprechend angepasst werden. In der vorliegenden Broschre erhalten Sie wesentliche Details zu den technischen Spezikationen und verschiedenen SEPA Formaten. Bei den nachfolgenden Informationen handelt es sich um eine Empfehlung. Grundlage hierfr ist das DF-Abkommen. Auf den nchsten Seiten dieser Broschre nden 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 Schnittstellenspezikation fr die Datenfernbertragung zwischen Kunde und Kreditinstitut gem DF-Abkommen Version 2.6 vom 18.06.2012, gltig ab 17. November 2012 www.ebics.de/index.php?id=77 Weitere Informationen zur nalen Beschreibung der Formate erhalten Sie bei folgenden Stellen: Die Deutsche Kreditwirtschaft (DK) Anlagen zum Kapitel 2, SEPA-Zahlungsverkehr der Version 2.6 der Anlage 3 Stand: Finale Version vom 18.06.2012 XML-Schemata fr SEPA www.ebics.de/

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) fr XML.  XML ist ein offener Standard  Keine feste Vorgabe von Feldbelegungen  Grer 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 jhrlich weiterentwickelt  ISO 20022 als XML basiertes Format bildet die Grundlage fr den modernen globalen Zahlungsverkehr und bietet eine sehr groe Bandbreite und dadurch eine entsprechende Variabilitt an  SEPA macht den Anfang einer durchgngigen ISO20022 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>

Fr die Kunde-Bank-Beziehung wurde das Pain-Format (Payment Initiation) festgelegt.

2.  Zusammenhang der Kunden- und Bankformate (ISO20022)

Kunden reichen bei Banken das pain-Format fr Zahlungsdateien ein. Im Interbankenverhltnis werden die Zahlungen dann zwischen den Banken mit dem pacs-Format ausgetauscht. Der Kunde erhlt dann ber die Buchungen als Kontoinformation das camt-Format optional zur Verfgung gestellt. Fehler/Rejects knnen optional an den Kunden auch im pain-Format als Datei von der Bank zur Verfgung gestellt werden.
Zahlungsauftrag pain = Payment initiation Zahlungsverkehrsinitiierung fr berweisungen (pain.001) Lastschriften (pain.008) pacs = Payment clearing & settlement Clearing fr berweisungen (pacs.008) Lastschriften (pacs.003) camt = cash management Konto-Informationen Avis (camt.052) Auszug (camt.053) DTI (camt.054) Kundeninformation Fehlerinformation pain = Payment Initiation FehlerNachrichten Fehler-Meldung/Statusmessage (pain.002) pacs = C&S Fehler-Nachrichten Fehler-Meldung/Statusmessage

pain
Kunde

pain

pacs
Bank

pacs

camt
Kunde

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) November 2008 (DF Anlage 3 Version 2.3)  keine Format nderungen November 2009 (DF Anlage 3 Version 2.4)  Start SEPA-Basislastschrift (Direct Debit Core) & SEPA-Firmenlastschrift (Direct Debit B2B)  Grouping Standard vereinheitlicht nur noch MIXED analog European Payments Council (EPC) Vorgaben  Optional: Zahlungsgrnde standardisiert (ber 100 Purpose-Codes) z. B. Gehalt, Vermgenswirksame Leistungen, ffentliche Kassen  Optional: Zustzliche Namensfelder fr Dritt-Beteiligte: Ultimative Creditor/Debtor  Optional: Denition der Formate fr XML Auszug (camt.052, camt.053, camt.054)

7 November 2010 (DF Anlage 3 Version 2.5) S  ummenfelder (Betrag, Posten & Referenz) auf Sammlerebene (PaymentInfo)  Restrukturierung der Reject pain.002-Nachricht auf Kundenbedrfnisse  Strukturierte Rckmeldung im MT940/MT942/DTI von Retouren-Gebhren  Rckgabegrund FOCR aufgrund SCT-Rckruf nach Buchung (Recall)  Optional: Zahlungsgrund Spende (PurposeCode=CHAR)  Optional: Prfzifferngerechte CreditorReferenz auf berweisungsbelegen November 2011 keine neuen Formate November 2012 (DF Anlage 3 Version 2.6)  keine Format nderungen  Rckgabegrund AC13 wenn Zahlungspichtiger ein Verbraucher ist und FF05 wenn Lastschrift mit verkrzter Vorlauffrist COR1 nicht mglich ist Hinweis: Jedes Jahr im November tritt meist ein neues Rulebook, das die Grundlage fr die fortschreitenden Anpassungen an die aktuellen Bedrfnisse bildet, in Kraft. Das EPC Rulebook 7.0 wird allerdings erst mit dem Migrationsdatum 1.2.2014 umgesetzt. Fr Sie bedeuten diese jhrlichen Rulebook-nderungen, dass Sie gegebenenfalls auch Anpassungen in den Formaten vornehmen mssen. Die Deutsche Kreditwirtschaft hat vereinbart, dass grundstzlich immer die aktuelle Formatversion und die Vorgngerversion angenommen werden sollen. Die HVB nimmt darberhinaus auch noch ltere Versionen an. Fr Nutzung neuer Funktionalitten mssen allerdings auch die entsprechenden Formaten verwendet werden.

4.  Ausblick nderungen fr November 2013

Zum 4. November 2013 ist geplant, eine neue DF-Anlage 3, Version 2.7 einzufhren (Verffentlichung im April 2013). Welche nderungen werden derzeit diskutiert (Stand Januar 2013):  Es wird eine neue XML-Version fr die Formate auch mit neuen Prfschemata (XSD) zur Abdeckung der fachlichen nderungen (insb. wegen IBANonly, COR1 und URGP) notwendig: Version 2.5 Version 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 verkrzter Vorlauffrist COR1 (D-1)  Die COR1 Basislastschrift wird zum November 2013 deutschlandweit eingefhrt  Fr den EBICS-Standard ist die Auftragsart CD1 bzw C1C (Container) zu verwenden  Im Localinstrument-Code des pain.008.003.02 wird der Code COR1 verwendet D  ie HVB nimmt bereits vor der deutschlandweiten Einfhrung COR1 Basis-Lastschriften im pain.008.002.02 und pain.008.001.02 entgegen, wenn der Zahlungspichtige bei der HVB ist
<LclInstrm> <Cd>COR1</Cd> </LclInstrm>

8  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 gleichtgiger Valuta als Einzelzahlung an die Bank des Begnstigten via Target bertragen  Es ist keine Sammler-Zahlung aus dem Massenzahlungsverkehr sondern eine Individual-Zahlung und fllt daher nicht unter die SEPA-Produkte  Eilzahlungen (XML-Variante fr die bisherigen DTE-Zahlungen) knnen mit der Auftragsart CCU im pain.001.003.03 und dem Service-Level URGP bertragen werden. Die HVB nimmt bereits vor der deutschlandweiten Einfhrung im pain.001.002.03 und pain.001.001.03 entsprechende Eilzahlungen entgegen. Hierzu sind besondere Feldbelegungen ntig, um alle relevanten Informationen an den Empfnger weiterzuleiten. Felder wie CategoryPurpose, Debtior-ID, UltimateDebtor, Creditor ID, und UltimateCreditor knnen nicht weitergeleitet werden, Felder wie PurposeCode und End2End-ID werden von der HVB in den Verwendungszweck gestellt Die Produktbroschre und weitere Detailbeschreibungen zur Feldbelegung erhalten Sie bei Ihrem Cash Management & eBanking Spezialisten
<SvcLvl> <Cd>URGP</Cd> </SvcLvl>

 IBANonly bzw. optionaler BIC  Die Angabe des BICs wird zum 1.2.2014 optional fr Zahlungen innerhalb Deutschlands. Da das DF-Abkommen Anlage 3 schon fr den November 2013 angepasst wird und nicht nochmal mehr im Februar 2014, sind die nderungen bereits hier angepasst  Bei der SEPA-berweisung wrde das, dann optionale, Feld <CdtrAgt> ganz weg gelassen  Bei der SEPA-Lastschrift bleibt das Feld <DbtrAgt> weiterhin ein Pichtfeld, aber es kann dann, statt dem optionalen Feld <BIC>, der Wert NOTPROVIDED in das Feld <Id> eingestellt werden
<DbtrAgt> <FinInstnId> <BIC>HYVEDEMMXXX</BIC> </FinInstnId> </DbtrAgt>

Neu ab Nov 2013 optionaler BIC fr nationale Zahlungen:

<DbtrAgt> <FinInstnId> <Othr> <Id>NOTPROVIDED</Id> </Othr> </FinInstnId> </DbtrAgt>

 Sonstige geplante nderungen  Altformate werden ab 2/2014 abgeschafft (z.B. DTA-berweisung/DTA-Lastschrift) Ausnahme Kartenzahlungen wie ELV sowie elektronische Schecks und DTE  In Diskussion ist das optionale Zulassen von deutschen Umlauten , , , , , , und verschiedenen Sonderzeichen  Rckgabegrund-Liste wird erweitert (CNOR/DNOR, wenn die Bank ber das Clearing nicht erreichbar ist)  Weitere PurposeCodes fr Gehalt (PAYR Payroll mit GVC 153) und Dauerauftragsgutschrift (RINP mit GVC 152)

5.  Nachrichtentypen-Erkennung
Wie erkennen Sie um welche Nachricht und welche Version es sich handelt? Aufbau einer XML Nachrichtenbezeichnung: pain.001.002.03 Version Variante

V3 ISO-Stand 2009

Die Deutsche Kreditwirtschaft

Nachricht/Message-Denition
CustomerCreditTransferInitiation

Geschftsfeld/Business-Aresa
Payment Initiation

pain.001.002.03 Business-Area  pain PAymentINnitiation Message-Denition 001 berweisung CustomerCreditTransferInitiation 008 Lastschrift DirectDebitInitiation 002 CustomerPaymentStatusReport (Reject) 007 CustomerPaymentReversal (Lastschriftsstorno) 009 bis 012 Mandats-Initierung, -nderung, -Storno und -Akzeptanz  Variante 002 ZKA/DK Version 001 IS020022/EPC  Version 03 Version 2010/2012 02 Version 2009 01 Version 2008  camt CAshMAnagement 052 BanktoCustomerAccountReport ZV-Avis MT942-Nachfolger 053 BanktoCustomerStatement Kontoauszug MT940-Nachfolger 054 BanktoCustomerDebitCreditNotification Sammler DTI-Nachfolger 055 CustomerPaymentCancellationRequest KundenRckruf 086 Bank Service Billing (ehem. TWIST-BSB)

in Planung in Planung

in Planung

10 Beauftragung einer SEPA Credit Transfer - Kunden-Format Folgende Auftragsarten sind ber die bertragungswege (EBICS/HBCI bzw. FinTS) mglich
SEPA Auftragsarten Credit Transfer DK-Format Namespace/Schema
EBICS-mixed EBICS-mixed Sonderprozess ohne VEU-Details EBICSXML-Container EBICS-Reject urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 urn:conxml:xsd:container.nnn.002.02 (+urn:iso:std:iso:20022:tech:xsd:pain.001.002.03) urn:iso:std:iso:20022:tech:xsd:pain.002.002.03

SCT 2.5 (2010) 2.6 (2012)

CCT pain.001.002.03 XCT pain.001.002.03 CCC pain.001.002.03 CRZ (Zip-Container) oder CRC (XML-Container) pain.002.002.03 HKCCM, HKCME HKCCS, HKCSE

HBCI-Sammel HBCI-Einzel

ltere Versionen des DF-Abkommens werden von der HVB auch noch akzeptiert:  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:  DF-Abkommen 2.4 (2009): pain.002.002.02  DF-Abkommen 2.3 (2008): pain.002.001.02 Beauftragung einer SEPA Direct Debit - Kunden-Format Folgende Auftragsarten sind ber die bertragungswege (EBICS/HBCI bzw. FinTS) mglich
SEPA Auftragsarten Direct Debit Namespace/Schema
EBICS-mixed EBICS-XML-Container urn:iso:std:iso:20022:tech:xsd: pain.008.002.02 urn:conxml:xsd:container.nnn.002.02 (+urn:iso:std:iso:20022:tech:xsd: pain.008.002.02) urn:iso:std:iso:20022:tech:xsd: pain.002.002.03

SDD Core 2.5 (2010)/2.6 (2012)

CDD pain.008.002.02 CDC pain.008.002.02 CDZ (Zip-Container) oder CBC (XML-Container) pain.002.002.03 HKDME

SDD B2B 2.5 (2010)/2.6 (2012)

CDB pain.008.002.02 C2C pain.008.002.02 CDZ (zip) oder CBC (Container) pain.002.002.03 HKBME

EBICS-Reject

HBCI-Sammel

ltere Versionen des DF-Abkommens werden von der HVB auch noch akzeptiert: DF-Abkommen 2.4 (2009): pain.008.002.01 bzw. geliefert nach entsprechender Einlieferung:  DF-Abkommen 2.4 (2009): pain.002.002.02 Die Reject-Nachrichten (pain.002) werden verwendet, wenn die Rcknachricht vor Settlement, also vor Buchung, erfolgt. Dazu gehren z. B. Rckgaben wegen Formatfehlern etc. Weitere Informationen erhalten Sie von Ihrem Cash Management & eBanking Spezialisten.

11

6.  Aufbau der Kundendatei (XML*)

XML-Container  nur fr deutschen DK Formate optional  Group Header  Dieser Block muss vorhanden sein und existiert einmal  Er enthlt Elemente wie Nachrichten-ID, Erstellungsdatum und -zeit  Payment Information (Dateiebene)  Dieser Block muss mindestens einmal vorkommen und ist wiederholbar  Er enthlt Elemente, die sich auf die Herkunftsseite der Transaktion beziehen, wie z. B. Auftraggeber oder Zahlungsart-Informationen und einen oder mehrere Transaction Information-Blcke  Ebene der logischen Datei fr die Auftraggeber-Buchung (als Sammler)  Transaction Information  Dieser Block muss pro Payment Information mindestens einmal vorkommen und ist wiederholbar  Er enthlt u. a. Elemente, die sich auf die Empfngerseite  Zahlungsempfnger bei der berweisung bzw  Zahler (Zahlungspichtiger) bei der Lastschrift beziehen,  Enthlt den Betrag und den Verwendungszweck.
* XML = Extensible Markup Language

Auftragsarten Container sowie Aufbau Datei mit GroupHeader, PaymentInfo und TransactionsInfo
DK XML-Container EBICS-Auftragsart CCC pain.001.002.03 GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-1 TransactionInfo Creditor/EUR PaymentInfo Debtor: Konto-2 TransactionInfo Creditor/EUR EBICS-Auftragsart CCT (mixed) pain.001.002.03 GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-1 TransactionInfo Creditor/EUR PaymentInfo Debtor: Konto-2 TransactionInfo Creditor/EUR

EBICS-Auftragsart CCT (mixed) pain.001.002.03 GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-3 TransactionInfo Creditor/EUR pain.001.002.03 GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-3 TransactionInfo Creditor/EUR

12 Gruppierung von Dateien und was kann gemischt angeliefert werden? Die Einreichung von SEPA-Dateien erfolgt als Sammler, hierzu mssen 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 fr jedes Produkt eine eigene Sende-Auftragsart verwendet werden muss Je logische Datei (PaymentInf) insbesondere auch getrennt nach Auftraggeber-IBAN  Flligkeitstag <ReqdColltnDt> bzw. Ausfhrungstag <ReqdExctnDt>  Lastschrift Sequenz (First, Recurrent, Final, OneOff) <SeqTp>  Unterscheidung zwischen SCT und SCT-Preferred (gleichtgiges Clearing) <InstrPrty>  Sammel/Einzelbuchung der Einreichung <BtchBookg> Anzahl der Stze bzw. Datei-Grenbeschrnkung siehe unten  In einer logischen Datei knnen gemischt werden z.B. :  verschiedene Empfnger bzw Zahlungspichte bei Lastschriften  verschiedene Betrge <Amt>  Verwendungszweck <RmtInf>, Zahlungsgrnde <Purp>, End-toEnd-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 whrend eine SEPA-Transaktion ber 2.100 Bytes beinhalten kann, hinzu kommen noch die Headerinformationen. Um noch verarbeitungsfhige Dateien zu erhalten (Filetransfer, Mapping, Validierung und Fehlerrecherche etc) empehlt es sich, die Gruppierung nicht zu gro zu machen. Empfehlung maximal 100.000 Transaktionen pro Datei (bis zu 210 MB)

Prfung auf Doppelverarbeitung von Dateien Damit Dateien nicht doppelt verarbeitet werden, prft 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 Prfziffer (Stelle 3-4) aller Empfnger- bzw Zahlungspichtigen-IBAN

13

7.  SEPA Credit Transfer (SCT)

Grundlegende Merkmale  Auftraggeberkonto und Empfngerkonto werden im SEPA-Raum gefhrt (Kontoinhaber kann auch auerhalb ansssig sein)  Transaktionswhrung ist immer EUR Unterschiede gegenber Inlandsberweisung (wird abgelst zum 1.2.2014)  Verwendung von IBAN/BIC  Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen)  Zustzliche Zahlungsgrnde (PurposeCodes) sind optional mglich  Verwendung von On-Behalf/Ultimates ist optional mglich  Zustzliche Referenzierungsmglichkeiten  Grenzberschreitend im SEPA Raum Unterschiede gegenber EU-Standardberweisung (abgelst seit 1.4.2012)  explizit auch nationale Nutzung  kein AWV-Meldeteil im Datensatz vorhanden  auch Zahlungen in die Schweiz und Monaco

14

Wichtige fachliche XML Felder fr SEPA Credit Transfer Feldnamen

GrpHdr GroupHeader MsgId (Message-Id) CreDtTm (CreationDateTime) NbOfTxs (NumberOfTransactions) CtrlSum (ControlSum) InitgPty-Nm (InitiatingPartyName) InitgPty-Nm-Id-OrgId/ PrvtId (InitiatingPartyOrganisation-Id/Private-ID) PmtInf PaymentInstructionInformation PmtInfId (PaymentInformation-ID) PmtMtd (PaymentMethod) BtchBookg (BatchBooking) NbOfTxs (NumberOfTransactions) CtrlSum (ControlSum) InstrPrty (InstructedPriority) SvcLvl-Cd (ServiceLevelCode) CtgyPurp (CategoryPurpose)

Beschreibung pain.001.002.03
Absenderdaten Einreicher-Referenznummer pro Datei Datum/Zeit der Dateierstellung Anzahl aller Einzeltransaktionen Kontrollsumme in Euro der Einreichung Name Einreicher (kann vom Namen des Auftraggebers abweichen Identication

Befllung DF Abkommen 2.5/2.6

1x pro logische Datei Pichtfeld (eindeutig) Pichtfeld Pichtfeld Empfohlen Pichtfeld DK nicht empfohlen Max. 35 Zeichen ISO-Date Unbegrenzt Unbegrenzt Max. 70 Zeichen Diverse

Nheres siehe Seite

11, 12 35, 37-38

25 28, 35-38

Auftraggeberdaten Referenz der Einreichung Zahlungsinstrument: Credit Transfer Auftraggeberbuchung Sammler/Einzelsatz Anzahl aller Einzeltransaktionen Kontrollsumme in Euro der logischen Datei Prioritt der Ausfhrung: high oder norm Service Schema Zahlungsart der Datei

beliebig oft mglich, empfohlen max. 100 Picht Picht Optional, in Stammdaten administriert Empfohlen Empfohlen Optional, in Stammdaten administriert Picht Optional, in Stammdaten administriert Pichtfeld Pichtfeld Optional Optional DK nicht empfohlen Max. 35 Zeichen TRF false Einzelbuchung true Sammelbuchung Unbegrenzt Unbegrenzt HIGH SCT Preferred NORM SCT Normal SEPA Fr gleichtgige Gehaltszahlung SALA ISO-Date Max. 70 Zeichen Lndercode ISO3166, DE fr Deutschland Max. 140 Zeichen Diverse

11, 12 35, 37-38

40-41

36 8, 36 24, 36

ReqdExctnDt Gewnschter Ausfhrungstermin (RequestedExecution Date) Dbtr-Nm (DebtorName) Dbtr-PstlAdr-Ctry (DebtorCountry) Dbtr-PstlAdr-AdrLine (DebtorAddress) Dbtr-Id-OrgId/PrvtId (DebtorOrganisation-Id/ Private-ID) DbtrAcct-IBAN (DebtorIBAN) DbtrAcct-Ccy (DebtorAccountCurrency) DbtrAgt-BIC (DebtorAgentBIC) UltmtDbtr (UltimateDebtorName) UltmtDbtr-Id-OrgId-Othr (UltimateDebtor-IBAN) ChrgBr (ChargeBearer) Name Auftraggeber. Ggf. von Bank mit Kontoinhaber berschrieben Land der Anschrift des Auftraggebers Anschrift Auftraggeber. Ggf. von Bank mit Kontoadresse berschrieben Identication

25 25 25 28, 35-38

IBAN des Auftraggebers Whrung des Auftraggeberkontos BIC/SWIFT Code des Auftraggebers Vom Kontoinhaber abweichender Auftraggeber. Rein informatorischer Charakter Ultimate Einreicherbelastungs-IBAN Preis-Verrechnung immer shared

Pichtfeld Optional Pichtfeld Optional

Max. 34 Zeichen Whrungscode 8 bzw. 11 Stellen Max. 70 Zeichen

8, 26

8 6, 25, 29, 36

Optional, nur wenn Produkt Ultimate Auftraggeber Empfohlen

Max. 34 Zeichen SLEV

26, 29, 28, 35 36

15 Fortsetzung
Feldnamen
CdtTrfTxInf CreditTransferTransaction-Information InstrId (Instruction-ID) EndToEndID (End2End-ID) InstrAmt (Instructed Amount) UltmtDbtr (UltimateDebtor) UltmtDbtr-Id-OrgId/PrvtId (UltimateDebtorOrganisation-Id/Private-ID) CdtrAgt-BIC (CreditorAgentBIC) Cdtr-Nm (CreditorName) Cdtr-PstlAdr-Ctry (CreditorCountry) Cdtr-PstlAdr-AdrLine (CreditorAddress) Cdtr-Id-OrgId/PrvtId (CreditorOrganisation-Id/ Private-ID) CdtrAcct-IBAN (CreditorIBAN) UltmtCdtr (UltimateCreditorName) UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrganisation-Id/Private-ID) Purp (Purpose)

Beschreibung
Transaktions-Information Technische Referenz zwischen Einreicher und Bank Referenz, wird bis Begnstigten durchgereicht Betrag und Whrungskennzeichen Abweichender Auftraggeber Identication

Befllung DF Abkommen 2.5/2.6

beliebig oft mglich, empfohlen max. 100.000 Optional, wenn gefllt: eindeutig Pichtfeld (eindeutig, sonst: NOTPROVIDED) Pichtfeld Optional. Nicht wenn auf PmtInf-Ebene schon gefllt DK nicht empfohlen Max. 35 Zeichen Max. 35 Zeichen Nur Euro erlaubt Max. 70 Zeichen Diverse

Nheres siehe Seite

11, 12 35, 37-38 35, 37-39

6, 25, 29, 36 28, 35-38

BIC/SWIFT-Code der Begnstigten Bank Name Begnstigter Land der Anschrift des Begnstigten Anschrift Begnstigter Identication

Pichtfeld Pichtfeld Optional Optional DK nicht empfohlen

8 bzw. 11 Stellen Max. 70 Zeichen Lndercode ISO3166, DE fr Deutschland Max. 140 Zeichen Diverse

8 25 25 25 35-38

IBAN des Begnstigten Abweichender Endbegnstigter. Rein informatorischer Charakter Identication

Pichtfeld Optional DK nicht empfohlen

Max. 34 Zeichen Max. 70 Zeichen Diverse

8, 26 6, 25, 29 28, 35, 37-38

Art der Zahlung (Textschlssel). Im Kontoauszug MT940/942 werden nicht alle Codes dargestellt. Die Codes BONU, PENS, SALA werden im MT940 als GVC 153; BENE, GOVT, SSBE als GVC 156; CHAR als GVC 119 bzw. 169 und CBFF als GVC 154 dargestellt Unstrukturierter Verwendungszweck

Optional

ISO20022 ExternalPurposeCodeListe

6, 23, 50

Ustrd-RmtInf (UnstructuredRemittanceInfo) Strd-CdtrRefInfCdtrRefTp-Cd (StructuredCreditor Reference-Code) Strd-CdtrRefInf-CdtrRef (StructuredCreditor Reference)

Empfohlen

Max. 140 Zeichen

21, 36

Strukturierter Verwendungszweck fr VL-Leistung oder CreditorReference

Nur wenn kein unstrukturierter Verwendungszweck

SCOR

21-22, 36

Strukturierter Verwendungszweck Teil 2 a)  VL-Leistung: Bezugsjahr der Vermgenswirksamen Leistung und Referenz alternativ b) CreditorReference: Prfziffern gerechte CreditorReference

Nur wenn kein unstrukturierter Verwendungszweck a)  in Verbindung mit Purp=CBFF: Bezugsjahr der VL und Referenz b) RF+Prfziffer+Reference (ISO11649)

Max. 35 Zeichen

21-22, 35, 37-38

Nicht angegeben sind rein technische Felder oder Felder, die in Deutschland mglich, aber von den Banken nicht empfohlen sind (z.B. OrgID, weitere strukturierte Verwendungszwecke). Details und Angabe aller Felder nden Sie im DF-Abkommen Spezikation der Datenformate.

16

8.  Beispiel einer Kunden-Datei

GroupHeader
<?xml version="1.0" encoding="UTF-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.002.03"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 pain.001.002.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
XML Schema und XSD Location

DTAUS-Feld

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) ServiceLevel SEPA  Category-Purpose SALA Gleichtgig beim Empfnger auch bei nach Cut-Off Ausfhrungstag Auftraggeber Name (ggf mit Adresse) (~DTA-A10) (DTA-E4) (DTA-E8)

(DTA-A11b) (DTA-C15)

Auftraggeber IBAN

(~DTA-C11)

Auftraggeber BIC

(~DTA-C10)

Ultimate Auftraggebername SELV = Share

CreditTransferTransaction Einzeltransaktion
<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> </Id> </CdtrAcct> <Purp> <Cd>PENS</Cd> </Purp> <RmtInf> <Ustrd>Unstructured Remittance Information</Ustrd> </RmtInf> </CdtTrfTxInf>  End2End-Id Referenz der Zahlung aus Sicht des Auftraggebers Betrag in EUR (DTA-C12)

Creditor Empfnger BIC

(~DTA-C4)

Empfngername

(DTA-C14a + Erw)

Empfnger IBAN

(~DTA-C5)

 Purpose Textschlssel der Zahlung siehe ISO20022 external Code list Remittance-Info Verwendungszweck 140 Stellen

(~DTA-C7a) (~DTA-C16 + Erw)

17

9.  SEPA Direct Debit (SDD)

Grundlegende Merkmale  SEPA Basislastschrift (SDD-Core)  hnlich der Inlands-Einzugsermchtigungs-Lastschrift  SEPA Firmenlastschrift (SDD-B2B)  hnlich der Inlands-Abbuchungsauftrags-Lastschrift M  andat muss zum Abgleich auch bei der Debitorbank vorliegen Unterschiede gegenber Inlandslastschrift (wird abgelst zum 1.2.2014)  Angabe der Glubiger Identikationsnummer (vergeben von der Bundesbank)  Mitgabe von Mandatsinformationen (Mandate-ID und Mandatsunterschriftsdatum)  Mitgabe von prozessrelevanten Angaben (Sequenz der Einreichung, Flligkeitstag mit entsprechenden Vorlaufeinreichungstagen)  Verwendung von IBAN/BIC  Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen)  Zustzliche Zahlungsgrnde (PurposeCodes) sind optional mglich  Verwendung von On-Behalf/Ultimates ist mglich  Zustzliche Referenzierungsmglichkeiten  grenzberschreitende Nutzung im SEPA-Raum
Wichtige fachliche XML Felder fr SEPA Direct Debit Feldnamen
GrpHdr GroupHeader MsgId (Message-Id) CreDtTm (CreationDateTime) NbOfTxs (NumberOfTransactions) CtrlSum (ControlSum) InitgPty-Nm (InitiatingPartyName) InitgPty-Nm-Id-OrgId/ PrvtId (InitiatingPartyOrganisation-Id/Private-ID) PmtInf PaymentInstructionInformation PmtInfId (PaymentInformationID) PmtMtd (PaymentMethod) BtchBookg (BatchBooking) NbOfTxs (NumberOfTransactions

Beschreibung pain.008.002.02
Absenderdaten Einreicher-Referenznummer pro Datei Datum/Zeit der Dateierstellung Anzahl aller Einzeltransaktionen Kontrollsumme in Euro der Einreichung Name Einreicher (kann abweichen von Auftraggebernamen) Identication

Befllung DF Abkommen 2.5/2.6

1x pro logische Datei Pichtfeld (eindeutig) Pichtfeld Pichtfeld Empfohlen Pichtfeld DK nicht empfohlen Max. 35 Zeichen ISO-Date Unbegrenzt Unbegrenzt Max. 70 Zeichen Diverse

Inhalt des papierhaften Mandates

Nheres siehe Seite

11, 12 35, 37-38

25 28, 35-38

Zahlungsempfnger-Daten Referenz der Einreichung

beliebig oft mglich, empfohlen max. 100 Pichtfeld Max. 35 Zeichen

11, 12 35, 37-38

Zahlungsinstrument: Direct Debit Auftraggeberbuchung Sammler/ Einzelsatz Anzahl aller Einzeltransaktionen

Pichtfeld Optional, wenn administriert in Stammdaten Empfohlen

DD true-Sammelbuchung false-Einzelsatzbuchung Unbegrenzt 40-41

18 Fortsetzung
Feldnamen
CtrlSum (ControlSum) SvcLvl-Cd (ServiceLevelCode) LclInstrm-Cd (LocalInstrumentCode SeqTp (SequenceType) CtgyPurp (CategoryPurpose) ReqdColltnDt (RequestedCollectionDate) Cdtr-Nm (CreditorName) Cdtr-PstlAdr-Ctry (CreditorCountry) Cdtr-PstlAdr-AdrLine (CreditorAddress) CdtrAcct-IBAN (CreditorIBAN) CdtrAcct-Ccy (CreditorAccount Currency) CdtrAgt-BIC (CreditorBIC) UltmtCdtr (UltimateCreditor) UltmtCdtr-Id--OrgIdOthr (UltimateCreditorIBAN) UltmtCdtr-Id-OrgId/ PrvtId (UltimateCreditorOrganisation-Id/Private-ID) ChrgBr (ChargeBearer) CdtrSchmeId-Id-PrvtIdOthrId-Id (CreditorIdentication)

Beschreibung pain.008.002.02
Kontrollsumme in Euro der logischen Datei Service Schema Lastschriftsart: normale SEPA-CoreBasislastschrift oder SEPA-B2BFirmenlastschrift Sequenz: Erst-, Folge-, Einmal- oder letztmalige-Lastschrift Zahlungsart der Datei Flligkeitsdatum der Lastschrift (Datum der Belastung auf Kto. des Bezogenen) Name Zahlungsempfnger. Ggf. von Bank mit Kontoinhaber berschrieben Land der Anschrift des Zahlungsempfngers Anschrift Zahlungsempfnger. Ggf. von Bank mit Kontoadresse berschrieben IBAN des Zahlungsempfngers Kontowhrung: muss EUR sein

Befllung DF Abkommen 2.5/2.6

Empfohlen Picht Pichtfeld (innerhalb GrpHdr nicht mischbar) Pichtfeld Unbegrenzt SEPA CORE oder B2B *

Inhalt des papierhaften Mandates

Nheres siehe Seite

36 7, 33, 36

FRST, RCUR, OOFF oder FNAL Nicht zur Weitergabe an Endkunden ISO-Date

Picht (wiederkehrend oder einmalig)

31, 33-34

Optional Pichtfeld

24, 36 33

Pichtfeld Optional Optional

Max. 70 Zeichen Lndercode ISO3166, DE fr Deutschland Max. 140 Zeichen

Picht Picht Picht

25 25 25

Pichtfeld Optional

Max. 34 Zeichen EUR

8, 24

BIC/SWIFT Code des Zahlungsempfngers Vom Kontoinhaber abweichender Zahlungsempfnger. Rein informatorischer Charakter Ultimate Einreicher-GutschriftsIBAN Identication

Pichtfeld Optional

8 bzw. 11 Stellen Max. 70 Zeichen

8 6, 25, 29, 36 26, 28-29

Optional, nur wenn Produkt Ultimate Auftraggeber DK nicht empfohlen

Max. 34 Zeichen

Diverse

28, 35-38

Preis-Verrechnung immer shared

Pichtfeld Ab DF-Abkommen 2.6 gendert auf Empfohlen Pichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich

SLEV

36

CreditorIdentication. Eindeutiges Identikationsmerkmal des Zahlungsempfngers (per legal entity)

Max. 35 Zeichen

Picht

27, 36-38

* fr 2013 ist hier auch der LocalInstrumentCode COR1 vorgesehen fr die Lastschrift mit verkrzter Vorlaufzeit D-1

19 Fortsetzung
Feldnamen
Drct DbtTrfTxInf Direct Debit Transaction-Information InstrId (Instruction-ID) EndToEndID (End2End-ID) InstrAmt (Instructed Amount) Mndtld (MandateID) DtOfSgntr (DateOfSignature)

Beschreibung
Transaktions-Information Technische Referenz zwischen Einreicher und Bank Referenz, wird bis Zahlungspichtigen durchgereicht Betrag und Whrungskennzeichen Eindeutige Mandatsreferenz Datum, zu dem das Mandat unterschrieben wurde

Befllung DF Abkommen 2.5/2.6

beliebig oft mglich, empfohlen max. 100.000 Optional, wenn gefllt: eindeutig Pichtfeld (eindeutig, sonst: NOTPROVIDED) Pichtfeld Pichtfeld Pichtfeld Max. 35 Zeichen Max. 35 Zeichen Nur Euro erlaubt Max. 35 Zeichen ISO-Date

Inhalt des papierhaften Mandates

Nheres siehe Seite

11, 12 35, 37-38 35, 37-39

35, 37-39 Picht, im Papiermandat auch Ort der Unterschrift und Unterschrift 30-32 30-32, 35, 37-39

AmdmntInd (AmendmentIndicator) OrgnlMndtId (OriginalMandateID)

Kennzeichen, ob das Mandat verndert wurde Eindeutige Referenz des ursprnglichen Mandats, falls sich die Mandatsreferenz (MndtId) gendert hat Ursprnglicher Creditor Name, falls sich der Zahlungsempfnger gendert hat Ursprngliche CreditorIdentication, falls sich die CreditorIdentication (CdtrSchmeIdI) gendert hat Ursprnglicher IBAN des Zahlungspichtigen, falls sich der IBAN gendert hat Ursprngliche Debtorbank hat sich gendert. Neueinreichung mit Sequenz FRST ntig Elektronisches Mandat eMandate elektronische Signatur CreditorIdentication. Eindeutiges Identikationsmerkmal des Zahlungsempfngers (per legal entity) Name abweichender Zahlungsempfnger Identication

Pichtfeld Nur bei Mandatsvernderung (AmdmntInd = True) Nur bei Mandatsvernderung (AmdmntInd = True) Nur bei Mandatsvernderung (AmdmntInd = True) Nur bei Mandatsvernderung (AmdmntInd = True) Nur bei Mandatsvernderung (AmdmntInd = True) Optional. Nicht fr papierhafte Mandate Pichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich. Optional. Nicht wenn auf PmtInf-Ebene schon gefllt DK nicht empfohlen

Vernderung = True Standard = False Max. 35 Zeichen

OrgnlCdtrSchmeId-Nm (OriginalCreditorName) OrgnlCdtrSchmeId-IdPrvtId-OthrId-Id (OriginalCreditorIdentication) OrgnlDbtrAcct-IBAN (OriginalDebtorIBAN) OrgnlDbtrAgt-Id (OrignalDebtorAgentID) ElctmcSgntr (ElectronicSignature) CdtrSchmeId-Id-PrvtIdOthrId-Id (CreditorIdentication) UltmtCdtr (UltimateCreditorName) UltmtCdtr-Id-OrgId/ PrvtId (UltimateCreditorOrganisation-Id/Private-ID) DbtrAgt-BIC (DebtorAgentBIC) Dbtr-Nm (DebtorName) Dbtr-PstlAdr-Ctry (DebtorCountry) Dbtr-PstlAdr-AdrLine (DebtorAddress)

Max. 70 Zeichen

25, 30-32

Max. 35 Zeichen

27, 30-32, 35, 37-38

Max. 34 Zeichen

26, 30-32

Kennzeichen SMNDA

30-32, 34

Max. 1.025 Zeichen; erst Max. eMandate relevant Max. 35 Zeichen 27, 36-38

Max. 70 Zeichen Diverse

6, 25, 29, 36 28, 35-38

BIC/SWIFT-Code der zahlungspichtigen Bank Name Zahlungspichtiger Land der Anschrift des Zahlungspichtigen Anschrift Zahlungspichtiger

Pichtfeld Pichtfeld Optional Optional

8 bzw. 11 Stellen Max. 70 Zeichen Lndercode ISO3166, DE fr Deutschland Max. 140 Zeichen Picht Picht

8 25 25 25

20 Fortsetzung
Feldnamen
Dbtr-Id-OrgId/PrvtId (DebtorOrganisationId/Private-ID) DbtrAcct-IBAN (DebtorIBAN) UltmtDbtr (UltimateDebtor) UltmtDbtr-Id-OrgId/ PrvdtId (UltimateDebtorOrganisation-Id/Private-ID) Purp (Purpose) Ustrd-RmtInf (Unstructured RemittanceInfo) Strd-CdtrRefInfCdtrRefTp-Cd (StructuredCreditor Reference-Code) Strd-CdtrRefInf-Cdtr Ref(StructuredCreditor Reference)

Beschreibung
Identication

Befllung DF Abkommen 2.5/2.6

DK nicht empfohlen Diverse

Inhalt des papierhaften Mandates

Nheres siehe Seite

28, 35-38

IBAN des Zahlungspichtigen Name abweichender Zahlungspichtiger. Rein informatorischer Charakter Identication

Pichtfeld Optional

Max. 34 Zeichen Max. 70 Zeichen

Picht Optional

8, 26 6, 25, 29

DK nicht empfohlen

Diverse

28, 35-38

Art der Zahlung (Textschlussel). Im Kontoauszug MT940/942 werden nicht alle Codes dargestellt. Unstrukturierter Verwendungszweck Strukturierter Verwendungszweck

Optional

ISO20022 ExternalPurposeCodeListe Max. 140 Zeichen Optional (Vertragsnummer und Beschreibung)

6, 23, 50

Empfohlen

21, 36

DK nicht empfohlen

SCOR

21, 36

Strukturierter Verwendungszweck Teil 2

DK nicht empfohlen

Max. 35 Zeichen

21, 36

21

10.  SEPA hug genutzte Zahlungsinformationen im Format

10.1 Verwendungszweck
Verwendungszweck <RmtInf>  Der Verwendungszweck hat bei SEPA nur 140 Stellen. Im noch gltigen Inlandszahlungsverkehr sind dagegen bis 14 x 27 Zeichen (= 378 Stellen) mglich.  In Ergnzung zu dem Verwendungszweck kann bei SEPA allerdings noch ein strukturierter Purpose <Purp> und eine Detaillierung der beteiligten Parteien (Adresse und Identikationsnummern) vorgenommen werden  Es wird daher empfohlen den unstrukturierten Verwendungszweck <Ustrd> zu verwenden
<RmtInf> <Ust d>1234567890123456789012345678901234567890123456789012345678 9012345678901234567890123456789012345678901234567890123456789012 345678901234567890</Ustrd> </RmtInf>

Strukturierter Verwendungszweck <RmtInf> <Strd> Der strukturierte Verwendungszweck kommt in 2 Fllen in Frage Vermgenswirksame Leistungen (VL-Zahlungen)  Wenn im strukturierten Verwendungszweck unter <CdtrRefInf> Informationen ber Vermgenswirksame Leistungen eingestellt sind (wie z. B. Jahreszahl oder Vertragsnummer: XXJ/Vertragsnummer), muss der Purpose Code CBFF (Capital building fringe fortune) fr Vermgenswirksame Leistungen verwendet werden, um regelmiges Scannen des Verwendungszwecks zu vermeiden
<Purp> <Cd>CBFF</Cd> </Purp> <RmtInf> <Strd> <CdtrRefInf> <Tp> <CdOrPrtry> <Cd>SCOR</Cd> </CdOrPrtry> </Tp> <Ref>XX3/123456789</Ref> </CdtrRefInf> </Strd> </RmtInf>

Der Name des VL-Empfngers kann ggf. im Ultimate Creditor hinterlegt werden.

22  trukturierte Creditor Referenz <CdtrRefInf> S  Belege mit Prfziffern gerechten Verwendungszwecken gibt es anlog den BZ-Belegen im Inlandszahlungsverkehr, auch in SEPA. Sie werden bei SEPA Creditor-Reference 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 den Codewort SCOR zugelassen  Wenn die Prfziffer nicht korrekt ist, wird die Referenz in den unstrukturierten Verwendungszweck berfhrt  Im papierhaften und elektronischen Kontoauszug MT940 wird die Struktur grundstzlich 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 grundstzlich an die Empfnger-Bank und deren End-Empfnger  Er kann zu unterschiedlichen Geschftsvorfallcodes (GVC) im elektronischen Auszug fhren  Die Zahlungsgrnde sind aufgefhrt in www.iso20022.org/external_code_list.page im Reiter 11-Purpose
<CdtTrfTxInf> ... <Purp> <Cd>PENS</Cd> </Purp> </CdtTrfTxInf>

PurposeCode Auszug
ADVA AGRT AIRB ALMY BECH BENE BLDM BONU BUSB CASH CBFF CBTV CDBL CFEE CHAR CLPR COMM COST CSLP DCRD DNTS ELEC ENRG ESTX GASB GDDS GOVI GOVT GWLT HLTC HLTI

Erklrung

Spezieller Geschftsvorfall-Code fr elektronischen Auszug, bzw. Anmerkungen

PurposeCode Auszug
HSPC INPC INSM INSU INTC

Erklrung

Spezieller Geschftsvorfall-Code fr elektronischen Auszug, bzw. Anmerkungen

Vorabzahlung Landwirtschaft Luftverkehr Alimente und Unterhalt Kindergeld Arbeitslosengeld Gebudepege Bonuszahlung Busverkehr Cash Mananagement Vermgenswirksame Leistung Kabelfernsehen Kreditkartenabrechnung Stornogebhr Spende Autokredit Kommissionszahlung Kosten Allgemein Sozialversicherungsabgaben Debitkartenzahlung Zahnarzt Service Stromrechnung Energie Grundsteuer Gasrechnung Warenkauf/Verkauf Staatliche Versicherung Zahlung an/von ffentlichen Kassen Kriegsversehrtenzahlung Gesundheits Service Krankenversicherung GVC Haben 156 GVC Soll 119, Haben 169 GVC Haben 154 GVC Haben 153 GVC Haben 156

Krankenhausbehandlung Autoversicherung Ratenzahlung Versicherung Intra-Company bertrag Zinsen Einkommenssteuer Berufsversicherung Lizenzkosten Lebensversicherung Kreditzahlung Medizinische Dienste Netzwerkkommunikation Lohn/Gehaltszahlung Pensions- und Rentenzahlung Telefon Haus/Grundstcksversicherung Dauerauftragsgutschrift Bahnverkehr Lohn/Gehaltszahlung Sparerzahlung Dienstleistungen Allgemein Sozialleistungen Bildung und Unterricht Lieferantenzahlung Steuerzahlung Laut Telefonauftrag Handelsgeschft Mehrwertsteuer Laut Auftrag im Internet Wasser GVC Haben 156 GVC Haben 153 GVC Haben 152 (Ab DF 2.7) GVC Haben 153 (ab DF-2.7) GVC Haben 153

INTE INTX LBRI LICF LIFI LOAN MDCS NWCM PAYR PENS PHON PPTI RINP RLWY SALA SAVG SCVE SSBE STDY SUPP TAXS TELI TRAD VATX WEBI WTER

24

10.3 Produktkategorie: Category Purpose <CtgyPurp>

 Der Category Purpose ist eine Anweisung des Einreichers an die Einreicher-Bank  Er gilt eine besondere Verarbeitung der Auftrge/der Datei z.B. mit einer Priorisierung oder Sonderkonditionen Gilt fr Datei oder je Zahlung Die Information geht nicht an die Empfnger-Bank Es ist eine bilaterale Vereinbarung ber Nutzung mit der Bank erforderlich  Bei HVB wird dzt. nur SALA (gleichtgige Gehaltszahlungen) auf Dateiebene verwendet. Weitere Informationen zum Produkt knnen Sie auch unserem Spezialyer Credit Transfer Preferred entnehmen
<PmtInfId> ... <PmtTpInf> ... <CtgyPurp> <Cd>SALA</Cd> </CtgyPurp> </PmtTpInf> ... </PmtInfId>

10.4 Fnf Beteiligte in einer SEPA-Nachricht

Auftraggeber und Empfnger bzw. Zahlungspichtiger erscheinen in den verschiedenen Ebenen eines SEPA Auftrages bzw. einer Dateieinreichung. ber die Felder Ultimate kann zustzlich ein abweichender Auftraggeber und Zahlungsempfnger bzw. - pichtiger mitgegeben werden. Beispiel SEPA-berweisung
GroupHeader InitiatingParty (Einreicher) Name (70 Stellen) PaymentInf Dateiebene Debitor (Auftraggeber) IBAN/BIC (Auftraggeber) UltimateDebitor Transaktion Creditor (Empfnger) IBAN/BIC (Empfnger) UltimateCreditor
Pichtangabe Optional

Adresse (2x 70 Stellen zzgl. Lndercode)* Organisationsnummer Personenidentikation

* Adresse nicht mglich bei Initiating Party

25 Beispiel SEPA-Lastschrift
GroupHeader InitiatingParty (Einreicher) PaymentInf Dateiebene Creditor (Auftraggeber) Glubiger-ID (Creditor) IBAN/BIC (Creditor) UltimateCreditor Transaktion Debitor (Zahlungspichtiger) IBAN/BIC (Zahlungspichtiger)
Pichtangabe

Name (70 Stellen) Adresse (2x 70 Stellen zzgl. Lndercode)* Organisationsnummer** Personenidentikation**

UltimateDebitor
* Adresse nicht mglich bei Initiating Party ** OrgID & PrivId nicht mglich bei Creditor

Optional

10.5 Name, Adresse

 In der SEPA Nachricht gibt es fnf mgliche Beteiligte (Debitor, Creditor, InitiatingParty, Ultimate Creditor und Ultimate Debtor)  Der jeweilige Name <Nm> der Beteiligten wird immer mit bis zu 70 Stellen angegeben  Optional knnen noch Adressen <PstlAdr> mitgegeben werden. Hierzu sind 2 mal 70 Stellen der unstrukturierten Adresse <AdrLine> zu verwenden zuzglich dem Lndercode <Ctry>  Der Auftraggebername und die -Adresse (bei grenzberschreitenden Zahlungen) mssen aufgrund der Auftraggeberdatenverordnung korrekt mitgeliefert werden. Die HVB fllt 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
 International Bank Account Number IBAN ist das eindeutige Identikationskriterium fr Zahlungsempfnger und Zahlungspichtige. Die IBAN lst die nationale Kontonummer im SEPA-Zahlungsraum fr SEPA-Auftrge komplett ab.
<Id> <IBAN>DE40700202700012345678</IBAN> </Id>

 Der Aufbau ist deniert von ISO 13616-1:2007. Die IBAN beginnt mit zwei Buchstaben, dem Lnderkennzeichen, gefolgt von der numerischen Prfziffer. Die zweistellige Prfziffer errechnet sich ber die gesamte IBAN nach ISO 7064 im Modulus 97-10. Anschlieend erfolgt eine Bank/Kontoidentikation. Diese Bank/Kontoidentifkation ist je nach Land unterschiedlich strukturiert hat eine unterschiedliche Anzahl an Stellen. Somit kann die IBAN zwischen 15 und 31 Stellen lang sein und neben numerischen Werten auch ausserhalb des Lndercodes alphanumerische Werte beinhalten.  In Deutschland bilden die ersten 8 Stellen nach der Prfziffer die numerische Bankleitzahl und die folgenden 10 Stellen die numerische Kontonummer, so dass der gesamte IBAN in Deutschland 22 stellig ist. Ob die Kontonummer korrekt ist, lsst sich fr viele Banken anhand der letzten Stelle der Kontonummer sagen. Viele Banken verwenden diese letzte Ziffer fr eine Kontrollziffer. Welcher bankenindividuelle Berechnungsmodulus hierfr notwendig ist, lsst sich im Bankleitzahlenverzeichnis bei der Bundesbank anhand der BLZ ermitteln.

 Eine simple Ermittlung der Prfziffer anhand der BLZ und Kontonummer fhrt in Deutschland hug zu Fehlleitungen von Zahlungen, da besonders zu beachten ist:  Einzelne Institute fllen das Kontonummernfeld im IBAN bei Kontonummern kleiner 10 Stellen nicht linksbndig mit Nullen auf sondern fllen die Nullen am Ende der Kontonummer  Besonders durch Fusionen und Zusammenlegungen von Banklialen benutzen Kunden hug noch ihre alte Bankleitzahl weiter, obwohl sie bereits in ihrem IBAN eine neue Bankleitzahl erhalten haben D  eshalb sollte eine Konvertierung immer ber die kontofhrende Bank oder in Deutschland ber den BankVerlag stattnden

27 IBAN Beispiele fr andere Lnder sterreich (20 stellig): LLPPBBBBBKKKKKKKKKKK LL Lnderkennzeichen: AT Buchstaben PP Prfziffer 2 stellig numerisch BBB... sterreichische Bankleitzahl 5 stellig numerisch KKK... Kontonummer 11 stellig numerisch

Schweiz (21 stellig): LLPPBBBBBKKKKKKKKKKKK LL Lnderkennzeichen: CH Buchstaben PP Prfziffer 2 stellig numerisch BBB... Schweizer Bankleitzahl 5 stellig numerisch KKK... Kontonummer 12 stellig numerisch

Italien (27 stellig): LLPPNBBBBBCCCCCKKKKKKKKKKKK LL Lnderkennzeichen: IT PP Prfziffer 2 stellig N Control Internal Number (CIN) 1 stellig BBB... Associazione Bancaria Italiana (ABI) 5 stellig CCC... Codice di Avviamento Bancario (CAB) 5 stellig KKK... Kontonummer 12 stellig

Buchstaben numerisch alphanumerisch numerisch numerisch numerisch

10.7 Glubigeridentikation (Creditoridentication/CI)

 SEPA-Lastschrifteinreicher bentigen eine eindeutige Identikationsnummer. Diese ist bei der Bundesbank pro Legal-Entity erhltlich www.glaeubiger-id.bundesbank.de Format: LLPPZZZ0NNNNNNNNNN LL Lndercode PP Prfziffer berechnet nach ISO 13616 (analog IBAN-Prfziffer) ZZZ  Glubiger Geschftsbereichskennung, beliebig zu vergeben, z.B. um berschneidungen bei Mandatsreferenzen zu vermeiden. Im Standard mit Wert ZZZ belegen 0NN 11-stellige eindeutige Glubigeridentikation mit fhrender Null

<CdtrSchmeId> <Id><PrvtId><Othr> <Id>DE12ZZZ01234567890</Id> <SchmeNm> <Prtry>SEPA</Prtry> </SchmeNm> </Othr></PrvtId></Id> </CdtrSchmeId>

 Die Glubigeridentikation sollte mglichst auf Payment-Informations-Ebene und nicht bei jeder Transaktion wiederholt angegeben werden

28

10.8 Identikationsnummern (OrgID/PrivateID)

 Optional kann zum Namen auch eine Identikationsnummer mitgegeben werden. In Deutschland (DFAnlage) wird empfohlen diese Felder nicht zu belegen, da auch eine Durchgngigkeit, z.B. im MT940 nicht gegeben ist. In manchen Lndern bzw. fr bestimmte Zahlungen, z.B. Steuerzahlungen, sind diese Angaben allerdings notwendig. Auch das internationale CGI-Format verlangt teilweise diese Identikationsnummern. Neben der Identikationsnummer knnen noch Daten, wie z.B. die ausstellende Behrde <Issr>, mitgegeben werden. Es kann entweder eine Organisationsnummer oder eine Personennummer angegeben werden  Organisations Identikation 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-OrganisationIdentication
<Id> <OrgId> <Othr> <Id>181/815/08155</Id> <SchmeNm> <Cd>TXID</Cd> </SchmeNm> <Issr>Finanzamt Muenchen IV</Issr> </Othr> </OrgId> </Id>

 Personen Identikation <PrvtID>, z.B. Geburtsdatum/Ort, Sozialversicherungsnrummer (SOSE), Passnummer (CCPT), Steuernummer (TXID), Kundennummer (CUST), Fhrerscheinnummer (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> <PrvtId> <DtAndPlcOfBirth> <BirthDt>1980-11-07</BirthDt> <PrvcOfBirth>Bayern</PrvcOfBirth> <CityOfBirth>Muenchen</CityOfBirth> <CtryOfBirth>DE</CtryOfBirth> </DtAndPlcOfBirth> </PrvtId> </Id>

<Id>RA 123445123</Id> <SchmeNm> <Cd>CCPT</Cd> </SchmeNm> <Issr>Kreisverwaltungsreferat Muenchen</Issr> </Othr> </PrvtId> </Id>

29

10.9 Ultimate/Reference Party/On Behalf

 Neben dem Auftraggeber knnen Namensfelder des abweichenden Auftraggebers Ultimate mitgeliefert werden. Auch fr den Empfnger gibt es die Mglichkeit, einen Ultimate Endbegnstigten bzw. einen Ultimate Zahlungspichtigen 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.  Fr eine schuldbefreiende Zahlung bei Lastschriften ist auf der Zahlungsempfngerseite ein Konto fr fremde Rechnung notwendig  Die Ultimate-Felder haben rein informatorischen Charakter und werden als zustzlicher Verwendungszweck interpretiert  Nicht jede Bank bietet ber alle Kanle die Durchleitung dieser zustzlichen Informationen an den Empfnger an. Besonders im Papier-Kontoauszug werden diese Informationen derzeit nur vereinzelt angedruckt. Eine zustzliche Angabe im Verwendungszweck ermglicht in jedem Fall eine Anzeige beim Endbegnstigten bzw. Zahlungspichtigen  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. Zahlungsempfnger (DD)]  ABWE+[Abweichender Zahlungsempfnger (CT) bzw. Zahlungspichtiger (DD)] berweisung Beispiel Kindergeld
<Dbtr> <Nm>Firma AG</Nm> </Dbtr> <UltmtDbtr> <Nm>Kindergeld-Abteilung</Nm> </UltmtDbtr> <Cdtr> <Nm>Mutter Meier</Nm> </Cdtr> <UltmtCdtr> <Nm>Kind Meier</Nm> </UltmtCdtr>

Lastschrift Beispiel Handyrechnung

<Cdtr> <Nm>Mobilfunk AG</Nm> </Cdtr> <Dbtr> <Nm>Mutter Meier</Nm> </Dbtr> <UltmtDbtr> <Nm>Kind Meier</Nm> </UltmtDbtr>

Abweichendes Retourenkonto Die Ultimate-Felder knnen 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. Nhere Infos zu dem Produkt Ultimate-Auftraggeber erhalten Sie bei Ihrem Cash Management & eBanking Spezialisten.

30 On behalf Payments ber Payment Factory Werden in einer Unternehmensgruppe ber eine Dachgesellschaft Zahlungen fr die verschiedenen Gesellschaften durchgefhrt (Payment Factory) ist insbesondere bei den SEPA-Lastschriften, den Mandaten und der Glubiger-ID zu beachten, wer die Mandate mit welcher Glubiger-ID zu schlieen hat und ber welche Konten der Zahlungsverkehr ausgefhrt wird, damit auf der Auftraggeberseite und hinsichtlich einer schuldbefreienden Zahlungen alle Voraussetzungen getroffen sind.  Grundannahme: Liefergeschft und Rechnungsstellung erfolgt durch Lieferrma Creditor ist Zahlungsabwicklungsrma. Hierbei hat die kontofhrende Stelle zu beachten, dass die eingehenden Gelder auf ein Konto fr fremde Rechnung laufen mssen (Treuhandkonto fr Lieferrma). Eine Haftungserklrung durch Zahlungsabwicklungsrma fr Rcklastschriften ist notwendig Zahlungsabwicklungsrma reicht die Lastschriften ein. Beim Einreicherkonto wird die Glubiger-Identikationsnummer (CI) der Zahlungsabwicklungsrma hinterlegt und bei Einreichungen geprft. Bei Gutschrift auf ein Zahlungsabwicklungsrma-Konto muss also die CI von Zahlungsabwicklungsrma hinterlegt werden. Ein Unternehmen kann nur mit einer CI Lastschriften einreichen, d.h. Zahlungsabwicklungsrma kann nicht mit der CI von der Lieferrma einreichen  Was ist auf dem Mandat anzugeben: Creditor ist Zahlungsabwicklungsrma, CI von Zahlungsabwicklungsrma als Creditor Reference Party wird Lieferrma und als deren CI als Creditor Reference ID angegeben  Das Mandat mit Creditor Lieferrma und CI Lieferrma kann aufgrund der Koppelung der Kontonummer mit der CI nur fr die Gutschrift auf ein Lieferrma Konto verwendet werden Lastschrift
<Cdtr> <Nm>Zahlungsabwicklungsrma</Nm> </Cdtr> <UltmtCdtr> <Nm>Lieferrma</Nm> </UltmtCdtr> <Dbtr> <Nm>Meier</Nm> </Dbtr>

10.10 Mandatsnderung/Mandate-Amendment
 Wenn sich nderungen am Mandat ergeben, muss nicht in jedem Fall ein neues Mandat eingeholt werden. Die Mandatsnderung wird in der nchstflligen SEPA-Lastschrift mitgeliefert  Folgende Felder sind hierfr im pain.008 vorgesehen:  Creditor bedingte nderungen  nderung der Mandatsnummer z.B. weil eine neue Mandatssystematik eingefhrt wird  Mitgabe der neuen Mandatsnummer <MndtId> und der alten Mandatsnummer <OrgnlMndtId>  nderung des Creditor-Namen, z.B. aufgrund von Firmenfusionen. Hier wird zumeist auch eine neue Glubiger-Identikationsnummer ntig  Mitgabe der neuen Glubiger-Identikationsnummer <CdtrSchmeId> und der alten GlubigerIdentikationsnummer <OrgnlCdtrSchmeId> <Id> sowie des  neuen Creditor-Namens <Cdtr> und des alten Creditor-Namens <OrgnlCdtrSchmeId><Nm>

31  nderungen beim Zahlungspichtigen  nderung der Debitoren-Kontoverbindung  Mitgabe der neuen IBAN <DbtrAcct> und alten IBAN <OrgnlDbtrAcct>  Wechselt der Debitor seine Bank wird das Kennzeichen SMNDA (SameMandateNewDebtorAgent) vergeben. Damit die neue Bank die korrekte Sequenz der Einreichung berprfen kann, muss diese Lastschrift dann als erstmalig FRST geschickt werden (mit den jeweilig notwendigen Vorlauftagen)  ndert sich der Debitorname, z.B. Heirat, muss kein neues Mandat eingeholt werden. Eine besondere Kennzeichnung in der Lastschrift ist hierbei nicht erforderlich berblick des Prozesses bei Mandatsnderungen 1 Kunde (Debitor) 4
B2BMandatsauftrag bzw. Debtor-Proling mit genderten Mandatsdaten schriftliche Mitteilung ber genderte IBAN/BIC Pre-Notication mit genderten Mandatsdaten

Archivierung der Mandatsnderung

Lieferant (Creditor) 5
Einreichung der nchsten* Lastschrift mit angehngten Mandatsnderungen

8
Einzug der Lastschrift mit angehngten Mandatsnderungen (alt/neu)

3
Mandatsnderungen Debitor-IBAN (alt/neu) Debitor-BIC Glubiger-ID (CI) (alt/neu) Creditorname (alt/neu) Mandats-ID (alt/neu)

6 Debitor-Bank 7
Prfung B2B-Lastschrift auf gltigen Mandatsauftrag Prfen auf Debtorproling (z.B. Sperren) Lastschrift mit angehngten Mandatsnderungen (alt/neu) Besonderheit: Bei BIC-nderung als FIRST D-5

* falls eine Lastschrift mit Mandatsnderung rejected (pain.002) wird, muss der Folgeeinzug wieder mit Mandatsnderung erfolgen

Weiter zu beachten  Wenn die Lastschrift mit den Mandatsnderungen vor Buchung zurckkommt (Information z.B. mit (pain.002), muss der folgende Lastschrifteinzug wieder diese Mandatsnderungen enthalten  In der Lastschrift mitgegebene Mandatsnderungen fhren bei der Zahlungspichtigenbank nicht automatisch zu nderung der Weisungen. So mssen vom Zahlungspichtigen hinterlegte SEPA-Firmenlastschriftsmandate durch den Zahlungspichtigen ggf. aktiv gendert werden. Gleiches gilt auch fr hinterlegte Mandats-Sperrlisten (Negativ-Liste) bzw. explizit erlaubte Einzge (Positiv-Liste) von SEPA Basislastschriften. Diese mssen ggf. an die Mandatsnderung angepasst werden. Informieren Sie deshalb frhzeitig den Zahlungspichtigen ber etwaige nderungen (z.B. ber eine hervorgehobene Prenotication) um unntige Retouren zu vermeiden  Archivieren Sie die Mandatsnderungen und die dazugehrigen Auftrge fr den lckenlosen Nachweis, um bei Mandatsanforderungen eine Lastschriftretoure wegen fehlender Autorisierung zu vermeiden

32

<MndtRltdInf> <MndtId>555544</MndtId> Aktuelle Mandatsnummer und Unterschriftsdatum <DtOfSgntr>2012-11-12</DtOfSgntr> Kennzeichen Mandatsnderung 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 Glubiger-Identikation <Prtry>SEPA</Prtry> </SchmeNm> </Othr> </PrvtId> </Id> </OrgnlCdtrSchmeId> <OrgnlDbtrAcct> <Id> <IBAN>DE84700202700654150818</IBAN> alte Debtor-IBAN </Id> </OrgnlDbtrAcct> <OrgnlDbtrAgt> <FinInstnId> <Othr> <Id>SMNDA</Id> Kennzeichen neue Debtor-Bank </Othr> </FinInstnId> </OrgnlDbtrAgt> </AmdmntInfDtls> </MndtRltdInf>

 Wann muss ein neues Mandat eingeholt werden?  Wenn seit dem letzten Einzug 36 Monate vergangen sind  Wenn eine Lastschriftrckgabe mit den Rckgabegrund NoMandate MD01 erfolgt D  er letzte Einzug erfolgte mit Sequenz FNAL-Final oder OOFF-OneOff (und wurde nicht rejected)  Der Debitor hat gegenber dem Creditor sein Mandat widerrufen

33

10.11 Lastschriftsequenz
 Es gibt zwei unterschiedliche SEPA-(Basis-/Firmen-) Lastschrift Mandate  Fr WIEDERKEHRENDE Einzge  Fr EINMALIGE Einzge  Dieses wird auf dem Mandat angegeben. Auerdem ist fr die Sequenz entscheidend, ob ein Mandat bereits verwendet wurde bzw. auch knftig 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 Flligkeitstag <ReqdColltnDt> in Abhngigkeit des Lastschriftproduktes Core/Cor1/B2B <LclInstrm> bei der Einreichung berprft.  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 Cutoff-Termine pro Lastschriftprodukt auf Basis der Sequenz mit Beispiel
Cutoff auf Basis der Sequenz
Basislastschrift (CORE) Regel Vorlage Debtorbank, Flligkeitstag Duedate x Cutoff HVB Cutoff HVB Beispiel Fllig: Fr 31.1.2013 Basislastschrift mit verkrzter Vorlauffrist (COR1) Regel Vorlage Debtorbank, Flligkeitstag Duedate x

FRST First
D5 D 6, 12 Uhr Mi 23.1.2013, 12 Uhr D1

RCUR recurrent
D2 D 3, 12 Uhr Mo 28.1.2013, 12 Uhr D1

FNAL Final
D2 D 3, 12 Uhr Mo 28.1.2013, 12 Uhr D1

OOFF OneOff
D5 D 6, 12 Uhr Mi 23.1.2013, 12 Uhr D1

Cutoff HVB Cutoff HVB Beispiel Fllig: Fr 31.1.2013 Firmenlastschrift (B2B) Regel Vorlage Debtorbank, Flligkeitstag Duedate x Cutoff HVB Cutoff HVB Beispiel Fllig: Fr 31.1.2013

D 2, 12 Uhr Di 29.1.2013, 12 Uhr D1 D 2, 12 Uhr Di 29.1.2013, 12 Uhr

D 2, 12 Uhr Di 29.1.2013, 12 Uhr D1 D 2, 12 Uhr Di 29.1.2013, 12 Uhr

D 2, 12 Uhr Di 29.1.2013, 12 Uhr D1 D 2, 12 Uhr Di 29.1.2013, 12 Uhr

D 2, 12 Uhr Di 29.1.2013, 12 Uhr D1 D 2, 12 Uhr Di 29.1.2013, 12 Uhr

Bitte beachten Sie ggf. abweichend vereinbarte Cutoffzeiten. Die aktuell gltigen Cutoffzeiten der HVB nden Sie unter www.hvb.de Geschftsbedingungen/Konditionen Grundlage fr die Berechnung:  Fr die Vorlauftage (D 5/D 2/D 1) werden im Interbanken-Clearing Targettage verwendet, d.h. Montag Freitag ohne die Targetfeiertage (1. Januar, Karfreitag, Ostermontag, 1. Mai, 25. & 26. Dezember)  Fllt ein Flligkeitstag auf ein Wochenende oder einen Targetfeiertag, kann die Zahlungspichtigenbank die Debitorbelastung auf den nchstmglichen Bankarbeitstag verschieben  Fr die Prenoticationregel (mind. 14 Tage) zhlen Kalendertage  Fr die Lastschrift-Retoure (Return D+2 fr die B2B bzw. D+5 fr die Basislastschrift) zhlen Targettage  Fr die Cutofftage zhlen Bankgeschftstage

34 Besonderheiten fr die Lastschriftsequenz  Kommt die Lastschrift vor Buchung zurck (reject/refusal/storno per pain.002) gilt die Lastschrift als nicht angekommen und es muss die ursprngliche Sequenz fr den Folgeeinzug genommen werden. Es mssen dann auch die ursprnglichen Vorlauftage eingehalten werden  Kommt die Lastschrift nach Buchung zurck (return/refund) gilt die Lastschrift als angekommen. Es muss die nchste Sequenz fr den Folgeeinzug genommen werden, bzw. das Mandat gilt bei einer einmaligen bzw. nalen Lastschrift als abgelaufen  Erfolgt eine Mandatsnderung auf eine neue Zahlungspichtigenbank SMNDA-SameMandateNewDebitorAgent muss die Lastschriftsequenz als erstmalig FRST gekennzeichnet werden  Erfolgt eine Mandatsnderung auf die gleiche Zahlungspichtigenbank (nur nderung der Creditordaten bzw. nur neue IBAN des Debitors bei gleicher Bank), muss die normale folgende Lastschriftsequenz verwendet werden Mit welcher Lastschrift-Sequenz erfolgt der Folgeeinzug, wenn es eine Rckgabe einer Lastschrift gab und wann sind Mandatsnderungen zu wiederholen?
Aktueller Einzug
FRST First FRST First FRST First RCUR Recurrent RCUR Recurrent RCUR Recurrent FNAL Final FNAL Final FNAL Final OOFF OneOff OOFF OneOff OOFF OneOff Mandatsnderung neue Debtorbank SMNDA mit FRST First (Picht) Mandatsnderung neue Debtorbank SMNDA mit FRST First (Picht) Mandatsnderung neue Debtorbank SMNDA mit FRST First (Picht) Mandatsnderung gleiche Debtorbank mit RCUR Recurrent Mandatsnderung gleiche Debtorbank mit RCUR Recurrent Mandatsnderung gleiche Debtorbank mit RCUR Recurrent

Rckgabe des aktuellen Einzugs

Keine Rckgabe Vor Buchung (pain.002) Nach Buchung Keine Rckgabe Vor Buchung (pain.002) Nach Buchung Keine Rckgabe Vor Buchung (pain.002) Nach Buchung Keine Rckgabe Vor Buchung (pain.002) Nach Buchung Keine Rckgabe Vor Buchung (pain.002) Nach Buchung Keine Rckgabe Vor Buchung (pain.002) Nach Buchung

Folgeeinzug
RCUR Recurrent* FRST First RCUR Recurrent* RCUR Recurrent* RCUR Recurrent* RCUR Recurrent* Kein Folgeeinzug FNAL - nal Neues Mandat ntig Kein Folgeeinzug OOFF OneOff Neues Mandat ntig RCUR Recurrent* FRST First & Mandatsnderung SMNDA wiederholen RCUR Recurrent* (Mandatsnderung nicht wiederholen) RCUR Recurrent* (Mandatsnderung nicht wiederholen) RCUR Recurrent* & Mandatsnderung wiederholen RCUR Recurrent* (Mandatsnderung nicht wiederholen)

* Ausnahme: der Folgeeinzug ist der letztmalige, dann mit FNAL-Final kennzeichnen

35

10.12 Zeichensatz und Umlaute

In SEPA kann ein umfangreicher Zeichensatz verwendet werden (UTF-8) mit vielen lnderspezischen Umlauten.  Das Deutsche Format (DK) lsst in der DF-Anlage derzeit nur einen eingeschrnkten Zeichensatz zu:  Numerische Zeichen 0 bis 9  Buchstaben A bis Z und a bis z  Sonderzeichen : ? , - ( + . )/und Leerzeichen  Im EPC Format verarbeitet die HVB auch noch weitere Zeichen  deutsche Umlaute  Lnderumlaute  Sonderzeichen ! # $ % * ; = [ \ ] ^ { | } ~  Infos grundstzlich zum Zeichensatz: www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=332  Im XML-Format sind folgende Sonderzeichen problematisch und sollten nicht verwendet werden: &<>@_  Banken, die die Sonderzeichen und Umlaute nicht verarbeiten knnen, ersetzen diese ggf. durch hnliche Zeichen laut EPC-Empfehlung oder sonst durch Leerstelle oder Punkt.  wird noch der alte elektronischen Kontoauszug MT940 verwendet (statt dem neuen camt.053) werden nur folgende Zeichen weitergegeben:  Numerische Zeichen 0 bis 9  Buchstaben A bis Z und a bis z  Sonderzeichen : , - ( + . )/und Leerzeichen Der denierte Zeichensatz ist mglich in allen Namens-, Adress- und Verwendungszweckfeldern. Besondere Felder und Zeichenrestriktionen  Referenznummern Message-ID <MsgId>, Private-ID <PrvtId> und strukturierte Creditorreferenz <CdtrRefInf>  Numerische Zeichen 0 bis 9  Buchstaben A bis Z und a bis z  Sonderzeichen : ? , - ( + . )/aber ohne Leerzeichen  Mandatsreferenz <MndtId> hier gilt auch der eingeschrnkte Zeichensatz  Numerische Zeichen 0 bis 9  Buchstaben A bis Z und a bis z (Kleinbuchstaben werden wie Grobuchstaben behandelt)  Sonderzeichen : ? , - ( + . )/und Leerzeichen  Empfehlung, da die Mandatsreferenz besonders wichtig ist, z.B. fr Mandatshinterlegung K  eine Leerzeichen und nur eingeschrnkt Sonderzeichen verwenden K  eine fhrenden Nullen verwenden V  erwechslungsgefahr bei 0 und O  BIC/IBAN  Verwechslungsgefahr bei 0 und O  Der 8 bis 11 stellige BIC hat immer Buchstaben (A bis Z) an den ersten 6 Stellen  Der Lndercode des IBAN und der Glubiger-ID ist immer mit 2 Buchstaben zu belegen und die zweistellige Prfziffer numerisch

36

10.13 Konkurrierende Felder XOR

Huge Fehler bei der Feldbelegung sind Felder, die mehrfach auf verschiedenen Ebenen vorkommen oder an Bedingungen geknpft sind. Dieses wird durch das XML Prfschema (XSD) nur eingeschrnkt geprft.  Einige Felder gibt es auf Dateiebene (Paymentinfo) und auch auf Transaktionsebene, z.B.
Paymentinfo-Ebene
CreditorIdentication (nur SDD) CategoryPurpose Empfohlen Empfohlen (ntig fr HVB Produkt SEPA Gehaltszahlung) Empfohlen Variante 1 (ntig fr HVB Produkt SEPA Ultimate Auftraggeber) Picht Optional Picht

Transaktions-Ebene
Alternativ Alternativ

entweder oder/Pichtfeld
Picht bei SDD Optional

ChargeBearer Ultimate-Debtor (SCT) Ultimate Creditor (SDD) ServiceLevel-Code InstructionPriority LocalInstrument-Code (nur SDD)

Alternativ Variante 2

Picht SLEV Optional

Nicht erlaubt auf Transaktionsebene bei DK Nicht erlaubt auf Transaktionsebene bei DK Nicht erlaubt auf Transaktionsebene bei DK

Picht (SEPA, URGP) Optional Picht bei SDD (B2B, CORE, COR1)

 Bei einigen Feldern darf entweder das Eine oder das Andere verwendet werden. Beide Feldgruppen zu belegen, ist nicht mglich. Das XSD des DK prft dieses, aber das XSD fr EPC-Formate stellt hier keinen Fehler fest  Der Verwendungszweck kann entweder strukturiert <Strd> ODER unstrukturiert <Ustrd> angegeben werden. Beide knnen nicht gleichzeitig verwendet werden  Organisational-ID <OrgId> versus Private-ID <PrvtId>. Hier ist nur eine der beiden Elementengruppen erlaubt  Bei Nutzung von der Private-ID kann auch nur entweder eine Identikationsnummer <Id> mit Issuer <Issr> und Identikationsart <SchmeNm><Cd> und ODER ein Geburtstag mit Geburtsort <DtAndPlcOfBirth> verwendet werden

37

10.14 SEPA-Referenznummern und deren Verwendung

Welche Referenznummern gibt es in SEPA und wo werden die vergeben?
SEPA-Feld
MessageIdentication (<MsgId>) DTI Dateinummer Original MessageIdentication (<OrgnlMsgId>) PaymentInformationIdentication (<PmtInfId>) Original PaymentInformationIdentication (<OrgnlPmtInfId>) Dateinummer HVB Transaktionsreferenz HVB CreditorIdentication (Creditor Identier, <CdtrSchmeId>) Original CreditorIdentication (<OrgnlCdtrSchmeID>) InstructionIdentication (<InstrId>) Original InstructionIdentication End-to-End Identication (<EndToEndId>) Original End to End ID TransactionIdentication (<TxId>) Creditor Reference (CreditorReferenceInformation, <CdtrRefInf>) MandateIdentication (Mandate Reference, <MndtId>) Original MandateIdentication OrganisationIdentication (<OrgId>)

Beschreibung
Eindeutige technische Referenz der Datei des Dateierstellers HVB-Sammlerreferenz Ursprngliche Message ID bei Datei-Reject Referenz der logischen Datei (Sammlerreferenz) Ursprngliche Referenz der logischen Datei bei DateiReject Eindeutige Dateinummer von HVB vergeben Eindeutige HVB-Referenz der einzelnen Transaktion Eindeutige GlubigerIdentication (von Bundesbank) Nur bei Mandatsnderung die ursprngliche CreditorIdentication Technische Point-to-Point-Referenz Transaktionsreferenz, wird nicht weitergegeben Ursprngliche Point-to-Point-Referenz bei Datei-Reject Fachliche Auftraggeberreferenz wird an Empfnger weitergeleitet Ursprngliche Auftraggeberreferenz bei Datei-Reject Eindeutige Transaktionsnummer vom erstbeteiligten Institut vergeben Strukturierte Referenznummer im strukturierten Verwendungszweck Eindeutige Mandatsreferenz (bezogen auf GlubigerIdentication) Nur bei Mandatsnderung die ursprngliche Mandatsreferenz Identikationsnummer einer Organisation (BIC, BEI, Steuernummer, Kundennummer, etc.; siehe ISO20022 External Code List) Identikationsnummer einer natrlichen Person (Geburtsdatum/Ort, Sozialversicherungsnummer, Passnummer, Steuernummer, Kundennummer, etc.; siehe ISO External Code List)

Datei/TransaktionsEbene
GroupHeader

Verwendung Einreichung
SCT, SDD

GroupHeader Payment-Information Payment-Information Payment-Information Transaktion Payment-Information oder Transaktion Transaktion Transaktion Transaktion Transaktion Transaktion Transaktion Transaktion Transaktion Transaktion Payment-Information oder Transaktion Payment-Information oder Transaktion SCT, SDD SCT, SDD SDD SDD SCT, SDD SCT, SDD SCT, SDD SDD SDD *

PersonIdentication (<PrvtId>)

* in Deutschland Verwendung nicht empfohlen; Ergnzung zu InitiatingParty, Debtor, Creditor, UltimateDebtor, UltimateCreditor

38 Abbildung der SEPA-Referenznummern im MT940/942/camt und pain.002

SEPA-Feld
MessageIdentication (<MsgId>) DTI Dateinummer Original MessageIdentication (<OrgnlMsgId>) PaymentInformationIdentication (<PmtInfId>) Original PaymentInformationIdentication (<OrgnlPmtInfId>) Dateinummer HVB Transaktionsreferenz HVB CreditorIdentication (Creditor Identier, <CdtrSchmeId>) Original CreditorIdentication (<OrgnlCdtrSchmeID>) InstructionIdentication (<InstrId>) Original InstructionIdentication End-to-End Identication (<EndToEndId>) Original End to End ID TransactionIdentication (<TxId>) Creditor Reference (CreditorReferenceInformation, <CdtrRefInf>) MandateIdentication (Mandate Reference, <MndtId>) Original MandateIdentication OrganisationIdentication (<OrgId>) PersonIdentication (<PrvtId>) pain.002 pain.002 pain.002 pain.002 pain.002 pain.002

Reporting pain.002 Reporting MT940/942

pain.002 Wenn lnger als 16 Chars : :86: mit Identier KREF+ Wenn krzer: :61/7: :61/9: :61/8: :86: mit Identier CRED+ :86: mit Identier EREF+ Teil des strukturierten Verwendungszwecks (allerdings ohne Tags) :86: mit Identier MREF+ Nur CreditorIdentication (siehe oben)

Reporting camt.052/camt.053
<AddtlInfInd><MsgId> <NtryDtls><Btch><PmtInfId> <NtryDtls><TxDtls><Refs><PmtInfId> (only initiator entry) <NtryDtls><TxDtls><Refs><AcctSvcrRef> bzw. <NtryDtls><TxDtls><Refs><ClrSysRef> <NtryDtls><TxDtls> <RltdPties><Cdtr><Id>< PrvtId><Othr><Id> <NtryDtls><TxDtls><Refs><EndToEndId> <NtryDtls><TxDtls><Refs><TxId> Teil des strukturierten Verwendungszwecks <NtryDtls><TxDtls><Refs<MndtId> Nur CreditorIdentication (siehe oben)

39 End-To-End Referenz <EndToEndId> D  ie bis zu 35 stellige End-To-End Referenz ist vom Einreicher zu vergeben. Sie wird an den Endempfnger weitergeleitet und auch bei Retouren wieder an den Einreicher zurckgegeben  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 im Subfeld ?60-?63
<EndToEndId>12345678901234567890123456789012345</EndToEndId>

Mandatsnummer/Mandatsreferenz <MndtId>  Die Mandatsnummer ist in Zusammenhang mit der Glubiger-Identikationsnummer (CI) europaweit eindeutig  Die bis zu 35 stellige Mandatsnummer ist vom Einreicher (Creditor) bei SEPA-Lastschriften eindeutig zu vergeben  Die Mandatsnummer dient dem Zahlungspichtigen zur Abstimmung sowie fr etwaige Weisungen gegenber der Debitorbank (z.B. zum Sperren oder betragsmigen Einschrnken der Lastschrift sowie zur Hinterlegung von Abbuchungsauthorisierungen im B2B-Mandat)  Sie wird an den Zahlungspichtigen weitergeleitet im  Prenotication (empfohlen)  Pichtfeld in der SEPA-Lastschrift <MdtId>  Mandat zur Unterschrift (kann aber auch nachtrglich ergnzt werden)  Elektronischen Kontoauszug MT940 (Feld 86/Subfeld ?20-?29: MREF+[Mandatsreferenz] ) oder wenn kein Platz im Subfeld ?60-?63 Lastschriftretoure  Wenn sich die Mandatsnummer ndert, kann die nderung ber die standardisierte Mandatsnderung vorgenommen werden (siehe Kapitel Mandatsnderung)  Fr die Vergabe der Mandatsnummer beachten Sie bitte auch das Kapitel Zeichensatz (siehe Seite 36)
<MndtId>555544</MndtId>

40

11. Reporting bersicht

11.1 Reporting (Bank-Kunde)
Welches Bank-Kunde Format ist fr welchen Zweck? In der folgenden Tabelle nden Sie eine bersicht der mglichen Varianten von elektronischen Kontoinformationen rund um Kontoauszge, Avise, Buchungssammler und Fehlerinformationen.
Empfohlen fr
MT940 MT942 DTI Elektronischer Kontoauszug Altsysteme ZV-Avis Altsysteme Elektronische Weiterverarbeitung von Eingngen und Retourenverarbeitung Altsysteme Elektronischer Kontoauszug Neu Elektronisches ZV-Avis Neu Elektronische Weiterverarbeitung von Eingngen und Retourenverarbeitung Neu

Optionen

Einschrnkung/ zu Beachten
Nicht alle SEPA Felder werden durchgereicht Nicht alle SEPA Felder werden durchgereicht Nicht alle SEPA Felder werden durchgereicht. Nicht fr Lastschriftretouren vor Buchung

Format
MT940 MT942 DTAUS0 DTAUS1

Erstellungs Zeitpunkt
Tagesende Buchungstag stndlich Buchungstag stndlich Buchungstag

camt.053 camt.052 camt.054

camt.053.001.02 camt.052.001.02

Tagesende Buchungstag stndlich Buchungstag stndlich Buchungstag

E  lektronische Informatia  b Juni 2013 optional

on ber die eingereichte SEPA Datei auch: Lastschriftretouren vor Buchung

Nicht fr Lastschriftretouren vor Buchung (bis Juni 2013)

camt.054.001.02

camt.086

elektronisches Preis-reporting

camt.086.001.01

Monatlich oder quartalsmig je nach Wunsch des Kunden Sofort bei Fehlerfeststellung

pain.002

SEPA-Fehlernachrichtenvor Buchung fr das SEPA-MandatsManagement

Optional seit Nov 2012: auch SEPA Fehlernachrichten nach Buchung

Keine Lastschrift-Retourengebhrenausweisung

DK: pain.002.002.03 pain.002.002.02 EPC: pain.002.001.03

11.2 Buchung von SEPA Dateien

Buchung der Datei (Sammler-/Einzelsatzbuchung) Wie erfolgt die Einreicher-Dateibuchung auf dem Konto? Die Kontoeinstellung fr Dateieinreichungen mit mehr als einem Posten ist standardmig die Sammelbuchung. Auf Kundenwunsch knnen auch alle Zahlungen auf dem Konto einzeln gebucht werden, oder das Konto administriert werden, dass Sie pro Datei individuell whlen knnen, welche Datei gesammelt wird (z.B. Gehaltsdateien) und welche Dateien als Einzelbuchung auf dem Kontoauszug erscheinen sollen. In der eingereichten SEPADatei knnen Sie individuell pro Datei einstellen ob die Buchung als Sammel- oder Einzelbuchung erfolgen soll (Kennzeichen BatchBooking):
<PmtInfId> <BtchBookg>true</BtchBookg> </PmtInfId>

41 BatchBooking = true (Sammelbuchung)

BatchBooking = false (Einzelsatzbuchung)

Damit dieses Feld BatchBooking in der Verarbeitung bercksichtigt wird, beauftragen sie dieses bitte im Vorwege 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 fr die 10 Posten. Die fehlerhaften zwei Stze werden dem Einreicherkonto zum Ausgleich wieder gutgeschrieben (dies kann nach Wunsch in einer Sammelsumme oder als Einzelsatz gebucht werden). Die Information ber die Detail-Fehler erfolgt sofort mittels Fehlerprotokoll und wenn gewnscht ber die elektronische Statusinformation pain.002. Die Buchung der Einreichung und der fehlerhaften Stze erfolgt immer zum Buchungstag dieses ist insbesondere relevant bei Lastschrifteinreichungen mit z.B. 6 Tagen Vorlauf. Die gebuchten fehlerhaften Stze werden Ihnen dann am Buchungstag per MT940 bzw. camt.053/camt.054 zur Verfgung gestellt Einreicher - Nettoprinzip  Das Nettoprinzip (die fehlerhaften Stze werden berhaupt nicht gebucht) erfolgt nur, wenn die gesamte Datei abgelehnt wird. Auch hier erfolgt die Information ber die Detail-Fehler mittels Fehlerprotokoll und wenn gewnscht ber die elektronische Statusinformation pain.002 Wie erfolgt die Empfngerbuchung auf dem Konto? Eine groe Anzahl an Gut- oder Lastschriften knnen in SEPA auch gesammelt und auf dem Konto in einer Summe gebucht werden. Die Detailposten knnen Ihnen dann mittels einer elektronischen Datei zur Weiterverarbeitung zur Verfgung gestellt werden  DTI: Hier werden die SEPA-Eingnge gesammelt und von XML in DTAUS-Format konvertiert und als DTI zur Verfgung gestellt. Fr konkrete Konvertierungsregeln fragen Sie bitte Ihren Betreuer  camt.054: um die umfangreichen Felder des SEPA-XML-Formates auch fr die Weiterverarbeitung nutzen zu knnen

42

Auftraggeber

camt.053 (Kontoauszug) <Umsatz 1> <Sammelbuchung> <Umsatz 2> <Umsatz >

Auftraggeber

Bank

Empfnger

camt.054 (Sammlerdetails) <Sammler-Umsatz 1> <Sammler-Umsatz 2> <Sammler-Umsatz >

Auftraggeber

 Gleichartige Umstze (z.B. berweisungseingnge, Rcklastschriften) knnen beim Empfngerkonto gesammelt und in einem Betrag gebucht werden  bersichtlichkeit fr die Kontodispositionen wird erhht  Sammlerdetails werden in einem separaten Prozess des Kunden efzient abgewickelt Die Einrichtung einer Sammelverbuchung von Gutschriftseingngen oder Belastungen knnen bei Ihrem zustndigen Cash Management & eBanking Spezialist der Bank beantragt werden.

11.3 Status/Fehler Nachricht pain.002

Mit einer Status/Fehlerdatei pain.002 erhalten Sie elektronisch in pain-Dateiformat eine genaue Rckmeldung zu den fehlerhaften Stzen und die Art der Fehler. Hiermit knnen Sie ein eindeutiges Matching zu Ihren originalen Einreichungen sicherstellen.
Beispiel SEPA-Lastschrift Auftraggeber initiiert Auftraggeber-Bank initiiert Zahlungspichtiger-Bank initiiert Zahlungspichtiger inittiiert pain.002 pacs Reject Creditor Creditorbank Debtorbank Debtor

 ISO 20022 Nachrichten enthalten alle relevanten Informationen von der Einreichung bis zur Rckmeldung  Fehler-Report bereits vor Buchung (vergleichbar mit bestehendem Fehlerprotokoll)  Besonderheit bei SEPA DD:  Weiterleitung Auftrag an Zahlungspichtiger-Bank bereits vor Flligkeit  Prfung durch Zahlungspichtiger-Bank vor Flligkeit (z.B. Konto aufgelst) R  ckmeldung von Fehlern an Einreicher bereits vor Flligkeit bzw. vor Buchung  Ergnzt Information im Kontoauszug (camt.053), da dieser erst nach Buchung vorliegt

43

Auftraggeber initiierte R-Nachrichten: Vor Buchung  Rckruf (Revocation/Recall) z.B. Besttigung der Revocation

Einreicher Bank initiierte R-Nachrichten: Vor Buchung Zahlungspichtiger-Bank fr Lastschriften nicht SEPA-ready P  ichtfelder fehlen I BAN Check fehlerhaft Zahlungspichtiger initiierte R-Nachrichten: Vor Buchung M  andatssperre durch Zahlungspichtiger K  omplette Lastschriftssperre W  iderspruch bereits vor Buchung

Zahlungspichtiger-Bank initiierte R-Nachrichten bei Lastschriften: Vor Buchung  Reject, z.B. Zahlungspichtiger-Konto besteht nicht Z  ahlungspichtiger-Konto gesperrt

Unterscheidung der Rckgabe vor oder nach Buchung? Relevant ist hier immer der Interbankensettlement-Zeitpunkt. Rckgaben vor diesem Zeitpunkt werden dem Einreicher als Storno gebucht und Rckgaben danach als Retoure. Bei der Empfngerbank kann es sein, dass auch Rckgaben vor Buchung aus Transparenzgrnden dem Kunden gebucht und gleich wieder zurckgebucht werden. Die Unterscheidung auf der Einreicherseite ist insbesondere relevant, da ja fr Lastschrift-Folgeeinreichungen die richtige Sequenz gewhlt werden muss. Wie kann der Einreicher jetzt die richtige R-Nachricht identizieren? Anhand der Rckgabegrnde lsst sich keine eindeutige Zuordnung treffen.
Vor Buchung
Buchung pain.002 Storno ja

Nach Buchung
Retoure optional

Option pain.002 auch fr Retouren nach Buchung dies kann sinnvoll sein, wenn fr das Mahnwesen zu den Lastschriftretouren nur ein einheitliches Format genutzt werden soll (der Standard wre pain.002 fr Rckgaben vor Buchung und camt.054 fr Retouren nach Buchung) w  enn die Option pain.002 genutzt wird, ist folgendes zu beachten D  ie Unterscheidung der pain.002 Nachricht vor und nach Buchung lsst sich derzeit nur anhand der Referenznummer <MsgId> bei der HVB durchfhren. 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.002.03 die Felder fr Interbankpreise und Zinskompensationen nicht erlaubt sind, werden diese im pain.002.002.03 nicht explizit ausgewiesen. Der Bruttorckgabebetrag (inkl. Retourenpreise und Zinskompensationen) ist eingestellt in <InstrAmt>

44

11.4 Rckgabegrnde
Die HypoVereinsbank stellt Ihren Kunden die Rckgabegrnde in den Kontoauszgen sowohl papierhaft als auch elektronisch in den Datentrgerinformationen zur Verfgung.
Return-Reason Name ISO-Code
AC01 AC04 AC06 AC13 AG01 AG02 AM01 AM02 AM03 AM04 AM05 AM06 AM07 AM09 AM10 ARDT BE01 BE04 BE05 BE06 BE07 DT01 ED05 FF01 Incorrect Account Number Closed Account Number Blocked Account InvalidDebtorAccountType Transaction Forbidden Invalid Bank Operation Code Zero Amount Not Allowed Amount NotAllowedCurrency Insufcient Funds Duplication TooLowAmount BlockedAmount WrongAmount InvalidControlSum Already returned transaction (Recall-Answer) InconsistenWithEndCustomer Account address invalid UnrecognisedInitiatingParty Identier fo the Creditor incorrect UnknownEndCustomer MissingDebtorAddress Invalid Date Settlement Failed reject due to an invalid le format

German Translation
IBAN fehlerhaft Konto aufgelst Konto gesperrt (auch bei unwiderruicher Lastschriftsperre) Der Zahlungspichtige ist ein Verbraucher (relevant bei SEPA-Firmenlastschrift) Zahlungsart fr Konto unzulssig Transaktionscode ungltig (auch falsche Lastschriftsequenz) Betrag ist Null Betrag ist unzulssig Whrung ist unzulssig Rckgabe mangels Deckung Doppeleinreichung Betrag zu niedrig Betrag gesperrt Betrag nicht korrekt Summe Einzelbetrge ungleich Prfsumme Bereits zurckgegeben (Antwort auf SCT-Recall) Kennung des Endkunden passt nicht zu der entsprechenden Kontonummer Adressangaben unvollstndig Absender unbekannt/ CI incorrect Auftraggeber/Zahlungsempfnger unbekannt Adresse des Zahlers (Zahlungspichtigen) fehlt oder unvollstndig Ungltiges Datum (z. B. falsches Abrechnungsdatum) Die Begleichung der Transaktion ist fehlgeschlagen Dateiformat ungltig

Returncode in MT940/DTI Returncode Textschlssel-Ergnzung in pain.002

901 902 903 930 904/914** 905 911* 911*/914** 911*/914** 906/914** 907 911*/914** 911*/914** 911*/914** 911* 905* 911*/914** 908/914** 911* 911* 914/914** 916* 914 911 AC01 AC04 AC06 AC13 AG01/MS03** AG02 AM01 AM02/MS03** AM03/MS03** AM04/MS03** AM05 AM06/MS03** AM07/MS03** AM09/MS03** AM10 AG02 BE01/MS03** BE04/MS03** BE05 BE06 BE07/MS03** DT01 ED05 FF01

45 Fortsetzung
Return-Reason Name ISO-Code
FF05 FOCR LEGL DirectDebitTypeIncorrect positive request for cancellation recall Legal Decision (Recall-Answer)

German Translation
Falsche Lastschriftart (COR1 trotz fehlender COR1-Vereinbarung verwendet) Rckgabe aufgrund eines Recalls (Rckrufes) Rechtliche Entscheidung (Antwort auf SCT-Recall) Kein gltiges Mandat (Rckgabe einer nicht autorisierten Lastschrift bis 13 Monate. Weiterverwendung des Mandates nicht erlaubt) Die Daten zum Mandat fehlen oder sind nicht korrekt Ungltiges Dateiformat Kein flliger Einzug Widerspruch durch den Zahler (Zahlungspichtigen, Rckgabe bis zu 8 Wochen ohne Angaben von Grnden) Kontoinhaber verstorben Rckgabe durch den Zahler (Zahlungspichtigen) vor Flligkeit (Refusal) Grund nicht speziziert Sonstige Grnde Keine Anwort von Kunde (Antwort auf SCT-Recall) Original-SCT nicht erhalten (Antwort auf SCT-Recall) BIC unbekannt BIC ungltig Transaktionsreferenz innerhalb der Nachricht nicht eindeutig Aufsichtsrechtliche Grnde, fehlendes Konto/ fehlende ID des Zahlers Aufsichtsrechtliche Grnde, fehlender Name/ fehlende Adresse des Zahlers Aufsichtsrechtliche Grnde, fehlender Name/ fehlende Adresse des Zahlungsempfngers Aufsichtsrechtliche Grnde Spezische Dienstleistung der Bank des Zahlers (auch aufgrund von Positiv-Negativlisten Weisung des Zahlungspichtigen) CutOff-Zeit berschritten

Returncode in MT940/DTI Returncode Textschlssel-Ergnzung in pain.002

931 919 917*/914** FF05 FOCR MS03

MD01 MD02 MD03 MD05

No Mandate Missing Mandatory Information Mandate Invalid File format CollectionNotDue

909 910 911 916/914**

MD01 MD02 FF01 DT01/MS03**

MD06 MD07 MS02 MS03 NARR NOAS NOOR PY01 RC01 RF01 RR01 RR02 RR03 RR04

Refund Request By End Customer End Customer Deceased Not Specied Reason Customer Generated Not Specied Reason Agent Generated Narrative No Answer from Customer (Antwort auf SCT-Recall) No Original Transaction Received Unknown BIC Bank Identier Incorrect NotUniqueTransactionReference Not Specied Reason Customer Generated Missing Debtor Name or Address Missing Creditor Name or Address Regulatory Reason Specic Service offered by Debtor Bank File received after Cut-off Time

912 913/914** 914 914 914 911*/914** 911* 915 915 907 917/914** 917/914** 917/914** 917/914**

MD06 MD07/MS03 MS02 MS03 MS03 MS03 RF01 RC01 RC01 RF01 RR01/MS03** RR02/MS03** RR03/MS03** RR04/MS03**

SL01 TM01

918 916

SL01 TM01

*  Meist keine Buchung deshalb kein MT940, sondern nur fr pain.002 interessant **  Datenschutz Einschrnkung Abkommen ber SEPA-Inlandslastschrift; bei aktiven SDD-Retouren Datenschutz auf DebtorbankSeite innerhalb Deutschlands zu beachten, deshalb anonymisiert 914 bzw MS03

Die genaue Feldbelegung stellt Ihnen auf Anfrage Ihr Cash Management & eBanking Spezialist gerne zur Verfgung.

46

11.5 Payment Status Report/pain.002-SEPA Credit Transfer

Wichtige fachliche XML Felder fr pain.002-SEPA Credit Transfer Feldnamen
GrpHdr GroupHeader MsgId CreDtTm DbtrAgt OrgnlMsgId OrgnlMsgNmId OrgnlNbOfTxs OrgnlCtrlSum GrpSts

Beschreibung pain.002.002.03
Absenderdaten Bankreferenznummer pro Datei Datum/Zeit der Dateierstellung Kreditinstitut BIC Ursprngliche Referenznummer der Kundeneinreichung Ursprngliche XML-Dateityp Ursprngliche Anzahl aller Einzeltransaktionen Ursprngliche Kontrollsumme in Euro der Einreichung Status auf Dateiebene

Befllung DF Abkommen 2.5/2.6

1 x pro logische Datei Pichtfeld Pichtfeld Pichtfeld nur SCT Originaldaten Originaldaten Originaldaten Originaldaten Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein Nur zusammen mit GrpSts. Wenn Orgtr-BICOrBEI gefllt nicht erlaubt Nur zusammen mit GrpSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt Siehe Anhang mgliche Rckgabegrnde lt. ISO20022 Codelist Anzahl je nach Originaldaten Abschnitt optional, wenn GrpSts gefllt RJCT-Reject pain.001 max. 35 Zeichen ISO-Date 8 bzw. 11 Stellen

StsRsnInf-Orgtr-Nm StsRsnInf-Orgtr-Id-OrgIdBICOrBEI StsRsnInf-Rsn OrgnlPmtInf Original-PaymentInstruction-Information und Status OrgnlPmtInfId OrgnlNbOfTxs OrgnlCtrlSum PmtInfSts

Initiator Rckgabe Kunde Initiator Rckgabe Bank Rckgabegrund Original-Auftraggeber-Daten und Status auf logischer Datei Ursprngliche Referenz der Einreichung Ursprngliche Anzahl aller Einzeltransaktionen Ursprngliche Kontrollsumme in Euro der logischen Datei Status auf logischer Dateiebene

Name (max. 70 Zeichen) = Kundeninitiert BIC = Bankinitierte Rckgabe

Originaldaten Originaldaten Originaldaten Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein Nur zusammen mit PmtInfSts. Wenn Orgtr-BICOrBEI gefllt nicht erlaubt Nur zusammen mit PmtInfSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt Siehe Anhang mgliche Rckgabegrnde lt. ISO20022 Codelist RJCT-Reject

StsRsnInf-Orgtr-Nm

Initiator Rckgabe Kunde

Name (max. 70 Zeichen) = Kundeninitiiert BIC = Bankinitiierte Rckgabe

StsRsnInf-Orgtr-Id-OrgIdBICOrBEI StsRsnInf-Rsn

Initiator Rckgabe Bank

Rckgabegrund

47 Fortsetzung
Feldnamen
CdtTrfTxInf CreditTransferTransaction-Information StsId OrgnlInstrId OrgnlEndToEndID TxSts

Beschreibung
Transaktions-Information Bank-Referenz der Rckgabe Ursprngliche technische Referenz zwischen Einreicher und Bank Ursprngliche Kunden-Referenz Status auf Transaktions-Ebene

Befllung DF Abkommen 2.5/2.6

Anzahl je nach Originaldaten. Optional Originaldaten Originaldaten Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein Nur zusammen mit TxSts. Wenn Orgtr-BICOrBEI gefllt nicht erlaubt Nur zusammen mit TxSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt Siehe Anhang mgliche Rckgabegrnde lt. ISO20022 Codelist Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten TRF Max. 140 Zeichen HIGH or NORM SEPA RJCT-Reject Abschnitt optional wenn PmtInfSts gefllt Max. 35 Zeichen

StsRsnInf-Orgtr-Nm

Initiator Rckgabe Kunde

Name (max. 70 Zeichen) = Kundeninitiiert BIC = Bankinitiierte Rckgabe

StsRsnInf-Orgtr-Id-OrgIdBICOrBEI StsRsnInf-Rsn InstrAmt ReqdExctnDt InstrPrty SvcLvl CtgyPurp PmtMtd Ustrd-RmtInf Strd-CdtrRefInfCdtrRefTp-Cd Strd-CdtrRefInf-CdtrRef

Initiator Rckgabe Bank

Rckgabegrund Ursprnglicher Betrag und Whrungskennzeichen Ursprnglich gewnschter Ausfhrungstermin Ursprngliche Prioritt der Ausfhrung Ursprngliches Servicelevel Ursprngliche Zahlungsart der Datei Ursprngliches Zahlungsinstrument: Credit Transfer Ursprnglicher unstrukturierter Verwendungszweck Ursprnglicher strukturierter Verwendungszweck fr VL-Leistung oder CreditorReference Ursprnglicher strukturierter VWZ Teil2 a)  VL-Leistung: Bezugsjahr der Vermgenswirksamen Leistung und Referenz alternativ b) CreditorReference: prfzifferngerechte CreditorReference Ursprnglicher vom Kontoinhaber abweichender Auftraggeber Ursprnglicher Name Auftraggeber Ursprngliches Land der Anschrift des Auftraggebers Ursprngliche Anschrift Auftraggeber Ursprngliche IBAN des Auftraggebers Ursprnglicher BIC/SWIFT Code des Auftraggebers Ursprngliche BIC/SWIFT-Code der Begnstigten Bank Ursprnglicher Name Begnstigter Ursprngliche Anschrift Begnstigter Ursprngliches Land der Anschrift des Begnstigten Ursprnglicher IBAN des Begnstigten Ursprnglicher abweichender Endbegnstigter

UltmtDbtr Dbtr-Nm Dbtr-PstlAdr-Ctry Dbtr-PstlAdr-AdrLine DbtrAcct-IBAN DbtrAgt-BIC CdtrAgt-BIC Cdtr-Nm Cdtr-PstlAdr-AdrLine Cdtr-PstlAdr-Ctry CdtrAcct-IBAN UltmtCdtr

Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten

48

11.6 Payment Status Report/pain.002-SEPA Direct Debit

Wichtige fachliche XML Felder fr pain.002-SEPA Direct Debit Feldnamen
GrpHdr GroupHeader MsgId CreDtTm CdtrAgt OrgnlMsgId OrgnlMsgNmId OrgnlNbOfTxs OrgnlCtrlSum GrpSts

Beschreibung pain.002.002.03
Absenderdaten Bankreferenznummer pro Datei Datum/Zeit der Dateierstellung Kreditinstitut BIC Ursprngliche Referenznummer der Kundeneinreichung Ursprnglicher XML-Dateityp Ursprngliche Anzahl aller Einzeltransaktionen Ursprngliche Kontrollsumme in Euro der Einreichung Status auf Dateiebene

Befllung DF Abkommen 2.5/2.6

1 x pro logische Datei Pichtfeld Pichtfeld Pichtfeld nur SDD Originaldaten Originaldaten Originaldaten Originaldaten Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein Nur zusammen mit GrpSts. Wenn Orgtr-BICOrBEI gefllt ist, nicht erlaubt Nur zusammen mit GrpSts Wenn Orgtr-Nm gefllt ist, nicht erlaubt Siehe Anhang mgliche Rckgabegrnde lt. ISO20022 Codelist Anzahl je nach Originaldaten Originaldaten Originaldaten Originaldaten Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein Nur zusammen mit PmtInfSts. Wenn Orgtr-BICOrBEI gefllt ist, nicht erlaubt Nur zusammen mit PmtInfSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt Siehe Anhang mgliche Rckgabegrnde lt. ISO20022 Codelist Anzahl je nach Originaldaten Optional Originaldaten Originaldaten Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein Nur zusammen mit TxSts. Wenn Orgtr-BICOrBEI gefllt ist, nicht erlaubt Nur zusammen mit TxSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt RJCT-Reject Abschnitt optional, wenn PmtInfSts gefllt Max. 35 Zeichen RJCT-Reject Abschnitt optional, wenn GrpSts gefllt RJCT-Reject pain.008 Max. 35 Zeichen ISO-Date 8 bzw. 11 Stellen

StsRsnInf-Orgtr-Nm

Initiator Rckgabe Kunde

Name (max. 70 Zeichen) = Kundeninitiiert BIC = Bankinitiierte Rckgabe

StsRsnInf-Orgtr-Id-OrgIdBICOrBEI StsRsnInf-Rsn OrgnlPmtInf Original-PaymentInstructionInformation und Status OrgnlPmtInfId OrgnlNbOfTxs OrgnlCtrlSum PmtInfSts

Initiator Rckgabe Bank

Rckgabegrund Original-Auftraggeber-Daten und Status auf logischer Datei Ursprngliche Referenz der Einreichung Ursprngliche Anzahl aller Einzeltransaktionen Ursprngliche Kontrollsumme in Euro der logischen Datei Status auf logischer Dateiebene

StsRsnInf-Orgtr-Nm

Initiator Rckgabe Kunde

Name (max. 70 Zeichen) = Kundeninitiiert BIC = Bankinitiierte Rckgabe

StsRsnInf-Orgtr-Id-OrgIdBICOrBEI StsRsnInf-Rsn CdtTrfTxInf CreditTransfer-TransactionInformation StsId OrgnlInstrId OrgnlEndToEndID TxSts

Initiator Rckgabe Bank Rckgabegrund Transaktions-Information Bank-Referenz der Rckgabe Ursprngliche technische Referenz zwischen Einreicher und Bank Ursprngliche Kunden-Referenz Status auf Transaktions-Ebene

StsRsnInf-Orgtr-Nm

Initiator Rckgabe Kunde

Name (max. 70 Zeichen) = Kundeninitiiert BIC = Bankinitiierte Rckgabe

StsRsnInf-Orgtr-Id-OrgIdBICOrBEI

Initiator Rckgabe Bank

49 Fortsetzung
Feldnamen
StsRsnInf-Rsn InstrAmt ReqdColltnDt CdtrSchmeId-Id-PrvtId-OthrId-Id Prtry SvcLvl LclInstrm-Cd SeqTp CtgyPurp PmtMtd Mndtld DtOfSgntr AmdmntInd OrgnlMndtId

Beschreibung
Rckgabegrund Ursprnglicher Betrag und Whrungskennzeichen Ursprnglich gewnschter Flligkeitstermin Ursprngliche CreditorIdentication Ursprngliche Identikation des Schemas Ursprnglicher Service Ursprngliche Lastschriftsart: Basislastschrift oder Firmenlastschrift Ursprngliche Sequenz: Erst-, Folge-, Einmaloder letztmalige Lastschrift Ursprngliche Zahlungsart der Datei Ursprngliches Zahlungsinstrument: Direct Debit Ursprngliche Mandatsreferenz Ursprngliches Datum, zu dem das Mandat unterschrieben wurde Ursprngliches Kennzeichen, ob das Mandat verndert wurde Ursprngliche Referenz des alten Mandats, falls sich die Mandatsreferenz (MndtId) gendert hat Ursprnglicher alter Creditor Name, falls sich der Zahlungsempfnger gendert hat Ursprngliche alte CreditorIdentication, falls sich die CreditorIdentication (CdtrSchmeIdI) gendert hat Ursprngliche alte IBAN des Zahlungspichtigen, falls sich die IBAN gendert hat Ursprngliche alte Debitorbank Ursprngliches elektronisches Mandat eMandate-Signatur Ursprnglicher unstrukturierter Verwendungszweck Ursprnglicher vom Kontoinhaber abweichender Zahlungspichtiger Ursprnglicher Name Zahlungspichtiger Ursprngliches Land der Anschrift des Zahlungspichtigen Ursprngliche Anschrift Zahlungspichtiger Ursprngliche IBAN des Zahlungspichtigen Ursprnglicher BIC/SWIFT Code des Zahlungspichtigen Ursprnglicher BIC/SWIFT-Code der Zahlungsempfnger Bank Ursprnglicher Name Zahlungsempfnger Ursprngliches Land der Anschrift des Zahlungsempfngers Ursprngliche Anschrift Zahlungsempfnger Ursprngliche IBAN des Zahlungsempfngers Ursprnglicher abweichender Zahlungsempfnger

Befllung DF Abkommen 2.5/2.6

Siehe Anhang mgliche Rckgabegrnde lt. ISO20022 Codelist Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Vernderung=True Standard=False DD SEPA SEPA CORE or B2B * FRST, RCUR, OOFF oder FNAL

OrgnlCdtrSchmeId-Nm OrgnlCdtrSchmeId-Id-PrvtIdOthrId-Id OrgnlDbtrAcct-IBAN OrgnlDbtrAgt-Id ElctmcSgntr Ustrd-RmtInf UltmtDbtr Dbtr-Nm Dbtr-PstlAdr-Ctry Dbtr-PstlAdr-AdrLine DbtrAcct-IBAN DbtrAgt-BIC CdtrAgt-BIC Cdtr-Nm Cdtr-PstlAdr-Ctry Cdtr-PstlAdr-AdrLine CdtrAcct-IBAN UltmtCdtr

Originaldaten Originaldaten

Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Originaldaten Max. 140 Zeichen Kennzeichen SMNDA

* ab 2013 auch COR1 fr die verkrzte Vorlauffristlastschrift D-1

50

11.7 Elektronischer Kontoauszug MT940

Obwohl die bisherigen SWIFT-Strukturen bei elektronischen Kontoauszgen und Vormerkposten im MT940 und MT942 unverndert bestehen bleiben, haben sich die Felder 61 und 86 im Format gendert. Mit den SEPAProdukten ergeben sich auch neue Geschftsvorfallcodes.

Geschftsvorfallcodes GVC 1XX 104 105 108 109 116 119 152 153 154 156 159 166 169 171 174 177 181 184 Bezeichnung ZAHLUNGSVERKEHR SEPA Direct Debit (Einzelbuchung-Soll, B2B) SEPA Direct Debit (Einzelbuchung-Soll, Core) SEPA Direct Debit (Soll; Rckbelastung, B2B) SEPA Direct Debit (Soll; Rckbelastung, Core) SEPA Credit Transfer (Einzelbuchung-Soll) SEPA Credit Transfer (Einzelbuchung-Soll, Spendenzahlung)4 SEPA Gutschrift aus Dauerauftrag (Einzelbuchung-Haben)5 SEPA Credit Transfer (Einzelbuchung-Haben, Lohn-, Gehalts-, Rentengutschrift)1 SEPA Credit Transfer (Einzelbuchung-Haben, Vermgenswirksame Leistungen)2 SEPA Credit Transfer (Einzelbuchung-Haben, berweisung ffentlicher Kassen)3 SEPA Credit Transfer Retoure (Haben) fr unanbringliche berweisung (Rckberweisung) SEPA Credit Transfer (Einzelbuchung, Haben) SEPA Credit Transfer (Einzelbuchung-Haben, Spendenzahlung)4 SEPA Direct Debit Einreichung (Einzelbuchung-Haben, Core) SEPA Direct Debit (Einzelbuchung-Haben, B2B) SEPA Credit Transfer Online (Einzelbuchung-Soll) SEPA Direct Debit (Haben; Wiedergutschrift, Core) SEPA Direct Debit (Haben; Wiedergutschrift, B2B)

Geschftsvorfallcodes GVC 191 192 193 194 195 196 197

1

Bezeichnung SEPA Credit Transfer (Sammler-Soll) SEPA Direct Debit (Sammler-Haben, Core) SEPA Direct Debit (Soll, Reversal) SEPA Credit Transfer (Sammler-Haben) SEPA Direct Debit (Sammler-Soll, Core) SEPA Direct Debit (Sammler-Haben, B2B) SEPA Direct Debit (Sammler-Soll, B2B)

 ird verwendet fr folgende ISO-Codes aus dem Feld Purpose: BONU, W PENS, SALA und ab Nov. 2013 auch PAYR. Die Belegung des Feldes Category Purpose wird ignoriert.  ird verwendet fr den ISO-Code CBFF aus dem Feld Purpose. Die BeleW gung des Feldes Category Purpose wird ignoriert.

 ird verwendet fr folgende ISO-Codes aus dem Feld Purpose: GOVT, W SSBE, BENE. Die Belegung des Feldes Category Purpose wird ignoriert. 4 Wird verwendet fr den ISO-Code aus dem Feld Purpose: CHAR. Die  Belegung des Feldes Category Purpose wird ignoriert. 5 Wird verwendet fr den ISO-Code aus dem Feld Purpose: RINP (ab Nov  2013) Die Belegung des Feldes Category Purpose wird ignoriert.
3

Struktur des Feldes 61/7 (Kundenreferenz) fr SEPA-Transaktionen Inhalt Bemerkung Aus SCT oder SDD: Payment  Wenn lnger als 16 Stellen: Information/Identication, KREF+ und kompletter falls bei der Einreichung nicht Feldinhalt im Feld 86 gefllt, Bulk-Message-ID Wenn leer: NONREF Struktur des Feldes 61/9 Bei SDD-Rckgaben: Einstellung des Ursprungsbetrages mit OCMT (Ursprungsbetrag) und CHGS (Summe aus Gebhren und ggf. Zinsausgleich)

51

Struktur des Feldes 86 fr SEPA-Transaktionen Pos. bzw. Feldschl. Die ersten 3 Zeichen ?00 ?10 ?20 ?29 Bezeichnung Lnge/Format*, bisher Lnge/Format*, neu Keine nderung Keine nderung Bemerkung Fr SEPA werden spezische GVCs vergeben (1xx) Fr SEPA werden spezische Buchungstexte vergeben In der Transaktion vorhandene SEPA-Attribute werden via Bezeichner dargestellt: EREF + [Ende-zu-Ende-Referenz] KREF + [Kundenreferenz] MREF + [Mandatsreferenz] CRED + [Creditor Identier] oder DEBT + [Originators Identication Code] SVWZ + [SEPA-Verwendungszweck] ABWA + [abweichender Auftraggeber] ABWE + [abweichender Empfnger] Jeder Bezeichner muss am Anfang eines Subfeldes (z.B. ?21) stehen, Fortsetzung des Inhalts ggf. im nachfolgenden Subfeld ohne Wiederholung des Bezeichners. Bei Rckgabe SVWZ + [RUECKUEBERWEISUNG bzw RUECKLASTSCHRIFT und Rckgabegrund im Klartext]

Geschftsvorfallcode 3 n Buchungstext Primanoten-Nr. Verwendungszweck 27 a 10 x 10 x 27 x

Keine nderung

?30 ?31

BLZ berweisender/ Zahlungsempfnger Kto.-Nr. berweisender/Zahlungsempfnger Name berweisender/Zahlungsempfnger Textschlsselergnzung Verwendungszweck

12 n 24 n

12 x 34 x IBAN anstelle der Kontonummer

?32 ?33

2 x 27 x

Keine nderung

SEPA-Lnge 70 (2 x 35); gekrzt auf 54 (2 x 27)

?34

3n

Keine nderung

Nutzung einer Mapping-Tabelle zur Umwandlung des vierstelligen SEPA-Rckgabecodes in einen dreistelligen Code Ggf. Fortsetzung von ?20 ?29

?60 ?63

4 x 27 x

Keine nderung

* n = numerisch, a = alphabetisch, x = alphanumerisch

52

12. Internationale SEPA Formate

Die Lnderformate
Wenn Sie nicht (nur) in Deutschland SEPA-Dateien einreichen wollen, bietet das ISO20022 XML Format hierzu mehrere Mglichkeiten  Lnderspezische Varianten Multibankenstandards), 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 Lnder Subsets basieren auf dem ISO20022  Sie werden meist von allen nationalen Banken angenommen  Die Formate haben detailliertere Prfschemata (XSD), fr korrekte SEPA-Feldbelegung Oder sie verwenden internationale Formate auf Basis ISO20022 wenn Sie nicht lnderindividuell die jeweiligen Kunde-Bank-Formate einsetzen mchten:

Das europische SEPA Basisformat EPC

Folgende Besonderheiten ergeben sich bei der Verwendung des SEPA EPC Formats: Es deniert lediglich die SEPA Produkte (SEPA CT, SEPA DD Core/Cor1 und SEPA DD B2B) Akzeptanz bei der Einreicherbank muss fr jede Formatvariante neu geprft werden

53 Unterschiede zwischen EPC und dem deutschen DK-Format I m Gegensatz zu der DK-DF-Anlage 3 mit den detaillierten Formatbeschreibungen und den XML-Schemata zur direkten Dateiprfung, gibt es fr das EPC-Format nur grobe Beschreibungen  Fr 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  EPC basiert wie beim DK-Format auf ISO20022, es werden nur Felder im Rahmen des SEPA Spektrums genutzt  Vom DK-Format abweichender Name-Space/Header  SCT: pain.001.001.03 statt pain.001.002.03  SDD: pain.008.001.02 statt pain.008.002.02 S  tatusinfo: pain.002.001.03 statt pain.002.002.03 K  eine Containervarianten mglich  Die fachliche Formatbeschreibung bzw. Feldbelegung weicht zwischen EPC und DK nur geringfgig voneinander ab

CGI Common Global Implementation (Format) Initiative

Ziel der Initiative ist es  einen gemeinsamen globalen Standard  auf Basis von ISO 20022 Payment Nachrichten  fr die Kunde-Bank Schnittstelle  fr alle Zahlungsverkehrsprodukte zu denieren. Die Kernpunkte sind:  Gleiche Satzstrukturen fr alle Arten von Zahlungen bei allen Banken weltweit (Schaffen eines MultibankenStandards, aber nur im Kunde Bank Umfeld)  Das richtige Format fr die zuknftige Planung fr weltweit ttige Konzerne, die Inlandszahlungsverkehr und Auslandszahlungsverkehr auf XML umstellen wollen  Es knnen alle Whrungen und sonstige Informationen mitgegeben werden, mssen aber mit jeder Bank bilateral abgestimmt werden  CGI-XML basiert auf ISO20022 XML ohne Beschrnkungen, aber unter Bercksichtigung nationaler Regeln und/ oder Regeln einer Community (z.B. SEPA)  Forum fr Banken und Bankenverbnde, Corporates, Verbnde und Hndler entwickeln diesen Standard weiter (derzeitige Teilnehmer: 29 Corporates und 33 Banken (darunter auch die UniCredit) www.swift.com/cgi

54  Das CGI Format ist allerdings extrem komplex und eignet sich derzeit nur fr einzelne Grokunden da,  Derzeit nur wenige Banken das Format entgegennehmen  Die vielfltigen Felder (ber 500 nutzbare ISO-Felder) im Interbankverkehr auf weniger als 150 Felder reduziert werden und somit die Information fr den Zahlungsempfnger nur sehr eingeschrnkt ist.  Eine bilaterale Vereinbarung mit Banken ist bei etwa 20 % der Feldbelegungen notwendig  Eine bilaterale Vereinbarung ber die Bercksichtigung von Codewrtern ist auch mit den Banken bzw. den Zahlungsempfnger notwendig  Vom DK-Format abweichender Name-Space/Header  SCT: pain.001.001.03 statt pain.001.002.03  SDD: pain.008.001.02 statt pain.008.002.02  Statusinfo: pain.002.001.03 statt pain.002.002.03  Keine Angabe zur Schemalocation und damit keine direkte Dateiprfung ber die allgemeine ISO-XMLFormatprfung hinaus  Keine Containervarianten mglich  Die fachliche Formatbeschreibung bzw. Feldbelegung weicht zwischen CGI und DK sehr stark voneinander ab

Der File-Header zeigt, um welches Format es sich handelt

<?xml version=1.0 encoding=UTF-8?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.002.03" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

-> DK-Version 2.5

<?xml version=1.0 encoding=UTF-8?> <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

55 Grascher berblick ISO20022 Payments Formate

ISO20022 Basis-Standard CGI

EPC ISO20022-XSD

DK Lnder-Varianten-XSD STUZZA CBI

Empfohlenes Format vom EPC

Lndersubsets

Kurzvergleich der DK/EPC/CGI-Formate

Ziel-Produkte
Verwendungszweck

Deutsches DK-Format
Unstrukturierter Verwendungszweck oder ein Teil der strukturierten Verwendungszwecke. Max. 140 Stellen Unstrukturierte Adresszeilen (2x70 Zeichen) Optional Ja, gewhrleistet, da alle DK-Felder auf Basis des EPC-Formates entwickelt wurden

Europisches EPC-Format
Unstrukturierter Verwendungszweck oder ein Teil der strukturierten Verwendungszwecke. Max. 140 Stellen Unstrukturierte Adresszeilen (2x70 Zeichen) Teilweise verpichtend Ja, gewhrleistet, da im SEPAInterbankverkehr das EPC-Format angewendet wird

Internationales CGI-Format
700 Stellen unstrukturierter Verwendungszweck und groe Variation von strukturierten Verwendungszwecken Strukturierte und Unstrukturierte Adresszeilen (bis 7x70 Zeichen) Teilweise verpichtend Nein, nur EPC-Felder und EPC maximale Feldbelegungen werden durchgeleitet

Adressangaben Organisational und Person IDs Interbankdurchgngigkeit der Informationen (z.B. Adressangaben, Verwendungszweck, IDs ) bei SEPA-Zahlung. Kommt die Information bei der Empfngerbank an? Bankenerreichbarkeit Bankenstandard Prfschema (XSD)

Alle deutschen Banken Deutscher Multibankenstandard Ja, eigenes vorhanden

Viele europische Banken Annahme ist mit Bank abzustimmen Nur ISO 20022

Hauptschlich die 33 CGI-Banken ber 20 % der Felder sind bilateral zu vereinbaren Nur ISO 20022

56 Welches Format ist fr Sie sinnvoll? Vorgehen/Entscheidungskriterien:  Denieren, welche Produkte umgesetzt werden sollen (SEPA, Auslandszahlungsverkehr, Urgent, Auszge,) bzw. mit welchen Zahlungsverkehrsprodukten Sie anfangen mchten.  Denieren Sie dann welche speziellen Informationen Sie ber die Zahlung transportieren mchten.  Reicht ihnen der unstrukturierte Verwendungszweck oder bentigen sie auch den strukturierten Verwendungszweck? Bentigen Sie die Durchleitung von Ultimates oder zahlen Sie On Behalf? Wollen Sie die besonderen Organisational IDs oder Private IDs nutzen? W  ir empfehlen Ihnen auf jeden Fall die Standardfelder unabhngig vom Format zu nutzen: Unstrukturierte Adresszeilen Maximale Belegung bercksichtigen: Adresse (70), Name (70), Verwendungszweck (140) Starten Sie auf Basis der EPC-Felder bzw. Interbankendurchgngigkeit (mit EPC und DK gewhrleistet) F  r die Bestimmung des technischen Formats ist auch wichtig:  Bankenerreichbarkeit. Ist Ihre Bank mit dem Format erreichbar (Die HVB nimmt neben dem DK auch seit 2012 die EPC und CGI-Formate an)

Fr weitere Informationen bitte wenden Sie sich an Ihren CashManagement Spezialisten und genaue Spezikationen der Felder die bei der HVB fr die DK, EPC und CGI-Formate angenommen werden, wenden Sie sich bitte an Ihren Cash Management & eBanking Spezialisten.

57

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 (Januar 2013) geplant sind. Zuknftige nderungen sind vorbehalten. Haftungsausschluss Die in dieser Verffentlichung enthaltenen Angaben basieren auf sorgfltig ausgewhlten Quellen, die als zuverlssig gelten. Wir geben jedoch keine Gewhr fr die Richtigkeit oder Vollstndigkeit der Angaben. Hierin zum Ausdruck gebrachte Meinungen geben unsere derzeitige Ansicht wieder und knnen ohne vorherige Ankndigung gendert werden. Die hierin bereitgestellten Berichte dienen nur allgemeinen Informationszwecken und sind kein Ersatz fr eine unabhngige Finanzberatung. Kein Bestandteil dieser Verffentlichung soll vertragliche Verpichtungen aufseiten der DivisionCorporate & Investment Banking der UniCredit Bank AG, Mnchen, betrachten. Inhalt und Aufbau dieses Broschre der UniCredit Bank AG sind urheberrechtlich geschtzt. Die Vervielfltigung von Informationen oder Daten, insbesondere die Verwendung von Texten, Textteilen oder Bildmaterial, bedarf der vorherigen Zustimmung der UniCredit Bank AG. UniCredit Bank AG, Mnchen. Alle Rechte vorbehalten. Die UniCredit Bank AG untersteht der Aufsicht der Bundesanstalt fr Finanzdienstleistungsaufsicht. UniCredit Bank AG, Rechtsform: Aktiengesellschaft, Sitz: Mnchen. Impressum UniCredit Bank AG Corporate & Investment Banking 80331 Mnchen E-Mail: sepa@unicreditgroup.de

UniCredit Bank AG Corporate & Investment Banking Am Tucherpark 16 80538 Mnchen www.hvb.de/corporatebanking

Stand Februar 2013. Alle Angaben beruhen auf der bei Drucklegung geltenden Gesetzes- und Rechtslage.

50062040