PAN in Mutual Fund Records: The Key the Folio Hangs On
A mutual fund record is keyed to the permanent account number (PAN), an identifier the tax authority hands out. No scheme and no asset manager makes it. Its work is to let accounts sitting with different managers be recognised as one person's, and when the copy on an account and the copy an agency holds are not identical, every operation needing both of them together halts.
Start with the thing the word hides. PANThe permanent account number, an identifier issued to a person by the tax authority and used far outside investing., written out once, is the permanent account number issued by the tax authority. Most readers meet it as paperwork: a number somebody asks for, on a form to be filled in, at a counter where nobody explains why it is wanted. The identifier is something quite different from paperwork. The identifier is a field inside a record, and the work that field does is what shows precisely what stops when the field is wrong.
Girnar Asset Management Limited, an invented asset manager, runs the Girnar Large Cap Equity Fund, an open ended equity scheme with net assets of Rs 4,200 crore and 120.00 crore units in issue, which puts the value of a unit at Rs 35.00. The scheme is held across 3,80,000 folios. Kalyani Bhagat manages the portfolio and Sohail Merchant heads operations. Girnar Asset Management runs a second scheme too, the Girnar Broad Market Index Fund, and that one matters only where a holder needs accounts sitting in more than one place.
Three things are settled elsewhere and are carried in as they stand: what a scheme is and who runs it, what a unit is and how the value of one is struck, and how money becomes units. Account identity is covered separately, and that treatment names the identity keyThe field a record system uses to recognise which person a record belongs to, matching separate records to one person., the one field capable of tying two accounts back to a single person. A statement loses its grouping when that field does not agree across two accounts. Two questions decide the rest: what a key is as an idea about records, and why a difference of a single character in one is not a small difference.
What is PAN, and who issues it?
The permanent account number is an identifier issued to a person by the tax authority. The definition stops there. The part that matters most is not about the identifier at all, it is about the issuer. The identifier is created outside this subject altogether, so no scheme, no asset manager and no record keeper brings it into being, controls it, alters it or takes it away. A mutual fund record receives an identifier that already exists somewhere else, copies it into a field, and that is the full extent of its power over the thing.
Everything else about the identifier belongs to somebody else to state. Its shape, who has to hold one, how a person applies for one, whether any exception exists for anybody, and what applies to a person living outside India all sit with the tax authority at incometaxindia.gov.in. Where the identifier has to appear inside a mutual fund record sits with the Securities and Exchange Board of India (SEBI) at sebi.gov.in. Conditions of that kind get revised, and a copy of one is not merely out of date on the day it changes, it is wrong, and wrong in exactly the place a reader would have no reason to check.
An arrangement shaped like this turns up in ordinary life. Consider the number on an electricity connection. The distribution company issued it, it identifies that connection inside their register, and when a shop takes a copy of the bill to open a delivery account it is reusing an identifier it did not create and cannot change. If the number printed on the bill and the number the shop typed into their book are not the same, the shop cannot find the customer who calls. Mark what has and has not happened there: the electricity is entirely unaffected, the bill is unaffected, and one lookup in one register has failed. A failed lookup beside an untouched thing is the shape of everything that follows.
What does a key actually do inside a record?
A key is a field used to bring together records kept in different places, by different people, for different purposes. Read that twice. The working part of it is not the word field, it is the words different places. A register can always find its own rows, so a key inside one register is barely doing anything. A key starts earning its keep the moment there are two registers that were never designed together and somebody needs to know which row in the first belongs with which row in the second.
Do not think of a key as something the record knows about a person. Think of it as a handle, and the entire worth of a handle lies in the identical handle having been written down twice, in two places, ready for the pair to be pulled together. The pulling together has a name: it is a joinThe operation of matching a row in one record against a row in another by finding the same value in a shared field.. Notice how little the key carries. The key does not say where a person lives, what they hold, how old they are or how large the account is. Ask a key what somebody's balance is and it has nothing to offer. Ask it which record, and it answers at once. Which record is the only question a key answers, and answering it is the whole job.
The familiar version is the token at a busy sweet shop. One counter takes the money and prints a slip with a number. A second counter has never seen the customer, and it hands over a box against the same number. The token carries no information about the sweets at all, and it does not need to. Its whole purpose is that the same number sits on the slip in the customer's hand and on the packing list at the second counter. Were the two counters somehow to write down different numbers, the box would still exist, the payment would still exist, and there would be no way on earth to put them together.
A record system looks at the key on an account. What does that key tell it about the person the account belongs to?
Why would a mutual fund record want a key in the first place?
Because it has three separate jobs it cannot do without one. Each of the three fails on its own terms, so the three are worth listing apart rather than rolling into a single reason. The first is recognition across managers. A holder with an account in the Girnar Large Cap Equity Fund and another account somewhere else entirely is one person, and the only way any record system arrives at that is by finding the same key written on both. The second is attachment. The check on whether a person is who they say they are is not kept inside the account; it lives with an agency, in a record of its own, and the account reaches it by the key. The third is reporting. Some obligations are stated about a person rather than about an account, and a system that keeps only accounts has to gather them into people before it can answer at all.
All three of those are joins. One key therefore serves every one of them, and a record carrying no key can hold its units perfectly correctly and still connect to absolutely nothing. That last clause is the part worth sitting with. An account with no key is not broken. The units are there, the value moves with the scheme, the bank instruction on it works. The account lacks any thread out of itself. A keyless account is a house with everything inside it in good order and no number on the gate.
Why reuse an identifier that was issued somewhere else?
Step back from mutual funds for a paragraph. Records in general get built this way. Suppose a record system were designed from scratch, minting its own identifier instead of borrowing one. Consider what that commits the designer to. A registry is needed to hold every identifier issued. A way of issuing them is needed that never issues the same one twice. A way is needed of proving that the person at the counter is the one a given identifier was issued to. And a way is needed of handling the person who ends up holding two of them by accident. Two identifiers on one person is not a rare case; it is the ordinary consequence of any registry that has been running a while. Taking one off the shelf instead, already issued and already unique to a person, avoids every last item on that list.
The saving is real and so is the price attached to it: the record system now leans on something it does not control, so a difficulty in the issuing authority's world walks straight into this one. If the identifier changes shape, the record system must follow. If a person's identifier is reissued or corrected upstream, every account carrying the old one is suddenly carrying a key that matches nothing. Nobody on the mutual fund side did anything wrong and nobody on that side can fix it at the source either. Control given up for effort saved is the trade a borrowed key always makes, and the trade is worth naming rather than discovering.
The household version is a rented flat and an electricity connection. The tenant did not create the connection number, the meter was there before the tenant arrived, and every service that asks for a copy of the bill is quietly keying itself to something the distribution company controls. The arrangement works beautifully and costs nothing, right up until the day the distribution company renumbers the connection.
A record system borrows an identifier issued by somebody else rather than minting one of its own. What does it give up by doing that?
What breaks when the two keys disagree?
Be exact here rather than alarming. The exact answer is more useful and a great deal less frightening than the vague one. The join fails. A failed join is the entire event. Not one unit moves, not one rupee of what those units represent moves, and every instruction already sitting on the account carries on running as before. The account goes on being an account. Every single operation that needed the two records brought together first is what stops, and that covers most of the things a holder ever actually wants to do.
The holding is now simultaneously whole and out of reach. The two descriptions are about two different objects, so there is no contradiction in holding both at once. Intact is a statement about the account. Unreachable is a statement about a lookup. People collapse the two because the only evidence a holder gets is a screen or a counter saying nothing was found, and nothing was found sounds exactly like nothing is there. Nothing was found and nothing is there are not the same sentence. One describes a search; the other describes a holding.
Here is the everyday shape of it again. A parcel is sitting in a courier warehouse with a name on it. The tracking number handed over with it has one wrong digit. The parcel has not been lost, stolen, delayed or returned; it is on a shelf, exactly where it was put. Every time the number is typed in, the answer is that there is no such consignment, and each time that answer comes back, the parcel does not move an inch. Nothing about the parcel changed when the lookup failed, and nothing about the lookup will change until the number does.
A join has failed on an account in the Girnar Large Cap Equity Fund. What has happened to the units standing in it?
An account carries one key, the agency holding the verification record carries another, and the two differ by exactly one character. What comes back from the join?
Why does one wrong character return nothing at all?
Because a join matches on exact equalityA match that holds only where two values are identical character for character, with no notion of being close., and exact equality has no notion of nearly. A key differing by one character is not an almost correct key. A key one character out is a different key. The distinction sounds like a technicality, and it explains the thing holders find hardest to accept about the outcome they are handed.
A join awards no partial credit: nowhere in the operation is there a step that observes how nearly two keys agreed, so what comes back is a plain report of nothing found, and from the outside that report looks the same in both cases. What that means is worth pausing on. An entirely wrong key returns nothing found. A key wrong by one character returns nothing found. Same words on the screen, same shrug at the counter, and no way whatsoever to tell the two apart from the answer alone. The system is not being unhelpful or withholding a clue. The system genuinely has no clue to withhold. Comparing for equality is all it did, and equality either held or it did not.
The everyday version is a letter. An envelope addressed to the correct street with one wrong digit in the house number is not delivered slightly late, to the wrong side of the road, or with an apology. The envelope is not delivered. And the postman does not report that it was close. Closeness never entered the operation; the address either matched a house or it did not.
Why is the holder always the first to find a mismatch?
Because from where each party stands, there is nothing to notice. Girnar Asset Management looks at the account and sees a record that is complete in itself: a key is present, units are present, instructions are present, everything reconciles. The agency looks at the verification recordThe separate record, kept by an agency rather than by a scheme, holding the outcome of a check made on a person. and sees a record that is also complete in itself. Neither of them is running a comparison against the other. Neither has any reason to, and in the ordinary course nobody asks them to.
So a mismatch is nobody's alert. The mismatch does not sit inside either record, it sits in the space between them, and a space between two records is not a thing either record can report. That has a consequence worth stating plainly, because it is the difference between a mechanism and a judgement. A holder who runs into one of these has not been overlooked, has not been deprioritised and has not fallen through a crack that somebody was supposed to be watching. The holder has arrived at a gap between two parties who each, quite correctly, believe everything on their side is in order.
The everyday version sits in most households. The gas connection is in one person's name and the flat is registered in another's, and both records are correct, both are complete, and neither office has ever compared them. Nothing goes wrong for years. The mismatch goes wrong the first time somebody needs a document that requires the two to line up, and at that moment it looks like a sudden problem when it was a quiet one all along.
Why is it always the holder who runs into a key mismatch first, rather than anybody upstream of them?
What is a key not, and what is it mistaken for?
Define both things before setting them against each other. The whole confusion comes from letting one word do two jobs. A key, as built up here, is a handle written into a field so that two records can be brought together. A check is something else entirely: it is the outcome of somebody establishing that a person is who they say they are, and that outcome is written down as a record of its own, kept by an agency, sitting outside the account. Two different objects, made by two different parties, doing two different jobs.
Now set them against each other. Nothing about the key proves an identity, nothing about it constitutes a verification, and it grants permission for precisely nothing. Which record: that is its answer, and there it stops. The check does not answer which record at all; it answers whether the person behind the record is who the record says. A key can be flawless while a check is still outstanding, and a check can be entirely complete while the key that would reach it is wrong. In everyday speech the two words get swapped constantly, and refusing to swap them is exactly the habit that tells a holder which side of the pair has come apart.
The practical version is worth holding on to. Somebody reports that their number was rejected. The complaint covers two completely different situations with completely different routes out of them. Either a lookup found no matching row, and that is a key problem, or a row was found and something on it was outstanding, and that is a check problem. The phrase alone does not distinguish them, and the first useful question is not what to submit, it is which of these two happened.
Somebody reports that their number was rejected. Which two quite different things could that single sentence be describing?
The Girnar Large Cap Equity Fund reports 3,80,000 folios. How many people hold the scheme?
Does a folio count show how many people hold the scheme?
No, and the reason follows directly from everything above rather than being a new idea. A scheme counts folios because folios are the things it keeps. A scheme has a register of accounts, it can count the rows in that register any time it likes, and that count is exact. A register of people is the thing it does not have. The scheme reaches people only by joining accounts on a key, and until it has run that join it genuinely does not know how many people its 3,80,000 accounts represent. The folio countThe number of accounts on a scheme's register. Accounts are what a scheme keeps, so it can count them directly. is a fact about the register. The holder countThe number of distinct people behind those accounts, reached only by joining accounts on a key. is a fact about people, and getting from the first to the second takes an operation.
Any statement about holders that was in truth worked out on folios is a statement about accounts flying a false flag. For that reason the baseThe thing a ratio or an average is measured against. Without it the number states nothing at all. travels beside every average, on every occasion, without exception. This is not pedantry. The two numbers can differ by a factor of three or more with nothing wrong anywhere, and a sentence that leaves the base unstated is a sentence nobody can check, including the person who wrote it.
The everyday version is a wedding caterer counting plates. Two hundred plates went out, so two hundred people ate, except that some guests took a second plate and some children shared one. The caterer's count is exact and it is a count of plates. Turning it into a count of guests needs information the kitchen does not have.
What does the counting look like, worked end to end?
Work it on the Girnar Large Cap Equity Fund, and carry the arithmetic unrounded until the last step. The scheme's net assets are Rs 4,200 crore. Written out in whole rupees that is Rs 42,00,00,00,000. Dividing that by 3,80,000 folios gives Rs 1,10,526.32, so about Rs 1,10,526/-. The same figure arrives by a route that shares none of that arithmetic: 120.00 crore units is 1,20,00,00,000 units, and across 3,80,000 folios that is 3,157.894736 units to a folio. At Rs 35.00 a unit those come back to Rs 1,10,526.32. Two routes, one answer, so the figure is checked rather than merely plausible. Rounding on the way costs something: taking the unit count to 3,157.89 first and then multiplying gives Rs 1,10,526.15, and the fifteen paise gap is the price of rounding in the middle of a chain rather than at the end of it.
Put to it, now, the one question a key is there to settle: how many people are behind this scheme? Accounts are what its register contains, so Girnar Asset Management has no answer. So assume something, and label the assumption every time it turns up: let a typical holder here have three accounts, the arrangement a household was walked through under account identity. Then 3,80,000 folios divided by three is 1,26,666.67 holders, about 1,26,667, and the fact that it does not come out whole is itself a small reminder that the divisor was assumed rather than observed. Divide Rs 42,00,00,00,000 by 1,26,666.67 and the average for a holder comes to Rs 3,31,578.95, about Rs 3,31,579/-. The holder figure is the folio figure multiplied by exactly three, and it arrives back at the same total it started from.
| Step | The arithmetic | Result |
|---|---|---|
| Value of a unit | Rs 42,00,00,00,000 divided by 1,20,00,00,000 units | Rs 35.00 |
| On a folio base | Rs 42,00,00,00,000 divided by 3,80,000 folios | Rs 1,10,526.32 |
| Check | 1,20,00,00,000 units divided by 3,80,000 folios | 3,157.894736 units |
| Check | 3,157.894736 units at Rs 35.00 a unit | Rs 1,10,526.32 |
| Illustration | 3,80,000 folios divided by three accounts to a holder | 1,26,666.67 holders |
| On a holder base | Rs 42,00,00,00,000 divided by 1,26,666.67 holders | Rs 3,31,578.95 |
| Check | Rs 1,10,526.32 multiplied by three | Rs 3,31,578.95 |
| Reconciliation | 1,26,666.67 holders at Rs 3,31,578.95 each | Rs 42,00,00,00,000 |
Read the two together and neither is wrong: the same scheme is 3,80,000 accounts averaging about Rs 1,10,526/- and about 1,26,667 holders averaging about Rs 3,31,579/-, and the only thing deciding which of them a given sentence intends is a base that hardly anybody bothers to write down. The missing thing is worth saying out loud. A scheme's register holds a folio count and no count of holders at all. Three accounts to a holder is an assumption built to expose the arithmetic, and no scheme reports a ratio of that kind.
The two halves of the subject meet here. Converting either count into the other takes a join, and a join tests for exact equality. A household with three accounts carrying three keys that differ slightly is reported by the only available method as three holders, not one. No amount of care taken over the arithmetic afterwards repairs a count that was taken on keys which never matched.
About Rs 1,10,526/- for each folio and about Rs 3,31,579/- for each holder. Which of the two is the bigger scheme?
Who reaches for this on an ordinary working day, and how?
Three people use this idea and none of them is doing it out of curiosity. Sohail Merchant, who heads operations at Girnar Asset Management, uses it to sort a queue. Every complaint that arrives saying nothing was found has to be split into two piles before anybody can act on it. One pile is a lookup that matched no row; the other is a row that was found with something outstanding on it. The two piles go to different places and take different amounts of time. Sorting them is the first useful minute of work, and it is done by asking what each party holds rather than by asking the holder what went wrong.
An analyst writing about a scheme uses it as a discipline on their own sentences. Given 3,80,000 folios and net assets of Rs 4,200 crore, the only average they can honestly write is about Rs 1,10,526/- for each folio, and the moment they write the word holder instead of folio they have made a claim the numbers do not support. The habit that protects them is small and mechanical: name the base in the same sentence as the average, always. A reader can then check the claim without asking a single question.
A household uses it to work out what to ask. If a lookup on an account has come back with nothing, the productive question is not what to submit; it is what key each side actually holds. Girnar Asset Management holds a key on the account. An agency holds a key on the verification record. Once both are read back, an invisible problem becomes a visible difference, and a visible difference is something that can be taken somewhere. Where it then goes, and what is asked for along the way, belongs to SEBI at sebi.gov.in and to the tax authority at incometaxindia.gov.in.
The failure that actually happens, and what it costs
Somewhere back in time an account got opened without any key against it, or with one that sits a single character away from what the agency holds. Today every operation wanting both records together comes back empty. The holder hears nothing found and understands it as nothing there. Neither reading is right. Units are sitting in that account, its instructions have never stopped working, and its value has tracked the scheme the whole way through. A join is what failed, and only a join.
Nothing in that sentence is anybody's carelessness. A key wrong by one character is almost always a transcriptionThe act of copying a value from one document or screen into another, and the source of most single character differences. made at a counter, or in a form somebody else filled in and the holder never saw. And the two parties either side of the join each hold a record that is complete on its own terms, so neither has any reason to raise it. Record systems behave this way, and no person has failed.
The cost is counted in years, not in rupees, and that is exactly why it slips past everybody. An account believed not to exist does not get searched for. Somebody told twice that nothing was found does not usually ask a third time. The holding carries on being a holding, and nobody is looking at it. A holding nobody looks at is a quiet loss, and it is nobody's fault.
The shape of the way out can be described without inventing its steps. One record is held by an asset manager and the other by an agency, so whichever of them carries the wrong field is where the repair belongs, and finding out which one that is amounts to asking each party to read back the key it has. Beyond that point, SEBI at sebi.gov.in and the tax authority at incometaxindia.gov.in decide what a person is asked for and how the change is put through, and the two do not decide the same way. One sentence is worth taking away from all of it. Nothing found describes a search. Nothing found never describes a holding.
Where are the requirements about the key actually set?
Two authorities, and everything of this kind belongs to them. The identifier itself belongs to the tax authority at incometaxindia.gov.in: what it is, what shape it takes, who has to hold one, how one is obtained, and whether anything is ever set aside for anybody. Where the identifier has to appear inside a mutual fund record, what applies to a record that does not carry one, and the route by which a difference between two records is corrected belong to SEBI at sebi.gov.in. Arrangements that run across asset managers are described at an industry level by the Association of Mutual Funds in India (AMFI) at amfiindia.com. AMFI reports rather than rules. Every asset manager, Girnar Asset Management included, publishes its own route as well.
The linking of the identifier to any other identifier, and anything that follows from not doing so, is policy of the same moving kind, set and revised by the authorities named above.
Conditions of that kind get revised, and a copy of one does not quietly become dated on the day it changes, it becomes wrong. Each is best read at its own source on the day the answer matters.
Where do the rules on who has to hold the identifier, and on what applies where a record does not carry one, come from?
References
| Source | Document | Where |
|---|---|---|
| Income Tax Department, Government of India | The authority that issues the permanent account number and sets everything about it: what it is, what shape it takes, who has to hold one, how one is applied for, and whether anything is ever set aside. Those particulars belong to the issuer and they change | incometaxindia.gov.in |
| Securities and Exchange Board of India | The rules that decide where the identifier has to sit inside a mutual fund record, what applies to a record that does not carry one, and the route by which a difference between two records is put right | sebi.gov.in |
| Association of Mutual Funds in India | The place where arrangements that run across asset managers are described at an industry level. AMFI reports rather than makes any rule | amfiindia.com |
Girnar Asset Management Limited, the Girnar Large Cap Equity Fund, the Girnar Broad Market Index Fund, Kalyani Bhagat, Sohail Merchant and the placeholder key strings are invented.
Educational material. Not advice on any investment, tax, budget or market position.