SEPA Request to Pay

Introduction

Over two years ago, I posted Request to Pay 101 and it is now (about) time to present the new messaging SEPA Request to Pay scheme (SRTP). The objective is to explain the basics of this new scheme without you having to read the whole package of documents published so far.

In this new post, I describe the more interesting business and operational aspects of the scheme from a practitioner point of view, leaving aside topics such as participation requirements, rights and obligations of participants, security obligations, disputes resolution, etc.

It is very helpful to be knowledgeable about SEPA payment schemes for easier reading. The reason is that although SRTP can operate separately from these schemes, we will see them working together in practice.

What is SRTP and what it covers?

SRTP is a European messaging scheme whereby a payee requests a payer to initiate a payment. The scheme aims to provide a standard European solution and is applicable to countries listed in the European Payment Council SEPA Scheme Countries. The rules and messages governing the request are covered in extensive detail in SRTP EPC Rulebook and SRTP Implementation Guidelines.

The request initiation channel, the identification checks between payee and payer, and the flows regarding payments prompted by the request to pay, are not covered in the rulebook.

How does the scheme work?

In its most common configuration, the scheme will be supported by ‘four corners’, where the payee relays the message to its service provider which in turn relays it to the payer’s service provider. The payer’s service provider finally delivers the message to the payer.

Figure 1. SRTP Four corners model

In this model, both payee and payer service providers can be PSP or non-PSP entities, and the processing between service providers would function on a 24/7/365 basis.

The scheme can also be supported by ‘three corners’ in case the payee and the payer share the same service provider, or even direct communication between payee and payer is possible.

As described in Figure.1 for the four corners model, the payee initiates the request to pay which reaches the payer through the service providers. The payer can then accept to pay immediately, accept to pay later, or refuse to pay. Irrespectively of payer’s response, a payment status report will inform the payee whether the request has been accepted or refused.

Participants have the obligation to accept ISO 20022 XML messages but different standards can be agreed bilaterally. Between payee and payee’s RTP Service Provider for example, single or multiple RTPs per message or what exact attributes to be conveyed in the message can be agreed, depending on the nature of the customer and the origination channel.

What are the Use-Cases?

The SRTP lends itself to several use-cases I have listed in table below. The list of examples is not exhaustive but provides a global view of use cases enabled by the first scheme release and those supported in future releases*.

*Below use-cases will not be part of the first release:

• Guarantee of payment
• Payment in multiple instalments
• Grouping of multiple requests to pay into one
• Currency agnostic requests to pay. (messages will be restricted to € as a currency in the first release)
• Request for pre-authorized amounts
• Possibility to include URLs in requests to pay.

For each use-case the table includes payee and payer type, whether they interact physically or remotely through e.g. mobile phone, (using QR code, Bluetooth Low Energy, Near Field Communications), and the request type exchanged. The request type is responded by a payment outcome, an immediate, deferred, or refused payment.

Table 1. SRTP Use-Cases

What are the Technical Specifications?

SRTP Implementation Guidelines published by the European Payments Council, provide standard rules applicable to ISO 20022 XML SRTP messages. Communication rules between payee and payee’s service provider, between services providers, and between payer and payer’s service provider, are defined.

Embedded below is a comprehensive table listing the messages governing the new scheme which includes a functional description for each message and their equivalent XML format. The full specifications for data sets are available in the SRTP Implementation Guidelines.

Table 2. SRTP Data Sets

It is worth mentioning a couple of relevant attributes the payee needs to provide mandatorily in the RTP message:

• ‘Expiry date / time’ for the payer to accept or refuse the RTP. Rules are defined around attribute AT-79, date and timestamp of the RTP (please see full list of attributes in pp.35 of the rulebook)
• ‘Requested execution date / time’ by when the payment must be initiated. (Used in combination with above expiry date).

Processing flows diagrams are depicted in the rulebook. Below some details are described for the more complex non-happy flows:

