Wie sich EBICS verbessern lässt, Teil 8 – Doppeleinreichungen mit EBICS-Mitteln verhindern: Was geht da?

Schnell ist es passiert. Die Zahlungsverkehrsaufträge wurden per EBICS versehentlich doppelt zur Bank übertragen. Keiner hat es bemerkt. Gleich mehrere solcher Fehlerfälle fallen einem da ein:

1. In der Zahlungserfassung wird eine Zahlung doppelt erfasst und gesendet.
2. Die Datei mit den Zahlungsaufträgen wird erneut und damit doppelt übertragen.
3. Die Zahlungsdatei wird aus technischen Gründen doppelt übertragen, da der Übertragungsstatus des ersten Transfers unklar war.

Wesentlich für eine Doppeleinreichung ist, dass ein Kunde eine Zahlung bzw. Datei mit identischen Angaben in einem festgelegten Zeitraum erneut bei der Bank einreicht. Aber ist eine identische Einreichung stets eine generell abzulehnende Doppeleinreichung? Nein, denn manche Zahlungen werden vom Einreicher bewusst mehrfach ausgestellt und übertragen.


Wie also kann die Bankseite echte Doppeleinreichungen sicher erkennen und einen Schaden für den Kunden abwenden?

Es ist möglich, zumindest offensichtliche Doppeleinreichungen bereits bei der Einreichung im EBICS-Bankrechner zu erkennen und abzulehnen.

Im Fall der technischen Doppeleinreichungen (siehe 3.) erkennt das EBICS-Protokoll bis zur EBICS-Version 2.4, wenn ein Kunde eine vom EBICS-Client vergebene Order-ID in einem definierten Zeitraum erneut verwendet. Ab EBICS V2.5 vergibt der EBICS-Bankrechner bereits beim Aufbau der Kommunikation eine eindeutige Order-ID. Ein Doppeleffekt wie bei EBICS V2.4 kann somit nicht auftreten.

Der Fall, dass eine Datei oder ein Auftrag aber versehentlich mit einem neuen Transfervorgang und somit einer neuen Order-ID noch einmal gesendet wird (siehe 2.), kann mit den bestehenden EBICS-Mitteln auf dem EBICS-Bankrechner derzeit nicht ausgeschlossen werden. Um dafür eine effektive Doppeleinreichungsprüfung auf Dateiebene zu ermöglichen, soll mit der nächsten EBICS-Version der EBICS-CR EB-14-08 DoubleUploadControl umgesetzt werden.

Dieser CR verpflichtet den EBICS-Client, einen Hashwert über die Zahlungsdatei an den EBICS-Bankrechner zu übermitteln. Der Client erstellt diesen Hashwert ohnehin für die Signaturerzeugung. Der EBICS-Bankrechner muss prüfen, ob der Hashwert im betreffenden Zeitraum schon mal vorgekommen ist, und den Auftrag bei Doppeleinreichung ablehnen.

Eine weitergehende Doppeleinreichungsprüfung, z. B. auf Einzeltransaktionsebene (Fall 1.) ist schon komplizierter und muss nach wie vor außerhalb von EBICS gelöst werden. Ggf. muss ein Bankmitarbeiter in Rücksprache mit dem Kunden ermitteln, ob die doppelte Einreichung nicht doch gewollt ist.

Mit dem geplanten EBICS-CR EB-14-08 DoubleUploadControl wird EBICS um eine weitere sinnvolle Funktion ergänzt und verbessert. Dies ist auch erforderlich. Versehentliche Doppeleinreichungen können so frühzeitig verhindert werden. Allerdings kommt damit kein Allheilmittel. Die Bankanwendungen können auf weitergehende Doppelprüfungen nach wie vor nicht verzichten.

Michael Lembcke 

Weiterlesen