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

Initial difficulties in onboarding Swiss EBICS customers

In earlier posts we reported that the spread of EBICS in Switzerland has already begun. The first credit institutions have since started to offer the multibank-capable standard, with others still in negotiations. The focus is now slowly shifting towards corporate clients, who would benefit from the new interfaces. More precisely, the focus is now on the EBICS software to be installed on the client's end.

The first survey at the beginning of this year in the Swiss software development community for the support of EBICS in their clients' products, was thoroughly positive. The majority of suppliers has already implemented EBICS as protocol and can maintain productive links with both of the large banks. In order to allow customers to easily switch to another interface, some software solutions offer the so-called EBICS profile in their installation programs for each institution. Before initialising the installation, the customer decides which bank they want to connect with and the program automatically verifies key connection and configuration parameters according to the institution (version, EU procedure, host name, certificate issuer, supported order types, URL etc.).

If the customer then wishes to connect to another bank which also offers EBICS, they often need a new software version which, in accordance with the procedures just mentioned, will include the configuration specific to the institution. The once customer-friendly setup at once becomes much more complex; who wants to update the entire system each time you connect to a new bank? At this point a configuration-based approach would be desirable, in which the customer can register for themselves the relevant EBICS parameters for the new connection.

If the developer still then charges release fees for these updates, one cannot help feeling that there is profit being made here at the customer's expense from a relatively trivial problem. It is now the role of the banks to provide an overview for all the available solutions and to ensure this information is included in the counselling of clients, when it deals with the question of which EBICS software would be the most suitable for connecting to a specific institution.

For Swiss developers who have not installed an EBICS protocol, here is a final tip: Configuring a new EBICS connection should not be rocket science if it is ensured from the beginning that, for example, the customers themselves will control the process using a dialog window. For the integration of the EBICS protocol, we make reference at this point to the PPI EBICS-kernel (see software modules on the PPI homepage), which provides the full range of EBICS functionality in the form of a software library.

Carsten Miehling