The pain family: payment initiation
pain messages carry a customer's payment instructions to their own bank — pain.001 to initiate, pain.002 to report what happened.
L0 Explain simply
Analogy: a pain.001 is the order slip a customer hands across the counter — "please pay these people, these amounts, from this account." It is not the payment itself, and it never travels between banks; it goes only from the customer to their own bank. The pain.002 is the bank's note back across the counter: "we received your order; items one to fourteen are accepted, item fifteen is refused because the account number fails its check." Everything that happens afterwards — the interbank freight, the clearing, the settlement — uses different paperwork that the customer never sees. The order slip starts the journey; it does not make the journey.
L1 Core concepts
pain stands for payment initiation: the customer-to-bank space of ISO 20022. The two messages met most often are pain.001, the customer credit transfer initiation, and pain.002, the payment status report the bank returns. A pain.001 can carry one payment or thousands: a group header with control totals, one or more payment information blocks (debtor account, requested execution date), and individual transactions beneath each block. The debtor's bank validates the file, reports status via pain.002, and converts accepted instructions into interbank pacs messages. The family also covers direct debit initiation and mandate handling, but credit transfer initiation is the usual entry point for learning it.
L2 Practitioner view
Operationally, pain.001 is corporate territory: payroll runs, supplier batches, and treasury payments submitted through online channels or host-to-host connections. Structure matters for control: the debtor account, requested execution date, and charge instructions sit at batch level, so one file can carry several batches with different settings. Status reporting varies more than people expect — some banks send a pain.002 per file, some per batch, some per transaction, and some only on rejection. The status codes come from ISO code sets, but which lifecycle points trigger a report is a bank-by-bank service decision, not a standard rule. Reconciling a submitted file against later statements relies on the end-to-end identifier the customer set on each transaction.
L3 Technical details
The boundary with the interbank leg is where design care pays off. The debtor agent maps each accepted pain.001 transaction into a pacs.008, carrying forward the end-to-end identifier, amounts, parties, and remittance data. Elements that exist in the initiation space but have no home in the applicable interbank usage guideline can be lost at this boundary, so corporates should not assume everything submitted reaches the creditor. Duplicate control leans on the message and payment information identifiers — banks typically refuse a reused file identifier within a retention window, though window lengths differ. Cut-off applies per execution date: a batch that misses cut-off is commonly warehoused to the next business day rather than rejected, but that too is a service feature that varies between banks.
L4 Standards & sources
Two layers of authority govern these messages. The base definitions of pain.001 (customer credit transfer initiation) and pain.002 (customer payment status report) are registered in the ISO 20022 catalogue under the pain business area, which fixes every element, multiplicity, and data type. In SEPA, the European Payments Council then constrains that base for scheme traffic through its SCT implementation guidelines, published in two sets: inter-PSP guidelines for the pacs space, and customer-to-PSP guidelines for initiation. The customer-to-PSP set maps each rulebook attribute onto specific pain.001 elements, marks which optional catalogue elements SEPA usage requires or excludes, and profiles pain.002 status reporting. In short: the catalogue answers what a pain.001 can express; the EPC guidelines answer what a SEPA one may contain — and a bank's channel guide narrows it further.
Sources & standards2
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain business area message definitions
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Scheme-specific rule2025 version 1.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · SCT customer-to-PSP implementation guidelines
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
SEE THE PAYMENT MOVE
Read the steps as text
- 02ProcessingBank Alfa validates the instructionBank Alfa (debtor agent)
The debtor agent checks the format, the IBAN, available funds, and runs compliance screening before accepting the instruction for execution.
Screening checkpoint: Debtor-agent transaction screening — Names and remittance data are screened against sanctions lists before the payment goes interbank.
- 03PostingThe debtor's account is debitedBank Alfa (debtor agent)
Once accepted, Bank Alfa books the debit. The customer's money has left their account, but no money has yet moved between banks.
- DR Debtor's current account at Bank Alfa — EUR 12,500.00
- 05Clearing obligationThe CSM calculates positionsClearing & settlement mechanism
The CSM validates the message and includes it in a clearing cycle. Each participant's obligations are calculated — this creates who-owes-whom, not yet a movement of money.
Clearing produces obligations. The banks do not have their money yet — that only happens at settlement.
- 06SettlementPositions settle in central bank moneyBank Alfa (debtor agent) → Nordbank (creditor agent)
The calculated positions settle across the banks' settlement accounts at the central bank. Only now has money finally moved between Bank Alfa and Nordbank.
- DR Bank Alfa settlement account — EUR 12,500.00
- CR Nordbank settlement account — EUR 12,500.00
- 08ProcessingNordbank validates and screens the incoming paymentNordbank (creditor agent)
The creditor agent checks that the account exists and can be credited, and runs its own sanctions screening on the incoming payment.
Screening checkpoint: Creditor-agent inbound screening — The receiving bank screens independently — it cannot rely on the sender's screening alone.
- 09PostingThe creditor's account is creditedNordbank (creditor agent)
Nordbank credits the beneficiary. The transfer is complete end to end: customer debited, banks settled, beneficiary credited.
- CR Creditor's current account at Nordbank — EUR 12,500.00
Sources for this topic2
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain business area message definitions
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Status-reporting behaviour, duplicate-control windows, and warehousing rules are described as ranges of common practice; the specifics are service decisions that differ by bank and channel contract.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.