pacs.009ISO 20022

pacs.009 — Financial Institution Credit Transfer

Moves funds between financial institutions where both the debtor and the creditor are themselves banks — the ISO 20022 counterpart of the MT202. In its core usage it settles bank-to-bank obligations such as treasury and liquidity movements. In its COV usage it is the cover leg of the cover method: it moves the funds for an underlying customer payment (a pacs.008 sent directly to the creditor agent) and carries a copy of that customer payment's details.

DIRECTION: Sent by or on behalf of the debtor financial institution to the next agent in the chain — its correspondent, an intermediary, or a settlement system — toward the creditor financial institution.

Contributor Shubham Mathure16 July 2026

WHO IS INVOLVED

Debtor (financial institution)The bank whose funds move — in pacs.009 the debtor is an institution, never a customer.
Instructing / instructed agentSender and receiver of each hop, settling their leg across mutual or clearing accounts.
Intermediary agentRelays and settles intermediate legs in longer correspondent chains.
Creditor (financial institution)The bank receiving the funds. In the COV usage, it is the creditor agent of the underlying customer payment and matches the cover against the pacs.008 it received directly.

KEY FIELDS

This is a curated teaching subset — the full pacs.009 message definition contains many more elements, including further intermediary agents, settlement account details, and remittance elements, and the COV copy structure has its own sub-elements. Requirement flags summarise the single context named on each field; check the official ISO 20022 message definition and the usage guideline governing your traffic.

