Request to Pay – a revolution without revolutionaries?

Technically, the European payments market could be in a mood for celebration - after all, the first concrete regulation for a pan-European electronic payment request came into force on 15 June 2021. The SEPA Request to Pay (SRTP) Scheme Rulebook defines the parameters for all participating financial institutions. Once this system is set up, companies simply send their customers a digital data record with the details of the payment request. The payers can transfer the included information such as IBAN, sum or remittance information into their banking system with a mouse click and then only have to authorise the transaction. 

Few reactions

Experts see RTP as a potential revolution in the European payments market. However, the participants for the revolution have been lacking so far. Efforts to launch products based on RTP are hardly discernible. The question arises as to the reason for this reluctance. Are financial institutions worried about a lack of demand? Is the implementation too complicated or too expensive for them? And what can help financial institutions if they want to launch SRTP products?

There is no lack of interest

The demand is there among the ultimate addressees, i.e. the private and corporate customers of the banks, at least on the business customer side. A survey by the European Banking Association (EBA) in cooperation with PPI clearly shows this. Regardless of which potential application scenario European companies were asked about, the willingness to use RTP in their own company was generally well over 80, sometimes over 90 per cent.

Manageable effort

Of course, a new payments standard does not come for free and cannot be implemented overnight. If a corresponding project is approached with the classic waterfall methodology, a duration of 18 to 24 months is to be expected. With modern means such as agile development, however, this period can be shortened. The key is to have a clear strategic idea of what an RTP product should be able to do. Furthermore, it must fit into the long-term business plans of the financial institution. The actual costs depend on the specific circumstances. But they are likely to be similar to those of an instant payments introduction. Institutions that have already introduced this service have advantages, because some of the important aspects for RTP have already been taken care of. They then only have to apply about 30 to 40 per cent of the mentioned cost framework.

In any case, the investment should pay for itself quite soon. After all, RTP products and services strengthen customer loyalty and can help institutions win back market shares. Especially since at least no major player has yet announced plans to enter the RTP market. 

Launch the first projects soon

Financial service providers should definitely take advantage of this. Minimum Viable Products (MVP) are suitable for a quick market entry. An alternative is cooperation with one or more business customers. Companies in particular should have a strong interest in RTP, as the use of the standard can save considerable sums in billing process costs.

Sooner or later, an entire product world will emerge around RTP – that much is foreseeable! Institutions that enter the new market early on can look forward to this development with joyful anticipation. We are happy to support financial service providers with the implementation. We have summarised the basics in the latest white paper "How Request to Pay becomes a success story for financial service providers", which is available for free download here.

Authors: Eric Waller, Anuschka Clasen

Read more

Digitisation of the account life cycle? Simple with eBAM and EBICS!

B07? B13? Though these designations may look like airport gates for an upcoming flight, they mean something else.

Perhaps you have already seen them in the planned changes for the BTF to order types mapping table of DK (Deutsche Kreditwirtschaft). They refer to two of the business transactions for Electronic Bank Account Management (eBAM) newly introduced in 2021. In a previous article, we already discussed the topic eBAM in general and argued in favour of standardised use within the framework of the RDT agreement.

eBAM provides messaging for account opening, management, closure and reporting. The focus is on an existing customer relationship. Otherwise, there would be additional challenges to consider.
eBAM combines concrete potentials for account management in the corporate customer sphere. Manual activities, media discontinuities and a generally paper-based procedure are currently predominant there. Opening an account or changing a power of attorney means a great deal of effort on both the customer's and the bank's part and takes days or even weeks to complete. Not to mention the lack of standards across different banks.

Electronic Bank Account Management enables the digitisation of account management processes. As shown in the figure, the paper-based processes and media discontinuities are replaced by standardised ISO 20022 XML formats (acmt.*), which are exchanged between the corporate customer and the financial institution via an electronic channel. The prerequisite is that essential bank and account master data, powers of attorney and other documents are managed in appropriate systems of the corporate customer. Document attachments and digital signatures are also supported, as these may be required in certain cases.

There is no need for a new channel, as the eBAM messages can also be transmitted via EBICS. In addition, they are already authorised in the EBICS channel. Such processes are well-known and well-established in payments, e.g. in the transmission of credit transfers and status reports. Transfers via other channels is also conceivable.

Within the institution, the necessary processing can be carried out faster and more efficiently through automated support. 

A few financial institutions have eBAM offerings on the market, but some of them are limited to individual use cases or channels. On the other hand, corporate customers such as the treasury departments of large companies are clearly interested in precisely this kind of digital account management. In particular, they want to have a better overview and reduced processing times, and at the same time manage their accounts with ease.

There are also great advantages for the financial institutions. The complexity of IT and processes can be significantly reduced and process costs lowered. 

eBAM has various points of contact in the business and IT areas, which means that questions have to be considered holistically during concept creation and implementation. This also applies to related topics such as KYC (Know Your Customer), electronic signatures, regulations or process management.
For the implementation of eBAM in IT systems, it must be considered which tasks are to be carried out in the bank server and which in the downstream systems. What should be taken into account with the new formats and their current and future versions? How can message validation and feedback generation take place? How are eBAM messages processed and transferred to the master data systems?
Based on the TRAVIC product suite, PPI can offer financial institutions the appropriate functionalities to facilitate the introduction of an eBAM offering. This includes the acceptance of messages in the EBICS bank server TRAVIC-Corporate as well as the central processing in a specific eBAM component at the interface between TRAVIC-Corporate and the downstream systems. Web-based account management in the corporate customer portal TRAVIC-Port equally offers potential for a dedicated eBAM offering. And via real-time notifications, the TRAVIC-Push-Server could be immediately notified of important events.

By offering technical and business expertise from a single source, PPI can provide holistic support for eBAM introduction on request.

I am convinced that the importance of eBAM will continue to grow. Those institutions that act early will be able to secure timely market advantages through innovative offers.

What do you think?

Author: Thomas Stuht, D.Eng.

Read more