Investigation: return of funds

A return of funds investigation starts when money comes back to the sender, and the sender, or the sender bank, must work out why it came back, what to do with it, and whether to resend the payment, and the return is sent as pacs.004, with a reason code that explains why. The investigation is about the reason code, because the reason decides the fix, and a return with reason code AC04, closed account, needs a new account number, while a return with reason code BE01, incorrect account number, needs a corrected account number, and the two must not be confused. Source: ISO 20022 pacs.004 definition; SWIFT CBPR+ usage guidelines; EPC SCT Rulebook 2025 on returns. Why returns happen is that the beneficiary bank cannot credit the payment, and the reasons are a short list that a 15-year SME should know by heart. The account is closed, AC04, the account number is incorrect, BE01, the account cannot receive the currency, the beneficiary is deceased, the payment is a duplicate, or the beneficiary bank has rejected it for compliance reasons. Each reason has a different fix, and the return message carries the reason code so the sender does not have to guess. The return must also carry the original references, including the UETR, so the sender can match it to the original payment, and a return without the UETR is a manual investigation, not a return. The parties are the creditor bank, which returns the funds, the debtor bank, which receives them and must credit its customer, and the customer, who must be told why the payment came back and what to do next. The intermediary banks forward the return along the same chain, in reverse, and each one must pass on the reason code unchanged, because a reason code that is changed in transit will mislead the sender. The message is pacs.004, and in the legacy MT world it was MT103 with a return indicator, or MT202 for a bank-to-bank return, and a 15-year SME must know both, because older case files use the MT names. How a return runs is shown by a worked example. A company in Madrid sends EUR 15,750 to a supplier in Athens on Monday, and on Tuesday the Athens bank returns it by pacs.004 with reason code AC04, closed account, because the supplier changed banks and closed the old account without telling the buyer. The Madrid bank receives the return on Tuesday, credits the company EUR 15,750, and tells the company the reason, closed account, and asks for the new account details. The company obtains the new IBAN from the supplier on Wednesday, resends EUR 15,750 on Wednesday, and the supplier is credited on Thursday, three days late, but the money was never lost, and the case closes with the reason recorded and the supplier master data updated, so the next payment goes to the new account. On success the funds come back, the customer is told the reason, the details are corrected, and the payment is resent, and the case closes with the reason and the correction recorded. On failure the return cannot be matched to the original payment, because the UETR was lost, and the funds sit in a suspense account while operations try to match them by amount and date, which fails when two returns for the same amount arrive on the same day. The most expensive failure is a return that is credited to the wrong customer, because the matching was done by amount alone, and then the bank has two errors to fix, the return and the misapplied credit, and the customer trust is damaged twice. The data in a pacs.004 is the original payment identification, the UETR, the returned amount, which may be less than the original if charges were deducted, the return reason code, and the return identification. The reason code is the field that matters most, because it decides the fix, and a BA must require the reason code to be shown to the customer in plain language, not just as a code, because a customer who is told AC04 will call the bank, while a customer who is told the beneficiary account is closed will obtain the new account details. The returned amount matters too, because a return that is short by the charges must be explained, or the customer will open a second case about the shortfall. Edge cases show the depth. 009, is different from a return of a customer payment, because the cover return must be matched to its customer payment, and the two must be returned together or neither, or the bank will have the money but not the instruction, or the instruction but not the money. A return that arrives after the original payment has already been resent creates a duplicate, because the customer now has the original funds back and the resent payment in flight, and the bank must hold the return until the resent payment is confirmed, or it will credit the customer twice. A return for a payment that was sent under OUR, where the sender paid all charges, must return the full amount, and any deduction must be investigated as a charges error. The effect on the bank is a return queue that must be matched, credited and explained, and a manager who can see how many returns are unmatched and how old they are. The effect on the customer is a payment that did not arrive, and a clear reason and a clear next step, which is the difference between a customer who resends the payment and a customer who complains. The effect on operations is a reconciliation control, because every return must be matched to an original payment, and an unmatched return is a break that must be investigated the same day. What a BA, PO or SME must understand is that a return is the system working, and the reason code is the diagnosis. The requirement must name the pacs.004 flow, the reason codes, the customer message in plain language, the matching rule by UETR, and the resend process. The test is to take one returned payment, read the reason code, state the fix, and resend the payment with the correction, because if the reason cannot be stated in plain language, the customer will not know what to do. Further reading: ISO 20022 pacs.004 definition; SWIFT CBPR+ usage guidelines; EPC SCT Rulebook 2025 on returns. Last reviewed 7 November 2026.