IntelliBooks — AI in Insurance

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...

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...

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,...

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...

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...

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. ...

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...

Delegated authority is a genuinely useful model. An MGA or coverholder writes business on your paper, in a niche where they have distribution and expertise you don't. You get access to a market without building it. What you also get, and rarely plan for, is a portfolio where the underwriting decisions, the policy data, and often the claims handling all happen inside someone else's systems — and what reaches you is whatever they choose to send, in whatever shape they send it. You carry the risk. They hold the detail. Why the oversight gap opens The contract usually specifies underwriting limits and reporting obligations, and both get monitored. But the data itself — the granular record of what was written, at what price, against what risk characteristics — arrives as a periodic bordereau built for compliance rather than analysis. It's summarised, formatted to the coverholder's convenience, and late. So the insurer supervising the portfolio can confirm the limits were...

Every insurer of any age carries business it no longer writes. A line it exited, a portfolio it acquired and wound down, a product withdrawn a decade ago. The policies are closed to new business but the liabilities are alive — claims still arrive, reserves still move, regulators still ask questions. And the data behind that run-off book sits in a system nobody actively develops, maintained by people who have mostly moved on, governed by no one in particular. It's the quietest data risk on the balance sheet. Why run-off data decays Attention follows new business. The systems and data supporting the active book get investment, migration, and governance; the run-off portfolio gets left where it is, because migrating it has cost and no upside anyone can point to. Over time the people who understood its quirks leave, the documentation ages, and the platform drifts further from anything current. The liabilities don't shrink as fast as the institutional knowledge does, and eventua...

Ask an actuary how the loss triangle behind the reserve estimate gets built and you'll often get a slightly embarrassed answer. Data comes out of the claims system, sometimes out of several claims systems, into a spreadsheet. It gets grouped, adjusted, reconciled against finance, and corrected for the known quirks that never got fixed at source. Then a reserving method is applied to it and a number goes into the accounts that materially affects the company's reported profit. The method is rigorous and well-documented. The data preparation feeding it frequently isn't. Why the preparation is the weak link Reserving methodology gets enormous scrutiny — peer review, actuarial standards, regulatory oversight. The pipeline that produces the triangle usually gets far less. It's treated as plumbing rather than as part of the estimate, even though a mis-grouped claim, an inconsistent transaction date, or a currency conversion applied at the wrong point moves the answer just ...