XS2A without third-party providers – well, why not?

As part of the PSD2 an interface for third-party service providers (XS2A API) was introduced across Europe. As the initiator, the EU aims to open the access to the customers' bank accounts to third parties and thus wants to promote competition in the market. By the due date on 14/09/2019 the XS2A API was put into operation by the financial institutions in Europe. Since then, market participants have been reorganising, adjusting the XS2A API to the needs of stakeholders and working intensively on services for both consumers and companies.

As a regulatory must-have, the XS2A API is initially a cost factor for financial institutions. However, value-added services have been considered right from the start and have already been specified by the Berlin Group, for example, in order to provide financial institutions with a source of income. But in the current API hype there are no limits to the fantasies about the sources of income.

So we are riding the hype wave for now and imagining the XS2A API as an alternative access channel for companies. And why not? From a technical point of view, the hurdles should be low. A company could identify itself as a third-party service provider by means of an eIDAS certificate. The certificate would only differ in the specific fields for third-party service providers. Similar to EBICS, submitted orders or enquiries can be provided with a signature which the recipient can use to check the integrity of the message. A secure transport channel is guaranteed by the use of TLS.

From a business point of view, you can use the use case "Initiate payment" to execute both individual and collective payments. For the release, consumers are offered the usual authorisation procedures known from online banking (e. g. photoTAN, pushTAN). This would probably be unsuitable for companies. Therefore, the use of corporate seals would be more likely, which has to be specified. The query of account information (balances, transactions, details) is also possible via the XS2A API. In this particular case, where a relationship of trust exists between the company and the financial institution, the consent required for this could be given via a permanently valid consent.

Seen from an average vantage point, the XS2A API would thus be a valid alternative, which is already being considered in various forums. Here, the idea is assigned attributes such as "cheaper, more convenient, real-time capable and more flexible in adjustments". However, the status quo brings us down to earth. The defining specification of the Berlin Group gives the financial institutions a lot of freedom to implement the API. In the effort to reach all financial institutions in Europe via XS2A, this freedom is currently a challenge for all market participants. A state that is not inviting for companies, not yet. However, the foundation for an alternative has been laid.

Author: Christian Wenz

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

Request to Pay is changing payments – first use cases

The payment request or, in business terms, Request to Pay (R2P), is a new payment instrument that is set to change payments for the long term. In the whitepaper “Request to Pay completes the electronic payment process”, I have already explained the relation between electronic billing, instant payments and the hitherto missing payment instrument Request to Pay.

I will use this blog entry to present the first few of many use cases which can be easily addressed to an existing bank account via Request to Pay:

  • Request to Pay in case of an already sent commercial invoice: an easy use case is that the invoice has already been sent in a classic way and a Request to Pay is additionally sent afterwards. This use case primarily focuses on speeding up the settlement of the due invoice by facilitating the invoice data processing for the debtor. The Request to Pay related to the invoice that the debtor has already received is displayed to him in his online or mobile banking application with the recipient data, the payment amount and the remittance information already filled out. The debtor only needs to confirm the data and sign the execution with his credentials.

  • Request to Pay combined with a commercial invoice: of course, the previously described use case is also conceivable if both an electronic invoice and the associated Request to Pay are to be presented to the debtor at the same time in his online or mobile banking application. The conventional postal dispatch is thus eliminated and the debtor can view his invoice digitally and pay it in a simple manner. This method also offers the option to digitally store the invoice in a banking archive and to digitally match it with a payment at any time.

  • Request to Pay in step-by-step transactions: needless to say, Request for Pay is useful for more than just scenarios with separate locations. It is thus also conceivable to digitise the previous cash on delivery method. The supplier addresses a Request to Pay message to the recipient who then verifies the product delivery and initiates an instant payments order as response to the request. The supplier is informed via a notification that the payment has been received and releases the product.

  • Request to Pay in stationary trade: similar to the previously described case, Request to Pay could also be used with instant payments and notifications in stationary trade. In this case, it is not the invoice but the purchase receipt that is transported with the Request to Pay message and can be stored in a digital archive at the account together with the booking. The cashier personnel release the purchase only once the notification has come in.

