SEPA "Schecks"

Ein geregeltes SEPA Scheckverfahren soll es im Gegensatz zum SEPA Überweisungsverfahren, zum SEPA Lastschriftverfahren sowie zu den SEPA Kartenzahlungen b.a.w. nicht geben.

Der Zahlungsverkehr mit Schecks unterliegt von daher weiterhin den jeweiligen nationalen technischen Standards und Regelungen. Damit bleiben (zum Teil schwerwiegend) technische Probleme bei der Einlösung von ausländischer Schecks weiterhin bestehen.

Detailfragen zu künftigen Scheckeinreichungen (Scheckeinlösung, Schecksperren, Scheckeinlösungsnachfragen, Scheckrückläufer etc.) sind also auch künftig stets mit dem kontoführenden Kreditinstitut individuell zu regeln.

Die Deutsche Kreditwirtschaft (DK) geht sogar eher davon aus, dass der Scheck als papierbasiertes Zahlungsmittel nicht zukunftsfähig ist. In anderen EU Staaten hingegen - zum Beispiel in Frankreich - ist der Scheck ein gängiges und weit verbreitetes Zahlungsmittel.

Die Deutsche Bundesbank hat am 21.12.2016 das Scheckverfahren vom DTAUS Format auf das SEPA fähige XML Format (ISO 20022, Version 2013) umgestellt und damit einhergehend den DTA Zweig des EMZ für Scheckeinreichungen abgeschaltet.

SEPA Informationsquelle www.hettwer-beratung.de

Die Umsetzung des Scheckeinzugsverfahrens auf Basis des XML Formats erforderte eine Überarbeitung der relevanten Zahlungsverkehrsabkommen (Scheck, Reisescheck) sowie den scheckrelevanten Teil der Richtlinien für einheitliche Zahlungsverkehrsvordrucke.

Das BSE Verfahren (Belegloser Scheckeinzug; Scheckbetrag < 6000,00 EUR) und das ISE Verfahren (Imagegestützter Scheckeinzug; Scheckbetrag >= 6000,00 EUR) bleiben als getrennte Verfahren mit den derzeitigen Betragsgrenzen unverändert bestehen.

Die Struktur der XML Datenformate orientiert sich an der Struktur der SEPA Basislastschrift. Das Schema für die „XML Schecks“ lässt den selbigen Zeichensatz wie bei den SEPA Verfahren zu, trennt bei BSE und ISE die Originalscheckeinreichungen von den Scheck-Rückgaben; enthält jedoch keine unnötigen Elemente wie z.B. Mandatsdaten oder Gläubiger ID.

Der Austausch der Images im ISE Verfahren erfolgt unverändert über das ExtraNet der Deutschen Bundesbank.

Als führende Kontoverbindungskennung muss nun auch bei Schecks die IBAN verbindlich verwendet werden. Hierfür wurden die Vorgaben für Scheckvordrucke entsprechende angepasst.

Die Restbestände der ausgegebenen „Scheck-Altvordrucke“ dürfen b.a.w. aufgebraucht werden, so dass die Kreditinstitute hierfür nun Konvertierungsfunktionalitäten anbieten müssen. Der diesbezüglich anzuwendende XML Datensatz sieht es vor, dass auf den Scheckvordrucken zusätzlich auch die codierte Kontonummer und Bankleitzahl mitgegeben werden.

Trotz der Umstellung der Scheckeinreichungen auf das SEPA-fähige XML Format enthält das Leistungsangebot der Deutschen Bundesbank (weiterhin) keine Interoperabilität mit anderen CSM.

Die Verrechnung erfolgt auf Sub-Accounts von Konten im Payments Module (PM) der TARGET2 Plattform, also analog der Logik von SCL und EMZ mit der Nutzung eines eigenen Verrechnungskontos oder durch Benennung des Kontos eines Verrechnungsagenten.

Für die neue Scheckverrechnung wird es kein zusätzliches Erreichbarkeitsverzeichnis geben, so dass die relevante BIC von der 1. Inkassostelle anhand der BLZ Datei identifiziert und im XML Datensatz mitgegeben werden muss.

Da über die Bankleitzahlendatei hinausgehende BIC nicht zulässig sind, ist für diese Verfahrensanmeldung die Nutzung einer SEPA Wildcard-Regelung nicht möglich.

Nationale Scheckabwicklung in XML Format seit dem 21.11.2016

Die technischen Details für das Image sind in Anlage 5 zum Abkommen über den Einzug von Schecks festgelegt.

Vorder- und Rückseite eines Schecks sind im JEPG-Format (.jpg) zu erstellen

Gespeicherte Vorder- und Rückseiten eines Schecks sind mittels einer ZIP-Datei (ZIP1) zu bündeln

Hinweis:

Größe einer ZIP1-Datei sollte möglichst nicht mehr als 500 KB betragen.

ZIP1 Dateien, die die Größe von 900 KB überschreiten, gelangen nicht zur Verarbeitung, sondern werden gelöscht. Hierüber wird der Einreicher nicht informiert.

ZIP bedeutet im Image-Kontext NICHT eine „Komprimierung“