How to Investigate a Rejected SWIFT Payment

The goal is to determine the rejection point (sender, network, intermediary, beneficiary) and the reason (format, routing, funds, compliance, or other). Trace reconstruction uses the message reference, timestamps, and any NACK or return messages. The output supports repair (correct and resubmit), client communication, and root-cause analysis. Evidence typically includes the original instruction, any NACK or return, status history, and relevant routing or account data.

Start when a payment is rejected (NACK, return, or negative status) or when it is stuck beyond the expected window. Triage first: confirm the payment id, last status, and whether the rejection or delay is already explained by a clear reason code. If the reason is unclear or client impact is high, open a formal investigation and follow the playbook steps.

• Retrieve the full trace: original message, any NACK or return, and all status updates in order.
• Identify the rejection stage: network (format), intermediary (routing), or beneficiary (funds, account, compliance).
• Extract reason code or narrative from the NACK/return and map it to a known cause (format, routing, R01/R02, etc.).

• Evidence pack should include: original instruction (sanitized if needed), NACK/return text or code, status timeline, and routing/BIC/IBAN used.
• Link to related reference pages (e.g. NACK format, R01, intermediary routing) so that operators can interpret codes and next steps.
• Use a consistent case format so that investigations are comparable and root-cause trends can be analyzed.