Insurance domain fundamentals

A policy is the contract: a party, a term, a premium and a set of promises. A risk is the thing insured — this vehicle, this building, this life, this cargo voyage — and a single policy can carry many of them, which is why a fleet motor policy is one contract over four hundred risks. A cover is one promise attached to a risk, with its own limit, excess and wording, so buildings and contents are two covers on one household risk. Conflating the three is the most common modelling error, because it produces a table where a limit belongs to a policy and then cannot express the fact that theft and flood are limited differently on the same building.

A peril is a cause of loss the cover responds to — fire, escape of water, theft, storm — so a cover is really a set of perils with the money attached. An exclusion removes something the wording would otherwise have caught: wear and tear, gradual deterioration, war, a named pre-existing condition. The engineering consequence is that a claim decision is not a lookup on the cover but an evaluation against a peril list and an exclusion list as they stood on the date of loss. That is why claims systems store the resolved wording version against the claim rather than joining to the current product definition, which will have changed by the time the claim is disputed.

Because they are three roles and often three different people. The policyholder owns the contract and pays; the insured is the person or asset whose loss triggers the promise; the beneficiary receives the money. On a family motor policy the holder is one parent and the insureds are four drivers. On a life policy the insured dies and the beneficiary is paid. A schema with a customer_id on the policy cannot express any of this, and the failure shows up late — at claim payment, when the money must go to someone who is not on the policy record, or at data subject access, when a named driver asks for their own data and you cannot separate it from the holder's.

The chain determines who holds the data, who holds the risk, and who your system integrates with.

sequenceDiagram
    participant C as Customer
    participant B as Broker
    participant M as MGA with delegated authority
    participant I as Insurer on whose paper it sits
    participant R as Reinsurer
    C->>B: Asks for cover and discloses facts
    B->>M: Submits the risk for a quote
    M->>I: Binds within the binder limits
    I->>R: Cedes part of the exposure
    M-->>B: Returns policy documents and premium

A broker advises the customer and is the customer's agent, not the insurer's. It holds the client relationship and often the client data, which means the insurer frequently does not know the customer's contact details and cannot email them directly — a fact that quietly kills a lot of direct-to-customer feature ideas.

A managing general agent is different: it acts for the insurer under a binder, an agreement delegating underwriting authority within stated limits. The MGA can quote, bind and often settle claims on the insurer's paper. Engineering-wise this means the system of record for a policy may not belong to the party carrying the risk, and the insurer learns about its own book through a monthly bordereau — a file of policies and claims written under the delegation.

Two consequences follow. Data arrives late and in bulk rather than in real time, so aggregate exposure is always somewhat stale, which matters most in exactly the week a hurricane forms. And commission sits in the chain: premium collected by a broker is net of commission and held in a client money account before settlement, so premium receivable, premium collected and premium earned are three different numbers that must reconcile.

Premium is what the insured pays. Sum insured is the declared value of the thing covered and is the ceiling for the whole risk. A limit caps what the insurer will pay for a particular cover or event, and is often lower than the sum insured — an inner limit for escape of water inside a buildings cover, for instance. Deductible and excess are broadly the same idea, the amount the insured bears before the insurer pays, with excess the British term and deductible the American one; in commercial lines a deductible is often much larger and negotiated as part of the price. The reason to be precise is that they combine in a defined order, and the order changes the settlement.

One loss, four contract terms, and an answer that is far below what the insured expected.

Household claim. Escape of water damages a kitchen and flooring.

  Sum insured, buildings                                    250,000
  Assessed loss                                              40,000
  Policy excess                                               1,000
  Inner limit, escape of water                               25,000
  Declared value 250,000 against assessed reinstatement
  value of 312,500  ->  cover ratio 80%

  1. Apply the inner limit      min of 40,000 and 25,000   = 25,000
  2. Apply average at 80%       25,000 x 0.80              = 20,000
  3. Deduct the excess          20,000 - 1,000             = 19,000
  4. Test the sum insured       19,000 < 250,000           = 19,000

  Settlement 19,000 against a 40,000 loss.

Nothing here is a bug. Every step is contractual, and the gap between 40,000 and 19,000 is the single largest source of complaints in general insurance, which is why the calculation must be explainable line by line rather than emitted as one number.

The order is the part candidates get wrong. Applying the excess before the inner limit gives 24,000 rather than 19,000, because the excess would then be absorbed by the amount the limit was going to strip out anyway. The contract dictates the sequence, so the sequence is product configuration, not code, and it varies by product and by jurisdiction.

Step two is the average or co-insurance clause, and it exists because the insured under-declared. Having insured 250,000 of a 312,500 property, they paid 80% of the correct premium and receive 80% of every claim, not only claims above the sum insured. Engineers routinely model underinsurance as a cap, and it is not — it is a proportional reduction applied to losses that never approach the sum insured.

The audit requirement follows from all of it. A settlement record needs the inputs, the rule versions, the order applied and the intermediate values, because a complaint or an ombudsman referral arriving two years later asks you to reproduce this exact arithmetic against the wording in force on the date of loss.

Reinsurance is insurance bought by insurers, so that a single large loss or a correlated set of losses does not consume the capital. Proportional reinsurance — quota share or surplus — cedes a fixed percentage of both premium and losses, so the reinsurer takes 30% of everything and the arithmetic is a share of each policy. Excess of loss is non-proportional: the reinsurer pays the layer above a retention, say 250 million in excess of 50 million, and pays nothing at all until the retention is exhausted. The engineering difference is real. Proportional needs per-policy cession records and premium splits; excess of loss needs accurate event aggregation, because you cannot claim on a layer without proving which losses belonged to one event.

