pacs.002 vs pacs.004: Status, Rejection, and Return

Direct answer

A pacs.002 reports the status of an interbank payment instruction. A pacs.004 is a separate payment return for funds from an instruction that has already settled. If a bank says a payment was “rejected,” ask whether the instruction failed before settlement. If it says the money was “returned,” ask for the return reference and confirm the credit back to the payer. Those are different records and different reconciliation events.

The message names come from the ISO 20022 catalogue. The ISO message family does not, by itself, tell you which version or procedure a specific rail uses. This guide uses two bounded examples: Swift's April 2026 cover-payment market practice and the European Payments Council's current SCT reason-code guidance. It does not assume that every domestic rail works the same way.

The operator decision table

This table is PaymentBrief operator guidance derived from the messages' roles. It is not a scheme-mandated flow or a guarantee that a bank will expose each record to a merchant.

A rejection is not a refund

In a pre-settlement rejection, the instruction is declined. A pacs.002 can report that outcome to the previous institution. There may be no settled funds to send back, so looking for a pacs.004 simply because the word “rejected” appears can send an investigation down the wrong path.

Swift's April 2026 cover-payment guideline gives a particularly useful contrast. For a delayed or rejected pacs.009 COV, it calls for a gpi Tracker update through an API, trck message or MT299, and a pacs.002 reject to the previous institution where appropriate. If settlement of that cover payment has already completed and funds must go back, it calls for a pacs.004 return. The guideline describes a cover-payment scenario; it is not a universal rule that all three records appear on every cross-border transfer.

For SCT, the EPC's current reason-code guidance likewise treats Reject and Return as different R-transaction types. A Recall or Request for Recall by the Originator is a request to recover a sent transfer; its response and the funds movement must be checked separately. The SEPA R-transaction reference carries the scheme-specific codes and timelines.

Do not confuse the Tracker with a message type

The UETR is a key for tracing a Swift transfer. The Tracker is a service that collects and exposes payment status information. pacs.002 is one interbank message type. A corporate may see a status label through its bank without seeing the underlying interbank message, and a Tracker update can use a channel other than pacs.002. Swift's cover guideline names API, trck and MT299 routes for that update.

Start with the UETR tracing runbook if a payment is missing. Ask the sending bank for the last available Tracker status, its timestamp, the last institution known to hold the payment, and whether there is a separate rejection, return or credit confirmation. An identifier or an “accepted for processing” status does not, alone, settle the beneficiary's invoice.

Reconcile the outcome, not just the message

Retain the original payment's UETR or scheme reference, amount and value date. Then link the exception record to the original instruction. If there is a return, record its own reference, reason, amount and date. Compare that with the payer's bank statement or notification before marking the cash recovered. If the beneficiary says it received the payment while the sender sees a return, pause and reconcile the two banks' account records rather than inferring the result from one status label.

For the original payment fields, see the MT103 to pacs.008 mapping reference. For cancellation and case-message roles, see the camt investigation reference. Message versions, allowed reason codes and return windows belong to the applicable scheme or correspondent arrangement; confirm them with the banks in the actual chain.