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.

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.