Because the same legal person appears in many roles across many contracts and over decades, and the roles carry different rights. One individual may be a policyholder on a household policy, a named driver on a relative's motor policy, a third-party claimant against a stranger's policy, and a beneficiary on a life policy. A third-party claimant is not your customer and never consented to anything, yet you hold their medical and financial data. That combination — roles rather than a customer type, and data about non-customers — is why insurers invest in party mastering, and why "one row per customer" designs fail their first data protection review.

The transitions matter more than the states, because each one writes a record somebody will later reconcile.

flowchart LR
    Q[Quote<br/>priced offer, no risk attached] --> B[Bind<br/>risk attaches, version 1 created]
    B --> I[Issue<br/>documents, premium schedule, tax]
    I --> E[Endorse<br/>new version plus a premium transaction]
    I --> L[Lapse<br/>non-payment, cover ends at paid-to date]
    I --> X[Cancel<br/>refund or charge, possibly backdated]
    E --> R[Renew<br/>new term, new version chain, invited or auto]

A quote is an offer with a price and an expiry, and no exposure. Quotes outnumber policies by ten or twenty to one, so they dominate storage and are the workload the rating engine is actually sized for, while contributing nothing to the book.

Bind is the moment risk attaches and the only irreversible step in the diagram. Everything after it is an amendment to something the insurer is already liable for, which is why bind writes an immutable version rather than setting a flag. Issue is separate because documents, premium schedules and premium tax are produced then, and because in delegated arrangements bind and issue can be days and two systems apart.

Endorsement, lapse and cancellation all end the current version's validity and create a financial transaction — additional premium, return premium, or a write-off. Lapse and cancel differ in intent and therefore in wording: lapse is the passive consequence of unpaid premium and typically ends cover at the date premium was paid to, while cancellation is a deliberate act by either party with a notice period and a refund basis.

Renewal is the one candidates treat as trivial. It creates a new term with re-rated premium, a fresh disclosure position and, in many markets, a regulated requirement to show last year's price beside this year's. It is also the highest volume batch process an insurer runs, because the entire book renews across twelve months and every renewal invites a rate and a rule set that may have changed since the policy was bound.

Because the insurer's obligation is defined by what the contract said at a particular instant, and an update destroys that. If a policy is amended in June and a claim is notified in July for a loss in May, the settlement must be evaluated against the May wording, limits and excesses — which no longer exist if June overwrote them. Versioning also carries the money: each version has its own premium, and the difference between consecutive versions is the additional or return premium that must appear in the ledger. A current-state row with an updated_at column can express neither, and retrofitting versions onto a live book is one of the most expensive migrations in the industry.

A quote is a price with an expiry and no liability; the insurer can withdraw it and nothing is owed either way. Bind is acceptance — risk attaches from the effective date, and the insurer is on the hook even if no document has been produced and no premium collected. Issue is the administrative act of producing the contract documents, the premium schedule and the tax entries. Keeping them distinct matters because the gap between bind and issue is real in commercial and delegated business, and because a system that only records "policy created" cannot answer the question an underwriter cares about most, which is what was on risk at midnight last night.

Lapse is what happens when premium stops arriving: cover ends by default, usually at the date premium was paid up to, after a grace period and a statutory or contractual notice. Cancellation is a deliberate act by the insured or the insurer, with a notice period, a stated effective date and a refund basis that may be pro-rata or on a short-period scale that penalises early exit. The distinction is not cosmetic. A lapsed policy is often reinstatable on payment with no gap in cover, whereas a cancellation by the insurer for non-disclosure may be treated as though the policy never existed, which changes every claim already paid under it.

A named driver added halfway through the term, and the two versions plus one transaction it produces.

Annual motor policy, 01 Apr 2026 to 31 Mar 2027, annual premium 600.00
On 01 Oct 2026 the insured adds a named driver.
Rerated annual premium for the amended risk: 780.00

  Days in term                                          365
  Days remaining from 01 Oct 2026                       182
  Unearned original premium    600.00 x 182 / 365    = 299.18
  Unearned amended premium     780.00 x 182 / 365    = 388.93
  Additional premium due                             =  89.75

After the endorsement, the policy is three records, not one

  version 1   effective 2026-04-01 .. 2026-09-30   annual 600.00
  version 2   effective 2026-10-01 .. 2027-03-31   annual 780.00
  txn MTA-1   additional premium 89.75, booked 2026-10-01, commission 13.46

The premium charged is the difference between two unearned amounts, not the difference between two annual premiums. Charging 180.00 — the annual difference — would overcharge by a factor of two, and charging nothing until renewal would give six months of extra risk for free.

Version 1's effective window closes; it is not deleted and its premium is not restated. That is what makes the earned premium for April to September stable forever, which every actuarial and financial report downstream depends on.

The transaction is a separate object from the versions, and this is the part candidates collapse. Versions describe cover; transactions describe money. One endorsement can create several transactions — additional premium, a mid-term administration fee, a commission adjustment and a premium tax entry — and each needs its own accounting date, which may differ from the effective date.

The awkward cases are worth naming unprompted. A minimum premium rule can make a tiny adjustment cost more than the arithmetic suggests. A refund below a threshold is usually not paid at all. And an adjustment backdated across an already-invoiced period requires reversing and reissuing the invoice rather than editing it.

