SEPA Request-to-Pay Rulebook v4.0: What Scheme Participants Must Update

ByOfficer

Last updated: June 2026

If your institution adhered to the SEPA Request-to-Pay scheme on an older rulebook and then left the change log unread, the SEPA Request-to-Pay Rulebook v4.0 is the version that quietly resets several of your operational assumptions. The functional flow looks the same. The participation mechanics do not. From the entry-into-force date, the way you register options, the way you get homologated, and the security you apply on the application programming interface all sit on new ground.

The European Payments Council published version 4.0 of the SRTP scheme rulebook on 29 November 2024, and it became effective on 5 October 2025, aligned with the wider European Payments Council scheme release window. That gap between publication and effect was the implementation runway. Teams that treated it as a year of breathing room rather than a year of build work are the ones now reconciling a live scheme against a rulebook they skimmed.

This article walks through what version 4.0 changes for an SRTP scheme participant, where the operational traps sit, and what a payment institution or e-money institution should actually update before it relies on the scheme in production. It is written for the people who fill in the adherence pack and the homologation forms, not for the people who sign the press release.

Related reading: our guide to the SEPA Instant Payments Regulation, which sits underneath most live request-to-pay use cases as the settlement leg.

What the SEPA Request-to-Pay Rulebook v4.0 actually changes

Version 4.0 was not a rewrite. The European Payments Council framed it around three goals: simplify and clarify the scheme, remove as much as possible of the undue entry barriers, and keep the scheme stable. That last goal matters, because it tells you the functional message flow was deliberately left alone.

The release came out of a defined maintenance cycle. The public call for change requests ran from 1 December 2022 to the end of December 2023. The Request to Pay Task Force assessed 19 change requests, put them through a three-month public consultation, gathered feedback from the Scheme End-User and Scheme Technical Player Multi-Stakeholder Groups, then made a second assessment and produced the fourth release. That paper trail is in the EPC status update to the December 2024 meeting of the Euro Retail Payments Board (document EPC278-24).

The main changes the European Payments Council lists are concrete and operational. Complementary reason codes were added for clarity. Examples were added in the API specifications. Sealing requirements were added in the API specifications for security. A Minimum Viable Product with options was defined to be simpler to implement. An API sandbox, later described as an API test toolbox, was introduced to ease implementation and reduce development cost for new applicants. The homologation process was simplified. And registration in, and funding of, the EPC Directory Service was made mandatory.

Read that list again as a participant rather than as an observer. Four of those seven items touch what you build, how you onboard, and what you pay for. None of them is a headline. All of them are scope.

The thing teams still get wrong: SRTP is messaging, not a payment

The most expensive misunderstanding about SRTP is older than version 4.0, and v4.0 does not remove it. SEPA Request-to-Pay is a messaging functionality. It is a standardised way for a payee to request that a payer initiate a payment. It is not a payment means and it is not a payment instrument.

What that means in practice is that the request and the money travel on different rails. The request-to-pay message moves under the SRTP scheme. The actual transfer of funds, if the payer accepts, settles on an underlying payment scheme, most commonly SEPA Instant Credit Transfer. So when you scope an SRTP project, you are scoping two things at once: the messaging layer that carries the request and its status, and the settlement layer that moves the cash. Teams that budget for one and inherit the other tend to discover the gap during testing, not during planning.

This distinction also drives the legal analysis. Because SRTP is messaging, it does not by itself create a payment obligation, and adherence to the SRTP scheme is voluntary. Nothing in the instant payments rules forces a payment service provider to offer request-to-pay. The two frameworks meet at the point of settlement, not at the point of obligation, which is the cleanest way to keep them straight in a compliance memo.

The four-corner model and who has to adhere

SRTP runs on a four-corner model. The four roles are the Payee, the Payer, the Payee’s RTP Service Provider, and the Payer’s RTP Service Provider. The model exists so that independent service providers on each side can interoperate and interact commercially without being the same entity. The party that requests, the party that pays, and the two service providers in between are all distinct corners.

The participants in the scheme are the SRTP Service Providers, and this is where v4.0 reinforces an important access point. Eligible entities from all SEPA countries are allowed to participate, on the basis that the level playing field principle between payment service providers and non-payment-service-providers is respected. SRTP is not a PSP-only club. A non-PSP can be an SRTP Service Provider, which is part of why the scheme treats request-to-pay as a service layer rather than as a regulated payment activity in its own right.

Here is where teams misread the scope. Adhering to the scheme and being able to run live traffic are not the same step. Adherence is the contractual act of joining. Homologation is the conformance check that proves your implementation behaves. You can sign the adherence agreement and still not be in the Register of Participants until homologation is done. The European Payments Council publishes a dedicated adherence guide for the scheme (EPC085-21) precisely because the sequence trips people up.

