Every Policy Will Name Its Seller From January 2027: The Data Model Brokers Have to Build First

IRDAI approved the IRDAI (Insurance Intermediaries) (Amendment) Regulations, 2026 at its 137th Authority meeting on 28 July 2026. The amendments cut across five sets of regulations at once: corporate agents, insurance brokers, insurance marketing firms, web aggregators and common public service centres. Two structural moves sit inside them.

The first is that registration shifts from periodic renewal to indefinite validity, subject to annual fees and continued compliance. Business Standard reported the new fee structure on 31 July 2026: a non-refundable application fee of Rs 10,000, and annual fees of the higher of Rs 10,000 or 0.04% of commissions and other insurer-related receipts. We covered what perpetual validity means for the renewal calendar in the perpetual registration piece.

The second move is the one this post is about, and it is the one most compliance memos are underselling. From 1 January 2027, intermediaries must keep records identifying the individual involved in the sale or solicitation of every policy, and the name and functional identity of that individual must appear in the proposal form, the policy document and the certificate of insurance. Financial Express put it plainly on 1 August 2026: IRDAI wants every insurance policy tagged to its seller.

A memo can tell your teams the rule exists. It cannot make a name entered in your CRM survive the journey into an insurer's policy schedule and back into a certificate your own operations desk prints. That journey is a data-model problem, and the firms that treat it as one have about four months of build time left.

Business Standard's 31 July report is specific about who can be the named individual: a broker-qualified person, a POSP, a designated person or an authorised verifier, recorded by name and functional identity. Read that as a two-part value. The name identifies the human. The functional identity states the capacity in which that human was allowed to solicit at all.

A name alone does not work at network scale. A broker running 400 POSPs will have duplicate names, and an auditor looking at "Rakesh Kumar" on a policy schedule three years from now needs to know which Rakesh Kumar, under which certificate, valid on which date. The tag your systems store should therefore be a structured record, not a free-text field:

• Person identifier: an internal unique ID that never gets reused, even after the person exits.
• Full name: exactly as it appears in the regulatory registry or certificate, because this is the string that prints on documents.
• Functional identity: one of the four permitted roles, stored as an enumerated value so nobody types "sales executive" into a regulatory field.
• Certificate or registration number for that role, with its validity dates.
• Entity linkage: which broker, sub-broker or marketing firm the person acts under, since people move.
• Tag timestamp and recorded-by: when the tag was set and by whom, so the record itself is auditable.

Store the free-text name only as a derived display value. Everything downstream should key on the identifier. Firms that skip this and capture a typed name in the proposal form will discover the cost the first time an insurer's schedule says "R. Kumar" and their CRM says "Rakesh Kumar Singh" and someone has to attest they are the same person.

The regulation names three documents: the proposal form, the policy document and the certificate of insurance. A broker directly controls two of them. The proposal form originates in your placement process, and certificates are frequently broker-issued, marine open cover declarations and group cover certificates being the everyday cases. The policy document is issued by the insurer, out of the insurer's core system, from whatever data the insurer's issuance team received.

That is the trap. For the same name and functional identity to appear on all three documents, the tag has to survive this chain intact:

1. CRM or lead system, where the solicitation actually happens and the tag should first be captured.
2. Placement or quote system, where the opportunity becomes a slip and a proposal.
3. The proposal form itself, now carrying the tag as a required field.
4. The insurer's issuance system, which must accept the tag as structured data and print it on the schedule.
5. Certificate generation, whether the insurer's or your own, which must pull the same value rather than a re-keyed one.

Every manual re-keying step in that chain is a mismatch generator. The tag sent in a covering email will be transcribed; the tag sent in a structured field in the placement data will be copied. So the insurer-facing part of this build is a data-exchange conversation, and it needs to start now, insurer by insurer, because their proposal formats and core-system fields are changing on the same deadline yours are.

The rule is easy to apply to a POSP selling a shopkeeper package. One person solicited, one person gets tagged. Commercial placements are where firms need a written internal rule before January, because the honest answer to "who solicited this policy" is often "a team".

Take a mid-market property programme: a relationship manager owns the client, a placement lead negotiated terms across three insurers on the slip, a wordings specialist rewrote two clauses, and a servicing executive handled the proposal paperwork. The regulation asks for the individual involved in the sale or solicitation, identified by name and functional identity. It does not ask for your org chart.

Our view is that firms should adopt a single-name rule and document it: the broker-qualified person who led the solicitation of that policy is the tag, decided at proposal stage, recorded before submission, never reconstructed at audit time from memory. On a layered placement, note that each insurer on the programme issues its own policy document, so the same tag has to reach every issuance system on the slip, including the followers who took their line on the lead's terms.

