IntelliBooks — AI in Insurance

When a vehicle is written off, two numbers decide the economics of the claim: what you pay the customer for the total loss, and what you recover selling the salvage. Both are valuation problems, both run on data, and at most insurers both leak money in small, systematic ways nobody quite owns. Overpay the settlement or under-recover the salvage and the loss on that claim quietly grows — not through fraud or bad handling, but through valuation data that's a little stale, a little generic, and a little disconnected from the specific vehicle in front of you. Why valuation is a data problem A fair total-loss settlement depends on knowing what this specific vehicle was actually worth — its condition, mileage, trim, options, and the local market — at the moment of loss. A good salvage recovery depends on routing the wreck to the right channel at the right reserve based on current salvage-market data. Both decisions are only as good as the valuation data behind them, and that data is ...

Price optimization — setting the premium using not just expected cost but the customer's likely price sensitivity — has been standard practice in parts of the market for years. It's also increasingly under regulatory fire, with rules targeting practices like charging loyal customers more simply because they won't shop around. Whatever your view of the practice, the regulatory direction is clear: insurers must be able to explain and defend how a price was set, and prove it isn't unfair. That's not primarily a pricing-model question. It's a data-lineage question, and most insurers can't answer it cleanly. Why "explain this price" is so hard A modern premium is the output of a chain: raw data, transformations, rating factors, models, and post-model adjustments, often across several systems and teams. When a regulator asks "why was this customer charged this, and what inputs drove it," the honest answer requires reconstructing that entire...

A life insurer's obligation is simple to state: when an insured dies, pay the beneficiary. But the industry has a long, uncomfortable history with policies where the insured has died and the benefit was never paid — because nobody filed a claim, and the insurer never went looking. Regulators have made this a serious issue, requiring insurers to proactively match their in-force book against death records and pay what's owed. It sounds like a compliance task. Underneath, it's a data-matching problem, and insurers that struggle with it struggle for data reasons, not moral ones. Why the benefit goes unpaid The traditional model was passive: the insurer waited for a beneficiary to file a claim with a death certificate. If the beneficiary didn't know the policy existed, or couldn't be found, the policy simply stayed on the books as in-force. Flipping to a proactive model means regularly comparing your policyholder data against a death master file and identifying match...

Plenty of insurers outsource claims handling to a third-party administrator, and for good reasons — scale, specialism, speed to a new line. But there's a quiet cost that shows up later: the TPA runs the claims, and the TPA's system holds the claims data. What comes back to the insurer is a periodic bordereau — a summarized feed, formatted the TPA's way, on the TPA's schedule. You carry the risk and the loss, but you don't hold clean, granular, timely data on your own book. That gap becomes a real problem the moment you want to analyze, price, or automate against those claims. Why outsourced claims become a data blind spot When a TPA handles claims, the rich operational data — the notes, the timeline, the granular transactions — lives in their environment. The insurer receives an extract designed for billing and basic reporting, not analysis. It arrives late, in an inconsistent structure, often missing the detail that would let you understand loss trends or feed ...

The first decision on any claim is where it should go: fast-track the simple ones, route the complex ones to experienced adjusters, flag the suspicious ones for investigation, escalate the severe ones before reserves and litigation get out of hand. Get triage right and everything downstream is cheaper and faster. Get it wrong and a large loss sits in a junior queue for a week, or a simple claim consumes a senior adjuster. The catch is that triage happens at the exact moment you know the least — and most insurers triage on the thin data available rather than the data they could assemble. Why triage is hard precisely when it matters most Triage is a prediction made at first notice of loss: given what little we know now, how will this claim behave? The problem is that the signal to make that prediction well isn't in the FNOL form alone. It's in the customer's history, the policy's coverage, similar past claims, and external context — data that exists but isn't asse...

