Insurance Platform Interviews for Engineers and Architects

What it is

An insurance platform is the collection of systems that turns a described risk into a priced contract, keeps that contract correct as it changes, decides and pays what is owed when something goes wrong, and accounts for all of it in a form that can be reconstructed years later by somebody who was not there. Every clause is load-bearing. Pricing is regulated in many markets, so a price is an artefact with a version and a provenance rather than a number in a table. Contracts change retroactively as a matter of routine, so the record needs two independent timelines. The payment obligation is recognised in the accounts before anybody knows its size, so an estimate is a financial statement rather than a note. And reconstruction is not an audit courtesy: it decides how the data is modelled, because a design that cannot reproduce what it believed on a past date has destroyed information no later effort recovers.

The estate usually holds a quote and rating service, a policy administration system owning the contract and its financial transactions, a claims system owning the loss and its money, billing and collections, a reinsurance cession engine, a fraud layer, actuarial and finance data platforms, and integrations to intermediaries, industry databases, payment providers, data vendors and reinsurers. Those components sit on one path, which is the territory this page covers.

flowchart LR
    accDescr: The insurance value chain as a loop, from quote and rate through bind and inception, in force with mid-term changes, claim notified and assessed, reserves and payments, cession and recovery, and reserving and ultimate cost, which feeds the next rate version and returns to quoting.
    A[Quote and rate] --> B[Bind and cover incepts]
    B --> C[In force with mid-term changes]
    C --> D[Claim notified and assessed]
    D --> E[Reserves and payments]
    E --> F[Cession and recovery]
    F --> G[Reserving and ultimate cost]
    G --> H[Next rate version]
    H --> A

Look at the last edge rather than the first. The path is a loop, and the return leg is the one candidates most often fail to see: what claims eventually cost is what sets next year's price, so a reserving figure produced by a claims system is a pricing input, and a claims data model that cannot support the reserving view has quietly broken the pricing of the product. Almost every hard question in this domain sits on that return leg or on one of the branches out of it.

What makes the domain hard is not volume. Personal lines motor at national scale is not web-scale by the standards of an advertising exchange, and a large carrier's claims table is smaller than a mid-sized retailer's order table. The difficulty is that most instincts that serve you well elsewhere are wrong here. Overwriting a row is the ordinary way to record a change, and it is the single operation that destroys the series a reserving actuary needs. Treating a price as configuration is normal, and in a filed market a price is a regulated artefact with an effective date somebody else agreed. Netting two related amounts is tidy, and it removes the gross cost the product's pricing depends on. Deleting an unpaid order is obviously right, and deleting an unpaid policy asserts a legal position the insurer does not hold.

An insurance platform interview is therefore a domain interview wearing engineering clothes. You will be asked to design things, and the design questions have right and wrong answers that come from the contract and the regulation rather than from the architecture literature. The candidates who do badly are rarely the ones with weak engineering. They are the ones who model the domain as e-commerce with a longer fulfilment window.

Why we need it

The domain-interview space is dominated by two kinds of content and neither is written for the person in this interview. The first is job-board filler: insurance terms with one-line definitions, assembled for search traffic rather than for comprehension, which survives a vocabulary check and abandons you the moment a question has a second clause. The second is testing and business-analysis material, genuinely useful for its own audience, describing the domain from outside the system: what a policy administration system does, what screens exist, what a tester should verify. Neither explains why a policy record needs two timelines, why a payment reduces a reserve without changing incurred cost, or why the loss timestamp is the most financially significant field in a catastrophe claim.

That matters because these interviews are unusually scenario-driven, and the scenarios are drawn from things that went wrong at the interviewer's employer. A broker wants a change backdated three months. A card payment fails the morning after cover was bought. Four thousand claims arrive from one storm and somebody must decide whether that is one event. A fraud score holds up an honest claim from a customer of eleven years. These are not hypotheticals invented to test reasoning in the abstract; they are last quarter's incidents, and the interviewer already knows which answers survive contact with the real thing.

There is a career reason too. Insurance rewards domain fluency more than most sectors because the constraints are external and permanent. A rating architect who understands filing is not replaceable by a generalist who is faster at Kubernetes, because the filing constraint does not disappear when the platform is modernised. The same holds for reserving data, cession logic and the conduct rules bounding automated decisions, and that fluency transfers between carriers in a way that familiarity with one company's systems does not.

The policy lifecycle is a sequence of contracts, not a status field

Quote, bind, endorse, renew, cancel is nearly useless as a recited list, because the content is in what each transition does to the contract, to the money and to the outside world. The reframing that pays for itself: a policy is not a record with a status. It is a policy term, which is one contract, carrying an ordered sequence of transactions, each with its own effective date and its own recorded date.

stateDiagram-v2
    accDescr: Policy states from quoted to on risk once bound and inception is reached, mid-term adjustments looping on risk, notice served moving to pending cancellation, which returns to on risk if premium arrives in time and becomes cancelled once the effective date passes, cancellation reversible only where the insurer agrees reinstatement terms, and on risk passing to the next term at renewal.
    [*] --> Quoted
    Quoted --> OnRisk: bound and inception reached
    OnRisk --> OnRisk: mid-term adjustment
    OnRisk --> PendingCancellation: notice served
    PendingCancellation --> OnRisk: premium received in time
    PendingCancellation --> Cancelled: effective date passes
    Cancelled --> Reinstated: insurer agrees terms
    OnRisk --> NextTerm: renewal incepts

Three transitions in that machine are where the real work is. The self-transition on the in-force state is a mid-term adjustment, which is not a state change at all but a new dated transaction against the same contract, frequently effective before the date it was recorded. Pending cancellation is a state most designs omit, and omitting it forces a system to treat a customer who is covered as though they were not. And the reinstatement edge is a decision rather than a side effect, because putting a cancelled policy back either grants cover retrospectively over a period the customer has already lived through or leaves a real gap in their cover history. A lapse at renewal for non-payment has the same shape as the cancellation path with a different trigger, and the transition into the next term is a new contract rather than a continuation.

Quote

A quote is an offer on stated terms at a stated price, valid for a stated period. It is priced against a specific version of the rating algorithm and its tables, selected by the intended inception date rather than by the date the quote was produced, because the rate that matters is the one in force when cover attaches. It carries a snapshot of the inputs that produced it, including external data fetched, because reproducing the price by re-running the engine drifts the moment reference data is rebanded or a vendor changes an answer. And it is a promise in the customer's understanding and often in the regulator's.

The reproducibility requirement shapes the design, and designing a rating engine with reproducible quotes works it through. Keep a factor-by-factor step trace, because a single premium figure cannot answer the only question anybody asks about a price, which is why it moved.

Bind

Bind is the moment the insurer accepts the risk and a contract exists, with an inception date and time stated in it. It is not the moment money arrives. A great many defective designs come from the instinct that a policy is provisional until payment clears and can be removed quietly if it does not, which is examined directly in bought cover last night, payment failed today. Cover incepted; the failed payment is a breach of the obligation to pay; the remedy runs forwards from a notice date. Narrow exceptions exist where the wording makes first premium a condition precedent, and knowing those are properties of the wording rather than of the payment integration is the distinction being tested.

Bind is also where fan-out begins, and fan-out is where most policy administration engineering lives. Documents are issued, in some classes the cover is reported to a central register, an intermediary is notified and commission accrues, and the risk enters the aggregate that gets ceded. Each has to be revisitable when the policy later changes, and none can be revisited by editing a row, because somebody outside your system has already acted on what you told them.

Endorse

An endorsement, called a mid-term adjustment in UK personal lines, changes the contract inside its term, and its effective date is frequently in the past. Backdating is ordinary rather than exceptional: brokers report late, customers remember late, and the underlying fact was true from a date already gone. Hence two clocks, business time for the span over which a fact is true of the risk and system time for the instant you learned it, and an append-only model. The bitemporal policy model for backdated endorsements sets out the storage shape, and the test that separates a real design from a plausible one is whether it can regenerate a document you issued before the backdated change arrived, including the error it contained.

