A returned payout feels like a system failure. Usually it is a data failure, and usually the data was wrong before anything was sent. The useful question is not why the payment bounced but where it could have been stopped earlier — because almost every cause on this list can be caught before the money leaves.
1. The recipient’s name is not how the bank spells it
The most common cause on the corridors that check names at all, and Thailand is the extreme case: the name must be in Latin characters exactly as in the passport. Transliterated by ear, shortened, reordered — all refused.
Catch it: show the expected format in your form, with an example. Validate character set before submission. Where you already hold identity documents, prefill from them rather than asking again.
2. The account identifier is the wrong kind of number
Someone gives you sixteen digits for Mexico. That is a card, not a CLABE. Someone gives you eleven. That is an internal account number. Neither will route.
Catch it: validate length and shape per corridor, not globally. A single “account number” field with no rules is a guarantee of this failure.
3. The institution and the number disagree
A CLABE carries its bank in the first three digits. Pick the wrong bank from a dropdown and the payment goes where the number says, not where the label said.
Catch it: cross-check the two whenever the format allows it. Where it does not, consider whether the dropdown should exist at all.
4. The amount has decimals the currency does not use
Whole rupees, whole dong, whole pesos, whole rupiah. Systems built on a single decimal assumption will send 1000.00 into a corridor that takes integers.
Catch it: store precision per currency and round at the point of entry, where the user can see it, rather than at the point of sending, where they cannot.
5. The code already had an amount in it
QR-specific. A code from a till carries a total. Pay anything else and the receiving bank refuses it — after your user has committed.
Catch it: decode before you display. Read what the code contains, and if it specifies an amount, show that figure and do not let it be edited.
6. The recipient’s account is closed, frozen or dormant
Nothing on your side is wrong. The account simply cannot receive.
Catch it: you cannot, and you should stop trying. What you can do is handle it gracefully — return the funds, tell the user plainly, and let them supply different details without starting over.
7. Compliance stopped it
Screening flagged something, or the receiving institution’s own checks did. These are not errors and cannot be engineered away.
Catch it: design for it. Show the operation as under review rather than as failed, and make sure your support team can see the same state your user sees.
8. Sender details are incomplete for that market
Some corridors want more about the sender than others — a document, an address, an email. A sender registered when you only served one country may lack what a new one asks for.
Catch it: top up the existing record instead of creating a new sender. The identifier should stay stable across your whole history.
The pattern underneath
Six of these eight are validation problems, and every one of them can be caught at the moment of entry rather than at the moment of sending. The difference matters more than it seems: at entry, the user is present, has the details in front of them and can fix the problem in seconds. At sending, they have moved on, and fixing it costs a support ticket.
Build the rules per corridor, put them in the form, and the returned-payout rate stops being interesting.