Buying an insurance policy in India has never been easier. A few minutes on an app, a couple of document uploads, an OTP, and a digital policy document lands in your inbox. The process is smooth, fast, and increasingly frictionless. Insurers have invested heavily in making it so - and the conversion numbers show it.

Then a customer needs to actually use their policy.

They file a claim after a hospitalisation. They request a nominee change after a marriage. They try to update their address after relocating. They attempt to port their health cover to a new insurer. Suddenly, the experience that felt modern and seamless at issuance reveals its underlying architecture: a verification system that was built entirely for the onboarding moment, with almost nothing designed for what comes after.

This is the insurance industry's quiet CX problem. Not the part customers see in the ads. The part they experience at the moments that matter most - and that determine whether they renew, whether they recommend, and whether they ever trust the category again.

The Issuance Illusion

Policy issuance is where the insurance industry has concentrated its digital transformation energy - and for good reason. It's measurable, competitive, and directly tied to growth metrics. Acquisition cost, conversion rate, time-to-policy: these are the numbers that get tracked in leadership reviews and optimised in product sprints.

The result is that the front-end customer experience of buying insurance is genuinely excellent at many insurers today. Proposal forms that auto-populate from Aadhaar. Video-based medical underwriting. Instant policy issuance for standard products. Real-time premium calculation. The application flow at a modern digital insurer is, by any reasonable standard, a well-engineered experience.

But the verification architecture underneath that experience was built to serve one moment: the moment of sale. Identity is confirmed. Health declarations are collected. Nominee details are captured. A KYC check is run. And then - in the overwhelming majority of cases - that data is filed, the policy is issued, and the verification infrastructure goes dormant.

What the insurer now has is a policy record built on a snapshot. A snapshot of who the customer was, where they lived, what their health status was, and who their nominees were on the day they signed up. The assumption, implicit in most insurance operating models, is that this snapshot remains accurate for the duration of the policy - which, in the case of life and health insurance, might be decades.

That assumption doesn't hold. And the places where it breaks down are exactly the places where customer experience is most consequential.

Claims: Where Verification Debt Gets Called In

No moment in the insurance relationship is more high-stakes than a claim. It's the moment the product promise is tested. It's the moment customer trust is earned or destroyed. And it's the moment where verification debt - the accumulation of stale, unverified, or inconsistent data across a policy's lifecycle - tends to surface most painfully.

Consider a health insurance claim filed after a hospitalisation. The insurer needs to verify the claimant's identity, confirm the policy is active and the treatment is covered, validate the hospital's documentation, and process the payout. In a best-case scenario, the data on file is current and consistent, the claim documents match the policy record, and the process moves quickly.

In practice, the scenarios that create delays - and that generate the complaints, the grievances, and the social media posts that damage brand perception - are almost always downstream of a data inconsistency that nobody caught earlier.

The name on the claim documents doesn't exactly match the policy record because the customer updated their name after marriage and the insurer's servicing team processed it incompletely. The bank account for the reimbursement payout is the old one, because the customer changed banks eight months ago and notified the insurer but the update wasn't verified and reconciled correctly. The address on the claim form is different from the policy address, which triggers a manual review flag, which adds five working days to settlement.

None of these are fraud cases. They're data hygiene failures - the cumulative result of treating verification as something that happened once, at issuance, rather than as an ongoing data quality function that keeps the policy record current.

The customer experience at the claim moment is not being degraded by an insurer's unwillingness to pay. It's being degraded by an insurer's inability to process - because the data substrate their claims operation runs on is inconsistent, stale, and was never designed to be maintained.

Servicing: The Invisible Experience That Shapes Retention

Claims are the most visible version of the problem, but they're not the only one. Policy servicing - the ongoing relationship between an insurer and a policyholder outside of claim events - is where verification friction shows up more quietly and more persistently.

Nominee updates. Address changes. Premium payment method modifications. Policy loan requests against life policies. Portability applications. Beneficiary additions. These are routine servicing requests that policyholders make across the lifecycle of a long-tenure policy - and they're all, in one way or another, identity and verification events.

How most insurers currently handle these requests reveals the gap between their issuance experience and their servicing experience. At issuance: API-first, automated, minimal documentation. At servicing: form-based, document-heavy, manual processing queues, inconsistent turnaround times, and a customer experience that often feels like it belongs to a different decade than the onboarding flow.

The reason is structural. The digital investment went into acquisition. The servicing infrastructure - the systems that process change requests, verify updated information, and maintain the policy record - was often not rebuilt as part of the digitisation push. It was layered over or left in place.

The practical result is that a customer who onboarded through a slick mobile app finds themselves, when they want to change their nominee, being asked to submit a physical form, a self-attested ID copy, and wait ten to fifteen working days. The cognitive dissonance between these two experiences is not subtle. And it communicates something to the customer that the acquisition experience spent considerable money trying to avoid communicating: that the insurer's interest in them peaked at the moment the premium was collected.

This is a retention problem wearing the costume of an operational problem. Policyholders who find servicing difficult don't complain loudly. They lapse at renewal. They don't port their other family members' policies to the same insurer. They don't recommend. The lifetime value impact of a poor servicing experience is real and sustained - it's just harder to measure than acquisition conversion, so it gets less attention.