Because two independent clocks apply to every fact. There is business time — the period the cover applies to — and record time, when the system came to believe it. A change can be agreed today and effective last month, or agreed last month and only keyed today. Every meaningful question therefore has a date in it: what cover was in force on the loss date, what premium had we earned as at the quarter end, what did we believe about this policy when we sent the reinsurer the June bordereau. A system that stores only current state can answer none of these, and no amount of application logic recovers information that was overwritten.

Two date pairs per row, and two genuinely different questions they answer.

policy_version  -- bitemporal: business time and record time

 ver  effective_from  effective_to  recorded_from  recorded_to   annual
 1    2026-04-01      2027-03-31    2026-03-28     2026-10-02    600.00
 1    2026-04-01      2026-09-30    2026-10-02     9999-12-31    600.00
 2    2026-10-01      2027-03-31    2026-10-02     9999-12-31    780.00

Q1  What cover was in force on 2026-08-15, as we understand it now?
    effective_from <= '2026-08-15' AND effective_to >= '2026-08-15'
    AND recorded_to = '9999-12-31'
    -> version 1, annual 600.00

Q2  What did we believe on 2026-09-20 about cover on 2026-11-01?
    effective_from <= '2026-11-01' AND effective_to >= '2026-11-01'
    AND recorded_from <= '2026-09-20' AND recorded_to > '2026-09-20'
    -> version 1, annual 600.00 - the endorsement did not exist yet

Q1 is the claims question and the one everybody models. Q2 is the audit and reconciliation question, and it is the one that requires the second date pair: the September bordereau said 600.00 for the whole term, and that file must remain reproducible after the October endorsement changed the answer.

Notice that version 1 appears twice. The first row is the original belief, closed off in record time when the endorsement was keyed; the second is the corrected belief with a shortened effective window. Nothing was updated in the sense of losing information — a row was closed and a replacement inserted.

The engineering costs are specific and worth stating before you are asked. Every query needs four predicates rather than one, so a forgotten recorded_to predicate silently returns duplicate rows and doubles a premium total. Uniqueness constraints become exclusion constraints over ranges, because two rows may share a version number legitimately. And the table grows with change rather than with the book, so a heavily endorsed commercial policy can hold hundreds of rows.

The pragmatic middle ground most insurers land on is full bitemporality on policy and cover, business time only on reference data, and a snapshot table for reporting so analysts are not writing four-predicate joins by hand.

The same sequence of events against a table that is updated in place, with the damage listed.

Naive schema:  policies(id, status, annual_premium, updated_at)

  Timeline
  2026-04-01  policy issued, annual premium 600.00, status ACTIVE
  2026-06-30  claim C-77 notified, loss date 2026-06-28
  2026-07-20  claim C-77 settled, 3,200 paid
  2026-08-10  underwriter cancels for non-disclosure,
              effective 2026-05-01

  UPDATE policies SET status = 'CANCELLED', annual_premium = 50.00,
         updated_at = now() WHERE id = 'P-100';

  What just broke
  - claim C-77 sits against a policy with no cover on 2026-06-28
  - the June bordereau sent to the reinsurer cannot be reproduced
  - earned premium for May to July changes in every report ever run
  - no record of who cancelled it, when, or what it said before
  - the 3,200 already paid has no recoverable basis in the data

Retroactive change is normal in insurance, not an edge case. Non-disclosure found during a claim investigation, a broker keying a change a fortnight late, a court deciding a cancellation was invalid — all of them rewrite the past legitimately, and the naive model treats each as an overwrite.

The specific failure is that the row now describes a policy that never existed in that form at any instant. It was never simultaneously true that the policy was cancelled from May and that a June claim was validly paid, yet that is exactly what the table asserts, and there is no way to tell whether the claim was paid in error or the cancellation postdates it.

The bitemporal version handles it without drama: close the current record-time row, insert a version with the shortened effective window, and leave the old belief intact. The June bordereau still reproduces, and the claim now visibly sits in the gap, which is the trigger for a recovery process rather than a silent inconsistency.

The point to make in an interview is that this is a correctness requirement rather than an audit nicety. Reserves, reinsurance recoveries, premium tax returns and regulatory capital are all computed as at a date, and every one of them is wrong if history is mutable.

Commercially it is a new contract with a new term, but operationally it inherits almost everything: the same party, the same risks, the claims history that drives the no-claims discount, and the continuous-cover position that determines whether a later claim falls into a gap. Systems therefore model it as a new policy term linked to its predecessor, so the chain can be walked. The consequences are that re-rating may produce a very different price from the same data because rates moved, that disclosure is refreshed rather than assumed, and that in several markets you must display last year's premium alongside this year's.

Three things, and only the first is about price. Whether to accept the risk at all, which is risk selection and produces decline and refer outcomes. On what terms, which covers exclusions, endorsed conditions, mandated excesses and required surveys. And at what price, which is rating. The order matters because a rate applied to a risk that should have been declined is worse than no rate: it converts a decision into a number and hides it. In engineering terms, the rating engine is downstream of the eligibility rules, and a design that prices first and filters afterwards will happily quote business the insurer has agreed never to write.

A commercial property submission evaluated against a binder's rules, and why the outcome is not a price.

Submission: sum insured 4,200,000, listed building,
            flat roof 40% of area, 1 prior claim in 5 years

  RULE   condition                             outcome
  UW-01  sum insured > 5,000,000               DECLINE, outside binder authority
  UW-02  sum insured > 2,000,000               REFER to underwriter
  UW-03  flat roof proportion > 30%            REFER, survey required
  UW-04  listed building                       REFER, reinstatement basis
  UW-05  postcode in flood zone 3              DECLINE
  UW-06  prior claims > 2 in 5 years           LOAD 25%
  UW-07  sprinklered throughout                DISCOUNT 10%

  Evaluation
  UW-01 false   UW-02 TRUE   UW-03 TRUE   UW-04 TRUE
  UW-05 false   UW-06 false  UW-07 false

  Outcome: REFER with three reasons. Premium shown as INDICATIVE.
           Bind blocked until an underwriter accepts or amends.

