Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1. Einleitung
2. Definition SEPA
2.1 Problemstellung
2.2 Zielsetzung und Bedeutung von SEPA
2.3 Teilnehmerländer
3. Die gesetzlichen Voraussetzungen für SEPA
3.1 Zahlungsdiensterichtlinie PSD
3.2 EPC-Richtlinien
3.3 EU-Verordnung Nr. 260/2012
3.4 Deutsches Begleitgesetz
4. Der technische Hintergrund von SEPA
4.1 IBAN
4.2 BIC
4.3 SEPA-Datenformat
4.4 Nachrichtenaufbau
5. Bestandteile von SEPA
5.1 SEPA-Überweisung
5.2 SEPA-Lastschrift
5.2.1 SDD-Core
5.2.2 SDD-B2B
5.2.3 Gläubiger-ID
5.2.4 Pre-Notification
5.2.5 R-Transaktionen
5.2.6 SEPA-Mandat
5.2.6.1 Mandatsarten
5.2.6.2 Mandatserteilungsprozess
5.2.6.3 Mandatsmigration
5.2.6.4 Anforderungen an eine Mandatsverwaltung
5.3 SEPA-Kartenzahlung
6. Auswirkungen von SEPA in einzelne Unternehmensprozesse
7. Umsetzung der SEPA-Anforderungen im SAP-System
7.1 Payment Medium Workbench
7.1.1 Grundlagen
7.1.2 Konfiguration der Zahlungsträgerformate
7.1.3 Prozessablauf
7.2 Data Medium Exchange Engine
7.3 Unterstützung der neuen Zahlungsformate in SAP
7.3.1 SEPA_CT
7.3.2 SEPA_DD
7.4 SEPA-Mandatsverwaltung in SAP
7.4.1 SAP-Datenfelder des Mandats
7.4.2 Verwaltung der SEPA-Mandate
7.4.3 Integration in den Zahllauf
7.4.4 Konfiguration
7.5 Anpassung von Prozessen der Zahlungsabwicklung
7.5.1 Anpassung der Stammdaten für Personenkonten und Banken
7.5.2 Migration deutscher Bankverbindungen in das IBAN-Format
7.5.3 Anpassung der Kontoauszugsverarbeitung
8. Zusammenfassung
Literaturverzeichnis
Anhang
Anhang 1: Übersicht der SEPA-Teilnehmerländer
Anhang 2: SEPA-Mandat
Anhang 3: SEPA-Kombimandat
Anhang 4: Firmenkunden-Befragung zu den SEPA-Herausforderungen
Anhang 5: Aufbau des DMEE-Formatbaums für SEPA_CT
Anhang 6: Aufbau des DMEE-Formatbaums für SEPA_DD
Anhang 7: Datenfelder der SEPA-Mandatsverwaltung
Anhang 8: Druckansicht eines SEPA-Mandats im SAP-System
Anhang 9: Konfiguration der SEPA-Mandatsverwaltung für FI-AR
Anhang 10: SEPA-Geschäftsvorfallcodes
Anhang 11: Einlesen Elektronischer Kontoauszug im SAP-System
Anhang 12: In dieser Arbeit behandelte SAP-Transaktionen
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Aufbau der IBAN in Deutschland
Abbildung 2: Aufbau des BIC
Abbildung 3: Aufbau eines XML-Datensatzes
Abbildung 4: SEPA-Nachrichten
Abbildung 5: CSM-Infrastruktur
Abbildung 6: Ablauf des SEPA-Überweisungsverfahrens
Abbildung 7: Ablauf des SEPA-Basislastschriftverfahrens
Abbildung 8: Ablauf des SEPA-Firmenlastschriftverfahrens
Abbildung 9: Aufbau der Gläubiger-ID
Abbildung 10: SEPA-Zahlungsträgerformate
Abbildung 11: PMW-Konfiguration für den Zahlweg SCT und Land DE
Abbildung 12: Verwendungszweck nach Herkunft ändern
Abbildung 13: Pflege der Granularität der Zahlungsträgerausgabe vom Format SEPA_CT
Abbildung 14: DMEE-Formatbaum für SEPA_CT
Abbildung 15: Anzeige von SEPA-Mandaten in den Debitorenstammdaten
Abbildung 16: Dialog-Transaktion FSEPA_M1 zum Anlegen von Mandaten im FI-AR
Abbildung 17: Pflege der UCI
Abbildung 18: Ablage von IBAN und BIC am Debitor
Abbildung 19: Aktivierung von „IBAN ohne Bankkontonummer“
Abbildung 20: SEPA-Teilnehmerländer
Abbildung 21: SEPA-Lastschriftmandat als separates Formular, Standardfall einer wiederkehrenden Lastschrift
Abbildung 22: SEPA-Kombimandat als Bestandteil eines Vertrages
Abbildung 23: SEPA-Herausforderungen
Abbildung 24: Druckansicht eines SEPA-Mandats im SAP-System
Abbildung 25: Standard-Konfiguration der SEPA-Mandatsverwaltung für FI-AR
Abbildung 26: Einlesen Elektronischer Kontoauszug
Tabelle 1: Berechnung der IBAN-Prüfziffer
Tabelle 2: Elektronische Kontoauszüge im camt- und SWIFT-Format
Tabelle 3: Aufbau des DMEE-Formatbaums für SEPA_CT
Tabelle 4: Aufbau des DMEE-Formatbaums für SEPA_DD
Tabelle 5: Datenfelder der SEPA-Mandatsverwaltung
Tabelle 6: SEPA-Geschäftsvorfallcodes
Tabelle 7: SAP-Transaktionen
Das Europäische Parlament und der Europäische Rat haben im Februar 2012 die EU-Verordnung zur weiteren Harmonisierung von Zahlungsdiensten im EU-Binnenmarkt beschlossen. Zehn Jahre nach der Bargeldeinführung des Euro im Jahr 2002 wird mit dem Euro-Zahlungsverkehrsraum SEPA (Single Euro Payments Area) auch der bargeldlose Zahlungsverkehr in Europa vereinheitlicht.[1]
Die derzeitige europäische Zahlungsverkehrslandschaft ist durch eine Heterogenität an unterschiedlichen Dateiformaten, die in den verschiedenen nationalen Systemen des Inlands- und Auslandszahlungsverkehrs zum Einsatz kommen, gekennzeichnet. Der Vereinheitlichung des europäischen Zahlungsverkehrs stehen zurzeit die unterschiedlichen Zahlungsverkehrsinfrastrukturen mit jeweils eigenen Dateiformaten und den damit implizierten Systembrüchen entgegen. Die Definition des SEPA-Datenformates zielt auf eine Konvergenz zu einem einheitlichen europäischen Standard im Zahlungsverkehrssektor.
In dieser Bachelor Thesis soll die Umsetzung der sich aus der Einführung der SEPA ergebenden Anforderungen im SAP-System erörtert werden. Dazu wird in Kapitel 2 zunächst die Zielsetzung und Bedeutung für die teilnehmenden SEPA-Länder erläutert. Anschließend werden die gesetzlichen Rahmenbedingungen für die SEPA Initiative aufgezeigt. In den Kapiteln 4 und 5 werden die theoretischen Grundlagen der SEPA-Umsetzung und deren neue Zahlungsinstrumente beleuchtet. Das Kapitel 6 befasst sich mit den Auswirkungen der SEPA auf die Prozesse im Unternehmen und der Fragestellung, ob sich aus der SEPA-Einführung gewisse Synergien und Optimierungspotentiale in den Unternehmensprozessen ergeben können. Es folgt eine ausführliche Darstellung der konkreten Umsetzung der SEPA-Anforderungen im SAP-System, bei der u.a. die Werkzeuge, die die SAP bereitstellt, vorgestellt werden. SAP liefert an alle Kunden mit gültiger Wartungsvereinbarung die funktionalen Erweiterungen aus, um die SEPA-Kompatibilität des SAP-Systems zu gewährleisten. Der heutige DTA-Zahllauf im SAP-System ist durch die entsprechende SEPA-Business-Logik zu ergänzen. Im Anschluss werden die wichtigsten Punkte zusammengefasst und ein Ausblick auf die möglichen Entwicklungen im harmonisierten Zahlungsverkehrsraum gegeben.
Diese Bachelor Thesis verfolgt eine anwendungsorientierte Zielsetzung, die neben der Beschreibung und Erklärung der SEPA-Zahlungsverfahren die konkrete Umsetzung der Sachverhalte im SAP-System behandelt. Die vorliegende Arbeit wurde auf Basis des Enhancement Package 4 des SAP ERP 6.0-Systems der FOM Hochschule für Oekonomie & Management erstellt. Als Informationsquellen wurden neben Beschreibungen fachspezifischer Prozesse, Dokumentationen bestehender SAP-Software-Lösungen sowie die gültigen SEPA-spezifischen gesetzlichen Richtlinien und Ergebnisse von Erhebungen Dritter genutzt.
SEPA bedeutet Single Euro Payments Area und bezeichnet den einheitlichen Zahlungsverkehrsraum für Finanztransaktionen in Euro.[2][3] Die Umstellung von den nationalen Zahlungsverfahren in Euro auf SEPA ist eine gesetzliche Verpflichtung, die von jedem Kreditinstitut, Unternehmen und Verbraucher in allen teilnehmenden Ländern umgesetzt werden muss.[4] Die neuen europäischen Zahlungsinstrumente für Lastschriften und Überweisungen sowie das Rahmenwerk für Kartenzahlungen wurden sukzessive seit 2008 sowohl für den grenzüberschreitenden als auch für den nationalen Euro-Zahlungsverkehr eingeführt. Die nationalen Zahlungsverfahren für Überweisungen und Lastschriften werden auf der gesetzlichen Grundlage der EU-Verordnung Nr. 260/2012 zum 01.02.2014 endgültig durch die SEPA-Zahlungsverfahren abgelöst.[5]
Die Nutzung der neuen SEPA-Verfahren zeigt im rein marktgetriebenen Ansatz nur sehr langsame Fortschritte. In Deutschland lag der SEPA-Anteil bei Überweisungen, die über die Bundesbank abgewickelt worden sind, im 2. Halbjahr 2011 bei 5,56 %. Im Euroraum lag der SEPA-Anteil bei Lastschriften im April 2012 bei 0,35%.[6] Vor allem liegt dies an den über Jahrzehnte entwickelten nationalen Verfahren, die die jeweiligen Bedürfnisse des Marktes weitgehend abdecken. Weiterhin gibt es eine große Divergenz bei den technischen Formaten und Standards zur nationalen Zahlungsabwicklung in den einzelnen Euro-Ländern. Es gelang der europäischen Kreditwirtschaft bisher nicht, die angestrebte kritische Masse zu erreichen, die zur Ablösung der nationalen Zahlungsverfahren geführt hätte. Ohne die Festsetzung von Auslaufterminen für die nationalen Zahlungsverfahren ließ sich die SEPA bisher nicht vollumfänglich umsetzen.[7][8] Die umfänglichen Vorteile des gemeinsamen pan-europäischen Zahlungsverkehrsraums können nur lukriert werden, wenn eine kritische Masse diese auch wirklich nutzt.[9] Mit Inkrafttreten der EU-Verordnung Nr. 260/2012 zum 30.03.2012 wurden verbindliche Endtermine der nationalen Verfahren festgelegt. Durch die gesetzliche Regulierung zur endgültigen SEPA-Einführung ist eine gewisse Dringlichkeit entstanden, die die Unternehmen und Banken verpflichtet, die sich dadurch ergebenden komplexen Änderungen bis zum 01.02.2014 umzusetzen und die entsprechenden Anpassungen in den IT-Systemen durchzuführen.
Das strategische Ziel der SEPA ist die Weiterentwicklung des Euro-Währungsgebietes zu einem vollständig integrierten inländischen Zahlungsverkehrsraum.[10] Dadurch soll die Abwicklung von bargeldlosen Zahlungen innerhalb der Teilnehmerländer standardisiert werden, sodass es keine Unterschiede zwischen nationalen und grenzüberschreitenden Zahlungen mehr gibt.[11][12]
Das Europäische Parlament und der Europäische Rat haben im Februar 2012 die EU-Verordnung Nr. 260/2012 zur weiteren Harmonisierung von Zahlungsdiensten im EU-Binnenmarkt beschlossen. Nach der Bargeldeinführung des Euro im Jahr 2002 wird mit SEPA auch der bargeldlose Zahlungsverkehr in Europa vereinheitlicht und ein weiterer Meilenstein für einen gemeinsamen Binnenmarkt erreicht.[13][14] Eine Vorgabe war, dass der neue SEPA-Zahlungsverkehr so effizient, einfach, kostengünstig und sicher durchgeführt werden soll wie die jeweiligen bestehenden nationalen Verfahren.[15] Neben der Konsolidierung der Zahlungssysteme sollen gleiche Wettbewerbsbedingungen geschaffen werden. Die erheblichen Preisunterschiede und Verarbeitungszeiten, bedingt durch fehlende länderübergreifende technische Standards und Regeln sowie unterschiedlicher lokaler Zahlungsgewohnheiten und Zahlungsinstrumente, sollen mit der Etablierung der SEPA aufgehoben werden.[16][17]
Der elektronische Zahlungsverkehr ist durch die Einführung der SEPA in 32 europäischen Ländern vereinheitlicht. Mit SEPA wurde somit eine Infrastruktur geschaffen, die es ermöglicht, grenzüberschreitende Zahlungsvorgänge genauso schnell abzuwickeln wie Zahlungsvorgänge im Inland. Der einheitliche Euro-Zahlungsverkehr in und zwischen den 32 Teilnehmerländern soll damit schneller, einfacher und sicherer abgewickelt werden. Die Mitgliedschaft wurde auch auf Staaten ausgeweitet, die den Euro derzeit nicht als Landeswährung verwenden. Teilnehmerländer sind alle 27 Mitglieder der Europäischen Union (EU), zudem Island, Liechtenstein und Norwegen, die zum Europäischen Wirtschaftsraum (EWR) gehören, sowie Monaco und die Schweiz.[18][19] Im Anhang 1 befindet sich eine Übersicht der SEPA-Teilnehmerländer.
Die Realisierung der SEPA ist Bestandteil der Entwicklung und Umsetzung des gemeinsamen Binnenmarktes der EU. Was 1957 mit den Römischen Verträgen zur Schaffung der Europäischen Wirtschaftsgemeinschaft (EWG) begann und 1992 mit dem Vertrag von Maastricht zur Gründung der Europäischen Wirtschafts- und Währungsunion (EWWU) weitergeführt wurde, erreicht nun mit SEPA einen weiteren Meilenstein.[20] Zur Unterstützung dieser politischen Forderung wurde von der europäischen Kreditwirtschaft ein eigenständiges Gremium, das European Payments Council (EPC) gegründet, von dem u. a. die Regelwerke (Rulebooks) definiert wurden. Neben den grundlegenden EPC-Richtlinien und der Zahlungsdiensterichtlinie PSD gibt es einige länderspezifische Besonderheiten der Teilnehmerländer. Diese Regelungen werden von den nationalen Interessenverbänden wie z.B. der Deutschen Kreditwirtschaft (DK) festgelegt und in das zu verabschiedende Deutsche Begleitgesetz aufgenommen. Mit der Verabschiedung der EU-Verordnung Nr. 260/2012 wurde der Wunsch der europäischen Kreditwirtschaft nach einem verbindlichen Endtermin für nationale Zahlungsverfahren erfüllt.
Die EU-Finanz- und Wirtschaftsminister haben sich im März 2007 über die Richtlinie für Zahlungsdienste im Binnenmarkt (Payment Services Directive, PSD) geeinigt. Die PSD, die im Europäischen Parlament verabschiedet wurde und am 01.11.2009 in Kraft trat, reguliert alle Zahlungen in europäischen Währungen in Europa und bildet damit auch den rechtlichen Rahmen für SEPA.[21] Mit der PSD kann der Zahlungsverkehr europaweit auf einer rechtlich einheitlichen Basis abgewickelt werden. Die PSD umfasst inhaltlich nicht nur die SEPA-Zahlungsverfahren, sondern auch die nationalen Zahlungsverfahren. Darüber hinaus gilt die PSD auch für Währungen anderer EU-Mitgliedsstaaten, während die SEPA sich nur auf Euro-Zahlungen bezieht.[22] Ein wesentlicher Bestandteil der PSD ist die Reduzierung der maximalen Ausführungsfrist (D+1). Die Kreditinstitute sind seit dem 01.01.2012 verpflichtet, beleglose Zahlungen innerhalb eines Geschäftstages abzuwickeln. Für beleghafte Zahlungen erhöht sich die Ausführungsfrist um einen zusätzlichen Geschäftstag (D+2). Außerdem wurde in der PSD die Kontoprüfung beim Empfängerinstitut mit Wirkung zum 01.11.2009 geändert. Es wird seitdem nicht mehr geprüft, ob der Name auf der Überweisungsgutschrift mit dem des Überweisungsauftrages übereinstimmt und nur noch nach Kontoidentifikationen (Kto./BLZ oder IBAN/BIC) gebucht.[23]
Die europäischen Banken haben sich zur selbstregulierten Gestaltung und Umsetzung der SEPA den European Payment Council (EPC) gegründet. Vom EPC wurden die wesentlichen Richtlinien verabschiedet, die die Grundlage für die operative Umsetzung und Ausgestaltung bei den Banken bilden. Diese sind das SEPA Rulebooks für Credit Transfers und Direct Debits sowie das SEPA Card Framework und die SEPA Implementation Guidelines.[24] Mit der Verabschiedung der Implementation Guidelines im September 2006 sind die für den Interbankenverkehr verbindlichen Grundlagen für die Verfügbarkeit der neuen SEPA-Datenformate gemäß ISO 20022 vorhanden.[25] Der EPC als Standardisierungsgremium der europäischen Kreditwirtschaft nimmt in den EPC-Arbeitsgruppen eine fortlaufende Weiterentwicklung der Regelwerke für die SEPA-Lastschrift und SEPA-Überweisung vor.[26][27] Diese haben i.d.R. Modifizierungen der Zahlungsträgerformate zur Folge, was entsprechende Anpassungen im SAP-System erfordert.
Auf Grundlage der SEPA-Rulebooks ist es neben den definierten Zahlungsinstrumenten SCT und SDD möglich, zusätzliche kundengerechte Services (Additional Optional Services, AOS) anzubieten.[28] Diese zusätzlichen Dienstleistungen dürfen die Funktionsfähigkeit des Verfahrens sowie die Handlungsfähigkeit der SEPA-Teilnehmer nicht beeinträchtigen.[29]
Am 30.03.2012 wurde die EU-Verordnung Nr. 260/2012 des Europäischen Parlaments und des Rates vom 14.03.2012 zur Festlegung der technischen Vorschriften und der Geschäftsanforderungen für Überweisungen und Lastschriften in Euro und zur Änderung der Verordnung (EG) Nr. 924/2009 im Amtsblatt der Europäischen Union veröffentlicht und trat damit in Kraft.[30] Durch die EU-Verordnung werden folgende wesentliche Eckpunkte festgelegt:
Gemeinsamer Endtermin für die nationalen Überweisungs- und Lastschriftverfahren zum 01.02.2014 (Längere Übergangsfristen für Nicht-Euroländer: 31.10.2016)
Pflicht zur Nutzung von IBAN
Pflicht zur Nutzung von ISO 20022-XML
Ab 01.02.2014 IBAN-only für nationale SEPA-Zahlungsaufträge
Ab 01.02.2016 IBAN-only für alle SEPA-Zahlungen (BIC entfällt im Kunde-Bank-Verhältnis)
Die EU-Verordnung Nr. 260/2012 gilt für Zahlungen innerhalb der Europäischen Union per Überweisung und Lastschrift in der Währung Euro. Eilüberweisungen, Schecks, Wechsel, Kartenzahlungen und andere Fremdwährungs-Zahlungen sind von der Verordnung nicht betroffen. Zahlungsdienstleister in der EU, die an inländischen Überweisungs- und Basislastschriftverfahren teilnehmen, müssen in dem jeweiligen SEPA-Verfahren erreichbar sein.[31][32]
Die EU-Verordnung Nr. 260/2012 sieht vor, dass einige Regelungen durch die Teilnehmerländer ausgestaltet werden müssen, andere sind als Option formuliert. Dies geschieht durch sogenannte nationale Begleitgesetze. Das deutsche Begleitgesetz trifft Festlegungen zu optionalen Konvertierungsdienstleistungen der Kreditinstitute, der befristeten Weiterführung des Elektronischen Lastschriftverfahrens des Handels (ELV) und den zuständigen Behörden (einschließlich Sanktionen und außergerichtliche Beschwerdeverfahren).[33] Die Inhalte des Begleitgesetzes führen zu einer Anpassung des Zahlungsdiensteaufsichtsgesetzes (ZAG). Ergänzend wird die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) als national zuständige Behörde für die Überwachung der Einhaltung der in der EU-Verordnung Nr. 260/2012 enthaltenen Pflichten bestimmt.[34] Durch das deutsche Begleitgesetz für den Übergangszeitraum bis zum 01.02.2016 kann das ELV-Verfahren weiterhin verwendet werden. Außerdem darf der Privatkunde bei nationalen Zahlungen weiterhin Kontonummer und die BLZ verwenden.[35] Das Gesetz ist für die SEPA-Migration in Deutschland bedeutsam und wird derzeit vom Deutschen Bundestag behandelt. Das Deutsche Begleitgesetz wird wahrscheinlich bis Ende des Jahres 2012 in Kraft treten.
Sowohl für die SEPA-Überweisung (SCT) als auch für die SEPA-Lastschriften (SDD) ist die Angabe der Kontoverbindung in Form von International Bank Account Number (IBAN) und den Business Identifier Code (BIC) verpflichtend.[36] Dies gilt für den nationalen deutschen Zahlungsverkehr genauso, wie für Zahlungen innerhalb des SEPA-Raumes.[37] Für die Einreichung und Abwicklung belegloser SEPA-Überweisungen (SCT) und SEPA-Lastschriften (SDD) wurde ein neues XML-basiertes Datenformat in den SEPA-Regelwerken vom EPC definiert. Dieser einheitliche technische Standard bildet die Grundlage für die Interoperabilität von Zahlungsverkehrsinfrastrukturen in SEPA und ermöglicht eine vollautomatische Abwicklung von Zahlungen.[38]
IBAN steht für International Bank Account Number und ist eine standardisierte, internationale Bank-/Kontonummer für nationale und grenzüberschreitende Zahlungen.[39] Die IBAN soll den grenzüberschreitenden Zahlungsverkehr vereinheitlichen und damit vereinfachen. Die IBAN besteht je nach Teilnehmerland aus bis zu 34 fortlaufenden alphanumerischen Zeichen (siehe Anhang 1). Jede IBAN in Deutschland besteht aus 22 alphanumerischen Zeichen, beginnend mit der zweistelligen Länderkennung DE, gefolgt von einer zweistelligen Prüfziffer sowie der Bankleitzahl und Kontonummer[40][41] (siehe Abbildung 1).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Aufbau der IBAN in Deutschland
Quelle: Entnommen aus: http://www.hypovereinsbank.de/portal?view=/privatkunden/242274.jsp.
Die Ermittlung der IBAN anhand der im IZV gebräuchlichen Konto- und Bank-Identifikationen ist in der ISO-Norm 13616 beschrieben. Die Richtigkeit einer IBAN kann nur durch das jeweils kontoführende Kreditinstitut festgestellt werden.[42][43] Die zweistellige Prüfziffer wird gem. ISO 7064 mit der Modulus 97-10-Methode generiert. In der nachfolgenden Tabelle 1 wird der Algorithmus zur Ermittlung der Prüfziffer des IBAN einer deutschen Bankverbindung erläutert.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Berechnung der IBAN-Prüfziffer
In Anlehnung an: https://www.sparkasse-dortmund.de/pdf/content/sepa/iban_bic.pdf, Stand 01.08.2012.
Gemäß der EU-Verordnung können Mitgliedstaaten den Banken erlauben, bis 01.02.2016 für Verbraucher Kontonummer und Bankleitzahl in die IBAN zu konvertieren.[44] Bis dahin besteht für die Verbraucher eine optionale Nutzung von Kontonummer und Bankleitzahl für nationale SEPA-Zahlungen. Ab dem 01.02.2014 wird für Unternehmen die IBAN für Zahlungen im Inland verpflichtend. Wenn grenzüberschreitende Zahlungen ausgeführt werden, muss zusätzlich der BIC übermittelt werden.[45]
Ein BIC ist die internationale Bankleitzahl eines Kreditinstituts gem. ISO 9362. Dieser international standardisierte Code kann neben der Identifikation von Kreditinstituten auch zur eindeutigen Bestimmung von anderen Geschäftsstellen wie z.B. Brokern, Lagerstellen und Unternehmen im Zahlungsverkehr verwendet werden. Der BIC besteht aus maximal elf Stellen und wird oft auch als SWIFT-Code bezeichnet[46] (siehe Abbildung 2).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Aufbau des BIC
Quelle: Entnommen aus: http://www.hypovereinsbank.de/portal?view=/privatkunden/242274.jsp.
Die ersten vier Stellen entsprechen der Bankbezeichnung, sind alphanumerisch und können von der Bank frei gewählt werden, z.B. HYVE für HypoVereinsbank. Anschließend folgt die zweistellige Länderkennung, welche dem ISO-Code des jeweiligen Landes gem. ISO-3166-1 entspricht, beispielsweise DE für Deutschland. Darauf folgt eine zweistellige Orts-/Regionsangabe, z.B. MM für München. Wenn das zweite Zeichen kein Buchstabe sondern eine Zahl ist, so bedeutet dies bei einer 0, dass es sich um einen Test-BIC handelt. Die letzten drei Stellen können für Filialbezeichnungen genutzt werden.[47] Ein 8-stelliger BIC kann um "XXX" auf einen 11-stelligen ergänzt werden, entsprechend kann "XXX" auch weggelassen werden.[48]
Ab dem 01.02.2014 dürfen Kreditinstitute bei Inlandszahlungen von ihren Kunden den BIC nicht mehr verlangen. Diese Vorgabe wird ab 01.02.2016 auch für grenzüberschreitende Zahlungen gelten.[49][50]
Das SEPA-Datenformat basiert auf dem ISO Standard 20022 und wurde für den Interbanken-Zahlungsverkehr verpflichtend eingeführt. Für den Datenaustausch zwischen Kunde und Kreditinstitut wird das neue XML-basierte Format empfohlen.[51] In Deutschland hat der ZKA eigene Formatempfehlungen veröffentlicht, die sich in Details unterscheiden. Das XML-Format ist ein offener, internationaler Standard zur Datenmodellierung in Form einer Baumstruktur, welcher vom World Wide Web Consortium (www.w3c.org) verwaltet wird. Im Gegensatz zum spaltenorientierten DTA-Format wird im XML-Format jeder Wert von zusätzlichen sogenannten XML-Tags umschlossen[52] In der folgenden Abbildung 3 ist der Aufbau eines XML-Datensatzes dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Aufbau eines XML-Datensatzes
Das hat zur Folge, dass XML-basierte Zahlungsdateien durchaus fünf- bis zehnmal mal mehr Zeichen benötigen als DTA-basierte Zahlungsträger[53], so dass mit einem deutlich größeren Bedarf an Rechnerressourcen, Speicher- und Übertragungskapazitäten kalkuliert werden muss, um eine gleichartige Performance zu ermöglichen. Entsprechende Investitionen in die Hard- und Softwareausstattung sind erforderlich. Das XML-Format hat aber den Vorteil, dass weltweit viele IT-Systeme diesen internationalen Standard in ihren Schnittstellen unterstützen, wohingegen das DTA-Format eher national begrenzt ist.[54] Das XML-Format ist auf Grund der Trennung von Inhalt und Darstellung der Daten plattform- und programmunabhängig.[55] Ein weiterer Vorteil der Nutzung von XML ist die einfachere Konvertierung mittels XSLT in andere Formate. In heterogenen Landschaften ist dadurch eine komfortable Kommunikation möglich.[56] Es ist abzusehen, dass ISO 20022 XML zukünftig neben der SEPA auch in weiteren Zahlungsverkehrsverfahren, wie z. B. bei TARGET2-Individualzahlungen zum Einsatz kommen wird. Die ISO 20022-Formate, als neuer globaler Standard der Finanzindustrie, werden sich im europäischen Zahlungsverkehr als einzig gültige Norm in Europa durchsetzen.[57][58]
Bei den SEPA-Nachrichten handelt es sich um einen End-to-End-Standard, der die Durchgängigkeit der Datenattribute des SEPA-Formats durch die gesamte Prozesskette vom Zahlungspflichtigen bis zum Zahlungsempfänger gewährleistet. Zur Referenzierung von Nachrichten, Nachrichtenblöcken und Zahlungsaufträgen bieten die neuen SEPA-Datensätze zusätzliche Funktionalitäten. Während beispielsweise in den heutigen DTA-Satzstrukturen die Referenzierung von der Erstellung des Lastschriftsatzes bis zur evtl. Übermittlung der Rücklastschrift ausschließlich über das Abbuchungsdatum und den Verwendungszwecks erfolgt, werden in den XML-Datensätzen Datenelemente zur Verfügung gestellt, die eine eindeutige Referenzierung ermöglichen. Die Kreditinstitute sind verpflichtet, diese Datenfelder unverändert im Interbankenverkehr und in der Schnittstelle Bank zu Kunde durchzureichen, was zur eindeutigen Identifizierung des Zahlungsauftrages führt. Ferner kann dieses eindeutige Merkmal als Referenz im Reklamationsfall gegenüber der Bank oder auch als Zuordnungskriterium für Rückgaben verwendet werden. Die Referenzierung ist dabei auf Ebene der Nachrichtendatei, auf der der Einzeltransaktion und der des Sammlers möglich.[59] Für die Abwicklung des Massenzahlungsverkehrs (EMZ) ist die Sammlerfunktionalität im DTAUS-Format, die eine Vielzahl von Einzeltransaktionen in einer Zahlungsdatei zusammenfasst, ein wesentlicher Bestandteil, die auch im SEPA-Datenformat integriert wurde.[60] Während die Kreditinstitute verpflichtet sind, die Einzeltransaktionsreferenz bis zum Kunden durchzureichen, dient die Referenzierung für die Nachrichtendatei und den Sammler ausschließlich der Interbankenkommunikation.
Der ZKA hat auf der Grundlage der Implementation Guidelines des EPC die SEPA-Datenformate für die Kunde-Bank- und die Bank-Bank-Schnittstelle definiert (siehe Abbildung 4). Hierbei wurden die Vorgaben des EPC exakt eins zu eins umgesetzt. Im SEPA-Umfeld werden Payment Initiation-Nachrichten (pain) des ISO 20022-Standards für die Einreichung von Kundenaufträgen bei der Bank eingesetzt. An der Kunde-Bank-Schnittstelle sind die Nachrichtentypen SEPA-Credit-Transfer-Initiation (pain.001) und die SEPA-Direct-Debit-Initiation (pain.008) spezifiziert worden.[61] Die Nachrichten pain.001 und pain.008 bestehen aus den Blöcken Group Header, Payment Information und Transaction Information. Der XML-Block „Group Header“ muss genau einmal vorhanden sein und enthält Elemente wie Nachrichten-ID, Erstellungsdatum und -zeit. Der XML-Block „Payment Information“ muss mindestens einmal vorkommen und ist wiederholbar. Darin sind alle Elemente, die sich auf die Herkunftsseite der Transaktion beziehen, wie z. B. Auftraggeber-Informationen und ein oder mehrere Transaction-Information-Blöcke, enthalten. Im XML-Block „Transaction Information“ sind u. a. Elemente, die sich auf die Empfängerseite beziehen, z. B. der Zahlungspflichtige einer SDD, enthalten. Außerdem sind in diesem XML-Block der Transaktionsbetrag und der Verwendungszweck zu finden.[62] An der Kunde-Bank-Schnittstelle ist für die Rückgabe vor Settlement der Nachrichtentyp pain.002 (Richtung Bank-Kunde) spezifiziert worden. Der Payment Status Report pain.002 ist ein elektronisches Fehlerprotokoll und enthält Rückweisungen von Zahlungen, die per pain.001 oder pain.008 eingereicht wurden. Dem Bankkunden werden damit fehlerhafte Transaktionen mit einem Fehlercode vor der Buchung übermittelt.[63] Für den Austausch von Zahlungsnachrichten zwischen den Banken werden Payments Clearing and Settlement-Nachrichten (pacs) des ISO 20022-Standards verwendet. Deshalb müssen die pain-Nachrichten zu pacs-Nachrichten konvertiert werden. Auch die R-Transaktionen (siehe Kapitel 5.2.5) sind pacs-Nachrichten. Beim SCT wird die pain.001 zur pacs.008 und bei der SDD die pain.008 zur pacs.003 umgewandelt. Für den elektronischen Kontoauszug werden Cash Management-Nachrichten (camt) für die Tagesendauszüge, untertägige Kontoinformationen und Avise eingesetzt (siehe Kapitel 7.5.3).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: SEPA-Nachrichten
In Anlehnung an: UniCredit Bank AG (2012b): Anlage zur SEPA-Kundeninformation: Technische Spezifikationen und Formate, S. 5.
Die SEPA-Überweisung (SCT) und die SEPA-Lastschrift (SDD) können für inländische und grenzüberschreitende Euro-Zahlungen innerhalb des SEPA-Raumes unterschiedslos ohne betragsmäßige Beschränkung genutzt werden.[64][65] Der Austausch von Transaktionen zwischen den Banken erfolgt über eine Verteil- und Verrechnungsinfrastruktur „Clearing and Settlemet Mechanism“ (CSM). Ziel der europäischen Kreditwirtschaft ist es, die vollständige Erreichbarkeit aller europäischen Banken zu gewährleisten. Eine Bank soll jede andere Bank innerhalb der SEPA erreichen können und gleichzeitig sicherstellen, dass sie ebenso von allen SEPA-Banken der Teilnehmerländer erreicht werden kann. Die Wahl der CSM-Abwicklungsstruktur unterliegt dem Wettbewerb und die Kreditinstitute können zwischen verschiedenen CSMs, die alle SEPA-konform sein müssen, entscheiden.[66] In Deutschland wird eine CSM-Infrastruktur für SEPA-Transaktionen durch den SEPA Clearer der Deutschen Bundesbank (SCL) bereitgestellt. Da jedoch nicht alle Banken in Deutschland direkt über die Bundesbank erreichbar sind haben sich die CSMs vernetzt, so dass ggf. mehrere CSMs an der Weiterleitung der Transaktionen beteiligt sind (siehe Abbildung 5).[67]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: CSM-Infrastruktur
Quelle: eigene Darstellung.
Der SEPA Credit Transfer (SCT) wurde am 28.01.2008 eingeführt und umfasst europaweit einheitliche Regeln für Überweisungen in Euro, die im Regelwerk „SEPA Credit Transfer Scheme Rulebook“ festgelegt sind. Der SCT entspricht in den Grundzügen der seit 2003 bekannten EU-Standardüberweisung, kann aber im Gegensatz dazu sowohl für grenzüberschreitende, als auch für inländische Zahlungen verwendet werden.[68] Die Zahlungsdiensterichtlinie (PSD) schreibt vor, das die Überweisungsdauer bei belegloser Auftragseinreichung ab 2012 maximal einen Bankarbeitstag bedarf. Bis zu diesem Zeitpunkt konnten drei Tage für die Ausführung der Überweisung beansprucht werden. Dem SCT wird ein festes verbindliches Ausführungsdatum mitgegeben, zu welchem das Konto des Debitors belastet wird. Im Gegensatz zur DTA-basierten Inlandsüberweisung wurde die Länge des Verwendungszwecks von 378 auf 140 Zeichen reduziert. Der Überweisungsbetrag muss dem Konto des Kreditors ungekürzt gutgeschrieben werden.[69] Die SEPA-Überweisung ist eine sogenannte SHARE-Zahlung[70], d. h. der Auftraggeber trägt die Gebühren im Land des Auftraggebers, der Empfänger die Gebühren im Empfängerland.
SCT können vor und nach der Verrechnung zurückgegeben werden. Diese sogenannte R-Transaktion kann vom Auftraggeber oder durch die Bank ausgelöst werden, wenn z.B. die falsche Empfängerkontoverbindung vorliegt.[71] Der Rückruf einer SCT (Recall) ist gem. Rulebooks nur im Interbankenverhältnis und nicht für den Rückruf durch den Kunden definiert. Nur unter bestimmten Voraussetzungen ist die Auslösung eines Recalls gestattet, wie z.B. bei technischen Problemen, die zur irrtümlichen/doppelten Ausführung der SCT geführt haben. Die Frist für den SCT-Recall beträgt zehn Bankarbeitstage.[72][73] In der nachfolgenden Abbildung 6 ist der Ablauf des SEPA-Überweisungsverfahrens dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: Ablauf des SEPA-Überweisungsverfahrens
Quelle: eigene Darstellung.
Die Einführung des europäischen Lastschriftverfahrens SEPA Direct Debit (SDD) erfolgte am 02.11.2009. Mit der SDD wurde erstmalig ein grenzüberschreitendes Lastschriftverfahren etabliert. Wie beim DTA-Lastschriftverfahren gibt es das SEPA-Lastschriftverfahren in zwei Varianten. Die SEPA-Basislastschrift (SDD Core) ist vergleichbar mit dem Einzugsermächtigungsverfahren und die SEPA-Firmenlastschrift (SDD B2B) ist vergleichbar mit dem Abbuchungsverfahren. Die Grundlage für die SDD-Verfahren bilden die jeweilige EPC-Regelwerke „SEPA Core Direct Debit Scheme Rulebook“[74] und „SEPA B2B Direct Debit Scheme Rulebook“.[75] Grundlegende Bedingung für die SDD ist die PSD, um unterschiedliche Gesetzesgrundlagen für Widerspruchsfristen zu ersetzen sowie den Lastschrifteinzug in der SEPA zu ermöglichen.[76][77] Die SDD stellt im grenzüberschreitenden Zahlungsverkehr eine Neuerung dar, da bislang kein standardisiertes Zahlungsinstrument existierte.
Der SDD muss ein Fälligkeitsdatum (Due-Date) mitgegeben werden, an dem die Belastung auf dem Konto des Debitors erfolgen soll. Wie beim SCT ist der Verwendungszweck auf 140 Zeichen minimiert.[78] Das SDD-Verfahren sieht im SEPA-Mandat ein verpflichtendes Merkmal zur kontounabhängigen und eindeutigen Kennzeichnung des Lastschriftgläubigers vor.[79] Außerdem wird in die Lastschrift-Typen Erst- (Kennzeichen: FRST), Folge- (RCUR), Einmal- (OOFF) und letzte Lastschrift (FNAL) unterschieden und im entsprechenden XML-Feld als Information mitgegeben.[80] Bei einer Änderung der Bankverbindung wird aus einer Folgelastschrift (RCUR) wieder eine Erstlastschrift (FRST). Ist dem Kreditor bekannt, dass die aktuell einzuziehende SDD die letzte SDD ist, so ist die SDD verpflichtend als letzte Lastschrift (FNAL) zu kennzeichnen. Diese Klassifizierung existiert im heutigen DTA-Verfahren nicht.[81]
[...]
[1] Vgl. http://www.voeb.de/de/themen/zahlungsverkehr/verabschiedung_sepa_verordnung, Stand 05.04.2012.
[2] Vgl. EU-Verordnung Nr. 260/2012 (2012), S. 1.
[3] Vgl. IT-Novum Whitepaper (2012), S. 4.
[4] Vgl. IT-Novum Whitepaper (2012), S. 4.
[5] Vgl. http://www.die-deutsche-kreditwirtschaft.de/dk/zahlungsverkehr/sepa/inhalte-der-sepa.html, Stand 01.09.2012.
[6] Vgl. http://www.bundesbank.de/Redaktion/DE/Downloads/Kerngeschaeftsfelder/Unbarer_ Zahlungsverkehr/informationsveranstaltung_zahlungsverkehr_und_kontofuehrung_fuer_kreditinstitute_juni_2012.pdf, Stand 29.07.2012.
[7] Vgl. http://www.sepadeutschland.de/de/ueber-sepa, Stand 29.07.2012.
[8] Vgl. Habersack, M., Mülbert, P. O., Nobbe, G. (2010), S. 6f.
[9] Vgl. Lammer, T. (2006), S. 152.
[10] Vgl. Lammer, T. (2006), S. 144.
[11] Vgl. IT-Novum Whitepaper (2012), S. 4.
[12] Vgl. Toussaint, G. (2009), S. 37.
[13] Vgl. http://www.voeb.de/de/themen/zahlungsverkehr/verabschiedung_sepa_verordnung, Stand 05.04.2012.
[14] Vgl. Bundesverband deutscher Banken e. V. (2012), S. 12.
[15] Vgl. Dittrich, A., Egner, T. (2012), S. 18.
[16] Vgl. Weiss, J. (2009), S. 39.
[17] Vgl. Habersack, M., Mülbert, P. O., Nobbe, G. (2010), S. 2f.
[18] Vgl. UniCredit Bank AG (2012a), S. 8 f.
[19] Vgl. Bundesverband deutscher Banken e. V. (2012), S. 12.
[20] Vgl. http://www.westlb.de/cms/sitecontent/westlb/westlb_de/de/ul/ts/zahlungsverkehr_/sepa_/was_ bedeutet_sepa.html, Stand 22.07.2012.
[21] Vgl. UniCredit Bank AG (2012a), S. 5.
[22] Vgl. Habersack, M., Mülbert, P. O., Nobbe, G. (2010), S. 15.
[23] Vgl. Wild, C., Siebert, J. (2012), S. 88f.
[24] Vgl. UniCredit Bank AG (2012a), S. 5.
[25] Vgl. Habersack, M., Mülbert, P. O., Nobbe, G. (2010), S. 4.
[26] Vgl. UniCredit Bank AG (2012b), S. 5.
[27] Vgl. Muthig, J. (2012), S. 12.
[28] Vgl. Wild, C., Siebert, J. (2012), S. 21.
[29] Vgl. Dippel, R., Lohmann, M., Peschke, N. (2008), S. 43.
[30] Vgl. EU-Verordnung Nr. 260/2012 (2012), S. 34.
[31] Vgl. UniCredit Bank AG (2012a), S. 7.
[32] Vgl. EU-Verordnung Nr. 260/2012 (2012), S. 1ff.
[33] Vgl. http://www.voeb.de/de/themen/zahlungsverkehr/verabschiedung_sepa_verordnung, Stand 05.04.2012.
[34] Vgl. http://www.voeb.de/download/newsletter_aktuell_03-12.pdf, Stand 03.09.2012.
[35] Vgl. van den Berg, H. R. (2012a), S. 34.
[36] Bis Juli 2010 stand die Abkürzung BIC für "Bank Identifier Code" gem. ISO 9362.
[37] Vgl. Toussaint, G. (2009), S. 124.
[38] Vgl. Gesamtverband der Deutschen Versicherungswirtschaft e. V. (2011), S. 55.
[39] Vgl. Barth, M. (2012), S. 14.
[40] Vgl. UniCredit Bank AG (2012a), S. 10.
[41] Vgl. http://www.ecbs.org/iban/germany-bank-account-number.html, Stand 29.07.2012.
[42] Vgl. UniCredit Bank AG (2012a), S. 11.
[43] Vgl. http://www.ecbs.org/iban.htm, Stand 29.07.2012.
[44] Vgl. UniCredit Bank AG (2012a), S. 7.
[45] Vgl. Wild, C., Siebert, J. (2012), S. 84f.
[46] Vgl. Barth, M. (2012), S. 14.
[47] Vgl. http://www.hypovereinsbank.de/portal?view=/privatkunden/242274.jsp, Stand 31.08.2012.
[48] Vgl. Barth, M. (2012), S. 14.
[49] Vgl. UniCredit Bank AG (2012a), S. 7.
[50] Vgl. Bundesverband deutscher Banken e. V. (2012), S. 15.
[51] Vgl. https://www.sparkasse-dortmund.de/firmenkunden/internationales_geschaeft/sepa/ datenformat/index.php, Stand 29.07.2012.
[52] Vgl. Barth, M. (2012), S. 14.
[53] Vgl. Wild, C., Siebert, J. (2012), S. 83.
[54] Vgl. Barth, M. (2012), S. 18.
[55] Vgl. Gesamtverband der Deutschen Versicherungswirtschaft e. V. (2011), S. 55.
[56] Vgl. Englbrecht, M., Wegelin, M. (2009), S. 319f.
[57] Vgl. Barth, M. (2012), S. 18.
[58] Vgl. Dittrich, A., Egner, T. (2012), S. 51.
[59] Vgl. Gesamtverband der Deutschen Versicherungswirtschaft e. V. (2011), S. 56f.
[60] Vgl. Gesamtverband der Deutschen Versicherungswirtschaft e. V. (2011), S. 55.
[61] Vgl. ZKA (2010), S. 22.
[62] Vgl. UniCredit Bank AG (2012b), S. 9.
[63] Vgl. UniCredit Bank AG (2012a), S. 26.
[64] Vgl. Toussaint, G. (2009), S. 124.
[65] Vgl. Muthig, J. (2012), S. 12.
[66] Vgl. Bundesverband Öffentlicher Banken Deutschlands (2007), S. 18f.
[67] Vgl. http://www.vdb.de/sct---das-verfahren.aspx, Stand 02.08.2012.
[68] Vgl. Grill, W., Perczynski, H. (2012), S. 133.
[69] Vgl. http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=EPC125-05 SCT RB v5.1 Approved.pdf, Stand 29.06.2012.
[70] Vgl. Barth, M. (2012), S. 8.
[71] Vgl. Wild, C., Siebert, J. (2012), S. 87.
[72] Vgl. Dittrich, A., Egner, T. (2012), S. 30.
[73] Vgl. http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=EPC125-05 SCT RB v5.1 Approved.pdf, Stand 29.06.2012.
[74] Vgl. http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=EPC016-06 Core SDD RB V5.1 Approved.pdf, Stand 29.06.2012.
[75] Vgl. http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=EPC222-07 SDD B2B RB v3.1 Approved.pdf, Stand 29.06.2012.
[76] Vgl. Muthig, J. (2012), S. 12.
[77] Vgl. Grill, W., Perczynski, H. (2012), S. 139.
[78] Vgl. Barth, M. (2012), S. 9.
[79] Vgl. http://www.bundesbank.de/Navigation/DE/Kerngeschaeftsfelder/Unbarer_Zahlungsverkehr/SEPA/ sepa.html, Stand 02.08.2012.
[80] Vgl. ZKA (2010), S. 117.
[81] Vgl. van den Berg, H. R. (2012a), S. 34.
