MT103 RETN / MT202 RETN ↔ pacs.004
2 pairs on this page · Use case: Cancellation / return
MT103 RETN ↔ pacs.004
Business purpose
Returns a customer credit transfer that has already been forwarded or settled — for example, when the beneficiary account turns out to be closed. Sent by an agent back to the previous agent in the chain.
What does NOT map cleanly
There was no dedicated legacy return message: an agent returned the original MT103, unchanged, with a return code inserted into free-text field 72 — which created structural ambiguity over whether the parties named were the original payment's parties or the return's. pacs.004 replaces that with two separate structured blocks under each transaction entry: Original Transaction Reference (OrgnlTxRef), a deliberately partial reference back to the original payment carrying only the fields needed to identify it (settlement amount, settlement date, settlement method) rather than a full copy, and Return Chain (RtrChain), which names all parties — agents and non-agents — involved in the return itself and can legitimately differ from the original payment's route. Some pacs.004 elements — notably Return Identification (RtrId), which has no FIN equivalent — are assigned by the agent sending the return, not inherited from the original instructing party, and persist unchanged through the rest of the return's own chain. Return reason moves from free text to a coded element; CBPR+ does not allow proprietary/free-text codes.
Migration notes
CBPR+ designates pacs.004 as the replacement for a returned MT103 as part of the November 2025 end-of-coexistence cutover for cross-border MT/MX traffic. Eurosystem T2/ESMIG usage guidelines make several previously optional original-payment fields (original message ID, original instruction ID, original interbank settlement amount/date) mandatory.
Sources
- BNY — ISO 20022 Learning Guide Module 6: A Deep Dive on pacs.004 & pacs.002 ·Today, there is no dedicated FIN equivalent of the pacs.004 message. To perform a return for the MT103 or MT202, an agent would return the original message to the sender, unchanged, using a return code in Field 72. (confirmed)
- BNY — ISO 20022 Learning Guide Module 6 ·pacs.004 carries a Return Identification element that identifies the returned transaction and remains unchanged end-to-end, with no FIN equivalent; the message separates an unchanged Original Transaction reference block from a new Return Chain routing block (confirmed)
- ISO 20022 RTPG — Message Definition Report, pacs.004 Payment Return ·PaymentReturn TransactionInformation carries three distinct blocks: Return Identification (RtrId, assigned by the instructing agent sending the return — 'not the party that sent the original instruction that is being returned'), Return Chain (RtrChain, TransactionParties5, 'provides all parties (agents and non-agents) involved in a return transaction'), and Original Transaction Reference (OrgnlTxRef, OriginalTransactionReference27, of which 'not all of the original data information is provided in the return message — only fields which are needed to clearly identify the original payment') (confirmed)
MT202 RETN ↔ pacs.004
Business purpose
Returns an interbank financial-institution transfer (or a cover payment) that has already settled or otherwise cannot be applied further down the chain.
What does NOT map cleanly
Same structural gap as MT103 RETN — there was no dedicated legacy return message; the original MT202 was returned unchanged with a field-72 reject code. For a cover payment (MT202 COV) specifically, the return must retrace the original cover routing through every reimbursement agent, a dual-track logic (underlying payment leg vs. reimbursement leg) that had no clean, unambiguous MT202 COV equivalent and was handled ad hoc via field-72 codewords on whichever leg needed reversing. Structurally this return uses the same two-block split as MT103 RETN: a deliberately partial Original Transaction Reference (only the fields needed to identify the original interbank transfer — settlement amount, date, method — not a full copy) and a separate Return Chain naming the agents involved in the return itself, which for an MT202 COV return does not automatically inherit the original cover routing and must be populated to retrace it explicitly.
Migration notes
Same November 2025 CBPR+ cross-border cutover applies; pacs.004 is grouped with MT103 RETN in SWIFT's MT-to-MX translation rules for this scenario.
Sources
- BNY — ISO 20022 Learning Guide Module 6: A Deep Dive on pacs.004 & pacs.002 ·To perform a return for the MT103 or MT202, an agent would return the original message to the sender, unchanged, using a return code in Field 72; for a cover payment already received via the reimbursement leg, the return retraces the original cover routing through each reimbursement agent (confirmed)
- ISO 20022 RTPG — Message Definition Report, pacs.004 Payment Return ·PaymentReturn TransactionInformation separates Return Chain (RtrChain, TransactionParties5 — 'provides all parties (agents and non-agents) involved in a return transaction') from Original Transaction Reference (OrgnlTxRef, OriginalTransactionReference27 — 'not all of the original data information is provided in the return message. Only fields which are needed to clearly identify the original payment') (confirmed)