Ask an insurer what a given policy actually covers and, surprisingly often, the honest answer lives in a document — a PDF wording, a Word template, a stack of endorsements — as prose written to be read by a human and defended by a lawyer. The coverage, the exclusions, the limits, the conditions: all of it is unstructured text. That's fine for a claims handler reading one policy. It's a wall for any AI you want to point at coverage questions, because the machine can't reliably reason over what was never turned into structured data. Why the wording being "just text" is a problem Almost every ambitious insurance-AI use case eventually needs to answer a coverage question: does this policy respond to this claim, is this exclusion triggered, what's the sub-limit here. If the authoritative answer lives only in prose — with cross-references, defined terms, and endorsements that silently override the base wording — then the AI is reading a legal document, not query...

Every month, insurers pay commissions to brokers and agents, and every month the numbers are quietly, routinely wrong. Overpayments that never get clawed back, underpayments that erode the distribution relationship, disputes that take weeks to resolve because two systems disagree about what was sold and at what rate. Commission reconciliation is one of the least glamorous processes in insurance and one of the most reliably broken, and the reason is almost never the commission logic. It's that the data feeding the calculation doesn't reconcile in the first place. Why a "simple" calculation goes wrong On paper, a commission is trivial: take the premium, apply the agreed rate, pay the producer. In practice, the premium data lives in the policy system, the producer hierarchy and rate agreements live somewhere else, endorsements and cancellations change the base after the fact, and clawbacks depend on events that arrive late. The calculation is only as correct as the j...

An insurer quotes a risk, the customer or broker doesn't bind, and the quote quietly disappears. Individually it's noise. In aggregate it's the single largest, least-understood leak in the business: a huge share of quotes never convert, and most insurers genuinely cannot tell you why. They see what bound. They rarely see what was quoted and lost, at what price, against whom, and for what reason. The whole pre-bind funnel — where the revenue is actually won or lost — is a data blind spot. Why the abandoned quote is invisible Insurers instrument what they keep. The bound policy generates clean, structured, well-governed data because it has to — it's billed, reserved, and reported. The quote that didn't convert generates almost nothing durable: maybe a row in a rating engine log, maybe not, rarely tied to the eventual outcome or the competitive context. So the data that would explain conversion — what we quoted, what the customer did next, whether they bought elsew...

A customer sends a deletion request — the right to erasure under privacy law — and asks you to remove everything you hold about them. It sounds like a simple instruction. Then someone has to actually do it, and the uncomfortable truth surfaces: the insurer doesn't know everywhere the customer's data lives. It's in the policy system, the claims system, a data warehouse, three spreadsheets, an email archive, a marketing tool, and a couple of vendor platforms nobody fully maps. You can't delete what you can't find, and most insurers can't find all of it. Why "delete my data" is so hard to honor Fulfilling an erasure or access request assumes something most insurers don't have: a reliable, complete view of where a single customer's data is scattered. Data has spread across decades of systems, integrations, and copies, and nobody maintained a map of it. So the request either gets a partial, best-effort response — which is a compliance risk if a ...

Every insurer screens customers, beneficiaries and payees against sanctions and watchlists, because the law requires it and the penalties for missing a real hit are severe. So most insurers tune their screening to catch everything — and end up drowning. A compliance analyst opens a queue of hundreds of "matches" a day, and almost all of them are the same person's name spelled slightly differently, a common name colliding with a listed one, or a stale record that was cleared last week. The real risk is in there somewhere, buried under noise the insurer generated itself. Why the false positives pile up Screening is a matching problem, and matching is only as good as the data on both sides of the comparison. When your own customer records are inconsistent — names in different formats, missing dates of birth, addresses that don't resolve — the matching engine has nothing precise to match on, so it falls back to fuzzy name matching and flags everything that's vague...

