EBICS WebSocket

The obligation to provide active notification

One of the challenges that has arisen for banks as a result of the instant payment regulation is the obligation to provide active notification of the execution of the real-time payment:

In addition to the actual legal text, the EU has also published some information in a question and answer document¹.

In the so-called DG-FISMA questions² , at least one bank asked explicitly about EBICS:

Question 48: With regard to informing the payer, is it sufficient to make the information available to the payer to be collected at his discretion (like it is done today in case EBICS is used) or does it have to be actively sent?

In response, the EU provides the following:

With regard to informing the payer on whether the amount of the payment transaction has been made available to the payee, Article 5a(4), point (e), implies an ‘active’ provision of such information by the payer’s PSP to the payer as the payer is not expected to look for it at the end of 10 seconds while he/she is making a purchase at the POS.

The bank that asked this question was obviously fully aware of the EBICS problem: With EBICS, the customer always initiates the communication and terminates it again immediately after data has been sent or retrieved. It is also always the customer who starts and ends this communication. The bank only has the option of providing information, but cannot push it to the customer on its own initiative.

So the bank is right to ask: Is it sufficient if we only provide the customer with information about the execution of the real-time payment?

Up to now, account statements have also only been “made available”, as have the processing protocols PTK, HAC or pain.002. In most cases, a well-organized EBICS customer with a professional EBICS connector has a scheduler in use that retrieves account statements at a certain time in the morning or PTK/HAC or pain.002 a short time after the payment file has been sent. The customer does this out of self-interest and without any active indication from the bank that something is ready for collection. It is therefore not necessary to indicate that this information is available.

In addition, it appears that DG FISMA did not really address the specific EBICS procedure case: The bank explicitly wanted to know how to proceed when using EBICS. However, the answer seems to refer to a purchase transaction at the point of sale (PoS).

Standing at the checkout and paying, you may find DGFISMA’s answer correct: One should not be forced to open a banking app after a payment to check whether the payment has been made or not. For this purpose, you receive a push notification via an app that this has been done, which is in the spirit of the IPR. However, EBICS has nothing to do with the PoS.

In our opinion, an EBICS customer should not have to be informed that there is information for collection, as – as mentioned above – they can use a scheduler to automatically collect such files. Nevertheless, the IPR now requires EBICS banks to actively notify their customers about the execution of the real-time payment. However, as already described above, this is not possible via EBICS for technical reasons.

The solution to this may lie in an EBICS offshoot, which the DK (Deutsche Kreditwirtschaft, an association of the central associations of the German banking industry) has included as a new Annex 2 to the RDT agreement since July 2020: EBICS WebSocket.

EBICS Websocket is a technology that is used in connection with the EBICS standard to establish a direct and permanent connection between a bank customer and their bank.

Normally, EBICS communicates via standardized HTTP or HTTPS connections. With WebSocket, however, this communication is possible in real time and bidirectionally. This means that both the customer’s client and the bank’s server can exchange data at any time without having to constantly establish new connections. It is particularly useful when continuous monitoring or immediate reactions are required, or even for “active notification”.

Necessary changes for the use of EBICS WebSocket in the bank

In order to be able to use WebSocket, the bank must set up an EBICS WebSocket server in addition to the EBICS server.

The Web Security Services (WSS) access data must be created in a defined JSON format. They can then be provided to the EBICS server. In addition, the bank must ensure the necessary number of potential connections and offer the corresponding bandwidth. The push notification to the customer is triggered by JSON messages when new data is available on the EBICS server. Finally, the WSS authorization must be assigned to the customer and participant on the bank computer.

Necessary changes for the customer to use EBICS WebSocket

To be able to use EBICS WebSocket, the customer must use a WebSocket-capable electronic banking program which must be able to execute the WSS order type. The system must also understand the supplied JSON structure from the EBICS response and be able to establish the permanent WebSocket connection from it.

The software must also be able to interpret the push message and derive the necessary actions from it, such as downloading the pain.002 file.

Structure of the WebSocket connection³

The structure of the EBICS WebSocket connection is shown in the following graphic with the individual actions numbered in chronological order and shown in different colors for the different spheres (blue = EBICS, red = WebSocket, green = interaction between EBICS WebSocket and EBICS in the customer sphere):

Notification process⁴

The following graphic shows the notification of an incoming real-time credit transfer as an example of a real-time notification. Here, too, the individual actions are numbered in chronological order and shown in different colors for the different spheres (blue = EBICS, red = WebSocket, green = interaction between WebSocket and EBICS in the customer sphere or in the bank sphere):

Transmission data

The bank’s push message to the customer does not transmit the actual data, for example the pain.002 or the camt.054 itself, but only the information that such a message is available for collection. The actual transfer of the message then takes place via the traditional EBICS interface. A good electronic banking system on the customer side can interpret the push message and then collect the file independently.

WebSocket for real-time incoming payments

EBICS WebSocket is currently not very widespread, neither on the bank side nor on the customer side. This may change with real-time payments. In addition to the bank’s new obligation to inform the customer about the success or failure of the real-time payment, the initial reason for the inclusion of this standard in the RDT agreement may come into focus: the notification that a real-time payment has been received.

Until now, corporate customers only had the option of regularly picking up camt.054 in the hope that information had been received in the meantime. In principle, this resulted in unnecessary traffic on the lines. With the WebSocket solution, there is a push message which then triggers the retrieval of the camt.054 message. EBICS communication is therefore only established if it is ensured that something is available for retrieval.

The obligation of active notification in the IPR

Even if WebSocket is not yet widely used, it is sufficient from the bank’s point of view if “active notification” in the sense of the IPR is offered. Banks do not have to ensure that all customers use WebSocket. The offer to actively provide this information via WebSocket is sufficient. Other acceptable forms of notification could also be a notification via e-mail or an Internet banking platform that can send push messages, or an SMS service. In addition, it would have to be defined in advance who should receive these messages from the customer.

Not offering the option of active notification of the execution of real-time payments could be fundamentally risky because it is a clear violation of the instant payment regulation.

Here, too, the banks were instructed to offer the active notification service free of charge for the account holder, while the implementation of the above-mentioned infrastructure causes considerable costs and additional administrative work for the bank.

Further challenges

There are other challenges that cannot be conclusively clarified here. But perhaps these will be decided over time by the banking associations or the courts:

• Does the bank have to ensure that the push message actually reaches the customer? For example, the customer could only receive such messages if their e-banking account is also open on their digital device.
• Is it sufficient if a customer user receives this push message or is administered for it? But what if this user is absent and therefore not currently working?

Conclusion

In practice, an EBICS customer does not need active notification of the execution of the real-time payment, as a scheduler can regularly check whether the corresponding data is available. It is questionable whether many customers will invest in EBICS WebSocket for this purpose.

The situation is different with a push message for incoming payments. As there was no prior activity on the part of the customer – after a payment, you know that a payment status report should be sent after a certain time – the information makes more sense here. However, a scheduler that “checks” with the bank every 15 minutes could also be used here.

Banks and software providers should therefore invest in EBICS WebSocket now in order to be able to operate IPR-compliant in the long term.