As demonstrated, payment requests are applicable in many sectors and I therefore believe that the new payment instrument Request to Pay is bound to change payments as we know them on a lasting basis. I will continue to post frequent updates on current developments and additional use cases on this blog.

Author: Eric Waller

Announcement: Extension of PPI’s EBICS blog – all about payments!

Dear readers,

We are pleased to inform you today about the extension of our EBICS blog.

In the PPI EBICS blog "All about payments" we would like to keep you up-to-date about current payment trends and topics concerning EBICS, SEPA, SWIFT, regulation and digitisation.

From now on the EBICS blog is maintained by two teams of authors in a 2-week rhythm. Our goal: to give you a first-hand account of the views and experiences of our product and consulting experts from customer projects, studies and white papers with regard to current and future requirements of the payments market.

We look forward to your feedback and hope you enjoy reading this blog!

Your team of authors at PPI

Real-time notifications and EBICS – no more "hopeful queries" for downloads

As I already wrote in my blog post in December 2018, real-time credit transfers (instant payments) in the corporate customer business are making their way into the world of EBICS via the new bulk format. When uploading real-time credit transfers, the EBICS transfer phase is not subject to the strict synchronous time rules of instant payments. The clock starts ticking only after the EBICS bank server processing.

But what about the opposite direction for instant payments business transactions in EBICS? After all, a credit notification, if not possible in real time, should still be sent to the payment recipient as soon as possible. In the standard role relationship between customer and bank, the EBICS client always downloads the information from the bank server. An active provision by the bank via EBICS is not intended. Especially the business community has urged the banks and the German Banking Industry Committee (Deutsche Kreditwirtschaft) to find a pragmatic solution for a push option. The ultimate goal was to develop a solution that could be implemented without the need to change the EBICS protocol and the role concept.

The result was the idea to create a new web socket-based standard interface that informs EBICS clients when new information is available for download. This also includes information about a newly available credit notification. This new push channel is thus not used to transfer any sensitive data. The download of the relevant sensitive data is still carried out via the secure EBICS channel.

In the meantime, the Deutsche Kreditwirtschaft has described this new interface in the "Spezifikation Echtzeitbenachrichtigungen" (specification for real-time notifications) and published version 1.0 on July 18, 2019 on the German EBICS website (www.ebics.de).

Now the interface must be implemented in the EBICS clients and EBICS servers in a standard-compliant and timely manner. This development opens up new possibilities for optimising corporate customer business, even independently of instant payments. For example, the frequent and ongoing "hopeful queries" by automated EBICS clients (as performed in case of account statement downloads) can be eliminated for all download processes. This means that both EBICS client users and bank server operators can expect a load reduction. That's good news, isn't it?

Author: Michael Lembcke

Is the EBICS protocol exempt from strong authentication (SCA) in line with PSD2?

We have been asked this question repeatedly by French and European financial institutions and it has not always been easy to give a sufficiently formal answer.

Recently, the Banque de France wrote an official reply in which it added the EBICS protocol to the list of procedures and protocols exempt from strong authentication under Article 17 of the delegated regulation (UE) 2018/389. The regulation states that: "For legal entities initiating electronic payment transactions through dedicated payment processes or protocols that are available only to payers who are not consumers, payment service providers may waive the requirement of strong customer authentication where the competent authorities consider that such processes or protocols provide at least a level of security comparable to that provided for in the directive (EU) 2015/2366."

The full text can be found on the following page: https://www.banque-france.fr/stabilite-financiere/securite-des-moyens-de-paiement-scripturaux/2eme-directive-sur-les-services-de-paiement
However, this does not mean that EBICS does not support strong authentication - far from it! The certainty that the EBICS protocol guarantees at least comparable levels of security to those provided for in the directive has long been established. With this in mind, I would like to invite you to read or re-read the article EBICS and PSD2 – How do they work together? published on this blog a few months ago.

Author: Marc Dutech