SRTP Technical Documentation: JWS Sealing and the 1 May 2027 EDS Date

On 27 October 2026 the European Payments Council (EPC) published updated SRTP technical documentation for the SEPA Request-to-Pay scheme: version 1.1.0 of the SRTP Trust and Security Model (EPC207-26) and version 4.0.1 of the SRTP OpenAPI Specifications, both aligned with version 4.0 of the scheme rulebook and its Implementation Guidelines. The EPC says the requirements may be implemented now on a voluntary basis and formally take effect six months after publication, a date it gives as 1 May 2027. From that date, according to the same notice, use of the EPC Directory Service (EDS) becomes mandatory for all SRTP scheme participants.

The Trust and Security Model’s change history records one revision since the initial version of 31 July 2026: an SRTP-specific JSON Web Signature (JWS) profile that fixes the algorithm, the signed HTTP components, the header fields and the verification steps. These are EPC scheme requirements for SRTP participants, with the updated documents formally taking effect on 1 May 2027 and earlier implementation voluntary. The Trust and Security Model relies on qualified certificates under Regulation (EU) No 910/2014 (eIDAS): a Qualified Website Authentication Certificate (QWAC) for API-client authentication and a Qualified Electronic Seal Certificate (QSealC), with which every SRTP API message exchanged between SRTP service providers is signed.

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

SRTP technical documentation dates to plan against

The end-September EDS milestone below is the plan the EPC reported in June 2026; the documents reviewed for this note do not confirm the production go-live date.

What version 1.1.0 changes in the Trust and Security Model

Both versions describe the same mutual TLS (mTLS) trust flow and the same five API endpoints. The difference is Chapter 3, message signature using a QSealC. Version 1.0 signed a canonical text built from the HTTP method, full target URI, API-defined headers and complete business payload, and carried the result in three custom headers. Version 1.1.0 uses a detached JWS built on RFC 7515, the unencoded-payload option in RFC 7797 and the HttpHeaders mechanism of the JAdES standard ETSI TS 119 182-1.

The EPC API Security Framework (EPC164-22, version 2.1 of 16 March 2026) had left the protocol for transporting a seal to each scheme’s API documentation, observing that no undisputed European or international standard existed for it, and noted that sealing was so far foreseen only for SRTP. Version 1.1.0 now specifies that protocol. It also requires each SRTP service provider to support both generation and verification of JWS signatures, because sending and receiving roles alternate within one exchange for responses, callbacks, acknowledgements and error responses.

The JWS profile in Chapter 3 of the Trust and Security Model

The JWS Protected Header carries six required parameters: alg set to PS256, b64 set to false, crit listing exactly b64 and sigD, iat as an integer NumericDate, sigD with the fixed mechanism identifier http://uri.etsi.org/19182/HttpHeaders, and x5c with the signing QSealC first. The order of signed components in sigD.pars is mandatory: for a request, (request target), host, the other API-defined headers present in lowercase alphabetical order, then digest; for a response, (response status), the headers, then digest. Components are joined by a single line feed with no trailing line feed, encoded as UTF-8, and used as raw octets in the signing input.

Two construction rules decide whether a receiver can reproduce the payload. The request target uses the path and query exactly as transmitted, with no normalisation of percent-encoding or parameter order, so a client library that re-encodes a query string after signing produces a message the receiver cannot verify. Header names in pars are the actual lowercase field names in the message, and the profile states that names of reusable OpenAPI components are not header field names. The ISO 20022 business payload itself stays in the HTTP body, unchanged and free of signature data.

SRTP API authentication and EDS participant authorisation

The trust flow is carried over from July; the 27 October notice attaches a date to it. Where the Payee’s SRTP service provider holds the registered BIC11 of the Payer’s SRTP service provider (attribute AT-N001, which the Trust and Security Model draws from dataset DS01), it queries the EDS for the endpoint URI and option information, and opens an mTLS connection presenting a Regular QWAC, while the server presents an Extended Validation TLS certificate. For an incoming SRTP request, the receiving API server verifies the sender’s BIC in AT-N002 together with the VAT identifier in its QWAC (organizationIdentifier attribute, OID 2.5.4.97) against the EDS before processing the message. The Trust and Security Model applies the same trust principles to every SRTP endpoint, including the GET retrieval call, and the API Security Framework applies client authorisation to SRTP API interactions.

