SEPA Request-to-pay: a door opener to innovation

If you are not working in the payments industry, it remains a mystery why payments are such a complex domain. In its essence, it is just a debit from one account and a credit on another account, which in a digital world should be super easy to accomplish.

The reality is however a whole different ball game, resulting from a complex web of dozens of parties (with different - often legacy - solutions, using different protocols), which have been integrated extensively. As a result, any new innovative solution, first needs to integrate with a large amount of existing payment solutions, in order to provide a reasonable user and acceptance base. If we could switch all businesses all at once to a new solution, payments could be organized a lot easier and more efficient, but obviously this is not realistic.

When we deconstruct payments to its core, you can identify following steps:

• Payer receives the info of how much he needs to pay from the payee (= recipient)

• Payer initiates a payment and signs this payment (via proper authentication)

• The institution holding the money of the payer authorizes the transaction.

• The account of the payer is debited

• Money is sent to the institution of the payee

• The account of the payee is credited

A whole variety of solutions already exists to resolve those different steps, each of them supporting specific use cases, i.e.

• Different ways to initiate a payment, e.g. Credit Transfer, Direct Debit, Card Payment (online and physical), P2P Payment, Mobile Payment, PSD2 Payment Initiation, a one-time versus a recurring payment…​

• Different ways the payer receives the info of what and how he must pay, e.g. via a terminal (POS device), via an invoice, via a QR code (static printed or dynamically generated), via an NFC signal from a mobile phone (SoftPOS)…​

• Different value-added services involved in the payment, like Forex, guarantees, instant payment or not, tracking of the delivery (e.g. SWIFT GPI tracking), credit handling (e.g. BNPL), loyalty programs linked to credit and debit card payments…​

• Different levels of guarantees for the payee to get paid or for the payer to get reimbursed in case of fraud/identity theft/…​ E.g. the difference between a SEPA Core and a SEPA B2B Direct Debit.

• Different ways of authentication, e.g. via the payer’s banking authentication, via a card and a PIN code, via biometric authentication on your mobile phone…​

• Different payment schemes, e.g. card schemes like MasterCard, VISA, American Express, Dinners Club, UnionPay or more national schemes like e.g. Bancontact in Belgium or bank schemes like the different SEPA payment schemes

• …​

The above shows that already a lot of options exist for each possible payment use case, but nonetheless thousands of individuals and companies still struggle on a daily basis to pay or get paid in a secure, reliable and convenient way. As a result, new Fintechs in the Payments space, that try to resolve (certain of) those gaps, are still being founded on an almost daily basis.

An exciting new evolution in the Payments domain is the introduction (introduced on 15th June 2021) of the new European payment scheme (or better framework as settlement and clearing will still be handled by existing schemes), called SEPA Request-to-Pay (SRTP), which opens the door to exciting new innovations, which could solve a lot of the day-to-day payment issues users encounter today.
In short SRTP defines the operating rules and technical standards (ISO 20022 XML), that enable a payee to request the initiation of a payment from a payer. It is therefore not a means of payment, but rather a new way to request a payment initiation (a "pull payment"), i.e. a creditor or merchant can send a digital, data-rich payment request directly to its customer via a secure digital channel (e.g. on their smartphone or by email).

The process goes as following:

• The payee sends a Request to Pay to the payer. This can be done e.g. by scanning a QR code or via an NFC contact.

• The payer (the consumer) receives the request on his mobile device (e.g. on his banking app) and will authenticate himself

• The payer has then 3 options, i.e.

  • Pay immediately in full or in part (Pay Now)

  • Delay the payment (Pay Later)

  • Decline the payment

• If payment is executed, it will be handled via a traditional SEPA Credit Transfer (SCT)

The potential advantages for banks and customers of this new scheme are enormous, i.e.

• Reduction of costs, fraud and chargebacks, i.e. this new standard is a cheaper and more secure alternative to cards, which is furthermore irrevocable, i.e. contrary to Direct Debits, which can be contested by the payer, transfers associated with SRTP are irrevocable.

• Reduction of accounting reconciliation issues, as the correct reference info can be pushed to the payer (i.e. use of a standardised, structured remittance information with every transaction).