Open banking rewired financial services by forcing banks to expose customer data, with consent, through standard APIs. Open insurance is the same idea arriving at our industry — driven by regulation in some markets, by competitive and ecosystem pressure in others — and it asks a question most insurers can't yet answer comfortably: can you expose your data, cleanly and in real time, to a customer or a third party who has the right to it? For a lot of insurers, the honest answer is no, and the reason is the same data foundation problem that shows up everywhere else, now with the doors about to open. What open insurance actually demands Strip away the policy debate and open insurance is a set of concrete data capabilities. A customer (or a party they authorize) should be able to access their insurance data — policies, coverage, claims, history — through standard, secure APIs, in real time, with consent governing exactly what's shared and with whom. That's it. And every cla...

In commercial insurance, the premium you quote at the start of a policy is an estimate. Workers' comp premium depends on actual payroll; general liability on actual sales or receipts; many commercial covers on exposure bases that aren't known until the period is over. So insurers run a premium audit after the fact to true up the estimate against what actually happened — and collect (or refund) the difference. It's a large, recurring source of revenue and leakage, and at most insurers it runs on a process that's slow, manual, and starved of the data that would make it accurate. Why premium audit matters more than it gets credit for Premium audit is where a meaningful chunk of commercial premium is actually determined. If the audited exposure is understated — payroll missed, sales under-reported, a misclassification left uncorrected — you've under-collected on risk you fully carried, the commercial cousin of premium leakage. If it's overstated, you've over...

Property insurers have spent the last few years handing out smart-home devices — water-leak sensors, smart smoke detectors, connected thermostats — on the promise of a compelling story: stop the loss before it happens. A leak sensor that catches a burst pipe at the first drip prevents the water damage that would have been a five-figure claim. The logic is sound and the devices work. And yet, for most insurers, the data those sensors generate ends up doing almost nothing, because collecting a stream of sensor readings and actually acting on it are very different capabilities. The prevention promise, and the gap Usage-based motor insurance struggled because telematics data ended in a dashboard instead of a decision. Smart-home programs are walking into the same trap. The value proposition is prevention — a sensor detects the early signal of a developing problem and someone intervenes before it becomes a loss. But that requires a real-time pipeline that ingests the sensor data, detect...

For insurers that distribute through agents and brokers, the single most important question about the business is also one of the hardest to answer: which of our distribution partners send us profitable business, and which send us the losses? Every insurer has the raw data to answer it — premiums, claims, and the producer code stamped on every policy. Almost none can answer it cleanly. The information sits in the systems, and the systems won't say, because nobody has connected the dots between what an agent produces and what it actually costs. The question you can't quite answer It sounds simple: join policies to claims, group by producer, and rank. In practice it collapses under the usual problems. Policy data lives in one system, claims in another, commissions in a third, and tying them together by producer — accounting for the fact that the same agency appears under different codes, that business moves between producers, that a "good" loss ratio this year might...

The first data an insurer captures about a customer — at quote, at application, at onboarding — is treated as a hurdle to clear on the way to binding the policy. Get the minimum, issue the cover, move on. That framing is a quiet, expensive mistake, because the data you capture at onboarding sets a ceiling on everything you can do afterward. Every downstream ambition — personalization, cross-sell, fraud detection, straight-through servicing, a real customer 360 — is limited by the quality and structure of what you collected at the front door. The ceiling nobody notices Consider what you can and can't do later based on onboarding data. If you didn't capture a reliable identifier, you can't confidently link this customer to their other policies — so customer 360 is broken from the start. If you collected the minimum to rate and bind, you have nothing to personalize with. If the data is inconsistent or unverified, every model that consumes it inherits the noise. You cannot ...

When a big loss hits, an insurer expects to recover part of it from its reinsurers. That recoverable is real money — often a very large number on the balance sheet — and at a surprising number of insurers, the process of calculating, tracking, and collecting it is held together with spreadsheets, email, and the memory of a few specialists. Ceded reinsurance is one of the most financially significant and least industrialized data flows in the business, and the recoverables it produces are frequently numbers nobody can fully reconcile. Why it's so messy Ceded reinsurance is genuinely complex: an insurer's book is protected by a program of treaties — proportional and non-proportional, with different attachment points, limits, reinstatements, and inuring relationships. When a claim occurs, working out exactly what's recoverable, from which treaty, in what order, requires applying that whole structure to the specific loss. Do it across thousands of claims and multiple treaty...

