Insurance Domain Knowledge for Engineers

What this area actually covers

Insurance domain knowledge means understanding two objects and the money between them. A policy is a contract in which the insurer promises to pay for specified losses during a specified period, in exchange for a premium. A claim is a request to make good on that promise. Rating engines, underwriting workbenches, billing, reinsurance and statutory reporting all exist to price, issue, service or settle those two things.

The boundary that matters is with banking. A bank's core object is a balance knowable exactly; an insurer's is a promise whose cost is unknown when it is sold and may not be fully known for a decade. That difference is why insurers need actuaries, reserves and reinsurance, and banks do not.

Two things get wrongly bundled in. Actuarial science is adjacent but separate: actuaries build the pricing and reserving methods, engineers make them executable. And insurance is not one domain — property and casualty means short claim tails and constant policy change, life means fifty-year contracts, health looks more like billing adjudication. Assume P&C unless told otherwise.

The seven areas underneath

The section splits into seven subsections, and the split is not arbitrary: it follows the two halves of the business, with the money-and-risk machinery underneath. Policy administration, underwriting and rating, and distribution are the inbound side, where risk is priced and accepted. Claims and fraud are the outbound side, where the promise is tested. Actuarial and reinsurance sit across both, because they decide whether the whole book makes sense.

Policy Administration is the system of record for the contract itself, and the transactions that change it: quote, bind, issue, endorse, renew and cancel. It exists as its own area because those six transactions and the temporal data model underneath them are the backbone every other insurance system depends on. Open it for the policy object, the effective-dated model, how a mid-term change is priced, and why "what did the policy say on this date" is a harder query than it sounds.

Underwriting & Rating is deciding whether to accept a risk and at what price. Rating is the arithmetic — base rates, factors, discounts, minimum premiums, applied in a prescribed order. Underwriting is the judgement layer around it: appetite, eligibility, referral rules, and the point at which a human looks at the file. It is separate from policy administration because the governing constraint is different: much of it is filed with a regulator and therefore cannot be changed quietly. Expect rating algorithms, rules versus models, referral workflow, and the governance of a rate change.

Claims Lifecycle runs from first notification of loss through reserving, investigation, adjudication and payment, into subrogation and recovery. It gets its own area because a claim is a long-lived case with its own money, its own participants and its own reversibility rules, and because reserving means money is recognised before it is spent. Read it for the claim state model, case reserves, indemnity versus expense, and what happens when a closed claim reopens.

Insurance Fraud covers detection at both ends — an application that misstates the risk, and a claim that is inflated, staged or entirely invented — plus the network analysis that finds organised rings and the investigator workflow that acts on it. It is separate because the objective differs from ordinary claims handling: you are looking for patterns across files rather than adjudicating one, and the output is a referral rather than a decision. Open it for detection signals, link analysis, and how a special investigation unit actually works a case.

Actuarial & Reserving is the discipline that estimates what the book will ultimately cost. For an engineer it means understanding loss development, triangles, incurred-but-not-reported reserves, and why an actuary's data requirements are not the same as a reporting team's. It exists separately because actuarial work needs data cut by accident period and development period, sliced in ways operational systems never anticipate. Expect triangles, development, the distinction between case reserves and bulk reserves, and the plumbing that feeds them.

Reinsurance is insurance bought by insurers: treaty and facultative arrangements, how each policy and each claim payment is ceded across them, the bordereaux reported to reinsurers, and how the recoverable shows up in the accounts. It is its own area because cession logic cuts across policy and claims data and imposes retention requirements on both. Read it for treaty structures, attachment points, cession calculations, and why claim payments must remain sliceable years after the file closed.

Distribution & Channels is how the business is written: independent and captive agents, brokers, comparison sites, managing general agents with delegated authority, and embedded cover sold inside someone else's purchase. It warrants its own area because the channel determines the data you receive, the latency you must hit and the commission you owe. Open it for channel models, quote-and-bind integration, delegated authority, and commission calculation and settlement.

Where it sits in a real business

Money enters through distribution: an agent, broker, aggregator or website produces an application. Rating turns its attributes into a price, and underwriting decides whether the carrier wants the risk at all and on what terms. From there the lifecycle is a small, universal set of transactions.

Four of the six are really about time, which is the theme of the whole domain.

