Not PAN, Not Aadhaar: The Identifier IRDAI Chose for Salesperson Tagging, and Why That Matters Under DPDP

The Insurance Intermediaries (Amendment) Regulations, 2026 were approved at IRDAI's 137th Authority Meeting on 28 July 2026. The operative requirement is that every proposal form, insurance policy and insurance certificate must carry the name and functional identification of the authorised salesperson who solicited or sold the policy, alongside the mobile number and email address of the sourcing branch or office. The obligation takes effect on 1 January 2027.

The part that deserves more attention than it has received sits in IRDAI's response to public comments, reported by TaxGuru on 30 July 2026. Commenters on the draft raised the identifier question, and the Authority accepted a unique identification number in place of PAN or Aadhaar for salesperson tagging, applying across online and offline channels.

That is a drafting decision with consequences measured in millions of documents. A policy schedule is not a document that stays inside the insurer. It goes to the client, it goes into the broker's file, it goes to a bank or NBFC when the asset is financed, it goes to a principal employer on a contract award, it gets attached to tender submissions and to loan drawdown packs. Had PAN been the salesperson identifier, every one of those circulation paths would have carried a permanent government financial identifier belonging to an employee who has no relationship with any of the recipients.

PAN and Aadhaar are both designed as identity anchors. That is precisely what makes them unsuitable for a field whose entire function is attribution of a sale.

The tagging requirement needs to answer one question: which authorised person solicited this policy, in which capacity, from which office. It does not need to establish that person's tax identity or their biometric identity. An identifier that carries more than the question requires is an identifier that leaks.

Three specific failure modes were avoided:

1. Permanence beyond the relationship. PAN follows a person for life. A salesperson who worked at your firm for eleven months in 2027 would still be findable, by PAN, on policy documents sitting in third-party filing systems in 2040.
2. Cross-context linkage. A single identifier printed across insurance documents, tax records and financial accounts allows anyone holding two of those datasets to join them. The salesperson never consented to that join, and cannot revoke it.
3. Irrevocability on compromise. If an internal identifier is exposed in a leak, you retire it and issue a new one. Neither PAN nor Aadhaar can be reissued because a broker's document store was breached.

A unique identification number issued by the intermediary has the opposite properties on all three counts. It is scoped to the distribution relationship, it links to nothing outside the insurance context, and it can be retired.

The same reasoning is why a certificate of insurance has historically carried an agent code rather than an agent's personal identity documents. IRDAI's 2026 decision extends that convention to a channel population that now includes POSPs and specified persons, not only tied agents.

India Briefing reported on 11 May 2026 that the full substantive obligations under the DPDP framework, covering notice, consent, security safeguards and breach reporting, become enforceable from 13 May 2027. Salesperson tagging goes live on 1 January 2027. The two dates are four months apart, and they are not independent of each other.

Data minimisation is the principle that a data fiduciary collects and processes only what the stated purpose requires. Printing a salesperson's PAN on a policy schedule would be difficult to defend against that principle, because the purpose (attributing a sale to an authorised person) is fully served by a number that means nothing outside your own registry. The regulator effectively pre-resolved a minimisation argument that would otherwise have been litigated firm by firm from May 2027.

The four-month gap is the operationally awkward part. From 1 January 2027 you will be generating and printing salesperson identifiers at volume. From 13 May 2027 the processing of that data sits squarely inside enforceable notice, security and breach-reporting duties. Anything you build in that first quarter without minimisation discipline becomes a legacy data estate you have to remediate under a live enforcement regime.

Practical consequences for the identifier design:

• The number should not be derived from personal data. A scheme that encodes date of birth, PAN characters or a phone number fragment reintroduces exactly what the regulator removed. If someone can reverse the identifier, it is not a substitute identifier.
• The number should not be a sequential counter that discloses headcount or hire order. BRK-000004 on a policy tells a competitor how large your desk was and when that person joined.
• The lookup from identifier to person is the sensitive asset. It belongs in a governed internal registry with access logging, not in the same table that feeds document generation.

Brokers already working through fiduciary duties will recognise the shape of this; the wider obligation set is covered in DPDP Act 2023 for Insurance Brokers.

IRDAI has specified that an identifier is acceptable in place of PAN or Aadhaar. It has not handed you a format. That means the design sits with the intermediary, and a design that fails will fail visibly, on printed documents, for years.

Four properties are worth fixing before you write a line of code.

Opaque, stable and never reused

The printed value should carry no meaning that can be decoded without your registry. It should attach to the person for as long as they are with the firm, and it should never be issued to a second person after the first leaves. Reuse is the single most damaging shortcut available here, because it silently rewrites history: a 2027 policy and a 2031 policy would name the same identifier and different humans, and no audit could separate them.

Separate from the role, so role changes do not orphan the sale. The identifier answers who. The functional identification answers in what capacity. A person can move from POSP to a specified person role, or hold a broker-qualified capacity on commercial lines while sourcing retail elsewhere. Bind the capacity to the transaction record, not to the identifier itself, or every role change forces a reissue and breaks the continuity of the person's sales history.

