What is a pacs.008 message? The ISO 20022 customer credit transfer explained
A pacs.008 is more than an MT103 written in XML. Each element answers a question that a correspondent, a screening team or a reconciliation system will ask later.
In this essay
A pacs.008 is the ISO 20022 message one financial institution sends to another to transfer funds on behalf of a customer; its formal name is the FI-to-FI customer credit transfer. It identifies the payer and payee, the banks in the chain, the amount, who bears the charges and what the payment is for, and it carries a UETR that stays the same from the first bank to the last. On Swift's cross-border service it does the job MT103 used to do, and the Fedwire Funds Service has used it since July 2025. Where the route requires it, the receiving side reports back with a pacs.002 status report.
pacs.008 sits in the Payments Clearing and Settlement (pacs) area of the ISO 20022 message definitions, next to pacs.002 (status report), pacs.004 (return) and pacs.009 (financial institution credit transfer). The catalogue listed pacs.008.001.14 when this page was checked, but usage guidelines often restrict an earlier version; Payments Canada's Real-Time Rail guideline restricts pacs.008.001.08. Build to the version your counterparty names.
What is pacs.008 used for, and when is pacs.009 used instead?
Swift describes pacs.008 as the message for transfers between institutions on behalf of customers. pacs.009 is the financial institution credit transfer: a core version for bank-to-bank transfers and a cover version (pacs.009 COV) that moves the funds behind a customer payment. Swift: ISO 20022 payments instructions
Fedwire's rule is plain: if at least one party is not a financial institution, use pacs.008; if all parties are financial institutions, use pacs.009. Fedwire Funds Service: format FAQ
pacs.008 is often called "the MX version of MT103", but the two have different data models; MT vs MX messaging formats explains why copying fields across loses meaning.
How is a pacs.008 message structured?
The message has a group header for the message as a whole, then a credit transfer transaction block for each payment and optional supplementary data. The group header holds the message identification, creation time, number of transactions and settlement information. ISO 20022: Payments Clearing and Settlement message definition report
The base message allows several transactions, but Swift's end-of-coexistence guidance says multi-transaction MT 102 and MT 203 messages are not supported because they do not exist in CBPR+; senders were pointed to separate MT 103 or MT 202 instructions, converted by contingency processing and charged from January 2026. Swift: ISO 20022 end of coexistence, two months to go
Which pacs.008 elements matter most?
Tag names are from the base message. Your route's usage guideline decides which are mandatory, their lengths and allowed values.
| Element | XML tag | What it carries | What to check |
|---|---|---|---|
| Message identification | GrpHdr/MsgId |
The sending agent's reference for this message | Unique per sender; it identifies the message, not the payment |
| End-to-end identification | PmtId/EndToEndId |
The originator's reference, passed unchanged to the beneficiary side | Never overwrite it with an internal ID |
| UETR | PmtId/UETR |
A version 4 UUID that stays the same along the chain | Generate once; reuse it on retries of the same payment |
| Debtor | Dbtr, DbtrAcct |
The payer and the account debited | Legal name, address and identifiers such as an LEI where known |
| Creditor | Cdtr, CdtrAcct |
The payee and the account credited | IBAN or the local account format of the destination market |
| Agents | DbtrAgt, CdtrAgt, InstgAgt, InstdAgt, IntrmyAgt1 |
The banks in the chain, from the payer's bank to the payee's | BIC or other permitted identifier; instructing and instructed agents change at each hop |
| Amount | IntrBkSttlmAmt, InstdAmt |
The interbank settlement amount and, where used, the amount originally instructed | Currency, settlement date and any FX difference |
| Charge bearer | ChrgBr |
Who pays processing charges | The option your product promised the customer |
| Remittance information | RmtInf (Ustrd or Strd) |
Invoice or reference details for the beneficiary | Length limits; structured references survive the chain better |
| Structured address | PstlAdr (TwnNm, Ctry, StrtNm, PstCd, AdrLine) |
Party and agent addresses in discrete elements | Town and country captured as separate fields |
UETR. Fedwire requires a UETR that conforms to the UUID version 4 standard in IETF RFC 4122, and it validates the pattern but not uniqueness, so duplicate control stays with the sender. Fedwire format FAQ In a cover flow, Swift's cover payments guidance requires the pacs.009 COV to carry the same UETR as the pacs.008 it covers. Swift PMPG: cover payments market practice
Charge bearer. This is a code, not free text, such as DEBT (borne by the debtor) or CRED (borne by the creditor), as PayNet's ISO 20022 mapping tables show. The usage guideline sets which values a route accepts.
Structured address. The CPMI's harmonised data requirements treat town name and country as the minimum structured address, plus postal code where possible. CPMI: harmonised ISO 20022 data requirements, October 2023 Swift planned to remove unstructured addresses in November 2026, then extended the timeline, with an update due by December. Swift: structured address extension See address and exception readiness.
How does a pacs.008 move between banks, and where does pacs.002 fit?
The payer's bank sets the end-to-end ID, a new UETR, the amount and the charge bearer.
A correspondent screens, settles and sends its own pacs.008 onward with the same UETR.
A status report with a reason code goes back to the previous agent.
The payee's account is credited and status is reported where the route requires it.
The UETR and end-to-end ID link status, returns and statements to the original instruction.
Simplified: cover payments (pacs.009 COV), returns after settlement (pacs.004) and tracker updates are left out.
In a serial payment the message identification changes at every hop; the end-to-end identification and UETR do not.
A pacs.002 is the FI-to-FI payment status report. When a receiving agent cannot process an instruction, it reports a rejection with a reason code; Swift publishes separate best-practice guidance on returns and rejects. Once funds have settled, the route back is a return, not a reject: the Fed's FAQ names pacs.004 as the correct message for returning funds from a previously settled pacs.008. Fedwire format FAQ
A status report is evidence of one step, not of the final outcome. Read the status code with the usage guideline, and follow the payment end to end by UETR, as Swift gpi tracking describes.
Where is pacs.008 used today? US, UK and cross-border notes
- Cross-border on Swift. CBPR+ coexistence for payment instructions ended in November 2025. Senders of some MT payment instructions can still use Swift's contingency conversion, which is charged from January 2026 and is a continuity measure, not a destination. Swift: end of coexistence guidance
- United States. Fedwire Funds moved to ISO 20022 on 14 July 2025, so domestic customer wires now travel as pacs.008. What changed when Fedwire moved to ISO 20022 covers the detail.
- United Kingdom. The Bank of England mandated purpose codes for CHAPS property transactions and LEIs for CHAPS payments between financial institutions from 1 May 2025, with wider requirements from November 2027. Bank of England: mandating ISO 20022 enhanced data in CHAPS · expansion from 2027
What goes wrong in pacs.008 implementations?
Use this as a pre-release checklist:
- A new UETR on a retry. A resend of the same payment keeps its UETR; a new payment gets a new one.
- An overwritten end-to-end ID. Replacing the originator's reference breaks the customer's reconciliation.
- Guessed address splits. Splitting free text into street and town without verification can change beneficiary data.
- Truncated remittance information. Check length limits at every hop, including any translation back to MT.
- Status read as success. A positive status at one hop does not prove the beneficiary was credited.
The ISO 20022 migration guide for product teams covers the operating model around these checks.
FAQ
Is pacs.008 the same as MT103?
They serve the same purpose, a customer credit transfer between banks, but pacs.008 is an ISO 20022 XML message with a richer data model. Mapping between them can truncate data.
What is the difference between pacs.008 and pacs.009?
pacs.008 moves money for a customer; pacs.009 moves money between financial institutions, including the cover leg of a customer payment (pacs.009 COV). On Fedwire, pacs.009 is used only when every party is a financial institution.
What is the UETR in a pacs.008?
A unique end-to-end transaction reference in UUID version 4 format, created once and carried unchanged by every bank in the chain. Swift gpi tracking and Fedwire use it to link messages about the same payment.
Does a pacs.002 mean the payment was successful?
Not necessarily. A pacs.002 reports the status of one instruction at one step, which may be a rejection or an acceptance. Check the code against the usage guideline.
Can one pacs.008 contain several payments?
The base message allows it, but Swift's cross-border practice uses one transaction per message, as MT 102 has no CBPR+ equivalent. Domestic schemes set their own rules.
Closing thought and further reading
A pacs.008 is more than an MT103 written in XML. Each element answers a question that a correspondent, a screening team or a reconciliation system will ask later.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.