The EPC Clarification Paper notes that the Payer’s provider, when responding, sends its answer to the Payee provider’s endpoint carried in the original message without further validation. The Trust and Security Model still sets identity checks for asynchronous callbacks: before opening the callback connection the Payer’s provider looks up the Payee provider’s AT-N002 BIC in the EDS, and the Payee’s provider verifies the AT-N001 BIC in the callback together with the VAT identifier in the caller’s QWAC against the EDS. Callback interactions run over a new mTLS connection with the API-client and API-server roles reversed.

Two records therefore have to agree: the VAT identifier the trust service provider wrote into the certificate and the one the participant maintains in the EDS. The EDS SRTP API specifications (EPC180-26) include a provisioning operation to modify a participant’s VAT ID and an Automated Download Service through which a daily EDS file is available in XML, JSON or CSV, and the API Security Framework makes keeping a current local copy the participant’s responsibility. The EPC reported in June 2026 that it reused the EDS setup built for Verification of Payee as far as possible, covered in our Verification of Payee 2.0 scheme note.

The certificate type matters for that match. The trust model names a Regular QWAC under ETSI EN 319 412-4. The API Security Framework separately defines a PSD2 QWAC under ETSI TS 119 495, built around a PSP identifier starting with PSD, and Article 34(3) of Delegated Regulation (EU) 2018/389 requires PSD2 certificates to carry the provider’s role and its competent authority. A provider planning to reuse an open-banking certificate for SRTP would need to confirm that its organizationIdentifier holds a VAT identifier in the form the EDS match reads. The same eIDAS framework underpins the EPC wallet work in our EPC SCARLET and eIDAS 2 analysis.

What changes for RTSPs and other technical solution providers

The API Security Framework applies its requirements to every participant, whether it exchanges messages directly or through a proxy acting as a message gateway; in SRTP, a proxy homologated for that role is a Referenced Technical Solution Provider (RTSP). The framework treats the proxy as legally transparent: liabilities and obligations stay with each participant, the proxy must provision its own QWAC, and a participant whose messages a visible proxy signs must tell the Operational Scheme Manager, with the proxy then provisioning a QSealC.

Version 1.1.0 adds a requirement that reaches whoever runs the gateway: SRTP service providers shall ensure that their API gateways, reverse proxies and other intermediaries support the x-jws-signature header, allowing for the size of the protected header and the x5c certificates, and header size limits shall not prevent processing of compliant messages. Header fields that infrastructure adds and the SRTP API Specifications do not define fall outside the signature scope. Any error response an SRTP service provider generates shall itself be signed, while an unsigned HTTP error from infrastructure outside the SRTP application flow counts as a transport-level failure, whatever its status code.

One point stays open. Verification step 13 requires the identity in the signing QSealC to correspond to the sending SRTP service provider, while the API Security Framework lets a declared proxy sign on a participant’s behalf, and step 13 itself does not say how a receiver reconciles the two. Participants relying on a declared proxy should confirm with the EPC how the signer-identity check applies.

OpenAPI Specifications 4.0.1: what the notice covers

The EPC describes version 4.0.1 as the API definitions in YAML and JSON, with HTML documentation generated using ReDoc. The number is the EPC’s document version, aligned with rulebook 4.0, and says nothing about which release of the OpenAPI Specification standard the files use. Version 1.1.0 of the Trust and Security Model states that the exact syntax of the Digest and x-jws-signature headers shall be reflected in the SRTP API Specifications and the corresponding OpenAPI definitions. The notice publishes no change log for 4.0.1, and this note does not compare the YAML files with the previous release.

Voluntary now, mandatory EDS use from 1 May 2027

