SEPA Request-to-Pay – Innovation driver or a castle in the air?

• The growth of e-commerce and POS non-cash payments has accelerated significantly; in particular, established international card organizations and closed loop platforms have benefited from these developments
• Various attempts have already been made to establish alternatives for everyday payments in the SEPA area - so far, however, with limited success
• Outside the SEPA area, however, there are successful solutions enabling payments, initiated by the recipient requesting for conventional account-to-account transactions
• The European Payment Council (EPC) has recognized the relevance of such payment requests for the SEPA area as well, and has been coordinating the introduction of a framework and rules for Request-to-Pay (RTP) since 2018
• Embedded in an end-to-end payment instrument, RTP could offer advantages for end customers and merchants, as well as for banks, especially in terms of cost and convenience
• In addition to the classical chicken-egg dilemma, various other challenges can currently be identified that could case respective players to hesitate in product development; for example, unclear chargeback regulations or the currently limited market coverage of instant payments
• However, these challenges could dissipate in the short term, provided that the European Commission's measures proclaimed in the EU Retail Payment Strategy are implemented
• All in all, an RTP standard has a considerable potential to change the market power structure, even if sustainable success requires haste, since the competition is already actively shaping solutions
  
   

The trend towards cashless payments is uninterrupted and will be further strengthened by the COVID-19 crisis. While 46.5% of retail sales in Germany were still conducted in cash in 2019, this figure is expected to be only 41.2% in 2020 - a significant reduction within one year, considering that the share of cash payments decreased only by 1.4% per year on average between 2009 and 2019. However, the increase in non-cash payments is not evenly distributed across the different payment instruments. While the share of SEPA direct debit, for example, has also declined (-3% from 2019 to 2020), the share of card payments has increased by 7.4% within one year to 49.6% in 2020. Although a large part of this increase is attributable to the Girocard, the international schemes can nevertheless be identified as major profiteer of this development. This is because even the Girocard depends on co-badging with international card organizations and more and more institutions in Germany are issuing a debit Mastercard or Visa Debit instead. The resulting dependency as well as the outflow of value creation and data in the strategic sector of payment traffic has already been analyzed in the paper "The Retail Payments Strategy of the EU Commission".

Strong efforts have been made in recent years to strengthen the European payments market, e.g. by opening up competition in the payments industry to non-banks as part of the Second Payment Services Directive (PSD2) and by creating interoperability through the introduction of further SEPA standards (e.g. SEPA Proxy Lookup or SEPA Instant Credit Transfer). However, this does not seem to have had any significant impact on the shares of everyday payments at the POS or in e-commerce yet. For instance, only about 7.5% of all credit transfers in the SEPA area will be processed in real time in 2020, even though the SEPA Instant Credit Transfer Scheme has been active since the end of 2017.

However, examples from India and Thailand show that this is possible and advantageous for instant payments to gain traction in a market. Unlike the payment card system, where the merchant is essentially granted the right to receive a certain amount from the customer, India and Thailand have each launched real-time payment systems for interbank transactions enabling retail payment solutions. Based on this, the beneficiary (generally, but not exclusively the merchant) has the possibility to send payment requests to their payers (e.g. customers), through which the desired amount is transferred after confirmation by the payer. In India, banks connected to the Unified Payment Interface (UPI) launched in 2016 can use their own customer app for this purpose, or use third-party apps (e.g. Google Pay, WhatsApp Pay and many more). Thereby, approx. 2.2 billion transactions have been processed in November 2020 alone.

Request-to-Pay (RTP) is developing into a collective term for digital payment requests through which, after confirmation by the payer, a transfer is triggered on the basis of the data contained in the request. To foster the use of interbank transactions in the SEPA area and to offer customer-friendly use cases on this basis, the relevance of request-to-pay was recognized, and a working group was formed with the so-called multi-stakeholder group. With the publication of an RTP framework in November 2019, this group defined the solution space and concretized it with the publication of a set of rules in November 2020, whereby care was taken to address the broadest possible number of use cases (e.g. payments at the physical point of sale or in e-commerce). The RTP Scheme does not primarily pursue an economic interest, i.e. no license fees are due for its application. Figure 2  shows the simplified process flow and its main characteristics.

