What is actually inside the RBI IFSC dataset

If you have ever looked up an IFSC code online, you have almost certainly been reading the same file. The Reserve Bank of India publishes the master list of bank branches that take part in NEFT and RTGS. Razorpay republishes that list as a plain CSV on a public repository, and the lookup sites — this one included — build their pages from it.

That shared origin is worth knowing, because it means the sites you compare are not independent. If the file says something odd about your branch, every site will say the same odd thing. And the file does say some odd things.

We keep every release of it that shipped a CSV going back to February 2016 — 135 of them, which reduce to 132 distinct builds once byte-identical rebuilds are removed. What follows was measured against the current one, not repeated from anywhere.

The sixteen columns

Each row is one branch. Here is every column, and how often it actually contains something:

DISTRICT is not a district

This is the trap that catches people first, and it is the reason you will not find district pages on this site.

The column called DISTRICT contains 39,314 distinct values. India does not have anything close to that many districts; the real number is in the hundreds. What the column actually holds is locality names — values like AKKALKOT DIST SOLAPUR and AKHUAPADA DISTRICT BHADRAK, which are neighbourhoods and towns with the word "district" somewhere in the string.

It is also identical to the CENTRE column on every one of the 183,214 rows. Two columns, one set of values. A site that generates a page for each "district" is generating 39,314 pages of a thing that does not exist.

SWIFT is an institution, not a branch

The SWIFT column looks like a feature and is not. 11,884 rows carry a SWIFT code — but those rows contain only 878 distinct codes, and one of them, HDFCINBB, is attached to 11,007 branches on its own. The remaining 877 codes appear exactly once each.

So a "SWIFT code lookup" built on this file returns, for the overwhelming majority of searches, the same eight characters that identify HDFC Bank as an institution. That is not a branch lookup.

There is a sharper problem underneath. We found 270 rows tagged with HDFCINBB that are not HDFC Bank branches at all — they are small co-operative banks and a few foreign banks routing through HDFC's infrastructure. Publishing HDFC's SWIFT code on a page headed with a different bank's name would be actively misleading about where an international payment would land. That is why this site has no SWIFT pages.

MICR codes are not unique

The MICR code is the nine-digit number on the bottom band of a cheque. The file has 153,344 of them, covering 152,716 distinct codes.

The gap matters. 522 MICR codes are shared by more than one branch, and one code is shared by 38 branches. Worse, 205 of those shared codes span more than one bank. A lookup tool that takes a MICR code and sends you straight to a single branch page will, in those cases, send you to the wrong branch — and sometimes to the wrong institution entirely.

It is a small fraction of the file. It is not a small thing to get wrong on a page about moving money.

The phone column looks three-quarters full. Less than half of it is usable.

The CONTACT column is filled on 75.1% of rows, which sounds useful. Then you look at what is in it.

• 45,564 rows have nothing at all.
• 27,261 rows carry a number that also appears against other branches — dozens or thousands of them. That is a call centre, not the branch.
• 22,196 rows are malformed: too few digits, or an STD code glued onto a toll-free number so the result cannot be dialled.
• 1,801 rows are placeholders such as 1234567890 and 9999999999.

After removing all of that, the number of branches with a plausible, unshared, well-formed phone number of their own is 86,392 — 47% of the file, not 75%.

We publish none of them. A phone number that is stale or belongs to someone else is the highest-risk field in this dataset, because the person reading it is usually about to discuss a payment. The RBI's own fraud awareness material specifically warns about customer-care numbers found through search results. If you need to call your branch, use your bank's own branch locator.

The first four letters of an IFSC are not a reliable bank identifier

An IFSC looks like it decomposes cleanly: four letters for the bank, a zero, then six characters for the branch. The zero part is solid — position five is 0 on all 183,214 rows, in every release we hold.

The bank part is not. 52 banks in this file use more than one IFSC prefix, and 39 prefixes carry more than one bank. The HDFC prefix alone covers 270 different bank names, because many small co-operative banks operate on a sponsor bank's payment infrastructure and are issued codes under the sponsor's prefix.

This is why, when you look up a co-operative bank on this site, its IFSC may begin with HDFC, ICICI or Axis. It is not an error in the data and it does not mean your account is with that bank. It means your bank's transfers are routed through a sponsor.

Where the addresses lose their spaces

Every row has an address. Many of them contain words run together — VISHAL SHOPPING CENTRESIR M.V. ROAD, where "CENTRE" and "SIR" have collapsed into one word.

That damage is in the source file. We tested a rule to split those tokens apart and it fired on 72% of the corpus and broke real names: FREE PRESS MARG, NARIMAN POINT came apart into "Free Press" and "Marg, Nariman Point", because ROAD, MARG, NAGAR and CHOWK are suffixes in Indian addresses, not separators.

So we show addresses exactly as recorded and say where the errors come from. An address you can see is imperfect is more useful than one that has been silently rearranged.

What this file is genuinely good at

It would be easy to read the above as a case against the dataset. It is not. The file is accurate about the thing it exists for: which branch an IFSC code routes to.

The IFSC column has no duplicates. Branch names, addresses, cities and states are present on essentially every row. The NEFT and RTGS flags are meaningful. Updated every few weeks and published openly, it is a better public dataset than most countries have for this.

The problems are all in the fields that were added later and filled in unevenly — SWIFT, CONTACT, MICR, DISTRICT. Knowing which is which is the whole job.

How to read a lookup site, including this one

Three questions worth asking of any IFSC site you land on:

1. Does it say which version of the data it is showing? Branches open and close. A page with no date behind it is a page that cannot be checked.
2. Does it fill in blanks? If a site shows opening hours, a locker facility or a payment-modes list for every branch in India, ask where that came from. It is not in this file. We have seen sites publish such fields as structured data on hundreds of thousands of pages.
3. Does it ever say it does not know? A directory built on an imperfect source that never once admits a gap is not being careful.

Every page on this site names the release it was built from, and says "not present in the source record" wherever the file is silent. That is a lower bar than it sounds like, and it is worth checking on any site you rely on.