pacs.004 — Payment Return
Returns the funds of a payment that already settled — because the credit could not be applied (closed account, deceased beneficiary), because a recall was accepted, or because the receiving agent must send the money back for another coded reason. Unlike a status report, a pacs.004 moves money: it settles in the opposite direction and stays linked to the original payment through echoed references.
DIRECTION: Sent by the agent that holds the funds — typically the creditor agent of the original payment — back along the chain toward the original debtor agent.
WHO IS INVOLVED
- Returning agentDecides (or is instructed by an accepted cancellation request) to send funds back, chooses the reason code, and originates the return.
- Intermediary agents / CSMSettle the return legs in reverse, passing the original references through unchanged.
- Original debtor agentReceives the returned funds, matches them to the original payment, and credits or notifies its customer.
- Original debtorUltimately gets the money back — possibly less charges, depending on the scheme and reason.
KEY FIELDS
This is a curated teaching subset — the full pacs.004 message definition contains many more elements, including the return chain of parties, compensation, and original transaction reference data. Requirement flags summarise the single context named on each field; versions and scheme profiles place some reference blocks differently, so check the official ISO 20022 message definition and the profile governing your rail.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
GrpHdr/MsgId | Message identification | MANDATORYBase ISO 20022 message definition | A unique reference for the return message itself — the return is a new settlement event with its own identity. |
GrpHdr/CreDtTm | Creation date and time | MANDATORYBase ISO 20022 message definition | When the return message was created. |
GrpHdr/SttlmInf/SttlmMtd | Settlement method | MANDATORYBase ISO 20022 message definition | How the return itself settles between the agents — the same choices as an outbound payment, applied in the reverse direction.A return does not have to retrace the original route hop by hop, but it must settle somewhere real; the settlement information describes the return's own arrangement. |
OrgnlGrpInf/OrgnlMsgId | Original message identification | CONDITIONALBase ISO 20022 message definition — mandatory within the original-group block when present | The MsgId of the message that carried the original payment.Depending on message version and scheme profile, original-group references appear at message level, transaction level, or both — the profile in force decides. |
TxInf/OrgnlEndToEndId | Original end-to-end identification | CONDITIONALBase ISO 20022 message definition — guidelines require enough original references to identify the returned payment unambiguously | The EndToEndId of the payment being returned, echoed unchanged.⚠ A return that arrives without usable original references becomes unapplied cash on a suspense account — money nobody can match. |
TxInf/OrgnlUETR | Original UETR | CONDITIONALBase ISO 20022 message definition — echoed when the original payment carried a UETR | The unique tracking identifier of the original payment, carried in the return so tracking systems connect the two events.The strongest automatic matching key for returns — especially when a payment was returned weeks after settlement and internal references have gone cold. |
TxInf/OrgnlIntrBkSttlmAmt | Original interbank settlement amount | CONDITIONALBase ISO 20022 message definition — required by the usage guidelines that profile returns | What settled originally — the baseline against which the returned amount is compared. |
TxInf/RtrdIntrBkSttlmAmt | Returned interbank settlement amount | MANDATORYBase ISO 20022 message definition | What actually comes back. It can be less than the original amount when the returning side deducts charges — scheme rules govern whether that is allowed.⚠ Reconciliation that expects the original amount to the cent will fail on legitimate returns with deducted charges; match on references first, amounts second. |
TxInf/ChrgsInf | Charges information | OPTIONALBase ISO 20022 message definition | An itemisation of charges deducted on the return, explaining any gap between the original and returned amounts.Transparent charge itemisation here is what prevents a follow-up investigation about the missing difference. |
TxInf/RtrRsnInf/Rsn/Cd | Return reason code | CONDITIONALBase ISO 20022 message definition — usage guidelines require a coded reason on every return | Why the money is coming back, coded from the ISO external return reason set — for example AC04 (account closed), AC06 (account blocked), or AM05 (duplication).MS03 (reason not specified) exists because some jurisdictions' data-protection rules prevent naming the true reason; the EPC publishes guidance on reason-code usage in SEPA.⚠ Choosing a convenient code instead of the accurate one corrupts everyone's return analytics and can route the case to the wrong follow-up process. |
TxInf/RtrRsnInf/Orgtr | Return originator | OPTIONALBase ISO 20022 message definition | Who initiated the return — the party, not just the reason.Useful when distinguishing a bank-initiated return from one made at the request of the beneficiary or in response to a recall. |
FIELD BY FIELD — FULL STRUCTURE
The whole pacs.004 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.PmtRtr—Payment Return — the body of a pacs.004: a settled payment being sent back with a reason.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-PACS004-001MandatoryA unique reference for the return message itself — the return is a new settlement event with its own identity.- 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-13T08:30:00ZMandatoryWhen the return 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.SttlmMtdCLRGMandatoryHow the return itself settles between the agents — the same choices as an outbound payment, applied in the reverse direction.- Use case
- A return does not have to retrace the original route hop by hop, but it must settle somewhere real; the settlement information describes the return's own arrangement.
- Example
<SttlmMtd>CLRG</SttlmMtd>- Codes
- see codes →
TxInf—Transaction Information — details of one original transaction being returned, cancelled, or reported on.RtrIdDEMO-RTR-001Return Identification — the reference the returning bank assigns to this return.OrgnlGrpInf—Original Group Information — identifies the original message a return or report refers to.OrgnlMsgIdDEMO-PACS008-001ConditionalThe MsgId of the message that carried the original payment.- Use case
- Depending on message version and scheme profile, original-group references appear at message level, transaction level, or both — the profile in force decides.
OrgnlMsgNmIdpacs.008.001.08Original Message Name Identification — the message type being referred to (e.g. pacs.008.001.08).
OrgnlEndToEndIdDEMO-E2E-001ConditionalThe EndToEndId of the payment being returned, echoed unchanged.- Watch out
- A return that arrives without usable original references becomes unapplied cash on a suspense account — money nobody can match.
OrgnlUETR6f9619ff-8b86-4e9f-a6dd-2cce35e4b321ConditionalThe unique tracking identifier of the original payment, carried in the return so tracking systems connect the two events.- Use case
- The strongest automatic matching key for returns — especially when a payment was returned weeks after settlement and internal references have gone cold.
OrgnlIntrBkSttlmAmt1250.00Ccy=EURConditionalWhat settled originally — the baseline against which the returned amount is compared.RtrdIntrBkSttlmAmt1250.00Ccy=EURMandatoryWhat actually comes back. It can be less than the original amount when the returning side deducts charges — scheme rules govern whether that is allowed.- Watch out
- Reconciliation that expects the original amount to the cent will fail on legitimate returns with deducted charges; match on references first, amounts second.
ChrgsInf—OptionalAn itemisation of charges deducted on the return, explaining any gap between the original and returned amounts.Amt0.00Ccy=EURAmount — the money being moved, as either an instructed amount or an equivalent amount.Agt—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
RtrRsnInf—Return Reason Information — why the payment was returned: the originator and a reason code.Orgtr—OptionalWho initiated the return — the party, not just the reason.Idchoice—Identification — a party or account identifier; for a party this is a choice of organisation id or private id.OrgId—Organisation Identification — identifies a party that is an organisation (e.g. by BIC or a scheme id).AnyBICDEMOGB2LXXXAny BIC — a BIC used to identify any party (not only a financial institution), e.g. the originator of a status reason.
Rsn—Reason — the reason, given as a code or proprietary value.CdAC04ConditionalWhy the money is coming back, coded from the ISO external return reason set — for example AC04 (account closed), AC06 (account blocked), or AM05 (duplication).- Use case
- MS03 (reason not specified) exists because some jurisdictions' data-protection rules prevent naming the true reason; the EPC publishes guidance on reason-code usage in SEPA.
- Watch out
- Choosing a convenient code instead of the accurate one corrupts everyone's return analytics and can route the case to the wrong follow-up process.
Sources for the field structure4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
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
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
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
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
- Sending the money back as a brand-new pacs.008 instead of a pacs.004.Consequence: The link to the original payment is lost: the original debtor agent receives an unexplained inbound payment it cannot match, the return statistics understate reality, and recalls appear unanswered.Avoid it: Always use the return message for returning settled funds, echoing the original references and UETR, and reserve fresh credit transfers for genuinely new payments.
- Original references incomplete or mangled — missing EndToEndId, wrong UETR, or references from the wrong leg of the chain.Consequence: The return lands as unapplied cash in a suspense account; the customer waits while two banks investigate what the money is.Avoid it: Build returns programmatically from the stored original message rather than retyping references, and validate the echo against the original before release.
- Returned amount differs from the original with no charges itemisation.Consequence: The receiving side cannot explain the difference to its customer and opens an investigation — turning a routine return into a case.Avoid it: Itemise every deduction in the charges information, and check the scheme actually permits deducting charges on returns before doing so.
- Inaccurate reason codes — defaulting everything to a generic code.Consequence: Downstream automation treats a closed account like a technical failure; repeated misuse also masks patterns (fraud, data quality) the analytics should surface.Avoid it: Map internal return causes to the external code set deliberately, use MS03 only where a real constraint applies, and audit reason-code distribution periodically.
USAGE CONTEXTS
- SEPA returns (SCT and SCT Inst)In SEPA, pacs.004 is the R-transaction for funds coming back after settlement — a beneficiary PSP returning a credit it cannot apply, within the return period the rulebook defines, using the reason codes the EPC guidance lists. It is also the positive outcome of a recall: when the beneficiary PSP agrees to a camt.056 recall request, the funds travel back in a pacs.004.
- Cross-border returns (CBPR+)CBPR+ profiles pacs.004 for returning cross-border payments in the correspondent-banking space, with the original UETR linking the return to the original for tracking. Charging practice on returns varies by corridor and bilateral agreement.
- Reject versus returnThe same business event — a payment that cannot be completed — takes different messages depending on timing: before settlement it is a reject (pacs.002), after settlement it is a return (pacs.004). Keeping that boundary straight is the key to understanding R-transaction flows.
SEE IT IN A PLAYABLE FLOW
Sources for this reference6
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.004 PaymentReturn message definition
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Return reason code set
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · Return and recall provisions
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Scheme-specific rule2025 version 1.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · Inter-PSP implementation guidelines — return usage
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.004 usage guideline
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The key-field list is a curated subset; the return chain of parties and compensation elements are omitted. Return periods, charging permissions, and reason-code usage differ by scheme and are described here only in general terms — the rulebook in force defines the actual deadlines and rules.
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.