flowchart TD
    A[Application received] --> B[Rate the risk]
    B --> C{Within appetite}
    C -->|No| D[Decline or refer]
    C -->|Yes| E[Bind and attach coverage]
    E --> F[Issue documents]
    F --> G[Endorse mid term]
    G --> F
    F --> H{End of term}
    H -->|Renew| B
    H -->|Cancel early| I[Compute return premium]

The edge worth noticing is the loop from Endorse back to Issue. An endorsement is not a small update; it produces a new set of documents, a new premium calculation and a new version of the contract, and it can be effective from a date already in the past.

Rating itself is mostly deterministic and rule-shaped: a base rate by coverage and territory, factors for the vehicle or building, discounts, minimum premiums, rounding in a prescribed order. In much of the world those rules are filed with a regulator, so they are versioned by state and effective date and cannot be quietly changed. In the United States that filing goes to each state's insurance department, and the practical consequence for engineers is that "the rating algorithm" is really fifty algorithms with a shared skeleton, each with its own effective dates.

A small worked example is worth more than a description, because it shows why order of operations is a specification rather than a detail:

Base rate, liability, territory 14      420.00
  x vehicle symbol factor  1.15         483.00
  x driver class factor    1.28         618.24
  x multi-policy discount  0.90         556.42     rounded to cents each step
  x term factor, 6 months  0.50         278.21
  + policy fee                            35.00
  = term premium                         313.21
Minimum premium check                    250.00    not binding here

Change the order of the discount and the term factor and you get a different answer in the last cent, which over a book of a million policies is a real number and, in a filed environment, a deviation from the algorithm you told the regulator you would use. This is why rating engines are so pedantic about sequence and rounding.

Underwriting is where models enter — risk scores, telematics, straight-through processing that binds a clean risk with no human involved — but they sit inside a rules frame rather than replacing it: eligibility and referral rules and capacity limits still gate the outcome, and a decline or a rate usually has to be explainable.

The reverse flow is loss

A claim is reported; a reserve is set aside for what the insurer expects to pay; the file is investigated and adjudicated against the policy's terms; payments go out and the reserve is drawn down until the claim closes. Where a third party caused the loss, subrogation lets the insurer pursue them to recover what it paid, a real revenue line rather than an afterthought.

sequenceDiagram
    participant I as Insured
    participant C as Carrier claims
    participant A as Adjuster
    participant V as Vendor or repairer
    participant R as Reinsurer
    I->>C: First notification of loss
    C->>C: Verify coverage and set reserve
    C->>A: Assign the file
    A->>V: Instruct inspection or repair
    V-->>A: Estimate and invoice
    A->>C: Recommend settlement
    C->>I: Payment issued
    C->>R: Cede the recoverable share

What to look at is the second line. The reserve is set before anybody knows what the claim will cost, and it is money recognised in the accounts on the strength of an estimate. Every later step either draws that reserve down or revises it, and the revision is itself a reportable event.

Claim state deserves an explicit model rather than a status column, chiefly because of the transition most systems forget:

stateDiagram-v2
    [*] --> Reported
    Reported --> Investigating
    Investigating --> Denied
    Investigating --> Reserved
    Reserved --> Paying
    Paying --> Closed
    Closed --> Reopened
    Reopened --> Paying
    Denied --> Reopened

Closed is not terminal. A claim can reopen years later because an injury worsened, a new party joined a suit, or a subrogation recovery arrived, and a schema that archived closed claims into a read-only store has just made the common case expensive.

So the vocabulary to be precise about is premium (money in, for risk accepted), loss (money out, for risk that materialised) and reserve (money held for losses incurred but not yet paid). Say which of the three a number is and as of what date, and you can follow almost any conversation in the building.

The words that carry the money

Earned premium is the one to internalise first. A twelve-month policy sold on 1 January for 1,200 has not earned 1,200; on 31 March it has earned roughly a quarter of it, and the rest is a liability. Almost every reporting misunderstanding between engineers and finance traces back to somebody summing written premium and calling it revenue.

Insurers also buy insurance

Reinsurance passes part of a carrier's risk to another carrier, either proportionally (a quota share: a fixed percentage of premium and loss) or excess-of-loss (the reinsurer pays above an attachment point, up to a limit, per risk or per catastrophe). It caps exposure to one hurricane or one enormous liability claim and lets a carrier write more than its own capital allows.

For engineers this is cession logic allocating each policy and claim payment across treaties, plus the reporting of what the reinsurer owes — so payments must stay sliceable by treaty, layer and accident date long after the file closed. The awkward part is that treaties are agreed by underwriting year and claims arrive by accident date, so a single payment can be split across structures that were negotiated years apart.