During the identification process, it must be ensured that the beneficiary is given the reference of the payer (e.g. the IBAN or a proxy such as the email address or mobile phone number). The beneficiary then formulates their request, which contains mandatory data such as the amount, the expiry date of the request, the requested initiation date of the payment or the desired means of payment (e.g. SCT, SCT Inst., local CTs or high value payments). Furthermore, the beneficiary can fill in optional fields, for example to convey special payment conditions (e.g. the payer can be given the option to choose a higher or lower amount, for example to allow tipping the cab driver or payment of a reduced invoice amount due to item returns) or to attach documents (or their reference). This request is then forwarded to the payer's RTP payment service provider via the beneficiary's RTP payment service provider (their bank or a service provider contracted by his bank) and displayed to the payer in his customer application (e.g. mobile or online banking). The payer now has the option of accepting or rejecting the request (or even changing the amount if previously parameterized), which is confirmed to the beneficiary by sending a status report via the RTP payment service provider. If the payer has agreed to the request, the RTP payment service provider initiates the payment according to the means of payment requested by the beneficiary.

However, the RTP rules themselves only include a standard for the RTP messages, which are to be processed by the RTP payment service providers in near-real time, 24/7/365. How exactly the identification is done, e.g. by scanning a QR code, entering an email address or with an iris scan, is entirely up to the RTP payment service providers and their creativity in developing a solution. The payment itself is also not addressed in the RTP regulations - here, for example, reference is made to the existing regulations for the respective means of payment like SCT Inst.

The RTP scheme offers great potential for merchants: simplifying the payment initiation process for the customer (manual entry of payment data during the transfer compared to fully automatic payment initiation based on data transmitted by the merchant) will have a positive effect on payment behavior for invoice purchases and thus on the effort required for manual payment tracking. Since purchases on account are still very popular with customers in the DACH region and they also appear attractive for merchants from a financial point of view - at least when purely considering the direct costs - an RTP-supported purchase on account could be interesting for many retailers, especially since the invoice document (or its reference) can be transmitted via the protocol. Furthermore, RTP in combination with instant payments would have the additional advantage of a faster inflow of liquidity, which might be particularly interesting for online merchants with on-demand supply chains.

However, everyday payments at the POS based on the RTP would also be conceivable, especially since self-checkout solutions and even concepts for cashier-less shops (invisible payments) have been increasingly observed in recent years. For example, in the first stage, the customer could scan their goods themselves with a smartphone, followed by an (automated) RTP sent by the merchant at the end of the purchase. The customer pays with their smartphone via instant payment and simply walks past the checkout when leaving the shop. Down the line, it would also be conceivable that the customer would no longer have to scan the goods themselves, similar to "Amazon-Go", but would simply take them from the shelf and a corresponding infrastructure would recognize which products the customer has packed. When leaving the shop, the customer would then receive an RTP, confirm it (or this can also be done automatically via a rule-based approach enabled by the bank), so that a corresponding exit opens. The time savings for the customer and the possible reduction of manual efforts for the merchant would be significant. A positive side effect would be that the merchant would also fulfil the obligation to provide a receipt if it is transmitted electronically.

Although such solutions can in principle also be implemented with cards or direct debits, these have essential disadvantages compared to an RTP-based solution: direct debits are favorable for the merchant when considering the direct costs only, but customers can object to the amount for up to 8 weeks, which means corresponding risk models and thus costs on the part of the merchant. Mandate handling is also complex for merchants and often not very convenient for customers.

For card payments, it must be noted that the payment initiation via app or in the background would be a so-called card-not-present (CNP) transaction. This not only incurs significantly higher costs for the merchant than a conventional card payment at the POS, but also the implementation of strong customer authentication via 3-D Secure is likely to have a negative impact on the reach and convenience of such solutions. Especially, as the Girocard, currently the most widely used card in Germany, cannot be used for CNP transactions.

