PACS messages explained
This page provides a detailed technical reference for the ISO 20022 pacs message family. It covers how messages work together in a complete payment lifecycle, the XML structure, settlement methods, reason codes, party identification, remittance information, and end-to-end tracking.
Payment lifecycle
The complete pacs payment lifecycle involves six stages and multiple message types working together.
Stage 1 — Initiation. The payment originates in the customer-to-bank domain (pain.001). The debtor's bank receives the instruction and maps it into the interbank domain.
Stage 2 — Interbank instruction. The debtor agent creates a pacs.008 and sends it to the next agent in the chain. In a serial flow, the pacs.008 travels hop by hop through intermediaries. In a cover flow, the pacs.008 goes directly from debtor agent to creditor agent, while a separate pacs.009 carries the funding leg through the correspondent chain.
Stage 3 — Status reporting. At each hop, the receiving agent may return a pacs.002 confirming acceptance (ACCP/ACSP/ACSC), rejection (RJCT), or pending status (PDNG). In CBPR+, pacs.002 is mandatory for all payment status communication.
Stage 4 — Settlement. Settlement occurs through a clearing system (CLRG), on correspondent accounts (INDA/INGA), or via a cover payment (COVE). The interbank settlement date and amount control when and how much settles.
Stage 5 — Credit to beneficiary. The creditor agent credits the beneficiary and may send a customer notification.
Stage 6 — Exception handling. If the beneficiary cannot be credited post-settlement, pacs.004 returns funds back through the chain. If the originator discovers an error or fraud, pacs.007 goes forward through the chain. If status is unknown, pacs.028 queries the next agent and the answer returns via pacs.002.
Serial method flow
text
Debtor Agent --(pacs.008)--> Intermediary Agent
Intermediary Agent --(pacs.002)--> Debtor Agent [status]
Intermediary Agent --(pacs.008)--> Creditor Agent
Creditor Agent --(pacs.002)--> Intermediary Agent [status]
Creditor Agent --> Creditor [credit notification]Cover method flow
text
Debtor Agent --(pacs.008)--> Creditor Agent [direct, with customer data]
Debtor Agent --(pacs.009)--> Cover Bank --(pacs.009)--> Creditor Agent [funding leg]XML structure of pacs.008
pacs.008 has two main building blocks: the Group Header (GrpHdr) and Credit Transfer Transaction Information (CdtTrfTxInf).
Group Header (GrpHdr)
The Group Header appears exactly once per message and contains:
- MsgId — Unique message identifier assigned by the sending agent. Max 35 characters, must be unique per sender.
- CreDtTm — Creation timestamp in ISO 8601 format.
- NbOfTxs — Count of individual transactions in the message.
- SttlmInf — Settlement information including the settlement method (SttlmMtd) and optionally the clearing system and settlement account.
- IntrBkSttlmDt — Date on which interbank settlement occurs.
- PmtTpInf — Payment type information including priority, service level, local instrument, and category purpose.
Credit Transfer Transaction Information (CdtTrfTxInf)
Each transaction carries:
- PmtId — Payment identifiers: InstrId, EndToEndId, TxId, and UETR.
- IntrBkSttlmAmt — Interbank settlement amount with currency code.
- InstdAmt — Original instructed amount (may differ from settlement amount due to FX).
- ChrgBr — Charge bearer code (DEBT, CRED, SHAR, or SLEV).
- Dbtr / DbtrAcct / DbtrAgt — Debtor name, address, identification, account, and agent.
- Cdtr / CdtrAcct / CdtrAgt — Creditor name, address, identification, account, and agent.
- IntrmyAgt1 / 2 / 3 — Up to three intermediary agents in the chain.
- RmtInf — Remittance information, either unstructured (free text) or structured (document references, amounts, dates).
- Purp — Structured purpose code.
- RgltryRptg — Regulatory reporting details.
Payment identifiers
pacs messages use several identifiers that serve different roles in the payment chain.
| Identifier | Set by | Changes in chain? |
|---|---|---|
| MsgId | Each sending agent | Yes — new per message |
| InstrId | Each instructing agent | Yes — may change per hop |
| EndToEndId | Originator (debtor) | No — must not be altered |
| TxId | First instructing agent | No — must not be altered |
| UETR | Debtor agent | No — universal tracking |
Settlement methods
The SttlmMtd element defines how interbank settlement occurs.
- CLRG — Settlement through a clearing system such as TARGET2, EURO1, or CHIPS. Most common for domestic and regional clearing.
- INDA — Settlement on the books of the instructed agent. The debtor agent holds a nostro account with the next agent. Typical for bilateral correspondent banking.
- INGA — Settlement on the books of the instructing agent. The instructed agent holds a nostro account with the sending agent. Less common than INDA.
- COVE — Settlement through a separate cover payment. A pacs.009 carries the funding leg while pacs.008 carries the customer data directly. Used in cross-border correspondent banking.
Charge bearer codes
The ChrgBr element specifies who bears the payment charges.
- DEBT — Debtor bears all charges (MT103 equivalent: OUR). Creditor receives the full amount.
- CRED — Creditor bears all charges (MT103 equivalent: BEN). Charges are deducted from the transfer.
- SHAR — Charges are shared (MT103 equivalent: SHA). Each party pays their own agent's charges. Most common for cross-border payments.
- SLEV — Charges follow the service level. Mandatory for SEPA. No deductions from the transfer amount.
MT103 to pacs.008 field mapping
| MT103 field | MT103 name | pacs.008 XML path |
|---|---|---|
| 20 | Sender's Reference | GrpHdr/MsgId or PmtId/InstrId |
| 23B | Bank Operation Code | PmtTpInf/SvcLvl |
| 32A | Value Date / Amount | IntrBkSttlmDt + IntrBkSttlmAmt |
| 33B | Instructed Amount | InstdAmt |
| 50a | Ordering Customer | Dbtr + DbtrAcct |
| 52a | Ordering Institution | DbtrAgt |
| 57a | Account With Institution | CdtrAgt |
| 59a | Beneficiary Customer | Cdtr + CdtrAcct |
| 70 | Remittance Information | RmtInf/Ustrd or RmtInf/Strd |
| 71A | Details of Charges | ChrgBr (BEN→CRED, OUR→DEBT, SHA→SHAR) |
| 72 | Sender to Receiver Info | InstrForCdtrAgt / InstrForNxtAgt |
| N/A | UETR (Block 3, field 121) | PmtId/UETR |
Status and reason codes
pacs.002 status codes
| Code | Meaning |
|---|---|
ACCP | Accepted — preceding checks passed |
ACSP | Accepted — settlement in progress |
ACSC | Accepted — settlement completed |
RCVD | Received — not yet processed |
PDNG | Pending — further processing needed |
RJCT | Rejected — with reason code |
Common rejection and return reason codes
| Code | Name | Description |
|---|---|---|
AC01 | Incorrect account number | Account number is invalid or does not exist |
AC04 | Closed account | Account is closed |
AC06 | Blocked account | Account is blocked for transactions |
AM04 | Insufficient funds | Insufficient funds in debtor account |
AM05 | Duplication | Duplicate payment detected |
BE04 | Missing creditor address | Creditor address is missing or incomplete |
CUST | Requested by customer | Return or rejection requested by the customer |
DUPL | Duplicate payment | Duplicate payment identified |
FOCR | Following cancellation | Following a cancellation request |
FR01 | Fraud | Suspected fraud |
RC01 | Incorrect BIC | BIC is incorrect or unknown |
RR03 | Missing creditor name/address | Creditor name or address data is missing |
TM01 | Cut-off time | Cut-off time has passed |
Postal address format
Structured address
xml
<PstlAdr>
<StrtNm>High Street</StrtNm>
<BldgNb>42</BldgNb>
<PstCd>EC2V 8BX</PstCd>
<TwnNm>London</TwnNm>
<Ctry>GB</Ctry>
</PstlAdr>Unstructured address (deprecated for CBPR+ after November 2026)
xml
<PstlAdr>
<AdrLine>42 High Street</AdrLine>
<AdrLine>London EC2V 8BX</AdrLine>
<Ctry>GB</Ctry>
</PstlAdr>Key constraints: StrtNm max 70 characters (CBPR+), TwnNm max 35 characters (CBPR+), Ctry is ISO 3166-1 alpha-2, AdrLine max 70 characters per line and max 7 lines.
Party identification
Parties in pacs.008 support multiple identification methods:
- BIC — Business Identifier Code per ISO 9362. 8 or 11 characters (BBBBCCLL or BBBBCCLLBBB). Used in FinInstnId/BICFI for agents and OrgId/AnyBIC for parties.
- LEI — Legal Entity Identifier per ISO 17442. 20 alphanumeric characters. Appears in OrgId/LEI for parties and FinInstnId/LEI for agents. Improves entity disambiguation for regulatory reporting.
- IBAN — International Bank Account Number per ISO 13616. Used in DbtrAcct/Id/IBAN and CdtrAcct/Id/IBAN.
- Organisation IDs — Other scheme-based identifiers (tax ID, DUNS, customer number) via OrgId/Othr with a scheme name code.
- Private IDs — For natural persons: date and place of birth, passport (CCPT), national ID (NIDN), or driver's licence (DRLC) via PrvtId.
Remittance information
Remittance data in pacs.008 uses the RmtInf element with two forms:
Unstructured — Free text up to 140 characters per occurrence. Simple but limits automated reconciliation.
Structured — Document references with type codes, numbers, dates, and amounts. Common document types: CINV (commercial invoice), CREN (credit note), SOAC (statement of account). Supports ISO 11649 creditor references (RF + check digits + reference) via CdtrRefInf. Enables automated invoice matching and multi-invoice payments.
UETR and gpi tracking
UETR (Unique End-to-End Transaction Reference) is a UUID v4 generated by the debtor agent. It appears in PmtId/UETR across pacs.008, pacs.009, pacs.002, pacs.004, pacs.007, and pacs.028. It must remain unchanged throughout the entire payment chain.
SWIFT gpi uses the UETR to track payments through a cloud-based Tracker database. Each agent confirms receipt and processing, enabling end-to-end visibility. The gpi SLA for cross-border payments targets same-day credit to the creditor account.