Inward remittance rejected or returned? Why it happens and how to prevent it

Your client says they sent it four days ago. They have forwarded the confirmation from their bank. Nothing has landed in your account, nobody has called you, and the tracking reference they gave you means nothing to anyone you can reach on a support line. Then, sometimes a fortnight later, the money reappears in your client's account instead of yours, minus a fee neither of you agreed to.

Inward remittances to India fail for a surprisingly short list of reasons. Almost all of them are preventable, and almost all of them are invisible until they have already cost you two weeks. Here is what each failure actually looks like from your side, and what to fix so it does not repeat.

First work out which of three things has happened

Late, held, and returned are three different problems with three different fixes, and the panic tends to blur them together. A late payment is still moving through correspondent banks and will arrive. A held payment has reached a bank in the chain and stopped there pending information, which means someone is waiting on an answer that nobody has asked you for yet. A returned payment has been rejected and sent back toward the sender, and no amount of waiting will help.

The document that tells you which one you are dealing with is the MT103. Ask your client to request it from their bank; it shows the payment's path, the intermediary banks involved and the reference numbers each one assigned. If you have not worked with one before, our guide to the MT103 and how international wires actually move covers how to read it. Everything below assumes you have established the payment was rejected rather than merely slow.

Reason one: the beneficiary name does not match the account

This is the single most common cause, and the most frustrating, because the mismatch is usually trivial. Your account is in the name of your registered business, and your client paid Priya Sharma because that is who they email. Or your account says Sharma Design Studio Private Limited and the payment instruction says Sharma Design. Or your PAN-linked name carries a middle name the invoice omitted.

Banks vary in how strict they are. Some credit the account and flag it, some hold the payment and ask a question, and some reject it outright. You cannot predict which, and the same bank may behave differently on a 500 dollar payment and a 50,000 dollar one. Larger amounts attract more scrutiny, which means the mismatch you have been getting away with for a year surfaces on your biggest invoice.

The fix is dull and permanent. Send your client the exact beneficiary name as it appears on your account, in writing, and ask them to save it in their payment template rather than retyping it. If you invoice as a sole proprietor with a trading name, decide which name the account uses and make every invoice and payment instruction match it. Consistency beats accuracy here, because the bank is comparing two strings, not judging who you are.

Reason two: the purpose of the payment is missing or wrong

Every foreign currency payment entering India has to be classified by purpose code for the bank's reporting to the RBI. Where the incoming instruction carries no usable description, or a description that does not fit any code cleanly, your bank cannot complete its side of the paperwork.

In practice this usually produces a hold and a query rather than an outright return, which is the good news. The bad news is that the query often goes nowhere: it lands with a relationship manager who emails an address you do not check, and the payment sits unclassified while everyone assumes someone else is dealing with it. Payment references like invoice 41 or consulting are what trigger this. A description naming the actual service, matching your invoice, does not.

Reason three: the account details are incomplete for the corridor

Different corridors need different things, and clients reuse whatever worked last time for someone else. A US client sending to India needs your SWIFT code and full account number, not a routing number. A European client will ask for an IBAN, which Indian bank accounts do not have, and may enter something invented to get past their form validation. A UK client may try to send domestically through Faster Payments because your details looked local.

Any of these produces either a rejection at the sending bank or a payment that travels partway and stops. The prevention is to hand clients a single block of correctly formatted details for their specific country rather than letting them assemble it from your email signature and guesswork.

Reason four: a compliance or sanctions screen somewhere in the chain

A wire from New York to Mumbai may pass through two or three correspondent banks, and each one screens it independently. A screen can trip on something that has nothing to do with you: a company name resembling a sanctioned entity, a payment reference mentioning a restricted country, an unusual amount from a new counterparty, or simply your client's own bank deciding a first payment to India warrants a look.

These are the hardest to resolve, because the bank holding the money is often one neither you nor your client has any relationship with. Only the sender can chase it, through their own bank, quoting the MT103 reference. You cannot escalate into a correspondent bank you are not a customer of, and support staff at your own bank genuinely cannot see what is happening at an intermediary.

How long a returned payment takes to come back

Longer than anyone expects. A rejected payment does not bounce straight back; it retraces the same correspondent chain it came down, and each hop takes its own processing time. One to three weeks is a fair expectation, and compliance-related returns can run longer because the holding bank works to its own timetable. Then the payment has to be reissued correctly, which starts the clock again.

This is the real cost of a failed remittance, and why prevention is worth more than any fee saving. A single rejection on a month-end invoice can push payment into the following quarter, distort your realisation timeline, and leave you chasing a client who reasonably believes they have already paid you.

Who pays for a failed payment, and what changes in October

A returned wire rarely comes back whole. Each bank in the chain may deduct a handling charge on the way out and again on the way back, so your client can end up receiving meaningfully less than they sent, for a payment that never arrived. Neither of you authorised any of it, and there is usually no itemised breakdown.

From 1 October 2026 exporters get some leverage here. Under the new export regulations, every authorised dealer bank must publish a standard operating procedure covering how it handles export transactions, along with the main features of its policy, on its own website. It must also provide a grievance escalation route with an appeal to a higher level inside the bank, which gives you somewhere to go beyond the branch official who cannot help.

The same regulation states that a bank shall not levy charges or penalty on its customer for that customer's own regulatory delay or violation, and that charges must be reasonable and proportional. Worth knowing before you accept a penalty line on a statement without asking. One caveat: banks are still publishing these procedures, so how much of this bites in practice will depend on what each one actually puts up.

The five-minute fix that prevents most of this

Write your payment details once, correctly, and never let a client reconstruct them. That block should carry the beneficiary name exactly as your account holds it, the account number in the format that corridor expects, the SWIFT or local routing details for the country your client is paying from, your bank's full branch address, and a payment reference format that names the service and the invoice number.

Then put it on the invoice itself rather than in an email thread, and ask new clients to send a small first payment before a large one. A 50 dollar test that fails costs you a week. A 15,000 dollar invoice that fails on the same error costs you a quarter.

Removing the failure points altogether

Most of these failures come from the same root: an international wire crossing multiple banks, each with its own rules, to reach an account that was never designed to receive foreign currency. A Winvesta Global Collections Account changes the shape of that problem. Your client gets local account details in their own country and pays you as a domestic transfer, so there is no correspondent chain to get stuck in, no IBAN to invent, and no routing format to guess at.

The name on the account is your registered name, the purpose of each payment is captured when it arrives, and a FIRA is issued for every credit, so your realisation evidence exists without you asking for it. It does not make compliance screening disappear, but it removes the three failure modes you can actually control.