RTP therefore offers merchants opportunities to enable simpler and faster purchase on account, to design leaner checkout solutions in the POS business and to save costs at the same time. In the future, it is also conceivable that large merchants with the corresponding development capacity can completely free themselves from the need for an acquirer/PSP through RTP.

Banks can take on two different roles within the framework of the RTP. On the one hand, banks would have to provide the customer interface to the end customer, which makes it possible to receive requests and initiate payments after authentication. In this respect, banks can make use of the existing online and mobile banking as well as already implemented procedures for strong customer authentication. Opportunities arise from the additional customer contact points at the customer interface and the resulting cross-selling potential. The RTP could be the missing link for banks to turn online banking into a one-stop-shop for payments, covering use cases from direct payments, e.g. at the checkout, to delayed payments, e.g. an on-account purchase. In this context, the security perception of payments initiated by the RTP is likely to be superior to conventional means of payment through authentication. Banks that manage to create an above-average customer-friendly user experience in the context of authentication can also positively differentiate themselves from the competition and thus promote customer acquisition and retention. In addition, a wide variety of value-added services could be linked to RTP payments (e.g. archiving solutions for invoices and warranty certificates, offering instalment payments, tax management, and much more).

In addition, banks could position themselves as service providers for the merchant. In this case, banks would be involved both in the creation and validation of the RTP and in the processing of incoming payments. While today merchants are usually paid out daily or weekly by the acquirer, in an RTP solution the sales would be received individually on the merchant's account depending on the setup. However, the allocation of the multitude of cash receipts to the individual payment transactions (so-called reconciliation) becomes a more complex and time-critical undertaking, which banks could in return offer as a service. Banks could also offer merchants additional services such as "buy now, pay later" offers or payment protection insurance for non-instant payments.

However, the intended degrees of freedom of the RTP framework are likely to pose challenges for banks, merchants and their service providers in the context of product development. For example, it does not address how a refund could work if, for example, a customer returns part of the goods to the online merchant; in this case, would the customer simply formulate an RTP for the remaining amount to the merchant - if so, would this mean that every RTP payment service provider would have to be able to accept as well as formulate and send payment requests? And would this in addition require a regulatory legal framework that protects consumers? Alternatively, the merchant could simply remit the outstanding amount to the customer, and the merchant would have to match the return to the original incoming payment to find the customer's IBAN.

Further ambiguities exist in use cases where merchants are dependent on a short-term confirmation on the customer's payment, for example, to let the customer walk out of the shop with the goods. On the one hand, this means that the end-to-end process (identification, processing of the RTP, payment initiation) must be conducted at a sufficient speed. On the other hand, this requires that the confirmation sent to the merchant is resilient in the first place. Whether the RTP status report, which essentially comprises the feedback on the acceptance or rejection of the payment request, fulfils this purpose is, however, questionable. This is because it is currently not clearly regulated whether the payment initiation must already have taken place at the time the RTP status report is sent out. Accordingly, the payment confirmation in the RTP status report cannot be equated with a payment guarantee for the merchant. If this solution is used for check-out transactions, a different interpretation is required, and here the use of instant payments in particular can be helpful, as the need for a payment guarantee might become obsolete due to the immediate receipt of funds on the merchant's account.

Another area that has not yet been conclusively defined is payment accounts with more complex structures, such as those of corporate clients: These often require several authorized persons per account, often even with separate limit lines. In order to integrate the RTP into the electronic billing processes and solutions for this target group, the banks would have to make the necessary adjustments.

In addition to product-related challenges, the SEPA RTP will ultimately stumble upon the chicken-egg dilemma. Only with a critical mass of participating European merchants would RTP become a "must-have" for banks and thus end customers. Merchants, on the other hand, will only offer a solution if there is sufficient customer coverage. And even if all users of online and mobile banking would be eligible for the use of RTP, banks would first be forced to invest in the development of a corresponding product offering. In addition, the penetration and scaling of instant payments will be an important piece of the puzzle for the overall success of the RTP scheme.

