Skip to content
MT ↔ ISO

MT103 RETN / MT202 RETN ↔ pacs.004

2 pairs on this page · Use case: Cancellation / return

MT103 RETN ↔ pacs.004

Close functional match

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

BNY explains that a legacy MT103 return reused the original message with a return code in field 72; there was no dedicated FIN return message. In pacs.004, original-payment references and the Return Chain are separate, so the parties in the return can differ from the original route. Return Identification has no FIN equivalent and remains unchanged through the return. The return reason is coded under CBPR+ rather than carried solely as a field-72 codeword. This is a structural explanation, not a field-by-field conversion recipe.

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

Close functional match

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

Like an MT103 return, a legacy MT202 return reused the original message with a field-72 return code rather than a dedicated FIN return type. BNY's cover-payment example sends a pacs.004 back along the original reimbursement route, agent by agent. pacs.004 separates original-payment references from the Return Chain; it does not simply copy every party from the original instruction. Apply the actual chain and service rules for a specific return rather than treating this example as a universal routing command.

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)