GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
PAYMENTSSIGNAL

The interactive academy for the standards, messages, and rails that move money.

GET IN TOUCH
04 / ISO 20022 & CBPR+18 MIN

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.

Contributor Shubham Mathure

NOT STARTED

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
  1. Official requirement

    ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs business area message definitions

    Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12

    Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.

  2. Official requirement

    Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.008 and pacs.009 usage guidelines

    Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12

    Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.

  3. Simplified educational illustration

    Payments Signal editorial teaching models — Payments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    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

SEPA Credit Transfer — swimlane diagramA euro credit transfer from one customer to another through a clearing and settlement mechanism, from initiation to the beneficiary's credit. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
SEPA Credit Transfer. One CSM, one settlement cycle, direct participants only. Real SEPA processing batches many payments and may involve indirect participation through another bank. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    The debtor initiates the transferDebtor (payer) → Bank Alfa (debtor agent) · pain.001

    The customer instructs their bank to pay. A corporate typically sends a pain.001 file; a retail customer uses a banking channel that creates the same instruction internally.

  2. 02Processing
    Bank 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.

  3. 03Posting
    The 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
  4. 04Message
    Bank Alfa submits the interbank transferBank Alfa (debtor agent) → Clearing & settlement mechanism · pacs.008

    The debtor agent converts the customer instruction into an interbank pacs.008 and submits it to the clearing and settlement mechanism.

  5. 05Clearing obligation
    The 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.

  6. 06Settlement
    Positions 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
  7. 07Message
    The CSM delivers the transfer to NordbankClearing & settlement mechanism → Nordbank (creditor agent) · pacs.008

    The creditor agent receives the pacs.008 with full payment details so it can credit the right account.

  8. 08Processing
    Nordbank 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.

  9. 09Posting
    The 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
CBPR+ cross-border transfer (pacs.008) — swimlane diagramA cross-border customer credit transfer in ISO 20022 under CBPR+ usage guidelines, tracked end to end by its UETR. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
CBPR+ cross-border transfer (pacs.008). One intermediary agent and a single settlement venue. Investigation messages are shown generically; specific case-management message choreography varies by corridor and era. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    The debtor initiates the cross-border paymentDebtor (payer) → Bank Alfa (debtor agent) · pain.001

    A corporate treasury sends a pain.001 with structured party and remittance data — the structure survives the whole journey because every hop speaks ISO 20022.

  2. 02Processing
    Bank 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.

  3. 03Message
    The pacs.008 leaves with a BAH and UETRBank Alfa (debtor agent) → Meridian Bank (intermediary agent) · pacs.008

    The interbank message travels with a Business Application Header and a UETR — the end-to-end reference every bank keeps unchanged, making the payment trackable.

  4. 04Processing
    Meridian 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.

  5. 05Settlement
    The 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
  6. 06Message
    The pacs.008 continues to the creditor agentMeridian Bank (intermediary agent) → Cassia Bank (creditor agent) · pacs.008

    The same UETR arrives at Cassia; anyone with the reference can see where the payment is in the chain.

  7. 07Processing
    Cassia validates the incoming paymentCassia Bank (creditor agent)

    Inbound screening and account checks before the credit is applied.

  8. 08Posting
    The 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
  9. 09Message
    A confirmation closes the loopCassia Bank (creditor agent) → Bank Alfa (debtor agent) · pacs.002

    A status confirmation tells the debtor agent the payment completed — the debtor can be told with certainty rather than silence.

