+ All Categories
Home > Documents > HVB SEPA Techn Spezifikationen 2013 Final

HVB SEPA Techn Spezifikationen 2013 Final

Date post: 19-Oct-2015
Category:
Upload: watumba
View: 222 times
Download: 1 times
Share this document with a friend

of 58

Transcript
  • Anlage zur SEPA- Kundeninformation

    Technische Spezifikationen und Formate

    Aktualisierte Auflage Stand 02/2013

  • Inhalt1. Dateiformate und SEPA-Verfahren

    der aktuelle Stand in Deutschland 5

    2. Zusammenhang der Kunden- und Bankformate (ISO20022) 6

    3. SEPA-Kundenformate 6

    4. Ausblick neue DF-Version 2.7/ November 2013 7

    5. Nachrichtentypen-Erkennung 9

    6. Aufbau der Kundendatei (XML*) 11

    7. SEPA Credit Transfer (SCT) 13

    8. Beispiel einer Kunden-Datei 16

    9. SEPA Direct Debit (SDD) 17

    10. SEPA hufig genutzte Zahlungs- informationen im Format 21

    10.1 Verwendungszweck/RemittanceInfo 21

    10.2 Zahlungsgrund/Purpose Code 23

    10.3 Produktkategorie/Category Purpose 24

    10.4 Fnf Beteiligte in einer SEPA-Nachricht 24

    10.5 Name, Adresse 25

    10.6 IBAN 26

    10.7 Glubiger-Identifikation/CI 27

    10.8 Identifikations-Nummern (OrgID/PrivateID) 28

    10.9 Ultimate/Reference Party/On Behalf 29

    10.10 Mandatsnderung/ Mandate-Amendment 30

    10.11 Lastschriftsequenz 33

    10.12 Zeichensatz und Umlaute 35

    10.13 Konkurrierende Felder XOR 36

    10.14 Referenz-Nummern und deren Verwendung 37

    11. Reporting (Bank-Kunde) 40

    11.1 Reporting (Bank-Kunde) 40

    11.2 Buchung von SEPA Dateien 40

    11.3 Status/Fehler Nachricht pain.002 42

    11.4 Rckgabegrnde 44

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

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

    11.7 Elektronischer Kontoauszug MT940 50

    12. Internationale SEPA Formate 52

  • 4Fr die Umstellung auf SEPA mssen Datenfelder in ihren Systemen entsprechend angepasst werden. In der vorliegenden Broschre erhalten Sie wesentliche Details zu den technischen Spezifikationen 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 finden Sie eine Zusammenfassung der wichtigsten fachlichen Felder, die zur Umstellung auf SEPA erforderlich sind.

    Weitere Details oder Angaben zu technischen Feldern entnehmen Sie dem nachfolgenden Link: Anlage 3 der Schnittstellenspezifikation fr die Datenfernbertragung zwischen Kunde und Kreditinstitut gem DF-Abkommen Version 2.6 vom 18.06.2012, gltig ab 17. November 2012www.ebics.de/index.php?id=77

    Weitere Informationen zur finalen Beschreibung der Formate erhalten Sie bei folgenden Stellen:Die Deutsche Kreditwirtschaft (DK)Anlagen zum Kapitel 2, SEPA-Zahlungsverkehrder Version 2.6 der Anlage 3 Stand: Finale Version vom 18.06.2012XML-Schemata fr SEPAwww.ebics.de/

  • 51. 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

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

    OriginatorID1234 1234.56 SPUEDE2UXXX Creditor Name DE21500500009876543210

  • 62. 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.

    3. SEPA-KundenformateFormat-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: Definition der Formate fr XML Auszug (camt.052, camt.053, camt.054)

    Kundeninformation

    pain

    pain = Payment initiation Zahlungsverkehrsinitiierung fr

    berweisungen (pain.001) Lastschriften (pain.008)

    pacs

    pacs = Payment clearing & settlement Clearing fr

    berweisungen (pacs.008) Lastschriften (pacs.003)

    camt

    camt = cash management Konto-Informationen

    Avis (camt.052) Auszug (camt.053) DTI (camt.054)

    pain pain = Payment Initiation Fehler-

    Nachrichten Fehler-Meldung/Statusmessage

    (pain.002)

    pacs pacs = C&S Fehler-Nachrichten Fehler-Meldung/Statusmessage

    Zahlungsauftrag Fehlerinformation

    Bank

    Kunde

    Kunde

  • 7November 2010 (DF Anlage 3 Version 2.5) Summenfelder (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 2011keine neuen Formate

    November 2012 (DF Anlage 3 Version 2.6) keine Format nderungen Rckgabegrund AC13 wenn Zahlungspflichtiger 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 gegebe-nenfalls 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 2013Zum 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 Die HVB nimmt bereits vor der deutschlandweiten Einfhrung COR1 Basis-Lastschriften im pain.008.002.02

    und pain.008.001.02 entgegen, wenn der Zahlungspflichtige bei der HVB ist

    COR1

  • 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

    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 ganz weg gelassen Bei der SEPA-Lastschrift bleibt das Feld weiterhin ein Pflichtfeld, aber es kann dann, statt dem

    optionalen Feld , der Wert NOTPROVIDED in das Feld eingestellt werden

    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)

    URGP

    HYVEDEMMXXX

    NOTPROVIDED

    Neu ab Nov 2013 optionaler BIC fr nationale Zahlungen:

  • 95. Nachrichtentypen-ErkennungWie erkennen Sie um welche Nachricht und welche Version es sich handelt? Aufbau einer XML Nachrichtenbezeichnung:

    pain.001.002.03 Version

    V3 ISO-Stand 2009 Variante

    Die Deutsche Kreditwirtschaft Nachricht/Message-Definition

    CustomerCreditTransferInitiation Geschftsfeld/Business-Aresa

    Payment Initiation

    pain.001.002.03Business-AreapainPAymentINnitiation

    Message-Definition 001berweisungCustomerCreditTransferInitiation 008LastschriftDirectDebitInitiation 002CustomerPaymentStatusReport(Reject) 007CustomerPaymentReversal(Lastschriftsstorno) 009bis012Mandats-Initierung,-nderung,-Stornound-Akzeptanz

    Variante 002ZKA/DKVersion 001IS020022/EPC

    Version 03Version2010/2012 02Version2009 01Version2008

    camtCAshMAnagement 052BanktoCustomerAccountReportZV-AvisMT942-Nachfolger 053BanktoCustomerStatementKontoauszugMT940-Nachfolger 054BanktoCustomerDebitCreditNotificationSammlerDTI-Nachfolger 055CustomerPaymentCancellationRequestKundenRckruf 086BankServiceBilling(ehem.TWIST-BSB)

    in Planung in Planung

    in Planung

  • 10

    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

    SEPA Auftragsarten Direct Debit

    Namespace/Schema SDD Core 2.5 (2010)/2.6 (2012)

    SDD B2B 2.5 (2010)/2.6 (2012)

    EBICS-mixed urn:iso:std:iso:20022:tech:xsd: pain.008.002.02

    CDDpain.008.002.02

    CDBpain.008.002.02

    EBICS-XML-Container urn:conxml:xsd:container.nnn.002.02(+urn:iso:std:iso:20022:tech:xsd: pain.008.002.02)

    CDCpain.008.002.02

    C2Cpain.008.002.02

    EBICS-Reject urn:iso:std:iso:20022:tech:xsd: pain.002.002.03

    CDZ (Zip-Container) oderCBC (XML-Container)pain.002.002.03

    CDZ (zip) oderCBC (Container)pain.002.002.03

    HBCI-Sammel HKDME HKBME

    SEPA Auftragsarten Credit Transfer DK-Format

    Namespace/Schema SCT 2.5 (2010) 2.6 (2012)EBICS-mixed urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 CCT

    pain.001.002.03

    EBICS-mixed Sonderprozess ohne VEU-Details urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 XCT pain.001.002.03

    EBICS-XML-Container

    urn:conxml:xsd:container.nnn.002.02(+urn:iso:std:iso:20022:tech:xsd:pain.001.002.03)

    CCCpain.001.002.03

    EBICS-Reject urn:iso:std:iso:20022:tech:xsd:pain.002.002.03 CRZ (Zip-Container) oder CRC (XML-Container)pain.002.002.03

    HBCI-Sammel HKCCM, HKCME

    HBCI-Einzel HKCCS, HKCSE

    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.

    Beauftragung einer SEPA Credit Transfer - Kunden-FormatFolgende Auftragsarten sind ber die bertragungswege (EBICS/HBCI bzw. FinTS) mglich

    Beauftragung einer SEPA Direct Debit - Kunden-FormatFolgende Auftragsarten sind ber die bertragungswege (EBICS/HBCI bzw. FinTS) mglich

  • 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 (Zahlungspflichtiger) 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

    PaymentInfoDebtor: Konto-3

    TransactionInfoCreditor/EUR

    pain.001.002.03GroupHeaderInitiatingParty Firma-1

    pain.001.002.03GroupHeaderInitiatingParty Firma-1

    PaymentInfoDebtor: Konto-1

    TransactionInfoCreditor/EUR

    PaymentInfoDebtor: Konto-2

    TransactionInfoCreditor/EUR

    EBICS-Auftragsart CCT (mixed)

    EBICS-Auftragsart CCT (mixed)

    PaymentInfoDebtor: Konto-3

    pain.001.002.03GroupHeaderInitiatingParty Firma-1

    pain.001.002.03GroupHeaderInitiatingParty Firma-1

    PaymentInfoDebtor: Konto-1

    TransactionInfoCreditor/EUR

    PaymentInfoDebtor: Konto-2

    TransactionInfoCreditor/EUR

    TransactionInfoCreditor/EUR

  • 12

    * 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) empfiehlt 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 Zahlungspflichtigen-IBAN

    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) , , und

    da fr jedes Produkt eine eigene Sende-Auftragsart verwendet werden muss

    Je logische Datei (PaymentInf) insbesondere auch getrennt nach Auftraggeber-IBAN Flligkeitstag bzw. Ausfhrungstag Lastschrift Sequenz (First, Recurrent, Final, OneOff) Unterscheidung zwischen SCT und SCT-Preferred (gleichtgiges Clearing) Sammel/Einzelbuchung der Einreichung Anzahl der Stze bzw. Datei-Grenbeschrnkung siehe unten

    In einer logischen Datei knnen gemischt werden z.B. : verschiedene Empfnger bzw Zahlungspflichte bei Lastschriften verschiedene Betrge Verwendungszweck , Zahlungsgrnde , End-toEnd-Referenz verschiedene Mandatsinformationen bei Lastschriften

    Gruppierung von Dateien und was kann gemischt angeliefert werden?

  • 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 Beschreibung pain.001.002.03

    Befllung DF Abkommen 2.5/2.6

    Nheres siehe Seite

    GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei 11, 12

    MsgId (Message-Id)

    Einreicher-Referenznummer pro Datei Pflichtfeld (eindeutig) Max. 35 Zeichen 35, 37-38

    CreDtTm (CreationDateTime)

    Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date

    NbOfTxs (NumberOfTransactions)

    Anzahl aller Einzeltransaktionen Pflichtfeld Unbegrenzt

    CtrlSum (ControlSum)

    Kontrollsumme in Euro der Einreichung Empfohlen Unbegrenzt

    InitgPty-Nm (InitiatingPartyName)

    Name Einreicher (kann vom Namen des Auftraggebers abweichen

    Pflichtfeld Max. 70 Zeichen 25

    InitgPty-Nm-Id-OrgId/PrvtId (InitiatingPartyOrganisa-tion-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    PmtInf PaymentInstruction - Information

    Auftraggeberdaten beliebig oft mglich, empfohlen max. 100

    11, 12

    PmtInfId (PaymentInformation-ID)

    Referenz der Einreichung Pflicht Max. 35 Zeichen 35, 37-38

    PmtMtd (PaymentMethod)

    Zahlungsinstrument: Credit Transfer Pflicht TRF

    BtchBookg (BatchBooking)

    Auftraggeberbuchung Sammler/Ein-zelsatz

    Optional, in Stammdaten administriert

    false Einzelbuchungtrue Sammelbuchung

    40-41

    NbOfTxs (NumberOfTransactions)

    Anzahl aller Einzeltransaktionen Empfohlen Unbegrenzt

    CtrlSum (ControlSum)

    Kontrollsumme in Euro der logischen Datei

    Empfohlen Unbegrenzt

    InstrPrty (InstructedPriority)

    Prioritt der Ausfhrung: high oder norm

    Optional, in Stammdaten administriert

    HIGH SCT PreferredNORM SCT Normal

    36

    SvcLvl-Cd (ServiceLevelCode)

    Service Schema Pflicht SEPA 8, 36

    CtgyPurp (CategoryPurpose)

    Zahlungsart der Datei Optional, in Stammdaten administriert

    Fr gleichtgige Gehalts-zahlung SALA

    24, 36

    ReqdExctnDt (RequestedExecution Date)

    Gewnschter Ausfhrungstermin Pflichtfeld ISO-Date

    Dbtr-Nm (DebtorName)

    Name Auftraggeber. Ggf. von Bank mit Kontoinhaber berschrieben

    Pflichtfeld Max. 70 Zeichen 25

    Dbtr-PstlAdr-Ctry (DebtorCountry)

    Land der Anschrift des Auftraggebers Optional Lndercode ISO3166, DE fr Deutschland

    25

    Dbtr-PstlAdr-AdrLine (DebtorAddress)

    Anschrift Auftraggeber. Ggf. von Bank mit Kontoadresse berschrieben

    Optional Max. 140 Zeichen 25

    Dbtr-Id-OrgId/PrvtId (DebtorOrganisation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    DbtrAcct-IBAN (DebtorIBAN)

    IBAN des Auftraggebers Pflichtfeld Max. 34 Zeichen 8, 26

    DbtrAcct-Ccy (DebtorAccountCurrency)

    Whrung des Auftraggeberkontos Optional Whrungscode

    DbtrAgt-BIC (DebtorAgentBIC)

    BIC/SWIFT Code des Auftraggebers Pflichtfeld 8 bzw. 11 Stellen 8

    UltmtDbtr (UltimateDebtorName)

    Vom Kontoinhaber abweichender Auftraggeber. Rein informatorischer Charakter

    Optional Max. 70 Zeichen 6, 25, 29, 36

    UltmtDbtr-Id-OrgId-Othr (UltimateDebtor-IBAN)

    Ultimate Einreicherbelastungs-IBAN Optional, nur wenn Produkt Ultimate Auftraggeber

    Max. 34 Zeichen 26, 29, 28, 35

    ChrgBr (ChargeBearer)

    Preis-Verrechnung immer shared Empfohlen SLEV 36

  • 15

    Feldnamen Beschreibung Befllung DF Abkommen 2.5/2.6

    Nheres siehe Seite

    CdtTrfTxInf CreditTransfer- Transaction-Information

    Transaktions-Information beliebig oft mglich, empfohlen max. 100.000

    11, 12

    InstrId (Instruction-ID)

    Technische Referenz zwischen Einreicher und Bank

    Optional, wenn gefllt: eindeutig Max. 35 Zeichen 35, 37-38

    EndToEndID (End2End-ID)

    Referenz, wird bis Begnstigten durchgereicht

    Pflichtfeld (eindeutig, sonst: NOTPROVIDED)

    Max. 35 Zeichen 35, 37-39

    InstrAmt (Instructed Amount)

    Betrag und Whrungskennzeichen Pflichtfeld Nur Euro erlaubt

    UltmtDbtr (UltimateDebtor)

    Abweichender Auftraggeber Optional. Nicht wenn auf PmtInf-Ebene schon gefllt

    Max. 70 Zeichen 6, 25, 29, 36

    UltmtDbtr-Id-OrgId/PrvtId (UltimateDebtorOrgani-sation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    CdtrAgt-BIC (CreditorAgentBIC)

    BIC/SWIFT-Code der Begnstigten Bank Pflichtfeld 8 bzw. 11 Stellen 8

    Cdtr-Nm (CreditorName)

    Name Begnstigter Pflichtfeld Max. 70 Zeichen 25

    Cdtr-PstlAdr-Ctry (CreditorCountry)

    Land der Anschrift des Begnstigten Optional Lndercode ISO3166, DE fr Deutschland

    25

    Cdtr-PstlAdr-AdrLine (CreditorAddress)

    Anschrift Begnstigter Optional Max. 140 Zeichen 25

    Cdtr-Id-OrgId/PrvtId (CreditorOrganisation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 35-38

    CdtrAcct-IBAN (CreditorIBAN)

    IBAN des Begnstigten Pflichtfeld Max. 34 Zeichen 8, 26

    UltmtCdtr (UltimateCreditorName)

    Abweichender Endbegnstigter. Rein informatorischer Charakter

    Optional Max. 70 Zeichen 6, 25, 29

    UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrgani-sation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35, 37-38

    Purp (Purpose)

    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

    Optional ISO20022 ExternalPurposeCode-Liste

    6, 23, 50

    Ustrd-RmtInf (UnstructuredRemit-tanceInfo)

    Unstrukturierter Verwendungszweck Empfohlen Max. 140 Zeichen 21, 36

    Strd-CdtrRefInf-CdtrRefTp-Cd (StructuredCreditor Reference-Code)

    Strukturierter Verwendungszweck fr VL-Leistung oder CreditorReference

    Nur wenn kein unstrukturierter Verwendungszweck

    SCOR 21-22, 36

    Strd-CdtrRefInf-CdtrRef (StructuredCreditor Reference)

    Strukturierter Verwendungszweck Teil 2a) VL-Leistung: Bezugsjahr der

    Vermgenswirksamen Leistung und Referenz

    alternativb) CreditorReference:

    Prfziffern gerechte CreditorReference

    Nur wenn kein unstrukturierter Verwendungszwecka) in Verbindung mit Purp=CBFF:

    Bezugsjahr der VL und Referenzb) 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 finden Sie im DF-Abkommen Spezifikation der Datenformate.

    Fortsetzung

  • 16

    8. Beispiel einer Kunden-DateiGroupHeader Beschreibung DTAUS-Feld

    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"> 20121118-105506 2012-11-18T10:55:06 1 MEIER PAYMENT MUENCHEN

    XML Schema und XSD Location

    GroupHeader MessageID eindeutige Referenz der Datei Creation Date/Time NumberOf-Transactions optional Gesamtsumme EUR ber alle logischen Dateien Name Initiating Party (z.B. DATEV)

    (~DTA-A7)

    (DTA-A6)

    Paymentinformation logische Datei

    PAYMENT-20110318-105506 TRF true 1 1234.56 HIGH SEPA SALA 2012-11-19 MEIER CORNELIA MUENCHEN DE67700202700064535072 HYVEDEMMXXX MEIER GEHALTSABTEILUNG SLEV

    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)

    Auftraggeber IBAN

    Auftraggeber BIC

    Ultimate Auftraggebername

    SELV = Share

    (~DTA-A10)

    (DTA-E4)(DTA-E8)

    (DTA-A11b)

    (DTA-C15)

    (~DTA-C11)

    (~DTA-C10)

    CreditTransferTransaction Einzeltransaktion

    OriginatorID1234 1234.56 SPUEDE2UXXX Creditor Name DE21500500009876543210 PENS Unstructured Remittance Information

    End2End-Id Referenz der Zahlung aus Sicht des Auftraggebers

    Betrag in EUR

    Creditor Empfnger BIC

    Empfngername

    Empfnger IBAN

    Purpose Textschlssel der Zahlung siehe ISO20022 external Code list

    Remittance-Info Verwendungszweck 140 Stellen

    (DTA-C12)

    (~DTA-C4)

    (DTA-C14a + Erw)

    (~DTA-C5)

    (~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 Mandat muss zum Abgleich auch bei der Debitorbank vorliegen

    Unterschiede gegenber Inlandslastschrift (wird abgelst zum 1.2.2014) Angabe der Glubiger Identifikationsnummer (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 DebitFeldnamen Beschreibung

    pain.008.002.02Befllung DF Abkommen 2.5/2.6

    Inhalt des papierhaften Mandates

    Nheres siehe Seite

    GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei 11, 12

    MsgId (Message-Id)

    Einreicher-Referenznummer pro Datei

    Pflichtfeld (eindeutig) Max. 35 Zeichen 35, 37-38

    CreDtTm (CreationDateTime)

    Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date

    NbOfTxs (NumberOfTransactions)

    Anzahl aller Einzeltransaktionen Pflichtfeld Unbegrenzt

    CtrlSum (ControlSum)

    Kontrollsumme in Euro der Einreichung

    Empfohlen Unbegrenzt

    InitgPty-Nm (InitiatingPartyName)

    Name Einreicher (kann abweichen von Auftraggebernamen)

    Pflichtfeld Max. 70 Zeichen 25

    InitgPty-Nm-Id-OrgId/PrvtId (InitiatingPartyOrgani-sation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    PmtInf PaymentInstruction-Information

    Zahlungsempfnger-Daten beliebig oft mglich, empfohlen max. 100

    11, 12

    PmtInfId (PaymentInformation-ID)

    Referenz der Einreichung Pflichtfeld Max. 35 Zeichen 35, 37-38

    PmtMtd (PaymentMethod)

    Zahlungsinstrument: Direct Debit Pflichtfeld DD

    BtchBookg (BatchBooking)

    Auftraggeberbuchung Sammler/Einzelsatz

    Optional, wenn administ-riert in Stammdaten

    true-Sammelbuchung false-Einzelsatz-buchung

    40-41

    NbOfTxs (NumberOfTransactions

    Anzahl aller Einzeltransaktionen Empfohlen Unbegrenzt

  • 18

    Feldnamen Beschreibung pain.008.002.02

    Befllung DF Abkommen 2.5/2.6

    Inhalt des papierhaften Mandates

    Nheres siehe Seite

    CtrlSum (ControlSum)

    Kontrollsumme in Euro der logischen Datei

    Empfohlen Unbegrenzt

    SvcLvl-Cd (ServiceLevelCode)

    Service Schema Pflicht SEPA 36

    LclInstrm-Cd (LocalInstrumentCode

    Lastschriftsart: normale SEPA-Core-Basislastschrift oder SEPA-B2B-Firmenlastschrift

    Pflichtfeld (innerhalb GrpHdr nicht mischbar)

    CORE oder B2B * 7, 33, 36

    SeqTp (SequenceType)

    Sequenz: Erst-, Folge-, Einmal- oder letztmalige-Lastschrift

    Pflichtfeld FRST, RCUR, OOFF oder FNAL

    Pflicht (wiederkehrend oder einmalig)

    31, 33-34

    CtgyPurp (CategoryPurpose)

    Zahlungsart der Datei Optional Nicht zur Weitergabe an Endkunden

    24, 36

    ReqdColltnDt (RequestedCollection-Date)

    Flligkeitsdatum der Lastschrift (Datum der Belastung auf Kto. des Bezogenen)

    Pflichtfeld ISO-Date 33

    Cdtr-Nm (CreditorName)

    Name Zahlungsempfnger. Ggf. von Bank mit Kontoinhaber berschrieben

    Pflichtfeld Max. 70 Zeichen Pflicht 25

    Cdtr-PstlAdr-Ctry (CreditorCountry)

    Land der Anschrift des Zahlungs-empfngers

    Optional Lndercode ISO3166, DE fr Deutschland

    Pflicht 25

    Cdtr-PstlAdr-AdrLine (CreditorAddress)

    Anschrift Zahlungsempfnger. Ggf. von Bank mit Kontoadresse berschrieben

    Optional Max. 140 Zeichen Pflicht 25

    CdtrAcct-IBAN (CreditorIBAN)

    IBAN des Zahlungsempfngers Pflichtfeld Max. 34 Zeichen 8, 24

    CdtrAcct-Ccy (CreditorAccount Currency)

    Kontowhrung: muss EUR sein Optional EUR

    CdtrAgt-BIC (CreditorBIC)

    BIC/SWIFT Code des Zahlungs-empfngers

    Pflichtfeld 8 bzw. 11 Stellen 8

    UltmtCdtr (UltimateCreditor)

    Vom Kontoinhaber abweichender Zahlungsempfnger. Rein informa-torischer Charakter

    Optional Max. 70 Zeichen 6, 25, 29, 36

    UltmtCdtr-Id--OrgId-Othr (UltimateCreditorIBAN)

    Ultimate Einreicher-Gutschrifts-IBAN

    Optional, nur wenn Produkt Ultimate Auftraggeber

    Max. 34 Zeichen 26, 28-29

    UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrga-nisation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    ChrgBr (ChargeBearer)

    Preis-Verrechnung immer shared Pflichtfeld Ab DF-Abkommen 2.6 gendert auf Empfohlen

    SLEV 36

    CdtrSchmeId-Id-PrvtId-OthrId-Id (CreditorIdentification)

    CreditorIdentification. Eindeutiges Identifikationsmerkmal des Zahlungsempfngers (per legal entity)

    Pflichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich

    Max. 35 Zeichen Pflicht 27, 36-38

    Fortsetzung

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

  • 19

    Feldnamen Beschreibung Befllung DF Abkommen 2.5/2.6

    Inhalt des papierhaften Mandates

    Nheres siehe Seite

    Drct DbtTrfTxInf

    Direct Debit Transac-tion-Information

    Transaktions-Information beliebig oft mglich, empfohlen max. 100.000

    11, 12

    InstrId (Instruction-ID)

    Technische Referenz zwischen Einreicher und Bank

    Optional, wenn gefllt: eindeutig

    Max. 35 Zeichen 35, 37-38

    EndToEndID (End2End-ID)

    Referenz, wird bis Zahlungs- pflichtigen durchgereicht

    Pflichtfeld (eindeutig, sonst: NOTPROVIDED)

    Max. 35 Zeichen 35, 37-39

    InstrAmt (Instructed Amount)

    Betrag und Whrungskennzeichen Pflichtfeld Nur Euro erlaubt

    Mndtld (MandateID)

    Eindeutige Mandatsreferenz Pflichtfeld Max. 35 Zeichen 35, 37-39

    DtOfSgntr (DateOfSignature)

    Datum, zu dem das Mandat unterschrieben wurde

    Pflichtfeld ISO-Date Pflicht, im Papier-mandat auch Ort der Unterschrift und Unterschrift

    AmdmntInd (AmendmentIndicator)

    Kennzeichen, ob das Mandat verndert wurde

    Pflichtfeld Vernderung = TrueStandard = False

    30-32

    OrgnlMndtId (OriginalMandateID)

    Eindeutige Referenz des ursprngli-chen Mandats, falls sich die Mandatsreferenz (MndtId) gendert hat

    Nur bei Mandats- vernderung (AmdmntInd = True)

    Max. 35 Zeichen 30-32, 35, 37-39

    OrgnlCdtrSchmeId-Nm (OriginalCreditorName)

    Ursprnglicher Creditor Name, falls sich der Zahlungsempfnger gendert hat

    Nur bei Mandats- vernderung (AmdmntInd = True)

    Max. 70 Zeichen 25, 30-32

    OrgnlCdtrSchmeId-Id-PrvtId-OthrId-Id (OriginalCreditorIdenti-fication)

    Ursprngliche CreditorIdentifica-tion, falls sich die Creditor- Identification (CdtrSchmeIdI) gendert hat

    Nur bei Mandats- vernderung (AmdmntInd = True)

    Max. 35 Zeichen 27, 30-32, 35, 37-38

    OrgnlDbtrAcct-IBAN (OriginalDebtorIBAN)

    Ursprnglicher IBAN des Zahlungs-pflichtigen, falls sich der IBAN gendert hat

    Nur bei Mandats- vernderung (AmdmntInd = True)

    Max. 34 Zeichen 26, 30-32

    OrgnlDbtrAgt-Id (OrignalDebtorAgentID)

    Ursprngliche Debtorbank hat sich gendert. Neueinreichung mit Sequenz FRST ntig

    Nur bei Mandats- vernderung (AmdmntInd = True)

    Kennzeichen SMNDA 30-32, 34

    ElctmcSgntr (ElectronicSignature)

    Elektronisches Mandat eMandate - elektronische Signatur

    Optional. Nicht fr papierhafte Mandate

    Max. 1.025 Zeichen; erst Max. eMandate relevant

    CdtrSchmeId-Id-PrvtId-OthrId-Id (CreditorIdentification)

    CreditorIdentification. Eindeutiges Identifikationsmerkmal des Zahlungsempfngers (per legal entity)

    Pflichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich.

    Max. 35 Zeichen 27, 36-38

    UltmtCdtr (UltimateCreditorName)

    Name abweichender Zahlungsempfnger

    Optional. Nicht wenn auf PmtInf-Ebene schon gefllt

    Max. 70 Zeichen 6, 25, 29, 36

    UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrga-nisation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    DbtrAgt-BIC (DebtorAgentBIC)

    BIC/SWIFT-Code der zahlungspflichtigen Bank

    Pflichtfeld 8 bzw. 11 Stellen 8

    Dbtr-Nm (DebtorName)

    Name Zahlungspflichtiger Pflichtfeld Max. 70 Zeichen 25

    Dbtr-PstlAdr-Ctry (DebtorCountry)

    Land der Anschrift des Zahlungspflichtigen

    Optional Lndercode ISO3166, DE fr Deutschland

    Pflicht 25

    Dbtr-PstlAdr-AdrLine (DebtorAddress)

    Anschrift Zahlungspflichtiger Optional Max. 140 Zeichen Pflicht 25

    Fortsetzung

  • 20

    Feldnamen Beschreibung Befllung DF Abkommen 2.5/2.6

    Inhalt des papierhaften Mandates

    Nheres siehe Seite

    Dbtr-Id-OrgId/PrvtId (DebtorOrganisation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    DbtrAcct-IBAN (DebtorIBAN)

    IBAN des Zahlungspflichtigen Pflichtfeld Max. 34 Zeichen Pflicht 8, 26

    UltmtDbtr (UltimateDebtor)

    Name abweichender Zahlungs- pflichtiger. Rein informatorischer Charakter

    Optional Max. 70 Zeichen Optional 6, 25, 29

    UltmtDbtr-Id-OrgId/PrvdtId (UltimateDebtorOrga-nisation-Id/Private-ID)

    Identification DK nicht empfohlen Diverse 28, 35-38

    Purp (Purpose)

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

    Optional ISO20022 ExternalPurposeCode-Liste

    6, 23, 50

    Ustrd-RmtInf (Unstructured RemittanceInfo)

    Unstrukturierter Verwendungs-zweck

    Empfohlen Max. 140 Zeichen Optional (Vertragsnummer und Beschreibung)

    21, 36

    Strd-CdtrRefInf-CdtrRefTp-Cd (StructuredCreditor Reference-Code)

    Strukturierter Verwendungszweck DK nicht empfohlen SCOR 21, 36

    Strd-CdtrRefInf-Cdtr Ref(StructuredCreditorReference)

    Strukturierter Verwendungszweck Teil 2

    DK nicht empfohlen Max. 35 Zeichen 21, 36

    Fortsetzung

  • 21

    10. SEPA hufig genutzte Zahlungsinformationen im Format

    10.1 Verwendungszweck

    Verwendungszweck 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 und

    eine Detaillierung der beteiligten Parteien (Adresse und Identifikationsnummern) vorgenommen werden Es wird daher empfohlen den unstrukturierten Verwendungszweck zu verwenden

    Strukturierter Verwendungszweck Der strukturierte Verwendungszweck kommt in 2 Fllen in FrageVermgenswirksame Leistungen (VL-Zahlungen) Wenn im strukturierten Verwendungszweck unter 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

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

    1234567890123456789012345678901234567890123456789012345678

    9012345678901234567890123456789012345678901234567890123456789012345678901234567890

    CBFF

    SCOR XX3/123456789

  • 22

    SCOR RF98123456789012345678901

    Strukturierte Creditor Referenz Belege mit Prfziffern gerechten Verwendungszwecken gibt es anlog den BZ-Belegen im Inlandszahlungs-

    verkehr, 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

  • 23

    ... PENS

    10.2 Zahlungsgrund: Purpose Code

    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

    Purpose- Code - Auszug

    Erklrung Spezieller Geschfts-vorfall-Code fr elektro- nischen Auszug, bzw. Anmerkungen

    ADVA Vorabzahlung

    AGRT Landwirtschaft

    AIRB Luftverkehr

    ALMY Alimente und Unterhalt

    BECH Kindergeld

    BENE Arbeitslosengeld GVC Haben 156

    BLDM Gebudepflege

    BONU Bonuszahlung GVC Haben 153

    BUSB Busverkehr

    CASH Cash Mananagement

    CBFF Vermgenswirksame Leistung

    GVC Haben 154

    CBTV Kabelfernsehen

    CDBL Kreditkartenabrechnung

    CFEE Stornogebhr

    CHAR Spende GVC Soll 119, Haben 169

    CLPR Autokredit

    COMM Kommissionszahlung

    COST Kosten Allgemein

    CSLP Sozialversicherungsab-gaben

    DCRD Debitkartenzahlung

    DNTS Zahnarzt Service

    ELEC Stromrechnung

    ENRG Energie

    ESTX Grundsteuer

    GASB Gasrechnung

    GDDS Warenkauf/Verkauf

    GOVI Staatliche Versicherung

    GOVT Zahlung an/von ffentli-chen Kassen

    GVC Haben 156

    GWLT Kriegsversehrtenzahlung

    HLTC Gesundheits Service

    HLTI Krankenversicherung

    Purpose- Code - Auszug

    Erklrung Spezieller Geschfts-vorfall-Code fr elektro- nischen Auszug, bzw. Anmerkungen

    HSPC Krankenhausbehandlung

    INPC Autoversicherung

    INSM Ratenzahlung

    INSU Versicherung

    INTC Intra-Company bertrag

    INTE Zinsen

    INTX Einkommenssteuer

    LBRI Berufsversicherung

    LICF Lizenzkosten

    LIFI Lebensversicherung

    LOAN Kreditzahlung

    MDCS Medizinische Dienste

    NWCM Netzwerkkommunikation

    PAYR Lohn/Gehaltszahlung GVC Haben 153 (ab DF-2.7)

    PENS Pensions- und Renten-zahlung

    GVC Haben 153

    PHON Telefon

    PPTI Haus/Grundstcksversi-cherung

    RINP Dauerauftragsgutschrift GVC Haben 152 (Ab DF 2.7)

    RLWY Bahnverkehr

    SALA Lohn/Gehaltszahlung GVC Haben 153

    SAVG Sparerzahlung

    SCVE Dienstleistungen Allgemein

    SSBE Sozialleistungen GVC Haben 156

    STDY Bildung und Unterricht

    SUPP Lieferantenzahlung

    TAXS Steuerzahlung

    TELI Laut Telefonauftrag

    TRAD Handelsgeschft

    VATX Mehrwertsteuer

    WEBI Laut Auftrag im Internet

    WTER Wasser

  • 24

    10.3 Produktkategorie: Category Purpose

    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 Spezialflyer Credit Transfer Preferred entnehmen

    ... ... SALA ...

    GroupHeader

    PaymentInf Dateiebene

    Transaktion

    * Adresse nicht mglich bei Initiating Party

    10.4 Fnf Beteiligte in einer SEPA-Nachricht

    Beispiel SEPA-berweisung

    Auftraggeber und Empfnger bzw. Zahlungspflichtiger erscheinen in den verschiedenen Ebenen eines SEPA Auftrages bzw. einer Dateieinreichung. ber die Felder Ultimate kann zustzlich ein abweichender Auftraggeber und Zahlungsempfnger bzw. - pflichtiger mitgegeben werden.

    InitiatingParty (Einreicher)

    Debitor (Auftraggeber)

    Name (70 Stellen)

    Creditor (Empfnger)

    IBAN/BIC (Auftraggeber)

    IBAN/BIC (Empfnger)

    UltimateDebitor

    UltimateCreditor

    Adresse (2x 70 Stellen zzgl. Lndercode)*

    Pflichtangabe

    Optional

    Organisationsnummer

    Personenidentifikation

  • 25

    GroupHeader

    PaymentInf Dateiebene

    Transaktion

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

    Beispiel SEPA-Lastschrift

    InitiatingParty (Einreicher)

    Creditor (Auftraggeber)

    Name (70 Stellen)

    Debitor (Zahlungspflichtiger)

    Glubiger-ID (Creditor)

    IBAN/BIC (Zahlungspflichtiger)

    IBAN/BIC (Creditor)

    UltimateCreditor

    UltimateDebitor

    Adresse (2x 70 Stellen zzgl. Lndercode)*

    Pflichtangabe

    Optional

    Organisationsnummer**

    Personenidentifikation**

    10.5 Name, Adresse

    In der SEPA Nachricht gibt es fnf mgliche Beteiligte (Debitor, Creditor, InitiatingParty, Ultimate Creditor und Ultimate Debtor)

    Der jeweilige Name der Beteiligten wird immer mit bis zu 70 Stellen angegeben Optional knnen noch Adressen mitgegeben werden. Hierzu sind 2 mal 70 Stellen der

    unstrukturierten Adresse zu verwenden zuzglich dem Lndercode Der Auftraggebername und die -Adresse (bei grenzberschreitenden Zahlungen) mssen aufgrund der Auftrag-

    geberdatenverordnung korrekt mitgeliefert werden. Die HVB fllt diese automatisch mit den Kontostammdaten

    ABC Handels GmbH

    DE Dorfstrasse 14 Muenchen

  • 26

    10.6 IBAN

    International Bank Account Number IBAN ist das eindeutige Identifikationskriterium fr Zahlungsempfnger und Zahlungspflichtige. Die IBAN lst die nationale Kontonummer im SEPA-Zahlungsraum fr SEPA-Auftrge komplett ab.

    Der Aufbau ist definiert von ISO 13616-1:2007. Die IBAN beginnt mit zwei Buchstaben, dem Lnderkennzei-chen, 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/Kontoidentifikation. Diese Bank/Kontoiden-tifkation 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 Lnder-codes 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 hufig 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 Bankfilialen benutzen Kunden hufig noch ihre alte Bankleitzahl weiter, obwohl sie bereits in ihrem IBAN eine neue Bankleitzahl erhalten haben

    Deshalb sollte eine Konvertierung immer ber die kontofhrende Bank oder in Deutschland ber den BankVerlag stattfinden

    DE40700202700012345678

  • 27

    IBAN Beispiele fr andere Lnder

    sterreich (20 stellig): LLPPBBBBBKKKKKKKKKKKLL Lnderkennzeichen: AT BuchstabenPP Prfziffer 2 stellig numerisch BBB... sterreichische Bankleitzahl 5 stellig numerischKKK... Kontonummer 11 stellig numerisch

    Schweiz (21 stellig): LLPPBBBBBKKKKKKKKKKKKLL Lnderkennzeichen: CH BuchstabenPP Prfziffer 2 stellig numerischBBB... Schweizer Bankleitzahl 5 stellig numerischKKK... Kontonummer 12 stellig numerisch

    Italien (27 stellig): LLPPNBBBBBCCCCCKKKKKKKKKKKKLL Lnderkennzeichen: IT BuchstabenPP Prfziffer 2 stellig numerischN Control Internal Number (CIN) 1 stellig alphanumerischBBB... Associazione Bancaria Italiana (ABI) 5 stellig numerischCCC... Codice di Avviamento Bancario (CAB) 5 stellig numerischKKK... Kontonummer 12 stellig numerisch

    10.7 Glubigeridentifikation (Creditoridentification/CI)

    SEPA-Lastschrifteinreicher bentigen eine eindeutige Identifikationsnummer. Diese ist bei der Bundesbank pro Legal-Entity erhltlich www.glaeubiger-id.bundesbank.de Format: LLPPZZZ0NNNNNNNNNNLL LndercodePP 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 belegen0NN 11-stellige eindeutige Glubigeridentifikation mit fhrender Null

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

    DE12ZZZ01234567890 SEPA

  • 28

    10.8 Identifikationsnummern (OrgID/PrivateID)

    Optional kann zum Namen auch eine Identifikationsnummer mitgegeben werden. In Deutschland (DF- Anlage) wird empfohlen diese Felder nicht zu belegen, da auch eine 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 Identifikationsnummern. Neben der Identifikationsnummer knnen noch Daten, wie z.B. die ausstellende Behrde , mitgegeben werden. Es kann entweder eine Organisationsnummer oder eine Personennummer angegeben werden

    Organisations Identifikation OrgID>, z.B. Firmennummer (COID), Kundennummer (CUST), Steuernummer (TXID), Arbeitgebernummer (EMPL), BIC/BEI, DUNS u.a. Siehe www.iso20022.org/external_code_list.page im Reiter 9-OrganisationIdentification

    Personen Identifikation , 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)

    181/815/08155 TXID Finanzamt Muenchen IV

    RA 123445123

    CCPT Kreisverwaltungsreferat Muenchen

    1980-11-07 Bayern Muenchen DE

  • 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 Zahlungspflichtigen im Datensatz mitzugeben

    Der Abweichende Auftraggeber kann entweder auf Dateiebene (PaymentInf) oder auf Transaktionsebene mitgeschickt werden. Empfohlen wird hier die Verwendung auf Dateiebene

    Wenn 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. Zahlungspflichtigen

    Im MT940 erfolgt die Weitergabe der Ultimate-Informationen im Feld 86/Subfeld ?20-?29 oder wenn kein Platz im Subfeld ?60-?63:

    ABWA+[Abweichender berweisender (CT) bzw. Zahlungsempfnger (DD)] ABWE+[Abweichender Zahlungsempfnger (CT) bzw. Zahlungspflichtiger (DD)]

    berweisung Beispiel Kindergeld

    Lastschrift Beispiel Handyrechnung

    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.

    Firma AG

    Kindergeld-Abteilung

    Mutter Meier

    Kind Meier

    Mobilfunk AG

    Mutter Meier

    Kind Meier

  • 30

    On behalf Payments ber Payment FactoryWerden in einer Unternehmensgruppe ber eine Dachgesellschaft Zahlungen fr die verschiedenen Gesell-schaften 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 Lieferfirma Creditor ist Zahlungsabwicklungsfirma. Hierbei hat die kontofhrende Stelle zu beachten, dass die eingehenden

    Gelder auf ein Konto fr fremde Rechnung laufen mssen (Treuhandkonto fr Lieferfirma). Eine Haftungs-erklrung durch Zahlungsabwicklungsfirma fr Rcklastschriften ist notwendig

    Zahlungsabwicklungsfirma reicht die Lastschriften ein. Beim Einreicherkonto wird die Glubiger-Identifikations-nummer (CI) der Zahlungsabwicklungsfirma hinterlegt und bei Einreichungen geprft. Bei Gutschrift auf ein Zahlungsabwicklungsfirma-Konto muss also die CI von Zahlungsabwicklungsfirma hinterlegt werden. Ein Unternehmen kann nur mit einer CI Lastschriften einreichen, d.h. Zahlungsabwicklungsfirma kann nicht mit der CI von der Lieferfirma einreichen

    Was ist auf dem Mandat anzugeben: Creditor ist Zahlungsabwicklungsfirma, CI von Zahlungsabwicklungsfirma als Creditor Reference Party wird Lieferfirma und als deren CI als Creditor Reference ID angegeben

    Das Mandat mit Creditor Lieferfirma und CI Lieferfirma kann aufgrund der Koppelung der Kontonummer mit der CI nur fr die Gutschrift auf ein Lieferfirma Konto verwendet werden

    Lastschrift

    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 und der alten Mandatsnummer nderung des Creditor-Namen, z.B. aufgrund von Firmenfusionen. Hier wird zumeist auch eine neue

    Glubiger-Identifikationsnummer ntig Mitgabe der neuen Glubiger-Identifikationsnummer und der alten Glubiger-

    Identifikationsnummer sowie des neuen Creditor-Namens und des alten Creditor-Namens

    Zahlungsabwicklungsfirma

    Lieferfirma

    Meier

  • 31

    nderungen beim Zahlungspflichtigen nderung der Debitoren-Kontoverbindung Mitgabe der neuen IBAN und alten IBAN 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

    Kunde(Debitor)

    B2B- Mandatsauftrag bzw. Debtor-Profilingmit genderten Mandatsdaten

    schriftliche Mitteilung ber genderte IBAN/BIC Lieferant

    (Creditor)Pre-Notification mit genderten Mandatsdaten

    Debitor-Bank

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

    Lastschrift mit angehngtenMandatsnderungen (alt/neu) Besonderheit: Bei BIC-nderung als FIRST D-5

    Einreichung der nchsten* Lastschrift mit angehngtenMandatsnderungen

    Archivierung derMandatsnderung

    Prfung B2B-Lastschrift auf gltigen MandatsauftragPrfen auf Debtorprofiling (z.B. Sperren)

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

    1 2

    4 8

    7

    3

    6

    5Einzug der Lastschrift mit angehngtenMandatsnde-rungen (alt/neu)

    berblick des Prozesses bei Mandatsnderungen

    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 Zahlungspflichtigenbank nicht

    automatisch zu nderung der Weisungen. So mssen vom Zahlungspflichtigen hinterlegte SEPA-Firmenlast-schriftsmandate durch den Zahlungspflichtigen 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 Zahlungspflichtigen ber etwaige nderungen (z.B. ber eine hervorgehobene Prenotification) 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

    555544 2012-11-12 true 444444 Schrauben AG DE16HVB00000017432 SEPA DE84700202700654150818 SMNDA

    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 Der letzte Einzug erfolgte mit Sequenz FNAL-Final oder OOFF-OneOff (und wurde nicht rejected) Der Debitor hat gegenber dem Creditor sein Mandat widerrufen

    Kennzeichen neue Debtor-Bank

    alte Debtor-IBAN

    alte Glubiger-Identifikation

    alter Creditor-Name

    alte Mandatsnummer

    Kennzeichen Mandatsnderung wird mitgeliefert

    Aktuelle Mandatsnummer und Unterschriftsdatum

  • 33

    RCUR

    Cutoff auf Basis der Sequenz FRST First RCUR recurrent FNAL Final OOFF OneOff

    Basislastschrift (CORE)

    Regel Vorlage Debtorbank, Flligkeitstag Duedate x

    D 5 D 2 D 2 D 5

    Cutoff HVB D 6, 12 Uhr D 3, 12 Uhr D 3, 12 Uhr D 6, 12 Uhr

    Cutoff HVB Beispiel Fllig: Fr 31.1.2013

    Mi 23.1.2013, 12 Uhr

    Mo 28.1.2013, 12 Uhr

    Mo 28.1.2013, 12 Uhr

    Mi 23.1.2013, 12 Uhr

    Basislastschrift mit verkrzter Vorlauffrist (COR1)

    Regel Vorlage Debtorbank, Flligkeitstag Duedate x

    D 1 D 1 D 1 D 1

    Cutoff HVB D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr

    Cutoff HVB Beispiel Fllig: Fr 31.1.2013

    Di 29.1.2013, 12 Uhr

    Di 29.1.2013, 12 Uhr

    Di 29.1.2013, 12 Uhr

    Di 29.1.2013, 12 Uhr

    Firmenlastschrift (B2B)

    Regel Vorlage Debtorbank, Flligkeitstag Duedate x

    D 1 D 1 D 1 D 1

    Cutoff HVB D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr

    Cutoff HVB Beispiel Fllig: Fr 31.1.2013

    Di 29.1.2013, 12 Uhr

    Di 29.1.2013, 12 Uhr

    Di 29.1.2013, 12 Uhr

    Di 29.1.2013, 12 Uhr

    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 muss auf

    logischer Dateiebene sortenrein geliefert werden. Von der Sequenz aus werden auch die korrekten Vorlauftage zum Flligkeitstag in Abhngigkeit des Lastschriftproduktes Core/Cor1/B2B bei der Einreichung berprft.

    Arten der Lastschriftsequenzen Ersteinzug einer WIEDERKEHRENDEN Lastschrift FRST (First) Folgeeinzug einer WIEDERKEHRENDEN Lastschrift RCUR (Recurrent) Letzter Einzug einer WIEDERKEHRENDEN Lastschrift FNAL (Final) EINMALIGER Einzug OOFF (OneOff)

    Bitte beachten Sie ggf. abweichend vereinbarte Cutoffzeiten. Die aktuell gltigen Cutoffzeiten der HVB finden 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 Zahlungspflichtigenbank die

    Debitorbelastung auf den nchstmglichen Bankarbeitstag verschieben Fr die Prenotificationregel (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

    bersicht ber die Cutoff-Termine pro Lastschriftprodukt auf Basis der Sequenz mit Beispiel

  • 34

    Aktueller Einzug Rckgabe des aktuellen Einzugs FolgeeinzugFRST First Keine Rckgabe RCUR Recurrent*

    FRST First Vor Buchung (pain.002) FRST First

    FRST First Nach Buchung RCUR Recurrent*

    RCUR Recurrent Keine Rckgabe RCUR Recurrent*

    RCUR Recurrent Vor Buchung (pain.002) RCUR Recurrent*

    RCUR Recurrent Nach Buchung RCUR Recurrent*

    FNAL Final Keine Rckgabe Kein Folgeeinzug

    FNAL Final Vor Buchung (pain.002) FNAL - final

    FNAL Final Nach Buchung Neues Mandat ntig

    OOFF OneOff Keine Rckgabe Kein Folgeeinzug

    OOFF OneOff Vor Buchung (pain.002) OOFF OneOff

    OOFF OneOff Nach Buchung Neues Mandat ntig

    Mandatsnderung neue Debtorbank SMNDA mit FRST First (Pflicht)

    Keine Rckgabe RCUR Recurrent*

    Mandatsnderung neue Debtorbank SMNDA mit FRST First (Pflicht)

    Vor Buchung (pain.002) FRST First & Mandatsnderung SMNDA wiederholen

    Mandatsnderung neue Debtorbank SMNDA mit FRST First (Pflicht)

    Nach Buchung RCUR Recurrent* (Mandatsnderung nicht wiederholen)

    Mandatsnderung gleiche Debtorbank mit RCUR Recurrent

    Keine Rckgabe RCUR Recurrent* (Mandatsnderung nicht wiederholen)

    Mandatsnderung gleiche Debtorbank mit RCUR Recurrent

    Vor Buchung (pain.002) RCUR Recurrent* & Mandatsnderung wiederholen

    Mandatsnderung gleiche Debtorbank mit RCUR Recurrent

    Nach Buchung RCUR Recurrent* (Mandatsnderung nicht wiederholen)

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

    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. finalen Lastschrift als abgelaufen

    Erfolgt eine Mandatsnderung auf eine neue Zahlungspflichtigenbank SMNDA-SameMandateNewDebitor-Agent muss die Lastschriftsequenz als erstmalig FRST gekennzeichnet werden

    Erfolgt eine Mandatsnderung auf die gleiche Zahlungspflichtigenbank (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?

  • 35

    10.12 Zeichensatz und Umlaute

    In SEPA kann ein umfangreicher Zeichensatz verwendet werden (UTF-8) mit vielen lnderspezifischen 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 definierte Zeichensatz ist mglich in allen Namens-, Adress- und Verwendungszweckfeldern.Besondere Felder und Zeichenrestriktionen Referenznummern

    Message-ID , Private-ID und strukturierte Creditorreferenz Numerische Zeichen 0 bis 9 Buchstaben A bis Z und a bis z Sonderzeichen : ? , - ( + . )/aber ohne Leerzeichen Mandatsreferenz

    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 Keine Leerzeichen und nur eingeschrnkt Sonderzeichen verwenden Keine fhrenden Nullen verwenden Verwechslungsgefahr 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

    Hufige 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.

    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 ODER unstrukturiert angegeben werden. Beide knnen nicht gleichzeitig verwendet werden

    Organisational-ID versus Private-ID . Hier ist nur eine der beiden Elementengruppen erlaubt Bei Nutzung von der Private-ID kann auch nur entweder eine Identifikationsnummer mit Issuer

    und Identifikationsart und ODER ein Geburtstag mit Geburtsort verwendet werden

    Paymentinfo-Ebene Transaktions-Ebene entweder oder/PflichtfeldCreditorIdentification(nur SDD)

    Empfohlen Alternativ Pflicht bei SDD

    CategoryPurpose Empfohlen (ntig fr HVB Produkt SEPA Gehaltszahlung)

    Alternativ Optional

    ChargeBearer Empfohlen Alternativ Pflicht SLEV

    Ultimate-Debtor (SCT)Ultimate Creditor (SDD)

    Variante 1 (ntig fr HVB Produkt SEPA Ultimate Auftraggeber)

    Variante 2 Optional

    ServiceLevel-Code Pflicht Nicht erlaubt auf Transaktionsebene bei DK Pflicht (SEPA, URGP)

    InstructionPriority Optional Nicht erlaubt auf Transaktionsebene bei DK Optional

    LocalInstrument-Code (nur SDD) Pflicht Nicht erlaubt auf Transaktionsebene bei DK Pflicht bei SDD (B2B, CORE, COR1)

  • 37

    10.14 SEPA-Referenznummern und deren Verwendung

    Welche Referenznummern gibt es in SEPA und wo werden die vergeben?

    SEPA-Feld Beschreibung Datei/Transaktions- Ebene

    Verwendung Einreichung

    MessageIdentification () Eindeutige technische Referenz der Datei des Datei-erstellers

    GroupHeader SCT, SDD

    DTI Dateinummer HVB-Sammlerreferenz

    Original MessageIdentification ()

    Ursprngliche Message ID bei Datei-Reject GroupHeader

    PaymentInformationIdentification ()

    Referenz der logischen Datei (Sammlerreferenz) Payment-Information SCT, SDD

    Original PaymentInformationIdentification ()

    Ursprngliche Referenz der logischen Datei bei Datei-Reject

    Payment-Information -

    Dateinummer HVB Eindeutige Dateinummer von HVB vergeben Payment-Information -

    Transaktionsreferenz HVB Eindeutige HVB-Referenz der einzelnen Transaktion Transaktion SCT, SDD

    CreditorIdentification (Creditor Identifier, )

    Eindeutige GlubigerIdentification (von Bundesbank)

    Payment-Information oder Transaktion

    SDD

    Original CreditorIdentification ()

    Nur bei Mandatsnderung die ursprngliche CreditorIdentification

    Transaktion SDD

    InstructionIdentification () Technische Point-to-Point-Referenz Transaktions-referenz, wird nicht weitergegeben

    Transaktion SCT, SDD

    Original InstructionIdentification Ursprngliche Point-to-Point-Referenz bei Datei-Reject Transaktion -

    End-to-End Identification () Fachliche Auftraggeberreferenz wird an Empfnger weitergeleitet

    Transaktion SCT, SDD

    Original End to End ID Ursprngliche Auftraggeberreferenz bei Datei-Reject Transaktion -

    TransactionIdentification () Eindeutige Transaktionsnummer vom erstbeteiligten Institut vergeben

    Transaktion -

    Creditor Reference (CreditorReferenceInformation, )

    Strukturierte Referenznummer im strukturierten Verwendungszweck

    Transaktion SCT, SDD

    MandateIdentification (Mandate Reference, )

    Eindeutige Mandatsreferenz (bezogen auf GlubigerIdentification)

    Transaktion SDD

    Original MandateIdentification Nur bei Mandatsnderung die ursprngliche Mandats-referenz

    Transaktion SDD

    OrganisationIdentification () Identifikationsnummer einer Organisation (BIC, BEI, Steuernummer, Kundennummer, etc.; siehe ISO20022 External Code List)

    Payment-Information oder Transaktion

    *

    PersonIdentification () Identifikationsnummer einer natrlichen Person (Geburtsdatum/Ort, Sozialversicherungsnummer, Pass-nummer, Steuernummer, Kundennummer, etc.; siehe ISO External Code List)

    Payment-Information oder Transaktion

    *

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

  • 38

    SEPA-Feld Reporting pain.002 Reporting MT940/942 Reporting camt.052/camt.053MessageIdentification () pain.002 - -

    DTI Dateinummer -

    Original MessageIdentification ()

    pain.002 - -

    PaymentInformationIdentification ()

    Wenn lnger als 16 Chars : :86: mit Identifier KREF+Wenn krzer: :61/7:

    (only initiator entry)

    Original PaymentInformationIdentification ()

    pain.002 - -

    Dateinummer HVB - :61/9: -

    Transaktionsreferenz HVB - :61/8: bzw.

    CreditorIdentification (Creditor Identifier, )

    - :86: mit Identifier CRED+

    Original CreditorIdentification ()

    - - -

    InstructionIdentification () - - -

    Original InstructionIdentification pain.002 - -

    End-to-End Identification () - :86: mit Identifier EREF+

    Original End to End ID pain.002 - -

    TransactionIdentification () - -

    Creditor Reference (CreditorReferenceInformation, )

    pain.002 Teil des strukturierten Verwendungszwecks (allerdings ohne Tags)

    Teil des strukturierten Verwendungszwecks

    MandateIdentification (Mandate Reference, )

    pain.002 :86: mit Identifier MREF+

  • 39

    End-To-End Referenz Die 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

    Mandatsnummer/Mandatsreferenz Die Mandatsnummer ist in Zusammenhang mit der Glubiger-Identifikationsnummer (CI) europaweit eindeutig Die bis zu 35 stellige Mandatsnummer ist vom Einreicher (Creditor) bei SEPA-Lastschriften eindeutig zu

    vergeben Die Mandatsnummer dient dem Zahlungspflichtigen zur Abstimmung sowie 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 Zahlungspflichtigen weitergeleitet im Prenotification (empfohlen) Pflichtfeld in der SEPA-Lastschrift 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)

    12345678901234567890123456789012345

    555544

  • 40

    11. Reporting bersicht11.1 Reporting (Bank-Kunde)

    Welches Bank-Kunde Format ist fr welchen Zweck? In der folgenden Tabelle finden Sie eine bersicht der mglichen Varianten von elektronischen Kontoinformationen rund um Kontoauszge, Avise, Buchungssammler und Fehlerinformationen.

    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 adminis-triert 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 SEPA- Datei knnen Sie individuell pro Datei einstellen ob die Buchung als Sammel- oder Einzelbuchung erfolgen soll (Kennzeichen BatchBooking):

    Empfohlen fr Optionen Einschrnkung/ zu Beachten

    Format Erstellungs Zeitpunkt

    MT940 Elektronischer Kontoauszug Altsysteme

    Nicht alle SEPA Felder werden durchgereicht

    MT940 Tagesende Buchungstag

    MT942 ZV-Avis Altsysteme

    Nicht alle SEPA Felder werden durchgereicht

    MT942 stndlich Buchungstag

    DTI Elektronische Weiterverar-beitung von Eingngen und Retourenverarbeitung Altsysteme

    Nicht alle SEPA Felder werden durchgereicht.Nicht fr Lastschriftretouren vor Buchung

    DTAUS0DTAUS1

    stndlich Buchungstag

    camt.053 Elektronischer Kontoauszug Neu

    camt.053.001.02 Tagesende Buchungstag

    camt.052 Elektronisches ZV-Avis Neu

    camt.052.001.02 stndlich Buchungstag

    camt.054 Elektronische Weiterverar-beitung von Eingngen und Retourenverarbeitung Neu

    Elektronische Informati-on ber die eingereichte SEPA Datei

    ab Juni 2013 optional auch: Lastschriftretouren vor Buchung

    Nicht fr Lastschriftretouren vor Buchung (bis Juni 2013)

    camt.054.001.02 stndlich Buchungstag

    camt.086 elektronisches Preis-reporting camt.086.001.01 Monatlich oder quartals-mig je nach Wunsch des Kunden

    pain.002 SEPA-Fehlernachrichtenvor Buchung fr das SEPA-Mandats-Management

    Optional seit Nov 2012: auch SEPA Fehlernachrich-ten nach Buchung

    Keine Lastschrift-Retouren-gebhrenausweisung

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

    Sofort bei Fehlerfest-stellung

    true

  • 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 Lastschriftein-reichungen 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

    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 effizient abgewickeltDie 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.

    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 Zahlungspflichtiger-Bank bereits vor Flligkeit Prfung durch Zahlungspflichtiger-Bank vor Flligkeit (z.B. Konto aufgelst) Rckmeldung von Fehlern an Einreicher bereits vor Flligkeit bzw. vor Buchung Ergnzt Information im Kontoauszug (camt.053), da dieser erst nach Buchung vorliegt

    Creditor Creditorbank Debtorbank Debtor

    Beispiel SEPA-Lastschrift

    pain.002 pacs Reject

    Auftraggeber initiiert

    Auftraggeber-Bank initiiert

    Zahlungspflichtiger-Bank initiiert

    Zahlungspflichtiger inittiiert

    camt.053 (Kontoauszug)

    camt.054 (Sammlerdetails)

    Auftraggeber

    Auftraggeber

    Auftraggeber

    Bank Empfnger

  • 43

    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-Folgeein-reichungen die richtige Sequenz gewhlt werden muss.Wie kann der Einreicher jetzt die richtige R-Nachricht identifizieren? Anhand der Rckgabegrnde lsst sich keine eindeutige Zuordnung treffen.

    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) wenn die Option pain.002 genutzt wird, ist folgendes zu beachten Die Unterscheidung der pain.002 Nachricht vor und nach Buchung lsst sich derzeit nur anhand der Referenz-

    nummer bei der HVB durchfhren. Die pain.002-Vor-Buchung hat in der 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

    Vor Buchung Nach BuchungBuchung Storno Retoure

    pain.002 ja optional

    Auftraggeber initiierte R-Nachrichten: Vor Buchung Rckruf (Revocation/Recall)

    z.B. Besttigung der Revocation

    Einreicher Bank initiierte R-Nachrichten: Vor Buchung Zahlungspflichtiger-Bank fr Lastschriften nicht SEPA-ready Pflichtfelder fehlen IBAN Check fehlerhaft

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

    Zahlungspflichtiger initiierte R-Nachrichten: Vor Buchung Mandatssperre durch Zahlungspflichtiger Komplette Lastschriftssperre Widerspruch bereits vor Buchung

  • 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 ISO-Code

    Name German Translation Returncode in MT940/DTI Textschlssel-Ergnzung

    Returncode in pain.002

    AC01 Incorrect Account Number IBAN fehlerhaft 901 AC01

    AC04 Closed Account Number Konto aufgelst 902 AC04

    AC06 Blocked AccountKonto gesperrt (auch bei unwiderruflicher Lastschriftsperre) 903 AC06

    AC13 InvalidDebtorAccountTypeDer Zahlungspflichtige ist ein Verbraucher (relevant bei SEPA-Firmenlastschrift) 930 AC13

    AG01 Transaction Forbidden Zahlungsart fr Konto unzulssig 904/914** AG01/MS03**

    AG02 Invalid Bank Operation CodeTransaktionscode ungltig (auch falsche Lastschriftsequenz) 905 AG02

    AM01 Zero Amount Betrag ist Null 911* AM01

    AM02 Not Allowed Amount Betrag ist unzulssig 911*/914** AM02/MS03**

    AM03 NotAllowedCurrency Whrung ist unzulssig 911*/914** AM03/MS03**

    AM04 Insufficient Funds Rckgabe mangels Deckung 906/914** AM04/MS03**

    AM05 Duplication Doppeleinreichung 907 AM05

    AM06 TooLowAmount Betrag zu niedrig 911*/914** AM06/MS03**

    AM07 BlockedAmount Betrag gesperrt 911*/914** AM07/MS03**

    AM09 WrongAmount Betrag nicht korrekt 911*/914** AM09/MS03**

    AM10 InvalidControlSum Summe Einzelbetrge ungleich Prfsumme 911* AM10

    ARDTAlready returned transaction (Recall-Answer) Bereits zurckgegeben (Antwort auf SCT-Recall) 905* AG02

    BE01 InconsistenWithEndCustomerKennung des Endkunden passt nicht zu der entsprechenden Kontonummer 911*/914** BE01/MS03**

    BE04 Account address invalid Adressangaben unvollstndig 908/914** BE04/MS03**

    BE05UnrecognisedInitiatingParty Identifier fo the Creditor incorrect

    Absender unbekannt/ CI incorrect 911* BE05

    BE06 UnknownEndCustomer Auftraggeber/Zahlungsempfnger unbekannt 911* BE06

    BE07 MissingDebtorAddressAdresse des Zahlers (Zahlungspflichtigen) fehlt oder unvollstndig 914/914** BE07/MS03**

    DT01 Invalid DateUngltiges Datum (z. B. falsches Abrechnungsdatum) 916* DT01

    ED05 Settlement Failed Die Begleichung der Transaktion ist fehlgeschlagen 914 ED05

    FF01 reject due to an invalid file format Dateiformat ungltig 911 FF01

  • 45

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

    * Meist keine Buchung deshalb kein MT940, sondern nur fr pain.002 interessant** Datenschutz Einschrnkung Abkommen ber SEPA-Inlandslastschrift; bei aktiven SDD-Retouren Datenschutz auf Debtorbank-

    Seite innerhalb Deutschlands zu beachten, deshalb anonymisiert 914 bzw MS03

    Return-Reason ISO-Code

    Name German Translation Returncode in MT940/DTI Textschlssel-Ergnzung

    Returncode in pain.002

    FF05 DirectDebitTypeIncorrectFalsche Lastschriftart (COR1 trotz fehlender COR1-Vereinbarung verwendet) 931 FF05

    FOCRpositive request for cancellation recall Rckgabe aufgrund eines Recalls (Rckrufes) 919 FOCR

    LEGLLegal Decision (Recall-Answer)

    Rechtliche Entscheidung (Antwort auf SCT-Recall) 917*/914** MS03

    MD01 No Mandate

    Kein gltiges Mandat (Rckgabe einer nicht autorisierten Lastschrift bis 13 Monate. Weiterverwendung des Mandates nicht erlaubt) 909 MD01

    MD02Missing Mandatory Information Mandate

    Die Daten zum Mandat fehlen oder sind nicht korrekt 910 MD02

    MD03 Invalid File format Ungltiges Dateiformat 911 FF01

    MD05 CollectionNotDue Kein flliger Einzug 916/914** DT01/MS03**

    MD06 Refund Request By End Customer

    Widerspruch durch den Zahler (Zahlungspflichtigen, Rckgabe bis zu 8 Wochen ohne Angaben von Grnden) 912 MD06

    MD07 End Customer Deceased Kontoinhaber verstorben 913/914** MD07/MS03

    MS02Not Specified Reason Customer Generated

    Rckgabe durch den Zahler (Zahlungspflichtigen) vor Flligkeit (Refusal) 914 MS02

    MS03Not Specified Reason Agent Generated Grund nicht spezifiziert 914 MS03

    NARR Narrative Sonstige Grnde 914 MS03

    NOASNo Answer from Customer (Antwort auf SCT-Recall)

    Keine Anwort von Kunde (Antwort auf SCT-Recall) 911*/914** MS03

    NOORNo Original Transaction Received

    Original-SCT nicht erhalten (Antwort auf SCT-Recall) 911* RF01

    PY01 Unknown BIC BIC unbekannt 915 RC01

    RC01 Bank Identifier Incorrect BIC ungltig 915 RC01

    RF01 NotUniqueTransactionReferenceTransaktionsreferenz innerhalb der Nachricht nicht eindeutig 907 RF01

    RR01Not Specified Reason Customer Generated

    Aufsichtsrechtliche Grnde, fehlendes Konto/ fehlende ID des Zahlers 917/914** RR01/MS03**

    RR02 Missing Debtor Name or Address Aufsichtsrechtliche Grnde, fehlender Name/fehlende Adresse des Zahlers 917/914** RR02/MS03**

    RR03 Missing Creditor Name or AddressAufsichtsrechtliche Grnde, fehlender Name/fehlende Adresse des Zahlungsempfngers 917/914** RR03/MS03**

    RR04 Regulatory Reason Aufsichtsrechtliche Grnde 917/914** RR04/MS03**

    SL01Specific Service offered by Debtor Bank

    Spezifische Dienstleistung der Bank des Zahlers (auch aufgrund von Positiv-Negativlisten Wei-sung des Zahlungspflichtigen) 918 SL01

    TM01 File received after Cut-off Time CutOff-Zeit berschritten 916 TM01

    Fortsetzung

  • 46

    Wichtige fachliche XML Felder fr pain.002-SEPA Credit TransferFeldnamen Beschreibung

    pain.002.002.03Befllung DF Abkommen 2.5/2.6

    GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei

    MsgId Bankreferenznummer pro Datei Pflichtfeld max. 35 Zeichen

    CreDtTm Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date

    DbtrAgt Kreditinstitut BIC Pflichtfeld nur SCT 8 bzw. 11 Stellen

    OrgnlMsgId Ursprngliche Referenznummer der Kunden-einreichung

    Originaldaten

    OrgnlMsgNmId Ursprngliche XML-Dateityp Originaldaten pain.001

    OrgnlNbOfTxs Ursprngliche Anzahl aller Einzel- transaktionen

    Originaldaten

    OrgnlCtrlSum Ursprngliche Kontrollsumme in Euro der Einreichung

    Originaldaten

    GrpSts Status auf Dateiebene Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein

    RJCT-Reject

    StsRsnInf-Orgtr-Nm Initiator Rckgabe Kunde Nur zusammen mit GrpSts. Wenn Orgtr-BICOrBEI gefllt nicht erlaubt

    Name (max. 70 Zeichen) = Kundeninitiert

    StsRsnInf-Orgtr-Id-OrgId-BICOrBEI

    Initiator Rckgabe Bank Nur zusammen mit GrpSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt


Recommended