Recalculation is harder than storage. A backdated change alters the rated premium for the whole term, so the additional premium you charged for a later endorsement was computed against a base that no longer exists. Either replay the chain from the earliest affected effective date and restate everything after it, or take the position that earlier transactions are financially closed and price only the increment forward. Both are defensible and different insurers do both; having no explicit rule is not defensible, because then the premium the system holds depends on the order in which changes happened to be keyed. The reason this bites is that the financial transactions have already left the building: premium written, commission accrued to the broker, tax recognised, instalments collected. Restating that requires reversal and re-issue entries dated in system time even though they concern business time in the past.

The related failure is the out-of-sequence read. If the current-state view is "the most recently recorded version wins", a backdated change silently overwrites a later-effective one that was recorded earlier. Ordering must be by effective date within the fold, with recorded time used only for tie-breaks and for the system-time filter. And an endorsement cannot cross a renewal, because a renewal is a new contract with its own rates and possibly a different insurer on the risk. A change spanning the boundary is two transactions.

Renew

Renewal surprises people who expect a subscription rollover. It is a new contract with a new term, re-rated under whatever is filed and effective at the new inception date, subject to whatever the appetite now is. The policy in force keeps its price until its term ends, which is why a rate change applies to new and renewing business from its effective date and not to policies already in force.

Renewal is also the most heavily regulated moment in personal lines in several markets, because it is where the customer is least attentive and the information asymmetry largest. In the UK the FCA's general insurance pricing practices rules require that a renewing customer is not offered a price higher than an equivalent new customer would be quoted through the same channel, which constrains the price rather than the model and has to be demonstrable rather than asserted. Architecturally renewal is a batch process with a real-time exception path, and the interesting work is in invitation lead times, re-rating a book against a version that may not be approved everywhere, and handling risks the appetite no longer covers.

Cancel

Cancellation is a transaction with an effective date, not a status flag, and the money is genuinely difficult. The refund depends first on who cancelled and why, because that decides whether the basis is pro rata or short rate, and the basis sits in the filed wording rather than in the system. The arithmetic is the last and smallest step, which is the argument of cancelling mid-term and computing the return premium.

Premium is also not the whole invoice, and the components behave differently. Policy fees are frequently fully earned at inception and not returned. Taxes and levies follow the premium, so tax computed on the returned amount has to be returned too and reported in the period the return happened, which is why finance cares about the accounting date rather than only the effective date. Instalment charges already applied are generally kept, and commission is clawed back in proportion, which is its own reconciliation with a third party. So a refund is a set of postings against several accounts rather than one number, and a design that stores a single premium figure on the policy and computes a percentage of it will be wrong on the first product that has a fee.

Two further complications decide the design. On some products a paid claim means no return premium at all, so the calculation has to see claim history and not only the policy. And where the policy was endorsed, premium is a sequence of amounts each valid for a period, so the unearned calculation runs over segments; a system that overwrote premium on endorsement cannot compute the figure at all. Rounding is not a detail either: money arithmetic here is integer minor units with a stated rounding rule applied at a stated step, because a filed algorithm specifies the order of operations, and a penny of drift across a large book is a deviation from the filed method that never reconciles.

Rating: the price is a regulated artefact

A rating engine executes an ordered sequence: a base rate for the product and coverage, a relativity per rating factor, then adjustments that are not factors at all such as minimum premium, optional cover charges, discounts and loadings, and finally taxes and levies calculated on premium but not themselves premium. That order is a specification rather than an implementation detail, because whether a discount applies before or after a term factor changes the last penny, and across a book that is a deviation from what was filed.

Algorithm and data have different cadences

The separation that makes rating tractable is between the algorithm, which is code and changes rarely, and the rate data, which is thousands of numbers and changes constantly. Put rate values in code and every price change becomes a release, which makes the pricing roadmap hostage to yours. A third category gets forgotten and causes most irreproducibility incidents: the mapping from what the customer told you to what the tables are keyed on. A customer gives a postcode and a date of birth; rating uses a rating area and an age band. Rebanding that mapping changes prices without any rate value changing anywhere.

A rate change is a filing, not a deploy

In personal lines in much of the world, and in the United States state by state, the algorithm and its tables are filed with a regulator before use. Three consequences follow, and they are the substance of a rate change is a filing, not a deploy. The change is per jurisdiction, so one algorithm is really many sharing a skeleton, each with its own approved values and effective date. The effective date is not the deployment date. And it applies to business written from that date, not to policies in force.

Rates are therefore never overwritten. Every table is a set of versions with validity periods and a filing reference, and a quote selects the version effective for the policy's own dates. Selecting on the current date is the single most common implementation bug in this area, and it produces quotes that silently reprice depending on when somebody opened them. Testing is a replay rather than a unit test: a growing corpus of historical quotes with known outputs, re-run against every build, because rate components are shared across products and a change aimed at one moves the price of another without erroring. The general statutory standard in US rate regulation is that a rate must be neither excessive, inadequate nor unfairly discriminatory, and that formulation explains most of the machinery: reproducibility demonstrates the filed algorithm was used, and documented factor definitions demonstrate that the discrimination in the rate is the permitted kind.

What has to be true before a new data source enters a price

Pricing conversations open on predictive power, which is the cheapest thing to establish and the least likely reason the project fails. The ordering that survives scrutiny, set out in putting a new data source into the price, is that the data must be obtainable, at the right moment, for a known share of risks, in a form you can stand behind, before anybody asks what it is worth.

Availability at quote is a commercial constraint disguised as a latency requirement. Coverage is the harder half: vendors match on identifiers and matching fails, so you need the match rate against your own book rather than the vendor's universe, and a decision about what you charge a risk the vendor cannot match. That default is itself a rate, and a visible gap between it and the matched price is an arbitrage somebody will find.

Point-in-time history is the constraint that quietly invalidates most business cases. Knowing what a factor is worth means attaching it to policies you already wrote and observing the losses that followed, which needs the value the vendor would have returned at the time of quote rather than the value they hold today. Where the data is a snapshot of something that changes, today's value has partly been shaped by the outcome you are trying to predict: a claim you paid may have caused the value you are now using to predict it. The result is a spectacular backtest and a live model that does nothing, discovered after the factor has been filed and the rate change taken. Where a point-in-time extract genuinely cannot be supplied, the honest fallback is a forward test in shadow mode, storing the value returned at every quote alongside the quote and waiting for the experience.

Two further constraints separate a senior answer. Incremental lift over the factors already in the model, on the risks you actually write, is the only lift that means anything, because your book is already selected and much of any external signal is already in your rate through postcode, age, vehicle group or tenure. And once the factor is filed, the vendor holds a lever on your pricing: if they recalibrate their score, extend their reference file or change their matching logic, your premium distribution moves with no change on your side and no filing, and the first evidence is a conversion shift somebody has to trace back to a supplier release note. Version the vendor's output as part of the rate version, monitor the distribution of returned values rather than only the error rate, because a recalibration is a successful response with different numbers in it, and decide in advance what happens to a filed rate when the data contract ends.

The inputs available to a rate are worth comparing on both axes at once, because the conversation in an interview usually treats them as though only the first column existed.

Read down the right-hand column rather than the left. The ranking of these inputs by predictive power is roughly the reverse of their ranking by how easily you can defend them, which is why the order in which you assess a new source matters more than the assessment of any one of them.

Where a statistical model sits

A generalised linear model, or increasingly a gradient-boosted model, does not replace the rating structure. It estimates expected cost, usually decomposed into frequency and severity, and enters the structure as a technical price. Above it sits a commercial layer: expenses, commission, cost of capital, target loss ratio, competitive position, renewal treatment. Keeping that gap visible as its own step is what lets anyone distinguish a segment that is unprofitable because the model is wrong from one where the market forced the price down. Both the filing constraint and the conduct rules push the same way: the model output should be a versioned, auditable, separately identifiable component rather than smeared across factor tables where nobody can explain it.