Rules do not vote. They are evaluated for all outcomes and then combined by severity: any decline beats any referral, any referral beats an automatic accept, and loadings and discounts apply only once the risk is acceptable. A design that stops at the first matching rule loses the other two referral reasons, and the underwriter then works blind.

Referral is the outcome candidates forget exists, and it dominates the architecture. It means the quote must persist in a suspended state, that a human queue and an ownership model are required, that the indicative price must be distinguishable from a bindable one, and that re-evaluation after the underwriter's decision must not silently reprice the risk under a rate that changed while it sat in the queue.

Each referral also carries a reason code, which is what makes the referral rate measurable per rule. That metric is how an insurer discovers a rule referring 40% of submissions for no underwriting benefit, and it is a far better answer to "how would you know this was working" than logging.

The decline path needs its own care. A decline is a commercial and sometimes a regulated decision, so it is recorded with its reason and retained, and in personal lines it may need to be expressible to the customer without exposing the threshold that produced it.

Multiplicative factors on a base rate, then the loadings that turn a risk premium into what the customer pays.

Motor quote. Base rate by vehicle group, then relativities.

  Base rate, vehicle group 14                        420.00
  x driver age 23                                      1.65
  x postcode risk band E                               1.20
  x annual mileage 18,000                              1.10
  x no-claims discount, 2 years                         0.85
  x voluntary excess 500                                0.93
  = risk premium                                      723.11

  + expense loading 12% of risk premium                86.77
  = net premium                                       809.88
  / 1 - commission 15%                                952.80
  + insurance premium tax 12%                         114.34
  = total payable                                   1,067.14

The risk premium is the expected cost of claims. Everything below it is expense, distribution and tax, and the customer's price is roughly 1.5 times the underlying risk — which is why "the premium is the model output" is wrong, and why a data scientist's improvement to the risk premium moves the sale price by less than they expect.

The commission line is a division, not an addition, because commission is a percentage of gross premium rather than of net. Adding 15% of net gives 931.36 instead of 952.80, understates commission by 3.2%, and produces a broker settlement that never reconciles. This is one of the most common defects in home-grown rating code.

Multiplicative factors compound, so the young driver in the poor postcode with high mileage is not additively worse — 1.65 times 1.20 times 1.10 is 2.18 times the base. That is intentional, and it is also why capping and smoothing rules exist, because the raw model output for the worst combinations exceeds anything the market will accept.

The engineering requirements follow from the audit position. Every factor value must be traceable to a rate table version, the whole calculation must be reproducible for a policy bound eighteen months ago, and the factor tables are data with effective dates, not constants in code. A quote must record the rate version it used, or a complaint about pricing cannot be answered.

It is the component that turns a risk description into a price, using rate tables, factor sets and rules that change far more often than the policy administration system does. Separation exists because the change cadences differ by an order of magnitude: rates move weekly or monthly in competitive personal lines, and a policy system release is quarterly. It also allows the engine to be called at very high volume from aggregators and quote journeys without touching the book of record. The cost of separation is that rate versions must be addressable and pinned, since a quote, a bind and an endorsement three months later must each price against a specific version.

Actuarial pricing derives expected cost from data — frequency and severity models over a large homogeneous portfolio — and is only as good as the volume and stability of the history. Underwriting judgement handles what the data cannot: the unusual commercial risk with no comparable, the loss history that has an explanation, the new exposure with no precedent. Personal motor is almost entirely actuarial; a specialist marine or cyber risk is largely judgement. The consequence for systems is that both paths must exist and be distinguishable, and that an overridden price needs the original, the override, the reason and the author, because the portfolio analysis later depends on separating modelled performance from human intervention.

Anti-selection, or adverse selection, is the tendency for those most likely to claim to be keenest to buy, and to shop hardest for the cover that suits them. If your price is below the market for a segment, you win a disproportionate share of that segment's worst risks. Engineering feels this in specific ways: a pricing bug is not a revenue leak but a magnet, because aggregators route every matching query to the cheapest quote within minutes. That is why insurers monitor quote conversion by segment as an operational alert, and why a rate deployment is watched like a release rather than filed as a data change.

Because a rate is a commercial and regulated artefact, not a configuration value. It must be approved by pricing and underwriting authority, tested against the existing book to show what would happen to renewals, checked for conduct issues such as an unjustified difference between new business and renewal pricing, and recorded so any historical quote can be reproduced. The engineering shape that follows is release management for data: versioned rate sets, an approval workflow, a dry-run capability that reprices a sample of the book, an effective date rather than a deploy time, and a rollback that does not retrospectively change quotes already given.

The states are ordinary workflow. The reserve movements beside them are what makes claims a financial system.

flowchart LR
    F[FNOL<br/>claim opened, default reserve 2,500] --> T[Triage<br/>adjuster sets reserve 8,000]
    T --> V[Investigate<br/>reserve raised to 14,000]
    V --> S[Settle<br/>11,200 paid, reserve to zero]
    S --> R[Recover<br/>subrogation receipt 4,000]
    R --> C[Close<br/>incurred 7,200 net of recovery]
    C --> O[Reopen<br/>a new head of loss creates a fresh reserve]

Every transition writes money as well as status. The reserve is the insurer's current estimate of what this claim will ultimately cost, and it appears in the accounts as a liability from the moment of notification, before anybody knows whether the claim is valid.

