Common Mistakes That Lead to Transfer Limit Issues
Most transfer failures do not come from the technology. They come from small paperwork errors and misunderstandings about how the limits are actually enforced. The wrong purpose code on Form A2, a document that does not match the declared profile, a running total the sender did not know they were tracking against — these are the reasons a transfer gets held, delayed, or reversed after the fact.
The good news is that the failure patterns are consistent. Once you know what they look like, you can avoid them well before the transfer is initiated. This piece walks through the specific mistakes that keep showing up, why the compliance systems catch them, and what to do differently next time.
Mistake One: The Wrong Purpose Code on Form A2
Every LRS outbound transfer requires a Form A2 declaration where the sender picks a purpose code. The code is a short alphanumeric tag that classifies the transaction for the Reserve Bank of India. It is meant to describe why the money is moving, and the bank uses it to apply the right tax treatment, the right documentation requirement, and the right monitoring flag.
The most common purpose code mistake is picking one that lets the transfer through the fastest, rather than one that describes what the money is actually for. A sender who is really investing in a foreign brokerage account might tag the transfer as a “family maintenance” transfer because the paperwork is lighter. This works exactly once. The AML system flags the transfer if the receiving account is an investment account, and the sender’s file goes into manual review the next time they transact.
The second most common purpose code mistake is a genuine confusion between adjacent codes. A tuition transfer that includes living expenses for a student abroad can be tagged as “studies abroad” or as “maintenance of close relatives,” and the two are treated differently for tax purposes. Picking the wrong one is not a violation, but it leads to a rework request from the bank when the supporting documents do not match the code.
The clean move is to describe the actual purpose in plain English to the provider’s support team before initiating the transfer, and let them tell you which code fits. Every provider has a list, and the list has more nuance than the drop down suggests.
Mistake Two: Missing or Mismatched Documents
Transfer holds due to documentation are the highest volume failure by a wide margin. The compliance team asks for a set of documents based on the purpose code, and the sender uploads something close but not exactly what was asked for.
The recurring patterns:
A pay slip is submitted where a tax return was requested. The two document types have different scopes — pay slip covers a month, tax return covers a year — and the compliance team asked for the annual figure because the transfer size warrants it.
A utility bill in a family member’s name is submitted as address proof. Every provider requires the address proof to be in the sender’s own name, or in the sender’s name jointly.
An admission letter is submitted without the accompanying fee schedule. The letter proves admission; the fee schedule proves the specific amount being transferred matches an actual charge. Without both, the transfer sits in review.
A hospital estimate is submitted without a doctor’s referral or a treatment plan. The estimate proves the cost; the referral proves the treatment is medically indicated. Providers ask for both because the AML system needs both to close the loop.
A sale agreement for a property purchase abroad is submitted without proof of the destination country tax clearance. Some destination countries require the buyer to show tax residency documentation before the funds can be received, and providers ask for this up front to avoid a return of funds later.
Every one of these is fixable, but each rework sends the transfer back to the queue and adds days.
Mistake Three: Exceeding the Aggregate Cap Without Realizing It
The LRS annual limit of USD 250,000 per financial year per individual is the ceiling that gets the most attention, but it is the aggregate cap that catches senders off guard. The 250,000 dollar figure is aggregated across every authorised dealer bank a sender uses. Banks report LRS usage to the RBI through a common infrastructure, and any sender who tries to reset the counter by moving to a different provider will find the aggregate flagged the moment they try to transact above their remaining allowance.
The math gets tricky when a family shares a transaction. A father sending tuition on behalf of an adult son sometimes uses the son’s own name on the transfer while paying from the father’s account, or vice versa. LRS tracks the sender name on the Form A2, not the funding source. The aggregate cap applies to whoever is named on the form. Getting this wrong once creates a compliance flag that carries through the rest of the year.
The financial year matters too. The Indian financial year runs from April 1 through March 31, not the calendar year. A sender who thinks they have “used up” their limit in December still has a full year’s worth of allowance to reset from April onward. The reverse also holds — a sender who has been at zero usage from April through November has the full 250,000 dollars available for a large transfer, but they cannot bring forward next year’s allowance.
Mistake Four: The Recipient Side Compliance Lapse
Every senders’ compliance story is only half the picture. The recipient side has its own KYC, and a mismatch there can hold a transfer that is fully clean on the sender end.
The typical patterns:
The recipient’s bank account KYC is limited or expired. Indian banks periodically re verify KYC and freeze inbound transfers when the KYC is stale. The sender sees the transfer initiated successfully and then held for recipient side clearance.
The recipient’s UPI handle is not linked to a KYC completed bank account. UPI usually inherits KYC from the underlying bank account, but some virtual UPI IDs sit on wallets or thin bank layers that have not completed full KYC. Higher value transfers into these handles get held.
The recipient’s PAN and Aadhaar are not seeded on the recipient bank account. For inbound transfers above a certain size, Indian banks require the PAN to be seeded so the transfer shows up correctly on the recipient’s Annual Information Statement. Without it, the transfer is held for the recipient to complete the linkage.
The recipient side is not something a sender can fix, but it is something they can check with the recipient before initiating the transfer. Ten minutes of coordination saves a two day hold.
Mistake Five: Splitting a Transfer to Avoid a Threshold
Splitting a large transfer into smaller ones to duck a threshold — whether the LRS aggregate cap, the TCS threshold, or a per transaction reporting trigger — is the fastest way to create a compliance flag that stays on the sender’s file.
The AML system is specifically built to detect structured transfers. A sender who has never remitted before, and suddenly makes eight transfers of USD 30,000 each in one month to the same recipient, is a pattern the system flags automatically. The provider’s compliance team then either asks for a source of funds explanation or files a suspicious activity report to the regulator, or both.
The reasons this fails are policy driven, not technology driven. The provider is regulated to detect structured transactions and would lose their license if they did not act on the pattern. The right move for a genuinely large transfer is to do it as one transfer against the right purpose code with the supporting documents, and let the higher tax or reporting treatment apply openly.
Mistake Six: Ignoring Currency and Rate Locking Windows
Some transfer failures look like limit issues but are actually rate lock issues. When a sender initiates a transfer and the amount they entered pushes the rupee equivalent above a limit they were unaware of, the transfer is held or reversed even though the sender thought they were under the ceiling.
This happens most often with LRS senders who calculate their remaining allowance in dollars but transact in rupees at the bank’s quoted rate. A transfer for 20 lakh rupees looks fine until the bank’s rate takes the dollar equivalent past the remaining allowance. Some providers rate lock at the moment of initiation and honor that rate through settlement; some rate lock only at final confirmation, and any move in the market between those two moments can push the transfer over a limit.
The clean move is to check the remaining allowance in the currency the provider tracks it in — usually USD — and leave a margin against rate movement.
Reality Check: Compliance Systems Are Faster Than They Used to Be
There is a lingering belief that AML systems are slow and that a small paperwork slip will not be caught. This has stopped being true in the last few years. Providers now run real time transaction monitoring against machine learning models that flag anomalies within seconds of a transfer being initiated. Manual review teams then act on the flags within hours during business hours.
The consequence for senders is that the old strategy of getting a transfer through and dealing with paperwork later does not work anymore. The transfer either clears at initiation or gets held immediately, and holding a transfer at the provider is not the same as holding it at the receiving bank. Money that is held mid flight can be returned to the sender’s account with the fee already deducted, which is a very expensive way to learn that the paperwork was not right.
Where Sliq Pay Fits
Sliq Pay’s inbound transfer flow, sending USD from the US to a recipient in India, is live today and does not run into LRS purpose code issues at all because it is an inbound transfer, not an LRS remittance out of India. Compliance is handled on the US side under FinCEN regulations and on the India side through the receiving bank’s own KYC. The recurring failures on this side are recipient KYC lapses, and Sliq Pay support helps both sender and recipient check the linkage before initiating a large transfer.
The LRS outbound product is a couple of months away. It is being built with the purpose code selection and the supporting document upload sitting inside the transfer flow itself, so the sender picks the correct code with support present and attaches the exact document set at the moment of transfer instead of finding out after the fact. Senders who want first access can join the waitlist on the marketing site.
Comparison: The Fixable Mistakes and Their Signatures
| Mistake | How It Shows Up | The Fix |
|---|---|---|
| Wrong purpose code | Transfer held for review, or reversed after receiving side rejects it | Describe the purpose in plain English to support before initiating |
| Missing or mismatched documents | Rework request within a business day of upload | Ask the review team for the exact document list for the purpose |
| Aggregate cap exceeded | Second bank flags the transfer at initiation | Track the running total in USD across all providers used |
| Recipient side KYC lapse | Transfer held after initiation, no fault of the sender | Confirm recipient KYC and PAN seeding before sending large amounts |
| Structured transfers | Compliance flag after two or three transfers to the same recipient | Send as one transfer with the right documentation |
| Rate lock timing | Transfer over the limit at settlement even though under at initiation | Leave a currency margin against rate movement |
Practical Tips Before You Initiate
Check the running LRS aggregate on your own record before starting. Providers show the used amount inside the app, or you can ask support for the certified figure.
Match the document names on file to the names on the KYC. If your passport shows one spelling and your PAN shows another, get one of them corrected before the transfer, not during.
Have the recipient run a small test transfer first if they have not received an inbound from you in a while. A small test flushes out KYC or PAN linkage issues without holding a large amount in review.
If the transfer is unusual for your normal pattern, tell support before initiating. A quick note that a large transfer is a real one time event — a property sale receipt, a tuition payment for a semester — usually keeps it out of AML review entirely.
Keep the paperwork organized in one place. When the review team asks for a specific document, the sender who can pull it in ten minutes gets the transfer released the same day, while the sender who has to search for it loses a business day of settlement.
FAQs
Why did my transfer get reversed after it looked like it had gone through? Two common causes. The receiving side rejected it, usually because the recipient bank’s KYC is not current, or the compliance team on the sender side pulled it back after a post initiation review found a documentation gap. The provider’s support team can tell you which one applies.
Can I appeal a compliance hold or do I have to restart the transfer? You can appeal in most cases. The support team escalates the file to the compliance team, and if the issue was a documentation gap that has been fixed, they release the same transfer without a full restart. If the issue was a purpose code mismatch, the transfer usually has to be redone against the correct code.
Does a hold on one transfer affect my other transfers? It can. A hold at initiation is usually specific to the one transfer, but a compliance flag on the file affects the next few transfers until the file is cleared. This is why getting the first flag off the record quickly matters.
Is there any documentation the provider is not allowed to ask for? Providers are bound to the regulator’s document lists for the purpose code. Anything outside that list is a request the sender can push back on. In practice, providers do not ask for out of scope documents because they get flagged in their own audits.
Does Sliq Pay hold transfers for compliance review? Sliq Pay runs the same real time monitoring that every regulated provider runs. The current live product for USD to India inbound transfers has a lightweight review layer because the compliance framework is simpler on that leg. The LRS outbound product being built has the full purpose code and document review inline in the transfer flow. Support is available on both.
What happens to the money if the transfer is reversed? The principal amount comes back to the sender’s funding account. Provider fees are usually refunded on reversals that were the provider’s call to make. TCS that has already been collected stays with the government and is claimed back through the ITR, since the government’s record of the collection does not roll back just because the underlying transfer did.
Can I use Sliq Pay if a previous provider flagged my file? Yes. Each provider’s compliance record is internal to that provider. Sliq Pay runs its own KYC from scratch on new customers and does not pull the flag from another provider. The customer still has to pass Sliq Pay’s own compliance review, but they start with a clean file.
How long does a compliance hold typically last? For a documentation issue, hours during business hours if the sender uploads the right document quickly. For a purpose code mismatch that needs a transfer redo, half a business day to a business day. For a genuine AML review that needs a source of funds explanation, several business days.
Before You Go
Transfer limit issues are almost always paperwork issues in disguise. The compliance systems are strict and fast, which cuts both ways — they catch mistakes quickly, but they also release cleanly once the mistake is fixed. Senders who match the purpose code to the actual use, submit the exact document set the review team asked for, and track their aggregate usage across providers rarely see a hold. Sliq Pay is building the LRS side of this with the review pieces sitting inside the transfer flow so senders can get the answers right before hitting confirm.
Disclaimer: The information provided on this blog is for general informational purposes only and does not constitute legal, financial, tax, or professional advice. Product features, pricing, eligibility, and availability may vary by country, user type, regulatory requirements, and are subject to change. Please refer to Sliq Pay’s Terms of Use and official product pages for the most accurate and up-to-date information. Sliq Pay makes no representations or warranties regarding the completeness, accuracy, or reliability of the content.
