pacs.008ISO 20022

pacs.008 — FI to FI Customer Credit Transfer

Carries a customer credit transfer between financial institutions — the interbank leg of a payment where the debtor, the creditor, or both are non-bank customers. It is the ISO 20022 counterpart of the MT103: it moves the payment obligation from the debtor agent toward the creditor agent, carrying the customer parties, amounts, charging arrangement, and remittance information with it.

DIRECTION: Sent by the debtor agent (or an instructing agent acting for it) to the next agent in the chain — directly, through intermediary agents, or through a clearing and settlement mechanism — until it reaches the creditor agent, which credits the creditor.

Contributor Shubham Mathure16 July 2026

WHO IS INVOLVED

Debtor agentDebits the customer, applies its controls, and originates the interbank message — usually from an accepted customer instruction such as pain.001.
Instructing / instructed agentThe sender and receiver of each individual hop. These roles shift at every leg of the chain, while debtor agent and creditor agent stay fixed.
Intermediary agentIn correspondent chains, receives the message, screens it, settles its leg, and passes it on.
Creditor agentRuns its own validation and screening, then credits the creditor's account or triggers an exception message.
Debtor and creditorThe customers at each end. They never send or receive pacs.008 themselves — they travel inside it as data.

KEY FIELDS

This is a curated teaching subset — the full pacs.008 message definition contains many more elements, including further intermediary agents, instructed and exchange-rate elements, regulatory reporting, and ultimate parties. Requirement flags summarise the single context named on each field; versions and scheme profiles differ, so always check the official ISO 20022 message definition and the usage guideline that actually governs your traffic.

