Anlage zur SEPA- Kundeninformation. Technische Spezifikationen und Formate

Transkript

1 Anlage zur SEPA- Kundeninformation Technische Spezifikationen und Formate Aktualisierte Auflage Stand: 02/2014 mit den Neuerungen ab

2 Anzeige Sie haben den Anschluss an SEPA immer noch nicht gefunden? JETZT UMSTELLEN! Trotz Übergangsfrist: Wir helfen Ihnen den passenden Anschluss jetzt herzustellen. In vielen Fällen genügt bereits eine leistungsfähige ebanking-software mit automatischer Konvertierungsfunktion. Welche Lösung für Ihr Unternehmen passt und wie wir Sie bei der Umstellung unterstützen, erfahren Sie unter

3 Inhalt 1. Dateiformate und SEPA-Verfahren der aktuelle Stand in Deutschland 5 2. Zusammenhang der Kunden- und Bankformate (ISO 20022) 6 3. SEPA-Kundenformate 6 4. Änderungen für November Nachrichtentypen-Erkennung Aufbau der Kundendatei (XML) SEPA Credit Transfer (SCT) Beispiel einer Kundendatei SEPA Direct Debit (SDD) SEPA häufig genutzte Zahlungsinformationen im Format Verwendungszweck/RemittanceInfo Zahlungsgrund/Purpose Code Produktkategorie/Category Purpose Fünf Beteiligte in einer SEPA-Nachricht Name, Adresse IBAN, IBAN-Only Gläubiger-Identifikation/CI Identifikationsnummern (OrgID/PrivateID) Ultimate/Reference Party/On Behalf Mandatsänderung/ Mandate-Amendment Lastschriftsequenz Zeichensatz und Umlaute Konkurrierende Felder XOR SEPA-Referenznummern und deren Verwendung Reporting-Übersicht Reporting (Bank Kunde) Buchung von SEPA-Dateien Status/Fehlernachricht pain Rückgabegründe Payment Status Report/ pain. 002-SEPA Credit Transfer Payment Status Report/ pain.002-sepa Direct Debit Elektronischer Kontoauszug MT Internationale SEPA-Formate Taggleiche Eilüberweisungen in Euro via pain Um Ihnen einen raschen Überblick über die Änderungen gegenüber der Vorauflage anzuzeigen, finden Sie am Rand des Textes eine Kennzeichnung.

4 Für die Umstellung auf SEPA müssen Datenfelder in Ihren Systemen entsprechend angepasst werden. In der vorliegenden Broschüre erhalten Sie wesentliche Details zu den technischen Spezifikationen und verschiedenen SEPA-Formaten. Bei den nachfolgenden Informationen handelt es sich um eine Empfehlung. Grundlage hierfür ist das DFÜ-Abkommen. Auf den nächsten Seiten dieser Broschüre finden Sie eine Zusammenfassung der wichtigsten fachlichen Felder, die zur Umstellung auf SEPA erforderlich sind. Weitere Details oder Angaben zu technischen Feldern entnehmen Sie dem nachfolgenden Link: Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und Kreditinstitut gemäß DFÜ-Abkommen Version 2.7 vom , gültig ab 4. November Weitere Informationen zur finalen Beschreibung der Formate erhalten Sie bei folgenden Stellen: Deutsche Kreditwirtschaft (DK) Anlagen zum Kapitel 2, SEPA-Zahlungsverkehr der Version 2.7 der Anlage 3 XML-Schemata für SEPA: 4

5 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: für XML. XML ist ein offener Standard. Keine feste Vorgabe von Feldbelegungen Größer als die bekannten DTA-Formate (z. B. DTAUS und DTAZV) Zeichensatz ist UTF-8, festgelegt im XML-Header <?xml version= 1.0 encoding= UTF-8?>. Implementation Guidelines (Interbankenverkehr) wurden vom European Payments Council (EPC) im September 2006 verabschiedet und werden jährlich weiterentwickelt. ISO als XML-basiertes Format bildet die Grundlage für den modernen globalen Zahlungsverkehr und bietet eine sehr große Bandbreite und dadurch eine entsprechende Variabilität an. SEPA macht den Anfang einer durchgängigen ISO Verarbeitung im Zahlungsverkehrsprozess hinsichtlich aller SEPA-Produkte. Im SEPA-Umfeld basiert bereits die komplette Prozesskette bis hin zum Auszug auf XML-ISO <CdtTrfTxInf> <PmtId> <EndToEndId>OriginatorID1234</EndToEndId> </PmtId> <Amt> <InstdAmt Ccy= EUR > </InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>SPUEDE2UXXX</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Creditor Name</Nm> </Cdtr> <CdtrAcct> <Id> <IBAN>DE </IBAN> Für die Kunde-Bank-Beziehung wurde das pain-format (Payment Initiation) festgelegt. 5

6 2. Zusammenhang der Kunden- und Bankformate (ISO 20022) Kunden reichen bei Banken das pain-format für Zahlungsdateien ein. Im Interbankenverhältnis werden die Zahlungen dann zwischen den Banken mit dem pacs-format ausgetauscht. Der Kunde erhält dann über die Buchungen als Kontoinformation das camt-format optional zur Verfügung gestellt. Fehler/Rejects können optional an den Kunden auch im pain-format als Datei von der Bank zur Verfügung gestellt werden. Zahlungsauftrag Fehlerinformation Kunde Bank pain pacs pain = Payment initiation Zahlungsverkehrsinitiierung für Überweisungen (pain.001) Lastschriften (pain.008) pacs = Payment clearing & settlement Clearing für Überweisungen (pacs.008) Lastschriften (pacs.003) pain pacs pain = Payment initiation Fehlernachrichten Fehlermeldung/Status-Message (pain.002) pacs = C&S Fehlernachrichten Fehlermeldung/Status-Message Kunde camt camt = cash management Konto-Informationen Avis (camt.052) Auszug (camt.053) DTI (camt.054) Kundeninformation 3. SEPA-Kundenformate Format-Evolution Was ändert sich bei den SEPA-Auftragsdaten? Januar 2008 (DFÜ Anlage 3 Version 2.2) Start SEPA-Überweisung (Credit Transfer) Formatversionen: pain , pain ct November 2008 (DFÜ Anlage 3 Version 2.3) Keine inhaltlichen Formatänderungen, aber Berücksichtigung von Gruppierung und Containern: pain , pain grp, pain con, pain ct, pain ct.con 6