Two situations need explicit treatment in your internal policy:

• Servicing-team renewals. A renewal placed by the servicing desk with no fresh solicitation still needs a name. Decide in advance whether the tag carries over from the prior year or transfers to the servicing qualified person, and apply the rule uniformly.
• Mid-term movement. When the tagged person exits between proposal and issuance, or between issuance and an endorsement, the record must show who held the policy at each point. Endorsement-level handling is worth specifying now rather than improvising in February.

Whatever rule you pick, the audit question in 2028 will be whether you applied it consistently. A defensible rule applied uniformly beats a clever rule applied sometimes.

For brokers running big POSP and sub-broker networks, tagging is less a capture problem than a reconciliation problem. Capture is a mandatory field in the onboarding journey. Reconciliation is proving, month after month, that the tags on issued policies match reality.

The failure modes are predictable:

• A POSP is deactivated mid-month and a policy solicited earlier gets issued after the deactivation date, so the document names a person who was not certified on the issuance date.
• The insurer's schedule prints a name variant that does not match your registry string, so a bulk comparison flags hundreds of false mismatches.
• A branch under monthly pressure tags policies to whichever POSP code is at the top of the dropdown, and one person ends up tagged on 300 policies they never touched.
• A sub-broker's people are tagged under the sub-broker entity in your records but reach the insurer under your broker code, so functional identity and entity linkage disagree.

The control is a monthly three-way match: policies issued per insurer statements, tags recorded in your CRM, and the live status of each tagged person in your registry on the relevant dates. Exceptions go to a queue with an owner and a closure deadline. This is the same discipline as commission reconciliation, and it should run on the same calendar, because the two datasets overlap almost completely: the person who earned the payout on a policy should normally be the person tagged on it. Where those two records disagree, one of them is wrong, and the mismatch is exactly what a conduct inspection will pull first.

The two halves of the amendment interact in a way that is easy to miss. Under periodic renewal, every renewal cycle forced a clean-up: lapsed certifications surfaced, exited people got removed, records got refreshed because the renewal application demanded it. Indefinite validity on an annual fee removes that forced checkpoint. Nobody outside your firm will make you look at your roster again.

Tagging arrives at exactly the moment roster hygiene becomes voluntary. From January 2027, a stale roster stops being an internal untidiness and starts printing on regulatory documents. Every policy tagged to a person whose certification lapsed, or who left the firm two quarters ago, is a discrepancy sitting in the client's own policy pack.

Movement between firms is also getting faster. ET Now reported on 31 July 2026 that the amendments set a 30-day deadline for no-objection certificates, which means people will transfer between intermediaries on a shorter clock and your registry will churn more, not less.

There is a second, quieter link. The annual fee is computed as the higher of Rs 10,000 or 0.04% of commissions and other insurer-related receipts. The receipts number that drives your fee and the per-person production data that sits behind your tags come from the same records. A firm whose tagging data is clean can decompose its receipts by individual and channel on demand. A firm whose tagging data is a formality will be explaining gaps in both directions at once.

The timeline has been visible for a while. TeamLease RegTech records the draft as issued on 19 June 2026 with comments due by 10 July 2026, and the Authority approved the final amendments on 28 July. Anyone starting in September has roughly one quarter. Sequenced backwards from the deadline:

1. People registry first. A single source of truth for every individual permitted to solicit: identifier, name string, functional identity, certificate numbers, validity dates, entity linkage, status history. Everything else reads from this. If your POSP data lives in the LMS, your qualified persons in HR, and your verifiers in a spreadsheet, consolidating them is the long pole, so start here.
2. CRM capture. Make the tag a mandatory, validated field at opportunity level, selectable only from active registry records. Reject free text.
3. Document templates. Proposal forms, slips and your own certificate formats updated to render the tag from the structured field.
4. Insurer data exchange. Agree with each major insurer where the tag travels in the proposal data and how it prints on the schedule. This is the step you control least, which is why it cannot start last.
5. Reconciliation and exceptions. The monthly three-way match, an exception queue, and a correction procedure for documents already issued with a wrong or missing tag.
6. Parallel run. Tag everything from October or November 2026 without the documents depending on it, measure the mismatch rate, and fix the process while the errors are still free.

None of these steps is exotic. All of them take longer than a quarter if the registry consolidation is left for December. The firms that treat this as a memo will technically comply on 1 January and then spend 2027 correcting documents. The firms that treat it as a build will end up with something they did not have before: a per-person view of production, conduct and receipts that is worth having even if no regulator ever asks for it.