Key fields of pacs.008
FIELD	NAME	PRESENCE	WHAT IT MEANS
`GrpHdr/MsgId`	Message identification	MANDATORYBase ISO 20022 message definition	A unique reference for this message, assigned by the instructing agent. It changes at every hop; end-to-end references live at transaction level.Point-to-point duplicate detection keys on MsgId between adjacent agents. It is not the reference to quote to the customer.⚠ Confusing MsgId with EndToEndId in reconciliation logic breaks matching as soon as a payment crosses more than one hop.
`GrpHdr/CreDtTm`	Creation date and time	MANDATORYBase ISO 20022 message definition	When this message was created — a timestamp for the message, distinct from the settlement date of the payment.
`GrpHdr/NbOfTxs`	Number of transactions	MANDATORYBase ISO 20022 message definition	How many credit transfer transactions the message contains.The base standard allows batches, but usage guidelines differ: the correspondent-banking usage constrains a message to a single transaction, while some market infrastructures permit more. Check the guideline in force.
`GrpHdr/SttlmInf/SttlmMtd`	Settlement method	MANDATORYBase ISO 20022 message definition	How the interbank settlement of this payment happens: INDA (settled on an account the instructed agent services), INGA (on an account the instructing agent services), CLRG (through a clearing system), or COVE (through a separate cover payment).COVE is the signal that a pacs.009 COV is travelling separately to move the funds — the receiving bank should expect to match the two.⚠ A settlement method that contradicts the actual account relationship between the two agents causes settlement fails and investigations.
`CdtTrfTxInf/PmtId/EndToEndId`	End-to-end identification	MANDATORYBase ISO 20022 message definition	The reference assigned by the original instructing party. It must travel unchanged through every agent to the creditor.This is the reference that survives from pain.001 through pacs.008 to the creditor's statement, and the one echoed back in pacs.002, pacs.004, and camt.056.⚠ Agents that overwrite EndToEndId with their own references destroy end-to-end reconciliation for everyone downstream.
`CdtTrfTxInf/PmtId/UETR`	Unique end-to-end transaction reference	MANDATORYCBPR+ usage guidelines — optional in the base ISO 20022 message definition	A globally unique identifier (a UUID) for the payment, used to track it across the whole chain regardless of how many hops it takes.The Swift gpi Tracker follows payments by UETR. Every agent must pass it on unchanged; a payment's status queries, cancellations, and confirmations all key on it.⚠ Generating a fresh UETR at an intermediate hop silently forks the tracking history — the payment looks stuck to the originator and orphaned to the tracker.
`CdtTrfTxInf/IntrBkSttlmAmt`	Interbank settlement amount	MANDATORYBase ISO 20022 message definition	The amount and currency that actually settles between the two agents on this leg — after any deducted charges, not necessarily what the customer instructed.The originally instructed amount can travel separately in InstdAmt. When the two differ, charges or currency conversion explain the gap — and receiving banks check that arithmetic.⚠ Treating the settlement amount as the customer's instructed amount misstates expected credits and triggers beneficiary complaints.
`CdtTrfTxInf/IntrBkSttlmDt`	Interbank settlement date	MANDATORYCBPR+ usage guidelines — optional in the base ISO 20022 message definition	The date the amount settles between the agents — the interbank value date of this leg.Liquidity and nostro reconciliation work off this date. Cut-off times decide whether the requested date is achievable on each leg.
`CdtTrfTxInf/ChrgBr`	Charge bearer	MANDATORYBase ISO 20022 message definition	Who pays the banks' fees: DEBT (debtor pays all), CRED (creditor pays all), SHAR (each side pays its own), or SLEV (whatever the scheme's service level prescribes).Schemes restrict the choice — the SEPA credit transfer implementation guidelines prescribe SLEV, while correspondent-banking usage works mainly with DEBT and SHAR.⚠ Sending a charge-bearer code the destination scheme does not allow is a classic reject reason at the entry point to that scheme.
`CdtTrfTxInf/Dbtr`	Debtor	MANDATORYBase ISO 20022 message definition	The customer the payment is from, with name and address — structured elements for street, town, and country exist and are preferred.This is prime sanctions-screening material at every bank in the chain. Structured, complete originator data is also a payment-transparency expectation, not just a formatting preference.⚠ Address text dumped into unstructured lines — often the residue of MT-to-MX translation — drives screening false positives and repair queues.
`CdtTrfTxInf/DbtrAgt`	Debtor agent	MANDATORYBase ISO 20022 message definition	The debtor's PSP — the bank that debited the customer and stands at the start of the interbank chain, normally identified by a BIC (Business Identifier Code).
`CdtTrfTxInf/PrvsInstgAgt1`	Previous instructing agent 1	OPTIONALBase ISO 20022 message definition	The agent that instructed the current sender on the immediately preceding leg — it records where the payment came from. Agents 2 and 3 (and their accounts) preserve more of the routing history when the chain is longer.Previous instructing agents look backward (where the payment has been); intermediary agents look forward (where it still has to go).
`CdtTrfTxInf/IntrmyAgt1`	Intermediary agent 1	OPTIONALBase ISO 20022 message definition	The first intermediary (correspondent) bank between the debtor agent and the creditor agent. Intermediary agents 2 and 3, each with an optional account element, extend the chain when more correspondents are involved.Each intermediary screens independently and can hold or return; more hops means more places a payment can stall.
`CdtTrfTxInf/CdtrAgt`	Creditor agent	MANDATORYBase ISO 20022 message definition	The creditor's PSP — the bank that will credit the beneficiary at the end of the chain.⚠ A creditor agent that is unreachable on the chosen rail forces rerouting or returns; reachability checks belong before sending, not after.
`CdtTrfTxInf/Cdtr`	Creditor	MANDATORYBase ISO 20022 message definition	The customer being paid, with name and address.Beneficiary name quality matters twice: for screening, and for name-checking services that compare the name against the account before crediting.⚠ A name that does not match the account holder at the creditor agent leads to delay, repair, or return depending on local practice.
`CdtTrfTxInf/Purp/Cd`	Purpose code	OPTIONALBase ISO 20022 message definition	The reason for the payment as a 4-letter code (e.g. SUPP), carried from debtor to creditor for the creditor's benefit; it is not used by the banks to route.Distinct from category purpose (bank-facing) in the payment-type information — see the code reference for both lists.
`CdtTrfTxInf/RmtInf`	Remittance information	OPTIONALBase ISO 20022 message definition	What the payment is for — unstructured text (Ustrd) or structured references (Strd) such as invoice numbers, passed through to the creditor.ISO 20022 allows far richer remittance data than the four 35-character lines of the MT103's field 70 — which is exactly what truncates when messages are translated back to MT.⚠ Remittance text is screened. Free text naming embargoed places, vessels, or goods stops otherwise clean payments.