Reserve movements are the signal the business watches. A reserve raised from 8,000 to 14,000 is adverse development, and a portfolio where reserves systematically strengthen after triage means the initial estimates are too optimistic and the reported loss ratio has been flattering. That is why the history of reserve changes is stored as movements, never as an updated field.

Payment does not end the claim. Recovery from a negligent third party arrives months later and reduces the net incurred cost, so the claim's financial position after closure differs from its position at settlement, and reporting must handle gross, net of recovery, and net of reinsurance as three separate figures.

Reopening is the transition that breaks naive designs. A closed claim is not immutable — a further head of loss, a late injury claim on a motor accident, or a successful appeal reopens it years later, sometimes into a financial period long since closed. Claims systems therefore treat closure as a state, not a deletion, and accept that a prior accident year's incurred cost can change today.

FNOL is the moment a loss is reported, and it sets everything downstream: the loss date that determines which policy version applies, the peril that decides which cover responds, the initial reserve, the fraud signals, and the customer's impression of the entire product. It is hard because the person reporting is distressed, often at the roadside, may not be the policyholder, frequently cannot identify the policy, and gives an account that will be revised. So the screen must capture enough to open a claim and reserve, while tolerating almost every field being provisional — the opposite of the validation-heavy design engineers default to.

Which handling path a claim takes, which is a cost decision as much as a service one. A small, clear, low-fraud-risk claim should settle automatically or with minimal touch, because the handling cost can otherwise approach the claim value. A large or contentious one needs an experienced adjuster, possibly a loss adjuster on site, and a legal reserve. Triage therefore consumes the initial reserve estimate, the fraud score, complexity indicators and the policy's own terms. The engineering risk is that triage rules become the de facto claims policy while living in nobody's documentation, so they need the same versioning and measurement as underwriting rules.

A reserve is the estimated future cost of a claim already notified, recognised as a liability now. Ownership is split, which surprises engineers. The case reserve is owned by the claims handler, who sets it from the facts of the individual claim. The portfolio-level provision, including everything not yet reported, is owned by the actuarial function, which will not simply sum the case reserves because it knows they are systematically biased. Both numbers must be derivable from your data at any past date, so a claims system exposes case reserve movements and does not permit editing a reserve without leaving the previous value and the reason.

Subrogation is the insurer stepping into the insured's shoes to recover from whoever caused the loss: having paid the policyholder, the insurer pursues the negligent third party or their insurer. Salvage is recovering value from the damaged property itself — selling the write-off vehicle for parts. Both reduce the net cost of a claim after it has been paid, sometimes long after, which is why net incurred cost is not knowable at settlement. Systemically they need a recovery sub-process with its own lifecycle, and they need to allocate the recovery back to the claim and onward to reinsurance, because a recovery on a ceded claim partly belongs to the reinsurer.

The model looks good in isolation. The economics only appear when the false positives are priced.

Motor claims, 10,000 per month. Prevalence 4%, so 400 are fraudulent.
Model at threshold 0.70: recall 60%, precision 25%.

  True positives      0.60 x 400                        =   240
  Flagged total       240 / 0.25                         =   960
  False positives     960 - 240                          =   720
  Missed fraud        400 - 240                          =   160

  Benefit
    fraud stopped     240 x 4,800 average value          = 1,152,000

  Cost
    investigations    960 x 350 handling                 =   336,000
    genuine claims delayed 18 days on average, 720 of them
      complaints      8% x 720 x 220 redress and handling =    12,672
      churn           3% x 720 x 900 lifetime value       =    19,440
    net benefit                                          =   783,888

The model pays for itself, and 720 honest customers waited eighteen days for money they were owed. That is the trade, and stating it as a trade rather than as an accuracy figure is what distinguishes a candidate who has shipped a detection system.

Precision is doing all the work here. At 25%, three in four investigations inconvenience an honest claimant, and the operational capacity — 960 investigations a month — is a hard constraint that no model improvement relaxes. Raising the threshold improves precision, cuts investigator load, and lets more fraud through; the correct threshold is a business decision informed by investigator headcount, not an F1 optimum.

The costs above are conservative because they exclude the ones that are hardest to quantify and easiest to lose your licence over. A conduct regulator does not accept net benefit as a defence for systematically delaying valid claims, and a model that flags a protected characteristic by proxy is a discrimination problem regardless of its lift.

Two design consequences follow. Scores route to human investigation rather than denying claims, because an automated denial on a probabilistic signal is indefensible. And every flag needs its outcome recorded — confirmed, cleared, inconclusive — or the model cannot be retrained, which is how detection systems quietly decay to worse than the rules they replaced.

It is a promise about elapsed time — acknowledge within one working day, appoint an adjuster within three, decide within ten, pay within five of agreement — and in several markets parts of it are regulated rather than commercial. Measuring it is harder than it looks, because the clock stops while waiting for the customer or a third party, and the definition of a stop determines whether you appear compliant. That makes SLA reporting a modelling problem: you need per-claim timestamps for every state entry and exit, an explicit pause concept with a reason, and a calendar for working days and holidays per jurisdiction.

Because a closed claim can reopen, and its financial position can still move. Recoveries arrive after closure, reducing net cost. Litigation can reopen a settled bodily injury claim years later, and long-tail liability lines routinely see claims reopen a decade on. A reopened claim needs a new reserve, which lands in the current accounting period but belongs to the original accident year, so prior-year development is a permanent feature of the reporting rather than a data-quality problem. Systems that model closure as terminal — archiving the record, dropping the reserve history — make this reopening a manual reconstruction every time.