An important lever for overcoming this dilemma could ultimately be the question of costs: empirical evidence has clearly shown that payment solutions that create transaction costs for the payer are not successful. At the same time, banks incur expenses for the implementation and operation of an RTP solution, which, following this logic, cannot be compensated through revenues on the end customer side. Furthermore, compensation for cannibalization costs, e.g. for interchange in card payments, would have to be ensured. If income has to be generated for the banks, it will have to be collected primarily from the merchants. One possibility here would be that, analogous to the interchange for card payments, the banks retain a portion of the transaction amount to cover their expenses. However, in addition to a technical solution, this also requires a contractual basis and since merchants must also have a financial incentive in the form of cost reductions compared to the status quo, the leeway is limited and highly political, since the interchange fee was deliberately capped with the MIF Regulation. By eliminating an acquirer and a commercial scheme in the value chain, it should still be possible to cover the expenses for the banks and still achieve a price reduction for the merchants.

The fact that pursuing an RTP approach is worthwhile is proven by various organizations which are already working on their own solutions or preparing an integration:

After an intensive test phase, Pay.UK's Request-to-Pay (R2P) framework was launched in May 2020, aiming to digitize invoicing and related use-cases, making them more customer-friendly. The main difference to the SEPA RTP is the message exchange, which is carried out based on open APIs. With Vocalink, now a Mastercard subsidiary, and Answer Pay, Pay.UK's R2P already has its first official participants. In this context, Vocalink, for instance, offers a wide range of functions and services. Starting with the provision of a routing service for payment requests between the connected merchants and customer applications, Vocalink offers a white-label merchant application as well as solutions for flexible customer management.

Deutsche Bank is also working on an API-based RTP solution in which it takes on the role of a Payment Initiation Service Provider (PISP) and transmits payment initiation APIs to the customer's bank based on PSD2. After authentication of the customer, which can be done via Deutsche Bank (with subsequent validation by the customer's bank) or directly via the bank's customer application, the payment to the merchant is processed by the customer's bank. The integration of this payment solution into the e-commerce check-out is currently offered by the Dutch payment service provider MultiSafepay.

In addition, in July 2019, SWIFT published a proof of value demonstrating that an RTP solution offered under a SWIFT gpi (global payments innovation) SLA could provide a more flexible, secure, and cost-effective alternative for corporates to collect cross-border payments. To evaluate any implementation requirements, a working group of representative gpi member banks and corporates has been established.

Furthermore, the Berlin Group recently announced the development of an Open Finance API, which offers additional functions beyond those required by PSD2. In addition to "Pay by Loan" and electronic mandates for SEPA, these will also include a RTP.

Finally, the SEPA RTP Scheme itself has already developed some momentum. The rulebook was published on November 30^th, 2020 after a six-month consultation period and is scheduled to enter into force on June 15^th, 2021. Furthermore, the go-live of a pan-European RTP infrastructure by EBA Clearing is imminent and some banks have already recognized the high relevance. At ERSTE Bank Hungary, the sending of payment requests has already been possible since July 1^st, 2020 based on the Real-Time Payment Engine of the company valantic; Banca Sella has already informed about its intention to obtain the RTP service of the company SIA via its EasyWay platform. DZ Bank and HVB have also announced their intention to provide a solution shortly respectively in 2021. It can be assumed that other banks actively participating in the RTP scheme are already working on solutions behind closed doors.

SEPA request-to-pay is a sound scheme, albeit, being a concept with an unclear future it is yet to prove its traction in the European payments market.