FIELD BY FIELD — FULL STRUCTURE

The whole pacs.008 laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.

Document—The root of an ISO 20022 message — the business payload, which a Business Application Header (head.001) accompanies as a separate document.
- FIToFICstmrCdtTrf—Financial-Institution-to-Financial-Institution Customer Credit Transfer — the body of a pacs.008, the interbank leg of a customer payment.
  - GrpHdr—Group header — data that applies to the whole message: its identity, when it was created, how many transactions it carries, and shared settlement data.
    MsgIdDEMO-PACS008-001MandatoryA unique reference for this message, assigned by the instructing agent. It changes at every hop; end-to-end references live at transaction level.
    Use case
    Point-to-point duplicate detection keys on MsgId between adjacent agents. It is not the reference to quote to the customer.
    Example
    DEMO-PACS008-001
    Watch out
    Confusing MsgId with EndToEndId in reconciliation logic breaks matching as soon as a payment crosses more than one hop.
    CreDtTm2026-07-12T09:01:00ZMandatoryWhen this message was created — a timestamp for the message, distinct from the settlement date of the payment.
    Use case
    A processing timestamp for the message — distinct from the requested execution or settlement date.
    Example
    2026-07-12T09:01:00Z
    NbOfTxs1MandatoryHow many credit transfer transactions the message contains.
    Use case
    The base standard allows batches, but usage guidelines differ: the correspondent-banking usage constrains a message to a single transaction, while some market infrastructures permit more. Check the guideline in force.
    Example
    <NbOfTxs>2</NbOfTxs>
    SttlmInf—Settlement Information — how the interbank settlement of the payment is to happen.
    SttlmMtdCLRGMandatoryHow the interbank settlement of this payment happens: INDA (settled on an account the instructed agent services), INGA (on an account the instructing agent services), CLRG (through a clearing system), or COVE (through a separate cover payment).
    Use case
    COVE is the signal that a pacs.009 COV is travelling separately to move the funds — the receiving bank should expect to match the two.
    Example
    <SttlmMtd>CLRG</SttlmMtd>
    Watch out
    A settlement method that contradicts the actual account relationship between the two agents causes settlement fails and investigations.
    Codes
    see codes →
  - CdtTrfTxInf—MandatoryCredit Transfer Transaction Information — one individual payment: its identifiers, amount, parties, and remittance data.
    PmtId—Payment Identification — the set of references that identify this payment along the chain.
    InstrIdDEMO-INSTR-001Instruction Identification — a point-to-point reference between the two agents exchanging this message; not carried end to end.
    Use case
    A reference for the immediate hop only — useful for a query between two adjacent banks, but it does not survive the next leg.
    Example
    DEMO-INSTR-001
    Watch out
    Don't rely on it for end-to-end reconciliation — that is what EndToEndId (and the UETR) are for.
    EndToEndIdDEMO-E2E-001MandatoryThe reference assigned by the original instructing party. It must travel unchanged through every agent to the creditor.
    Use case
    This is the reference that survives from pain.001 through pacs.008 to the creditor's statement, and the one echoed back in pacs.002, pacs.004, and camt.056.
    Example
    DEMO-E2E-001
    Watch out
    Agents that overwrite EndToEndId with their own references destroy end-to-end reconciliation for everyone downstream.
    TxIdDEMO-TX-001Transaction Identification — an interbank reference for this transaction, assigned by the first instructing agent.
    Use case
    The interbank handle a return (pacs.004) or status report (pacs.002) quotes to point at the original transaction.
    Example
    DEMO-TX-001
    UETR6f9619ff-8b86-4e9f-a6dd-2cce35e4b321MandatoryA globally unique identifier (a UUID) for the payment, used to track it across the whole chain regardless of how many hops it takes.
    Use case
    The Swift gpi Tracker follows payments by UETR. Every agent must pass it on unchanged; a payment's status queries, cancellations, and confirmations all key on it.
    Example
    6f9619ff-8b86-4e9f-a6dd-2cce35e4b321
    Watch out
    Generating a fresh UETR at an intermediate hop silently forks the tracking history — the payment looks stuck to the originator and orphaned to the tracker.
    PmtTpInf—Payment Type Information — how the payment should be handled: its service level, local instrument, category purpose, and priority.
    SvcLvlchoice—Service Level — the rulebook or agreed service under which the payment runs (e.g. a SEPA scheme).
    CdSEPAService-level code — the 4-letter code naming the scheme/service (e.g. SEPA).
    Use case
    Set SEPA for a euro retail payment; SDVA to ask for same-day value.
    Example
    SEPA
    Codes
    see codes →
    IntrBkSttlmAmt1250.00Ccy=EURMandatoryThe amount and currency that actually settles between the two agents on this leg — after any deducted charges, not necessarily what the customer instructed.
    Use case
    The originally instructed amount can travel separately in InstdAmt. When the two differ, charges or currency conversion explain the gap — and receiving banks check that arithmetic.
    Example
    <IntrBkSttlmAmt Ccy="EUR">1250.00</IntrBkSttlmAmt>
    Watch out
    Treating the settlement amount as the customer's instructed amount misstates expected credits and triggers beneficiary complaints.
    IntrBkSttlmDt2026-07-13MandatoryThe date the amount settles between the agents — the interbank value date of this leg.
    Use case
    Liquidity and nostro reconciliation work off this date. Cut-off times decide whether the requested date is achievable on each leg.
    Example
    <IntrBkSttlmDt>2026-07-13</IntrBkSttlmDt>
    ChrgBrSLEVMandatoryWho pays the banks' fees: DEBT (debtor pays all), CRED (creditor pays all), SHAR (each side pays its own), or SLEV (whatever the scheme's service level prescribes).
    Use case
    Schemes restrict the choice — the SEPA credit transfer implementation guidelines prescribe SLEV, while correspondent-banking usage works mainly with DEBT and SHAR.
    Example
    <ChrgBr>SLEV</ChrgBr>
    Watch out
    Sending a charge-bearer code the destination scheme does not allow is a classic reject reason at the entry point to that scheme.
    Codes
    see codes →
    InstgAgt—Instructing Agent — the bank sending this message on this leg.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMODEFFXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    InstdAgt—Instructed Agent — the bank receiving this message on this leg.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOGB2LXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    PrvsInstgAgt1—OptionalThe agent that instructed the current sender on the immediately preceding leg — it records where the payment came from. Agents 2 and 3 (and their accounts) preserve more of the routing history when the chain is longer.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOFRPPXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    IntrmyAgt1—OptionalThe first intermediary (correspondent) bank between the debtor agent and the creditor agent. Intermediary agents 2 and 3, each with an optional account element, extend the chain when more correspondents are involved.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMONL2AXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    Dbtr—MandatoryThe customer the payment is from, with name and address — structured elements for street, town, and country exist and are preferred.
    NmDemo Trading LtdName — the free-text name of a party.
    Use case
    The name screening and verification-of-payee compare against; quality here directly affects whether a payment clears.
    Example
    <Nm>Demo Trading Ltd</Nm>
    Watch out
    A creditor name that doesn't match the account holder can trigger a name-check warning or return.
    PstlAdr—Postal Address — the party's address; a fully structured address (street/town/country in separate elements) is preferred and, cross-border, becoming mandatory over unstructured lines.
    StrtNmBeispielstrasseStreet Name — the street, as a structured address element.
    Example
    <StrtNm>Beispielstrasse</StrtNm>
    BldgNb12Building Number — the building/house number, structured.
    Example
    <BldgNb>12</BldgNb>
    PstCd60311Post Code — the postal/ZIP code, structured.
    Example
    <PstCd>60311</PstCd>
    TwnNmFrankfurt am MainTown Name — the town or city, structured.
    Example
    <TwnNm>Frankfurt am Main</TwnNm>
    CtryDECountry — the ISO 3166 two-letter country code.
    Use case
    Mandatory even on an otherwise-unstructured address; used for routing and screening.
    Example
    <Ctry>DE</Ctry>
    DbtrAcct—Debtor Account — the account to debit; in SEPA an IBAN.
    Idchoice—Identification — a party or account identifier; for a party this is a choice of organisation id or private id.
    IBANDE02120300000000202051International Bank Account Number — the standardised account identifier used across SEPA and beyond.
    Use case
    Encodes country, bank, and account with a checksum, so a typo usually fails validation before it leaves.
    Example
    DE02120300000000202051
    DbtrAgt—MandatoryThe debtor's PSP — the bank that debited the customer and stands at the start of the interbank chain, normally identified by a BIC (Business Identifier Code).
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMODEFFXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    CdtrAgt—MandatoryThe creditor's PSP — the bank that will credit the beneficiary at the end of the chain.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOGB2LXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    Cdtr—MandatoryThe customer being paid, with name and address.
    NmExample Supplies LtdName — the free-text name of a party.
    Use case
    The name screening and verification-of-payee compare against; quality here directly affects whether a payment clears.
    Example
    <Nm>Demo Trading Ltd</Nm>
    Watch out
    A creditor name that doesn't match the account holder can trigger a name-check warning or return.
    PstlAdr—Postal Address — the party's address; a fully structured address (street/town/country in separate elements) is preferred and, cross-border, becoming mandatory over unstructured lines.
    StrtNmSample RowStreet Name — the street, as a structured address element.
    Example
    <StrtNm>Beispielstrasse</StrtNm>
    BldgNb2Building Number — the building/house number, structured.
    Example
    <BldgNb>12</BldgNb>
    PstCdEC1A 1BBPost Code — the postal/ZIP code, structured.
    Example
    <PstCd>60311</PstCd>
    TwnNmLondonTown Name — the town or city, structured.
    Example
    <TwnNm>Frankfurt am Main</TwnNm>
    CtryGBCountry — the ISO 3166 two-letter country code.
    Use case
    Mandatory even on an otherwise-unstructured address; used for routing and screening.
    Example
    <Ctry>DE</Ctry>
    CdtrAcct—Creditor Account — the account to credit; in SEPA the beneficiary's IBAN.
    Idchoice—Identification — a party or account identifier; for a party this is a choice of organisation id or private id.
    IBANGB33BUKB20201555555555International Bank Account Number — the standardised account identifier used across SEPA and beyond.
    Use case
    Encodes country, bank, and account with a checksum, so a typo usually fails validation before it leaves.
    Example
    DE02120300000000202051
    Purpchoice—Purpose — the reason for the payment as stated by the debtor, carried unchanged to the creditor; informational, not for bank routing.
    CdSUPPOptionalThe reason for the payment as a 4-letter code (e.g. SUPP), carried from debtor to creditor for the creditor's benefit; it is not used by the banks to route.
    Use case
    Distinct from category purpose (bank-facing) in the payment-type information — see the code reference for both lists.
    Example
    SUPP
    Codes
    see codes →
    RmtInf—OptionalWhat the payment is for — unstructured text (Ustrd) or structured references (Strd) such as invoice numbers, passed through to the creditor.
    UstrdDEMO INVOICE 1001Unstructured — free-text remittance information (e.g. an invoice note); readable but not machine-parseable.
    Use case
    Fine for a human-read note; SEPA allows one occurrence of up to 140 characters.
    Example
    <Ustrd>DEMO INVOICE 1001</Ustrd>
    Watch out
    This text is screened — careless free text ('payment for Iran project') creates sanctions alerts that stop clean payments.
    Strd—Structured — machine-readable remittance references (e.g. a structured creditor reference), which auto-reconcile.
    CdtrRefInf—Creditor Reference Information — a structured reference the creditor supplied (e.g. an ISO 11649 RF reference) for automatic matching.
    Tp—Type — qualifies what kind of reference or code this is.
    CdOrPrtrychoice—Code or Proprietary — a choice between a standard code and a proprietary value.
    CdSCORCode — a value taken from a defined code list.
    RefRF18000000000000001001Reference — the reference value itself.