The same product change, expressed both ways, and the delivery difference it produces.

Hard-coded                              Configured
--------------------------------------  --------------------------------------
if product == "HOME_PLUS":              product HOME_PLUS version 4
  if peril == "ESCAPE_OF_WATER":          cover ESCAPE_OF_WATER
     limit = 25000                          limit 25000
     excess = 1000                          excess 1000, range 250 to 2500
  if year_built < 1900:                   rule REFER when year_built < 1900
     refer()                              factor POSTCODE_BAND, table 12
                                          effective 2026-10-01, territory GB

Adding a peril with its own limit      Adding a peril with its own limit
  code change, release, regression       new product version, no release
  weeks of lead time                     hours, with approval
  in-force policies priced by            in-force policies keep the version
  whatever code is currently live        they were bound on

The left column has one fatal property that has nothing to do with speed: the code expresses only the current product. A policy bound two years ago under different limits is now evaluated by today's branches, so historical claims are assessed under wording that never applied to them.

The right column makes the product a versioned, effective-dated artefact, and the policy stores which version it was bound on. That single indirection is what makes historical correctness possible, and it is the actual reason insurers build product engines — the release-cadence argument is secondary.

The cost is real and worth conceding. A configuration language is a language: it needs validation, a test harness, a preview against sample risks, an approval workflow and versioning of its own. Configuration errors reach production without passing through code review, so the guardrails must live in the tooling, and a badly designed product engine becomes an untyped programming language operated by people who were never given a debugger.

The boundary question is the mature one. Limits, excesses, factor tables, eligibility rules and wording variants belong in configuration; a genuinely novel calculation belongs in code with a configuration hook. Insurers that tried to configure everything ended up with rules engines nobody could reason about, which is the failure mode at the opposite end from hard-coding.

Because they sell hundreds of variants of a handful of products, differing by distribution channel, territory, regulatory regime and scheme, and each variant changes on its own schedule. Encoding that in application code multiplies releases by variants until the release train is the constraint on the commercial strategy. The deeper reason is temporal: an insurer must price and adjudicate against the product as it stood when each policy was bound, so product definitions have to be data with effective dates whatever the delivery argument. A product engine is the mechanism that lets a new scheme launch without a code change and lets a 2019 policy still be evaluated under 2019 terms.

More than the covers. The limits and excesses and their permitted ranges, the peril and exclusion sets, the eligibility and referral rules, the rate tables and factor sets, the wording and document templates, the question set used to gather the risk data, and the mapping from answers to rating inputs. Version them together, because a rate table that assumes a question added in version 4 will misprice a version 3 risk. The practical implication is that the product version is a first-class reference on the quote, the policy version, the claim and the document, so any of them can be reconstructed without guessing.

The PAS is the book of record: it holds policies, versions, premiums and the lifecycle transitions, and everything else in the estate reconciles to it. They are old — twenty to forty years is common, often COBOL or a mainframe-era package — because they encode decades of product variants and regulatory history that nobody can fully specify, and because the migration risk is existential rather than merely large. The engineering consequence is that most insurance work is integration: an event layer or API façade over a batch-oriented system of record, with a nightly extract as the real interface and reconciliation as a permanent feature rather than a project.

ACORD is the general insurance industry's standards body, publishing data standards and message formats — the AL3 and EDI legacy formats, XML standards, and more recently JSON-based ones — for exchanging risks, policies, claims and bordereaux between brokers, insurers and reinsurers. It buys you an agreed vocabulary and message shape for the party, risk and cover concepts, so a broker's submission need not be mapped bespoke to every insurer. What it does not buy is uniformity, because implementations use extension points heavily and every counterparty's dialect differs, which is why the mapping layer is real work rather than a library call.

Because it has different obligations, a different lifecycle and vastly different volume. A quote expires, has no risk attached, can be abandoned mid-journey and must record the rate version and factor values that produced its price so it can be honoured or explained. Twenty quotes exist for every policy, and in aggregator-fed personal lines the ratio is far higher, so quotes dominate write volume and storage while contributing nothing to the book. Modelling them as draft policies puts that volume into the book of record, mixes expiring speculative data with the legally significant kind, and makes every policy query filter on status forever.

Everything that assumed the product was current. In-force policies must continue to be administered — endorsed, claimed against, renewed — under the version they were bound on, so the runtime must load a historical product definition rather than the latest. Renewal is the interesting case, because it deliberately moves the policy onto a newer version, which means the difference between versions becomes a customer communication and possibly a conduct issue if cover narrowed. Mid-term adjustments are the awkward one: an endorsement to an old-version policy prices against the old rates, which is correct, and periodically produces a premium the current rate set cannot reproduce.

One accident year, valued at successive year ends, and what each column does.

Accident year 2024, valued each 31 December, GBP thousands

  valued at   paid    case reserve   IBNR    incurred
  2024-12    1,200        2,600      1,900     5,700
  2025-12    3,400        1,500      1,000     5,900
  2026-12    4,900          700        300     5,900
  2027-12    5,450          200         50     5,700
  ultimate   5,600            0          0     5,600

Read the columns as processes rather than numbers. Paid only rises. Case reserves fall as individual claims settle and the estimate becomes a payment. IBNR falls as the unknown becomes known — it is a provision for claims not yet reported and for the under-reserving of those that are.

Incurred — paid plus case plus IBNR — is the estimate of ultimate cost, and its movement is the scoreboard. Here it deteriorated by 200 in the first year and then improved, ending 100 below the original estimate. A book where incurred rises every year is under-reserving, and the reported profit of earlier years was fiction.

