The pacs family: interbank messages
The interbank workhorses: pacs.008 and pacs.009 move value, pacs.002 reports status, and pacs.004 brings money back.
L0 Explain simply
Analogy: if the pain.001 was the customer's order slip, pacs messages are the freight documents exchanged between transport companies. The customer never sees them, but they do the actual moving. A pacs.008 is a parcel with a customer's goods inside — the paperwork names the real sender and the real recipient. A pacs.009 is a container one transport company sends to another for its own business — sometimes as the "cover" that pays for a parcel travelling separately by a different route. A pacs.002 is the status slip: "accepted" or "refused at the depot". And a pacs.004 is the returned parcel, coming back with a note explaining why it could not be delivered.
L1 Core concepts
pacs stands for payments clearing and settlement: the interbank space. pacs.008 is the FI-to-FI customer credit transfer — an underlying customer is being paid, so full debtor and creditor detail travels with it. pacs.009 is the financial institution credit transfer: banks moving money between themselves, either settling their own obligations or providing cover for a customer payment routed separately (the COV usage, which embeds the underlying customer details so intermediaries can screen them). pacs.002 is the FI-to-FI payment status report, carrying accepts and rejects. pacs.004 is the payment return, which moves already-settled funds back toward where they came from, with a reason code attached.
L2 Practitioner view
Practitioners map these to the MT world: pacs.008 does the job of the MT103, pacs.009 that of the MT202, and pacs.009 COV that of the MT202 COV. The differences matter, though. A pacs.008 distinguishes the instructed amount from the interbank settlement amount, so deducted charges are visible rather than inferred. Agents are explicit named roles — instructing, instructed, previous, and intermediary agents — instead of position-coded fields. A UETR travels end to end for tracking. Status handling also differs by rail: in an instant payment scheme, the pacs.002 is the make-or-break accept or reject within seconds; in correspondent banking, a negative pacs.002 is a reject before settlement, while a pacs.004 unwinds a payment after settlement. Reject and return are different events with different accounting.
L3 Technical details
Structure worth studying in a real message: the group header carries the settlement method, which declares how the interbank obligation settles — across a clearing system, across accounts the two agents hold with each other, or via a separate cover message. The transaction block carries the amounts, the charge bearer, the agent chain, purpose codes, and structured or unstructured remittance data. On returns, a pacs.004 references the original message and transaction identifiers plus the original UETR, and carries a return reason from the external code set. The returned amount can be lower than the original if fees were deducted along the way — a frequent reconciliation trap. Version pinning is real: each scheme or service names the exact pacs.008.001 version it accepts, so "we support pacs.008" is always an incomplete statement.
L4 Standards & sources
The message definitions — every element, its multiplicity, its data type — are published in the ISO 20022 catalogue maintained by the ISO 20022 Registration Authority. But the catalogue deliberately permits far more than any network accepts: usage guidelines such as CBPR+ for correspondent banking remove optional elements, pin versions, and narrow code lists, and it is the guideline, not the base standard, that decides whether a message passes validation on a given rail. When you need an authoritative answer about a field, check the usage guideline for the specific rail first, then the catalogue for the underlying definition. Our four-message summary is itself a simplification: the pacs family contains further messages, and each message has scheme-specific usage variants.
Sources & standards3
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs business area message definitions
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.008 and pacs.009 usage guidelines
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: We present a four-message core (pacs.008, pacs.009, pacs.002, pacs.004); the pacs family includes additional messages, and element-level rules vary by scheme usage guideline.
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.
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
Read the steps as text
- 02ProcessingBank Alfa validates, screens, and debitsBank Alfa (debtor agent)
Checks and screening run on rich, structured fields — one of ISO 20022's main gains. The customer account is debited on acceptance.
- DR Debtor's account at Bank Alfa — USD 1,250,000.00
Screening checkpoint: Outbound screening on structured data — Structured names and addresses screen more precisely than free-text lines, cutting false positives.
- 04ProcessingMeridian screens in the middle of the chainMeridian Bank (intermediary agent)
The intermediary agent screens the structured parties and checks cover on Bank Alfa's account.
- 05SettlementThe correspondent settles across its booksMeridian Bank (intermediary agent)
Settlement is a book transfer between the two banks' USD accounts at Meridian — same mechanics as the MT world; the message standard changed, the money movement did not.
- DR Bank Alfa's USD account at Meridian (vostro) — USD 1,250,000.00
- CR Cassia's USD account at Meridian (vostro) — USD 1,250,000.00
- 07ProcessingCassia validates the incoming paymentCassia Bank (creditor agent)
Inbound screening and account checks before the credit is applied.
- 08PostingThe creditor is creditedCassia Bank (creditor agent)
The structured remittance information lets the creditor reconcile the invoice automatically.
- CR Creditor's account at Cassia — USD 1,250,000.00
Sources for this topic3
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs business area message definitions
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border usage of pacs messages
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The freight-document analogy and the four-message framing compress the pacs family; additional pacs messages and scheme-specific variants exist.
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.