Underwriting rules answer a different question from rating

Rating asks how much; underwriting asks whether, and on what terms. The rules divide into eligibility rules that decline, referral rules that route to a human before bind, and rules attaching a condition, an increased excess or an exclusion. They belong in a separate evaluation from the premium calculation and should emit decisions rather than mutate the price; where a rule must affect price it adds a named loading that appears in the trace.

Two things go wrong when that boundary is soft. The premium becomes unexplainable, because part of it came from something nobody thinks of as pricing, which defeats the complaints handler and the examiner alike. And the referral queue becomes unmanageable, because nobody can measure an individual rule's referral rate when rules and rating are tangled together. Instrument every rule with its own hit rate on the day it ships; that number is what lets underwriting management decide which rules earn their keep, and it is the only basis on which a referral rate can be reduced without guessing.

Delegated authority is the same problem at portfolio scale. A managing general agent, or a coverholder in the Lloyd's market, binds on the insurer's behalf within an agreed appetite, so the insurer is on risk for policies it did not price and did not see. That is why delegated authority carries audit rights, appetite constraints written into the binding agreement, and bordereau reporting as the mechanism by which the insurer discovers what it is on risk for.

Distribution: the same risk arriving repeatedly

The parties and the money are covered in distribution channels and commission settlement, and the organising distinction is agency: a broker acts for the customer, an agent for the insurer, and the direction of that duty determines who owes suitability advice, who holds the data, who the customer complains to and whose money the premium is in transit. Commission is not an attribute of a policy but a stream of transactions each caused by a premium transaction, which is why a return premium produces negative commission automatically and clawback needs no special case. The commissionable base excludes taxes and levies, and getting that base wrong is the commonest cause of a broker statement dispute. Settlement shape matters too: under gross settlement the intermediary remits the full premium and you pay commission back, while under net settlement the broker deducts commission first, so nothing arrives that can be matched against a gross figure and reconciliation is against a running statement of account instead.

The channel that changes the architecture most is the aggregator. The customer describes the risk once to the comparison site, which fans it out to a panel and ranks by price; you are one of the answers, your brand is invisible until a number has been chosen, and the customer can re-run the exercise as often as they like at no cost. Repeated presentation is therefore normal channel behaviour rather than an anomaly to filter out, which is where the same risk five times in one day begins.

Three consequences follow, and reaching the third marks a strong candidate. Identity has to be built probabilistically, because the whole point is that something differs each time; the stable signals are the ones the customer is not editing, and what you want to record is precisely which fields were edited and in which direction the premium moved. The response window is a revenue constraint rather than a performance target, because missing it removes you from the panel with no degraded appearance and no retry, which is why enrichment in this channel runs in parallel behind a hard deadline with a deliberately cautious assumption standing in for anything that has not returned, and why the quote has to record which enrichments contributed. And the edits are price probing: whichever insurer is softest on the edited factor becomes the cheapest quote and wins the risk, so the channel systematically fills your book with the risks you most underprice, described in the most flattering terms the customer could construct. That is structural anti-selection, and it is why aggregator business is priced and reserved as its own segment.

Claims: the money moves before anybody knows the amount

The lifecycle runs from first notification of loss through coverage verification, adjudication, payment, recovery and closure, and the claim lifecycle from FNOL to closure walks it end to end. The field to capture accurately above almost all others at notification is the date of loss, because it determines which policy term and which terms of cover govern the claim; a claim notified today for a loss eight months ago is covered and adjudicated under the contract as it stood then, and today's version of the policy is relevant only as a source of error. Claims are set up as features, one per head of loss, because vehicle damage resolves in weeks against a repair estimate while bodily injury can stay open for years.

The reserve is recognised money

When a claim is notified the insurer becomes liable for something whose amount is unknown, and accounting does not permit waiting. The estimate is recognised now, flows into the period's reported result, and appears in regulatory returns, which is the point of setting a reserve before anybody knows the cost. The identity to have at your fingertips is that incurred equals paid to date plus outstanding reserve, and the consequence people get wrong under pressure is that a payment reduces outstanding and raises paid by the same amount, leaving incurred unchanged, because paying from a reserve is a liability converting into cash rather than a new cost.

The first figure is deliberately a placeholder, typically an average by claim type, because a zero reserve understates the liability and a speculative large figure distorts the period it lands in. What matters is that the move from formula reserve to adjuster assessment is itself an event worth recording, because a reserve that moved because somebody finally read the file is a different thing from one that moved because the claim got worse.

Movements are therefore transactions with reason codes: information arrival, prognosis change, litigation, severity drift, coverage or liability reassessment. Indemnity stays separate from handling expense, because a long liability claim can run substantial legal cost while indemnity stays flat and treaties often treat the two differently. Case reserves exist only for known claims; the bulk provision for claims that have occurred and not been reported is IBNR, an aggregate estimate over a cohort rather than anything a claims system holds per claim. Closure is a state rather than an ending, and reopening is a new dated movement that leaves the prior history intact.

Subrogation, salvage and the excess that is not yours

You paid in full and it was the other driver's fault is the best single test of whether a candidate understands claims money. You indemnify first, unconditionally, and in doing so acquire the insured's right to recover. A system that waits for the recovery before recognising the payment is a debt-collection system with a policy attached.

Four flows then run against one file: indemnity paid, handling expense, subrogation recovery, and salvage proceeds net of disposal costs where you paid for a total loss and the item is now yours. Collapsing them into a net cost answers the accounting question and destroys the gross figure the actuary prices on. Before the money arrives an anticipated recovery is a receivable with credit and collection risk, held as its own asset with its own ageing rather than netted off the reserve, because reducing the reserve asserts the loss cost less while holding an asset asserts a third party owes you money. If the at-fault party turns out to be uninsured, only the second of those statements was wrong.

The allocation is where a well-built system separates itself, because a recovery is not one number credited to a ledger but a set of amounts owed to different parties in a priority order.

The row that decides whether the design is real is the second. A partial settlement is an allocation against that order rather than a proportional split, the order itself varies by wording and jurisdiction, and a system that posts a recovery as a single credit cannot express it at all. Note also that the recovery leaves the claim: the cession is restated in the proportions the original payment was allocated in, and the transaction carries the accident date it belongs to as well as the date it arrived, or the triangles show cost falling in a period where nothing happened.

Reserving, triangles and the loop back into rates

Engineers get pulled into actuarial work because the actuarial team cannot use what the reporting warehouse produces, and the reason is structural rather than a missing column. Reporting answers what is true now and achieves that by overwriting; reserving needs the value as it stood at each past valuation date. Why the actuary cannot use your reporting tables diagnoses that, and loss development triangles and actuarial data needs gives the mechanism.

A triangle has cohorts down the side, grouped by the period the loss belongs to, and development periods across the top measuring how long after that period the observation was taken; each cell holds the cumulative paid or incurred figure for that cohort as at that point. Recent cohorts have not lived long enough to fill the later columns, and the exercise is projecting those blanks from the completed rows, classically by chain ladder. Read one cell and the data model falls out: the 2023 row at development twenty-four months is the incurred figure for 2023 accident-year claims as at the end of 2024, not as at today. Build it from current figures and you get today's number in every column, the development pattern flattens, the factors are meaningless, the totals still reconcile and no test catches it.

There are two correct ways to make that available and mature shops use both. Periodic snapshots physically store the figures for every open and recently closed claim at each valuation date and are never touched again, which is simple, obviously correct, and unremarkable in storage terms because claim counts are not web-scale. A movement store records every payment and reserve movement as an immutable row carrying both an effective date and a booked date, and derives any as-at view by summing movements up to that point, which is more flexible because the actuary can evaluate at any date rather than only the ones somebody thought to snapshot. They combine well, with movements as the source of truth and snapshots materialised from them so the actuarial run is not recomputing the world. What does not work is reconstructing from a database audit log, for reasons the questions below go into.

Which date defines the cohort has to be established before anything is built, because a single claim sits in a different bucket under each of them and they routinely differ by years.

