The POSP Client Book: Structuring Policyholder Records So Nothing Falls Through

A client book is not a list of names. It is the set of records that lets you answer, on any morning, four questions without asking anybody: which policies expire in the next 90 days, what cover each of them actually carries, what the client paid last time, and what you were paid for placing it.

If answering those needs a diary for the expiry dates, a spreadsheet for the premiums, a WhatsApp thread for the policy PDF the client sent you, and a memory for the commission, you do not have a client book. You have four partial copies of one, and they disagree. The disagreement is quiet. It does not announce itself the day it starts. It announces itself eleven months later, when a two-wheeler policy you placed lapses because the diary said August and the policy schedule said 14 July.

Most advisors discover the limit somewhere between 120 and 200 policies. Below that, memory carries the book, because you personally remember that the Deshpande family has a car, a health floater and a term plan, and that the car falls due before the monsoon. Above it, memory stops carrying and nothing replaces it. The failure is not that you forget a client. It is that you forget the third policy of a client you speak to every month.

This is a structure problem before it is a software problem. A well-structured book works in a spreadsheet. A badly structured one fails in expensive software, because the software will faithfully store the same ambiguity you gave it.

Almost every broken advisor book makes the same modelling mistake: it treats the client as the unit of record. One row per person, with the policies written into columns or, worse, into a notes field. It feels natural, because you think in people. It breaks immediately, because the things with dates on them are not people. They are policies.

Use two layers instead.

The policy layer. One row per policy, per period. A car policy renewed in 2025 and again in 2026 is two rows, not one row overwritten. Overwriting destroys the only history that tells you whether this client renews on time, renews late, or renews only when chased. That history is the whole of persistency, and persistency is the difference between a book that compounds and a book you rebuild every year.

The client layer. One record per household, not per individual. The person paying for the health floater, the person named on the RC of the second car, and the person whose term plan you placed are frequently three different names and one decision maker. If they sit as three unrelated clients, you will call the same house three times, quote a family discount you cannot honour, and miss that the household has a June cluster and a January cluster.

The join between the layers is one field on the policy row: a client ID pointing at the household. Not the client's name. Names are not identifiers. R. Sharma, Rajesh Sharma and Sharma ji are one household and three rows the day you sort the sheet.

A policy row needs seven groups of fields. Fewer than seven and something you will need is living in your head.

1. Identity. Policy number, insurer, product name, and the client ID from the household layer. The policy number is the only field the insurer and you both agree on, so it is the field every later reconciliation hangs off.
2. Cover. Sum insured or sum assured, and the one or two attributes that actually decide the renewal conversation: IDV and the add-ons on a motor policy, room-rent basis and waiting-period status on health, policy term and premium paying term on a life case. Not the full wording. Just the facts you will be asked to repeat.
3. Dates. Risk start date, risk end date, and the proposal or issuance date. The end date is the one the whole book turns on, and it must be copied from the policy schedule, never from memory and never from the client.
4. Money in. Gross premium, and the tax component separately if you want a sane year-end.
5. Money out. What you were paid, when, and against which payout statement. Covered in its own section below.
6. The POS Code the proposal carried. Covered in its own section below.
7. State. In force, lapsed, cancelled, renewed-elsewhere, or replaced. A book that only records live policies cannot tell you what you are losing or to whom.

Two fields that look useful and are not: a free-text remarks column, which becomes the place where load-bearing facts go to hide, and a status field that means both the renewal stage and the policy state at once. Split them. The renewal stage belongs on the renewal workflow. The policy state belongs on the policy.

One field on the policy row is not an administrative nicety. It is the field the regulatory record is built on.

When you passed your engaging entity's examination and received your certificate and appointment letter, that entity allocated you a unique POS Code. The IRDAI guidelines governing the channel require that every proposal carries the POS Code, and place the responsibility for recording it on the insurer. This is the mechanism by which a POS policy is attributable to a named, trained, certified person rather than to a faceless lead.

What that means for your book is direct: the POS Code on the proposal is the reason the policy is yours. It is what your payout is computed against, and it is the trail anybody would follow if a proposal you submitted were ever questioned. So record it on the policy row, as it was submitted, for that policy. Do not carry it as a global fact about yourself in a header cell.

