EBICS payment receipt in real time – utopia or reality!?

Payments with FTAM or EBICS have been characterised by contradictions for over 25 years. Eve-ry form of communication was a one-way street, there was always only a technical acknowledge-ment and you could only be sure that everything had really worked when you had manually down-loaded and read through the customer log with a time delay. A comparison for the process could be a postal letter sent in a non-transparent envelope with the receipt of the answer by postal letter in any envelope. Even though the transmission was of course much faster than the classic postal letter.

Well, time marches on, the need for an answer within seconds and, above all, a qualitatively meaningful answer is taken for granted today. EBICS must also slowly (finally!) meet this demand and offer new mechanisms.

However, the previous procedure of reciprocal transmission of the order and its response must not simply be ignored or even discarded. Existing process sequences in EBICS have their proven right to exist, especially when it comes to transmitting very large amounts of data, which even today require several minutes for complete processing. It is precisely this capability that is still the out-standing feature of EBICS.

In spite of everything, it must also be possible in the future in the EBICS protocol to be able to send smaller amounts of data faster and above all with an immediate business response.

To be able to consider these future requirements, the EBICS protocol was extended to include the EBICS real-time messages. In this, a second bidirectional communication channel is set up between the customer product and the EBICS bank server. In the current specification this chan-nel is initially only used for ad-hoc messages from the bank server to the customer product.

In the future, this now existing communication channel can also be used for submissions and in-stant business processing in the banking environment. This instant processing can then also gen-erate the necessary return messages and immediately – similar to the online banking – display a qualitative return message to the user.

Currently, this submission format is still being piloted with special EBICS systems and is not gener-ally established in the market.

However, much more important than the above future scenario is the generally available form of asynchronous return messages to customer systems and their users, i.e. the corporate customers, which has already been specified for two years. This EBICS real-time notification is documented in the specification "Real-time notification" and can be implemented by all manufacturers. It offers unique opportunities to inform customers, i.e. corporate customers, quickly and promptly about all kinds of changes to their various accounts.

With this new capability of the EBICS protocol it will be possible in future to send a real-time mes-sage via EBICS to the customer and the customer system already at the time of booking. The EBICS infrastructure will then provide an interface for this which can be integrated into corre-sponding booking systems or it will also be possible to use any other text-based messages from other banking systems and thus always provide corporate customers with new messages. De-pending on the performance of the customer systems, many new interesting forms of application can be realised.

For financial institutions which do not want such a close coupling between EBICS and their busi-ness applications or for which integration is too cost-intensive, another option will arouse interest.
EBICS bank servers – such as TRAVIC-Corporate – can send an immediate message to the cus-tomer system(s) assigned to the customer each time data is provided, signalling that new data, e.g. an incoming account notification, is available.

This form of notification will generate interest i.a. among customers, especially in the context of instant payments. In the future more and more – regulated – payments will be based on instant payments and thus be executed quickly. This means that the payment receipt by the corporate customer must also be indicated immediately so that the goods or services can be delivered or provided quickly.

EBICS real-time notifications are the most important element of an instant payments solution over the entire process.

These messages are also structured in such a way that customer systems – such as TRAVIC-Port – can derive actions from them internally. Automated downloads of the data provided by the fi-nancial institution become possible.

And if EBICS real-time notifications become more and more established in the market, the many "hopeful queries" from customers – 80 to 90 % of account statement queries from customers are answered with "no data" – will no longer take place. Customers will rely on this new mechanism. For the operators of EBICS bank servers this means that they only incur consumption costs when data is actually available. This is an important savings effect for financial institutions, which means that their server systems are allowed to be smaller and are actually much less frequented.

However, the whole scenario can only gain momentum if financial institutions start to offer this service; waiting for the customer product manufacturers will not work, as they always only incorpo-rate changes into their products if there are actually suppliers – i.e. EBICS bank servers.

My appeal to the EBICS banks: Start the new service to use the next generation of the EBICS protocol for yourself and, above all, for the benefit of your customers.

Author: Michael Schunk