The situation in the SEPA area is currently special: with the European Retail Payments Strategy, the European Commission has recently taken a clear position and subtly initiated a market impulse against international card organizations and platforms. In this context, it supports European initiatives and developments, such as the introduction of the SEPA Proxy Lookup Scheme or the introduction of a harmonized QR standard, each of which would have a positive influence on identification mechanisms in the context of future RTP solutions. Furthermore, real-time processing of payments - a key payment type for the RTP - has been declared as the "new normal" in the EU Retail Payment Strategy and it is expected that the European Commission will announce mandatory participation for banks in the SCT Instant standard. Moreover, the European Commission has recognized that real-time payments will only become the "new normal" if they (and payment solutions based on them) are offered free of charge on the payer side - which is quite reasonable considering that the main advantages of real-time processing arise on the receiver side (e.g. liquidity advantage).

With this tailwind and the current RTP momentum, the necessary awareness of the relevance of the topic should at least be created on the banks’ and merchants’ side. Even if there is still a need for clarification regarding the regulations and possible products, the RTP is without question an important piece of the puzzle that offers opportunities for banks and merchants alike.

However, the fact that in the SEPA area, speed is of the essence for bringing appropriate solutions to the customer and for overcoming the critical mass of participants is shown above all by Vocalink's participation in Pay.UK's R2P, even though this solution is not currently in direct geographical competition with SEPA RTP. At the latest, when the card organizations have launched a solution that serves a standard that should actually promote the banks strategic independence, banks and merchants would have missed a great opportunity to operationalize the geopolitical agenda of the EU Commission and, in parallel, the interests of their own organizations.

Merchants and banks are therefore advised to analyze the current observations carefully and to start working on customer-friendly and market-differentiating product offerings as soon as possible. Furthermore, the possibility to actively participate in the design of the Request-to-Pay scheme and to set groundbreaking impulses still exists. For example, participation and transaction fees have not yet been set - finding the right balance between the payer and recipient side should consider the perspectives of all the players involved. As it is so often the case in business, one can either shape the change, or leave the change to shape oneself.

Figure 1: CORE

Figure 2: CORE (with information of the SEPA Request-To-Pay Scheme Rulebook https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2020-12/EPC014-20%20v1.0%20SEPA%20RTP%20Scheme%20Rulebook.pdf)

Figure 3: CORE (with information of the SEPA Request-To-Pay Scheme Rulebook https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2020-12/EPC014-20%20v1.0%20SEPA%20RTP%20Scheme%20Rulebook.pdf)

1. Statistics on the shares of payment methods in retail sales in Germany:
   https://de.statista.com/statistik/daten/studie/702443/umfrage/verteilung-der-zahlungsarten-im-einzelhandel-in-deutschland/
2. CORE Blogpost: The Retail Payment Strategy of the EU Commission:
   Disruption or protection - an analysis of the EU Payments Strategy (core.se)
3. Retail Payments Strategy for the EU:
   https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020DC0592
4. Fact Sheet Retail Payments Strategy for the EU:
   https://ec.europa.eu/info/sites/info/files/business_economy_euro/banking_and_finance/200924-retail-payments-factsheet_en.pdf
5. ECB payment statistics:
   https://www.ecb.europa.eu/press/pr/stats/paysec/html/ecb.pis2019~71119b94d1.en.html
6. SEPA Instant Credit Transfer:
   https://www.europeanpaymentscouncil.eu/what-we-do/sepa-instant-credit-transfer
   https://www.ecb.europa.eu/pub/pdf/scpops/ecb.op229~4c5ec8f02a.en.pdf
7. SEPA Payment Scheme Management:
   https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payment-scheme-management
8. SEPA Request to Pay Framework:
   https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/request-pay-specifications-standardisation-framework
   https://paytechlaw.com/sepa-request-to-pay-srtp/
9. SEPA Request-to-pay Scheme Rulebook:
   The SEPA Request-To-Pay (SRTP) Scheme Rulebook | European Payments Council
10. SEPA Proxy Lookup (SPL) scheme:
    https://www.europeanpaymentscouncil.eu/document-library/rulebooks/sepa-proxy-lookup-spl-scheme-rulebook-version-20
11. Cross-border RTP - Proof of Value:
    https://www.swift.com/de/node/228211