The EPC Directory Service becomes mandatory

The single change in version 4.0 with the widest operational reach is the EPC Directory Service. Registration in the EDS, and funding of it, became mandatory under v4.0. This is not a nice-to-have lookup. The European Payments Council has been explicit that the main changes in the fourth version relate to the optionalities and options whose selection requires the use of the EDS. In other words, the directory is the mechanism through which participants declare which options they support, so that the other corner knows what it can send.

That dependency created a sequencing problem the EPC handled openly. The directory had to exist before the option model could be fully described. The EPC stated that the EDS would be implemented for the SRTP scheme around the end of 2025, and that it would wait for the EDS to be available to participants before publishing a new version of the SRTP Clarification Paper that describes the option-selection process. The status update to the June 2025 ERPB meeting (document EPC183-25) sets out that ordering.

For a participant, the practical consequence is a new permanent line item. You register in the EDS, you fund it, you maintain your option declarations there, and you treat the directory as the source of truth for what each counterparty supports. If you built your v3-era integration assuming a static bilateral configuration, the option-by-directory model is a genuine change to how you discover counterparty capability.

Simplified homologation: the route that changed

Homologation is the conformance gate, and v4.0 set out to make it lighter. The simplification was agreed by the SRTP Task Force at the start of 2025, discussed with the Homologation Body, and the European Payments Council launched the simplified homologation process in October 2025.

The headline relief is for applicants that rely on a Referenced Technical Solution Provider. An RTSP is a technical provider whose solution has already been homologated against the scheme. A payment service provider applicant that uses an RTSP is not required to repeat the full homologation, because the technical conformance has already been demonstrated at the provider level. The EPC introduced lighter routes, described as simplified homologation variants, that distinguish applicants by whether they use an RTSP and whether they hold the relevant authorisations or licences. The exact route names and their precise conditions are set out in the EPC homologation material, and applicants should map their own situation to that material rather than assume which variant applies.

This is the second place teams get it wrong. Choosing an RTSP is not only a build decision, it is a homologation decision. If you select a Referenced Technical Solution Provider, you can compress the conformance path significantly. If you build in-house, you carry the full homologation yourself. The decision you make in procurement determines the work you face in conformance, and the two are often owned by different people who never compare notes.

API changes: sealing, examples, the test toolbox and MVP options

Version 4.0 made the application programming interface easier to build against and harder to get wrong on security. Two changes pull in opposite directions and both are deliberate. Examples were added in the API specifications, which lowers the cost of a first integration. Sealing requirements were added in the API specifications for security, which raises the bar on message integrity. Sealing is a cryptographic protection applied to the message so the receiving corner can trust that the content was not altered in transit. If your v3-era integration did not implement sealing, that is build work, not a configuration toggle.

The European Payments Council also defined a Minimum Viable Product with options. The intent is that a new entrant can implement a smaller mandatory core and then add options as needed, rather than building the entire surface before going live. Alongside it, the EPC introduced an API sandbox, later referred to as an API test toolbox, to let applicants test interoperability before homologation and to reduce development cost. For a small payment institution, the MVP-plus-options shape is the most important affordability change in the release, because it lets you scope to a viable core first.

The Implementation Guidelines and the API specifications that align to rulebook v4.0 were published after the rulebook itself, in the run-up to the October 2025 effective date. The guidelines cover the message exchanges in the Payee to Payee’s RTP Service Provider space, the inter-RTP Service Provider space, and the Payer to Payer’s RTP Service Provider space, in both directions, and they set the rules for implementing the relevant ISO 20022 XML messages.

Reason codes and the option model

The complementary reason codes added in v4.0 are a clarity change rather than a flow change. Reason codes tell the other corner why something happened, for example why a request was rejected or why a status moved as it did. Adding complementary codes reduces the number of situations that have to be explained out of band, which is exactly the kind of friction the release set out to remove.

The option model is the more strategic point. Because v4.0 leans on optionalities whose selection runs through the EPC Directory Service, the reason codes and the options together describe a scheme that is more configurable than a flat single-profile scheme. The trade is familiar to anyone who has implemented a flexible message standard: more options mean more interoperability questions, and the directory is the answer the scheme chose. Do not treat the option set as a menu you fill in once. Treat it as state you publish and maintain.

Timing: the dates that actually bind