7 November 2009 (DFÜ Anlage 3 Version 2.4) Start SEPA-Basislastschrift (Direct Debit Core) und SEPA-Firmenlastschrift (Direct Debit B2B) Formatversionen: pain , pain , pain Grouping Standard vereinheitlicht nur noch MIXED analog European-Payments-Council (EPC)-Vorgaben Optional: Zahlungsgründe standardisiert (über 100 Purpose-Codes), z. B. Gehalt, vermögenswirksame Leistungen, öffentliche Kassen Optional: zusätzliche Namensfelder für Dritt-Beteiligte: Ultimative Creditor/Debtor Optional: Definition der Formate für XML-Auszug (camt.052, camt.053, camt.054) November 2010 (DFÜ Anlage 3 Version 2.5) Formatversionen: pain , pain , pain Summenfelder (Betrag, Posten und Referenz) auf Sammler-Ebene (PaymentInfo) Restrukturierung der Reject pain.002-nachricht auf Kundenbedürfnisse Strukturierte Rückmeldung im MT940/MT942/DTI von Retouren-Gebühren Rückgabegrund FOCR aufgrund SCT-Rückruf nach Buchung (Recall) Optional: Zahlungsgrund Spende (PurposeCode = CHAR) Optional: prüfzifferngerechte CreditorReferenz auf Überweisungsbelegen November 2011 Keine Formatänderungen November 2012 (DFÜ Anlage 3 Version 2.6) Keine Formatänderungen Rückgabegrund AC13, wenn Zahlungspflichtiger ein Verbraucher ist, und FF05, wenn Lastschrift mit verkürzter Vorlauffrist COR1 nicht möglich ist November 2013 (DFÜ Anlage 3 Version 2.7) Formatversionen: pain , pain , pain Verkürzte Vorlauffrist COR1 IBAN-Only Eilüberweisung als pain.001 mit Servicel-Level URGP November 2014 (DFÜ-Anlage 3 Version 2.8, derzeitiger Diskussionsstand) Keine Formatänderungen Anpassungen in den Kontoauszugsformaten, weitere Details siehe Kapitel 4 Integration von SCC (SEPA Cards Clearing) Optionale Ergänzung beim Dateinamen von XML-Dateien in ZIP-Containern Hinweis: Jedes Jahr im November tritt ein neues Rulebook, das die Grundlage für die fortschreitenden Anpassungen an die aktuellen Bedürfnisse bildet, in Kraft. Für Sie bedeuten diese jährlichen Rulebook-Änderungen, dass Sie gegebenenfalls auch Anpassungen in den Formaten vornehmen müssen. Die Deutsche Kreditwirtschaft hat vereinbart, dass grundsätzlich immer die aktuelle Formatversion und die Vorgängerversion angenommen werden sollen. Die HVB nimmt darüber hinaus auch noch ältere Versionen an. Für Nutzung neuer Funktionalitäten müssen allerdings auch die entsprechenden Formate verwendet werden. 7

