Articles / Learning brief
The pain.001 payment initiation
Your notes
In simple terms / 01
What this means in plain language
How a customer or corporate instructs one or many credit transfers with a pain.001 message: what it carries, from the debtor and creditors to amounts and a requested execution date, and how the pain.002 status report replies.
A pain.001 (payment initiation message 001, formally the Customer Credit Transfer Initiation) is how a customer or a company tells its own bank to make one payment or many. It is a customer-to-bank instruction, which distinguishes it from the interbank pacs.008 (payments clearing and settlement message 008) the bank later sends onward. A single pain.001 is organised in layers: a group header with a message identifier, a creation timestamp, and a count of transactions; one or more payment blocks, each naming the debtor, the account to pay from, and a requested execution date; and inside each block, one or more credit transfers, each with an amount, a creditor, a creditor account, and remittance information. Because one file can hold many payments from one account, a company can send an entire supplier run or payroll in a single message. The bank replies with a pain.002 (Customer Payment Status Report) telling the sender whether the file and each payment were accepted, rejected, or are still pending.
Complete lesson / 02
Understand the full idea, step by step
When Asha Traders runs payroll or pays a batch of suppliers, nobody keys in each transfer at a bank counter. One file leaves the company's system, one account is debited, and dozens of beneficiaries are paid. That file has a name in ISO 20022: the pain.001. It is where a credit transfer begins.
pain.001 — payment initiation message 001 — the Customer Credit Transfer Initiation
The pain.001 is the instruction a customer or corporate sends to its own bank asking for money to be paid out. Because it is a customer-to-bank message, it sits one step before the interbank world: the bank that receives a pain.001 turns each requested payment into an interbank pacs.008 to move it between institutions. So pain is the customer's request; pacs is what banks exchange to carry it out. The two are different messages for different legs — not the same message renamed.
Read the steps as text
- 01MessageThe payer asks their bank to payPayer → Bank Alfa (payer's bank)
Using an app or a branch, the payer gives their bank an instruction: pay this person, at that bank, this amount. Nothing has moved yet — it is only a request.
- 02ProcessingBank Alfa checks the instructionBank Alfa (payer's bank)
Is the account number valid? Is there enough money? Is anything suspicious? Banks check before they promise.
- 03PostingThe payer's balance goes downBank Alfa (payer's bank)
Bank Alfa reduces the payer's balance. Important: the payee does not have the money yet — it has only left the payer.
- DR Payer's account at Bank Alfa — EUR 200.00
- 04MessageThe instruction travels to the clearing systemBank Alfa (payer's bank) → Clearing system
Banks do not call each other one by one. They send payment messages to a shared clearing system that connects them all.
- 05Clearing obligationThe clearing system adds everything upClearing system
Thousands of payments flow both ways between the banks. The clearing system works out who owes whom overall — a tally, not yet a movement of money.
Clearing decides who owes what. Settlement — the next step — actually moves the money.
- 06SettlementThe banks settle upBank Alfa (payer's bank) → Nordbank (payee's bank)
Bank Alfa's account at the central bank goes down; Nordbank's goes up. Now — and only now — has money truly moved between the banks.
- DR Bank Alfa's account at the central bank — EUR 200.00
- CR Nordbank's account at the central bank — EUR 200.00
- 07MessageNordbank receives the detailsClearing system → Nordbank (payee's bank)
The message tells Nordbank exactly whose account to credit and with how much.
- 08PostingThe payee's balance goes upNordbank (payee's bank)
Nordbank credits the payee. The journey is complete: payer down, banks settled, payee up.
- CR Payee's account at Nordbank — EUR 200.00
The three nested layers inside the file
- INSTRUCTION
Group header — appears once, describing the file as a whole: a message identifier that names the file, a creation date and time, the number of transactions, an optional control sum, and the initiating party.
- INSTRUCTION
Payment information — one or more blocks, each grouping payments that share instructions: the debtor, the debtor's account and bank, the payment method, the requested execution date, and charges handling.
- INSTRUCTION
Credit transfer transaction information — one entry per payment: the amount and currency, the creditor, the creditor's account and bank, an end-to-end identifier the customer sets, and the remittance information saying what the payment is for.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
Notice the roles: the initiating party is whoever submits the file, while the debtor is whose account is charged — often the same party, but not always. A payments bureau can be the initiating party for its client, the debtor. Keeping them distinct tells the bank who instructed the payment and whose money moves.
You may be wondering: if one file can hold many payments, is it all-or-nothing — accepted or refused as a block?
No. The reply reports at two levels: a status for the whole group, and a status for each individual transaction. So a file of eight can have seven accepted and one rejected, each with its own outcome. That is exactly why corporates trust one file for a whole supplier run — a single bad account number does not sink the other seven payments.
The reply: the pain.002 status report
An instruction needs an answer. For the pain.001, that answer is the pain.002 (Customer Payment Status Report), sent back to whoever submitted the file. Its statuses form a short standard vocabulary — including ACCP (accepted after initial checks), ACSP (accepted, settlement in process), PDNG (pending), and RJCT (rejected). A rejection carries a status reason code such as AC01 (incorrect account number) or AC04 (closed account), drawn from a shared external list so both sides read the cause the same way. Each status ties back to the original payment through the end-to-end identifier, so a rejection matches the exact transfer it came from. The pain.002 is the customer-facing counterpart to the interbank pacs.002.
COMMON CONFUSION
“Sending the pain.001 means the money has left and the suppliers are paid.”
The pain.001 is a request to Bank Alfa, not the payment itself. The bank must validate it, debit the account, and send interbank pacs.008 messages onward; each supplier is paid only when their bank credits them. And like every message here, the pain.001 carries an instruction, not the funds.
STRICTLY SPEAKING
Strictly speaking, the exact status and reason-code values a bank may return, and which pain.001 version and fields it accepts, are set by the message version and the bank's implementation guideline. The status vocabulary and reason codes come from ISO 20022 external code lists that are revised over time, so confirm the current list rather than memorising one set.
FOR NOW, REMEMBER
- The pain.001 is a customer-to-bank credit transfer initiation — the request that starts a payment, one step before the interbank pacs.008.
- One file can carry many payments, nested as group header, payment information, and per-transaction detail, sharing common instructions once.
- It separates the initiating party (who submits) from the debtor (whose account is charged).
- The pain.002 replies at group and transaction level, with standard status and reason codes tied back by end-to-end identifier — so a batch can be partly accepted.
TRY IT YOURSELF
Bank Alfa returns a pain.002 for Asha Traders' file of eight: seven transactions show `ACSP`, and one shows `RJCT` with `AC04`. What has happened, and what should Asha Traders do?
You have followed one message family into the bank. SEPA uses pain, pacs, and camt together — the next lesson shows how the three fit around a single euro payment.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
A pain.001 is a customer-to-bank instruction to make one or many credit transfers, distinct from the interbank pacs.008 the bank sends onward.
- 02
It is organised in layers: a group header, one or more payment blocks each with a debtor and a requested execution date, and the individual credit transfers inside them.
- 03
The bank answers with a pain.002 status report that reports acceptance, rejection, or pending status for the whole file and each transaction.
Practical use cases / 04
Where you would use this
A corporate treasury sends a single pain.001 containing an entire supplier payment run from one account with one requested execution date.
A payroll bureau initiates hundreds of salary payments in one pain.001 and reconciles the pain.002 to confirm which were accepted.
A bank's channel team validates an incoming pain.001 against the schema and returns a pain.002 flagging any transaction that failed a check.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional company, Brightwater Logistics Ltd, sends its bank a single pain.001 to pay 3 suppliers from one account on a requested execution date of 20 July 2026. The group header states 3 transactions and a control sum of EUR 47,250.00. The three credit transfers are EUR 12,500.00, EUR 18,750.00, and EUR 16,000.00, each naming its creditor, the creditor's account, and an invoice reference. The bank validates the file and replies with a pain.002. Two transactions are accepted with the status ACCP (accepted), but the EUR 16,000.00 payment is rejected with the status RJCT (rejected) and the reason code AC01 (incorrect account number), because the creditor account failed its check. Brightwater Logistics Ltd corrects that one account and resubmits only the EUR 16,000.00 payment, leaving the two accepted transfers to proceed.
Evidence & review / 07
Evidence & review
ISO 20022 pain.001 / pain.002 generally; accepted versions and returned code subsets are set by each bank's implementation guideline.
What this brief simplifies: Describes the three-layer structure and a representative status set rather than the complete element list; scenario amounts are illustrative.
Sources for this brief3
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain.001 Customer Credit Transfer Initiation; pain.002 Customer Payment Status Report
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Status and status-reason code lists
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.