IntelliBooks — AI in Insurance

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...

Ask a motor insurer with a telematics programme how much data they're collecting. You'll get an impressive number — billions of GPS points, accelerometer readings, trip records, harsh-braking events. Then ask what decisions that data actually changes. The answer is usually: a discount at renewal, and a dashboard nobody opens. That's a remarkable gap. You built the collection infrastructure — the hard, expensive part — and then used maybe 5% of what it produces. The pattern is everywhere in insurance IoT It's not just motor: Telematics collects continuous driving behaviour, and is used to apply one annual discount tier. Connected home sensors detect leaks and are used to... send the customer an app notification. Commercial IoT monitors equipment continuously, and feeds a quarterly risk-engineering report. Wearables in health and life gather daily activity, and drive a points-and-vouchers scheme. In each case the data is high-frequency and behavioural...

Here's an uncomfortable estimate: somewhere between 60% and 80% of what your insurance company knows isn't in a database at all. It's in documents. Policy wordings. Medical records. Police reports. Repair estimates. Surveyor reports. Correspondence. Endorsement letters. Forty years of accumulated PDFs, scans, faxes-turned-images, and email attachments — full of exactly the facts every AI model on your roadmap wants, and structurally unable to give them up. This is the quietest bottleneck in insurance data, and it blocks more than people realise. Why this is worse in insurance than elsewhere Plenty of industries have documents. Insurance has a specific compounding problem: The documents are the contract. A policy wording isn't a description of coverage — it is the coverage. What's in that PDF is legally what you owe. You can't approximate it. They arrive from everywhere. Hospitals, garages, police, surveyors, brokers, customers — none of whom use y...

Your fraud team is good at catching individuals. A claimant whose story shifts, a receipt that looks altered, someone who files a bit too often. That's what the rules were built for, and they work. They're nearly blind to organised fraud — and organised fraud is where the money goes. The reason isn't that your team lacks skill or your rules lack sophistication. It's that you're asking a question your database structurally cannot answer. What a fraud ring actually looks like A ring isn't one bad claimant. It's a network: a handful of claimants, a couple of "witnesses", a repair shop, a medical clinic, a few bank accounts, some phone numbers, and a device or two — recombined across dozens of claims over months. Take any single claim from that ring and it looks fine. The claimant has no history. The damage is plausible. The repair estimate is in range. Nothing trips a rule, because the rule is examining one claim in isolation, and in isolati...

Over 200 cloud migrations, patterns emerge. Not the ones in the vendor case studies — the ones you only see from inside, at 2am, when the reconciliation doesn't balance. Here's what we've actually learned about insurance data. Some of it is uncomfortable. 1. The estimate is always wrong in the same direction Every migration takes longer than planned, and almost never because of the technology. It's because of what you find: a rating rule nobody documented, a batch job that silently corrects bad data at 2am, a product variant that exists only in one state. The work isn't moving data. It's discovering what the old system actually does — which nobody knows in full, because the people who knew have retired. Budget for archaeology, not just engineering. 2. Every reconciliation mismatch is a gift When your new premium calculation disagrees with the legacy system by ₹40 on 300 policies, the instinct is to treat it as a bug to squash quickly. Don't. Tha...

It's the question in every insurance data platform decision, and it generates more heat than insight: Snowflake or Databricks? Here's an honest answer from having migrated a lot of both. Short version: they're both excellent, the gap is narrower than either vendor implies, and the decision matters far less than what you do next. But there are real differences, and your workload should pick. Where each genuinely leads Snowflake is stronger when your centre of gravity is SQL analytics. Reporting, actuarial analysis, regulatory extracts, BI over structured policy and claims data. It's operationally calmer — less to tune, fewer knobs, and your existing SQL people are productive on day one. Separation of storage and compute means the finance team's month-end doesn't fight the actuaries' model run. For a carrier whose data is mostly relational and whose consumers are mostly analysts, it's the shorter path. Databricks is stronger when your centre of g...