8 4. Änderungen für November 2014 Zum 17. November 2014 wird eine neue DFÜ-Anlage 3, Version 2.8, eingeführt, welche nach derzeitigem Diskussionsstand folgende Änderungen enthalten wird (Veröffentlichung im Mai 2014 unter Einreichung von SEPA-Überweisungen und SEPA-Lastschriften nur Klarstellungen zum Zeichensatz die Schema pain und pain bleiben aktuell Anpassungen im Reporting des elektronischen XML Auszuges (camt-formate) camt.052, Electronic Sequence Number nun optional statt mandatorisch camt.052, Salden-Angabe auch wenn Umsätzen ohne Status BOOK enthalten sind camt.052/054: Optionale Nutzung der Additional Information im Group Header zur Angaben zu den verschiedenen Anwendungsfällen, z.b. ob ein bestimmter Filter gesetzt wurde camt.05x, Einheitliche Belegungsregeln für Additional Entry/Transaction Information camt.05x, Elementgruppe Return Information, optionales Feld Additional Information nun mit Belegungsvorschrift zu RETURN, REJECT oder REFUND bei Rücklastschriften Anpassungen im Reporting generell Bei Rücklastschriften die Empfehlung bei MT940 im Feld 86 hinter dem Bezeichner SVWZ+ angeben, ob REJECT Rückweisung vor Settlement oder für Rückgabe nach Settlement RETURN/REFUND bzw. RUECK- LASTSCHRIFT Neuer GVC für ELV-Kartenbelastungen mit PurposeCode CGDD (GVC 107 SEPA Direct Debit Einzelbuchung-Soll, mittels Karte am Point of Sale generierte Lastschrift) SEPA Cards Clearing für den Start im April 2015 neue Schemas für die Einreichung von garantierten Kartenzahlungen (z. B. POS-Netzbetreiber) im Format pain mit LocalInstrumentCode CARD und Reversal pain Neue GVC s für SEPA Cards Clearing (106 SCC Kartenbelastung, 110 SCC Rückbelastung, 182 SCC Wiedergutschrift, 190 SCC Belastungsammler, 198 SCC Gutschriftssammler, 199 SCC Reversal) Neue Rückgabegründe für das SEPA Cards Clearing (SVNR Ware nicht ausgegeben und EMVL EMV Haftungsumkehr) Rückgabegrund BE06 bekommt Textschlüsselergänzung 929 und AM09 bekommt Textschlüsselergänzung 935 Neue PurposeCodes für garantierte Karten-Zahlungen (IDCP/CDDP-Kartenzahlung, CDCB/CDCD/CDCS Auszahlung, MTUP Laden Mobilfunk, ETUP/CBLK/FCOL Geldkarte) 8

9 Anzeige Ohne SEPA-Umstellung fließt bei Ihnen vielleicht kein Geld mehr. SEPA CHECK SEPA-Check machen! HVB Jetzt Deshalb jetzt mit den HVB Spezialisten auf SEPA umstellen und zahlungsfähig bleiben. Der HVB SEPA-Check unterstützt Sie dabei: unter

10 5. Nachrichtentypen-Erkennung Wie erkennen Sie, um welche Nachricht und welche Version es sich handelt? Aufbau einer XML-Nachrichtenbezeichnung: pain Version V3 ISO-Stand 2009 Variante Die Deutsche Kreditwirtschaft Nachricht/Message-Definition CustomerCreditTransferInitiation Geschäftsfeld/Business-Area Payment Initiation pain Business-Area pain PAymentINnitiation Message-Definition 001 Überweisung CustomerCreditTransferInitiation 008 Lastschrift DirectDebitInitiation 002 CustomerPaymentStatusReport (Reject) 007 CustomerPaymentReversal (Lastschriftsstorno) 009 bis 012 Mandatsinitiierung, -änderung, -storno und -akzeptanz Variante 003 ZKA/DK Version ZKA/DK Version IS /EPC Version 05 ISO Version 05/ ISO Version 04/ ISO Version 03/ ISO Version 09/ ISO Version 09/2005 camt CAshMAnagement 052 BanktoCustomerAccountReport ZV-Avis MT942-Nachfolger 053 BanktoCustomerStatement Kontoauszug MT940-Nachfolger 054 BanktoCustomerDebitCreditNotification Sammler DTI-Nachfolger 055 CustomerPaymentCancellationRequest Kunden-Rückruf 086 Bank Service Billing (ehem. TWIST-BSB) in Planung in Planung in Planung 10

11 Beauftragung einer SEPA Credit Transfer Kundenformat Folgende Auftragsarten sind über die Übertragungswege (EBICS/HBCI bzw. FinTS) möglich: SEPA-Auftragsarten Credit Transfer DK-Format Namespace/Schema SCT 2.7 (2013) EBICS-mixed urn:iso:std:iso:20022:tech:xsd:pain CCT pain EBICS-mixed Sonderprozess ohne VEU-Details urn:iso:std:iso:20022:tech:xsd:pain XCT pain EBICS- XML-Container urn:conxml:xsd:container.nnn (+urn:iso:std:iso:20022:tech:xsd:pain ) CCC pain EBICS-Reject urn:iso:std:iso:20022:tech:xsd:pain CRZ (Zip-Datei) oder CRC (XML-Container) pain HBCI-Sammel HKCCM, HKCME HBCI-Einzel HKCCS, HKCSE Ältere Versionen des DFÜ-Abkommens werden von der HVB weiterhin akzeptiert: DFÜ-Abkommen 2.5/2.6 (2010/2012): pain DFÜ-Abkommen 2.4 (2009): pain DFÜ-Abkommen 2.3 (2008): pain grp, pain con und pain bzw. geliefert nach entsprechender Einlieferung: DFÜ-Abkommen 2.5/2.6 (2010/2012): pain DFÜ-Abkommen 2.4 (2009): pain DFÜ-Abkommen 2.3 (2008): pain Beauftragung einer SEPA Direct Debit Kundenformat Folgende Auftragsarten sind über die Übertragungswege (EBICS/HBCI bzw. FinTS) möglich: SEPA-Auftragsarten Direct Debit EBICS-mixed EBICS-XML-Container EBICS-Reject Namespace/Schema urn:iso:std:iso:20022:tech:xsd: pain uurn:conxml:xsd:container.nnn (+urn:iso:std:iso:20022:tech:xsd: pain ) urn:iso:std:iso:20022:tech:xsd: pain SDD CORE/COR1 2.7 (2013) CDD/CD1 pain CDC/C1C pain CDZ (Zip-Container) oder CBC (XML-Container) pain SDD B2B 2.7 (2013) HBCI-Sammel HKDME HKBME CDB pain C2C pain CDZ (Zip-Datei) oder CBC (XML-Container) pain Ältere Versionen des DFÜ-Abkommens werden von der HVB weiterhin akzeptiert: DFÜ-Abkommen 2.5/2.6 (2010/2012): pain DFÜ-Abkommen 2.4 (2009): pain bzw. geliefert nach entsprechender Einlieferung: DFÜ-Abkommen 2.5/2.6 (2010/2012): pain DFÜ-Abkommen 2.4 (2009): pain Die Reject-Nachrichten (pain.002) werden verwendet, wenn die Rücknachricht vor Settlement, also vor Buchung, erfolgt. Dazu gehören z. B. Rückgaben wegen Formatfehlern etc. Weitere Informationen erhalten Sie von Ihrem Cash Management & ebanking-spezialisten. 11

12 6. Aufbau der Kundendatei (XML*) XML-Container nur für deutsche DK-Formate optional Group Header Dieser Block muss vorhanden sein und existiert einmal. Er enthält Elemente wie Nachrichten-ID, Erstellungsdatum und -zeit. Payment Information (Dateiebene) Dieser Block muss mindestens einmal vorkommen und ist wiederholbar. Er enthält Elemente, die sich auf die Herkunftsseite der Transaktion beziehen, wie z. B. Auftraggeber oder Zahlungsart-Informationen und einen oder mehrere Transaction-Information-Blöcke. Ebene der logischen Datei für die Auftraggeber-Buchung (als Sammler) Transaction Information Dieser Block muss pro Payment Information mindestens einmal vorkommen und ist wiederholbar. Er enthält u. a. Elemente, die sich auf die Empfängerseite Zahlungsempfänger bei der Überweisung bzw. Zahler (Zahlungspflichtiger) bei der Lastschrift beziehen. Er enthält den Betrag und den Verwendungszweck. * XML = Extensible Markup Language Auftragsarten Container sowie Aufbau Datei mit GroupHeader, PaymentInfo und TransactionInfo pain.001. GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-1 DK XML-Container EBICS-Auftragsart CCC TransactionInfo Creditor/EUR PaymentInfo Debtor: Konto-2 TransactionInfo Creditor/EUR EBICS-Auftragsart CCT (mixed) pain.001. GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-1 TransactionInfo Creditor/EUR PaymentInfo Debtor: Konto-2 TransactionInfo Creditor/EUR pain.001. GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-3 TransactionInfo Creditor/EUR EBICS-Auftragsart CCT (mixed) pain.001. GroupHeader InitiatingParty Firma-1 PaymentInfo Debtor: Konto-3 TransactionInfo Creditor/EUR 12

13 Gruppierung von Dateien und was kann gemischt angeliefert werden? Die Einreichung von SEPA-Dateien erfolgt als Sammler, hierzu müssen Dateien gebildet werden: Je physische Datei (Sendung (z. B. XML-Container)/GroupHeader) getrennt nach Produkt (SCT, SDD-Core, SDD-COR1, SDD-B2B, CT-Urgent) <XML-Schema>, <PmtInfId>, <SvcLvl> und <LclInstrm>, da für jedes Produkt eine eigene Sende-Auftragsart verwendet werden muss Je logische Datei (PaymentInfo), insbesondere auch getrennt nach Auftraggeber-IBAN Fälligkeitstag <ReqdColltnDt> bzw. Ausführungstag <ReqdExctnDt> Lastschriftsequenz (First, Recurrent, Final, OneOff) <SeqTp> Unterscheidung zwischen SCT und SCT-Preferred (gleichtägiges Clearing) <InstrPrty> Sammel-/Einzelbuchung der Einreichung <BtchBookg> Anzahl der Sätze bzw. Datei-Größenbeschränkung siehe unten In einer logischen Datei können gemischt werden z. B. : verschiedene Empfänger bzw. Zahlungspflichtige bei Lastschriften verschiedene Beträge <Amt> Verwendungszweck <RmtInf>, Zahlungsgründe <Purp>, End-To-End-Referenz <EndToEndId> verschiedene Mandatsinformationen bei Lastschriften. * Das bisherige Inlandszahlungsverkehrsformat DTAUS ist sehr viel kleiner als das XML-Datenformat. Eine Transaktion ohne Header hat im DTAUS bis zu 622 Bytes, während eine SEPA-Transaktion über Bytes beinhalten kann, hinzu kommen noch die Header-Informationen. Um noch verarbeitungsfähige Dateien zu erhalten (Filetransfer, Mapping, Validierung und Fehlerrecherche, etc.), empfiehlt es sich, die Gruppierung nicht zu groß zu machen und auf maximal Transaktionen pro Datei (bis zu 210 MB) zu begrenzen. Prüfung auf Doppelverarbeitung von Dateien Damit Dateien nicht doppelt verarbeitet werden, prüft die HVB logische Dateien (PaymentInf) nach folgenden Prinzipien: Je Auftraggeber-IBAN Zeitraum: 15 TARGET-Tage Ermittelte Gesamtsumme in EUR Ermittelte Anzahl Posten Produkt (SCT, Basislastschrift, Firmenlastschrift) Summe der Prüfziffern (Stelle 3 4) aller Empfänger- bzw. Zahlungspflichtigen-IBANs 13

14 7. SEPA Credit Transfer (SCT) Grundlegende Merkmale Auftraggeberkonto und Empfängerkonto werden im SEPA-Raum geführt (Kontoinhaber kann auch außerhalb ansässig sein). Transaktionswährung ist immer EUR. Unterschiede gegenüber Inlandsüberweisung (wird abgelöst zum ) Verwendung von IBAN/BIC Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen) Zusätzliche Zahlungsgründe (PurposeCodes) sind optional möglich. Verwendung von On-Behalf/Ultimates ist optional möglich. Zusätzliche Referenzierungsmöglichkeiten Grenzüberschreitend im SEPA-Raum Unterschiede gegenüber EU-Standardüberweisung (abgelöst seit ) Explizit auch nationale Nutzung Kein AWV-Meldeteil im Datensatz vorhanden Auch Zahlungen in die Schweiz und nach Monaco 14