That sounds pedantic until the day your code changes. A POSP is tied to one insurer or intermediary at a time, and if you move principals, your new principal allocates a new code. Your book then contains policies proposed under the old code and policies proposed under the new one, both live, both renewing. If the code was a header cell rather than a field, that history is gone, and reconciling an old payout statement against a new code becomes a conversation with two entities who each hold half the truth.

The client record carries the things that are true across policies and would otherwise be copied, and drift, on every row.

• The household key: client ID, the decision maker's name, and one reachable mobile number. One, not four. If there are four, mark which one answers.
• Members: names, relationship, dates of birth. Dates of birth are not sentimental here. They drive health renewal loadings and term eligibility, and they tell you a floater that worked at 42 prices very differently at 46.
• Vernacular and channel preference: which language the conversation actually happens in, and whether this household reads or listens. An advisor who sends a Marathi-speaking client an English renewal notice has technically communicated.
• KYC state: what you collected, from whom, and when you passed it to your principal. You are required to collect and maintain KYC documentation and product sales records, and the practical form that takes is a field per document with a date, not a folder of photographs named IMG_20240817.jpg. You collect on behalf of the insurer or intermediary that engages you, so their retention and purpose rules govern what you keep. Ask your principal for those rules rather than inventing a period of your own.
• The relationship facts: how they came to you, who referred them, what they have declined and why.

One field earns its place more than the rest: household ticket size, the total annual premium across every live policy in the house. It is the number that tells you where an hour of your time is worth spending, and no sprawled book can produce it, because producing it requires that every policy is joined to the right household. If you cannot compute it, that is the diagnostic, not a missing report.

One field to leave out: your own opinion of the client. It will be read back to you.

The money side of an advisor's book is usually its least structured part, and the part where the arithmetic is least forgiving.

A POSP is remunerated by the entity that engages them, under the contract of engagement. You are not an independent commission earner facing the insurer. As a matter of general market structure, where a POSP is engaged by an intermediary, the insurer settles with the intermediary and the intermediary pays the POSP under contract. That decides what your book reconciles against: not the insurer's commission schedule, but your principal's payout statement, which arrives on its own cycle and with its own groupings.

So the policy row needs three money-out fields, not one:

• Expected: what the engagement terms say this policy earns, from the premium and the rate for that product at that date.
• Received: what actually landed, and on which statement.
• Variance: the difference, and why.

The third is the one advisors skip and the one that pays for the exercise. Two patterns recur. First, rate drift: the payout rate on a product changes and reaches you as a line on a statement rather than as a notice, so months of policies quietly pay differently than you assumed. Under the IRDAI (Payment of Commission) Regulations, 2023, product-wise caps came off and each insurer's board-approved policy sets rates, inside the expenses-of-management envelope of the IRDAI (Expenses of Management, including Commission, of Insurers) Regulations, 2024. Rates move, and a book storing only what arrived cannot tell that they moved.

Second, orphaned renewals: a policy renews, the client is happy, and no payout line appears, because the renewal was processed without your code on it. The payout statement cannot show you this, since it shows what you were paid. You find it only by taking your list of policies due and asking which came back. That is a completeness test, and it needs the policy row to exist before the money does.

The test of a client book is not how it looks. It is whether it answers questions without you. Run these four. Each should take under a minute.

One: what expires in the next 90 days, sorted by date? If this needs a manual scan, your end dates are not a real field, or they are not all in the same place. This is the query the whole structure exists to serve, and the one a forward renewal calendar is built on.

Two: which households have exactly one policy with me? Every name on that list is a household where somebody else holds the rest of the cover, and the single policy you do hold is the least defensible policy in your book. Single-policy households lapse at rates that multi-policy households do not, because there is no second reason for the client to keep you in their phone.

Three: which policies renewed last cycle with no payout line against them? The orphaned renewals. Every one is either a coding error at proposal or a policy that came back without you. Both are worth knowing within weeks rather than at year end.

Four: what is my top decile of households by ticket size, and when do they next fall due? If you cannot produce this, you are allocating your attention by who called most recently, which is precisely the allocation a structured book exists to overturn.

If all four run clean, the sprawl is gone, and the notebook is a notebook again rather than a system of record. If any of them stalls, the field that stalls it is the field to fix first. Do not fix the tool. Fix the field.