The engineering requirement hiding in this table is that every figure is as at a valuation date, computed from claim transactions with both an accident date and a transaction date. If a claim system stores current reserve only, this table cannot be produced at all, and the actuarial function will build a shadow database from extracts — which is how most insurers end up with two contradictory sources of claims truth.

The last column is only known years after the accident year closed, which is why long-tail lines are structurally harder than motor: liability and asbestos claims develop over decades, so 2024's true cost may not be settled until the 2040s and the reserve is the business's most consequential estimate.

Incurred but not reported: the provision for losses that have already happened but which the insurer has not heard about. A storm on 28 December generates claims in January, so the year-end accounts must carry a liability for claims with no claim record. It cannot come from a transaction system because there are no transactions — it is estimated statistically from development patterns, typically by chain-ladder methods on historical triangles. The engineering consequence is that a claims database is necessary and insufficient for the accounts, and the data an actuary needs to estimate IBNR is a triangle by accident period and development period, which is a different shape from anything an operational report produces.

The book looks diversified at portfolio level. Aggregating by geography says otherwise.

Household book: 92,000 policies, total sum insured 4.10bn.
Aggregated by outward postcode, top five by sum insured:

  postcode  policies   sum insured   share   flood zone
  HU1          1,840   184,000,000    4.5%   3
  HU3          1,610   152,000,000    3.7%   3
  YO8            980   106,000,000    2.6%   2
  DN14           870    97,000,000    2.4%   3
  LS10           760    72,000,000     1.8%   1

  HU1 + HU3 + DN14 lie on the same river system and tidal surge zone:
    433,000,000 of sum insured, 10.6% of the book, fully correlated.
  Reinsurance programme: 250,000,000 excess of 50,000,000.
  A 60% damage ratio across those three -> 260,000,000 gross.
  The retention of 50,000,000 is ours; the reinsurer pays 210,000,000
  of a 250,000,000 layer, so 40,000,000 of cover is unused.
  A 71% damage ratio would exhaust it.

The point of the aggregation is that ordinary portfolio diversification is an illusion under a single physical event. Four and a half per cent in one postcode is unremarkable; ten and a half per cent behind one flood defence is a solvency question.

The correlation is not visible in any field. Nothing in the data says HU1, HU3 and DN14 share a river system — that comes from a hazard model joined to geocoded exposure, which is why insurers buy peril data and why geocoding quality is a material control rather than a data-cleaning nicety. A policy geocoded to a postcode centroid rather than a building can sit on the wrong side of a defence.

The engineering demands are specific. Exposure must be aggregatable within hours of a warning, across the whole book, at the granularity the hazard model uses, and including business bound by delegated authorities whose bordereau has not yet arrived. That last point is the real difficulty: the exposure you cannot see is still yours.

The operational use is a live constraint on underwriting. Once an accumulation zone approaches its limit, further risks in that zone are declined or priced up regardless of individual quality, which means the rating engine needs a real-time-ish view of aggregate exposure — a very different data access pattern from pricing one risk.

Catastrophe models simulate large numbers of synthetic events — windstorms, floods, earthquakes — against a portfolio to produce a loss distribution, from which the business reads an average annual loss and the loss at return periods such as one in two hundred years. Those figures drive reinsurance purchasing and regulatory capital. The engineer's job is the exposure data: geocoded locations, construction type, occupancy, year built, height, sum insured by cover, and the policy terms that cap the loss. Model output is only as good as those inputs, so the unglamorous work — geocoding accuracy, completeness of construction attributes, correct application of limits — is where the value sits.

Because their methods are longitudinal. A reserving triangle needs to know what was paid and reserved on each claim at each past valuation date, and a pricing model needs the exposure as it was during each period at risk, not as it is now. A current-state extract answers neither, and an actuarial team given one will reconstruct history from monthly snapshots, badly. This is why insurance data platforms are built around immutable transaction and snapshot layers rather than mutable entity tables, and why "we can rebuild it from the audit log" is not an acceptable answer — the audit log was designed for compliance, not for joins.

The loss ratio is incurred claims divided by earned premium, so 68% means sixty-eight pence of claims for every pound earned. The expense ratio adds acquisition costs, commission and administration over the same premium base. The combined ratio is their sum, and it is the single number the market judges an insurer's underwriting on: below 100% the underwriting made money, above 100% it lost money and any profit came from investment returns. They matter to engineers because both numerator and denominator are non-trivial to compute — incurred includes reserve movements and prior-year development, and earned premium requires apportioning premium across time.

Written premium is the premium for policies bound in a period, recognised when the contract is written. Earned premium is the portion relating to risk already elapsed, so a twelve-month policy written on 1 October has earned a quarter of its premium by 31 December and the remainder sits as an unearned premium reserve. The distinction complicates reporting in a specific way: growth appears in written premium immediately and in earned premium over the following year, so a fast- growing insurer looks worse on ratios than it is. Every reporting layer therefore needs an earning pattern per product, and it is not always straight-line.

It is the European prudential regime governing how much capital an insurer must hold, built on three pillars: quantitative capital requirements, governance and risk management including the ORSA, and disclosure and supervisory reporting. It reaches engineers through data. The capital calculation consumes granular exposure and claims data with defined lineage, the quantitative reporting templates demand specific classifications at fixed frequencies, and the data-quality expectations are explicit — completeness, accuracy and appropriateness must be demonstrable. In practice that means documented lineage from source system to submitted figure, controls with evidence, and the ability to reproduce a past submission exactly, which is a temporal-data requirement in a compliance costume.

