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:
Michael Lembcke
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 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.
Michael Lembcke