• Transfer richer transaction info to the payer, i.e. the SRTP scheme allows to transfer far richer data than a traditional card payment, e.g. an SRTP message allows to pass attachments. This opens the door to all kinds of new value-added services, e.g. passing the cashier’s receipt or invoice in the request gives new opportunities for PFM tools and cash-back and loyalty schemes.

• Real-time confirmation of the payment initiation, i.e. the payee can be informed in real-time when the payer has initiated the payment. Note that only a confirmation of the payment initiation is foreseen, i.e. not a confirmation when the actual settlement of payee’s account is completed

• Accelerate the collection of money for the payee, thus improving cash management. This is especially the case when the resulting SCT is handled via instant payments. SRTP is therefore considered as a strong accelerator for the roll-out of Instant Payments.

• Simplify the customer payment journey, i.e. bring frictionless digital payments, e.g. contrary to Direct Debits, SRTP payments don’t require an upfront mandate from the payer.

• Allows banks to increase the number of user interactions with their banking app, i.e. as an SRTP will require a bank authentication by the payer, the banking apps are in the center of this process. This creates all kinds of cross-selling and other value-added service opportunities for banks.

Although the benefits are clear, it remains to be seen if this new framework will really become a success, especially as

• Similar solutions exist already all over the world, including in Europe. As banks often have invested (heavily) in those solutions, it is uncertain if banks (the primary actors for SRTP) will adopt the new standard and push it as an alternative.
  Some examples of existing solutions:

  • India: Bharat BillPay is highly successful (with nearly a million transactions every day) facilitating instant money transfers between individuals and with merchants

  • Australia: BPAY, an electronic invoicing service, is used by more than 60% of Australians for paying their invoices from companies.

  • US: Venmo handles millions of peer-to-peer payments

  • Switzerland: the eBill services are used by a lot of financial institutions and companies.

  • Netherlands: the iDEAL platform handles more than 80% of online payments using a payment link or a QR code

  • Belgium: several solutions exist that provide similar functionalities, like the Payconiq by Bancontact app, the KBC/Belfius Pay Button available on most eCommerce webshops or POM providing an easy payment button/link/QR code for paying invoices

  • …​

• The new solution forms a direct threat to card payments. As banks have strong stakes in card payments and the lobbying and power of international payment networks like VISA, MasterCard, UnionPay…​ is immense, it could be a risky move for banks to push this new solution.

• The need for a strong customer authentication gives a strong friction and can make certain user journeys extremely complex. E.g. imagine you need to pay in the supermarket, but you first need to execute a complex authentication process on your smartphone (i.e. receive a push notification, open the banking app, log-in and authorize the request-to-pay).
  For corporate accounts requiring authorization of several people, the journey can become even more complex and unclear how it will exactly work.

• The payment initiation foreseen in SRTP is a bit counterintuitive to today’s practices. With SRTP it is foreseen that the Payee initiates the transaction, meaning the Payee scans a QR code presented by the Payer. Most payment schemes today (like Payconiq, AliPay…​) have designed the flow in the opposite direction, i.e. the Payer scanning a QR code presented by the Payee.

• As indicated above, SRTP only gives a real-time confirmation of the payment initiation to the payee, i.e. not of the actual payment. When combined with SEPA Instant Payments, this could be resolved, even though Instant Payments are still not fully supported by all European banks and almost no bank has a push-mechanism (like a webhook or a notification system) that informs their customers of a new incoming money transfer.

• It is unclear how the exception flows, like chargebacks or refunds need to be handled. Additionally the possibility for a payer to refuse or delay a payment, makes it more complex for the payee to have necessary payment guarantees.

• SRTP offers no real solution for off-line payments. Contrary to a card payment which only needs the "Payee" to be online, you need here both the "Payer" and "Payee" to be online, which puts an additional strain for certain use cases and can result in additional issues (e.g. suppose your smartphone has no battery left anymore, but you need to authorize an SRTP payment).

Clearly there is an equilibrium between the benefits and concerns. It will be interesting to see how this evolution unfolds and if the benefits can outweigh the concerns or if the concerns can be properly addressed in the coming months/years. Any evolution to simplify the payments journey is of course more than welcome.