pain.001 vs pacs.008: Who Sends What

If you work with ISO 20022 for any length of time, you will run into two message types over and over: pain.001 and pacs.008. They are both about credit transfers, they carry overlapping data, and they are constantly mixed up. But they live in different parts of the payment chain and are sent by different actors. Getting the distinction right is essential to building correct integrations. This post explains who sends what, and how the two messages relate.

The two message families

ISO 20022 organises messages into business areas identified by a four-letter prefix. Two of the most important for credit transfers are:

• pain — PAyment INitiation. Messages exchanged between a customer (or corporate) and its own bank.
• pacs — PAyments Clearing and Settlement. Messages exchanged between financial institutions to actually clear and settle the payment.

So the prefix already tells you the domain: pain is the customer-to-bank space, and pacs is the interbank space. The number after the prefix identifies the specific message, and a version suffix follows, for example pain.001.001.09.

pain.001: the instruction from customer to bank

The pain.001, formally the CustomerCreditTransferInitiation, is how a payer instructs its bank to make one or more credit transfers. A corporate treasury system typically generates a pain.001 file containing a group header, one or more payment information blocks (grouping payments that share a debit account and execution date), and the individual credit transfer transactions with the beneficiaries.

Key characteristics of pain.001:

• It flows from the debtor to the debtor's bank. It never travels between banks.
• It can be a bulk file: one message may request many payments in a single batch.
• It expresses an intention — the customer wants these payments made — not a settled fact.
• Its lifecycle is often acknowledged with a pain.002 (PaymentStatusReport) that tells the customer whether the initiation was accepted or rejected.

pacs.008: the transfer between banks

The pacs.008, formally the FIToFICustomerCreditTransfer, is the interbank message that actually carries the payment from the debtor's bank to the creditor's bank, usually through a clearing system or market infrastructure. When your bank receives your pain.001, it decides which rail to use and generates the corresponding pacs.008 to move the money.

Key characteristics of pacs.008:

• It flows between financial institutions (FI to FI), often via a payment system operator.
• It is typically one payment per message in real-time contexts, though some clearing systems bundle them.
• It carries settlement information — how and when the banks settle — alongside the debtor and creditor details.
• In modern schemes it is wrapped with a Business Application Header (head.001) that carries routing and identification metadata.

How they chain together

Picture a corporate paying a supplier abroad. The flow looks like this:

• The corporate's ERP emits a pain.001 to its bank requesting the payment.
• The bank validates it and returns a pain.002 status report.
• The bank generates a pacs.008 and sends it into the clearing system toward the beneficiary's bank.
• Interbank status may be reported with a pacs.002, and returns handled by pacs.004.
• The beneficiary's bank credits the supplier and may notify them with a camt statement or advice message.

One customer intention (pain.001) can therefore spawn many interbank transactions (pacs.008), one for each payment in the batch. The debtor and creditor identity data carries through, but the sender and receiver of the message change from customer-to-bank to bank-to-bank.

Why the distinction matters in practice

Mixing these up leads to real bugs. If you are building a corporate payment integration, you produce and consume pain messages; you generally never emit a pacs.008 unless you are a bank or a payment institution connected to a clearing system. If you are building scheme connectivity, you live in the pacs world and must handle the Business Application Header, settlement fields, and interbank status messages. Knowing which side of the customer-bank boundary you sit on tells you exactly which messages you own.

Key takeaways

• pain.001 is a customer-to-bank payment initiation; pacs.008 is a bank-to-bank credit transfer.
• The prefix reveals the domain: pain = payment initiation, pacs = clearing and settlement.
• A single pain.001 batch can generate many individual pacs.008 messages, one per payment.
• pain.001 is acknowledged by pain.002; pacs.008 flows with a BAH and is tracked by pacs.002 and pacs.004.
• Which messages you own depends on whether you sit on the customer or the interbank side of the chain.