Sources for the field structure4

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
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.
Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
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.
Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
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.

COMMON ERRORS

Party addresses carried as unstructured text lines — typically the residue of MT-to-MX translation.Consequence: Sanctions screening generates avoidable alerts at every agent in the chain, and receiving banks raise repairs or requests for information; guidelines are progressively restricting unstructured address use.Avoid it: Capture debtor and creditor addresses in structured elements at source, and treat translation output with unstructured residue as an exception to fix, not a format to live with.
Charge-bearer code not allowed by the destination scheme — for example SHAR or DEBT sent into a scheme profiled for SLEV.Consequence: Rejection at the scheme entry point, or disputes over deducted charges when an intermediary applies its own interpretation.Avoid it: Drive ChrgBr from the target scheme's profile in the payment engine rather than copying whatever the customer channel supplied.
UETR regenerated or dropped at an intermediate hop.Consequence: End-to-end tracking breaks: the originator sees a payment stuck at the hop, status queries fail to match, and cancellation requests cannot be correlated confidently.Avoid it: Pass the UETR through unchanged in every onward leg and exception message, and validate its presence on receipt before processing.
Settlement method inconsistent with the actual settlement arrangement — for example COVE declared with no cover payment sent.Consequence: The creditor agent waits for cover that never arrives, the customer credit is delayed, and an investigation opens between the banks.Avoid it: Generate SttlmInf from the routing decision itself, and reconcile announced covers (pacs.009 COV) against received pacs.008 messages daily.