A driver has a fender-bender, opens the insurer's app, photographs the damage, and gets a repair estimate — sometimes a settlement — in minutes, without an adjuster ever seeing the car. Photo-based damage estimation is one of the most visible AI wins in motor insurance, and the demos are genuinely impressive. But the gap between an impressive demo and a capability you can trust on real claims at real volume is, as always, not about the vision model. It's about the data and the guardrails around it. What the model does, and what it doesn't Modern computer vision can look at photos of a damaged vehicle and identify affected parts, assess severity, and estimate repair scope. That part works. What the model alone can't do is know whether the photos are of the right car, whether they're recent, whether the damage matches the reported incident, or whether the estimate is being manipulated. The intelligence in the model has to sit inside a system that handles those que...

Most fraud attention in insurance goes to claims — the staged accident, the inflated loss, the organized ring. But there's an earlier, quieter kind that shapes everything downstream: application fraud, the misrepresentation baked into a policy at the point of sale. The wrong address to get a cheaper zone. The undisclosed prior claim. The commercial risk described as something safer than it is. Catch it at claim time and you're fighting from behind; catch it at application time and you never write the bad risk at all. The difference is entirely a matter of what data you can bring to bear in the seconds before you bind. Why application fraud is underplayed Claims fraud is visible — there's a payout, a file, an investigation. Application fraud is invisible by design: the policy looks normal, the premium arrives, and the misrepresentation only surfaces (if ever) when a claim exposes it. So it doesn't generate an obvious loss line to fight, and it quietly poisons the boo...

Ask an insurer how long it takes to launch a new product or change a rating factor, and the honest answer is usually measured in quarters, not weeks. Ask why, and you'll hear about "the release cycle" or "IT capacity." The real reason is deeper and more fixable: your product definitions — the coverages, the rules, the rating logic — live buried in application code, so changing a product means changing software, and changing software means a project. Products that should be data are trapped as code, and that trap sets the speed of your entire business. The difference between product-as-code and product-as-data In most insurers, when you want to add a coverage, adjust an eligibility rule, or tweak a rating factor, a developer edits logic embedded in the policy admin or rating system, and that change flows through the full software release process: development, testing, deployment, regression. The product is expressed as code, so every product change is a code ...

Insurers spent years and fortunes implementing IFRS 17, and most of them filed it under "finance transformation." That framing is why so many of the programs were painful and why the pain isn't over. IFRS 17 was never really an accounting change you could hand to the actuaries and the finance team. It was a data project — one that demanded granular, reconciled, traceable data at a level most insurers had never assembled — wearing an accounting standard's clothing. Why the standard is a data problem The old world let insurers report at a fairly aggregated level. IFRS 17 changed the unit of account: measurement at the level of groups of contracts, with explicit tracking of the contractual service margin, risk adjustment, and the release of profit over time. To produce those numbers you need data at a granularity — cohort, contract group, cash flow, assumption version — that legacy policy and finance systems were never designed to expose. The accounting rules were th...

Every insurance AI roadmap is full of models — fraud detection, claims triage, document extraction, risk scoring. Almost none of them mention the thing those models actually run on: labeled data. It's the least glamorous topic in machine learning, the one nobody puts on a slide, and it is quietly the reason a startling number of insurance AI projects stall, underperform, or never ship. The model gets the credit and the attention; the labels do the work and get ignored. Supervised learning has a prerequisite Most of the high-value AI in insurance is supervised learning: to predict fraud you need examples labeled fraud and not-fraud; to extract a policy limit you need documents where someone marked what the limit is; to triage a claim you need historical claims labeled with how they turned out. The model learns the pattern from the labels. No labels, no learning. And here's the trap: the quality and quantity of your labels put a hard ceiling on model performance that no amo...