Key fields of pacs.009
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 for this hop.
`GrpHdr/CreDtTm`	Creation date and time	MANDATORYBase ISO 20022 message definition	When this message was created.
`GrpHdr/SttlmInf/SttlmMtd`	Settlement method	MANDATORYBase ISO 20022 message definition	How this transfer settles between the agents — on an account one of them services (INDA, INGA), through a clearing system (CLRG), or via a separate cover (COVE). In a COV cover the reimbursement agents below name where the cover funds move.The pacs.009 COV carries the cover leg; the reimbursement agents are the ISO equivalent of the MT202 COV's sender's/receiver's correspondents (:53a:/:54a:).
`GrpHdr/SttlmInf/InstgRmbrsmntAgt`	Instructing reimbursement agent	CONDITIONALBase ISO 20022 message definition — present with cover settlement	In a cover arrangement, the agent that reimburses the instructed agent — where the cover funds come from (the sender's correspondent). A third reimbursement agent extends the chain when needed.This is field :53a: in an MT202 COV; the instructed reimbursement agent below is :54a:.
`GrpHdr/SttlmInf/InstdRmbrsmntAgt`	Instructed reimbursement agent	CONDITIONALBase ISO 20022 message definition — present with cover settlement	The agent that receives the reimbursement — where the cover funds are paid (the receiver's correspondent).Reimbursement agents only appear with the COVE settlement method; a plain interbank pacs.009 does not carry them.
`CdtTrfTxInf/PmtId/EndToEndId`	End-to-end identification	MANDATORYBase ISO 20022 message definition	The reference the first instructing party assigned to this institutional transfer, passed on unchanged.In the COV usage, market practice ties the cover's references to the underlying customer payment so the creditor agent can match the two — follow the usage guideline in force for exactly which reference goes where.⚠ A cover whose references do not line up with the underlying pacs.008 leaves funds unapplied in a queue while investigations run.
`CdtTrfTxInf/PmtId/UETR`	Unique end-to-end transaction reference	MANDATORYCBPR+ usage guidelines — optional in the base ISO 20022 message definition	The globally unique tracking identifier for the transfer.Tracking and matching of cover payments leans heavily on the UETR — it is the strongest link between a pacs.009 COV and its underlying pacs.008.
`CdtTrfTxInf/IntrBkSttlmAmt`	Interbank settlement amount	MANDATORYBase ISO 20022 message definition	The amount and currency settling between the institutions.⚠ In the cover method, a cover amount that differs from the underlying pacs.008 settlement amount (beyond agreed charging) is a classic mismatch investigation.
`CdtTrfTxInf/IntrBkSttlmDt`	Interbank settlement date	MANDATORYCBPR+ usage guidelines — optional in the base ISO 20022 message definition	The value date of the transfer between the institutions.Cover timing matters: if the cover settles later than the beneficiary bank expects, the customer credit may be withheld until the funds actually arrive.
`CdtTrfTxInf/Dbtr`	Debtor	MANDATORYBase ISO 20022 message definition	The financial institution whose funds move. In pacs.009 this element identifies an institution (typically by BIC), not a customer — that is the structural difference from pacs.008.If a customer appears anywhere in the business content, pacs.009 core is the wrong message — the payment belongs in pacs.008, possibly with a pacs.009 COV as cover.
`CdtTrfTxInf/IntrmyAgt1`	Intermediary agent 1	OPTIONALBase ISO 20022 message definition	The first intermediary institution between the agents, when the transfer routes through more than one correspondent.⚠ Routing data that names an intermediary with no account relationship to the next party pushes the transfer into manual repair.
`CdtTrfTxInf/Cdtr`	Creditor	MANDATORYBase ISO 20022 message definition	The financial institution receiving the funds.
`CdtTrfTxInf/UndrlygCstmrCdtTrf`	Underlying customer credit transfer	CONDITIONALBase ISO 20022 message definition — present in the COV usage, absent in the core usage	A copy of key details of the underlying customer payment — its debtor, debtor agent, creditor agent, creditor, and remittance information — carried inside the cover so every bank moving the money can see whose payment it funds.This element exists because cover payments historically hid the customer parties from the banks moving the funds. Its content must be copied faithfully from the underlying pacs.008 and left unchanged in transit.⚠ Sending a plain pacs.009 core where the transfer actually funds a customer payment removes exactly the data sanctions screening needs — a payment-transparency failure, not a formatting nuance.

FIELD BY FIELD — FULL STRUCTURE

The whole pacs.009 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.
- FICdtTrf—Financial Institution Credit Transfer — the body of a pacs.009, a bank-to-bank transfer (including cover).
  - 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-PACS009-001MandatoryA unique reference for this message, assigned by the instructing agent for this hop.
    Use case
    Quoted when a status report or return refers back to this whole message; changes at every interbank hop.
    Example
    DEMO-PACS008-001
    CreDtTm2026-07-12T09:02:00ZMandatoryWhen this message was created.
    Use case
    A processing timestamp for the message — distinct from the requested execution or settlement date.
    Example
    2026-07-12T09:01:00Z
    NbOfTxs1Number of transactions the message carries — a control total the receiver checks against the transactions it finds.
    Use case
    The receiver counts the transactions it parsed and rejects the whole message if the tally disagrees.
    Example
    <NbOfTxs>2</NbOfTxs>
    SttlmInf—Settlement Information — how the interbank settlement of the payment is to happen.
    SttlmMtdCOVEMandatoryHow this transfer settles between the agents — on an account one of them services (INDA, INGA), through a clearing system (CLRG), or via a separate cover (COVE). In a COV cover the reimbursement agents below name where the cover funds move.
    Use case
    The pacs.009 COV carries the cover leg; the reimbursement agents are the ISO equivalent of the MT202 COV's sender's/receiver's correspondents (:53a:/:54a:).
    Example
    <SttlmMtd>CLRG</SttlmMtd>
    Codes
    see codes →
    InstgRmbrsmntAgt—ConditionalIn a cover arrangement, the agent that reimburses the instructed agent — where the cover funds come from (the sender's correspondent). A third reimbursement agent extends the chain when needed.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOUS33XXXBusiness 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
    InstdRmbrsmntAgt—ConditionalThe agent that receives the reimbursement — where the cover funds are paid (the receiver's correspondent).
    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
  - 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-COV-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 the first instructing party assigned to this institutional transfer, passed on unchanged.
    Use case
    In the COV usage, market practice ties the cover's references to the underlying customer payment so the creditor agent can match the two — follow the usage guideline in force for exactly which reference goes where.
    Example
    DEMO-E2E-001
    Watch out
    A cover whose references do not line up with the underlying pacs.008 leaves funds unapplied in a queue while investigations run.
    UETR6f9619ff-8b86-4e9f-a6dd-2cce35e4b321MandatoryThe globally unique tracking identifier for the transfer.
    Use case
    Tracking and matching of cover payments leans heavily on the UETR — it is the strongest link between a pacs.009 COV and its underlying pacs.008.
    Example
    6f9619ff-8b86-4e9f-a6dd-2cce35e4b321
    IntrBkSttlmAmt1250.00Ccy=EURMandatoryThe amount and currency settling between the institutions.
    Use case
    The figure that moves between the banks — after any deducted charges, so it can differ from what the customer instructed.
    Example
    <IntrBkSttlmAmt Ccy="EUR">1250.00</IntrBkSttlmAmt>
    Watch out
    In the cover method, a cover amount that differs from the underlying pacs.008 settlement amount (beyond agreed charging) is a classic mismatch investigation.
    IntrBkSttlmDt2026-07-12MandatoryThe value date of the transfer between the institutions.
    Use case
    Cover timing matters: if the cover settles later than the beneficiary bank expects, the customer credit may be withheld until the funds actually arrive.
    Example
    <IntrBkSttlmDt>2026-07-13</IntrBkSttlmDt>
    IntrmyAgt1—OptionalThe first intermediary institution between the agents, when the transfer routes through more than one correspondent.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOUS33XXXBusiness 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 financial institution whose funds move. In pacs.009 this element identifies an institution (typically by BIC), not a customer — that is the structural difference from pacs.008.
    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
    Cdtr—MandatoryThe financial institution receiving the funds.
    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
    UndrlygCstmrCdtTrf—ConditionalA copy of key details of the underlying customer payment — its debtor, debtor agent, creditor agent, creditor, and remittance information — carried inside the cover so every bank moving the money can see whose payment it funds.
    Dbtr—MandatoryDebtor — the party whose account is debited: the payer.
    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.
    DbtrAgt—Debtor Agent — the debtor's bank, the one being instructed.
    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—Creditor Agent — the creditor's bank, which credits 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—MandatoryCreditor — the party being paid: the beneficiary.
    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.
    InstdAmt1250.00Ccy=EURInstructed Amount — the amount and currency the customer instructed, before any charges or conversion.
    Use case
    What the customer asked to pay; compare it against the interbank settlement amount to see what charges or FX did to the figure.
    Example
    <InstdAmt Ccy="EUR">1250.00</InstdAmt>
    RmtInf—Remittance Information — what the payment is for, so the creditor can reconcile it; either unstructured free text or structured references.
    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.

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

Using pacs.009 core where the transfer funds a customer payment, instead of pacs.009 COV (or a serial pacs.008).Consequence: Banks in the funds chain screen a message with no customer data — a transparency failure that regulators and correspondents treat seriously, and that can surface much later as an account-relationship problem.Avoid it: Route by business content: any underlying customer payment means COV or serial, never core. Enforce this in the payment engine's routing rules rather than trusting manual choice.
Cover and underlying payment references that do not match — different UETR, misaligned references, or an amount gap beyond agreed charges.Consequence: The creditor agent cannot apply the funds; the customer credit waits in an unmatched-cover queue and an interbank investigation opens.Avoid it: Generate the pacs.008 and its pacs.009 COV from a single source transaction so references, UETR handling, and amounts stay consistent by construction.
Editing the underlying-customer-credit-transfer copy in transit — 'improving' names, truncating addresses, or dropping remittance data.Consequence: The copy no longer matches the pacs.008 the creditor agent holds, creating screening discrepancies and disputes over which version is true.Avoid it: Treat UndrlygCstmrCdtTrf as read-only pass-through data at every hop; fix data-quality problems at origination, not en route.
Crediting the customer on receipt of the pacs.008 without confirming the cover actually settled.Consequence: If the cover never arrives — sender failure, sanctions hold, or insolvency — the crediting bank has given away its own funds.Avoid it: Follow your institution's cover-matching policy: match announced covers to received customer payments and release credits according to the risk rules your bank has actually approved, which differ between institutions.

USAGE CONTEXTS

Bank-to-bank transfers over Swift (CBPR+ core)CBPR+ defines pacs.009 core as the successor to the MT202 for institutional transfers in the correspondent-banking space: settlement of FX deals, funding of nostro accounts, and other obligations where both parties are banks.
Cover method (CBPR+ COV)In the cover method the debtor agent sends the pacs.008 straight to the creditor agent and routes a pacs.009 COV through the correspondent chain to move the funds. The COV variant carries the underlying customer details so intermediaries can screen the payment they are funding — the ISO 20022 successor to the MT202 COV.
High-value payment systemsRTGS systems settle interbank obligations with pacs.009 under HVPS+-aligned profiles, including dedicated variants some systems use for liquidity transfers between accounts. Each infrastructure's profile differs in the elements and codes it allows.

SEE IT IN A PLAYABLE FLOW

Sources for this reference4

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.009 FinancialInstitutionCreditTransfer 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.009 core and pacs.009 COV 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.
Scheme-specific rule
High Value Payments Systems Plus (HVPS+) usage guidelines ↗ — HVPS+ task force (published by Swift) · pacs.009 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. The core/COV distinction is presented as two usages of one message; some infrastructures define additional dedicated variants. Cover-matching and credit-release policies vary by institution more than any summary can capture.
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.