Resolvable by an insurer, an auditor and a regulator without a phone call

The value on the document has to be traceable back to a named, authorised individual on demand, including after that individual has left. Build the resolution path as a service with a retention rule, not as tribal knowledge in a spreadsheet that a departing ops manager owns.

Consistent across online and offline channels. IRDAI's acceptance of the identifier applies across both. A digital journey that stamps an internal user ID while the branch prints a different code from a legacy system produces two identifier namespaces for one salesperson, and the reconciliation cost lands on whoever answers the audit.

The amendment retains the No Objection Certificate requirement for a specified person moving employer, as TaxGuru noted on 30 July 2026. That NOC event is the trigger the identifier lifecycle has been waiting for, and it is where most implementations will be weakest.

Consider what a salesperson exit actually does to your data estate on 2 January 2027 and after:

• The person stops being authorised to solicit. Any new policy tagged with their identifier after the exit date is a control failure, not a data-entry error.
• Every policy they already sold keeps their identifier printed on it, permanently, in the client's file and in the insurer's archive. That is by design; attribution has to survive the person.
• Their name, mobile and email may sit in adjacent fields on quotes, endorsements and renewal notices generated before the exit.
• Renewals falling due after the exit need reassignment to a live salesperson, with the original sale's attribution untouched.

The correct model is retirement, not deletion. Deleting the identifier destroys the audit trail the tagging rule exists to create. Leaving it active lets a departed person's identifier keep landing on new business.

A retirement sequence that holds up looks like this:

1. Record the exit date and the NOC issuance against the person record, as facts with dates rather than a status flag.
2. Set the identifier to retired with effect from that date, blocking any new proposal, policy or certificate from being stamped with it.
3. Keep resolution active. The identifier must still resolve to the person, the capacity and the validity dates for every historical policy.
4. Reassign the live book to a named successor, recording the reassignment as a separate event so that the original sale attribution is not overwritten.
5. Apply a retention rule to the personal fields, keeping what attribution requires and expiring what it does not.

Step five is where the DPDP clock and the IRDAI clock interact. Attribution is a legitimate reason to keep the identifier and name indefinitely. It is not an obvious reason to keep the departed salesperson's personal mobile number in an active operational table for a decade.

The requirement names the mobile number and email address of the sourcing branch or office, not of the individual. That is the second minimisation decision in the same sentence, and it is easy to break in implementation.

The failure mode is well known to anyone who has looked at how contact fields get populated in practice. Branch records are created when the branch opens, nobody maintains them, and the fastest way for an ops team to get a working contact onto a document is to paste in whatever number reaches someone. That is usually the branch manager's personal handset or a salesperson's own mobile.

The result is a personal mobile number printed on policy documents that circulate to clients, financiers and principals, on a field the regulation intended to be institutional. It survives the person's exit, because nobody thinks to change a branch record when a manager transfers.

Three controls are cheap and worth putting in before January:

• Validate at the source. Branch contact fields should accept only numbers and mailboxes owned by the firm, checked against a telecom and mailbox inventory rather than free text.
• Make the fields owned. Assign each branch record an accountable owner with a periodic confirmation, so the record has a maintenance cycle instead of a creation date.
• Reconcile against the salesperson registry. A branch contact number that also appears as an individual's personal mobile in the HR record is a defect, and it is a one-line query to find.

Firms that have already tightened control ownership around intermediary conduct will find this sits on the same rails; the control-design pattern is described in Intermediary Fraud Is Now a Named Category.

Once the first policy prints, the format is effectively permanent. You can add fields; you cannot recall documents. A short list of decisions is worth settling deliberately rather than by default.

1. Who issues the number. One authority inside the firm, or the number is not unique. If the broking system, the POSP app and the branch back office can each mint an identifier, you have three namespaces by March.
2. What the format is. Fixed length, checksum digit, no encoded personal data, no meaning that discloses hire order or headcount. A checksum catches transcription errors when a value is read off a printed schedule into a claim intimation.
3. Where the registry lives. A single system of record that both the digital journey and the branch systems call, with access logging on the identifier-to-person lookup.
4. What happens on the exit event. The retirement sequence, wired to the NOC record rather than to an HR ticket that closes silently.
5. What retention applies to each field. Identifier and name are attribution data. Personal contact details are not, and should have an expiry defined before May 2027 rather than after.
6. How reconciliation runs. A monthly check that every identifier stamped on new business in the period belonged to an authorised, non-retired person on the date of sale. Exceptions are the report; a clean run should be one line.

The build itself, across proposal, issuance and certificate generation, is a wider piece of work than the identifier alone. That systems view is covered in Every Policy Will Name Its Seller From January 2027.

The identifier decision is the one with the longest tail. IRDAI removed PAN and Aadhaar from the document. What replaces them is yours to design, and it will be legible on your client's policy schedules long after everyone involved in choosing it has moved on.