Who Consents When the Policyholder Is a Company? The Public Insurance Registry Meets Group Cover

IRDAI released its Consultation Paper on the proposed Public Insurance Registry on 1 September 2026. Comments are due by 30 September 2026, submitted through iib.gov.in/pir or by email. That is a four-week window on a piece of market infrastructure that will eventually sit underneath every policy record in the country, and most of the commentary since publication has read it as a retail story: portable claims history, less duplicate KYC, a policyholder who finally owns the record of what they bought.

That reading is fair for an individual motor or health policy. It stops working on a group medical cover for four thousand employees, where the policyholder is a company, the insured lives are employees and their dependants, the claim history sits on one master policy number, and the party with the strongest interest in reading it is a rival insurer preparing a quote. The consent question there is not whether the customer agrees. It is who the customer is.

The paper's consent standard is four words. Consent-based access is proposed to be specific, informed, revocable and auditable, with an insurer able to access a customer's claims history from another insurer with that customer's consent. Each adjective has an obvious meaning when the data subject is a person deciding whether an insurer may pull their own record. Each becomes a question of corporate authority when the data subject is a legal entity, the data describes several thousand other people, and the incumbent insurer treats the record as its own priced experience.

IRDAI links the proposal to the Sabka Bima Sabki Raksha (Amendment of Insurance Laws) Act, 2025, which places the registry inside a statutory reset rather than a standalone technology project. The comment window is the cheapest point at which a corporate buyer can get group and commercial lines written into the design. After 30 September 2026 the argument moves to implementation, where the answer is usually that the framework is already settled.

The paper describes the PIR as population-scale, interoperable and non-exclusionary digital public infrastructure built on a federated architecture. Federated is the load-bearing word. The registry is not proposed as one central vault holding a copy of every policy in India. It is proposed as a layer that knows where authoritative records live and moves them under rules, with a source-system primacy approach that keeps the originating system, usually the insurer's core platform, as the authoritative version of the record.

Against that architecture the paper sets out three handling tiers:

1. Reference: the registry knows a record exists and where it sits, without the data itself moving into a shared store.
2. Governed copy: an actual copy of the record moves to a permitted party under defined governance.
3. Anonymised aggregate: identifiers are stripped and the output is statistical rather than record-level.

The tiering is the most important design decision in the paper for anyone buying commercial cover, because the three tiers carry very different exposure. A reference pointer tells a requesting insurer that a record exists. An anonymised aggregate tells the market something about a population. A governed copy puts your actual claims experience in the hands of a party you did not select, and once it has been read it cannot be unread.

What the paper does not resolve in the detail a corporate risk manager needs is how these tiers apply when a single record describes many people at once. A group medical master policy is one record contractually and thousands of records for data-protection purposes. Source-system primacy tells you which system is authoritative. It does not tell you who may authorise release.

Work through an actual group medical account and the consent question resolves into three candidate signatories, none of whom is obviously correct.

The company as policyholder. It signs the contract, pays the premium, negotiates the policy wording and owns the commercial relationship. It is the customer on any reading of insurance law, and the only party that can practically execute a consent instruction at renewal. What it does not have is any personal stake in the underlying data, most of which describes the medical history of people it employs.

The individual insured. Employees and their dependants generate the claims, and under a data-protection reading they are the people whose personal data is being moved. Specific and informed is a demanding standard, and it is not obviously met by an HR head signing a renewal instruction for four thousand people who never saw the request, cannot see the audit trail, and in many cases have already left.

The broker under mandate. The broker operates the account, gathers the claims MIS today and would be the party making the request tomorrow. A mandate letter authorising a broker to act on a client's behalf is not a data consent, and treating it as one is the likeliest operational shortcut in the first year of any registry.

Pure commercial lines are cleaner but not clean. On a fire, liability or property programme there is usually no natural person insured, so the company alone can consent and the only question is who inside it holds that authority. On directors and officers liability and workers compensation, named individuals and claimants reappear and the group problem returns in smaller form.

The answer a corporate buyer should push for is layered rather than single: the policyholder entity consents to release of policy-level and aggregate claims data, and member-level records either stay behind the reference tier or need a separate basis. That distinction is easy to write in at consultation stage and very hard to retrofit.

The stated benefit of consented cross-insurer access is that an insurer can see a customer's claims history from another insurer, cutting fraud, improving pricing accuracy and shortening onboarding. On individual lines that is straightforwardly good. On a corporate account it changes a negotiation that currently runs on controlled disclosure.

Today, when a corporate buyer goes to market on a group medical renewal, the incumbent insurer holds the full claims file while challengers get whatever MIS the broker extracts and circulates. A consented registry pull narrows that asymmetry, which is a genuine gain for buyers shopping a well-performing account.

The exposure runs the other way for everyone else. An insurer that can pull a governed copy of the master policy's claims history sees the loss ratio, the concentration of high-cost claimants, the mix of maternity, oncology and chronic-care utilisation, and the mid-term endorsement history, before it quotes and before it has any obligation to the buyer. A poorly performing account loses the ability to stage disclosure. A healthy one finds its workforce health profile has become a market-readable document. Neither outcome is priced into the renewal.