CBPR+ corporate payment — full MX lifecycle — swimlane diagramOne corporate payment from pain.001 initiation through pacs.008 execution, status, settlement, exceptions, and camt account reporting — with every conditional step labelled. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
CBPR+ corporate payment — full MX lifecycle. A teaching composite across customer initiation, CBPR+ execution, Case Management, and bank-to-customer reporting. Not every bank sends every status or report, and mutually exclusive reject, return, and recall outcomes are shown as branches. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    Treasury sends the payment instructionAsha Traders treasury → Bank Alfa (debtor agent) · pain.001

    Asha Traders asks Bank Alfa to pay one supplier. The pain.001 is a customer instruction, not an interbank payment and not proof that funds moved.

  2. 02Processing
    Bank Alfa validates the instructionBank Alfa (debtor agent)

    The bank checks authority, account and address data, duplicate references, available funds, cut-off time, and sanctions-screening results before accepting the instruction.

    Screening checkpoint: Customer-payment screening — Debtor, creditor, agents, addresses, and remittance data are screened before release.

  3. 03Message
    Treasury receives an accepted statusBank Alfa (debtor agent) → Asha Traders treasury · pain.002

    A pain.002 says the instruction passed the reported checks and was accepted for processing. It does not say the supplier has been credited; banks choose which lifecycle statuses their service reports.

  4. 04Posting
    Bank Alfa debits the corporate accountBank Alfa (debtor agent)

    Bank Alfa books the customer debit. The debit and the interbank settlement are separate ledger events and can occur at different times under the account agreement.

    • DR Asha Traders USD operating account — USD 125,000.00
  5. 05Message
    Treasury receives an entry notificationBank Alfa (debtor agent) → Asha Traders treasury · camt.054

    Where the service provides it, a camt.054 reports the booked debit promptly and carries structured references for cash application. It reports an account entry; it does not create the entry.

  6. 06Message
    Bank Alfa sends the interbank paymentBank Alfa (debtor agent) → Meridian Bank (correspondent) · pacs.008

    Bank Alfa turns the accepted customer instruction into a pacs.008. The UETR, end-to-end reference, parties, agents, amounts, and remittance data identify the same business payment on the interbank leg.

  7. 07Processing
    Meridian validates and screens the paymentMeridian Bank (correspondent)

    The correspondent applies CBPR+ validation, sanctions screening, routing checks, and a cover check before it books or forwards the payment.

    Screening checkpoint: Correspondent screening — Every bank in the chain makes its own decision; an upstream pass does not bind a downstream bank.

  8. 08Settlement
    The correspondent settles the interbank legMeridian Bank (correspondent)

    Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. This book transfer is the value movement; the pacs.008 is the instruction describing it.

    This teaching corridor uses correspondent-book settlement in commercial bank money. Other CBPR+ payments may use different correspondents or market infrastructures.

    • DR Bank Alfa USD account at Meridian — USD 125,000.00
    • CR Nordbank USD account at Meridian — USD 125,000.00
  9. 09Message
    The payment reaches NordbankMeridian Bank (correspondent) → Nordbank (creditor agent) · pacs.008

    Meridian forwards the customer credit transfer with the original UETR and structured payment data so Nordbank can identify the supplier and reconcile the incoming cover.

  10. 10Processing
    Nordbank validates the incoming paymentNordbank (creditor agent)

    Nordbank checks the supplier account, screens the payment, and confirms that the incoming value and instruction can be matched before it credits the customer.

  11. 11Posting
    Nordbank credits the supplierNordbank (creditor agent)

    Nordbank books the credit to Northstar Components. The supplier can now use the funds; any later recovery request must respect that settled and credited state.

    • CR Northstar Components USD account — USD 125,000.00
  12. 12Message
    An interbank status closes the processing loopNordbank (creditor agent) → Bank Alfa (debtor agent) · pacs.002

    Where the service and status point provide it, a pacs.002 reports the interbank outcome against the original pacs.008. A transport acknowledgement and a payment status are different signals.

  13. 13Message
    Treasury receives the intraday account reportBank Alfa (debtor agent) → Asha Traders treasury · camt.052

    If contracted, camt.052 gives Asha an intraday view of balances and entries, including the debit and its references. It is an interim report, not the final daily statement.

  14. 14Message
    The end-of-day statement closes reconciliationBank Alfa (debtor agent) → Asha Traders treasury · camt.053

    Bank Alfa sends the booked statement for the account. Treasury matches the camt.053 entry to its pain.001 transaction using the end-to-end and account-servicer references.

MESSAGES INVOLVED

Sources for this topic3
  1. Official requirement

    ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs business area message definitions

    Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12

    Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.

  2. Official requirement

    Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border usage of pacs messages

    Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12

    Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.

  3. Simplified educational illustration

    Payments Signal editorial teaching models — Payments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    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.