USAGE CONTEXTS

Cross-border correspondent banking (CBPR+)CBPR+ — the usage guidelines for ISO 20022 payments exchanged over the Swift network — defines how pacs.008 replaces the MT103 for cross-border customer credit transfers. It tightens the base standard: UETR mandatory, one transaction per message, and constrained party and address usage. The message travels serially agent to agent, or the creditor agent receives it directly while a pacs.009 COV moves the funds.
SEPA credit transfers (SCT and SCT Inst)The EPC inter-PSP implementation guidelines profile pacs.008 for the SEPA schemes: euro only, IBAN for the accounts, charge bearer SLEV, and one unstructured remittance occurrence of up to 140 characters. SCT Inst uses the same message under the scheme's tight execution timeline, paired with an immediate pacs.002 confirmation.
High-value payment systemsRTGS operators profile pacs.008 for customer payments settled in their systems, broadly aligned through the HVPS+ usage guidelines. Each system publishes its own profile, so a pacs.008 valid in one market infrastructure is not automatically valid in another.

SEE IT IN A PLAYABLE FLOW

Sources for this reference5

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.008 FIToFICustomerCreditTransfer message definition
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.
Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.008 usage guideline
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.
Scheme-specific rule2025 version 1.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · Inter-PSP implementation guidelines for SEPA credit transfers
Specifies how the ISO 20022 inter-PSP messages (pacs and camt) are used to implement the 2025 SCT rulebook between scheme participants. · Effective 2025-10-05 · Checked 2026-07-12
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
Scheme-specific rule
High Value Payments Systems Plus (HVPS+) usage guidelines ↗ — HVPS+ task force (published by Swift) · pacs.008 high-value payments usage guideline
Provides the common ISO 20022 usage-guideline base that high-value payment systems such as T2, CHAPS, Fedwire, and CHIPS adapt for their own specifications, supporting interoperability with CBPR+. · Checked 2026-07-12
Full guidelines are published on MyStandards; content here relies on public summaries.
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 key-field list is a curated subset chosen for teaching. Requirement flags name one context per field and compress differences between pacs.008 versions and between CBPR+, SEPA, and market-infrastructure profiles. Intermediary agents, ultimate parties, and regulatory reporting elements are omitted.
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.