Rulebook 4.0, effective since 5 October 2025, already made registration in and funding of the EDS mandatory, and the Clarification Paper of 1 June 2026 describes how participants select options through it; the 27 October notice adds the date from which using the EDS is mandatory. The EPC’s June 2026 status update counted three homologated applicants in the Register of Participants and four listed RTSPs, with further providers planning to join by the end of 2026 and early 2027; the Register’s publication calendar is covered in our note on the EPC Register of Participants December 2026 cycle. The notice does not say how a provider on the JWS profile exchanges messages before 1 May 2027 with a counterparty that is not.

Frequently Asked Questions

Does the Payer’s SRTP service provider need a QWAC, or only the Payee’s side?

Both providers need a QWAC for their API-client role and a QSealC, because the Trust and Security Model requires every SRTP API message exchanged between providers to be signed; each also needs an EV TLS certificate when acting as an API server. In the request flow the Payee’s provider is the mTLS client with a Regular QWAC and the Payer’s provider is the server with an EV/TLS certificate; in the callback flow the roles reverse. The trust model states that the server-side EV/TLS model cannot be replaced by QWAC-based server authentication before the next SRTP change management cycle.

Related Articles

• SEPA Request-to-Pay Rulebook v4.0: What Scheme Participants Must Update: the rulebook changes behind this package.
• Verification of Payee 2.0: What the Next-Generation VoP Scheme Standard Means for EU PSPs: the other EPC API scheme on the EDS.
• EPC SCARLET: EUDI Wallet SCA Acceptance and the eIDAS 2 Clock: eIDAS 2 and the EPC’s wallet rulebook plans.

Key Takeaways

• Prepare and test the JWS implementation specified by version 1.1.0, but do not retire an existing counterparty-compatible signature integration solely because the new version has been published. Confirm bilateral interoperability and transition arrangements during the voluntary period before 1 May 2027.
• Use the registered BIC11 in AT-N001 for EDS endpoint discovery. For incoming-request authorisation, validate the sender’s AT-N002 BIC together with the VAT ID from its QWAC against the EDS. Systems storing only BIC8 values must obtain the correct registered BIC11.
• Run a gateway test with a full x5c certificate chain inside x-jws-signature before counterparty testing starts.
• Diff OpenAPI 4.0.1 against the current baseline before regenerating client and server code.
• An RTSP that signs as a visible proxy should obtain the EPC’s reading of the step 13 QSealC identity check before 1 May 2027.

Sources and References

• EPC, EPC publishes updated technical documentation for the SRTP scheme (27 October 2026): EPC news
• EPC207-26, SRTP Trust and Security Model, version 1.1.0 (27 October 2026): EPC (PDF)
• EPC207-26, SRTP Trust and Security Model, version 1.0 (31 July 2026): EPC (PDF)
• EPC164-22, EPC API Security Framework, version 2.1 (16 March 2026): EPC (PDF)
• EPC180-26, EPC Directory Service (EDS): SRTP API specifications, version 1.0 (16 July 2026): EPC (PDF)
• EPC177-26, EPC status update for the 18 June 2026 Euro Retail Payments Board meeting (1 June 2026): ECB (PDF)
• EPC278-24, SRTP scheme status update to the December 2024 Euro Retail Payments Board meeting (18 November 2024): ECB (PDF)
• EPC216-20, Clarification Paper on SRTP Scheme Rulebook, version 4.0 (1 June 2026): EPC (PDF)
• EPC, SEPA Request-to-Pay Scheme Rulebook version 4.0 (EPC014-20): EPC document library
• Regulation (EU) No 910/2014 on electronic identification and trust services (eIDAS): EUR-Lex
• Commission Delegated Regulation (EU) 2018/389, Article 34: EUR-Lex
• IETF RFC 7515, JSON Web Signature: RFC Editor; IETF RFC 7797, JWS Unencoded Payload Option: RFC Editor
• ETSI TS 119 182-1, JAdES digital signatures, Part 1: Building blocks and JAdES baseline signatures (version 1.2.1, July 2024): ETSI (PDF)

Reconciling EDS identity records before 1 May 2027

Until a provider’s QWAC VAT identifier, BIC and EDS participant record line up, the receiving side cannot confirm it as an SRTP scheme participant, whatever signature format its messages carry. EDS use becomes mandatory for all SRTP scheme participants on 1 May 2027, so the three records need to agree before that date.

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.