The last row is the one that catches engineers, because treaties attach by the year the policy was written while claims arrive by accident date, so a single payment can be split across structures negotiated years apart. Your model does not choose between these; it stores the underlying dates and lets the cohort basis be a query decision, because an engineer who bakes one basis into a warehouse table has removed the actuary's ability to look at the book the other way round.

How reserves feed next year's rates follows the loop back into pricing, and the awkward step is between the reserve review and the experience by segment: the review produces figures for a whole class of business, and a rate indication needs them broken down far further than the review ever computed them. Premium has to be brought to today's rate level as well, because historical earned premium was collected at whatever was filed then, so a rising loss ratio can mean a deteriorating book or three years of rate reductions. That on-levelling is a re-run if your platform can replay historical quotes against a chosen rate version, and a spreadsheet somebody maintains by hand if the only artefact of a past rate change is a deployment.

Reinsurance and catastrophe aggregation

Reinsurance is cession logic running over policy and claim data to produce amounts a third party owes you, and the two axes people collapse into one are how cover is agreed and how it responds. A treaty covers a defined class of business so every qualifying risk written in the period is reinsured automatically; facultative cover is arranged for one named risk, offered and accepted individually. Independently of that, cover may be proportional, taking an agreed share of premium and losses, or non-proportional, paying above a retention up to a limit. Treaty versus facultative reinsurance in systems works through both axes and the data model they imply, including why ceded and net figures are stored transactions rather than views derived from the current treaty configuration.

The claim-side arithmetic has two traps, set out in one claim payment split across treaties years apart. An excess layer attaches on the claim's cumulative total rather than on the payment in front of you, so each payment's cession is the difference between the cumulative recoverable before and after; compute per payment in isolation and you cede either nothing or everything, and the error only surfaces on claims crossing an attachment point. And inuring order, meaning which structure applies first, is a contract term rather than a default, because applying an excess layer before or after a quota share gives different net results. The recoverable is an asset carrying the reinsurer's credit risk rather than a discount on the claim, which is why gross remains the figure the actuary reserves on, why a disputed or uncollectable recoverable is a bad debt, and why exposure has to be reportable per counterparty rather than only in total.

Catastrophe cover is different in kind, and four thousand claims, is that one event is the sharpest scenario in the section. Per-risk cover has a claim as its unit of account and each claim is assessed independently. Catastrophe cover has an occurrence as its unit of account, meaning the aggregate of many claims across many policies arising from one thing happening, whose membership is unknown when any of them is notified, whose boundary is contractual rather than meteorological, and which keeps growing for months. The treaty defines the occurrence by clock, typically as all losses from the same peril within a stated number of consecutive hours, and the cedant normally elects where the window begins.

Deciding whether a set of claims is one occurrence is a series of contractual tests, each of which needs a field the claims system captured under pressure at first notification.

The fourth row is the one that makes this an engineering problem rather than a reinsurance one. Candidate windows have to be enumerated from real timestamps before anybody can choose between them, and a system storing only a loss date to the day cannot enumerate them at all. Two further points follow. The election is a computation rather than a rule of thumb, because one large occurrence deducts a single retention while two smaller ones may each sit comfortably inside a layer, and reinstating a consumed layer costs a premium that has to be netted against the extra recovery. And the grouping changes as the event develops, long after cessions were reported and periods closed, so the cession must be a restatable derivation over immutable transactions with the event assignment held as a separate versioned decision.

Fraud: ranking a queue rather than gating a payment

Fraud splits into two problems sharing a word, separated in detecting insurance fraud at claim and application. Application fraud is misrepresentation of the risk before any loss: fronting, where the declared main driver is a parent and the real one is the teenage son; an address in a cheaper rating area; undisclosed claims or convictions; and the organised variant of ghost broking, where somebody sells policies obtained by falsifying applications and the customer often does not know their cover is void. It is caught inside a quote flow with a latency budget in hundreds of milliseconds, against externally verifiable data and against your own quote logs, where the same broad risk re-quoted with the date of birth or occupation shuffled until the price drops is among the most reliable signals you own outright. Claim fraud is a false or inflated claim against genuine cover, caught over days rather than milliseconds, on behavioural and relational evidence rather than anything checkable against a register.

Organised claim fraud is a graph problem and per-claim scoring is systematically bad at it, because each individual claim in a well-run ring looks acceptable and what is unusual is the pattern of connections between people, addresses, phone numbers, bank accounts, vehicles, repairers, clinics and solicitors. Entity resolution decides whether that works, and it fails in both directions: too conservative and the ring never appears as one structure, too aggressive and everybody in a large block of flats collapses into a single node and the graph becomes a hairball of false structure. Keep matching decisions auditable and prefer explicit possible-match edges over silent merging.

The label problem is the part most candidates miss: you have outcomes only for cases somebody investigated, and those were selected by the rules you are trying to improve on, so training on them reproduces the blind spot and hides it from every offline metric. Reserve a fraction of investigator capacity for randomly sampled referrals, and never let "investigated and found clean" collapse into "not investigated".

The architectural point is in a fraud hold on an eleven-year customer: a score orders a queue and must not sit anywhere a payment cannot proceed without it clearing. Wire it that way and the threshold becomes capacity allocation rather than a statistic, and the decision to delay a payment becomes a separate, human, recorded act with its own justification. That is what makes it defensible, because a design where the model output is the reason for a delay has put an unexplainable artefact in the causal chain of a decision the insurer is obliged to explain.

Regulatory and conduct constraints on automated decisions

This is where engineers most often answer confidently and wrongly, usually by treating compliance as a logging requirement. The constraints bite on the decision, and four families are worth distinguishing.

Prudential regulation governs capital and reserves. In the EU and UK, Solvency II frames technical provisions, capital requirements and governance, and IFRS 17 governs how insurance contracts are measured and presented. Engineers meet these as data requirements: figures reconstructible at valuation dates, movements explicable, and the distinction between an accounting date and an effective date treated as real.

Rate and product regulation governs the price. Filed markets require the algorithm and its factors to be filed or approved before use, against the general standard that rates be neither excessive, inadequate nor unfairly discriminatory. Some jurisdictions prohibit specific characteristics as rating factors, and where they do, a proxy is generally treated no more favourably than the characteristic itself. That is why external composite scores carry particular exposure: a score whose construction the vendor treats as proprietary may carry signal you are not permitted to use, and you cannot rule that out by inspection. Several US states now require insurers using external data and predictive models to test for unfairly discriminatory outcomes and describe what their inputs measure.

Conduct regulation governs treatment of customers: the pricing practices rules constraining renewal pricing, obligations to handle claims promptly and fairly, and in the UK the FCA's Consumer Duty, which frames outcomes rather than prescribing steps. Non-disclosure has a statutory shape too. For consumers, the Consumer Insurance (Disclosure and Representations) Act 2012 replaced the old duty of disclosure with a duty to take reasonable care not to make a misrepresentation, with proportionate remedies depending on whether a misrepresentation was deliberate or reckless rather than careless; the Insurance Act 2015 does something comparable for non-consumer insurance through a duty of fair presentation. The systems consequence is concrete: a design that can only void a policy or pay in full cannot express the proportionate remedy the law expects, and a platform that cannot record what the customer was asked and what they answered cannot establish materiality at all.

Data protection and AI regulation govern the automation. The GDPR restricts decisions based solely on automated processing that produce legal effects or similarly significantly affect a person, and provides for human intervention and contestability, which constrains a fully automated declinature or repudiation directly. It also requires personal data to be adequate and relevant to the purpose, a real limit on collecting external attributes because they improve a score. The EU AI Act classifies AI systems used for risk assessment and pricing in relation to natural persons in life and health insurance as high risk, bringing obligations on risk management, data governance, documentation, logging and human oversight. Interviewers do not expect clause-level recitation. What they expect is that you know the constraint lands on the decision, and that you can name the design consequences: a human in the loop where the decision is significant, a reason expressible to the customer in language that is not a model output, retained inputs and versions, and a route for a contested decision to reach somebody with authority to change it.

