pain.013 and pain.014: Request to Pay in ISO 20022

Request to pay is one of the more transformative overlays on instant rails: it lets a biller ask for money and lets the payer decide, in-app, whether and when to pay. In ISO 20022, that request-and-response conversation is carried by a specific pair of messages — pain.013 and pain.014. Understanding them clarifies how request to pay differs from both a normal credit transfer and a direct debit.

Where these messages sit

The pain family — "payments initiation" — covers messages between a customer and their bank, as opposed to the pacs family used between banks. The familiar member is pain.001, the customer credit transfer initiation. Request to pay adds two more: pain.013.001 (CreditorPaymentActivationRequest) and pain.014.001 (CreditorPaymentActivationRequestStatusReport). Together they let a creditor request activation of a payment and receive the debtor's decision.

pain.013: the request to pay

A pain.013 is sent on behalf of the creditor (the payee) toward the debtor (the payer). It is essentially a structured, electronic invoice-plus-request. Its payload includes the amount requested, the creditor's account for receiving funds, a requested execution or due date, and rich remittance information — an invoice number, a reference, a description of what is owed. Importantly, it does not move money. It asks the debtor to authorize a payment. That authorization, when given, results in a normal credit transfer that the debtor pushes.

This is the crucial distinction from a direct debit: with request to pay, the payer stays in control. Nothing is pulled from their account. They receive the request, review it, and choose to pay, defer, or decline. The scheme is a messaging and decision layer; the actual settlement rides an underlying push rail such as an instant credit transfer.

pain.014: the response

The pain.014 carries the debtor's status response back to the creditor. It reports the outcome of the request — accepted, rejected, or pending — and can indicate partial acceptance or a request to pay later, depending on the scheme's rules. This closes the loop: the creditor learns whether to expect funds and can update its records or dunning process accordingly.

The status report structure lets the debtor communicate nuance. Rather than a binary yes/no, request-to-pay schemes commonly allow responses such as accept-now, accept-and-schedule, request-more-time, or decline-with-reason, and pain.014 conveys these coded outcomes so the creditor's systems can react automatically. A rejection can also carry a reason code, letting the creditor distinguish a disputed amount from a temporary inability to pay and adjust its follow-up accordingly. Because the response is structured rather than free text, the creditor can automate dunning, scheduling, and reconciliation off the coded outcome without human interpretation.

The full flow

A typical request-to-pay exchange runs like this:

• The creditor generates a pain.013 with the amount, due date, and invoice reference, and sends it toward the debtor.
• The debtor receives the request in their banking app and reviews it.
• The debtor responds; a pain.014 status report goes back to the creditor.
• If accepted, the debtor's authorization triggers a separate credit-transfer instruction (a push) that settles on the underlying rail.
• The creditor reconciles the incoming payment against the original request reference.

Why request to pay matters

The model brings the convenience of biller-initiated collection to push rails without surrendering the payer's control or the finality of a push. It reduces failed direct debits (there is no bounced collection — the payer either pays or does not), gives billers structured confirmation, and supports flexible outcomes like part payment and deferral. The EPC's SEPA Request-to-Pay scheme standardizes exactly this exchange at European scale, and similar overlays exist on other instant rails. For builders, the key mental model is that pain.013/pain.014 are a conversation about a payment; the money itself still moves on a separate credit transfer once the payer agrees.

Key takeaways

• pain.013 (CreditorPaymentActivationRequest) is the creditor's request to pay — amount, due date, and invoice details — but it moves no money.
• pain.014 is the debtor's status response, supporting accept, decline, defer, or partial outcomes.
• The debtor stays in control: acceptance triggers a separate credit-transfer push, unlike a direct debit which pulls.
• Both sit in the pain (payments initiation) family, between customer and bank; pacs messages move funds between banks.
• SEPA Request-to-Pay standardizes this exchange; settlement rides an underlying instant rail.