Getting Ready for the Public Insurance Registry: What Brokers Should Fix in Their Data Now

On 17 March 2026 IRDAI held an industry stakeholders' discussion in New Delhi on the proposed Public Insurance Registry (PIR), described as a consent-driven, legally compliant digital infrastructure spanning the policy lifecycle from issuance through claims, grievance redressal and dispute resolution. The stated intent is to consolidate structured insurance data across stakeholders, reduce information asymmetry, improve fraud detection and support data-driven supervision, explicitly aligned with Bima Sugam.

That sentence reads like a regulatory vision document. For a broker it is actually an operations problem, and a near-term one. A registry that holds structured policy and claims records does not invent data. It pulls data that already sits in insurer and intermediary systems, normalises it, and exposes it under consent to regulators and, eventually, to clients. The quality of what gets pulled is the quality of what you have today.

The uncomfortable part is visibility. Right now your data hygiene is a private matter. A mis-keyed sum insured, a renewal recorded against the wrong client entity, an endorsement that never reached the policy admin system, a claim closed in the insurer portal but open in your CRM: these are invisible to outsiders. Once records flow into a common registry, gaps and mismatches become comparable across intermediaries. The firm whose policy count reconciles to the insurer's, whose claims status matches the carrier's, and whose grievance log lines up with Bima Bharosa entries will simply look more credible.

No deadline has been notified, and the design is still under discussion. That is the argument for starting now rather than the argument for waiting. Data clean-up is slow, manual and political inside a brokerage. Begin while it is voluntary and you set the pace. Begin under a mandate and you do it badly, under pressure, with the regulator watching.

Strip away the policy language and a lifecycle registry needs a small number of data domains to be accurate and joinable. Work backwards from those domains and your clean-up list writes itself.

• Party and identity data. Who is the insured, the proposer, the beneficiary, the intermediary? In commercial lines this is messy: group entities, subsidiaries, special-purpose vehicles, co-insured parties. A registry that consolidates across the market needs each legal entity identified consistently, ideally tied to PAN, GSTIN or CIN, not to a free-text name typed three different ways across three policies.
• Policy and coverage data. Policy number, insurer, line of business, sum insured, period, premium, and material terms. The risk here is silent divergence between what the insurer issued and what you recorded at placement.
• Endorsement and mid-term change data. Every increase in sum insured, addition of a location, change of beneficiary or cancellation. Endorsements are where broker records and insurer records drift apart fastest because they are processed in a hurry.
• Claims data. Intimation date, status, paid and outstanding amounts, closure. If a registry shows claims status to a regulator, your number must match the carrier's number.
• Grievance and redressal data. Complaints, turnaround, resolution, and any Ombudsman or Bima Bharosa reference.

Notice the common thread. The registry's value comes from joining these domains across the lifecycle, so a registry is only as good as its keys. If your systems cannot reliably link a claim to the right policy to the right legal entity, your data will not assemble cleanly no matter how much each individual record is corrected.

Before fixing field-level errors, fix the keys. Decide your authoritative entity identifier and your authoritative policy identifier, and make sure every claim, endorsement and grievance record carries both. Joinability is worth more than cosmetic accuracy.

Most brokers, asked about data quality, will run an internal survey: ask each team whether their records are clean, collate reassuring answers, and conclude things are broadly fine. That tells you nothing. The only test that matters is reconciliation against an external source of truth, and for insurance data the external truth is the insurer.

Do this concretely. Pick your three or four largest carriers by premium. Request a bordereau or portfolio extract: every live policy they show against your broker code, with sum insured, premium and period. Then match it, line by line, against your own policy register. You are looking for four failure types.

1. Policies they show that you do not. Usually renewals booked by the insurer but never updated in your system, or business migrated between teams.
2. Policies you show that they do not. Lapsed or cancelled cover still marked live in your CRM, which inflates your apparent book and your renewal pipeline.
3. Same policy, different values. Sum insured, premium or period that disagree. These are the dangerous ones, because they often reflect an endorsement processed on one side only.
4. Same policy, different client entity. The carrier has it against one legal name, you have it against another. This breaks joinability and is common across group structures.

Run the same exercise on claims. Pull the insurer's claims register for your portfolio and match status, paid and outstanding amounts against your records. Status mismatches, a claim closed by the carrier but open with you, are exactly what a registry would expose.

Quantify the gap before you start fixing. A reconciliation that finds, say, eight percent of policies with a value mismatch gives you a defensible baseline, a number to take to management for resourcing, and a measure of progress. A vague sense that data is messy gets no budget.

The word that keeps appearing in the PIR description is consent. The registry is consent-driven by design, and it sits downstream of the DPDP Act framework. For brokers this is the genuinely new work, because most have cleaned data before but few have mapped consent properly.

Start from a simple question for every category of personal data you hold: on what lawful basis do we hold it, and can we evidence the consent or the legitimate processing ground? In a consent-based registry, the relevant question becomes sharper: for which records can the client validly authorise the registry to access their data, and is that authorisation captured in a form a consent manager can act on?

Commercial-lines brokers often assume DPDP is a retail problem because their clients are companies, not individuals. That is a mistake. A commercial file is full of personal data: directors and officers in a D&O placement, key-management individuals in keyman cover, employees in group health and workers' compensation, named drivers in fleet motor, claimants and witnesses in liability claims. All of that is personal data of natural persons, and the company buying the policy is frequently not the data principal for those individuals.