A second-order problem matters more than it sounds. Registry data will read as authoritative because source-system primacy makes the insurer's own system the source. A miscoded claim, a reserve never released, an endorsement recorded as free text rather than a structured change to the sum insured: all of it becomes visible and hard to contest at speed. Buyers who have never reconciled their claims MIS against the insurer's ledger should assume divergence and find it before a rival insurer does.

Revocable consent is a simple promise for one person and a hard engineering problem for four thousand. Three questions need answers the consultation paper leaves open.

Does revocation reach copies already released? Once a governed copy has been transferred and used to price a quote, withdrawing consent cannot unprice it. The workable answer is prospective revocation, blocking further access, combined with a defined retention and deletion obligation on whoever holds the copy. That should be stated rather than assumed: the difference between prospective and retrospective revocation is the difference between a manageable process and an unenforceable one.

Whose revocation counts? If an individual employee withdraws consent, does the master policy record become partly unavailable, and does the company's own consent survive? A design that lets any one of four thousand members disable a policy-level pull is unusable. A design that lets the employer override individual withdrawal is difficult to reconcile with the specific and informed standard. The layered approach again offers a route: entity consent governs policy-level and aggregate data, individual consent governs member-level records, and revocation operates within its own layer.

What happens to leavers? An employee who left two years ago has claims sitting on a master policy the company still renews. The company cannot obtain fresh consent from them and cannot exclude their history from the policy's loss record. A group consent framework has to say whether historical member data is released with the policy record or suppressed.

Auditable consent is worth more to corporate buyers than it first appears, provided the audit is visible to them. A trail only the regulator and participating insurers can read does nothing for a risk manager establishing who pulled workforce data during a competitive renewal. The log for a corporate account should record the authorising role inside the policyholder, the purpose asserted, the tier served and the requesting entity, and the policyholder should be able to read its own log without filing a request.

Brokers will operate most registry requests on commercial and group accounts, placing them between a consent they do not own and a pull they do execute. Three consequences follow.

First, mandate documents need rewriting. A broking mandate authorises placement and servicing. It does not, on its own terms, authorise transfer of member-level medical claims data to third parties. Firms treating the existing mandate as a sufficient basis for registry access rely on an instrument never drafted for the purpose. This is the same drafting discipline that the DPDP Act data fiduciary analysis already demands of broker vendor contracts and client agreements.

Second, evidence of authority becomes an operational artefact. Every pull needs a retrievable answer to who authorised it, in what role, for which purpose and under what expiry. If a client later disputes that a pull was authorised, the broker holds the exposure, because the broker made the request.

Third, the data the broker contributes has to be good enough to defend. Registry access runs both ways, and a broker's own entity keys, policy identifiers and endorsement history become visible in a way they are not today. The reconciliation work set out in the broker data readiness analysis is the prerequisite, and it is cheaper before a registry makes the gaps legible than after.

The broader architecture question, how the registry sits alongside Bima Sugam and what it means for commercial placement generally, is covered in the PIR overview for commercial brokers.

For corporate buyers the instruction is short. Ask your broker, in writing, under what authority it would make a registry request on your account, what it would do with the data, and how you would see the log. If the answer is the existing mandate, it is not ready.

Comments close on 30 September 2026 and can be filed at iib.gov.in/pir or by email. A corporate submission need not be long. It needs to raise the group and commercial case that the paper's individual-policyholder framing does not fully address. Six asks are worth making.

1. Define the consenting party for group and commercial policies explicitly, distinguishing the policyholder entity from the insured individuals whose data sits on the master policy.
2. Adopt a layered consent model: entity consent for policy-level and aggregate claims data, a separate basis for member-level records.
3. Restrict the governed-copy tier for group claims data where the requesting party is not the incumbent insurer, defaulting to aggregate or suppressed member-level output.
4. State that revocation is prospective, with a defined deletion and retention obligation on any party holding a governed copy.
5. Make the consent and access log readable by the policyholder, showing the authorising role, purpose, tier and requesting entity for every pull on its account.
6. Confirm whether group and commercial lines are in scope for the first phase at all, so that buyers can plan rather than guess.

Route your comment through your broker or an industry body if that is easier, and file it in your own name as well. On consultations of this kind, the record of which constituency raised an issue shapes how it is treated later.

Internally, the same four weeks are enough to do three things: write down who in your organisation would hold registry consent authority, reconcile your group medical claims MIS against the insurer's ledger so you know what a rival insurer would see, and check whether your broking mandate would be read as a data consent. None of that is wasted if the registry arrives late or in reduced form. It is the governance a corporate buyer should already have over its own loss data.

Sarvada helps brokers and corporate risk teams hold structured, wording-grounded records of what is covered and what has been claimed, which is the condition for meeting a registry knowing your own data rather than discovering it. Request Access to see how that supports registry readiness on group and commercial programmes.