Insurance software is dominated by two forces: products that must be configurable per state, per year and per channel, and data that must stay correct as of any date in the past.
Steady demand19 min readPolicy Administration Developer, Claims Systems Engineer, Guidewire / Duck Creek Configuration Developer, Insurance Business Analyst, Actuarial Systems AnalystUpdated 2026-07-27
Assumes you know: Relational data modelling and SQL, Comfort reading business rules and written specifications
Overview
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 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.
Subsection
What it is for
Policy Administration
The contract as a record, and the six transactions on it
Underwriting & Rating
Deciding to accept the risk, and pricing it
Claims Lifecycle
Testing the promise, from notification to closure
Insurance Fraud
Finding the applications and claims that are not honest
Actuarial & Reserving
Estimating what the book will ultimately cost
Reinsurance
Passing risk on, and accounting for what comes back
Distribution & Channels
Where business comes from, and what it costs to get
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.
Transaction
What it does
Why it is awkward
Quote
Prices a proposed risk, no obligation
Must be reproducible exactly, after rates change
Bind
Accepts the risk; coverage attaches
Where an audit trail becomes legally required
Issue
Produces contract and documents
Document versions must match the terms in force
Endorse
Mid-term change: add a car, raise a limit
Effective from a date that may be in the past
Renew
New term, usually re-rated
Rates, forms and rules may all have moved
Cancel
Ends coverage early
Refund depends on date, method, jurisdiction
Four of the six are really about time, which is the theme of the whole domain.
Loading diagram…
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.
Loading diagram…
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:
Loading diagram…
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
Term
What it means, precisely
Written premium
Premium on policies bound in the period
Earned premium
The portion of that premium the period has consumed
Unearned premium
The rest, held as a liability until the term runs off
Case reserve
The estimate on one specific known claim
IBNR
Bulk reserve for losses incurred but not yet reported
Incurred loss
Payments made plus reserves still held
Loss ratio
Incurred loss divided by earned premium
Combined ratio
Loss ratio plus expense ratio; above 100 means underwriting loss
Exposure
The unit rating is applied to, such as a vehicle-year
Retention
The share of a risk the carrier keeps rather than cedes
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.
Structure
How it splits
Typically used for
Quota share
Fixed percentage of every premium and loss
New books, capital relief
Surplus share
Cedes only the part above a retained line
Varying sums insured
Per-risk excess
Reinsurer pays above a point on one claim
Large single losses
Catastrophe excess
Pays above a point on one event, across many claims
Storms, earthquakes
Facultative
Negotiated for one specific risk
Unusual or very large risks
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.
Role
Builds or specifies
What they need from you
Configuration developer
Builds, inside the platform
A product model that survives an upgrade
Integration engineer
Builds
Reliable message exchange with partners
Underwriter
Specifies
Referral rules that fire on the right files
Actuary
Specifies
Data cut by accident and development period
Adjuster
Operates
A claim file that shows the whole history
Business analyst
Specifies
The filing translated into unambiguous rules
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.
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".
-- 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 5002026-07-012027-07-012026-06-284471 liability 5002026-07-012026-07-012026-08-14-- closed off4471 liability 10002026-07-012027-07-012026-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.