The dates on this release are easy to confuse because there are several of them. The rulebook was published on 29 November 2024. It became effective on 5 October 2025, aligned with the European Payments Council scheme release window. The Implementation Guidelines that align to v4.0 take effect on the same date, 5 October 2025, at 03:30 CEST, which is the standard scheme cutover moment. The fourth version of the Risk Management Annex was developed and approved in May 2025, ahead of the rulebook going live.

One date inside the message is worth singling out, because it governs the lifecycle of every request. The Expiry Date and Time is the most important date and time in an SRTP, because it defines how long the request remains valid. Subject to a bilateral agreement between the SRTP Service Providers of the payee and the payer, an Expiry Date and Time greater than three months may be accepted. If your collections logic assumes an open-ended request, the expiry field is where that assumption breaks.

How v4.0 sits next to instant payments and Verification of Payee

SRTP does not live alone. It sits in the same payments stack as instant credit transfer and the verification controls that now wrap around it. The Instant Payments Regulation was adopted on 13 March 2024 and drives euro instant credit transfer reachability and the Verification of Payee control across the European Union. SRTP is the layer that can carry the request that an instant payment then settles, and Verification of Payee is the layer that checks the payee identity before the payer commits.

The clean way to hold these together is by function. SRTP requests. Instant credit transfer settles. Verification of Payee checks the name against the account before the payer pays. They are complementary, not substitutes, and a request-to-pay journey can touch all three. If you are scoping the wider build, our SEPA Instant Payments Regulation guide covers the settlement and reachability obligations, and our note on PSD2 reporting requirements covers the supervisory reporting that already applies to your payment activity regardless of whether you offer request-to-pay.

Here is the third common error. Some teams assume that because instant payments are mandated, request-to-pay is mandated too. It is not. SRTP adherence remains voluntary. The instant payments rules do not require you to offer SRTP. So the business case for joining the scheme has to stand on its own commercial merits, not on a compliance deadline, which is a different conversation with a steering committee.

A practical update list for scheme participants

If you are already an SRTP Service Provider on an earlier rulebook, the move to v4.0 is a defined set of actions rather than a vague upgrade. The work clusters into directory, conformance, security, and configuration.

On the directory, register in the EPC Directory Service, arrange for its funding, and load your option declarations so counterparties can discover what you support. On conformance, decide whether you rely on a Referenced Technical Solution Provider or carry homologation yourself, then run the route that matches your situation under the simplified process. On security, implement the sealing requirements in the API specifications if you have not already. On configuration, review the complementary reason codes, set your handling of the option set, and check your treatment of the Expiry Date and Time against the three-month default and any bilateral agreement you hold.

When I onboard any new scheme into an existing payments operation, the first question is always which register a counterparty or supervisor will actually check, because that is the artefact that has to be correct on day one. For SRTP v4.0 that artefact is now twofold: the Register of Participants for scheme membership, and the EPC Directory Service for your live option set. Getting into the first and keeping the second current are two separate disciplines, and only one of them is a one-off.

The second thing I check on any messaging scheme is the security delta between the version I run and the version going live, because that is where the silent build hides. For v4.0 the sealing requirement is that delta. It does not announce itself in a flow diagram, and it is the kind of item that passes a functional test and fails a conformance test.

Adoption so far, and why it matters for your timeline

Adoption of the SRTP scheme has been measured rather than explosive, which is useful context when you plan. According to the European Payments Council status update to the June 2025 ERPB meeting, the EPC had received five adherence requests, three applicants had been successfully homologated and published in the Register of Participants, and three Referenced Technical Solution Providers had been homologated and listed on the EPC website. The same update noted that some communities were planning to join the scheme in 2025 and 2026.

Those are small numbers, and they tell you two things. First, the homologation pipeline is not congested, so the simplified process and the test toolbox are aimed at growing the base rather than clearing a backlog. Second, the option-and-directory model is being introduced while the participant set is still small, which is the easier time to introduce it. If your institution joins now, you are joining a scheme that is stable by design and still early in its adoption curve, which cuts both ways for a business case.

Frequently Asked Questions

When did the SEPA Request-to-Pay Rulebook v4.0 take effect?

The rulebook was published on 29 November 2024 and became effective on 5 October 2025, aligned with the European Payments Council scheme release window. The Implementation Guidelines aligned to v4.0 take effect on the same date at 03:30 CEST.

Is adherence to the SRTP scheme mandatory under the instant payments rules?

No. SRTP is a messaging functionality and adherence is voluntary. The Instant Payments Regulation drives euro instant credit transfer reachability and Verification of Payee, but it does not require a payment service provider to offer request-to-pay.

What is the EPC Directory Service and why does v4.0 make it mandatory?

