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.

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.

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
  • 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.
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.

Table 2. SRTP Data Sets
  • ‘Requested execution date / time’ by when the payment must be initiated. (Used in combination with above expiry date).
  • 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).
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


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:

  • 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.


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.

  • 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.

Technology consultant — banking