The Cross-Insurer Fraud Gap the April 2026 IRDAI Framework Cannot Close With Centralised Data
The IRDAI (Insurance Fraud Monitoring Framework) Guidelines, 2025, issued on 9 October 2025 and in force from 1 April 2026, replaced the January 2013 circular and named four fraud classes: policyholder fraud, intermediary fraud, internal fraud, and third-party fraud. The framework extends accountability across the full distribution chain (corporate brokers, web aggregators, bancassurance partners, motor garages, hospitals, and agents) and requires every insurer to run a Fraud Monitoring Committee and report frauds above INR 1 crore within 30 days. The classes it targets are increasingly organised, and the most damaging rings do not sit inside one insurer's book.
A staged-accident garage, a colluding hospital cluster, or an agent issuing nominal policies rarely limits itself to a single carrier. The same orchestrator files a motor own-damage claim with one insurer, a personal accident claim with a second, and a health claim with a third, precisely because no single insurer sees the full pattern. This is the structural weakness in single-insurer analytics: each carrier scores claims against its own data and each ring stays below the per-insurer threshold that would trigger investigation.
The obvious answer, pooling raw claims data into one central store, now collides with the Digital Personal Data Protection Act, 2023. Claims records are personal data, and moving them between insurers for a new purpose engages purpose limitation, consent, and data-fiduciary obligations that make bulk raw-data sharing legally fraught. The Insurance Information Bureau of India already pools entity-level signals, but that model contributes and consumes flagged identifiers rather than jointly training a model on the underlying records. The result is a real gap: the fraud the 2026 framework most wants caught is the fraud that centralised, in-house analytics is least equipped to see.
What Federated Learning Actually Moves: Model Updates, Not Policyholder Records
Federated learning inverts the usual pipeline. Instead of moving data to a model, it moves the model to the data. Each insurer keeps its claims records on its own infrastructure. A shared model architecture is distributed to every participant, each trains it locally on its own book, and only the resulting parameter updates (gradients or weight deltas) leave the building. A coordinator aggregates those updates into a global model and sends the improved version back for the next round. Raw policyholder data never crosses an organisational boundary.
Two partitioning patterns matter for insurance. Horizontal federated learning suits participants who hold the same kind of records for different customers, for example several general insurers each holding motor claims with the same feature columns. The federation widens the training population without any of them seeing another's rows. Vertical federated learning suits participants who hold different attributes about an overlapping set of entities, which is the more interesting case for cross-insurer and insurer-to-provider fraud work.
Gradients alone are not automatically safe, because a well-crafted query can partially reconstruct training data from them. Production federations therefore layer defences. Secure aggregation lets the coordinator compute the sum of everyone's updates without reading any single participant's contribution. Differential privacy adds calibrated noise so no individual record measurably changes the model, giving a quantifiable privacy budget. Homomorphic encryption and secure multi-party computation let specific steps run on encrypted values. Published cross-carrier studies through 2025 and 2026 report federated fraud models reaching strong detection scores (one vertical federated health-fraud study reported an F1 near 0.90) while outperforming local-only training, because each participant contributes exposure to fraud typologies the others never see.
Vertical Federated Learning for Claims: When Two Firms Hold Different Columns on the Same Entity
Vertical federated learning is the pattern that maps onto the Indian cross-insurer fraud problem. Consider a suspected health ring. One insurer holds the claim, diagnosis codes, and payment history. The empanelled hospital holds admission records, procedure detail, and length-of-stay data. A third-party administrator holds pre-authorisation and cashless-settlement patterns. Each party holds a different set of columns about the same patients and providers. No party wants to hand its raw records to the others, and DPDP obligations mean it largely cannot.
A vertical federation lets them train one fraud model across those columns. The first step is a private set intersection, a cryptographic method that finds the common entities (patients, providers, policy numbers) without either side revealing its full list. Training then proceeds on the aligned records, with each party computing on its own features and exchanging only intermediate representations, not the underlying values. The model learns that a specific combination of short pre-authorisation gap, recurring procedure code, and repeat provider across insurers is a ring signature, a pattern invisible to any one participant.
Entity alignment is where the Indian context bites. Aadhaar is restricted for claim processing where the policy was not Aadhaar-linked at issuance, PAN coverage is partial in motor and retail health, and name and address strings vary across transliteration and data entry. Private set intersection must therefore run over probabilistic keys, which lowers match rates and demands careful calibration to avoid false links.
Mapping Federated Approaches to DPDP Act Obligations
Federated learning is not automatic DPDP compliance, but it changes which obligations bite and how heavily. Under the Digital Personal Data Protection Act, 2023, each insurer is a Data Fiduciary for its own policyholder data. Because raw records never leave the fiduciary in a federation, the high-risk act of transferring bulk personal data to a third party is avoided, and with it much of the cross-border and consent-transfer exposure that a central data lake would create.
Several obligations still apply and must be designed for. Purpose limitation requires that fraud detection sit within the purposes for which the data was collected, which insurers generally address through the claims-processing and fraud-prevention grounds rather than fresh consent. Data minimisation is served structurally, since only model updates move, and differential privacy strengthens the argument that those updates are not personal data in any recoverable form. The reasonable security safeguards duty extends to the federation itself: secure aggregation, encrypted transport, and access control over the coordinator all become part of the fiduciary's security posture.
The residual risk is that model updates can leak information. If a participant can infer whether a specific person was in another insurer's training set (a membership inference attack), the federation may itself constitute a processing activity that engages DPDP. This is why a defensible design pairs federation with a documented differential-privacy budget and a threat assessment, so the insurer can show the Data Protection Board that updates were engineered to be non-identifying.
The Cross-Insurer Consortium Model: Governance, Coordinator, and the IIB's Natural Role
A federation needs a trusted coordinator, and the Indian market already has the obvious candidate. The Insurance Information Bureau of India, which operates under IRDAI and runs the industry's pooled data programmes, is well placed to host the aggregation server, define the shared model architecture, and enforce the privacy budget across participants. A consortium model built around a neutral, regulator-adjacent coordinator avoids the trust problem of one large insurer aggregating on behalf of rivals.
Governance is the substance of the model, not an afterthought. Participants need a consortium agreement covering who may join, what data domains are in scope (motor, health, personal accident), how the model architecture changes, and how disputes over false positives are handled. The agreement should fix the differential-privacy budget centrally so no participant can weaken it unilaterally, and should bar any use of the model beyond fraud detection, which keeps the arrangement inside purpose limitation and avoids drift toward pricing or risk-selection uses that would raise competition and DPDP concerns at once.
The consortium must also defend against adversarial participants. A carrier could attempt data poisoning, feeding corrupted updates to blind the model to its own fraud, or model inversion to extract information about rivals' books. Countermeasures include update validation, anomaly detection on contributions, outlier-resistant aggregation that discounts anomalous updates, and audit logging that IRDAI can inspect.
A realistic 2026 path is a phased consortium: begin with horizontal federation on a single high-fraud line such as motor own-damage, prove the governance and privacy controls, then extend to vertical federation with hospitals and third-party administrators on health. Signals surfaced by the federation feed each insurer's existing Fraud Monitoring Committee rather than triggering automatic adverse action, keeping human investigation in the loop as the framework requires.
Building a Federated Fraud Programme: Threat Model, Costs, and What Brokers Should Ask
A federated fraud programme is a security project as much as a data-science one, and the threat model should be written before the first training round. The realistic adversaries are an honest-but-curious participant probing shared updates, a malicious participant poisoning the model, and an external attacker targeting the coordinator. Each maps to a control: differential privacy and secure aggregation against inference, outlier-resistant aggregation and contribution validation against poisoning, and hardened coordinator infrastructure with audit trails against external compromise. Skipping the threat model is how a privacy-preserving project quietly becomes a privacy-leaking one.
Costs differ from a single-insurer model. Federation adds cryptographic overhead (private set intersection and secure aggregation are computationally heavy), coordination engineering, and the legal and governance work of the consortium agreement. Against that, participants avoid building and securing a shared central data lake, and each gains detection lift on cross-insurer rings that no in-house model could reach. The economics favour lines where organised, multi-insurer fraud is material, which in the Indian market means motor and cashless health ahead of low-frequency commercial property.
Brokers and risk managers sit closer to this than they might assume. Insurer fraud performance flows into loss ratios and therefore into renewal pricing for large corporate and group-health accounts. When evaluating carriers, brokers can ask whether the insurer participates in a federated or consortium fraud programme, how flagged claims are investigated before any adverse action, and how policyholder rights under the DPDP Act are preserved when analytics inform a decision.
Understanding whether a carrier's fraud controls and data-sharing posture match what its wordings actually say is a wordings problem. Sarvada makes insurer policy wordings searchable across the market, so brokers can compare fraud, cooperation, and data-handling clauses side by side and advise clients with the exact language in front of them. Request Access to search insurer wordings in one place.