The Specific Failure of Nominee Verification

Of all the servicing moments in a policy lifecycle, nominee management is the one with the highest stakes - and the most consistently poor verification practice.

Nominees, in most policy types, are captured at issuance with minimal verification. A name, a relationship declaration, a date of birth. In many cases, the nominee's identity is not independently verified at all - the policyholder's declaration is accepted at face value.

This creates a specific problem at claim time. When a policyholder dies and the nominee files for the death benefit, the insurer must now verify the nominee's identity against a record that may be years or decades old, may contain errors from the original entry, and may reference personal details that have since changed. Nominee name spelling variations, changed surnames post-marriage, outdated contact details - these are all routine complications that turn what should be a compassionate, efficient claim settlement into an extended, document-intensive ordeal for a grieving family.

The insurer hasn't done anything malicious. They've done exactly what their systems were designed to do: verify at issuance, trust that record forever after, and adjudicate at claim based on what's on file. The problem is that what's on file was never robust enough to serve the claim moment - and nobody built the process to maintain it.

The nominee verification problem is a microcosm of the broader issue: a verification architecture designed for the front of the customer journey, deployed in a product that has consequences at the back.

Why Insurers Haven't Fixed This Yet

The gap between issuance experience and servicing experience is widely acknowledged inside insurance operations. It's not a secret. So why hasn't it been closed?

Several reasons compound.

Investment follows acquisition metrics. The ROI of improving onboarding conversion is immediate and measurable. The ROI of improving servicing experience shows up in retention and NPS over longer timeframes - and is harder to attribute cleanly. In budget cycles that prioritise short-term growth, servicing infrastructure loses.

Servicing is operationally complex. Unlike onboarding, which is a standardised flow, servicing requests are varied, exception-heavy, and involve updating records in core policy administration systems that are often legacy infrastructure with limited API surface. Building modern verification capabilities on top of those systems is genuinely hard, and the integration cost has deterred many insurers from attempting it.

The pain is distributed. No single team owns the full servicing experience. Claims operations, policy administration, customer service, compliance - all of these teams touch servicing moments, and none of them own the end-to-end experience. The verification gap falls between the org chart boxes.

Regulatory pressure has focused on issuance. IRDAI's digital push has largely focused on KYC at onboarding, paperless policy issuance, and digital premium collection. The regulatory framework for ongoing verification and re-KYC in insurance is less developed than in banking and lending - which means there's less external pressure forcing insurers to build it.

None of these are good reasons to leave the problem unaddressed. They are, however, accurate explanations for why most insurers have.

What a Better Model Looks Like

The fix isn't complicated in principle. It requires extending the verification logic that insurers already apply at issuance across the full policy lifecycle - not as a one-time gate, but as a continuous data quality function.

Concretely, this means:

Nominee verification at issuance should be real, not declaratory. If a policyholder names a nominee, that nominee's identity should be confirmed against a verifiable source - not just recorded as stated. This is an investment that pays out at claim time, when the policy has its highest operational complexity.

Servicing requests should trigger lightweight re-verification. A nominee change, an address update, a bank account modification - each of these is a verification event, and each should be handled with the same data discipline as onboarding, adapted for the lower friction that an established customer relationship warrants.

Portability applications should include a verification refresh. When a customer ports their health policy to a new insurer, that's an ideal trigger for a fresh address, identity, and contact verification. The new insurer is effectively re-underwriting a relationship; they should be working from current data.

Claims initiation should include identity confirmation of the claimant. Particularly for large claims or death benefits, verifying that the person filing the claim is who they say they are - and that their relationship to the policy matches what's on record - is a fraud prevention step and a data quality step simultaneously.

Where Tartan's HyperVerify Fits

Tartan built HyperVerify to serve exactly this need - verification that works across a lifecycle, not just at the front of one.

For insurers, HyperVerify provides API-accessible verification capabilities that can be embedded at any point in the policy journey: issuance, servicing, and claims. It draws on authoritative data sources to verify identity, address currency, mobile number validity, and bank account ownership - and returns structured, auditable outputs that integrate into policy administration systems and claims workflows without requiring a core system rebuild.

At policy issuance, HyperVerify strengthens the KYC foundation - including nominee identity verification that goes beyond declaration capture.

At servicing events, it enables lightweight but real-time re-verification of updated details - so an address change is confirmed against a live source, not just recorded as stated by the customer.

At claims initiation, it provides claimant identity confirmation and bank account verification - reducing the document-chasing that slows settlement and the inconsistencies that trigger manual review queues.

The result is a verification architecture that serves the full insurance relationship - not just the moment of sale. For a product category where the customer relationship can span decades, that's not a marginal improvement. It's the difference between a policy record that holds up at the moments that matter and one that quietly accumulates the gaps that make those moments difficult.

Insurance CX doesn't suffer at issuance. It suffers at servicing and claims, in the quiet places where verification was never designed to reach. HyperVerify by Tartan is built to reach them.

The policy is easy to sell. It's harder to service well. Insurers who close the verification gap between those two moments will build the customer relationships that survive renewal - and earn the ones that follow.