For a lot of insurers, legal spend is one of the largest controllable costs in claims — defense counsel fees, expert witnesses, litigation expenses — and one of the least managed with any rigor. The premium-sized irony is that an industry built on measuring and pricing risk manages its own litigation spend the way a small business manages petty cash: invoices reviewed one at a time, panel counsel chosen by habit, and almost no aggregate view of what's actually driving cost or which firms deliver value. It's a data blind spot hiding in plain sight on the loss run. Why it stays unmanaged Legal invoices are messy, unstructured, and voluminous. They arrive as PDFs, in inconsistent formats, with line items described in each firm's own shorthand. Reviewing them for reasonableness is tedious, so it's done superficially or not at all. And because the data is never aggregated into a structured, analyzable form, the questions that would actually control cost simply can'...

Workers' compensation looks like a medical line — injuries, treatment, recovery, return to work. So insurers reach for medical expertise to manage it and are puzzled when the outcomes stay stubborn: claims that should close in weeks stretch into months, costs that balloon on a minority of claims, injured workers who don't come back. The reason is that workers' comp is really a data-and-coordination problem wearing medical clothing. The medicine is often fine; it's the information flow around it that fails. The claim that quietly goes bad Most workers' comp claims are small and close quickly. The cost — and the human harm — concentrates in a small fraction that develop badly: the injury that becomes chronic, the recovery that stalls, the claim that drifts into litigation. The defining feature of these claims is that they were often identifiable early, if anyone had been watching the right signals. Instead they announce themselves late, when the window to interv...

Climate risk has a permanent slot in every insurer's strategy deck, usually somewhere near the ESG commitments. What it rarely has is a coherent answer to the operational question underneath it: how does climate risk actually change the number an underwriter puts on a policy today? Between the boardroom ambition and the point-of-sale decision sits a data problem that most insurers haven't solved, and until they do, "we take climate risk seriously" is a statement about intent, not capability. The gap between narrative and rating At the strategic level, climate risk is well understood: perils are intensifying, historical loss experience is becoming a weaker guide to the future, and portfolios concentrated in exposed geographies carry risk that yesterday's models understate. All true, all in the deck. But an underwriter pricing a specific property in a specific location needs that macro truth translated into a concrete input — a forward-looking view of flood, w...

Every insurer's contact center records its calls — "this call may be recorded for training and quality purposes." Then those recordings go into storage and are never heard again unless a complaint or a dispute forces someone to dig one out. It is, quite possibly, the largest untapped dataset in the company: millions of hours of customers explaining, in their own words, exactly what confuses them, what they need, what went wrong, and why they're calling instead of using the app. Recorded faithfully, analyzed almost never. The dataset you already paid to collect Think about what's in a contact-center call. A customer states their problem in natural language. An agent works through it. The outcome — resolved, escalated, churned — is implicit in the conversation. Aggregate that across millions of calls and you have a direct, unfiltered readout of customer intent, friction, and sentiment that no survey can match, because it's what customers actually said when...

Every insurer deploying AI is accumulating something they may not have named yet: model risk. As models move from analytics curiosities to systems that price policies, decline applicants, and settle claims, the question stops being "is the model accurate?" and becomes "can we govern it?" Banking learned this the hard way and built model risk management (MRM) into a discipline. Insurance is now being asked the same questions — by regulators, by auditors, by its own risk functions — and most insurers don't have a coherent answer. The uncomfortable part is that MRM, done properly, is mostly a data problem. What model risk management actually means MRM is the practice of identifying, measuring, and controlling the risk that a model is wrong, misused, or misunderstood. It covers the model's development, its validation by someone independent of the builders, its ongoing monitoring, its documentation, and the governance around who can deploy and change it. It...