pacs.008.001.13 — FI to FI Customer Credit Transfer
Overview
The pacs.008 message is the main customer credit-transfer instruction between financial institutions. It carries party, amount, and remittance data.
Reviewed 23 March 2026. ISO catalogue date: 2025-02-27.
Key data elements
- GrpHdr — Group Header with message ID, creation date, number of transactions, and settlement information.
- CdtTrfTxInf — Credit Transfer Transaction Information with amount, charges, and purpose.
- Dbtr / DbtrAgt — Debtor and Debtor Agent identification and account details.
- Cdtr / CdtrAgt — Creditor and Creditor Agent identification and account details.
- RmtInf — Remittance Information for structured or unstructured payment references.
Business context
- Main message for customer cross-border and domestic credit transfers.
- Used across SEPA SCT, SEPA Instant, CBPR+, and national clearing systems.
- Carries remittance data for straight-through reconciliation.
- Supports serial, cover, and direct settlement methods.
| Key data elements | Business context |
|---|---|
| GrpHdr — Group Header with message ID, creation date, number of transactions, and settlement information | Main message for customer cross-border and domestic credit transfers |
| CdtTrfTxInf — Credit Transfer Transaction Information with amount, charges, and purpose | Used across SEPA SCT, SEPA Instant, CBPR+, and national clearing systems |
| Dbtr / DbtrAgt — Debtor and Debtor Agent identification and account details | Carries remittance data for straight-through reconciliation |
| Cdtr / CdtrAgt — Creditor and Creditor Agent identification and account details | Supports serial, cover, and direct settlement methods |
| RmtInf — Remittance Information for structured or unstructured payment references | The debtor agent sends pacs.008 to the creditor agent, directly or through intermediaries. Each agent validates and forwards the instruction until the creditor agent credits the beneficiary. |
CBPR+ and scheme context
- Replaces MT103 and MT103+ for cross-border customer credit transfers.
- The November 2026 structured-address deadline applies to party postal addresses.
- SWIFT gpi uses pacs.008 for UETR-based tracking.
- Revision 13 reflects ongoing schema change across market infrastructures.
Message flow
The debtor agent sends pacs.008 to the creditor agent, directly or through intermediaries. Each agent validates and forwards the instruction until the creditor agent credits the beneficiary.
Version commentary
ISO 20022 last updated this business area on 2025-02-27. This site documents pacs.008.001.13, which still matches the latest catalogue version.
Use this page for current implementation work, but still check scheme guidance before production use.
Version-diff table
| Version range | Why it matters | Implementation takeaway |
|---|---|---|
| pacs.008.001.01-07 | Early revisions | Useful mainly for legacy migration analysis and version-history context. |
| pacs.008.001.08-12 | Pre-current modern revisions | These are the revisions most likely to appear in recent migration or coexistence projects. |
| pacs.008.001.13 | Current catalogue revision | Use this for current-version planning, while still validating scheme usage guidelines and counterparty readiness. |
Scheme-specific notes
- For SEPA credit transfers, pacs.008 is part of the SCT scheme messaging stack defined by the EPC SCT rulebook.
- For instant payments, pacs.008 is also central to SCT Inst flows under the EPC SCT Inst rulebook.
- For CBPR+, Swift positions pacs.008 as the ISO 20022 successor to MT103-style customer credit-transfer instructions. See Swift CBPR+ pacs.008 training overview, serial method, and cover method.
- Swift's roadmap shows MT 103 moving to pacs.008 during migration. See the Swift roadmap PDF.
- Structured-address changes around November 2026 affect pacs.008 data quality in cross-border use. See the Swift CBPR+ roadmap.
When to use this message
Use pacs.008 for customer credit transfers moving between financial institutions.
When not to use this message
Do not use pacs.008 for institution-own-account funding transfers or for status, return, or investigation messages.
Implementation notes
- Address quality, party identifiers, and remittance structure often matter more than the XML skeleton.
- Model payment purpose, charge bearer, settlement method, and party roles in source data before rendering.
- Treat version selection as a deployment decision tied to market infrastructure and counterparties.
Common failure modes
- Assuming one pacs.008 mapping works unchanged across CBPR+, SEPA, domestic RTGS, and instant-payment contexts.
- Using free text where structured remittance or address fields are expected.
- Leaving exception-handling design until after XML generation already works.
Worked XML fragment
xml
<FIToFICstmrCdtTrf>
<GrpHdr>
<MsgId>MSG-2026-001</MsgId>
<CreDtTm>2026-01-15T10:30:00Z</CreDtTm>
</GrpHdr>
<CdtTrfTxInf>
<PmtId>
<EndToEndId>E2E-INV-2026-001</EndToEndId>
<UETR>123e4567-e89b-12d3-a456-426614174000</UETR>
</PmtId>
<IntrBkSttlmAmt Ccy="EUR">25000.00</IntrBkSttlmAmt>
<Dbtr><Nm>Acme Corp GmbH</Nm></Dbtr>
<Cdtr><Nm>Widget Industries SA</Nm></Cdtr>
</CdtTrfTxInf>
</FIToFICstmrCdtTrf>Field commentary
MsgId: This should identify the message envelope, not the end-customer payment reference.EndToEndId: Keep customer-facing traceability stable across downstream systems where possible.UETR: Use this consistently in cross-border and tracking-heavy environments; do not generate it ad hoc in later workflow stages.IntrBkSttlmAmt: Validate amount and currency using business rules before schema validation.Dbtr/Cdtr: Party quality, address structure, and identifiers are usually the main determinants of repair rates.
Decision flow
text
Is this a customer credit-transfer instruction between institutions?
Yes -> Use pacs.008.
No -> Is it an institution funding leg or cover payment?
Yes -> Consider pacs.009 instead.
No -> Re-check whether the business event is status, return, or reversal.Compare pacs.008 vs pacs.009
Implementation FAQ
Is pacs.008 enough on its own for production payments?
No. Production readiness also depends on scheme rules, address quality, party data, status handling, and exception flows.
What causes the most repair work?
Weak party data, poor address structuring, inconsistent identifiers, and unstructured remittance content are common causes.
Primary references
- ISO 20022 message definitions catalogue for
pacs.008.001.13 - Swift CBPR+ ISO 20022 usage-guidelines announcement
- Swift CBPR+ migration roadmap PDF
- EPC SEPA Credit Transfer rulebook
- EPC SEPA Instant Credit Transfer rulebook
- Swift CBPR+ pacs.008 overview
- Swift CBPR+ serial-method pacs.008 guidance
- Swift CBPR+ cover-method pacs.008/pacs.009 guidance
- Swift CBPR+ roadmap and standards programme