Budget-Based Microinsurance

Insurance sold like a subscription: pick a monthly price from $5 and get personal cover. AI does the work an agent and a claims desk used to do, so small cover finally pays its way.

Comment

Inspiration

When a storm shuts down a city, a delivery rider loses a whole day's pay. Cover for exactly that has existed for decades, yet almost nobody sells it to them. The reason is not demand, it is cost: a $5 policy cannot pay for the people around it. The agent who sells it, the underwriter who rates it and the claims handler whose time costs more than the claim all eat the premium before it protects anyone. So the people with the least savings, gig workers, first-time buyers and anyone paid by the day, are exactly the people insurance never reaches.

We asked a simple question: what if the per-customer work cost almost nothing? Reading what a customer shares, explaining a cover in plain words, checking a photo, judging a small claim: that is reading, writing and judgement on unstructured input, which is what AI can now do. That makes a new kind of insurance possible, one that is sold like a subscription inside the apps people already use.

What it does

You pick the price. We build the protection, every month.

  • The customer picks a monthly plan ($5, $10, $15 or $20). A deterministic optimiser turns that price into a personal set of small covers (phone damage, weather income, accident, event tickets, ...) in about 33 µs, refitted every month to what is ahead in their life.
  • The AI explains every cover in one plain sentence, so nobody has to read a policy wording.
  • The AI reads the month ahead (a new phone, a flight in December) and writes one prevention task for exactly that. The customer sends a photo, a vision model checks it (including whether it looks reused or edited), and a reward lands. The product is useful even in a month when nothing goes wrong.
  • Parametric covers pay automatically. When a weather service publishes a storm warning (CAP 1.2, the open alerting standard national weather services use), every matching policy is paid in seconds, with no claim form. One warning fans out to 1,000,000 policies in 1.6 s.
  • Small claims go straight through. The AI reads the photo and recommends approve or refer; within the insurer's authority the claim is paid at once.
  • People stay in charge. The AI can never decline. A random 1 in 20 automated decisions goes to a person, and a fairness audit flags any group treated worse.
  • It is built as an engine an insurer runs and distribution partners (delivery apps, wallets, ticketing, telecoms) embed with a Web Component, so there is no agent and no form.

How we built it

The core rule: the AI recommends, a deterministic engine decides money.

  • crates/engine (Rust) decides every price, sum insured and payout. It has no I/O, no clock, no randomness and no AI; money is integer minor units (Money(i64)), and clippy denies floating-point arithmetic. The engine does not depend on the AI crate, so the compiler enforces the boundary.
  • crates/ai (Rust) calls Claude through the Anthropic Messages API: a fast tier (claude-haiku-5-5) for short customer-facing text and a strong tier (claude-sonnet-5-5) for judgement and images. Prompts are Markdown files loaded at runtime. Each reply is deserialised into a typed recommendation and checked (one sentence, no amounts, no protected attributes). Anything that fails to parse, times out or errors falls back to a saved answer.
  • Illegal states are unrepresentable. The straight-through claim outcome is enum StpOutcome { Approved, Referred }: there is no Declined variant, so only a named person can decline.
  • 59 business rules, each with its source and a test named after it, and 12 architecture decision records, each mapped to existing insurance practice (loss occurrence and hours clauses, first-loss settlement, reinsurance event limits, waiting periods).
  • One source of truth across three languages: Rust types generate the OpenAPI and JSON Schema contracts, the TypeScript client and the Python models. The Python economic models call the production engine through PyO3, not a re-implementation.
  • Apps: a framework-free TypeScript customer app, a partner embed (Web Component), and partner and operations consoles, served by an axum API with a live payout stream; PostgreSQL for the double-entry ledger and the policy store.
  • A new country is configuration, not code. The demo runs in an international market (US dollars, English, CAP storm warnings) defined entirely in config/markets/global/; two more market configurations ship as worked examples.
  • Evaluations: every AI component has a golden set that runs through the real harness, offline on saved replies or live against the model.
  • We built it with Claude Code as our coding agent, working under explicit constraints (AGENTS.md): the engine boundary, integer money, test-first rules and generated contracts. AI helped build it, and AI runs inside it, with the money decisions kept where a compiler can check them.

Two pieces of the maths the engine enforces:

A prevention reward is a share of the claims it avoids, so rewards can never cost more than they save:

$$ r = \alpha \cdot (p_{\text{without}} - p_{\text{with}}) \cdot \bar{C}, \quad 0 < \alpha < 1 $$

A storm is one loss occurrence. Each policy is paid a guaranteed share at once, and the balance when the occurrence closes, pro-rated if total payouts would exceed the reinsurance event limit L:

$$ \text{paid}_i = b_i \cdot \min\left(1, \frac{L}{\sum_j b_j}\right) $$

Challenges we ran into

  • Letting AI help without letting it decide money. We solved it structurally rather than with prompts: a separate deterministic engine, typed recommendations, saved fallbacks, and a type with no "decline" variant.
  • Testing something non-deterministic. Golden sets with saved replies keyed by the exact input make every AI component reproducible offline, and the same cases run live against the model.
  • Making $5 insurance actually work as insurance: waiting periods, accumulation limits, one storm counted as one loss occurrence so a day is never paid twice, and payouts that respect the reinsurance event limit.
  • Fairness and privacy: protected attributes never reach a model; partners only see aggregates from at least 50 customers; approval rates are compared across groups.
  • Going international: every market-specific value (currency, plans, feeds, language, limits) had to move out of code into configuration.

Accomplishments that we're proud of

  • A complete, running system, not a mock-up: customer app, partner embed, partner and operations consoles, workers, ledger and economic models, with about 330 tests and green CI.
  • Measured performance: 1,000,000 policies matched in 1.6 s on one core, the optimiser at 32.8 µs per customer, and 8,400 idempotent ledger postings a second on PostgreSQL.
  • An AI layer that is genuinely useful (seven jobs across the monthly loop) and provably unable to move money.

What we learned

The interesting question is not "can AI decide claims?" but "which work can AI take over so that a product that was never viable becomes viable?" Drawing that line explicitly, in types and in tests, made the AI easier to trust, not harder.

What's next

An insurer partner to supply approved product wordings and its own loss data, a pilot with a wait-list control group and fixed success gates (already designed in the repo), and more markets added as configuration.

Built With

Share this project:

Updates

Submission history