Every payout carries the same quiet risk: the account number is valid, the transfer succeeds, and the money reaches the wrong person. Account numbers have no checksum you can rely on and a mistyped digit often lands on a real account. Verifying the destination before the first payment is the cheapest control available.
Why account numbers need verifying at all
A PAN has a structure. A GSTIN has a checksum. An Indian bank account number has neither in any universal form — lengths and formats vary by bank, and there is no general algorithm that tells you a number is wrong.
The consequence is specific and unpleasant: a transposed digit frequently produces another valid account number, at the same bank, belonging to someone else. The transfer succeeds. Your system records success. The intended recipient is not paid, and recovering the funds depends on the goodwill of a stranger.
What you can check locally
The account number resists validation, but the IFSC does not, and a wrong IFSC is a common enough error to be worth catching for free.
- An IFSC is eleven characters: four letters for the bank, a zero, then six characters identifying the branch.
- The fifth character is always zero, which catches a class of typo immediately.
- The bank prefix can be checked against a list, so a non-existent bank code fails in the browser.
- The account number length can be range-checked per bank where you know the bank from the IFSC.
Penny drop: deposit a rupee and read the name back
A penny drop sends a token amount to the account and reads the beneficiary name returned by the receiving bank. It is the method with the strongest guarantee, because a real transfer actually completed.
- It proves the account exists, is active and can receive credits — the exact conditions your payout needs.
- It returns the name as the receiving bank holds it, which is the authoritative version for name matching.
- It costs a small amount per check, plus the transferred amount, which adds up across a large beneficiary base.
- It is slower than a lookup, because it depends on the rail and the receiving bank rather than a database read.
- The customer may see a small unexplained credit, which is worth telling them about in advance.
What a penny drop can still miss
It is the strongest available check, not a guarantee. Knowing its limits stops it being trusted further than it should be.
- An account can receive credits and still be frozen for debits, which does not matter for a payout but might for other flows.
- The name returned is the bank's record, which can itself be stale — a married name not yet updated, for instance.
- Joint accounts may return only one holder's name, which will not match a legitimate co-holder.
- A successful penny drop today does not mean the account is open next month.
Penny-less: ask without moving money
A penny-less check queries account validity and the registered name without transferring anything. It is cheaper and faster, with a weaker guarantee.
- No money moves, so there is no stray credit for the customer to query and no amount to reconcile.
- It is quicker and cheaper per check, which matters when verifying thousands of beneficiaries.
- Coverage is not universal. Support varies by bank, so you need a fallback for the accounts it cannot answer for.
- It confirms the account record rather than demonstrating that a credit will actually settle.
Choosing between them
| Situation | Suggested method | Why |
|---|---|---|
| Payroll onboarding | Penny drop | High value, repeated monthly; the stronger proof is worth it once |
| Bulk vendor import | Penny-less, penny drop on failures | Volume makes per-check cost material |
| First payout to a new beneficiary | Penny drop | The one transfer most likely to be wrong is the first |
| Re-verifying an existing payee | Penny-less | You already have a settlement history with the account |
| High-value one-off transfer | Penny drop | The cost of the check is negligible against the amount |
| Customer-supplied refund account | Penny drop | The account is new to you and the customer is motivated |
The same cost-versus-certainty reasoning governs how you sequence verification generally, which the PAN verification guide covers for the identity side of onboarding.
Name matching, again
Both methods hand you the same final problem as PAN verification: the name you get back will rarely match the name you hold, character for character. The same approach applies — normalise, compare token sets, score rather than decide, and keep a review band in the middle.
One difference is worth noting. A name mismatch on a payout destination is more serious than one during identity onboarding, because the consequence is money leaving to the wrong party rather than an account being created. Set the review band wider and the auto-accept threshold higher than you would elsewhere.
The cases that need a human every time
- A partial name match where the surname differs. Given names vary; surnames varying is a different kind of signal.
- An individual's name on an account meant to be a company's, or the reverse.
- Any mismatch on an account that has never received a payment from you before.
- A beneficiary whose account details changed shortly before a large payment — the classic pattern for redirection fraud.
That last one deserves a control of its own: flag any payment above a threshold to a beneficiary whose bank details changed within a recent window, and require a second approver. It is a cheap rule that addresses one of the more expensive failure modes.
Where verification belongs in the flow
Verification is most valuable at the point the beneficiary is created, not the point the payment is sent. At creation there is a person present who can fix a typo. At payment time there is a batch running and nobody to ask.
- Verify on addRun the check when a beneficiary is created or their account details change, while the person who entered them is still there.
- Block unverified destinationsMake a verified account a precondition for payment rather than a warning on the way past.
- Re-verify on change onlyTreat an edit to the account number or IFSC as invalidating the previous verification.
- Cool off after a changeRequire a short delay or a second approver before a large payment to recently changed details.
- Keep the evidenceRecord what was returned and when. It is what answers a dispute about where money went.
How this fits a batch run — and why verification belongs outside the run rather than inside it — is covered in the bulk payout guide.
Verifying a base you inherited
Adding verification to a new product is straightforward. Applying it to forty thousand beneficiaries already in the system, many added before anyone checked anything, is the harder and more common problem.
- Segment before verifying anythingBeneficiaries with a long clean settlement history are lower risk than ones added last month and never paid. Verifying in that order spends the budget where it buys the most.
- Treat settlement history as partial evidenceAn account that has received twelve monthly payments without a return is demonstrably real and reachable. That is not the same as confirming who owns it, but it is not nothing.
- Verify on next use, not all at onceVerifying a dormant beneficiary nobody will pay again is wasted. Gating the next payment on a verification spreads the cost and targets it perfectly.
- Expect a meaningful failure rateLegacy data contains closed accounts, changed banks and people who left. Budget the review time, not just the API calls.
- Fix the source, not only the recordsIf the base is bad because the form never validated anything, verifying it once leaves you doing this again in two years.
Frequently asked questions
Is penny drop always more reliable than penny-less?
It carries a stronger guarantee, because a real credit completed and the receiving bank returned the name it holds. Penny-less confirms the account record, which is usually sufficient, but does not demonstrate that a credit will settle.
Will the customer see the penny drop amount?
Yes — a small credit appears in their statement. Say so during onboarding; an unexplained deposit generates support contacts that one sentence would have prevented.
Can I validate an account number without an API?
Not reliably — Indian account numbers have no universal checksum. The IFSC does validate locally, though: it is eleven characters with a zero in the fifth position, and the bank prefix can be checked against a list.
What should happen on a name mismatch?
Stop and route it to a human. A mismatch on a payout destination means money could reach the wrong party, so it deserves a stricter threshold than an identity check elsewhere in onboarding.
Do I need to verify before every payment?
No. Verify when the beneficiary is created and again whenever the account number or IFSC changes. Re-verifying unchanged details on every transfer costs money and tells you nothing new.
What if a beneficiary changes their account just before a large payment?
Treat it as a distinct risk. Flag payments above a threshold to recently changed details and require a second approver or a short cooling-off period — it is a cheap rule against one of the more expensive failure modes.
Does a successful penny drop mean the account will always work?
No. It confirms the account could receive a credit at that moment. Accounts close, freeze and change, which is why verification is stored against the beneficiary with a re-check on any detail change.