It changes insurance contract accounting to a current-value measurement, and its demands are structural rather than cosmetic. Contracts must be grouped into portfolios and annual cohorts by profitability at inception, which means every contract carries a grouping determined at issue and immutable thereafter. Each group needs expected future cash flows, a discount rate, a risk adjustment and a contractual service margin released over the coverage period. For engineers the consequence is granularity and history: cash flow projections at cohort level, per-period movement analysis, and reproducibility of every prior close. Insurers that had only current-state policy data discovered that IFRS 17 was a data programme rather than an accounting change.

It is the conduct principle that outcomes for customers must be fair, and in the UK the Consumer Duty makes it more explicit: products must offer fair value, communications must be understandable, and customers must not be exploited for inertia. Engineering consequences are concrete. Claims decisions need reasons a person can read. Cancellation and complaint journeys cannot be materially harder than the buying journey. Pricing must not penalise loyalty. Vulnerable customers must be identifiable and handled differently. And because firms must evidence outcomes rather than assert them, the monitoring itself becomes a deliverable — outcome metrics by customer segment, not just system metrics.

The significant one in the UK is the general insurance pricing practices reform, which bans price walking: a renewing customer must not be quoted more than an equivalent new customer through the same channel. That is a systems requirement, because it means the renewal price must be checked against a computed new-business-equivalent price for the same risk, and the two pricing paths must therefore be reconcilable rather than separately evolved. Related rules require disclosing last year's premium at renewal, making auto-renewal cancellable easily, and reporting on product value. Each one turns a marketing practice into a constraint the rating and renewal batch must satisfy and evidence.

Because the questions asked of an insurance system are historical by nature and come from parties with legal standing. An ombudsman asks why a claim was declined under wording in force two years ago. A regulator asks how a price was derived and whether the rate set was approved. An auditor asks you to reproduce the year-end reserve. A court asks who knew what and when. None of these can be answered from current state plus application logs, so the trail has to be part of the data model — versions, transactions, effective and record dates, decision reasons and rule versions — rather than a logging concern bolted on for compliance.

A layer with sharper teeth than engineers expect, because insurance data is frequently special category. Medical underwriting, injury claims and life applications involve health data; criminal convictions appear in motor proposals. Special category data needs a specific lawful basis, tighter access control, and genuine minimisation, so the common pattern of copying production into every environment is not merely poor practice but a reportable breach waiting to happen. Retention is the other tension: long-tail liability requires keeping claim data for decades, which must be reconciled with erasure rights, and the reconciliation is a documented retention schedule per data category rather than a global default.

More than most sectors, and all of it periodic and granular. Prudential returns under Solvency II at quarterly and annual frequency with prescribed templates. Financial reporting under IFRS 17 at cohort level. Conduct reporting on product value, complaints volumes and claims acceptance rates. Bordereaux to reinsurers and from delegated authorities, monthly and per agreement. Premium tax returns per territory. Each has its own classification scheme, and the classifications rarely agree, so a policy needs several parallel categorisations — regulatory class of business, internal product, reinsurance treaty section, tax category — assigned at inception and stable thereafter.

Whether you reach for a version or for an update, and it is the single most diagnostic question in insurance interviews. A weak answer changes the policy row and perhaps adds an updated_at or an audit table, which discards the state the contract was in and makes any claim on the earlier period unanswerable. A strong answer creates a new immutable version with its own effective window, closes the previous one, records a separate premium transaction for the pro-rata difference, and mentions that the change may be backdated so record time and business time must both be stored. The question is really asking whether you understand that insurance data is a history, not a state.

Because an audit table is written for humans investigating incidents, and versioning is read by the system making decisions. Adjudicating a claim needs to load the cover as it stood on the loss date, as a first-class query with joins and constraints — not to reconstruct it by replaying diffs from a log of column changes. Audit tables are typically incomplete, denormalised, unindexed for temporal queries, and not covered by referential integrity, so the reconstruction is unreliable exactly when it matters. The distinction to state is that versioning is a functional data model and auditing is an operational record; you need both, and one does not substitute for the other.

They model the states and miss the money. A claim's states are ordinary workflow and could be built in a fortnight; what makes claims hard is that every state change carries reserve and payment movements that land in the general ledger, feed reinsurance recoveries, and drive actuarial reserving by accident period. A claim also has multiple parties with conflicting interests, several currencies of truth — gross, net of recovery, net of reinsurance — and can reopen years after closure into a financial period that was signed off. A design that treats it as a ticketing system with statuses will need rebuilding the first time finance asks for incurred cost by accident year.

Because the record is evidence, and its history is the product. A cancelled policy still explains claims paid during the period it existed. A voided claim still explains a payment that was reversed. A superseded rate table is needed to justify a price to an ombudsman three years on. Even a genuine erasure request under data protection is handled by redacting personal identifiers while retaining the financial and contractual record, because the retention obligation and the legal basis for it survive the erasure right. So the default is soft state transitions and immutable transactions, and any true deletion is a controlled, evidenced exception rather than an implementation choice.

"A claim arrives today for a loss last March, and the policy has been endorsed twice and backdated once since. Which terms apply, and how does your schema find them?" A strong answer separates the two time axes without prompting, describes selecting the version whose effective window contains the loss date under the record-time view relevant to the question, notes that a backdated cancellation may leave the loss date uncovered and that this triggers a recovery process rather than a data fix, and names the product and rate version pinned to the policy so the wording can be resolved. A weak answer describes joining to the policy and reading its limits, which is the current-state model, and cannot explain what happens when the answer changes tomorrow.