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
0 comments:
Post a Comment