Returns
The return family: MT103 and MT202 returns (the /RETN/ codeword in :72:) to and from pacs.004, with reason codes, original references and charges.
Formats
| Format | What it is | Versions accepted | Emitted by default |
|---|---|---|---|
mt103-retn | MT103 carrying /RETN/ in :72: (customer transfer returned) | n/a | n/a |
mt202-retn | MT202 carrying /RETN/ in :72: (bank transfer returned) | n/a | n/a |
pacs.004 | Payment return | .001.09 – .001.13 | .001.09 |
Pairs
| From | To |
|---|---|
mt103-retn, mt202-retn | pacs.004 |
pacs.004 | mt103-retn, mt202-retn |
A return is never a new payment and never a reject: mt103-retn → pacs.008 and mt103-retn → pacs.002 do not exist. There is no canonical source for this family.
How fields map
The canonical model is a payment return: who pays the money back, how much, why, and which original payment it answers.
MT to pacs.004.
:20:becomes the message id and the return id.:32A:becomes the settlement date and the returned amount; MT103:33B:becomes the original amount.- The block 3 UETR
{121:}becomes the original UETR: a return travels under the UETR of the payment it returns. :52a:becomes the institution paying back (return chain debtor); MT103:57a:or MT202:58a:the institution being paid (return chain creditor);:56a:the intermediary.- MT202
:21:becomes the original end-to-end id. - MT103
:71F:/:71G:become charges. :72:is read line by line through the codeword table below.
:72: line | Becomes |
|---|---|
/RETN/ | The return marker. A reason-code suffix (/RETN/AC04) is the reason; a field-tag suffix (/RETN/32A) is dropped |
/AC04/ACCOUNT CLOSED | Reason code AC04, with the text as additional information |
/MREF/<ref> | Original instruction id |
/TREF/<ref> | Original end-to-end id (wins over MT202 :21:) |
/CHGS/EUR10,00 | A charge |
/TEXT/<text> or plain text | Additional information |
pacs.004 to MT. The reverse: :72: is written as /RETN/<reason>, /MREF/, /TREF/ (MT103) and /TEXT/ lines in that order. Charges become :71F: on an MT103 and /CHGS/ lines on an MT202.
Where information is lost
| Situation | Warning |
|---|---|
| Ordering customer and beneficiary of an MT103 return (the return model has no customer parties) | DROP_FIELD |
| Correspondent and other agents with no slot in the return chain | DROP_AGENT |
| A return chain with only one end known: pacs.004 needs both, so the chain is left out | DROP_AGENT |
| A charge with no levying institution (pacs.004 requires one) | DROP_FIELD |
| A reason or codeword with no table row, carried as proprietary text | RETURN_REASON_UNMAPPED |
The same charge in :71G: and /CHGS/, collapsed to one | CHARGES_DUPLICATED |
MT103 return: :23B:CRED, :71A:SHA and NOTPROVIDED customer fields written because MT103 requires them | MISSING_REQUIRED_DEFAULTED |
pacs.004 creation time and settlement method (INDA) | MISSING_REQUIRED_DEFAULTED |
:72: over six lines of 35; additional information over 105 characters | TRUNC_REMITTANCE |
Conventions
- Detection. transmute scans
:72:for/RETN/and routes the message tomt103-retnormt202-retnautomatically. If you sendfrom=mt103for a message that carries/RETN/(orfrom=mt103-retnfor one that does not), the request isinvalid-input400. - Reason codes pass through. Four-character ISO return reasons (
AC04,AM05,MS03,CUST, …) are carried verbatim, including codes transmute has never seen. Nothing is rejected for an unknown reason. - MT202 returns need both banks. An MT202 return requires
:58a:. A pacs.004 without a return chain cannot become anmt202-retnand the conversion is refused. - One file, one family. A file of several MT103 or MT202 messages that includes a
/RETN/message is rejected: send returns separately from payments.
Example
curl -sS -X POST "https://api.transmute.403fin.io/v1/convert?to=pacs.004" \
-H "Authorization: Bearer $TRANSMUTE_KEY" \
-H "Content-Type: text/plain" \
--data-binary @- <<'MT'
:20:RTN-103-0100
:23B:CRED
:32A:260610EUR985,50
:33B:EUR1000,00
:50K:/DE89370400440532013000
JANE EXAMPLE
:57A:AAAADEFF
:59:/GB29NWBK60161331926819
ACME TOOLS LTD
:71A:SHA
:72:/RETN/32A
/AC04/ACCOUNT CLOSED
/MREF/INSTR-0001
/TREF/E2E-2026-0001
MT
The result document, formatted:
<TxInf>
<RtrId>RTN-103-0100</RtrId>
<OrgnlInstrId>INSTR-0001</OrgnlInstrId>
<OrgnlEndToEndId>E2E-2026-0001</OrgnlEndToEndId>
<OrgnlIntrBkSttlmAmt Ccy="EUR">1000.00</OrgnlIntrBkSttlmAmt>
<RtrdIntrBkSttlmAmt Ccy="EUR">985.50</RtrdIntrBkSttlmAmt>
<IntrBkSttlmDt>2026-06-10</IntrBkSttlmDt>
<RtrRsnInf><Rsn><Cd>AC04</Cd></Rsn><AddtlInf>ACCOUNT CLOSED</AddtlInf></RtrRsnInf>
</TxInf>
"warnings": [
{ "code": "MISSING_REQUIRED_DEFAULTED", "severity": "info", "targetField": "GrpHdr/CreDtTm", "detail": "..." },
{ "code": "MISSING_REQUIRED_DEFAULTED", "severity": "info", "targetField": "GrpHdr/SttlmInf/SttlmMtd", "detail": "..." },
{ "code": "DROP_FIELD", "severity": "info", "sourceField": ":23B:", "detail": "..." },
{ "code": "DROP_FIELD", "severity": "lossy", "sourceField": ":50a:", "detail": "..." },
{ "code": "DROP_FIELD", "severity": "lossy", "sourceField": ":59a:", "detail": "..." },
{ "code": "DROP_FIELD", "severity": "info", "sourceField": ":71A:", "detail": "..." },
{ "code": "DROP_FIELD", "severity": "info", "sourceField": ":72:", "detail": "..." },
{ "code": "DROP_AGENT", "severity": "lossy", "sourceField": "creditorAgent", "targetField": "TxInf/RtrChain/Cdtr", "detail": "..." }
],
"meta": { "detectedType": "mt103-retn", "targetType": "pacs.004.001.09", "...": "..." }
The customer parties and the 32A pointer are dropped, and because the message names only the creditor-side bank (:57A:), the one-legged return chain is left out rather than half-written.