Notifications for incoming SEPA instant payments – an elementary part of the payment process chain

In addition to the short duration of a final real-time credit transfer, the immediate notification of the payment recipient about received payments is a core element of the SCT Inst payment process and the associated further process steps.

What is now well feasible in online transaction processing between consumers or in the merchant-customer relationship poses challenges for the players involved in the EBICS corporate field – as described in Michael Lembcke's blog article "Real-time notifications and EBICS – no more ‘hopeful queries’ for downloads": although transaction notifications have now found their way into Appendix 3 of the DFÜ Agreement, which will be valid as of November 2019, and are specified there as camt.054 messages that can be downloaded using EBICS order type C5N, they must be actively downloaded from the bank by the payment recipient. An active push notification of the payment recipient was so far not planned. In the meantime, however, this functional gap was filled by an extension of the EBICS specification – a notification based on the WebSocket protocol that is sent from the bank server to the customer. Thus transaction information can be downloaded shortly after the corresponding payment has been received. Unsuccessful "hopeful queries" are no longer required.

As a direct notification about the payment receipt also allows for faster and more efficient overall processes in the corporate field, the time has come to take a closer look at this important function.
The starting point of our journey into the instant notification world is the globalisation of society. Almost at any time and place in the world, digital services are available: increasingly in real time – "always on, always instant". In the past, process-related waiting times due to classic payment processes (which could take several days depending on the recipient country) and slow logistical processes during the dispatch of goods were the standard. Now, the progressing digitisation enables more and more continuous process chains without media disruptions and waiting times and ensures rapid growth in the area of new digital offers.

Some of the consecutive steps of the process chain cannot be easily migrated to the instant world, as there are procedural dependencies on the non-digital domain. Other steps, however, are already available 24/7/365 in the present day – and are sometimes even finalised within a few seconds. This includes, among other things, the ordering and the subsequent payment process.

The magic word here is instant payments. Instant payments enable an immediate credit booking of the payment amount to the recipient and thus can also allow for an immediate provision of the service after payment. What works in terms of digital products is more difficult in the mail order trade sector: although it is possible to speed up the overall process through a fast payment receipt at the merchant, direct availability of the ordered goods is difficult to achieve and the customer pays in advance for a short period of time.

A purchase on account would be the least risky option from the customer's point of view. However, it carries increased risks for the merchant/supplier, as they provide services in advance and it cannot be assumed that the outstanding claim will be settled in a timely manner. Advance payment by means of classic payment methods, including cards, only leads to a reversal of the risk position, but not to an optimal risk distribution between the merchant and the buyer. At present, this circumstance can only be dealt with by an intermediary who, as an authority trusted by both the merchant and the buyer, handles the handover of the goods and the payment process at the same time. No payment – no goods; and vice versa. Classic cash on delivery process.

What is the role of the payment recipient notification in this? Without immediate notification of the beneficiary about the received payment, accelerated processes and associated innovative products based on direct payment are unthinkable. Only by means of information for the beneficiary integrated into the payment process or directly connected to it can the underlying transaction be concluded or at least the next step in the process chain be taken – whether through an online process via an API provided by the bank, or by using the EBICS channel combined with a push service.

Up to now, transaction notifications have generally been sent via intraday account information (MT942 transaction report) or in the account statement (MT940) provided with a one-day offset. It is only due to the mandatory immediate response to an instant payment receipt, which is anchored in SCT Inst, that the payment process can be fully completed. This is particularly crucial for the use of instant payments at the POS. Long waiting times until the transaction is completed would prevent customer acceptance. The benchmark for this process is the duration of a card payment.

However, immediate notification is not only relevant at the POS: existing payment methods such as settlement of invoices via instant payments in online banking or the classic cash on delivery at the front door benefit from this. In the first case, the advantage lies in an accelerated overall process for all parties involved, and in the latter it is mainly the substitution of classic payment instruments such as cash or cards.

Notifications will also play a key role in the development of future payment procedures such as Request to Pay. In this context, I would like to refer you to another EBICS blog article dealing with this topic by my colleague Eric Waller: "Request to Pay is changing payments – first use cases".

Author: René Keller

Formatting errors in EBICS orders – test services can help

EBICS has been specifically designed for secure, high-performance data transfers with files of any size between banks and corporate customers. For payment orders, the content of a file that is uploaded to the EBICS server must match the defined business transaction (order type, FileFormat parameter or BTF) and the respective format specifications. When payments are submitted, collection files with single transactions grouped by ordering party accounts are common practice. The protocol creation (HAC and PTK) for server-side EBICS processes is partly format-specific for payment orders. The authorisation checks and the protocol creation therefore require that the EBICS bank server knows and can read the submitted format at least in the relevant places (for example, ordering party account and amount). In order to read the information, the EBICS bank server performs a format check. The EBICS bank server usually aborts the check as soon as the first formatting error is detected. The order is rejected due to the formatting error and documented in the customer protocol.
Why is the file not fully checked and why are the error details not written into the customer protocol?
There are several reasons for this. First of all, the usual service agreement for e-banking via EBICS includes the upload and fast processing of correct files. Extensive format verification with an error protocol is not included and also not the core task of an EBICS bank server. Furthermore, the bank server capacities are to be used for the immediate processing of format-compliant orders and not for the analysis of incorrect files.

But how can a bank offer its corporate customers a service that increases the quality of payment orders in terms of format and content without adding unnecessary load onto the EBICS bank server?
Customers could use test services such as the ISO 20022 test platform for this purpose. As part of the harmonisation of Swiss payments, Swiss banks already offer their customers a test platform for testing incoming and outgoing payment transaction formats.

The test platform mimics the specific production conditions of the bank. It can validate XML-based customer-bank messages and simulate the bank-to-customer interface.

An extension of the ISO 20022 test platform towards payment order checks for specific formatting conventions and content can improve the quality of the file even further. A comprehensive format verification of payment orders carried out in advance enables errors to be identified quickly and easily using a detailed error log.

Files that are invalid with regard to format and content can be detected and corrected in a preliminary check by a test service before they are uploaded to the EBICS server.


Authors: Aline Wendler and Michael Lembcke