pacs.004 Payment Return

When pacs.004 is used

A return is needed once the money has moved. If the creditor’s bank finds after settlement that the account is closed, the name does not match the account, or the creditor refuses the funds, it sends a pacs.004 to the bank it received the payment from, which passes the return back hop by hop to the debtor’s bank. Before settlement the same problem is handled with a pacs.002 reject instead.

Returns also close cancellation cases. When a debtor’s bank asks for a payment back with a camt.056 and the creditor’s bank agrees after settlement, the funds come back in a pacs.004 with reason FOCR (following cancellation request). If it cannot agree, it answers with a camt.029 instead.

For a cover payment the return follows the route of the funds, not the route of the customer message: the creditor agent returns to the correspondent that paid it, which returns to the sender’s correspondent, and the debtor agent is informed of the credit with a camt.054.

The debtor’s bank credits its customer and reports the credit in a camt.054 or statement. The return keeps the original UETR so the case can be matched end to end.

Versions in common use

pacs.004 key elements

Paths are relative to Document/PmtRtr. Occurrence is from the base message (pacs.004.001.09); market practice such as CBPR+ or a CSD’s rules can make an optional element mandatory or forbid it.

Rules worth knowing

• Return a payment only after settlement. Before settlement, reject it with a pacs.002.
• The original references (message ID and name, instruction ID, end-to-end ID, UETR) must be the exact values of the payment being returned.
• Reason codes seen in returns (ISO names): AC01 Incorrect Account Number, AC04 Closed Account Number, AC06 Blocked Account, AG01 Transaction Forbidden, AM05 Duplication, BE01 Inconsistent With End Customer, BE04 Missing Creditor Address, CNOR Creditor Bank Is Not Registered, FOCR Following Cancellation Request, MD07 End Customer Deceased, MS02 Not Specified Reason Customer Generated, MS03 Not Specified Reason Agent Generated, RC01 Bank Identifier Incorrect, RR01 to RR04 regulatory reasons.
• FOCR is the positive answer to a cancellation or recall: the funds come back because the case was accepted. It is used in a pacs.004, while a refusal goes in a camt.029.
• Where data protection law forbids naming the reason (for example AC04 or MD07 in some SEPA countries), banks fall back to MS03.
• The return chain lists the parties of the return, while the original transaction reference lists the parties of the original payment. In the FIN return method the same field 72 could describe either, which caused confusion.

pacs.004 XML example

On 22 October 2026 BANKGB2LXXX settled a GBP 12,500.00 pacs.008 from ZagTrader Test Bank by debiting ZagTrader’s GBP account that it holds (INDA), then found that the creditor’s account had been closed. As the payment has settled, it returns the funds on 23 October by crediting the same account. In the return BANKGB2LXXX is the instructing agent and holds the account, so the settlement method is INGA.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.004.001.09">
  <PmtRtr>
    <GrpHdr>
      <MsgId>BGB26102300114</MsgId>
      <CreDtTm>2026-10-23T09:30:00+01:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INGA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <TxInf>
      <RtrId>BGBRTN26102300114</RtrId>
      <OrgnlGrpInf>
        <OrgnlMsgId>ZT26102000004</OrgnlMsgId>
        <OrgnlMsgNmId>pacs.008.001.08</OrgnlMsgNmId>
        <OrgnlCreDtTm>2026-10-20T11:30:00+04:00</OrgnlCreDtTm>
      </OrgnlGrpInf>
      <OrgnlInstrId>ZT2610200004</OrgnlInstrId>
      <OrgnlEndToEndId>GT-PO-2026-0462</OrgnlEndToEndId>
      <OrgnlUETR>60cec7c9-5dff-4a29-8bd1-8fcb4d5c52dd</OrgnlUETR>
      <OrgnlIntrBkSttlmAmt Ccy="GBP">12500.00</OrgnlIntrBkSttlmAmt>
      <OrgnlIntrBkSttlmDt>2026-10-22</OrgnlIntrBkSttlmDt>
      <RtrdIntrBkSttlmAmt Ccy="GBP">12500.00</RtrdIntrBkSttlmAmt>
      <IntrBkSttlmDt>2026-10-23</IntrBkSttlmDt>
      <InstgAgt>
        <FinInstnId>
          <BICFI>BANKGB2LXXX</BICFI>
        </FinInstnId>
      </InstgAgt>
      <InstdAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </InstdAgt>
      <RtrChain>
        <Dbtr>
          <Pty>
            <Nm>ACME COMPONENTS LTD</Nm>
            <PstlAdr>
              <TwnNm>LONDON</TwnNm>
              <Ctry>GB</Ctry>
            </PstlAdr>
          </Pty>
        </Dbtr>
        <DbtrAgt>
          <FinInstnId>
            <BICFI>BANKGB2LXXX</BICFI>
          </FinInstnId>
        </DbtrAgt>
        <CdtrAgt>
          <FinInstnId>
            <BICFI>ZAGTAEADXXX</BICFI>
          </FinInstnId>
        </CdtrAgt>
        <Cdtr>
          <Pty>
            <Nm>GULF TRADING LLC</Nm>
            <PstlAdr>
              <TwnNm>DUBAI</TwnNm>
              <Ctry>AE</Ctry>
            </PstlAdr>
          </Pty>
        </Cdtr>
      </RtrChain>
      <RtrRsnInf>
        <Orgtr>
          <Id>
            <OrgId>
              <AnyBIC>BANKGB2LXXX</AnyBIC>
            </OrgId>
          </Id>
        </Orgtr>
        <Rsn>
          <Cd>AC04</Cd>
        </Rsn>
      </RtrRsnInf>
    </TxInf>
  </PmtRtr>