The unifying principle across all four families is that an automated system in insurance must be able to explain a past decision in the terms in which it was made. That is the same requirement as reproducing an eighteen-month-old quote, producing a triangle cell as at a past year end, and showing a reinsurer why the cession they were shown last quarter differs from today's figure. The domain keeps asking one question in different clothes, and every part of the platform has to be able to answer it.

What interviewers ask

These interviews run in a recognisable shape: a domain-fluency conversation, a scenario or two drawn from real incidents, a design exercise on rating or claims data, and at senior level a conversation about governance and stakeholders. Almost every question you will be asked is one of a small number of archetypes, and each archetype is grading one thing.

Reading the middle column tells you almost nothing about difficulty, which is the point. The vocabulary probe and the stakeholder conflict can both be failed in one sentence, and what follows expands on what each of those signals looks like in practice.

Whether your vocabulary is load-bearing. Anybody can define subrogation. The difference is whether you use the term to reach a consequence: that recovery is an asset rather than a reversal, that gross has to survive, that the insured's excess has priority on a partial recovery. Interviewers listen for the second clause, and a candidate who defines terms accurately and derives nothing from them reads as someone who revised a glossary.

What you ask before you answer. Scenario questions are deliberately underspecified because the real ones were. Who cancelled, and why? What does the wording say? Which jurisdiction, and is this consumer or commercial? Is the treaty risks-attaching or losses-occurring? Computing a refund before establishing who cancelled answers a different question, and the interviewer knows which. The signal is not curiosity for its own sake; it is whether you know which variables change the answer.

Whether you attribute rules to their source. Strong answers say the basis is set in the filed wording, the occurrence definition is a treaty term, the accounting treatment is finance's judgement rather than the engineer's. Weak answers make those decisions on the system's behalf. This predicts behaviour: an engineer who will invent a business rule under time pressure is a liability in a regulated estate.

Your treatment of history. Whether the ledger is append-only, effective date is separated from recorded date, a correction is a reversal and re-issue, a quote is pinned to the version that priced it, a cession is a restatable derivation. Interviewers converge here because it is the one property that cannot be retrofitted: everything else can be improved later, and destroyed history is gone.

Whether you follow the money out of the component you were handed. A claim payment changes the cession, lands in a development period, moves a loss ratio and may generate a recovery arriving after closure. A cancellation claws back commission, reverses tax in the period it happened, needs an end date on a register entry, and cannot recall documents already issued. Candidates who trace one full path are scored as architects; candidates who stay inside their component are scored as implementers.

Whether you can state what a number means before computing it. Incurred equals paid plus outstanding. A payment from a reserve leaves incurred unchanged. Gross is what the actuary reserves on and net is what the accounts report. Written premium is not earned premium. IBNR is an aggregate estimate, not a per-claim field. These are quick to check and highly diagnostic, and a wrong answer on the incurred identity is hard to recover from because everything downstream inherits it.

Whether you size an automated decision against the human capacity behind it. In fraud, referral rules and any model-driven queue, the question is how many cases the team can genuinely work in a day and whether the threshold fills that capacity or came off a validation curve. A candidate who optimises a metric without asking who consumes the output has designed something that will be switched off within a quarter, and the interviewer has usually watched that happen.

Whether you can name what you would refuse to automate. This is the senior discriminator in almost every insurance interview touching models. The good answer identifies decisions significant to the customer and hard to explain, connects them to the obligation to give reasons and provide human intervention, and proposes the legitimate automation instead: ranking, evidence gathering, triage, drafting the information request a handler will send. A candidate willing to automate a repudiation on the strength of a score has failed the question regardless of the rest of the answer.

At senior level, whether you can hold a position against a stakeholder. The domain is full of legitimate parties wanting incompatible things: the actuary needing immutable movement history, the claims director needing a fast handler screen, pricing wanting a change next Monday, finance needing the period closed. The architecture is largely a record of which of those arguments were won, and the signal is whether you can explain a constraint in the other party's terms rather than asserting it in yours.

Questions

Walk me through what happens between a customer seeing a price and being on cover.

The quote is an offer priced against a rate version selected by the intended inception date, with its inputs, the external data it fetched and a factor-by-factor trace stored alongside the premium. Underwriting rules have already established that the risk is eligible and needs no referral. Bind creates the contract with an inception date and time, and cover attaches at inception rather than on receipt of money, unless the wording makes first payment a condition precedent. Bind then fans out: documents issued, intermediary notified and commission accrued, tax recognised, the risk entered into the aggregate that gets ceded, and in some classes a report to a central register.

What the interviewer is listening for is that binding is contract formation with external consequences rather than a status change, and that everything in the fan-out has to be revisitable by appending a dated transaction rather than by editing what was already sent. Candidates who describe this as a checkout flow with a confirmation email have told you how they will model the cancellation that follows it.

A broker asks you to backdate a cover change to three months ago. How do you model the policy so that works?

Separate the date a change is effective from the date you learned about it, and store transactions rather than a mutable policy. Business time is the span over which a fact is true of the risk; system time is when your organisation recorded it. Transactions are append-only, carry both, and store a resolved snapshot so as-at reads are a lookup rather than an unbounded fold. Business-time queries answer what cover was in force, which claims adjudication needs; system-time queries answer what you believed on a date, which audit, complaints and disputed claims need and a single-timeline design cannot answer at all.

The recalculation gets probed harder than the storage. A backdated change alters the rated premium for the whole term, so additional premium charged for later endorsements was computed against a base that no longer exists. You need an explicit rule for whether earlier transactions are restated or treated as financially closed, and the ledger correction is reversal and re-issue rather than an in-place fix. Where the backdated change lands on a term against which a claim has already been adjudicated, it forces a human decision rather than a recalculation, because the cover applied to that claim may no longer be the cover the policy records.

A customer cancels a twelve-month policy after four months. How much do you refund?

Establish who cancelled and why before computing anything, because that decides the basis and the basis comes from the filed wording. A voluntary customer cancellation frequently attracts short rate, returning less than the unused proportion because acquisition cost is already incurred and risk is not evenly spread across the term. Insurer-initiated cancellation is normally pro rata, because penalising the customer for the insurer's decision is not defensible and in many jurisdictions not permitted. Cancellation inside a statutory cooling-off period typically attracts a full or near-full refund.

Then remember premium is not the whole invoice: policy fees are often fully earned, taxes follow the premium and must be returned and reported in the right period, instalment charges are usually kept, commission is clawed back in proportion. Pro rata is computed on days rather than months, and if the policy was endorsed the unearned calculation runs over premium segments rather than one figure.

A customer bought cover on your site last night and this morning the card payment failed. Are they on risk?

Yes, on the ordinary analysis. The contract formed when you accepted the risk and cover incepted on the date stated in it; the failed payment is a breach of the obligation to pay, not evidence that no cover existed. The remedy is cancellation for non-payment, which is dated, notified and forward-looking: notice served, the notice period taken from the wording and the jurisdiction, cover persisting throughout it, and cancellation effective from the stated date with premium due for the period on risk.

That needs a state beyond active and cancelled. Pending cancellation is materially different from both, because the customer is covered, a claim would be paid, the notice has been served, and payment received before the effective date stops the process. Name the exceptions without overreaching: some wordings make first payment a condition precedent, and that is a property of the product rather than of the payment integration. And say what premium finance does to the answer, because if a lender has already paid you the annual premium, a failed instalment is the lender's default rather than yours, the lender instructs the cancellation, and the unearned premium goes back to the lender rather than to the customer.

A loss occurs on day four of that unpaid window and is notified on day twenty. What do you pay?

The claim, on the terms in force at the date of loss. Cover was in force on day four, the customer's failure to pay does not retroactively remove it, and the unpaid premium becomes a debt you can set against the settlement or pursue separately. The same holds for a loss during the notice period, because the entire point of a notice period is that cover continues through it.