Who does this work

Most of the engineering happens on vendor platforms. Guidewire, Duck Creek, Sapiens and FINEOS dominate administration, so a large share of insurance developers are configuration developers, writing product models, rules and integrations inside a platform rather than building a policy system from nothing. Around them sit integration engineers moving ACORD-standard messages between carriers, brokers and reinsurers, data engineers feeding actuarial and regulatory reporting, and claims engineers wiring in fraud scoring and payment rails.

The people who specify the work are distinct and you will spend your days with them: underwriters decide what risks to take, actuaries own pricing and reserving, adjusters run claim files, business analysts turn a filing into requirements. A good day is one where the analyst can tell you which version of which rule applies from which date.

It is worth saying plainly that the configuration developer role is the modal job in this domain and is often undersold in interviews. Configuring a modern policy platform is programming: you are writing a product model, rules and integrations in a constrained language, against an upgrade cycle you do not control, with the same testing and version-control problems as any other codebase and a few extra ones.

Demand, adoption and how that is changing

Demand is steady rather than surging, for structural reasons. Cover is compulsory across large parts of life — motor, mortgage-linked property, employer liability — so volumes do not collapse in a downturn. Regulation keeps producing work with no product upside: IFRS 17 rewired insurance contract accounting, rate-fairness and data-protection rules constrain what a model may use, and every jurisdiction's filings change on their own calendar. And carriers still run policy administration systems built decades ago that cannot be switched off, because they hold in-force contracts that will not expire for thirty years. That legacy tail is not a footnote; it is where much of the work is, and migration programmes routinely outlive the people who started them.

Consolidation is real but partial. Core administration is moving to a handful of vendor platforms, which shrinks from-scratch building and grows configuration and migration work. The insurtech wave that promised to displace carriers mostly ended up selling software and distribution to them instead. What has genuinely grown is data and model work: telematics, claims automation, document extraction, and getting a decade of policy history off a mainframe into something an actuary can query.

Two pressures are worth watching because they change what gets funded. Climate exposure has made catastrophe modelling and reinsurance analytics disproportionately important in property lines, and has pushed carriers to withdraw from or reprice whole territories, which is a product-configuration problem before it is anything else. And distribution keeps moving towards embedded and comparison channels, which means quote latency and API quality are now commercial differentiators rather than IT concerns — a comparison site that times out your quote simply shows the customer somebody else's.

One thing that is not changing is the shape of the employer base. Carriers, brokers, the four or five platform vendors and the consultancies that implement them account for nearly all of the roles, and they hire in long cycles tied to programme funding rather than to quarterly product bets. That makes the market less volatile than most of software and also less liquid: there are fewer openings at any moment, and the good ones are filled by people the hiring manager has worked with before.

What makes it hard

The conceptual leap is that there is no single present. An endorsement filed on 14 August effective 1 July means the policy retroactively had different coverage for six weeks: premium for that window must be recalculated, the difference billed or refunded, and any claim already adjudicated under the old terms revisited. Yet the policy as it was believed on 20 July must stay reconstructible, because a regulator or a court may ask. Every fact carries two timelines: when it is true in the world, and when the system learned it.

-- Policy 4471: bound with a 500 limit, later endorsed retroactively to 1000.
-- effective_* = when the coverage applies; recorded_at = when we knew it.
policy_id  coverage   limit  effective_from  effective_to  recorded_at
4471       liability    500  2026-07-01      2027-07-01    2026-06-28
4471       liability    500  2026-07-01      2026-07-01    2026-08-14  -- closed off
4471       liability   1000  2026-07-01      2027-07-01    2026-08-14  -- supersedes

-- Limit on 10 July, as understood on 20 July? -> 500
-- Limit on 10 July, as understood today?      -> 1000
-- One timeline cannot answer both. Most legacy schemas try anyway.

The reason this is not academic is that money hangs off the answer. If a claim was paid on 20 July against a 500 limit and the endorsement later raises it to 1,000 effective 1 July, the insured is arguably owed more. The system must be able to find every decision made under superseded knowledge, which means the old view has to remain queryable rather than being overwritten and audited in a log nobody can join to.

