PAIN vs pacs in ISO 20022: The Difference Every Payments Analyst Should Know

When I started in payments, everyone around me threw around “pain dot oh oh one” and “pacs dot oh oh eight” like I was supposed to already know the difference. Nobody slowed down to explain it. I nodded along in meetings, mapped fields I half understood, and eventually watched a developer burn two days chasing a “missing field” that was never missing. The business had signed off on a pain.001. The integration team was testing against pacs.008. Both sides swore the other had broken the contract. Neither had. They were looking at two different messages describing the same payment from two different vantage points, and no one had drawn the line between them.

The short answer: pain messages move between a customer and their bank, and pacs messages move between banks. Same payment, two different vantage points. That single boundary between the customer space and the interbank space is one of the most useful things a technical BA can carry into any ISO 20022 conversation. Once you see where one ends and the other begins, half the “weird” requirements in a payments backlog stop being weird.

This article walks the full picture: the prefix system, the four core messages (pain.001, pain.002, pacs.008, pacs.002), the rest of the interbank family, where camt reporting fits, a worked field-mapping example, and the mistakes that cost teams days.

What do the ISO 20022 prefixes mean?

ISO 20022 message identifiers look intimidating until you realize the first four letters tell you which business domain you are in. The prefix is a business area code, and the digits that follow identify the specific message and its variant. For payments you mostly deal with a handful of prefixes.

pain stands for Payments Initiation. These messages move between a customer and their bank. A corporate treasury system, an ERP, a retail banking app: anything on the customer side talking to the bank uses pain messages.

pacs stands for Payments Clearing and Settlement. These messages move between banks, or between banks and a clearing system or market infrastructure. The customer never sees a pacs message. It lives entirely in the interbank space.

camt stands for Cash Management. These messages report on accounts and payments: statements, balances, notifications, and investigations. They do not initiate or settle a payment, they describe what happened to it.

So before you read a single field, the prefix already tells you who is talking to whom. pain is customer-to-bank. pacs is bank-to-bank. camt is reporting. Confusing the first two is the single most common mistake I see analysts make when they first touch payments, and it is exactly what burned my team in that two-day defect.

pain.001: the instruction the customer hands the bank

A pain.001 is a Customer Credit Transfer Initiation. In plain terms, it is the message a customer sends to its bank to say “please pay these people on my behalf.”

Picture a corporate running payroll. The treasury system bundles up two thousand salary payments into a single pain.001 and submits it to the bank. The message carries the debtor (the corporate), the debtor’s account, and then a batch of credit transfer transactions, each with a creditor, a creditor account, an amount, and a remittance reference so the receiver knows what the payment is for.

Two things matter here for a BA. First, a pain.001 is an instruction, not a settled payment. The customer is requesting that the bank act. Nothing has moved yet. Second, the structure is built for batching. One pain.001 can hold many payments grouped under payment information blocks (the PmtInf level), which is why corporate ERP integrations care so much about how those groups map to execution dates and debit accounts.

When you are writing requirements for an onboarding channel, host-to-host file ingestion, or an API that accepts customer payment instructions, you are almost always living in pain.001 territory. The grouping rules, the validation on debtor account, and the handling of mixed currencies in one file: that is all customer-space analysis.

pacs.008: the same payment, now between banks

Once the bank accepts that pain.001, it does not forward the customer’s message onward. It generates a new message in a different domain. For a customer credit transfer, that message is a pacs.008, the FI to FI Customer Credit Transfer.

The “FI to FI” part is the key. This is financial institution to financial institution. The debtor agent (the customer’s bank) sends a pacs.008 to the creditor agent (the beneficiary’s bank), often routed through a clearing system or a network like SWIFT under CBPR+ or a domestic instant scheme.

Here is the mental model that fixes everything: one customer instruction can fan out into many interbank messages. That payroll pain.001 with two thousand transactions does not become one pacs.008. It becomes potentially two thousand individual pacs.008 messages, one per beneficiary, each routed to whichever bank holds the beneficiary account. The customer thinks “I sent one file.” The interbank world sees “two thousand separate settlement instructions.”

This fan-out is why field mapping between pain and pacs is never one-to-one, and why my team’s “missing field” was not missing at all. A field that is mandatory and structured in the customer space might be carried differently, derived, or enriched by the bank before it appears in the interbank message. The bank adds agent information, settlement details, and clearing identifiers that the customer never provided. The two messages are relatives, not copies.

If you are mapping these flows for the first time, build a side-by-side field comparison early. Doing it in a blank spreadsheet every time is how fields go missing, so start from a structured template. I keep a set of cross-message mapping templates in the guides.

The rest of the interbank family: pacs.009, pacs.004, pacs.007

pacs.008 is the one everyone learns first, but the interbank space has siblings worth knowing, because requirements often touch them.

pacs.009 is the Financial Institution Credit Transfer. Where pacs.008 moves a customer’s payment, pacs.009 moves a payment where the debtor and creditor are themselves financial institutions. Bank-to-bank treasury movements and cover payments live here.

pacs.004 is the Payment Return. When a pacs.008 cannot be applied, for example the beneficiary account is closed, the receiving bank returns the funds with a pacs.004, carrying a reason code and a reference back to the original. Returns are their own analysis topic, because the money flows in the opposite direction and the original UETR has to be preserved for tracking.

pacs.007 is the FI to FI Payment Reversal, used to reverse a payment that was sent in error. It is not the same as a return: a reversal unwinds the original instruction, while a return sends value back as a new movement.

You do not need every variant memorized, but knowing that returns and reversals are distinct messages with distinct reason codes saves you from modeling them as a single “failure” state in a backlog.

pain.002 and pacs.002: the two messages that report status

Now the symmetry gets satisfying. Both the customer and interbank domains have a status report message, and they sit at the same position in their respective worlds.