What changes is what happens afterwards rather than whether you pay. A claim on a policy whose premium never arrived is a recognisable pattern and a legitimate reason to verify, and verification is a different act from refusal. The rule the question exists to reach is that payment status must never be an input to the coverage decision. Wire the collections status into the claims decision and you have built a machine that issues unfounded declinatures automatically and then requires somebody to defend them, which they will not be able to do.

How would you build a rating engine, and how do you reproduce a quote you gave someone eighteen months ago?

Model the algorithm as an ordered sequence of steps over versioned rate tables, keep the tables in data with their own lifecycle so a price change is not a release, and treat the mapping from customer-supplied values to rating factors as versioned reference data, because rebanding a factor moves prices without any rate value changing.

Reproduction is not achieved by re-running the engine. Even with the right tables you have drifted: reference data rebanded, an enrichment provider answering differently for the same input, a rounding rule tidied. Store the input snapshot, the rate set identifier, the engine version, the external responses and a step-by-step trace of factors and running totals, and treat re-execution as verification. A published rate set is immutable, identified by an identifier and an effective date range, and corrections are new versions. Editing a published set to fix one cell makes every quote priced under it unexplainable, which is why it is the defect that destroys reproducibility most often.

The business wants to change a rating factor next Monday. Walk me through what has to happen.

Ask which jurisdictions it applies in, because in filed markets the algorithm is filed per state or market and a change may be approved in some and pending in others. Separate the effective date from the deployment date: the new rate applies to business written on or after a date the regulator agreed, and shipping early or late does not move it. It applies to new and renewing business from then, not to policies in force.

Implementation is a new version of the affected tables with a validity period and a filing reference, selected by the policy's effective date rather than the current date. Selecting on the current date is the standard bug and produces quotes that reprice depending on when somebody opened them. Outstanding quotes on the old version are normally honoured for their stated validity, which requires the quote to have stored the version and not only the number. Regression is a replay of a growing corpus of historical quotes, because rate components are shared and a change aimed at one product silently moves another.

The change is wrong and has been live for a day. What is the rollback?

There is no rollback in the deployment sense, because the quotes issued and policies bound at the wrong price are contracts. Reverting the code stops the bleeding and does nothing about what has happened.

What engineering has to provide, quickly and defensibly, is the exposure: every quote and policy priced under the bad version, identifiable because the version was recorded against each. Remediation is then a business decision made with compliance and usually with the regulator informed, and the options are honouring the prices, re-rating at renewal, or refunding the difference. The answer that scores is the list plus an explicit handover of the decision to the people whose decision it is.

Underwriting want to put a new external data source into the price. What has to be true before it goes near the rating algorithm?

Four things, and predictive power is the last. It has to be obtainable inside the quote window, which means accepting a latency tail, an availability figure below one, and a price per call. It has to cover a known share of your book, which means the match rate against your own population rather than the vendor's universe, and a decision about what you charge a risk the vendor cannot match, because that default is itself a rate and a visible gap between it and the matched price is an arbitrage somebody will find.

It has to be obtainable as it stood historically, dated to the quote date, or your backtest is measuring an outcome that partly caused the value you are predicting with; where a point-in-time extract is impossible the honest route is shadow mode. And it has to be describable in plain language and testable for concentration against characteristics you cannot price on, because a proxy for a prohibited characteristic is generally no more acceptable than the characteristic itself. Then version the vendor's output as part of the rate version, monitor the returned distribution rather than only the error rate, and settle in advance what happens to a filed rate when the data contract ends, because otherwise you re-file under time pressure with a default factor doing the work of a real one.

Where does a machine-learning model sit in a filed rating structure?

Upstream of it, as an identifiable component rather than a replacement. The model estimates expected cost, usually decomposed into claim frequency and claim severity, and that estimate enters the rating structure as a technical or risk price. Above it sits the commercial layer: expenses, commission, cost of capital, target loss ratio, competitive position and renewal treatment. Keeping that gap visible as its own step is what lets anybody distinguish a segment that is unprofitable because the model is wrong from one where the market forced the price down.

Two constraints shape how freely the model can drive the price, and naming them is what separates a machine-learning answer from an insurance one. In filed markets the structure and its factors are filed and approved before use, which limits both how the output can be used and how quickly it can change. And conduct and data-protection rules bear on decisions that significantly affect a person, which is a constraint on the decision rather than on the model. Both push the same way: versioned, auditable, separately identifiable output rather than relativities smeared across factor tables where nobody can see the model at all.

How would you test a rate change, given you cannot unit-test a premium into existence?

By replay. Maintain a corpus of historical quotes with their inputs and their known outputs, per jurisdiction and per rate version, and re-run every one against every build. The corpus grows rather than being replaced, because its purpose is to prove that old calculations still reproduce.

The failure it catches is specific and worth naming. Rating components are shared, so a territory table used by three products or a rounding helper used by all of them means a change aimed at one product moves the price of another. Nothing errors, nobody notices, and it surfaces as a filing audit finding or a customer complaint months later. Alongside the replay you want targeted checks on the new behaviour, a comparison of the premium distribution before and after against what the pricing team predicted, and a line-by-line reconciliation of the implemented steps against the filed algorithm, including the order of operations and the step at which rounding is applied.

A referral rule fires on twelve per cent of quotes and underwriting cannot cope. What do you change first?

Nothing, until you can see the rules individually. The first change is instrumentation: every rule reporting its own hit rate, its overlap with other rules, and the outcomes of the referrals it generated. Without that, any tightening is a guess.

With the data the question becomes which rules produce referrals the underwriter almost always waves through, because those are pure cost, and which produce the declinatures and amended terms that justify the queue. Rules that never change an outcome should be retired or converted into a note on the risk. Rules firing on a large population for a small effect can often be narrowed by combining conditions rather than moving one threshold. Underneath is a capacity argument: a queue nobody can clear stops being read, and the control stops existing.

The same risk comes back to you five times in one day through an aggregator, with slightly different answers each time. What does that do to your pipeline and your book?

Treat the five as one risk being re-presented rather than five prospects. Resolve them probabilistically on the signals the customer is not editing, keep every attempt, link them, and record what changed. That gives you a versioned risk to reason about instead of five unrelated quotes with five sets of enrichment calls.

The pipeline consequence is that the response window is a revenue constraint, since missing it removes you from the panel entirely, so enrichment runs in parallel behind a hard deadline with cautious assumptions for what has not returned, and the quote records which enrichments contributed. Quote-to-bind ratios in this channel are poor and every quote costs real money, so caching an enrichment against a resolved risk for a short defensible window is the largest lever available. The book consequence is the one to reach: the edits are price probing, whichever insurer is softest on the edited factor wins the risk, and the channel fills with the risks you most underprice in the most flattering available terms.

Walk me through a claim from first notification to closure, and tell me what the reserve is doing at each stage.

At notification you capture the date of loss above almost everything else, because it decides which term and which terms of cover govern, and you set up features for the separate heads of loss because they develop on different clocks. The initial reserve is usually a formula figure from an average by claim type, carrying almost no information about this claim. Coverage review asks whether the policy in force at the date of loss responds; adjudication decides quantum against limits, sub-limits and the excess. The reserve moves as information arrives, each movement a dated transaction with a reason code rather than an updated field.

Payments go out against a specific feature, often to a payee who is not the insured, and reduce outstanding while raising paid, leaving incurred unchanged. Closure happens when outstanding is zero and nothing is pending, and it is a state rather than an ending, because injury and latent-defect claims reopen and the reopening is a new movement that leaves prior history intact.

A claim is notified and nobody yet knows what it will cost. Why does the system have to put a number on it immediately?

Because the liability exists now and accounting does not permit waiting for certainty. The case reserve is a recognised estimate of what remains to be paid, it flows into the period's reported result, and it appears in regulatory returns. Treating it as an editable field on a claim record misunderstands what it is: a figure that moves the company's profit and will be examined.