The EPC Directory Service is the directory through which participants declare the options they support, so that the other corner knows what it can send. Version 4.0 made registration in, and funding of, the EDS mandatory because the main changes rely on optionalities whose selection runs through the directory.

Do I have to repeat homologation if I use a Referenced Technical Solution Provider?

A payment service provider applicant using a Referenced Technical Solution Provider is not required to pass the full homologation, because the technical conformance has already been demonstrated at the provider level. The European Payments Council introduced simplified homologation routes that distinguish applicants by RTSP use and by the authorisations they hold. Map your situation to the EPC homologation material.

Can a non-PSP participate in the SRTP scheme?

Yes. Eligible entities from all SEPA countries are allowed to participate, on the basis that the level playing field principle between payment service providers and non-payment-service-providers is respected. The scheme participants are SRTP Service Providers, which need not be PSPs.

What is the new security requirement in the v4.0 API specifications?

Version 4.0 added sealing requirements in the API specifications for security. Sealing protects message integrity so the receiving corner can trust that the content was not altered in transit. If your earlier integration did not implement sealing, this is build work.

How long does a request-to-pay stay valid?

The Expiry Date and Time defines the lifecycle of an SRTP and is the most important date and time in the message. Subject to a bilateral agreement between the SRTP Service Providers of the payee and the payer, an Expiry Date and Time greater than three months may be accepted.

When will the v4.0 Clarification Paper be published?

The European Payments Council stated it would wait for the EPC Directory Service to be available to SRTP participants before publishing a new version of the Clarification Paper that describes the option-selection process. Check the EPC document library for the current published version before relying on its detail.

Related Articles

Key Takeaways

  • The SEPA Request-to-Pay Rulebook v4.0 was published on 29 November 2024 and became effective on 5 October 2025.
  • SRTP is a messaging functionality, not a payment means. The request travels under SRTP, the money settles on an underlying scheme such as SEPA Instant Credit Transfer.
  • Registration in, and funding of, the EPC Directory Service is now mandatory, and the directory is where participants declare the options they support.
  • Homologation was simplified and launched in October 2025. Using a Referenced Technical Solution Provider can remove the need to repeat full homologation.
  • The API specifications added sealing requirements for security and worked examples, plus an MVP-with-options shape and an API test toolbox to lower the cost of entry.
  • Adherence to the SRTP scheme is voluntary. The instant payments rules do not require you to offer request-to-pay.
  • The Expiry Date and Time governs each request, with a three-month default that can be extended by bilateral agreement.
  • As of the June 2025 ERPB status update, the scheme had five adherence requests, three homologated participants, and three Referenced Technical Solution Providers.

Sources and References

  • European Payments Council, SEPA Request-To-Pay (SRTP) Scheme Rulebook version 4.0 (EPC014-20 v4.0), published 29 November 2024: document library page and rulebook PDF.
  • European Payments Council, SRTP Scheme Status Update to the December 2024 ERPB meeting (EPC278-24, 18 November 2024, ERPB/2024/018), hosted by the ECB: status update PDF.
  • European Payments Council, SRTP Scheme Status Update to the June 2025 ERPB meeting (EPC183-25, 11 June 2025, ERPB/2025/005), hosted by the ECB: status update PDF.
  • European Payments Council, SEPA Request-to-Pay Implementation Guidelines version 4.0: implementation guidelines page.
  • European Payments Council, Guide to the SEPA RTP Scheme Adherence Process v5.0 (EPC085-21, 1 October 2025), which incorporates the simplified homologation process: adherence guide PDF.
  • European Payments Council, SRTP scheme launch of the simplified homologation process: news item.
  • European Payments Council, SEPA Request-to-Pay scheme overview and Register of Participants: scheme page and Register of Participants.
  • European Central Bank, Instant Payments Regulation overview (adopted 13 March 2024): ECB instant payments page.

What to put on your SRTP project plan before you rely on the scheme

The honest read on version 4.0 is that it lowered the cost of getting in and raised the cost of doing it wrong. The simplified homologation, the test toolbox and the MVP-with-options shape all make a first integration cheaper. The mandatory directory, the sealing requirement and the option model all make a careless integration fail conformance. Those are not in tension. They are the same intent from two sides: a scheme that wants more participants but only correct ones.

So before you tell anyone the scheme is live for your institution, confirm four things in writing. You are in the Register of Participants. You are registered and funded in the EPC Directory Service with your options declared. Your API implements sealing and matches the v4.0 specifications. And your handling of expiry, reason codes and the option set has been tested against a counterparty, not just against your own stub. Get those four right and v4.0 is a smaller project than it looks. Skip one and it becomes the kind of project that gets discovered in production.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts