In any metro with several branches inside a few square kilometres, an unallocated lead list produces predictable waste: two branches call the same business, an RM travels across the city for one prospect, and leads in the gaps between catchments get worked by nobody. PIN-level routing is the standard fix, and it works — provided you understand what the address in a registration record actually is.
It is the declared principal place of business. For a large share of newly registered businesses, that is a residence, a chartered accountant's office, or a virtual office provider. The PIN is real. The implication that a commercial premises exists there is not.
Where the address comes from and where it fails
Four recurring cases break naive routing:
- Residential registration. New proprietorships very commonly register at the proprietor's home. Routable, but an RM expecting a shopfront will not find one.
- The CA's office. The accountant who handled registration used their own address. The business may be nowhere near it.
- Virtual office providers. Dozens or hundreds of unrelated businesses share one address, usually in a commercial district none of them occupy.
- Registered versus operating address. A business registers at a head office and trades from a warehouse in a different district entirely.
For general geographic filtering this is a precision problem, covered in state-wise GST registration data. For a bank it is more than that.
The address cluster is a KYC signal
This is the part that matters specifically to banks, and it is rarely mentioned in lead-generation material.
Group any lead file by exact address string and sort descending by count. Concentrations will appear — one address carrying forty, eighty, two hundred unrelated registrations. Most are legitimate virtual office and co-working providers serving real businesses.
But the same pattern is one that customer due diligence looks at. An account application whose registered address is shared with hundreds of unrelated entities is not automatically suspicious, and treating it as such would be both wrong and unfair to a large number of genuine small businesses. It is, however, a factor your onboarding process almost certainly already weighs — and knowing it before an RM invests a week is operationally useful in both directions.
Run this before distributing any list
Group by exact address, sort by count descending, flag anything above a threshold you set. It takes two minutes in a spreadsheet. It tells your field team which visits are worth making, and it surfaces the records where onboarding will ask questions. Neither insight is available from the record on its own.
Note also what this does to routing: two hundred registrations at one address are two hundred leads in one branch's catchment, which will distort every per-branch count you produce unless you handle them separately.
One business, several branches
The other structural problem is duplication that is not an error:
- Multi-state registration. One PAN, several GSTINs, one commercial customer. A business registered in Maharashtra, Gujarat and Karnataka appears three times.
- Multiple registrations within a state, indicated by position 13 of the GSTIN being above
1. - Additional places of business under one registration.
For a bank this is a relationship question, not a data question. Three GSTINs for one group is one customer with potentially several accounts, and the branch that gets there first probably should own the relationship.
Deduplicate on PAN — GSTIN positions 3 to 12 — before allocating, then decide ownership deliberately. Allocating on GSTIN alone guarantees three branches call the same finance person in the same week, which is exactly the impression you do not want to make on a new commercial customer.
A routing scheme that holds up
| Step | Rule |
|---|---|
| 1 | Deduplicate on PAN, not GSTIN |
| 2 | Flag shared-address clusters and route them separately, not to the nearest branch |
| 3 | Allocate remaining leads by PIN to a single owning branch — no PIN in two catchments |
| 4 | Assign unclaimed PINs explicitly; gaps are where leads die silently |
| 5 | For multi-GSTIN groups, assign one relationship owner and notify the others |
| 6 | Split by entity type before the RM sees the list — proprietorships and companies need different scripts |
| 7 | Set a return-to-pool rule: unworked after N days goes back for reallocation |
Step 4 is the one most often skipped. Territory maps drawn around branches leave gaps between them, and leads landing in a gap belong to nobody. Assign every PIN in your operating area to exactly one branch, including the ones nobody wants.
Step 7 is what keeps the list honest. Without it, leads sit in an RM's queue past the point of usefulness — and given how quickly the acquisition window closes, an unworked lead at day 20 is worth reallocating rather than preserving.
What an RM actually needs in the row
A registration record is not a call sheet. The gap between them is real work, and if the provider does not close it, your operations team will.
An RM-ready row carries: trade name (what the business calls itself, not just the legal name), constitution of business, nature of activity in language a human uses, registered address with PIN, days since registration, a contact number with its source noted, and the branch it is allocated to. Legal name alone gets a call opened with the wrong name, which is a poor start.
Two fields are worth insisting on that vendors often omit: days since registration, computed at delivery rather than left for the RM to calculate, and contact source, so the RM knows whether they are dialling a directory listing or a number from the business's own website. The second changes how the call should open.
Audit any sample against the 12-point data quality checklist before it reaches a branch.
Measuring the routing itself
Separate from conversion, measure whether the allocation is working:
| Metric | What it exposes |
|---|---|
| PIN coverage | Proportion of your operating area assigned to a branch |
| Overlap rate | Leads contacted by more than one branch — should be near zero |
| Unworked rate by branch | Capacity mismatch, or a branch quietly ignoring the list |
| Shared-address share | How much of your volume is virtual-office registrations |
| Contact rate by branch | Isolates data quality from RM effort, since data quality is constant |
Contact rate varying sharply between branches on the same data source is a management signal, not a data signal. That distinction is hard to see without per-branch reporting and easy to see with it.
Common questions
Is PIN-level routing worth it? For multi-branch metros, yes — it is the difference between a coordinated motion and several branches competing with each other. For single-branch towns it is unnecessary overhead.
How do I identify virtual offices? Count distinct registrations sharing an exact address string in your own file. No external data needed, and it is the fastest signal available.
Should shared-address leads be discarded? No. Many are legitimate businesses using a service that exists for good reasons. Route them differently — remote contact rather than a field visit — and let your normal onboarding process apply its own judgement.
What if the business operates somewhere other than its registered address? Common, especially for companies. Confirm by phone before any field visit. The cost of a wasted visit far exceeds the cost of a call.
Can we route on the business's actual location instead? Not from registration data, which only carries the declared address. Anything more precise has to be established in conversation.