The number is expected to move, and the movements are the object of interest rather than the current value. Store them as transactions with reasons, distinguish a move caused by somebody finally reading the file from a move caused by the claim getting worse, keep indemnity separate from handling expense because they behave differently and are managed differently, and remember case reserves cover only known claims. The provision for claims occurred and not reported is IBNR, an aggregate estimate over a cohort, and a report summing only case reserves understates the liability on any line with a reporting delay.

You have paid your policyholder in full and the accident was the other driver's fault. What does your claims system now have to do?

Recognise that you have acquired the insured's right to recover and pursue the third party in their place, while keeping the payment and the recovery as separate transactions against the same file. The claim carries at least four flows: indemnity paid, handling expense, subrogation recovery, and salvage proceeds net of disposal costs where you paid for a total loss and the item is now yours. Collapsing them into a net cost answers the accounting question and destroys the gross figure the actuary prices on.

Before the money arrives an anticipated recovery is a receivable with credit and collection risk, held as its own asset with its own ageing and its own write-off policy rather than netted off the case reserve. On a partial recovery the insured's uninsured excess commonly has priority, so allocation follows an order set by the wording and jurisdiction rather than splitting proportionally. The recovery also does not stay inside the claim: the cession is restated in the proportions the payment was allocated in, and the transaction carries the accident date it belongs to as well as the date received.

Say what happens at closure too. The cleaner model treats the recovery as its own long-lived object linked to the claim, with its own status and owner, so the claim can close on its own timetable while the pursuit continues, and closure must not discard the engineer's report, the liability admission and the payment record, because those are what make the recovery provable years later.

The recovery arrives two years later and covers seventy per cent of what you paid. How is it split between you and the insured?

Not proportionally. The right of recovery you inherited covers the insured's uninsured loss as well as your outlay, and the widely applied convention on a partial recovery is that the insured's excess is reimbursed before the insurer retains anything, subject to the wording and the jurisdiction. The excess goes back to the customer first and you retain the balance against what you paid, with your own recovery costs treated as the wording provides.

The design point is that this is an allocation against a priority order rather than a credit posted to a ledger, because the order differs by wording and by market, and because getting it wrong produces the most avoidable complaint in the domain: a customer who discovers you recovered from the other driver and kept their excess. Timing matters as much as the split. A recovery arriving two years on has to be attributable to the accident period it belongs to rather than the period the cash arrived in, or the triangles for that cohort show cost falling in a period where nothing happened, and where recoveries are material most insurers develop them as their own pattern because they run on a different clock from the losses.

What is a loss development triangle, and what does the actuary need from your claims system that reporting does not?

A triangle groups claims into cohorts by the period the loss belongs to, arranges observations by how long after that period the measurement was taken, and holds in each cell the cumulative paid or incurred figure for that cohort as at that point. Recent cohorts have not lived long enough to fill the later columns, and the exercise is projecting those blanks from the completed rows.

What reporting cannot supply is the figure as it stood at each past valuation date, because reporting overwrites in order to answer what is true now. So you need either physical snapshots taken at each valuation date and never touched, or an immutable movement store from which any as-at view is derived by summing movements up to a knowledge cut-off. You also need the underlying dates kept rather than one cohort basis baked in, because accident year, underwriting year and reporting year are needed by different exercises, and enough dimensional detail to cut homogeneous groups after the fact. Homogeneity matters more than people expect: a triangle mixing a short-tail property book with a long-tail liability book produces a development pattern that describes neither.

Why can you not rebuild that history from a database audit log?

Because an audit log records that a field changed rather than what business event occurred. It carries no reason code, no distinction between a strengthening on a medical report and the correction of a keying error, usually no accident-period context, and it is frequently pruned on a retention schedule set by somebody thinking about storage cost. Reconstructing a movement history from it means inferring business meaning from field diffs, and that inference is unverifiable at precisely the moment the numbers are being challenged.

There is a stronger version of the objection worth reaching. Even a perfect log gives you the sequence of states, not the accounting dates on which those states were recognised, and reserving needs the knowledge cut-off rather than the change timestamp. Programmes discover this at the point of needing the data, which is the worst possible moment, because the information was destroyed years earlier by a design decision nobody recorded as a decision.

How does the reserve figure your systems produce end up changing next year's rates, and where does that loop break?

Reserving estimates what business already written will ultimately cost; pricing needs that cost attributed back to the characteristics that were rated. The loop is the actuarial control cycle: rates set, business written, claims develop, ultimate cost estimated, experience compared with premium charged, rates move.

It breaks in three predictable places. Reserving groups losses by accident period and pricing needs policy period, so accident-period losses against written premium produce a loss ratio containing no rate change at all. Historical premium was collected at rates nobody charges any more, so it has to be brought to current level, which is a re-run if you can replay quotes against a chosen rate version and a hand-maintained spreadsheet otherwise. And the most recent period always looks most profitable because incurred-to-date is a fraction of ultimate, which is how a rate cut gets argued for on business whose losses have not arrived. The defence is procedural: no period cost published without its development stage attached, and pricing consuming ultimates rather than incurred-to-date.

A fourth break is worth volunteering. IBNR is an aggregate estimate held for a reserving segment, and a pricing model wants cost at the level of the factors it is fitting, so somebody has to allocate an aggregate down into cells. Allocating in proportion to case incurred pulls the estimate towards whichever cells reported early; allocating in proportion to exposure ignores that some segments genuinely develop more slowly. Whichever basis is chosen has to be recorded as data rather than performed inside a workbook, or nobody can explain a year later why one segment's indicated rate moved.

A single very large loss dominates one segment's experience. What do you do with it?

On the reserving side, analyse it separately from the attritional claims, because one enormous claim in a small cohort makes that row's development factor meaningless and large losses develop on a different pattern anyway. On the pricing side, cap the loss at a threshold and spread the excess across the wider population, so that a single fire does not reprice a rating cell for years.

Two engineering consequences follow, and they are what the question is testing rather than the actuarial judgement. The large-loss threshold is a business parameter that changes over time and differs by line of business, so it has to be applied at query time rather than baked into an extract, which means the data must remain sliceable by size band. And the cap and the spreading basis have to stay stable between reviews, because if either moves then the change you observe in a segment's indicated rate is your own methodology rather than the underlying risk. Recording the basis as data rather than performing it in a spreadsheet is what lets anybody explain a rate movement a year later.

A windstorm produces four thousand claims across three days. How does your system decide that is one event for reinsurance purposes?

The treaty decides, and it does so by clock. It defines a loss occurrence, typically as all individual losses from the same peril within a stated number of consecutive hours, with the number varying by peril because a windstorm and a freeze have different natural durations. Your system enumerates the candidate windows from real loss timestamps, because the cedant is normally entitled to elect where the window starts, and computes the financial outcome of each candidate.

Two things follow. The money turns on the date and time of loss rather than the notification date, so a claim notified in November for September damage belongs to the September occurrence, and a system storing only a loss date to the day cannot enumerate windows at all. And the choice is a computation rather than a rule of thumb, because whether one large occurrence beats two smaller ones depends on where the losses sit against the retention and the top of each layer, and on the reinstatement premium payable for consuming a layer twice.

The strong answer goes one step further and says who decides. The aggregation is a commercial election made by the cedant under a contractual definition, repeatedly, on incomplete data, with real money attached. What the system owes the reinsurance team is therefore not one computed recovery but the ability to evaluate alternative groupings against the current claim population and record which was elected and why. A recovery engine that hard-codes one grouping rule has taken a decision that belongs to a person, before the information needed to take it existed.

A claim from the same storm is notified eleven weeks later. What happens to a cession you have already reported?

It gets restated, which is the reason a cession has to be a derivation rather than a stored figure with no provenance. The late claim changes the aggregate, and in a bad case it changes which grouping is optimal, after you have reported cessions, submitted bordereaux, taken credit for recoverables in the accounts and closed a reporting period.

That only works if the underlying payments and reserve movements are immutable and remain sliceable by policy, treaty, layer, accident date and underwriting year, with the event grouping held as a separate versioned assignment on top of them. Recompute the recovery under the new grouping, post the difference as a dated adjustment, and keep the prior version so the bordereau you sent in March still reproduces exactly. Editing the recovery figure in place leaves you unable to explain to a reinsurer why the number they were shown last quarter differs from the one in front of them, which is precisely the conversation in which you need to be able to explain it.

