pacs.004 returns after stablecoin settlement: what the message must carry

A cross border payment fails at the last step more often than anyone would like. The beneficiary account is closed, the account number is wrong, or the receiving bank declines after a compliance review. In ISO 20022 the answer is a pacs.004, the message that returns a settled payment to the sender. The mechanics are well understood when both legs moved through correspondent accounts. They are much less understood when the settlement leg was a stablecoin transfer on a public blockchain. This article explains how pacs.004 returns work after stablecoin settlement, what the return message must carry, which reason code to choose, and the controls the return leg needs before value moves back.

What is a pacs.004 return, and when does a payment need one?

pacs.004 is the ISO 20022 payment return message. It sends value back along the chain after a payment has already settled. That timing is the whole distinction. A pacs.004 is not a cancellation. A cancellation asks a bank to stop a payment before it settles, and that request travels as a camt.056. The reply is a camt.029. Only once the funds have left does the answer become a return.

Two triggers dominate. The first is a failure on the beneficiary side: a closed account, an incorrect account number, a blocked account, or a regulatory hold placed by the receiving institution. The second is a request from the original sender, usually a duplicate payment or an error caught after release. Both end in the same place: the receiving institution sends the money back and explains why in a structured code.

Returns are ordinary, and they are not a sign of a broken rail. What separates a good operation from a poor one is speed, a clear reason, and whether the sender can match the return to the original payment without opening a case.

What changes when the original leg settled in stablecoin?

One fact drives everything else. A confirmed blockchain transfer cannot be reversed. There is no recall, no unwind, and no network level debit of the receiving address. So a return after stablecoin settlement is a fresh transfer, sent in the opposite direction, with its own transaction hash and its own confirmation.

That makes the return a payment in its own right. It needs an instructing party, a beneficiary, an amount, a reason and a record. It needs sanctions screening, because the party receiving value back is now a beneficiary rather than an originator. It needs Travel Rule data, because the direction has flipped and the originator and beneficiary roles have swapped with it.

It also needs a destination address. The safest policy is to return value to the address that funded the original transfer, and only to that address. A return instruction that names a new destination is a well worn social engineering route. Treat any change of return address as a new beneficiary, with the same approval and the same screening a new beneficiary would get.

Amount is the other difference. If the original payment converted currency on the way out, the amount coming back may not equal the amount that was sent. Network fees and intermediary charges may also have been deducted. The message has to say so, rather than leave the sender to reconcile the gap.

A return on a public blockchain is not an undo. It is a second payment, and it deserves the same screening, the same message and the same audit record as the first.

What must a pacs.004 carry when returns follow stablecoin settlement?

Start with the references, because they are how the two payments are joined. The return quotes the original end to end identification and the original transaction identification. It carries the original UETR, so the sender can match the return to the payment it reverses inside the same tracking record. Where the original was a pacs.008 customer credit transfer or a pacs.009 interbank leg, the return points at that message.

Then the amounts. The returned interbank settlement amount is the figure actually sent back. Where it differs from the original settlement amount, charges information should explain the difference line by line. Do not net silently. A sender that receives less than it sent, with no charge detail, will open an investigation, and the investigation costs far more than the field would have.

Then the reason. A structured return reason code belongs on every pacs.004. Narrative text is useful as a supplement, but it is not a substitute. Codes can be counted, sorted and charted.

Finally, the settlement detail that the on chain leg introduces. The record should name the token, the chain, the returning address and the transaction hash of the return transfer. Schemes vary in where that detail sits, so many institutions carry it in supplementary data or in the settlement record they keep beside the message. Wherever it sits, it has to be in the file. An auditor asking how a pacs.004 returns value to a sender will want the hash, not a screenshot.

Which return reason code belongs on the message?

Reason codes come from the ISO 20022 external code sets, and the working list is shorter than most teams expect. A handful cover the large majority of returns in a cross border book.

AC04 marks a closed account. AC01 marks an incorrect account number. AC06 marks a blocked account. AM09 covers a wrong amount. CUST records a return requested by the customer. DUPL marks a duplicate payment. FOCR follows an earlier cancellation request. RR04 is a regulatory reason, and it is the code most often used when a compliance decision, rather than an account problem, stops the payout.

Choose the narrow code and keep the generic narrative code for cases where nothing fits. Reason codes are how an operations team learns where failures cluster. A book tagged AC04 and RR04 tells you whether to fix your beneficiary data or your screening thresholds.

How should an institution run the return leg, step by step?

Returns deserve a written runbook, because they happen under time pressure and often involve an unhappy customer. Run these steps in order, and record the output of each one.

• Freeze the payout attempt and record the reason the beneficiary leg failed, with the name of the person or system that made the call.
• Confirm the original settlement on chain: the transaction hash, the token, the chain, the amount received and the funding address.
• Decide the return amount, and separate the original amount from any network fee, charge or currency conversion that has to be disclosed.
• Screen the return as a new payment. Sanctions and PEP checks on both parties, plus a risk check on the destination address.
• Send the value back to the funding address, and capture the hash of that return transfer before you send any message.
• Build the pacs.004 with the original references, the original UETR, the returned settlement amount, the charges detail and the reason code.
• Update the case record so the original payment, the return transfer and the return message all sit under one reference, then tell the customer.

Note the order of the last three steps. Move the value, capture the evidence, then send the message. A return message that goes out before the transfer is confirmed creates an exposure that nobody has agreed to carry.

What controls does a returned stablecoin payment need?

Treat the return as a new payment for every control that matters. Screen both parties again. Run a risk check on the destination address, because an address that was safe when it funded a payment last month may sit behind a new alert today. Apply the Travel Rule obligations that attach to the transfer in the direction it is now moving. The FATF has kept originator and beneficiary information at the centre of its standards for virtual asset transfers, and a return is a transfer.

Set a policy for timing. How long may funds sit while a return is decided? Who approves a return above a given size? What happens to a currency gain or loss that arises between the two legs? These questions are easier to answer in a policy than in the middle of an incident.

Then close the accounting loop. The return has to land in the ledger against the original payment, not as an unexplained credit. Tie the original hash, the return hash, the original UETR and the reason code into one record. That record is what an examiner reads, and what lets an operations lead answer the only question a customer asks: where is my money, and when is it coming back.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Settlement is in regulated stablecoins such as USDC and USDT on public blockchains, completing in minutes with on chain auditability, so the original transfer and the return transfer are both observable rather than asserted. The platform is ISO 20022 native, with pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns inside head.001 envelopes, tracked end to end by UETR, so a return and the payment it reverses sit under one reference. Compliance is built in, with KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper evident audit trail, so the return leg is screened and evidenced on the same rails as the original. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.