• The scheme allows for issuing of a ‘request for status update’ in case of non-response from payer RTP’s service provider
• In case of reject of the RTP, (DS04 data set in above table), the following relevant attributes are conveyed in the message: reason code for rejection, unique payee’s service provider reference (AT-63), end-to-end reference provided by payee is sent back for reconciliation (AT-41), placeholder for charges, a copy of attributes of DS01 (similarly to pacs.004 return messages in SEPA payments)
• For the negative response processing, (DS07 data set above), the same references described above are relevant
• The scheme also allows for issuing of a ‘request for cancellation’, (DS10, DS11, data sets above). Several reasons may prompt this request type, duplicate, technical error, fraud (similarly to camt.056 recall in SEPA). The reason code for cancellation is informed in AT-50. Initial RTP is identified by payee’s service provide reference (AT-63).

Please find below an overview of data sets and flows of the scheme, broken down by use cases for an easier understanding. You may notice that there is no specification / data set enforced for some messages exchanged between service provider and payer / payee such as ‘reject of RfC by payee’s service provider’, or ‘cancellation information’ message between payer’s service provider and payer.

Figure 2. Data Sets & Flows for SRTP

What are the benefits for scheme participants?

In below table, I have listed a range of benefits for the different participating entities. Benefits are grouped into two categories, user experience / added value and service management benefits.

Table 3. Benefits for participants to SRTP

Challenges

For all the benefits described in the previous section, there are still many challenges for a successful deployment and scaling of this new scheme. Below I have listed some of them:

• SRTP would be easier to integrate if the SEPA Instant Payments market coverage was larger and Instant Payments were free of charges which is not the case today. It stands to reason that payers should not be charged when the main advantages lie on the payee side
• The scheme is lacking on a legal framework of guarantees for payers for what are called R-transactions, returns, refunds, chargebacks.
• Means of payment is proposed by payee although the final choice lies within the payer. SRTP may be an interesting alternative to cards or direct debits but there is no guarantee for payees that the payment will be received instantly. As we have said, payers can refuse or defer payment, or pay a minimum amount. Payment guarantees could help here, although this use case needs to be elaborated in future versions of the scheme
• Payers need to be confident about security to facilitate adoption reason why strong authentication is required. This might be a friction point even if applications are designed to be user friendly
• Corporate payment accounts where authorization from several people is required may hinder deployment in the corporate space
• Both payee’s and payer’s service providers can be non-PSP, but actual synergies can only be obtained when payments services are provided together with SRTP. On the flip side, SRTP could be of interest for non-banks payment initiators.

Conclusions

Despite the challenges mentioned in this post, SRTP is bound to grow significantly over the coming years against the context of instant payments and open banking initiatives. It could be considered a complementary flow in support of the whole payment processes, and key to the payments’ strategy devised by the European Commission to create a more competitive and efficient market space.

Underpinning the success of the scheme for mass adoption across Europe are some of the below aspects:

• Participants will need to find a viable economic model for the scheme to deploy the service. A good Return on Investment is hard to achieve especially when payers and payees are not willing to accept further charges. Ensuring a good experience and eliminating transaction costs on payer’s side is critical for a successful deployment. However, passing cost onto payees may discourage them from adopting this scheme e.g. merchants accepting card payments when costs of the scheme exceed interchange fees. It is not clear that removing the acquirer from the payment chain, will provide good value for payee and PSP alike
• Banks must identify ways of creating value-added services beyond gains in operational efficiencies. These new revenue streams provided by overlay services, would compensate for the loses due to disintermediation in the payments value chain
• Socialization and implementation of standardized payment workflows for users to get familiar with use cases applicable to the service, will be key to clear up the confusion around what this new scheme offers.

In some countries, the request to pay service has been very successful e.g. eBill in Switzerland or BPAY in Australia. In others, the success is still limited due to poor user experiences on payer’s side. In Europe particularly, direct debits and profitable card payments have been there for a very long time and the status quo will be hard to break. Some countries such as France, introduced in the past similar services like SEPA mail rubis meeting mild success.

I am convinced however, that this new European SRTP scheme is very attractive, flexible, and functionally rich. Its future holds a lot of promise despite the initial challenges it will face after its deployment. Watch this space! 😊