A claim payment goes out. How does your system work out how much of it a reinsurer owes?

By identifying which structures cover the policy, applying them in the contractual inuring order, and computing the cession against the claim's running cumulative rather than against the payment in isolation. Proportional cover is a multiplication on the share. An excess layer attaches on the claim total, so an interim payment below the attachment point cedes nothing and each payment's cession is the difference between the cumulative recoverable before and after.

What makes it a data problem is the date mismatch. Treaties commonly attach by underwriting year while claims arrive by accident date, so a policy written in November covers accidents into the following year and cedes to the earlier treaty. One claim does not have a treaty; it has whichever programme covered its policy. Payments therefore stay sliceable by treaty, layer, accident date and underwriting year, and the cession is stored per payment per treaty per layer with the treaty version and the cumulative position it was computed against.

What is the difference between treaty and facultative reinsurance?

Treaty and facultative describe how cover is agreed; proportional and non-proportional describe how it responds. Conflating the two axes is the commonest error in this answer, and an interviewer will usually let you do it and then ask about a non-proportional treaty to see whether you notice. A treaty covers a defined class of business, so every qualifying risk written during the treaty period is reinsured automatically, the reinsurer having underwritten the portfolio and the cedant's underwriting standards rather than individual risks. Facultative cover is arranged for one specific risk, offered and accepted individually and evidenced by a certificate for that risk alone, used for something too large, too unusual or explicitly excluded from the treaty, and carrying a per-risk administrative cost that is exactly why treaties exist.

Independently of that, cover may be proportional, taking an agreed share of premium and losses as in a quota share where the share is fixed or a surplus treaty where it varies with the size of the risk, or non-proportional, paying losses above a retention up to a limit as in per-risk excess of loss, catastrophe excess of loss triggered by an event rather than a risk, or aggregate covers responding to a year's total. Facultative placements are commonly proportional but need not be, treaties come in both flavours, and most insurers run a programme of several treaties and layers at once.

What is a bordereau, and what would you validate on one?

A bordereau is a periodic schedule of business or claims sent between parties, most importantly from a coverholder or managing general agent to the insurer whose capacity they are writing on, and onwards to reinsurers. Under delegated authority the insurer is on risk for policies it did not key, and the bordereau is how it discovers what it is on risk for, so treating ingestion as low-status file loading has direct financial consequences.

Validate structure and business rules on receipt and reject or quarantine rather than partially load. Check that risks fall inside the delegated appetite, that premiums are consistent with the agreed rating basis, that policy identifiers are stable across submissions, and that submitted totals reconcile against cash settled. Store each submission as an immutable versioned artefact separately from your corrected interpretation of it, because submissions arrive late, in formats that drift, and restate prior periods without saying which rows changed.

How would you detect insurance fraud, and how is detecting it at claim different from detecting it at application?

They are two problems sharing a word. Application fraud is misrepresentation of the risk before any loss, caught inside a quote flow with a very short latency budget by comparing declared facts against reference data and industry-shared registers where the market has them, and by reading your own quote logs for manipulation such as the same risk re-quoted with the date of birth or occupation shuffled until the price drops. Claim fraud is a false or inflated claim against genuine cover, caught over days, on behavioural and relational evidence rather than anything checkable against a register.

Per-claim scoring finds the opportunistic end. Organised fraud is a graph problem, because each claim in a well-run ring looks acceptable and what is unusual is the pattern of connections between people, addresses, accounts, vehicles, repairers, clinics and solicitors. Entity resolution decides whether that works. In both cases the output is a capacity-shaped ranked queue carrying the evidence that justified each referral, and the model triages while a human decides.

Your fraud score holds up a claim from a customer of eleven years, the investigation finds nothing, and settlement is six weeks late. What did that cost you?

More than the investigator hours, which are the smallest item. A long-tenure customer was treated as a suspect at the moment they finally used the product; some proportion of customers in that position leave and they are disproportionately the profitable renewals the book depends on; and a complaint about delay on a claim you eventually paid in full is hard to defend because its substance is true. Delay also makes the claim more expensive, because the hire car runs longer and legal costs accrue.

The subtler cost is to the model. An investigation that found nothing established that nobody found evidence in the time available, not that the claim was honest, and writing it back as a negative label teaches the model that a pattern it flagged correctly is normal. Outcomes therefore need to distinguish confirmed fraud from claims withdrawn, settled below the amount presented, closed for lack of evidence, and closed because nobody had time. The design fixes are a score that ranks a queue rather than gating a payment, a hard time limit on referrals, and an interim payment path for the parts of a claim not in question.

Where would you refuse to automate a decision, and on what grounds?

Where a decision is significant to the customer and cannot be explained in terms the customer can engage with. Repudiating a claim, voiding a policy, declining cover outright and holding a payment are decisions where the insurer is expected to give reasons, and a model score is not a reason. Data-protection law restricts decisions based solely on automated processing that significantly affect a person and provides for human intervention and contestability, and conduct rules independently require fair treatment and prompt handling. A pipeline making those decisions automatically has put an unexplainable artefact in the causal chain of a decision it is obliged to explain.

What is legitimate to automate is substantial and worth naming, because refusing everything is also a wrong answer. Ranking cases, assembling evidence, resolving entities, computing indicators, drafting the specific information request a handler will send, and routing to the right skill set all increase both speed and defensibility. The line runs between preparing a decision and making one.

How would you demonstrate to a regulator that a rating factor is not a proxy for something you are not permitted to use?

With evidence rather than assurance, in two halves. The documentary half is being able to state in plain language what the input measures and how it is constructed, which for a vendor composite is a contractual requirement on the vendor rather than an analysis you can perform. A score whose construction is proprietary and undisclosed cannot be defended by inspection, which makes this a procurement problem before it is a compliance problem.

The quantitative half is testing the fitted effect for concentration against the characteristics prohibited or restricted in the jurisdiction, at the level of the rating cells you actually charge, and retaining those tests with the filing rather than producing them when asked. Several markets have moved towards requiring exactly this of insurers using external data and predictive models. The engineering consequence is that the factor, its source, its version, its documentation and its test results are retained as a versioned artefact alongside the rate, because the question will be asked about a rate in force years ago rather than the one running now.

A claim is notified today for a loss eight months ago. Which terms govern it?

The terms in force at the date of loss, reconstructed as they stood, including every endorsement effective on or before that date and excluding every one effective after it. Today's version of the policy is relevant only as a source of error. That is the practical reason the policy model needs business time rather than a current-state record: claims adjudication is a business-time query, and it will be asked about dates long past.

Two follow-on points score well here. The system-time question is different and also needed, because if the certificate you issued in March was wrong you have to be able to regenerate it exactly as issued, including its error, and then show the transaction that corrected it and when it arrived. And a backdated endorsement that lands after this claim has been adjudicated forces a human decision rather than a silent recalculation, because the cover applied to the claim may no longer be the cover the policy records, and the right handling depends on what changed, who knew what and when, and the non-disclosure regime that applies.

The actuary wants immutable movement history and the claims director wants a fast handler screen. How do you resolve that?

By recognising they conflict only if you serve both from one mutable table. The claims application needs current state and low latency, and it is entirely reasonable for it to maintain a derived current-state view. The actuarial requirement is on the write path: every financial event appended with its effective date, its booked date, its reason and its dimensional context, and nothing corrected except by a reversing entry.

Framed that way the argument becomes an engineering trade about materialisation rather than a fight about principles, and the position to hold firmly is only this: no operation may overwrite a movement, because a derived view can always be rebuilt and destroyed history cannot. It helps to make the cost concrete in the other party's terms. The claims director's own hardest question, what a claim was believed to be worth at the end of last quarter on a file that has since closed and reopened, is unanswerable without the same history the actuary is asking for.