Posts

Global Programs: One Client, Twelve Countries, No Single View

A multinational client buys one program. Underneath it sits a master policy plus a set of local policies issued in each country where the client operates, each in local currency, under local regulation, often on a different system or through a different network partner. The client experiences it as one relationship. The insurer, internally, frequently cannot see it as one thing at all — and that gap shows up exactly when it matters: at renewal, during a large loss, or when the client asks a simple question about their own program. Why the single view doesn't exist Global programs are assembled from parts that were never designed to be assembled. Local policies live in local systems, with local product codes, local currencies, and local claims processes. Network partners issue some of them entirely outside your estate. Rolling that into a coherent view of one client's total exposure, premium and loss experience means resolving the client across countries, normalising product...
Post a Comment
Read more

Your Repair Network Costs Vary Wildly and Your Data Won't Say Why

A large share of an insurer's claims spend never goes to the customer as cash. It goes to a supply chain: repairers, contractors, medical providers, hire companies, loss adjusters, restoration firms. The same type of claim, handled by two different suppliers, can differ substantially in cost, cycle time, and how satisfied the customer is at the end. Most insurers know this in the abstract. Far fewer can say which suppliers are genuinely better once you account for the fact that they don't all get the same work. Why supplier performance is hard to see Comparing suppliers naively is misleading, because the work isn't randomly distributed. One repairer gets the complex jobs, another gets the straightforward ones; a contractor in a high-cost region will look expensive regardless of how well it performs. A fair comparison needs claim characteristics, supplier assignment, cost, cycle time and outcome joined together — and that data usually lives across claims, procurement and...
Post a Comment
Read more

Identifying Vulnerable Customers Is a Data Problem With Regulatory Teeth

Regulators increasingly expect insurers to recognise customers in vulnerable circumstances — bereavement, serious illness, financial difficulty, cognitive decline, a recent major life event — and to treat them appropriately. That's a reasonable expectation and most insurers agree with it in principle. In practice it runs into an awkward reality: the signals that someone is vulnerable are scattered across call recordings, claim notes, correspondence and payment behaviour, and almost none of it is captured in a form the business can act on consistently. Why good intentions don't reach the customer Vulnerability is usually noticed by an individual — an adviser hears distress on a call, a claims handler reads a bereavement in a note. That recognition lives in that moment, with that person. It rarely becomes a durable, governed attribute of the customer that other parts of the business can see and respond to. So the customer explains their situation again to the next department,...
Post a Comment
Read more

How Long Should You Keep Insurance Data? Nobody Knows, So You Keep Everything

Ask an insurer what its data retention policy is and you'll usually be handed a document. Ask what actually happens to a policy record fifteen years after the policy lapsed and the answer is almost always the same: it's still there. Insurance has genuine reasons to keep data for a long time — long-tail liabilities, latent claims, regulatory and legal obligations that run for years. But "we might need it" has quietly become "we delete nothing," and that default carries costs and risks nobody signed off on. Why keeping everything feels safe and isn't Deleting data feels risky: if a claim surfaces in twenty years, you want the file. So the cautious choice is always to retain, and since nobody is accountable for the cost of retention, the cautious choice always wins. But data you keep is data you must secure, must include in a breach if one happens, must search when a customer exercises a privacy right, and must migrate every time you change platforms. I...
Post a Comment
Read more

Your Test Environments Are Running on Real Customer Data

Ask where the data in your development and test environments came from and the answer is very often a copy of production, taken some time ago, by someone who needed realistic data to test against. It's an entirely understandable shortcut — synthetic data is hard, and defects hide in the messiness of real records. It also means real policyholders' names, addresses, claim details and payment information are sitting in environments with weaker access control, looser monitoring, and a much longer list of people who can reach them. Why it keeps happening Testing insurance systems genuinely needs realistic data. Rating engines, matching logic, document generation and migration scripts all behave differently on the long tail of odd real-world records, and clean synthetic data hides exactly the defects you most want to find. So teams copy production because it works, and the copy quietly becomes permanent — refreshed occasionally, never inventoried, and rarely covered by the same c...
Post a Comment
Read more

Reference Data: The Boring Tables That Break Everything Downstream

Nobody gets promoted for fixing reference data. It's the unglamorous layer underneath everything else: class codes, peril codes, currency rates, territory mappings, product and coverage codes, the little lookup tables that give raw values their meaning. It's also, quietly, one of the most common root causes when two reports disagree, a migration produces nonsense, or a model behaves oddly on a subset of the book. The tables are boring. The failures they cause are not. Why reference data goes wrong Reference data tends to be copied rather than shared. Each system gets its own version of the class-code list, its own territory mapping, its own currency table — and they drift. A code is retired in one place and kept in another. A mapping is extended locally to handle an edge case. A rate table is updated on a different schedule. Nothing breaks loudly; the systems just gradually stop agreeing about what the same code means, and every downstream join inherits the disagreement. ...
Post a Comment
Read more

Premium Collection: The Money You Billed and Never Actually Collected

An insurer writes the policy, bills the premium, and books the revenue. Somewhere between that and the bank account, a proportion quietly fails to arrive. A direct debit bounces, a card expires, an instalment is missed, a broker's account doesn't reconcile. Individually these are small operational events handled by a collections process. In aggregate they're a persistent leak, and at a lot of insurers nobody can say precisely how big it is — because the data needed to answer that question is spread across billing, banking, and policy administration and never gets joined. Why collection failure hides Billing systems know what was invoiced. Bank feeds know what was received. Policy systems know whether cover lapsed. The interesting question — which customers are failing to pay, why, and what happened to their policy as a result — sits across all three, and the join is often incomplete. So collection is managed as a queue of individual failures to chase rather than as a me...
Post a Comment
Read more