pacs.004.001.11 — Payment Return
Overview
The pacs.004 message returns a payment that has already settled. It sends funds back when a payment cannot be applied or must be sent back.
Reviewed 23 March 2026. ISO catalogue date: 2025-02-27.
Key data elements
- GrpHdr — Group Header with message identification and creation timestamp.
- TxInf — Transaction Information with return amount and parties.
- OrgnlGrpInf — Original Group Information linking to the source message.
- RtrRsnInf — Return Reason Information with structured reason codes.
- OrgnlTxRef — Original Transaction Reference for matching and reconciliation.
Business context
- Handles post-settlement returns when the beneficiary's account cannot be credited.
- Supports recall scenarios where the originator requests return of funds.
- Carries structured return reason codes for regulatory and operational transparency.
- Applies to both credit transfer returns (pacs.008) and direct debit returns (pacs.003).
| Key data elements | Business context |
|---|---|
| GrpHdr — Group Header with message identification and creation timestamp | Handles post-settlement returns when the beneficiary's account cannot be credited |
| TxInf — Transaction Information with return amount and parties | Supports recall scenarios where the originator requests return of funds |
| OrgnlGrpInf — Original Group Information linking to the source message | Carries structured return reason codes for regulatory and operational transparency |
| RtrRsnInf — Return Reason Information with structured reason codes | Applies to both credit transfer returns (pacs.008) and direct debit returns (pacs.003) |
| OrgnlTxRef — Original Transaction Reference for matching and reconciliation | The instructed agent sends pacs.004 back through the payment chain to return previously settled funds. Each agent in the chain processes the return and credits back the relevant accounts. |
CBPR+ and scheme context
- Replaces MT103 RETURN and cover-method return messaging.
- Return reason codes are standardised and machine-readable under ISO 20022.
- CBPR+ requires full original transaction reference data for matching.
- SWIFT gpi tracking extends to return transactions for end-to-end visibility.
Message flow
The instructed agent sends pacs.004 back through the payment chain to return previously settled funds. Each agent in the chain processes the return and credits back the relevant accounts.
Version commentary
ISO 20022 last updated this business area on 2025-02-27. This site documents pacs.004.001.11. The latest catalogue version is pacs.004.001.14.
Use this page for the version that pacs008 implements today, and review the newer catalogue version for roadmap planning.
Version-diff table
| Version range | Why it matters | Implementation takeaway |
|---|---|---|
| pacs.004.001.11 | Current implementation in pacs008 | Aligns with current templates for payment returns. |
| pacs.004.001.12-14 | Later catalogue revisions | Review later return-message revisions when scheme upgrades or new counterparties are in scope. |
Scheme-specific notes
- For SEPA credit-transfer flows, pacs.004 is part of the wider return and exception-management picture around executed payments. The EPC SCT rulebook and EPC SCT Inst rulebook define scheme behaviour around those operational flows.
- In CBPR+, Swift maps pacs.004 alongside pacs.008, pacs.009, and pacs.002 during the ISO 20022 migration of payment instructions. See the CBPR+ coexistence and end-state roadmap.
When to use this message
Use pacs.004 when settled funds need to move back to the original sender because the payment cannot be applied or must be returned after settlement.
When not to use this message
Do not use pacs.004 when the original instructing agent is requesting an upstream reversal before or around settlement; that is pacs.007 territory.
Implementation notes
- Return reason codes should be mapped into internal exception categories so operations teams can route cases quickly.
- Keep the original transaction reference accessible to customer-support tooling; returns are hard to reconcile without it.
- Expect scheme and correspondent-bank rules to limit which return reasons are acceptable after specific processing stages.
Common failure modes
- Mixing up return and reversal processes.
- Losing the link to the original transaction and value date.
- Assuming every rejected beneficiary credit should become a pacs.004 automatically.
Worked XML fragment
xml
<PmtRtr>
<GrpHdr>
<MsgId>RTRN-2026-0003</MsgId>
</GrpHdr>
<TxInf>
<OrgnlInstrId>PAY-2026-8841</OrgnlInstrId>
<RtrdIntrBkSttlmAmt Ccy="EUR">25000.00</RtrdIntrBkSttlmAmt>
<RtrRsnInf>
<Rsn><Cd>AC04</Cd></Rsn>
</RtrRsnInf>
</TxInf>
</PmtRtr>Field commentary
OrgnlInstrId: This must point back to the settled transaction being returned.RtrdIntrBkSttlmAmt: Return amount should reflect the actual returned value, not a reconstructed business amount.RtrRsnInf: Reason-code quality is critical for downstream customer communication and operational routing.
Decision flow
text
Has value already settled and now needs to move back?
Yes -> Use pacs.004.
No -> Is the instructing side trying to stop or reverse the payment?
Yes -> Consider pacs.007 instead.
No -> Review scheme exception handling before choosing a message.Compare pacs.004 vs pacs.007
Implementation FAQ
What is the difference between pacs.004 and pacs.007?
pacs.004 returns settled funds from the receiving side, while pacs.007 requests reversal from the original instructing side.
Should every failed beneficiary credit become pacs.004?
Not automatically. The right path depends on scheme rules, settlement stage, and counterparty handling.
Primary references
- ISO 20022 message definitions catalogue for
pacs.004.001.11 - Swift CBPR+ ISO 20022 usage-guidelines announcement
- Swift CBPR+ migration roadmap PDF
- EPC SEPA Credit Transfer rulebook
- EPC SEPA Instant Credit Transfer rulebook