The second difficulty is product configurability. A carrier does not sell one motor product; it sells one per state, per programme, per channel, each with its own coverages, forms, rules and rate tables, each versioned by effective date. Hard-code any of it and you cannot launch a product without a release; generalise all of it and you have built a configuration language nobody can debug. Every real system sits somewhere painful between, and knowing where to put that line is what experience buys.

The failure mode at each extreme is worth naming, because both are common. The hard-coded system produces a release backlog: the business waits three months to change a factor, so it stops asking and starts running spreadsheets beside the system, and now the spreadsheet is the real product definition. The over-generalised system produces an untestable one: rules referencing rules, no type checking, no way to know which of four thousand configuration rows a given quote used, and a defect that can only be found by replaying production traffic.

Third, correctness is delayed. A rating defect crashes nothing; it silently misprices thousands of policies and surfaces during a market conduct exam, and reserving errors take years to appear. The tests that matter are reconciliations against an actuary's spreadsheet and replays of historical transactions. A good insurance test suite therefore looks unusual: a corpus of real historical quotes with their known outputs, re-run against every build, so that a change to a shared factor cannot silently move a product it was not aimed at.

Fourth, and least discussed, documents are part of the product. The contract the customer holds is a generated document, and its wording is filed and version-controlled just as the rates are. Producing the right form version for the right jurisdiction on the right effective date, with the right endorsements attached in the right order, is an entire subsystem, and a mismatch between the document and the system's view of the coverage is resolved in the customer's favour more often than not.

Why study it

The honest case is stability and pay rather than excitement. Budgets are large, the work is not seasonal, and domain knowledge compounds: an engineer who understands endorsement pricing and effective-dated product models is scarce, and because the platforms are industry-standard that knowledge travels between carriers in a way generic CRUD experience does not.

There is a technical case too, and it is stronger than the domain's reputation suggests. Bitemporal modelling, rules engines whose configuration is the product, and reproducibility of a computation performed years ago are genuinely hard problems that most industries only meet in weak forms. Solve them here and you will recognise them instantly in banking, healthcare, tax and anywhere else a decision has to be defended after the fact.

It is also unglamorous, and you should know that going in. The stack lags the industry by years, novel distributed systems work is rare, and you will spend real time in spreadsheets and regulatory filings. If you want to ship weekly or work on frontier infrastructure, this is the wrong domain. If you want durable, well-paid expertise in a business that will still exist in thirty years, it is one of the better trades available.

Your first hour

Take a real policy document — your own motor or home schedule will do — and reconstruct it on one page: the policy period, each coverage with its limit and deductible, the insured items, the total premium. Split that premium across coverages as best the document allows, then compute earned premium as of today on a straight-line basis: premium times days elapsed over days in the term.

Then the hard part. Write the SQL DDL for a table holding those coverages such that you can answer both "what were the limits on 1 September" and "what did we believe the limits were, as of 1 September". You will need effective-date columns, a separate recorded-at column, and a decision about what supersession looks like. Finish by writing down what your schema does when a coverage is backdated two months, and what that does to the earned premium.

If you want a second exercise that exposes a different muscle, price a cancellation. Cancel your reconstructed policy halfway through the term and compute the return premium two ways: strictly pro rata, and on a short-rate basis where the insurer keeps a penalty share for the cancellation. Then write one sentence on which one applies when the insurer cancels rather than the customer. The answer differs by jurisdiction and by reason, and noticing that a single word in the requirement changes the arithmetic is exactly the instinct this domain rewards.

What this is not

It is not actuarial work. Implementing a filed rating algorithm is engineering; deriving it is a credentialled profession with its own exams, and blurring the two reads badly in both directions. Nor is it generic fintech: the overlap with payments is the billing edge and little else, because payments has no equivalent of an effective-dated, retroactively amendable, regulator-filed product, and no equivalent of a reserve.

It is also not one system. Candidates talk about "the insurance system" as though a carrier had one. A mid-size carrier runs separate policy administration, billing, claims, document generation, warehouse and reinsurance systems, often more than one of each because an acquisition brought its own, joined by files and messages rather than a shared database. Much of the real work lives at those seams.

And it is not a rules engine plus CRUD. That description survives the first sprint and then meets the endorsement, the reopened claim, the treaty that attaches by underwriting year while claims arrive by accident date, and the document that has to match a version of the contract nobody stored. Each of those is the same underlying problem in a different costume: the present is not enough information.

The question that separates someone who has done this from someone who has read about it is not "what is an endorsement" but "what does your system do when the endorsement is backdated past a paid claim".