Claims Processing Testing
A claim is the moment the promise is tested. It runs from first notification of loss through assessment to a settled payment, and a defect at any stage either underpays a customer in need or pays out money that should never have moved. This lesson teaches you to test that flow.
1 The Hook
Rata Insurance, a fictional NZ general insurer, settled a kitchen fire claim for a Christchurch customer. The repair was assessed at $24,000. The policy carried a $500 excess. The customer expected $23,500 in their account.
The system paid $24,000. The excess had not been deducted. A change to the settlement screen the month before had moved the excess field out of the payment calculation — it still displayed the excess, but no longer subtracted it. The customer was overpaid $500. On one claim, a rounding-level annoyance. Across thousands of fire and storm claims that quarter, it was a serious loss the insurer only found at reconciliation, long after the money had gone.
The opposite failure is worse for the customer. On another claim the same quarter, a flood-damage payment had the excess deducted twice — once by the assessment tool and again by the settlement engine. The customer received $1,000 less than they were owed, at the exact moment they were trying to rebuild. They had to notice, complain, and wait for a correction. Many customers would simply have accepted the lower figure.
Here is the lesson hidden in those stories. The team had tested that a claim could be lodged, assessed, and paid. The happy path produced a payment. What no test pinned down was the settlement arithmetic itself — cover minus excess, applied exactly once, to the cent. Claims testing is not about whether money moves. It is about whether the right amount moves, every time, in both directions.
2 The Rule
A claim is paid against a defined cover, less a defined excess, applied exactly once. Test the settlement arithmetic to the cent and in both directions: an overpayment is the insurer’s loss, and an underpayment is the customer’s — and the customer is the one who has just suffered the loss the policy was meant to cover. Never accept “a payment was made” as evidence the right payment was made.
3 The Analogy
Splitting a restaurant bill in Wellington with a voucher.
The bill is $120. You have a $30 voucher. The correct amount to pay is $90 — the bill, less the voucher, once. If the till forgets to apply the voucher you pay $120 and you are out of pocket. If it applies the voucher twice you pay $60 and the restaurant is short. Either way money moved, the card beeped, the receipt printed — and the amount was still wrong.
A claim settlement is the same sum: cover, less excess, once. Rata Insurance forgot the voucher on one claim and applied it twice on another. A claims tester is the person who does not just check that the card beeped, but that the maths under the beep is exactly right — and who cares as much about the customer short-changed as the insurer over-charged.
4 The Claims Lifecycle
A claim moves through a defined sequence. A tester must know each stage, because each can fail in its own way.
First notification of loss (FNOL). The customer tells the insurer something has happened — a crash, a burglary, a burst pipe. The system captures the loss, the date, and the policy. The key test property is that the claim is matched to a policy that was in force on the date of loss, with cover for that peril. A claim against a lapsed or wrong policy must not proceed as if covered.
Assessment. The insurer decides whether the loss is covered and how much it is worth — via an assessor, a repairer quote, or an automated rule. This is where cover, exclusions, and the sum insured are applied. A defect here decides the wrong amount before any money moves.
Settlement. The covered amount is turned into a payment figure: assessed loss, capped at the sum insured, less the excess, less any prior payments on the same claim. This is the arithmetic that hurt Rata Insurance, and it is the single most important thing to test exactly.
Payment. The figure is paid — to the customer, a repairer, or a third party. Payment carries its own risks: paying the right payee, the right amount, once, and reconciling it. This is where claims testing meets the payment-rail testing of the Banking QA track.
Recovery and closure. The insurer may recover from a third party (subrogation) or close the claim. A reopened claim, a supplementary payment, or a recovery must all keep the claim’s running total correct — total paid must never exceed the cover, and every movement must reconcile.
5 Cover, Excess and Settlement Maths
The settlement figure is the spine of claims testing, so it is worth being precise about the arithmetic.
The general shape is: settlement = min(assessed loss, sum insured) − excess − prior payments, never below zero. Each term is a place a defect can hide.
- The cap at sum insured: a loss larger than the cover settles at the cover, not the loss. Test a claim above the sum insured and confirm it caps, and a claim below it and confirm it pays the loss.
- The excess, applied once: the excess is subtracted exactly one time. Test that it is deducted (the Rata overpayment), and that it is not deducted twice (the Rata underpayment). Both are real and opposite defects.
- Excess type: some excesses are a fixed dollar amount, some a percentage of the sum insured or loss. Test the right type is applied — a percentage excess on a large claim is very different from a flat one.
- Prior payments on the same claim: a supplementary or staged payment must subtract what was already paid, so the running total never exceeds the entitlement.
- Boundary at zero: a loss smaller than the excess settles at zero, not a negative payment. Test the boundary where loss equals, just exceeds, and is just under the excess.
6 The EQC / Toka Tū Ake Natural-Disaster Context
NZ sits on plate boundaries and floods often, so natural-disaster claims have their own machinery a tester must understand. Toka Tū Ake (the Natural Hazards Commission, formerly EQC) provides a layer of natural-hazard cover for residential property, funded through a levy collected with private house insurance.
The practical consequence for a claims system is a shared boundary: for natural-hazard damage to a home, part of the claim may sit with the statutory natural-hazard scheme and part with the private insurer, depending on the cap and the type of damage. A claim can be lodged, assessed, and apportioned across that boundary. The testing risks are specific:
- Apportionment: the split between the statutory scheme’s cap and the private insurer must be correct, with neither double-counting the same damage nor leaving a gap the customer falls into.
- Cap handling: the natural-hazard scheme covers up to a cap; damage above it flows to the private policy. Test losses at, below, and above the cap.
- Event aggregation: a single event versus separate events changes how caps and excesses apply — aftershocks and repeated flooding raise hard aggregation questions a tester must pin down.
- Hand-off integrity: data shared between the scheme and the insurer must stay consistent, so the same claim is not assessed on two different sets of facts.
The general principle holds: keep the regulatory specifics conceptual and confirm them against current scheme rules, but test the boundary arithmetic exactly. The customer must end up whole — no damage counted twice, none dropped between the two parties.
7 The Two Costs of Fraud Detection
Claims systems screen for fraud, and a tester has to understand that a fraud check has two opposite ways to be wrong, with two very different costs.
A false positive flags a genuine claim as suspicious. The cost lands on a real customer — their legitimate claim is delayed, they are treated as a suspect at a vulnerable moment, and the insurer risks a conduct breach and a complaint. After a major event, a flood of false positives can clog the queue and delay thousands of honest people who have just lost their homes.
A false negative lets a fraudulent claim through. The cost lands on the insurer and, ultimately, on every honest customer through higher premiums. Fraud that is paid is money gone.
The two costs pull in opposite directions. Tighten the model to catch more fraud and you flag more honest customers; loosen it to spare honest customers and you pay more fraud. There is no setting that eliminates both. So a claims tester does not test for “accuracy” as a single number — they test both error rates, separately, against thresholds the business has agreed, and they pay special attention to the false-positive path because that is where a real customer in distress is harmed.
8 Building Claims Test Cases
A strong claims test case states the claim scenario, the cover and excess in play, and asserts the exact settled amount — not just that a payment was made.
Here is a worked test case written to catch the exact Rata Insurance excess bug:
Scenario: House fire claim, settlement arithmetic
Risk category: Excess not applied / applied twice (wrong settlement)
Pre-conditions: In-force house policy on date of loss; sum insured $400,000;
flat excess $500; no prior payments on this claim.
Action: Lodge and assess a fire loss of $24,000; settle the claim.
Expected result: 1) Assessed loss $24,000 is within the sum insured (no cap).
2) Excess of $500 deducted exactly once.
3) Settled amount is EXACTLY $23,500.00, to the cent.
4) Claim running total = $23,500; does not exceed entitlement.
Boundary cases: Loss $400 (under excess) settles $0; loss $500 settles $0;
loss $450,000 caps at $400,000 less $500 = $399,500.
Evidence required: Settlement calculation breakdown; payment record; claim ledger line.
Traceability: Risk R-01 (excess mis-applied in settlement).
Result: [Pass / Fail]
Notice what makes this catch the Hook bug: the expected result asserts an EXACT cent figure and “excess deducted exactly once,” so both the missed-excess overpayment and the double-excess underpayment fail the test. The boundary cases cover the zero floor and the sum-insured cap, and the case traces to a numbered risk. That is the difference between a real settlement test and “check a payment is made.”
9 Common Mistakes
🚫 Asserting that a payment was made, not that the right amount was paid
Why it happens: A successful payment feels like a passed test, and the demo ends when money moves.
The fix: The Rata Insurance trap is a payment that moves the wrong amount. Assert the exact settled figure to the cent — cover, capped, less excess applied once — not merely that a payment occurred.
🚫 Testing the overpayment but not the underpayment (or the other way around)
Why it happens: One direction of error is front of mind — usually the insurer’s loss.
The fix: Excess can be missed (customer overpaid, insurer’s loss) or applied twice (customer underpaid, customer’s loss). Test both directions. The underpayment harms a customer who has just suffered a loss and may never notice, so it is a conduct risk, not just a maths error.
🚫 Settling a claim without checking cover on the date of loss
Why it happens: The claim is in the system, so it feels valid by default.
The fix: A claim must match a policy in force for that peril on the date of loss. Test claims against lapsed policies, the wrong peril, and dates outside the cover period — getting the settlement maths right on a claim that was never covered is the wrong kind of correct.
🚫 Treating fraud detection as a single accuracy number
Why it happens: One headline accuracy figure is easy to report and feels complete.
The fix: A fraud check fails in two opposite ways — false positives harm genuine customers, false negatives cost the insurer. Test both error rates separately against agreed thresholds, and test the customer-facing consequence of a wrongly flagged genuine claim, because that is a conduct risk after a major event.
10 Now You Try
Three graded exercises across the claims lifecycle. Write your answer, run it for AI feedback, then compare to the model answer.
Read the description of a fictional vehicle-claim settlement flow below. Identify 3 claims risks that could pay the wrong amount, settle an uncovered claim, or harm a genuine customer, and name the part of the lifecycle each touches (FNOL/cover, assessment, settlement maths, fraud, payment).
On lodgement the system matches the claim to the customer’s current policy, not the policy in force on the date of loss. The settlement engine subtracts the excess, but the assessment tool has already subtracted it from the figure it passes through. Losses above the sum insured are paid at the assessed loss, not capped. The fraud model flags any claim over $10,000 for manual review, and after a hailstorm this floods the queue, delaying hundreds of genuine claims for weeks. There is no separate measure of how many flagged claims turn out to be genuine.
List 3 claims risks and the lifecycle part each touches:
Show model answer
There are at least four real risks here; any three well-explained earns full marks. 1. Cover matched to the wrong policy version — the claim matches the current policy, not the one in force on the date of loss, so cover, sum insured, and excess could all be wrong. Lifecycle part: FNOL / cover. Impact: a claim assessed against terms that did not apply on the loss date. Fix: match to the policy in force on the date of loss. 2. Excess deducted twice — both the assessment tool and the settlement engine subtract the excess, so the customer is underpaid. Lifecycle part: settlement maths. Impact: customer short-changed at the moment of loss — a conduct risk. Fix: deduct the excess exactly once; assert the exact cent. 3. No cap at sum insured — losses above the sum insured pay the full assessed loss instead of capping, so the insurer overpays. Lifecycle part: settlement maths. Impact: insurer loss on large claims. Fix: settle min(loss, sum insured) less excess. Bonus: fraud false positives unmeasured and flooding the queue — a $10,000 flat threshold flags hundreds of genuine claims after a hailstorm, delaying honest customers, with no separate false-positive measure. Lifecycle part: fraud. Fix: measure the false-positive rate separately and test the customer-facing delay as a conduct risk. The trap: a payment still happens in every case — the defects are in which policy, how the maths runs, and who gets harmed when a genuine claim is flagged.
The claim settlement test case below stops at “a payment was made” and misses the arithmetic. Rewrite it to assert the exact settled amount and the boundaries, with these fields: Test ID, Scenario, Risk category, Pre-conditions, Action, Expected result, Boundary cases, Evidence required, Traceability. Use a fictional NZ contents-theft claim as the context.
“Lodge a theft claim and settle it. Check a payment is made. Pass if the customer is paid.”
Rewrite as a settlement-arithmetic test case:
Show model answer
Test ID: CLM-SET-014 Scenario: Contents theft claim, settlement arithmetic Risk category: Excess mis-applied / no cap at sum insured (wrong settlement) Pre-conditions: In-force contents policy on the date of loss; contents sum insured $50,000; flat excess $400; no prior payments on this claim. Action: Lodge and assess a theft loss of $8,000; settle the claim. Expected result: 1) Assessed loss $8,000 is within the sum insured (no cap). 2) Excess $400 deducted exactly once. 3) Settled amount is EXACTLY $7,600.00 to the cent. 4) Claim running total = $7,600 and does not exceed entitlement. Boundary cases: Loss $300 (under excess) settles $0, not negative; loss $400 (equal to excess) settles $0; loss $60,000 caps at $50,000 less $400 = $49,600. Evidence required: Settlement calculation breakdown showing loss, cap, excess, and net; payment record; claim ledger line with running total. Traceability: Risk register R-01 (excess mis-applied) and R-03 (no cap at sum insured). What makes it strong: it asserts the exact cent and "excess once" so both an overpayment and a double-excess underpayment fail, and the boundary cases cover the zero floor and the sum-insured cap. The original would pass on any payment at all.
Design a test plan of 5 test cases for a fictional NZ house claim apportioned across the Toka Tū Ake natural-hazard scheme and a private insurer after a flood and aftershock event. Each case needs at least: an ID, what it verifies, an acceptance criterion, and the evidence required. Cover apportionment across the cap, a loss at the cap boundary, event aggregation, hand-off data integrity, and a false-positive fraud flag on a genuine claim. Keep the scheme rules conceptual.
Show model answer
ND-01 | Verifies: damage is apportioned correctly between the natural-hazard scheme and the private insurer | Acceptance criteria: no item of damage counted twice and no item left uncovered; the two shares sum to the total assessed loss; customer ends up whole | Evidence required: apportionment breakdown; combined-vs-total reconciliation ND-02 | Verifies: behaviour at the scheme cap boundary | Acceptance criteria: a loss at the cap is fully covered by the scheme; a loss above the cap covers up to the cap from the scheme and the remainder from the private policy; tested at, just under, and just over the cap | Evidence required: settlement breakdowns at the three boundary points ND-03 | Verifies: event aggregation is applied correctly across the flood and aftershock | Acceptance criteria: caps and excesses apply per the agreed event-aggregation rule (single vs separate events) consistently; the customer is not charged duplicate excesses contrary to the rule | Evidence required: event grouping record; excess applied per event with the rule referenced ND-04 | Verifies: data shared between the scheme and the insurer stays consistent | Acceptance criteria: the same claim is assessed on one consistent set of facts on both sides; 0 divergence in loss, damage type, or property details | Evidence required: hand-off data comparison between the two parties ND-05 | Verifies: a genuine claim wrongly flagged for fraud is handled without undue harm | Acceptance criteria: the false-positive rate is measured separately; a flagged genuine claim is resolved within the agreed service standard; the customer-facing delay is bounded | Evidence required: false-positive rate report; flagged-genuine-claim resolution time vs standard Strong plans: each case is specific, has a measurable criterion, names concrete evidence, and together they cover apportionment (ND-01), the cap boundary (ND-02), event aggregation (ND-03), hand-off integrity (ND-04), and the false-positive conduct risk (ND-05). Weak plans say "check the disaster claim works" five times — that is the difference being marked.
11 Self-Check
Click each question to reveal the answer.
Q1: Why is “a payment was made” not enough to pass a claims settlement test?
Because the payment can move the wrong amount — the Rata Insurance trap. A settlement is cover, capped at the sum insured, less the excess applied exactly once. You must assert the exact settled figure to the cent, in both directions, so a missed excess (overpayment) and a double excess (underpayment) both fail. Money moving is not the same as the right money moving.
Q2: What is the general settlement formula, and where do defects hide in it?
settlement = min(assessed loss, sum insured) − excess − prior payments, floored at zero. Defects hide in the cap (large losses not capping), the excess (missed or applied twice, wrong type), prior payments (running total exceeding entitlement), and the zero floor (a loss under the excess paying negative). Test each term with a small table of boundary cases.
Q3: Why ask “was the policy in force for this peril on the date of loss?” first?
Because a claim that should never have been accepted is a defect upstream of every settlement calculation. If cover did not apply on the loss date, or the peril was excluded, getting the maths right is the wrong kind of correct. Match the claim to the policy in force on the date of loss before testing any arithmetic.
Q4: What are the two costs of fraud detection, and why test them separately?
A false positive flags a genuine claim — the cost lands on a real customer in distress and is a conduct risk, especially after a major event. A false negative pays a fraudulent claim — the cost lands on the insurer and honest customers. They pull in opposite directions, so a single accuracy number hides the trade-off. Test both error rates against agreed thresholds, and test the customer harm of a false positive.
Q5: In the EQC / Toka Tū Ake context, what is the core thing a tester must get right?
The boundary arithmetic between the statutory natural-hazard scheme and the private insurer: apportionment with no damage counted twice and none dropped, correct behaviour at the cap, correct event aggregation across aftershocks or repeated flooding, and consistent hand-off data so the same claim is not assessed on two sets of facts. Keep the scheme rules conceptual, but test the split exactly so the customer ends up whole.
12 Interview Prep
Real questions asked in NZ QA interviews for insurance roles. Read the model answers, then practise your own version.
“How would you test a claim settlement calculation?”
I’d build it as a small table of cases against the formula — min(assessed loss, sum insured) less excess applied once, floored at zero. I test a loss under the excess (settles zero, not negative), a loss equal to the excess, a loss between the excess and the sum insured (pays loss less excess to the cent), a loss equal to the sum insured, and a loss above it (caps then deducts excess). For each I assert the exact cent, not just that a payment happened. That table catches both the missed-excess overpayment and the double-excess underpayment, which are real and opposite defects, and I treat the underpayment as a conduct risk because it harms a customer who has just suffered a loss.
“A customer says they were paid less than they expected on a claim. What is your first hypothesis?”
My first hypothesis is the excess being deducted twice — once in assessment and again in settlement — or the wrong excess type or amount applied. I’d reproduce the exact claim, trace the settlement breakdown line by line, and check the excess is subtracted exactly once. I’d also confirm the claim was assessed against the policy in force on the date of loss, because an underpayment can come from the wrong sum insured if the system matched the current policy instead of the historic one. The underpayment matters most because the customer may simply have accepted it.
“How do you think about testing fraud detection on claims?”
I refuse to treat it as a single accuracy number, because a fraud check is wrong in two opposite ways. A false positive flags a genuine claim, harming a real customer at a vulnerable moment and creating a conduct risk — after a flood or quake, a flood of false positives can delay hundreds of honest people. A false negative pays a fraudulent claim, which is the insurer’s and ultimately every customer’s loss. I test both rates separately against thresholds the business has agreed, and I test the customer-facing path of a wrongly flagged claim — how long they wait and how they are treated — as hard as the financial path of missed fraud.