Request to Pay (R2P) is changing payments – technical challenges

Our last blog entry on Request to Pay showed us how peaceful the Christmas season could be and how R2P could make all the associated shopping perfectly organised. Now it is still a while until next Christmas, which leaves us time to deal with the challenges of establishing R2P based payment systems.

The first aspect that warrants mentioning is the technical component. In December 2019, EBA CLEARING published format specifications that describe both the payment request (pain.013) and the response to the payment request (pain.014). Thus, the clearing part is technically defined and the "only" challenge left is to prepare the incoming and outgoing interfaces of the payment system for these processes and formats. This may sound trivial at first, but is in fact quite challenging for a payment system: both the outgoing payment request and the returning response to the request must be routed from a customer system through the payment system, the relevant clearing systems and the receiving and/or responding customer system within the shortest possible time.

This, of course, also raises the question of how customers should transport the payment request to their bank to begin with. The technical aspect is currently being discussed by the European Payments Council and the Deutsche Kreditwirtschaft (DK). A corresponding technical specification for the customer-bank interface will be created.

This is where the business component comes into play. It should involve a conceptual revision of existing systems with regard to which system shall accept incoming payment requests and which system shall respond to them. This leads to immediate follow-up questions; for example, if customers can choose whether they want to pay via SEPA or SCT Inst (provided they are given the choice at all by the design of the payment request). No less important is the question of how they shall authorise the payment request. Suitable authorisation methods are, for example, a mobile device with an established TAN system or a submission to the EBICS signature folder for signing via electronic distributed signature.

Meanwhile, information on a payment receipt from an instantly settled payment request can be provided rather easily thanks to the specified "Credit Notification for SEPA instant credit transfers".
With the right combination of technical possibilities, R2P will certainly give Instant Payments an immense boost. Admittedly, mastering the challenges along the way will require a considerable amount of effort, but in view of the numerous design possibilities, it will pay off if the implementation is handled correctly. Find out more about the application scenarios and use cases that result from the technical possibilities in the white paper "Request to Pay and its versatile applications" we created for you . Please also feel free to contact us any time for both content-related and technical discussions.

Author: Eric Waller

Read more

Multibanking – all in one portal

Standards as the basis for networked process automation

Data is the oil of the 21st century. For years this has been preached at all digital conferences. The more data a provider has from a customer, the better the customer can be clustered and classified into target group segments. This knowledge of the customer's needs allows the creation of interesting additional offers for them.

When, as part of the digitisation, the access channels are increasingly realised via the Internet, the decisive point of contact between financial institution and corporate customer will be "digital branches" such as the web-based corporate customer portal TRAVIC-Port. If the operator succeeds in aggregating all the customer's bank accounts, including those of other banks, at the digital point of sale and bundling them in an own portal, the operator has the best prerequisites for a holistic overview of the customer's payment transactions. The more accounts that are bundled here, the better service offers the operator can create for his customers.

The keyword "multi-banking" refers to this functionality of bundling the optimal payment transactions of a customer. Both sides - customer and financial institution - benefit from this combination under one roof. The customers are given a comprehensive overview of their transactions. The aggregation considers both submissions of all types of payments and downloads of the account information of all connected accounts. The multi-banking portal offers the users a unified, easy-to-use GUI for various payment providers using one secure access - and that way provides efficient internal processes. However, the benefit of this smooth automation of multiple payment transactions stands and falls with the speed of processing and the clean implementation of the bank servers from various providers. A high degree of networked transactions in both directions requires uniform interfaces and the compliance with the valid specifications. The EBICS-based communication of TRAVIC-Port provides the most secure, Internet-based, technical protocol for the SEPA area. All too generous adjustments and deviations from the specification prevent smooth processes on the part of the providers and stand in the way of a comprehensive, seamless consolidation of payments. Here, both the clients of the portal providers and the suppliers or software houses should pull together. In contrast, APIs with proprietary interfaces enable individual adaptation to the financial institution's technical environment. However, any deviation from the standards delays the smooth integration of the complex data traffic. An imprecise interpretation of the specification reduces the degree of automation and the data volume of each connection. The more gaps there are in the complex network of multi-banking connections, the lower the customer benefit and the quality of the analyses.

Guest author: Christian Veith

Read more