Insurance Platform: Policies and Claims

Quote, Bind, Bill, Claim, Pay

Design a home and auto insurer's core platform: quote, underwrite, bind and bill policies, then take claims through adjudication to payment, where every past version of a policy can be reproduced and no claim is ever paid twice.

Overview

An insurer sells a promise: pay for a covered loss in exchange for a premium. The platform behind that promise has two halves. The policy side quotes a price, decides whether to accept the risk (underwriting), binds the policy so coverage starts, and bills the premium. The claims side takes the first notice of loss (FNOL), decides what the policy covers, and pays.

Traffic is modest: about 12 quotes a second on average at our assumptions, and a few thousand claims a day. What makes it hard is time and money. A claim filed today for a storm last month must be judged against the policy as it stood on the day of the storm, including changes recorded later. Each state has its own rules and deadlines. A payment must happen exactly once, and a regulator may ask, years later, to see every step of a claim. Then a hurricane arrives and claims jump fifty times in a day, mostly from people who need money for a roof or a hotel now.

Questions to ask first

Which products? — Personal home and auto, sold in many US states
How big? — 10 million policies in force, 1 million quotes a day, 1 million claims a year
Who uses it? — Customers, agents, underwriters, adjusters, finance, and regulators through audits
How do changes work? — Endorsements change a policy from an effective date, sometimes in the past
Who moves money? — Banks and card processors; we record, instruct and reconcile
Biggest risk? — A catastrophe surge, and paying a claim twice or wrongly

What you will be able to do

Walk a policy from quote to bind and a claim from FNOL to payment, naming the record each step writes.
Model policy versions and endorsements so you can answer what was covered on a date, as known on another date.
Pay claims exactly once through a double-entry ledger, while reports stay eventually consistent.
Absorb a 50× catastrophe surge without losing a claim or overwhelming adjusters.
Keep an audit trail regulators accept, and keep personal and medical data out of most systems.

Key concepts

Rating engine
Effective-dated versions
Bitemporal records
Endorsements
Claim state machine
Straight-through processing
Fraud scoring
Loss reserves
Double-entry ledger
Catastrophe surge

Functional requirements

Quote a premium from rate tables for a state, product and effective date
Apply each state's underwriting rules; bind and issue a policy
Change a policy with endorsements that take effect on a given date, including past dates
Bill premiums in full or in installments, and handle cancellations and refunds
Take a first notice of loss with photos and documents
Adjudicate claims with rules, fraud scores and adjusters; pay through a ledger
Report catastrophe losses to reinsurers and to regulators

Non-functional requirements

A retried bind, endorsement or payment never takes effect twice
Any past premium or coverage decision can be reproduced from stored versions
Every change to a policy or claim is in an append-only audit trail kept for the retention period
FNOL intake stays available through a 50× surge (a target we chose)
Quotes return in under 1 second at p99 (a target we chose)
Personal and medical data are encrypted and visible only to roles that need them

Interview questions

How do you know what a policy covered on the date of a loss?
How do you make sure a claim is never paid twice?
Walk through a claim from first notice to payment.
How does the system survive a hurricane?
Why cache rate tables, and how do you invalidate the cache?
How do you handle different rules in every state?
Where do you need exactly once, and where is eventual consistency fine?
How do you protect personal and medical data?
What does the reinsurance hand-off need from the platform?