pain.002 is the Customer Payment Status Report. The bank sends it back to the customer to say what happened to the pain.001: accepted, rejected, partially accepted, or pending. If the payroll file had three transactions with invalid account numbers, the pain.002 is where the corporate finds out, usually with a reason code pointing at the offending transactions. This is the message your customer-facing channel needs to parse and surface in a UI, and it is the message that drives “why did my payment fail” support tickets.

pacs.002 is the FI to FI Payment Status Report. It does the same job, but between banks. The creditor agent or the clearing system sends a pacs.002 back upstream to confirm whether the pacs.008 was accepted or rejected for settlement. Real-time schemes lean heavily on pacs.002 because the whole point is an instant accept or reject answer at the interbank layer.

So the full picture for a credit transfer looks like this. The customer sends a pain.001. The bank responds with a pain.002 to acknowledge the instruction. The bank then generates pacs.008 messages to other banks, and receives pacs.002 messages back confirming settlement status. The customer’s pain.002 might even be informed by what comes back in the pacs.002, which is why timing and status reconciliation between the two domains is a real requirement and not a theoretical one. Validating that reconciliation end to end is squarely QA analyst territory.

Message	Domain	Direction	Purpose
pain.001	Customer space	Customer to bank	Initiate a credit transfer
pain.002	Customer space	Bank to customer	Report status of the initiation
pacs.008	Interbank space	Bank to bank	Move the credit transfer between FIs
pacs.002	Interbank space	Bank to bank	Report settlement status
pacs.004	Interbank space	Bank to bank	Return a payment that could not be applied
camt.053	Customer space	Bank to customer	End-of-day account statement

Where do camt messages fit?

pain initiates, pacs settles, and camt reports. Once a payment has moved, the customer still needs to know it landed and reconcile it against their books. That is camt territory.

camt.053 is the Bank to Customer Statement, the structured end-of-day statement a corporate loads into its ERP to reconcile. camt.052 is the intraday Account Report. camt.054 is the Debit Credit Notification, a near real-time “this hit your account” message. On the investigation side, camt.056 requests the recall of a payment, and camt.029 resolves that investigation.

For a BA, the lesson is that reconciliation and exceptions are a third domain. If a requirement is about “show the customer their incoming payments” or “let them recall a payment,” you are no longer in pain or pacs, you are in camt, and the data you need may have to be stitched across all three.

A worked example: mapping pain.001 to pacs.008

Abstract definitions only get you so far. Here is the kind of mapping that shows up in a real migration backlog.

A corporate submits a pain.001 with one payment: pay 10,000 EUR to a supplier, with invoice number INV-4471 in the remittance information and an end-to-end id the corporate generated. Walk the key fields across the boundary:

• The Debtor and Debtor Account from the pain.001 become the Debtor and Debtor Account in the pacs.008, but the bank now also populates the Debtor Agent (itself) with a BIC the customer never supplied.
• The Instructed Amount the customer gave becomes the Interbank Settlement Amount (IntrBkSttlmAmt), and the bank adds a Settlement Date and settlement method that did not exist in the customer message.
• The End To End Id the corporate set is preserved so the two ends can be tied together, and a UETR rides along to trace the payment across the whole chain.
• The Remittance Information carrying INV-4471 must survive intact, because the beneficiary reconciles on it. If a channel truncates structured remittance into a shorter free-text field, that is the classic defect, and it is invisible unless you are comparing both messages.

That single payment shows the pattern: some fields copy across, some are enriched by the bank, and some are derived. Multiply it by a batch and you see why the customer’s “one file” and the interbank “many instructions” never line up field for field.

Why this distinction shows up in real backlogs

This is not academic. The pain versus pacs boundary shapes requirements constantly.

Status mapping is the obvious one. A pacs.002 rejection from a downstream bank has to be translated into something meaningful in a pain.002 for the customer. The reason codes are not always identical across the boundary, and deciding how to map them is a genuine analysis task with compliance implications.

Reference and remittance data is another. The customer cares about an invoice number in the remittance fields of pain.001. By the time the payment is a pacs.008, that data needs to survive intact so the beneficiary can reconcile. Truncation or loss of remittance data across the pain to pacs hop is a classic defect, and it is exactly the kind of thing you only catch if you understand both messages are in play.

Then there is timing and idempotency. Because one pain.001 fans out into many pacs.008 messages, partial failures are normal. Five of two thousand payments fail at the interbank layer. The customer needs a clear pain.002 that says “1,995 accepted, 5 rejected” with reasons, while the bank’s internal state tracks each pacs.008 and pacs.002 independently. Designing that reconciliation across services is a systems analyst problem as much as a BA one.

Common mistakes analysts make

A few patterns come up again and again with analysts new to payments:

• Treating pain.001 and pacs.008 as the same message with a rename, then writing one set of field requirements for both.
• Modeling returns (pacs.004) and reversals (pacs.007) as a single generic “failed payment” status.
• Assuming one customer instruction equals one interbank message, which breaks as soon as a batch fans out.
• Losing the UETR or End To End Id across the hop, which makes a payment impossible to trace later.
• Putting reconciliation requirements in the pacs flow when they actually belong in camt.

The mental model to keep

Strip everything else away and hold onto a few sentences. pain messages live between a customer and a bank, where payments are initiated and their status is reported to the customer. pacs messages live between banks, where payments are cleared, settled, and their status is reported across institutions. camt messages report on accounts and payments after the fact.

pain.001 initiates, pain.002 reports back to the customer. pacs.008 settles between banks, pacs.002 reports back across the interbank chain. The four core messages are two matched pairs sitting on opposite sides of the bank, describing the same money on its journey from one account to another.

Get that boundary clear in your head and you will never spend two days hunting a field that was never missing.