Blog series: How to enhance EBICS, Part 1 – Customer order reference

In this new blog series I would like to create a regular opportunity to reflect on potential or desirable extensions to EBICS. Suggestions will have a specifically technical and specialised background, from which various solutions can be identified. To begin with, this first article in the series deals with customer order references.

Customers have often requested a reference to be sent with the order, e.g. a file name or randomly-assigned ID. This reference must be unique. In this way, the customer would be able to query the status of a specific order by using the reference, regardless of whether the order is still being processed or has been complete for days. In addition, a check can be carried out on the reference to ensure it was not submitted more than once.

At this point it should be clear that the existing four-digit order ID is not a satisfactory way to fulfil the above-mentioned requirements. Since EBICS version 2.5 the order ID has been issued by the EBICS server and is not unique.

The challenges can be met by introducing a customer order reference as an extension to the EBICS standard. In concrete terms, it could be implemented thus:

• An individual customer order reference is introduced, with a length of e.g. 512 characters. The customer order reference can be freely allocated by the customer. For instance, the file name, a random ID or a combination of both could be used. The customer order reference must be recorded in a log (PTK/HAC).
• The order reference would, for example, be tested for uniqueness in the EBICS server within 90 days for each customer. If an order is submitted with a customer order reference for which there has already been a successful upload, the new order will be declined. However, if a second upload with the same order reference initialises while the first upload is still running, the first (older) upload will be terminated with an error. In this way, the customer order reference can also be used if a transfer becomes unresponsive. This failure will always be logged in PTK/HAC.
• If the PTK/HAC entries of the bank's EBICS server are supplemented by entries e.g. from Clearing, the supplementing PTK/HAC entries should also contain the corresponding customer order reference insofar as they concern submissions.

The following orders would be possible as queries:

• The customer can specifically call up PTK/HAC for one or several customer order references. The PTK/HAC completed to that point in time will thereby be given back to the customer. The access status of PTK and HAC will remain unchanged.
• All customer order references which have already been submitted can be queried. The timespan here can be limited in a similar way to historic access. This would be a service function for the customer order references.

Introducing a customer order reference, individual query functionalities according to particular customer order references and the resulting double submission check would create a very powerful tool. The customer could search for individual submissions and would have the ability to establish an effective double submission checking system. The bank could extend the search capabilities for customers and thereby reduce queries to the bank. A double submission check would even be assigned to customers. Introducing the customer order reference concept would therefore be a win-win situation for both banks and customers. What more could we want?

Michael Lembcke