Practical consent-mapping steps:

• Inventory the personal data inside your commercial files by category, not just by client. Group health and employee benefit lines are where the volume sits.
• Identify who the actual data principal is for each category. For employee data, the individual employee is the principal, even though the employer is your client.
• Check whether your placement and renewal documentation captures any consent for onward processing and registry-style sharing, or whether you have simply never asked.
• Map which records would need fresh consent collection before they could flow to a consent-driven registry, and treat that as a renewal-cycle project, not a one-time blast.

The firms that look ready when the PIR goes live will be the ones who can say, per data category, what their consent position is. Most cannot say that today.

Reconciliation tells you where records disagree. The deeper fix is structural, and it is about identifiers. A registry consolidates across the market by joining records, so your internal joins have to hold first.

Entity identity

Decide your single authoritative way to identify a client entity and apply it everywhere. For Indian commercial clients the natural candidates are CIN for companies, GSTIN for tax registration, and PAN as a fallback. Free-text client names will not survive a market-level consolidation: 'Reliance', 'Reliance Industries', 'Reliance Industries Ltd' and 'RIL' are four entities to a matching engine and one to a human. Tag every client record with a structured identifier and reconcile your duplicates now, while you can do it deliberately.

Group structures need explicit handling. Decide whether you record cover against the contracting entity or the named insured, document the rule, and apply it consistently. A registry will struggle with cover that floats ambiguously between a parent and a subsidiary, and so does your own MIS.

Policy identity

The insurer's policy number is the natural key, but brokers often carry their own internal reference too. Keep both, and make the insurer's number the one that joins to the outside world, because that is what the carrier will submit to any registry. Where you have placed cover across multiple insurers (layered programmes, co-insurance, facultative arrangements), make sure each participating policy is captured, not just the lead.

The joins

Every claim, endorsement and grievance record must carry the policy key and, through it, the entity key. This is the single most valuable fix. A claim that cannot be reliably traced to its policy and its legal entity is, from a registry's perspective, orphaned data. Audit your claims and endorsement records specifically for missing or broken policy references, and close those gaps before you worry about field-level polish.

Get the keys right and accuracy improvements compound. Get them wrong and every other clean-up effort sits on sand.

Two data domains deserve singling out because they drift fastest and because the registry covers both explicitly.

Endorsements. Mid-term changes are processed under time pressure, often by email and phone, and the discipline of updating every system lags the discipline of getting the cover bound. The result is predictable: the insurer issues an endorsement increasing a sum insured or adding a location, the client is covered, but the broker's policy admin record still shows the original terms. Now your sum insured is wrong, your premium is wrong, and at renewal you may quote off stale figures. In a registry, your record and the carrier's record disagree on material terms, which is exactly the kind of mismatch supervision is meant to surface.

The fix is process as much as clean-up. Make endorsement capture a closed loop: no endorsement is considered complete until the policy admin record reflects it and reconciles to the insurer's confirmation. For the backlog, your insurer reconciliation will already have flagged value mismatches; many will turn out to be unprocessed endorsements.

Grievances. The PIR covers grievance redressal and dispute resolution, and this connects directly to the Bima Bharosa system and Ombudsman pathways. Brokers frequently keep grievance handling in email threads and individual notes rather than a structured log. That will not assemble into registry-grade data.

• Maintain a single grievance register with complaint date, category, channel, turnaround, resolution and any external reference.
• Reconcile it against Bima Bharosa entries where complaints escalated, so your internal record and the regulatory record agree.
• Capture turnaround against the applicable norms, because a registry that exposes redressal data exposes your service quality, not just your existence.

Grievance data is reputational, not just operational. A registry that shows complaint volumes and resolution timelines across intermediaries makes service quality comparable. Clean the data, but also use the exercise to find where your redressal process is genuinely slow.

None of this needs to wait for a notified deadline, and trying to do it all at once guarantees you do it badly. Sequence it.

1. Assign ownership. Name one person accountable for registry data readiness, reporting to a senior principal. Without single ownership this becomes everybody's job and therefore nobody's. Treat it like the data-governance function it is.
2. Run the insurer reconciliation. Top three or four carriers, policies and claims, line-by-line match. This produces your baseline error rate and your prioritised fix list. Budget several weeks; the data requests alone take time.
3. Fix the keys. Standardise entity identifiers (CIN, GSTIN, PAN), de-duplicate clients, and confirm the insurer policy number is your external join. Audit claims and endorsement records for broken policy links and repair them.
4. Close the endorsement loop. Clear the backlog of unprocessed endorsements surfaced by reconciliation, and change the process so future endorsements cannot close without a reconciled record.
5. Map consent. Inventory personal data by category, identify the true data principals (especially in employee benefit lines), and plan consent collection into the renewal cycle for records that would need it.
6. Structure the grievance register. Move grievance handling out of email into a single log that reconciles to Bima Bharosa.
7. Re-reconcile and measure. Repeat the insurer match quarterly and watch the error rate fall. A falling number is your evidence of readiness.

The brokers who treat the PIR as a future compliance chore will scramble when a deadline lands. The ones who treat it as a reason to fix data they should have fixed anyway will be ready early, will carry lower errors-and-omissions risk, and will look the part exactly when regulators and clients start looking.