15 Wichtige fachliche XML-Felder für SEPA Credit Transfer Feldnamen Beschreibung pain Befüllung DFÜ-Abkommen 2.7 GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei PmtInf MsgId (Message-Id) CreDtTm (CreationDateTime) NbOfTxs (NumberOfTransactions) CtrlSum (ControlSum) InitgPty-Nm (InitiatingPartyName) InitgPty-Nm-Id-OrgId/ PrvtId (InitiatingPartyOrganisation-Id/Private-ID) PaymentInstruction- Information PmtInfId (PaymentInformation-ID) Näheres siehe Seite Einreicher-Referenznummer pro Datei Pflichtfeld (eindeutig) Max. 35 Zeichen 38 39, Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date Anzahl aller Einzeltransaktionen Pflichtfeld Unbegrenzt Kontrollsumme in Euro der Einreichung Empfohlen Unbegrenzt Name Einreicher (kann vom Namen des Pflichtfeld Max. 70 Zeichen Auftraggebers abweichen) Identification DK nicht empfohlen Diverse 31 Auftraggeberdaten beliebig oft möglich, empfohlen max Referenz der Einreichung Pflicht Max. 35 Zeichen 38 39, PmtMtd (PaymentMethod) Zahlungsinstrument: Credit Transfer Pflicht TRF BtchBookg (BatchBooking) NbOfTxs (NumberOfTransactions) CtrlSum (ControlSum) InstrPrty (InstructedPriority) SvcLvl-Cd (ServiceLevelCode) CtgyPurp (CategoryPurpose) ReqdExctnDt (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) DbtrAgt-Othr-Id (DebtorAgentId) Auftraggeberbuchung Sammler/Einzelsatz Optional, in Stammdaten administriert Anzahl aller Einzeltransaktionen Empfohlen Unbegrenzt Kontrollsumme in Euro der logischen Datei Priorität der Ausführung: high oder norm Empfohlen Optional, in Stammdaten administriert false Einzelbuchung true Sammelbuchung Unbegrenzt HIGH SCT Preferred NORM SCT Normal Service Schema Pflicht SEPA, URGP (siehe Kap. 13) Zahlungsart der Datei Optional, in Stammdaten administriert Gewünschter Ausführungstermin Pflichtfeld ISO-Date Name Auftraggeber. Ggf. von Bank mit Kontoinhaber überschrieben Für gleichtägige Gehaltszahlung SALA , 40, 60 25, 40 Pflichtfeld Max. 70 Zeichen Land der Anschrift des Auftraggebers Optional Ländercode ISO 3166, DE für Deutschland Anschrift Auftraggeber. Ggf. von Bank mit Kontoadresse überschrieben Optional Max. 2x70 Zeichen 26 Identification DK nicht empfohlen Diverse 31, 41 IBAN des Auftraggebers Pflichtfeld Max. 34 Zeichen 9, 27 29, Währung des Auftraggeberkontos Optional Währungscode BIC/SWIFT-Code des Auftraggebers Kennzeichnung IBAN-Only Optional bei DE-Banken (IBANOnly), sonst Pflichtfeld Optional, bei Nutzung von IBAN-Only für Deutschland 26 8 bzw. 11 Stellen 9, 29, NOTPROVIDED 29 UltmtDbtr (UltimateDebtorName) UltmtDbtr-Id-OrgId-Othr (UltimateDebtor-IBAN) Vom Kontoinhaber abweichender Auftraggeber. Rein informatorischer Charakter Ultimate Einreicherbelastungs-IBAN Optional, nur wenn Produkt Ultimate Auftraggeber Optional Max. 70 Zeichen 7, 25 26, 32, 40 Max. 34 Zeichen 27 28, 32, ChrgBr (ChargeBearer) Preis-Verrechnung immer shared Empfohlen SLEV 40 15

16 Fortsetzung Feldnamen CdtTrfTxInf CreditTransfer- Transaction-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) Ustrd-RmtInf (UnstructuredRemittanceInfo) Strd-CdtrRefInf- CdtrRefTp-Cd (StructuredCreditor Reference-Code) Strd-CdtrRefInf-CdtrRef (StructuredCreditor Reference) Beschreibung pain Transaktions-Information Technische Referenz zwischen Einreicher und Bank Referenz, wird bis Begünstigten durchgereicht Befüllung DFÜ-Abkommen 2.7 Näheres siehe Seite beliebig oft möglich, empfohlen max Optional, wenn gefüllt: eindeutig Max. 35 Zeichen 38 39, Pflichtfeld (eindeutig, sonst: NOTPROVIDED ) Betrag und Währungskennzeichen Pflichtfeld Nur Euro erlaubt Abweichender Auftraggeber Optional. Nicht, wenn auf PmtInf-Ebene schon gefüllt Max. 35 Zeichen 38 39, Max. 70 Zeichen 7, 25 26, 32, 40 Identification DK nicht empfohlen Diverse 31, BIC/SWIFT-Code der Begünstigten-Bank Optional bei DE-Banken (IBAN-Only), sonst Pflichtfeld 8 bzw. 11 Stellen. Zusätzlich bei HVB: NOTPROVIDED, NOTAVAIL 9, 29, Name Begünstigter Pflichtfeld Max. 70 Zeichen Land der Anschrift des Begünstigten Optional Ländercode ISO 3166, 26 DE für Deutschland Anschrift Begünstigter Optional Max. 2x70 Zeichen 26 Identification DK nicht empfohlen Diverse 31 IBAN des Begünstigten Pflichtfeld Max. 34 Zeichen 9, 27 29, Abweichender Endbegünstigter. Rein informatorischer Charakter Optional Max. 70 Zeichen 7, 25 26, 32, 40 Identification DK nicht empfohlen Diverse 31, Art der Zahlung (Textschlüssel), z. B. SALA (Salary) bei Gehaltszahlung Optional ISO ExternalPurposeCode- Liste 7, 24, 54 Unstrukturierter Verwendungszweck Empfohlen Max. 140 Zeichen 22, 40 Strukturierter Verwendungszweck für CreditorReference Strukturierter Verwendungszweck Teil 2 CreditorReference: prüfzifferngerechte CreditorReference Nur wenn kein unstrukturierter Verwendungszweck Nur wenn kein unstrukturierter Verwendungszweck RF +Prüfziffer+Reference (ISO 11649) SCOR 23, 40 Max. 35 Zeichen 23, 40 Nicht angegeben sind rein technische Felder oder Felder, die in Deutschland möglich, aber von den Banken nicht empfohlen sind (z. B. OrgID, weitere strukturierte Verwendungszwecke). Details und Angabe aller Felder finden Sie im DFÜ-Abkommen Spezifikation der Datenformate. 16

17 8. Beispiel einer Kundendatei GroupHeader Beschreibung DTAUS-Feld <?xml version= 1.0 encoding= UTF-8?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain pain xsd"> <CstmrCdtTrfInitn> <GrpHdr> <MsgId> </MsgId> <CreDtTm> T10:55:06</CreDtTm> <NbOfTxs>1</NbOfTxs> <InitgPty> <Nm>MEIER PAYMENT MUENCHEN</Nm> </InitgPty> </GrpHdr> PaymentInformation logische Datei <PmtInf> <PmtInfId>PAYMENT </PmtInfId> <PmtMtd>TRF</PmtMtd> <BtchBookg>true</BtchBookg> <NbOfTxs>1</NbOfTxs> <CtrlSum> </CtrlSum> <PmtTpInf> <InstrPrty>NORM</InstrPrty> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> </PmtTpInf> <ReqdExctnDt> </ReqdExctnDt> <Dbtr> <Nm>MEIER CORNELIA MUENCHEN</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>DE </IBAN> </Id> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>HYVEDEMMXXX</BIC> </FinInstnId> </DbtrAgt> <UltmtDbtr> <Nm>MEIER GEHALTSABTEILUNG</Nm> </UltmtDbtr> <ChrgBr>SLEV</ChrgBr> CreditTransferTransaction Einzeltransaktion <CdtTrfTxInf> <PmtId> <EndToEndId>OriginatorID1234</EndToEndId> </PmtId> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>SPUEDE2UXXX</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Creditor Name</Nm> </Cdtr> <CdtrAcct> <Id> <IBAN>DE </IBAN> </Id> </CdtrAcct> <Purp> <Cd>PENS</Cd> </Purp> <RmtInf> <Ustrd>Unstructured Remittance Information</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> </CstmrCdtTrfInitn> </Document> 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) PaymentInfID eindeutige Referenz der log. Datei PaymentMethode: Transfer Batchbooking True/False Sammler/Einzelbuchung Anzahl Posten Summe EUR Priority NORM/HIGH (SCT-Preferred) ServiceLevel SEPA Ausführungstag Auftraggeber Name (ggf. mit Adresse) Auftraggeber-IBAN Auftraggeber-BIC Ultimate Auftraggebername SLEV = Shared bei SEPA End2End-Id Referenz der Zahlung aus Sicht des Auftraggebers Betrag in EUR Creditor Empfänger-BIC Empfängername Empfänger-IBAN Purpose Textschlüssel der Zahlung siehe ISO external Code list Remittance-Info Verwendungszweck 140 Stellen (~DTA-A7) (DTA-A6) (~DTA-A10) (DTA-E4) (DTA-E8) (DTA-A11b) (DTA-C15) (~DTA-C11) (~DTA-C10) (DTA-C12) (~DTA-C4) (DTA-C14a + Erw) (~DTA-C5) (~DTA-C7a) (~DTA-C16 + Erw) 17