</Document>

The original references are copied unchanged so ZagTrader can find the payment by UETR 60cec7c9-5dff-4a29-8bd1-8fcb4d5c52dd.

In the return chain the roles are reversed: the original creditor is the debtor of the return and the original debtor is its creditor. Check your counterparty’s guide for how it fills these when the creditor account no longer exists.

No charges were taken, so the returned amount equals the original. If charges were deducted, RtrdIntrBkSttlmAmt would be lower and each charge would appear in ChrgsInf.

All identifiers are made up.

pacs.004 and its MT equivalent

FIN had no dedicated return message. A bank returned an MT103 or MT202 by sending a new MT103 or MT202 back to the sender with the code /RETN/ and a reason in field 72; once /RETN/ (or /REJT/) appears there, the network requires the payments reject and return guidelines to be followed. The Bank of England lists pacs.004.001.09 for the CHAPS MT202 return transfer.

The FIN method was ambiguous: the parties in the returned message could be read as those of the original payment or those of the return. pacs.004 separates them into the original transaction reference and the return chain.

With the end of MT/MX coexistence for cross-border payment instructions on 22 November 2025, returns of ISO 20022 payments on Swift travel as pacs.004.

Common errors and rejects

1. Return sent instead of a reject (or the other way round)

   If nothing has settled yet, a pacs.004 moves money that was never received. If funds have settled, a pacs.002 reject leaves them stuck. Check the settlement method and whether your nostro was debited or credited before choosing.

   How to fix it

2. Original references do not match

   A return that quotes an instruction ID, end-to-end ID or UETR different from the original cannot be matched by the receiving bank, and the funds sit in a suspense account. Copy the values from the received message, never retype them.

   How to fix it

3. Return without a coded reason

   CBPR+ requires a code from the ISO list; a proprietary or free-text reason is not allowed. Put any explanation in AddtlInf, next to a valid code.

4. Returned amount short without explanation

   If charges were deducted, list them in ChrgsInf. Otherwise the debtor’s bank sees a shortfall it cannot explain to its customer.

5. Cover return routed the wrong way

   For a payment settled through a cover, the funds must go back along the cover route through the correspondents, not directly to the debtor agent that sent the pacs.008.

Related messages

• pacs.008FI to FI Customer Credit Transfer
• pacs.009Financial Institution Credit Transfer
• pacs.002FI to FI Payment Status Report
• camt.056FI to FI Payment Cancellation Request
• camt.029Resolution of Investigation
• camt.054Bank to Customer Debit Credit Notification
• MT103Single Customer Credit Transfer
• MT202General Financial Institution Transfer

• pacs.002 reason codes
• Serial MT103 chains vs MT103 plus MT202COV cover, and the same flows in pacs.008 and pacs.009 COV.

pacs.004 questions

What is a pacs.004 message?

The ISO 20022 Payment Return: the message that sends back the funds of a payment already settled, with the original references, the UETR and a coded reason.

When do you use pacs.004 instead of pacs.002?

Use a pacs.002 reject before settlement, when no money has moved. Use a pacs.004 return after settlement, because funds must flow back.

What does FOCR mean in a pacs.004?

Following Cancellation Request: the funds are returned because a cancellation or recall request (camt.056) was accepted.

What was the MT equivalent of pacs.004?

There was none dedicated. The bank sent an MT103 or MT202 back with /RETN/ and a reason code in field 72.

Does a pacs.004 keep the original UETR?

Yes. OrgnlUETR carries the UETR of the payment being returned, unchanged along the whole return chain.

Which pacs.004 version is used?

CBPR+ uses pacs.004.001.09. The SEPA Credit Transfer inter-PSP guidelines and CHAPS also use pacs.004.001.09.