Pressebericht "SEPA - nur eine Absichtserklärung?"

Vor ein paar Wochen wurde mein Pressebericht SEPA - nur eine Absichtserklärung? veröffentlicht. Darin kritisiere ich die fehlende Standardisierung der Zusammenfassung von verschiedenen Nachrichtenarten in einer Datei.

Ab spätestens 2014 wird die Anzahl der SEPA-Transaktionen deutlich zunehmen. Damit nimmt auch die Größe von XML-Dateien zu. Bereits heute haben die Dateien eine Größe von mehreren zig Megabyte. Schon mit diesen kleinen Dateigrößen kann es problematisch sein, die Dateien mit einem Editor zu öffnen. Zwar sollten die Dateien in der Regel automatisch verarbeitet werden und keine Notwendigkeit bestehen, sie mit einem Editor zu öffnen. Allerdings zeigt die Praxis, dass dies vorkommt. So wird z.B. eine Datei von einem Clearing-Institut abgewiesen und damit nicht verarbeitet. Das Clearing-Institut schickt dann eine Datei, wo der Grund für die Abweisung der Datei enthalten ist. Es kann auf Datei-, Gruppen- und Transaktionsebene jeweils einen Grund geben. Wenn z.B. nur eine Transaktion abgewiesen wird, so wird auf Dateiebene angegeben, dass nur ein Teil der Datei akzeptiert wurde. Für jeden Bulk, der vollständig akzeptiert wurde, wird der entsprechende Code angegeben. Nur der Bulk mit der fehlerhaften Transaktion bekommt einen anderen Code und zusätzlich wird die Transaktion angegeben, die fehlerhaft ist. Für jede der Ebenen gibt es eine Auswahl von (Fehler-)Codes.

In trivialen Fällen kann eine R-Transaktion erstellt werden und die Original-Transaktion an den Absender zurückgegeben werden. In der Regel sollte eine solche Transaktion natürlich gar nicht erst an das Clearing-Institut übergeben werden. Es gibt aber natürlich Fehler, die genau dazu führen.

In komplexeren Fällen muss aber manuell eingegriffen werden. So wird z.B. ein ganzes Bulk abgewiesen weil alle darin enthaltenen Tranaktionen, die darin enthalten sind, abgewiesen wurden. Der entsprechende Fehlercode sagt genau dies aus. Wenn in dem Bulk nur eine Transaktion enthalten war, hilft dieser Code natürlich nicht bei der Behebung des Problems. Also schaut man sich die Original-Transaktion an. Wenn die Datei, die die Transaktion enthält, aber so groß ist, dass sie mit einem Editor nicht mehr geöffnet werden kann, steht man vor einem Problem.

Die Systeme, die heute für die Verarbeitung von SEPA-Dateien entwickelt werden, sollen mit mehreren Gigabyte großen Dateien umgehen können. Damit nicht nur Maschinen deren Inhalt verstehen, sondern auch Menschen vor dem Bildschirm, wurde das XML-Format gewählt. Wenn aber die Dateien wegen ihrer Größe gar nicht erst geöffnet werden können, macht das aus meiner Sicht alles keinen Sinn mehr. Deshalb verstehe ich nicht, warum Bulks in nur einer Datei zusammengefasst werden.

Letztendlich werden die Bulks sowieso getrennt voneinander verarbeitet. Wenn verschiedene Nachrichtenarten ausgetauscht werden, werden die Dateien also wieder zerpflückt, die vorher für den Austausch zusammengefügt wurden.

Warum werden mehrere ISO20022-konforme Dateien nicht zu einer Datei zusammengefasst, so wie man es von ZIP-Archiven kennt? Eine Datei mit einem standardisiertem Namen (z.B. „header.xml“) könnte als Container für Informationen über das Archiv genutzt werden. Das hätte viele Vorteile:

ISO20022 dient als vernünftige Vorlage für das SEPA-Dateiformat. Was die Clearing-Institute bisher daraus gemacht haben, ist leider in vielen Belangen nicht optimal.