18 9. SEPA Direct Debit (SDD) Grundlegende Merkmale SEPA-Basislastschrift (SDD-Core) ähnlich der Inlands-Einzugsermächtigungs-Lastschrift SEPA-Firmenlastschrift (SDD-B2B) ähnlich der Inlands-Abbuchungsauftrags-Lastschrift Mandat muss zum Abgleich auch bei der Debitorbank vorliegen. Unterschiede gegenüber Inlandslastschrift (Einzugsermächtigung wird abgelöst zum und Abbuchungsauftrag zum ) Angabe der Gläubiger-Identifikationsnummer (vergeben von der Bundesbank) Mitgabe von Mandatsinformationen (Mandats-ID und Mandatsunterschriftsdatum) Mitgabe von prozessrelevanten Angaben (Sequenz der Einreichung, Fälligkeitstag mit entsprechenden Vorlaufeinreichungstagen) Verwendung von IBAN/BIC Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen) Zusätzliche Zahlungsgründe (PurposeCodes) sind optional möglich. Verwendung von On-Behalf/Ultimates ist möglich. Zusätzliche Referenzierungsmöglichkeiten Grenzüberschreitende Nutzung im SEPA-Raum Wichtige fachliche XML-Felder für SEPA Direct Debit Feldnamen Beschreibung pain Befüllung DFÜ-Abkommen 2.7 Inhalt des papierhaften Mandats GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei PmtInf MsgId (Message-ID) CreDtTm (CreationDateTime) NbOfTxs (NumberOfTransactions) CtrlSum (ControlSum) InitgPty-Nm (InitiatingPartyName) InitgPty-Nm-Id-OrgId/ PrvtId (InitiatingPartyOrganisation-ID/Private-ID) PaymentInstruction- Information PmtInfId (PaymentInformation- ID) PmtMtd (PaymentMethod) BtchBookg (BatchBooking) NbOfTxs (NumberOfTransactions Einreicher-Referenznummer pro Datei Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date Näheres siehe Seite Pflichtfeld (eindeutig) Max. 35 Zeichen 38 39, Anzahl aller Einzeltransaktionen Pflichtfeld Unbegrenzt Kontrollsumme in Euro der Einreichung Name Einreicher (kann abweichen von Auftraggebernamen) Empfohlen Unbegrenzt Pflichtfeld Max. 70 Zeichen Identification DK nicht empfohlen Diverse 31 Zahlungsempfänger-Daten beliebig oft möglich, empfohlen max Referenz der Einreichung Pflichtfeld Max. 35 Zeichen 38 39, Zahlungsinstrument: Direct Debit Pflichtfeld DD Auftraggeberbuchung Sammler/ Einzelsatz Optional, wenn administriert in Stammdaten true -Sammelbuchung false -Einzelsatzbuchung Anzahl aller Einzeltransaktionen Empfohlen Unbegrenzt

19 Fortsetzung Feldnamen CtrlSum (ControlSum) SvcLvl-Cd (ServiceLevelCode) LclInstrm-Cd (LocalInstrumentCode) SeqTp (SequenceType) CtgyPurp (CategoryPurpose) ReqdColltnDt (RequestedCollection- Date) Cdtr-Nm (CreditorName) Cdtr-PstlAdr-Ctry (CreditorCountry) Cdtr-PstlAdr-AdrLine (CreditorAddress) CdtrAcct-IBAN (CreditorIBAN) CdtrAcct-Ccy (CreditorAccount Currency) CdtrAgt-BIC (CreditorBIC) CtrAgt-Othr-Id (CreditorAgentID) UltmtCdtr (UltimateCreditor) UltmtCdtr-Id--OrgId- Othr (UltimateCreditorIBAN) ChrgBr (ChargeBearer) UltmtCdtr-Id-OrgId/ PrvtId (UltimateCreditorOrganisation-ID/Private-ID) CdtrSchmeId-Id-PrvtId- OthrId-Id (CreditorIdentification) Beschreibung pain Kontrollsumme in Euro der logischen Datei Befüllung DFÜ-Abkommen 2.7 Empfohlen Unbegrenzt Inhalt des papierhaften Mandats Service Schema Pflicht SEPA 40 Lastschriftart: normale SEPA-Core- Basislastschrift oder SEPA-B2B- Firmenlastschrift Sequenz: Erst-, Folge-, Einmal- oder letztmalige Lastschrift Pflichtfeld (innerhalb GrpHdr nicht mischbar) Pflichtfeld CORE, COR1 oder B2B FRST, RCUR, OOFF oder FNAL Zahlungsart der Datei Optional Nicht zur Weitergabe an Endkunden Fälligkeitsdatum der Lastschrift (Datum der Belastung auf Kto. des Bezogenen) Name Zahlungsempfänger. Ggf. von Bank mit Kontoinhaber überschrieben Land der Anschrift des Zahlungsempfängers Anschrift Zahlungsempfänger. Ggf. von Bank mit Kontoadresse überschrieben Pflicht (wiederkehrend oder einmalig) Pflichtfeld ISO-Date 36 Näheres siehe Seite 7 8, 36, , 40 Pflichtfeld Max. 70 Zeichen Pflicht Optional Ländercode ISO 3166, DE für Deutschland Pflicht 26 Optional Max. 2x70 Zeichen Pflicht 26 IBAN des Zahlungsempfängers Pflichtfeld Max. 34 Zeichen 9, 27 29, Kontowährung: muss EUR sein Optional EUR BIC/SWIFT-Code des Zahlungsempfängers Kennzeichnung IBAN-Only Vom Kontoinhaber abweichender Zahlungsempfänger. Rein informatorischer Charakter Ultimate Einreicher-Gutschrifts- IBAN Optional bei DE-Banken (IBAN-Only), sonst Pflichtfeld Optional, bei Nutzung von IBAN-Only für Deutschland 8 bzw. 11 Stellen 9, 29, NOTPROVIDED 29 Optional Max. 70 Zeichen Optional 7, 25 26, 32, 40 Optional, nur wenn Produkt Ultimate Auftraggeber Max. 34 Zeichen 27 28, 32, Identification DK nicht empfohlen Diverse 31, Preis-Verrechnung immer shared Empfohlen SLEV 40 CreditorIdentification. Eindeutiges Identifikationsmerkmal des Zahlungsempfängers (per legal entity) Pflichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich (empfohlen) Max. 35 Zeichen Pflicht 30, 33,

20 Fortsetzung Feldnamen DrctDbtTxInf Direct Debit Transaction-Information InstrId (Instruction-ID) EndToEndID (End2End-ID) InstrAmt (Instructed Amount) Mndtld (MandateID) DtOfSgntr (DateOfSignature) AmdmntInd (AmendmentIndicator) OrgnlMndtId (OriginalMandateID) OrgnlCdtrSchmeId-Nm (OriginalCreditorName) OrgnlCdtrSchmeId-Id- PrvtId-OthrId-Id (OriginalCreditorIdentification) OrgnlDbtrAcct-IBAN (OriginalDebtorIBAN) OrgnlDbtrAgt-Id (OrignalDebtorAgentID) ElctmcSgntr (ElectronicSignature) CdtrSchmeId-Id-PrvtId- OthrId-Id (CreditorIdentification) UltmtCdtr (UltimateCreditorName) UltmtCdtr-Id-OrgId/ PrvtId (UltimateCreditorOrganisation-ID/Private-ID) DbtrAgt-BIC (DebtorAgentBIC) DbtrAgt-Othr-Id (DebtorAgentID) Beschreibung pain Transaktions-Information Technische Referenz zwischen Einreicher und Bank Referenz, wird bis Zahlungspflichtigen durchgereicht Befüllung DFÜ-Abkommen 2.7 beliebig oft möglich, empfohlen max Optional, wenn gefüllt: eindeutig Pflichtfeld (eindeutig, sonst: NOTPROVIDED ) Betrag und Währungskennzeichen Pflichtfeld Nur Euro erlaubt Inhalt des papierhaften Mandats Näheres siehe Seite Max. 35 Zeichen 38 39, Max. 35 Zeichen 38 39, Eindeutige Mandatsreferenz Pflichtfeld Max. 35 Zeichen kann nachgeliefert werden Datum, zu dem das Mandat unterschrieben wurde bzw. über die Mandatsumdeutung informiert wurde Kennzeichen, ob das Mandat verändert wurde Eindeutige Referenz des ursprünglichen Mandats, falls sich die Mandatsreferenz (MndtId) geändert hat Ursprünglicher Creditor-Name, falls sich der Zahlungsempfänger geändert hat Ursprüngliche CreditorIdentification, falls sich die Creditor- Identification (CdtrSchmeIdI) geändert hat Ursprüngliche IBAN des Zahlungspflichtigen, falls sich die IBAN geändert hat Ursprüngliche Debtorbank hat sich geändert. Neueinreichung mit Sequenz FRST nötig Elektronisches Mandat emandate elektronische Signatur CreditorIdentification. Eindeutiges Identifikationsmerkmal des Zahlungsempfängers (per legal entity) Name abweichender Zahlungsempfänger Pflichtfeld ISO-Date Pflicht, im Papiermandat auch Ort der Unterschrift und Unterschrift Optional Nur bei Mandatsveränderung (AmdmntInd = true) Nur bei Mandatsveränderung (AmdmntInd = true) Nur bei Mandatsveränderung (AmdmntInd = true) Nur bei Mandatsveränderung (AmdmntInd = true) Nur bei Mandatsveränderung (AmdmntInd = true) Optional. Nicht für papierhafte Mandate Pflichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich Optional. Nicht, wenn auf PmtInf-Ebene schon gefüllt Veränderung = true Standard = false 38 39, Max. 35 Zeichen 33 35, 38 39, Max. 70 Zeichen Max. 35 Zeichen 30, 33 35, Max. 34 Zeichen 27 29, Kennzeichen SMNDA 33 35, 37 Max Zeichen; erst mit emandate relevant Max. 35 Zeichen 30, 33, Max. 70 Zeichen 7, 25 26, 32, 40 Identification DK nicht empfohlen Diverse 31, BIC/SWIFT-Code der Zahlungspflichtigen-Bank (= Bank des Zahlungspflichtigen) Kennzeichnung IBAN-Only Optional bei DE-Banken (IBAN-Only), sonst Pflichtfeld Optional, bei Nutzung von IBAN-Only für Deutschland 8 bzw. 11 Stellen. Zusätzlich bei HVB: NOTPROVIDED, NOTAVAIL Optional bei DE-Banken (IBAN-Only), sonst Pflichtfeld NOTPROVIDED 29 9, 29,

21 Fortsetzung Feldnamen Dbtr-Nm (DebtorName) Dbtr-PstlAdr-Ctry (DebtorCountry) Dbtr-PstlAdr-AdrLine (DebtorAddress) Dbtr-Id-OrgId/PrvtId (DebtorOrganisation- Id/Private-ID) DbtrAcct-IBAN (DebtorIBAN) UltmtDbtr (UltimateDebtor) UltmtDbtr-Id-OrgId/ PrvdtId (UltimateDebtorOrganisation-ID/Private-ID) Purp (Purpose) Ustrd-RmtInf (Unstructured RemittanceInfo) Unstrukturierter Verwendungszweck Strd-CdtrRefInf- CdtrRefTp-Cd (StructuredCreditor Reference-Code) Strd-CdtrRefInf-Cdtr Ref (StructuredCreditor Reference) Beschreibung pain Befüllung DFÜ-Abkommen 2.7 Inhalt des papierhaften Mandats Näheres siehe Seite Name Zahlungspflichtiger Pflichtfeld* Max. 70 Zeichen 9, Land der Anschrift des Zahlungspflichtigen Optional Ländercode ISO 3166, DE für Deutschland Optional ab Feb Anschrift Zahlungspflichtiger Optional Max. 2 x 70 Zeichen Optional ab Feb Identification DK nicht empfohlen Diverse 31, 41 IBAN des Zahlungspflichtigen Pflichtfeld Max. 34 Zeichen Pflicht 9, 27 29, Name abweichender Zahlungspflichtiger. Rein informatorischer Charakter Optional Max. 70 Zeichen Optional 7, 25 26, 32, 40 Identification DK nicht empfohlen Diverse 31, Art der Zahlung (Textschlüssel). Im Kontoauszug MT940/942 werden nicht alle Codes dargestellt. Optional ISO ExternalPurposeCode- Liste Empfohlen Max. 140 Zeichen Optional (Vertragsnummer und Beschreibung) , 24, 54 22, 40 Strukturierter Verwendungszweck DK nicht empfohlen SCOR 23, 40 Strukturierter Verwendungszweck Teil 2 DK nicht empfohlen Max. 35 Zeichen 23, 40 * Wenn ein Lastschriftmandat für eine SEPA-Lastschrift am POS/Kartenterminal aus Kartendaten generiert wird und der Name des Zahlers nicht verfügbar ist, können als Name auch die Kartendaten mit der Konstante /CDGM (Card Data Generated Mandate), gefolgt von /Kartennummer/Folgenummer/Verfalldatum(JJMM) angegeben werden. Die Kartennummer ist links auf 19 Stellen aufzunullen. Ist die Kartennummer nicht verfügbar, so ist die PAN zu verwenden. 21

22 10. SEPA häufig genutzte Zahlungsinformationen im Format 10.1 Verwendungszweck Verwendungszweck <RmtInf> Der Verwendungszweck hat bei SEPA nur 140 Stellen. Im DTAUS-Inlandszahlungsverkehr sind dagegen bis 14 x 27 Zeichen (= 378 Stellen) möglich. In Ergänzung zu dem Verwendungszweck können bei SEPA allerdings noch ein strukturierter Purpose <Purp> und eine Detaillierung der beteiligten Parteien (Adresse und Identifikationsnummern) sowie die End-To-End- Referenz mit 35 Stellen vorgenommen werden. <RmtInf> <Ustrd> </Ustrd> </RmtInf> Vermögenswirksame Leistungen (VL-Zahlungen) Im Falle von vermögenswirksamen Leistungen (VL) wird hier XXJ/Vertragsnummer eingetragen, wobei XX entweder 00 oder durch den Prozentsatz der Sparzulage ersetzt wird und der Buchstabe J durch die letzte Ziffer des Leistungsjahres. Der Name des VL-Empfängers kann ggf. im Datenelement Ultimate Creditor hinterlegt werden. Des Weiteren muss als Purpose Code CBFF gesetzt werden. <Purp> <Cd>CBFF</Cd> </Purp> <RmtInf> <Ustrd> 003/ABC </Ustrd> </RmtInf> 22

23 Strukturierter Verwendungszweck <RmtInf> <Strd> Strukturierte Creditor-Referenz <CdtrRefInf> Belege mit prüfzifferngerechten Verwendungszwecken gibt es analog den BZÜ-Belegen im Inlandszahlungsverkehr, auch in SEPA. Sie werden bei SEPA CreditorReference genannt nach ISO 11649, beginnend mit RF und dann gefolgt von 21 alphanumerischen Stellen. Berechnet wird die CreditorReference mit Modulus 97. In SEPA ist nur der strukturierte Verwendungszweck mit dem Codewort SCOR zugelassen. Wenn die Prüfziffer nicht korrekt ist, wird die Referenz in den unstrukturierten Verwendungszweck überführt. Im papierhaften und elektronischen Kontoauszug MT940 wird die Struktur grundsätzlich nicht mitgegeben, sondern einfach nur der Inhalt ohne Tags, z. B. SCOR RF Im neuen camt.05x wird die Struktur durchgeleitet. <RmtInf> <Strd> </Strd> </RmtInf> <CdtrRefInf> </CdtrRefInf> <Tp> <CdOrPrtry> <Cd>SCOR</Cd> </CdOrPrtry> </Tp> <Ref>RF </Ref> 23

24 10.2 Zahlungsgrund: Purpose Code <Purp> Die strukturierte Information über den Zahlungsgrund pro Zahlung, z. B. Spende oder Gehalt, wird über den Purpose Code in SEPA abgebildet. Der Purpose Code geht grundsätzlich an die Empfänger-Bank und deren End-Empfänger. Er kann zu unterschiedlichen Geschäftsvorfall-Codes (GVC) im elektronischen Auszug führen. Die Zahlungsgründe sind aufgeführt in im Reiter 11-Purpose. <CdtTrfTxInf> </CdtTrfTxInf>... <Purp> </Purp> <Cd>PENS</Cd> Purpose- Code - Auszug ADVA AGRT AIRB ALMY BECH Erklärung Vorabzahlung Landwirtschaft Luftverkehr Alimente und Unterhalt Kindergeld BENE Arbeitslosengeld GVC Haben 156 BLDM Gebäudepflege BONU Bonuszahlung GVC Haben 153 BUSB CASH CBFF CBTV CDBL CFEE Busverkehr Cash Management Vermögenswirksame Leistung Kabelfernsehen Kreditkartenabrechnung Stornogebühr Spezieller Geschäftsvorfall-Code für elektronischen Auszug bzw. Anmerkungen GVC Haben 154 CHAR Spende GVC Soll 119, Haben 169 CLPR COMM COST CSLP DCRD DNTS ELEC ENRG ESTX GASB GDDS GOVI GOVT GWLT HLTC HLTI 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 Purpose- Code - Auszug HSPC INPC INSM INSU INTC INTE INTX LBRI LICF LIFI LOAN MDCS NWCM Erklärung Krankenhausbehandlung Autoversicherung Ratenzahlung Versicherung Intra-Company Übertrag Zinsen Einkommensteuer Berufsversicherung Lizenzkosten Lebensversicherung Kreditzahlung Medizinische Dienste Netzwerkkommunikation Spezieller Geschäftsvorfall-Code für elektronischen Auszug bzw. Anmerkungen PAYR Lohn/Gehaltszahlung GVC Haben 153 (ab DFÜ 2.7) PENS PHON PPTI Telefon Pensions- und Rentenzahlung Haus/Grundstücksversicherung GVC Haben 153 RINP Dauerauftragsgutschrift GVC Haben 152 (ab DFÜ 2.7) RLWY Bahnverkehr SALA Lohn/Gehaltszahlung GVC Haben 153 SAVG SCVE Sparerzahlung Dienstleistungen allgemein SSBE Sozialleistungen GVC Haben 156 STDY SUPP TAXS TELI TRAD VATX WEBI WTER Bildung und Unterricht Lieferantenzahlung Steuerzahlung Laut Telefonauftrag Handelsgeschäft Mehrwertsteuer Laut Auftrag im Internet Wasser 24

25 10.3 Produktkategorie: Category Purpose <CtgyPurp> Der Category Purpose ist eine Anweisung des Einreichers an die Einreicher-Bank. Er gilt eine besondere Verarbeitung der Aufträge/der Datei, z. B. mit einer Priorisierung oder Sonderkonditionen. Gilt für Datei oder je Zahlung Die Information geht nicht an die Empfänger-Bank. Es ist eine bilaterale Vereinbarung über Nutzung mit der Bank erforderlich. Bei HVB wird derzeit nur SALA (gleichtägige Gehaltszahlungen) auf Dateiebene verwendet. Weitere Informationen zum Produkt können Sie auch unserem Spezialflyer Credit Transfer Preferred entnehmen. <PmtInfId> </PmtInfId>... <PmtTpInf> </PmtTpInf> <CtgyPurp> </CtgyPurp> <Cd>SALA</Cd> 10.4 Fünf Beteiligte in einer SEPA-Nachricht Auftraggeber und Empfänger bzw. Zahlungspflichtiger erscheinen in den verschiedenen Ebenen eines SEPA- Auftrags bzw. einer Dateieinreichung. Über die Felder Ultimate kann zusätzlich ein abweichender Auftraggeber und Zahlungsempfänger bzw. -pflichtiger mitgegeben werden. Beispiel SEPA-Überweisung GroupHeader InitiatingParty (Einreicher) PaymentInf Dateiebene Debitor (Auftraggeber) IBAN/BIC (Auftraggeber) UltimateDebitor Name (70 Stellen) Adresse (2 x 70 Stellen zzgl. Ländercode)* Organisationsnummer Personenidentifikation Transaktion Creditor (Empfänger) IBAN/BIC (Empfänger) Pflichtangabe Optional UltimateCreditor * Adresse nicht möglich bei Initiating Party und den Ultimates 25

26 Beispiel SEPA-Lastschrift GroupHeader InitiatingParty (Einreicher) PaymentInf Dateiebene Creditor (Auftraggeber) Gläubiger-ID (Creditor) IBAN/BIC (Creditor) UltimateCreditor Name (70 Stellen) Adresse (2 x 70 Stellen zzgl. Ländercode)* Organisationsnummer** Personenidentifikation** Transaktion Debitor (Zahlungspflichtiger) IBAN/BIC (Zahlungspflichtiger) UltimateDebitor Pflichtangabe Optional * Adresse nicht möglich bei Initiating Party und den Ultimates ** OrgID & PrivId nicht möglich bei Creditor 10.5 Name, Adresse In der SEPA-Nachricht gibt es fünf mögliche Beteiligte (Debtor, Creditor, InitiatingParty, Ultimate Creditor und Ultimate Debtor) Der jeweilige Name <Nm> der Beteiligten wird immer mit bis zu 70 Stellen angegeben. Optional können bei Debtor und Creditor noch Adressen <PstlAdr> mitgegeben werden. Hierzu sind 2 x 70 Stellen der unstrukturierten Adresse <AdrLine> zu verwenden zuzüglich dem Ländercode <Ctry>. Der Auftraggebername und die -adresse (bei grenzüberschreitenden Zahlungen) müssen aufgrund der Auftraggeberdatenverordnung korrekt mitgeliefert werden. Die HVB füllt diese automatisch mit den Kontostammdaten. <Nm>ABC Handels GmbH</Nm> <PstlAdr> <Ctry>DE</Ctry> <AdrLine>Dorfstrasse 14</AdrLine> <AdrLine>Muenchen</AdrLine> </PstlAdr> 26

27 10.6 IBAN, IBAN-Only International Bank Account Number IBAN ist das eindeutige Identifikationskriterium für Zahlungsempfänger und Zahlungspflichtige. Die IBAN löst die nationale Kontonummer im SEPA-Zahlungsraum für SEPA-Aufträge komplett ab. <Id> </Id> <IBAN>DE </IBAN> Der Aufbau ist definiert von ISO :2007. Die IBAN beginnt mit zwei Buchstaben, dem Länderkennzeichen, gefolgt von der numerischen Prüfziffer. Die zweistellige Prüfziffer errechnet sich über die gesamte IBAN nach ISO 7064 im Modulus Anschließend erfolgt eine Bank-/Kontoidentifikation. Diese Bank-/Kontoidentifkation ist je nach Land unterschiedlich strukturiert und hat bis zu 34 Stellen. Derzeit gibt es IBANs zwischen 15 und 31 Stellen und neben numerischen Werten können ab der 5. Stelle auch alphanumerische Werte enthalten sein. In Deutschland bilden die ersten 8 Stellen nach der Prüfziffer die numerische Bankleitzahl und die folgenden 10 Stellen die numerische Kontonummer, sodass die gesamte IBAN in Deutschland 22-stellig ist. Ob die Kontonummer korrekt ist, lässt sich für viele Banken anhand der letzten Stelle der Kontonummer sagen. Viele Banken verwenden diese letzte Ziffer für eine Kontrollziffer. Welcher bankenindividuelle Berechnungsmodulus hierfür notwendig ist, lässt sich im Bankleitzahlenverzeichnis bei der Bundesbank anhand der BLZ ermitteln. Eine simple Ermittlung der Prüfziffer anhand der BLZ und Kontonummer führt in Deutschland häufig zu Fehlleitungen von Zahlungen, da besonders zu beachten ist: Einzelne Institute füllen das Kontonummernfeld in der IBAN bei Kontonummern kleiner 10 Stellen nicht linksbündig mit Nullen auf, sondern füllen die Nullen am Ende der Kontonummer auf. Besonders durch Fusionen und Zusammenlegungen von Bankfilialen benutzen Kunden häufig noch ihre alte Bankleitzahl weiter, obwohl sie bereits in ihrer IBAN eine neue Bankleitzahl erhalten haben. Deshalb sollte eine IBAN-Berechnung immer über die kontoführende Bank oder in Deutschland über den BankVerlag oder über Verfahren stattfinden, die die institutsindividuellen Besonderheiten berücksichtigen, welche von der Bundesbank veröffentlicht wurden. Beispiele für institutsindividuelle Besonderheiten bei der IBAN-Ermittlung Spenden- und Pseudokonten werden vor IBAN-Ermittlung in echte Kontonummern umgewandelt, z. B.: BLZ und Konto wird in IBAN zu Konto , also DE Konten werden hinten statt vorne auf 10 Stellen mit Nullen aufgefüllt, z. B.: BLZ und Konto werden zu IBAN DE Die BLZ wird ausgetauscht, z. B.: BLZ und Konto werden zu IBAN DE

28 IBAN-Beispiele für andere Länder Im Dokument sind alle national vereinbarten IBAN-Formate aufgeführt, hier ein Auszug: Österreich (20-stellig): LLPPBBBBBKKKKKKKKKKK Beispiel: AT LL Länderkennzeichen: AT Buchstaben PP Prüfziffer 2-stellig numerisch BBB... österreichische Bankleitzahl 5-stellig numerisch KKK... Kontonummer 11-stellig numerisch Schweiz (21-stellig): LLPPBBBBBKKKKKKKKKKKK Beispiel: CH LL Länderkennzeichen: CH Buchstaben PP Prüfziffer 2-stellig numerisch BBB... Schweizer Bankleitzahl 5-stellig numerisch KKK... Kontonummer 12-stellig numerisch Italien (27-stellig): LLPPNBBBBBCCCCCKKKKKKKKKKKK Beispiel: IT60X LL Länderkennzeichen: IT Buchstaben PP Prüfziffer 2-stellig numerisch N Control Internal Number (CIN) 1-stellig alphanumerisch BBB... Associazione Bancaria Italiana (ABI) 5-stellig numerisch CCC... Codice di Avviamento Bancario (CAB) 5-stellig numerisch KKK... Kontonummer 12-stellig numerisch 28

29 IBAN-Only Seit 4. November 2013 kann in Deutschland für innerdeutsche Transaktionen die Angabe des BIC entfallen: SCT pain <DbtrAgt> <FinInstnId> <Othr> <Id>NOTPROVIDED</Id> </Othr> </FinInstnId> </DbtrAgt>... CdtrAgt kann komplett entfallen <CdtrAgt> <FinInstnId> <BIC>SPUEDE2UXXX</BIC> </FinInstnId> </CdtrAgt>... SDD pain <CdtrAgt> <FinInstnId> <Othr> <Id>NOTPROVIDED</Id> </Othr> </FinInstnId> </CdtrAgt>... <DbtrAgt> <FinInstnId> <Othr> <Id>NOTPROVIDED</Id> </Othr> </FinInstnId> </DbtrAgt>... Um den Kunden den Umstieg auf IBAN-Only zu erleichtern, bietet die HVB ihren Kunden als Sonderlösung seit April 2013 IBAN-Only auch in den bestehenden XML-Formaten direkt über das BIC-Feld an, ohne das zusätzliche XML-Feld Other-Id: SCT pain , pain , pain <DbtrAgt> <FinInstnId> <BIC>HYVEDEMMXXX</BIC> </FinInstnId> </DbtrAgt>... <CdtrAgt> <FinInstnId> <BIC>HYVEDEMMXXX</BIC> </FinInstnId> </CdtrAgt>... Oder <BIC>NOTAVAIL</BIC> SDD pain , pain , pain <CdtrAgt> <FinInstnId> <BIC>HYVEDEMMXXX</BIC> </FinInstnId> </CdtrAgt>... <DbtrAgt> <FinInstnId> <BIC>HYVEDEMMXXX</BIC> </FinInstnId> </DbtrAgt>... Oder <BIC>NOTAVAIL</BIC> Beim Payment-Status-Report pain.002 wird IBAN-Only wie folgt berücksichtigt: Bei Überweisungen enthält der DebtorAgent den BIC der HVB und der CreditorAgent verbleibt so, wie dieser angeliefert wurde. Bei Lastschriften gilt dies analog für CreditorAgent und DebtorAgent. 29

30 10.7 Gläubiger-Identifikation (Creditor-Identification/CI) Die Länge und Vergabe der Gläubiger-Identifikation ist je Land unterschiedlich. Für Deutschland ist die Länge 18 und die Vergabe erfolgt pro Legal-Entity über Format: LLPPZZZXXXXXXXXXXX LL Ländercode PP Prüfziffer berechnet nach ISO (analog IBAN-Prüfziffer) ZZZ Gläubiger-Geschäftsbereichskennung, beliebig zu vergeben, z. B. um Überschneidungen bei Mandatsreferenzen zu vermeiden. Im Standard mit Wert ZZZ belegen XXX Nationale Identifikation bis zu 28 Stellen (für Deutschland 11 Stellen inkl. führende Null) <CdtrSchmeId> <Id><PrvtId><Othr> <Id>DE12ZZZ </Id> <SchmeNm> <Prtry>SEPA</Prtry> </SchmeNm> </Othr></PrvtId></Id> </CdtrSchmeId> Die Gläubiger-Identifikation sollte möglichst auf Payment-Informations-Ebene und nicht bei jeder Transaktion wiederholt angegeben werden. Die Gläubiger-Geschäftsbereichskennung wird von der Prüfziffernberechnung ignoriert. Wird eine abweichende Gläubiger-Geschäftsbereichskennung beim Einzug verwendet, muss diese auch auf dem Mandat angegeben werden. 30