pain.013/14 ISO 20022 message
Published on
10/09/2026
Updated on
10/09/2026
Reading time
3 min
Last updated: 10 September 2026
The pain.013 is the ISO 20022 CreditorPaymentActivationRequest; its answer is the pain.014 (CreditorPaymentActivationRequestStatusReport). With them a payee asks a payer to pay and receives a report on how the payer responded. In the market the procedure is known as request to pay.
A request, not a payment
The decisive point comes first, because it is confused again and again in practice: the pain.013 moves no money. It is value-neutral. It carries who wants how much from whom and by when, and it typically carries a remittance reference and a link to the invoice – but it triggers no booking.
The decision rests with the payer. If the payer agrees, it is the payer who then instructs a payment, as a rule a credit transfer or an instant credit transfer. This sets the procedure apart fundamentally from the direct debit, where the payee collects and the payer has agreed in advance by mandate.
| Characteristic | request to pay (pain.013) | SEPA direct debit | credit transfer |
|---|---|---|---|
| who initiates | the payee | the payee | the payer |
| who decides on the payment | the payer, case by case | the payer in advance, by mandate | the payer |
| mandate required | no | yes | no |
| money moves through the message | no – it is value-neutral | yes | yes |
| what happens next | the payer initiates a credit transfer | the amount is collected | the payment is instructed |
| message | pain.013 with pain.014 as the answer | pain.008 customer side, pacs.003 interbank | pain.001 customer side, pacs.008 interbank |
The flow in the SEPA scheme
In the European scheme SEPA Request-to-Pay, two service providers sit between payee and payer – one on each side. The payee hands the request to its SRTP provider, which validates it, adds routing details and forwards it to the payer's provider, which presents it to the payer. The status report travels back along the same route.
Two features of the scheme matter more for implementation than the message structure. First, the provider roles are not necessarily banks – any admitted participant can fill them. Second, the exchange between providers is not file-based but runs through interfaces. The EPC publishes its own API specifications and a security framework for this; in that setup pain.013 and pain.014 supply the business data model, not the transport.
State of the SEPA scheme
Version 4.0 of the SRTP rulebook currently governs, issued at the end of 2024 and effective since October 2025. The scheme grows through fixed admission windows: the European Payments Council runs homologation waves several times a year in which new participants are admitted. For 2026 the EPC directory service is also to be opened to SRTP participants – a practical step, because without a reliable directory the reachability of the other side is the real obstacle.
That brings the sober assessment with it: the scheme is available and governed, but adoption is still building. Anyone planning today should check the reachability of the payer side before basing use cases on it.
Use outside SEPA
The two messages are not a European construct. The US instant payment service FedNow lists pain.013 as request for payment and pain.014 as the corresponding response in its message catalogue; the role is the same as in the SEPA area. Other instant payment systems build on the same base message. The rulebooks differ, the business model does not – whoever has understood the message once will find their way in several markets.
Relevance for banks and payment service providers
- Two roles, two projects. Sending requests and receiving them are separate capabilities. The payer side is the more demanding one, because the request has to be presented to the customer intelligibly and the decision reported back cleanly.
- The payment is not part of the scheme. Consent and payment initiation have to be linked inside your own systems, otherwise an open request is left without a traceable conclusion.
- Interfaces instead of files. Institutions coming from classic file exchange should plan for a different kind of connection – with availability requirements closer to those of instant payments.