Building a Life insurance product, explained for people who know Medical, not Life

In Medical, "configuring a product" usually means picking a network and a set of benefit limits. In Life, you're defining what the product actually promises — and that promise takes several new shapes Medical never needed.

Skim once. Every one of these appears on the real screenshots further down.

Product / Plan

Product = the type you're building in this wizard ("Term Life Standard"). Plan = a specific cover-amount configuration under it, built in Step 2 — a Product can have more than one Plan.

Category

The product's fundamental shape — Term, Whole Life, Endowment, Savings, Investment-Linked, Retirement or Group. Not the same thing as Sub-LOB or Policy Type.

Sum Assured

The cover amount — the lump sum the product can pay out. Configured as a range on the Plan (Step 2), separate from what the customer pays in.

Contribution

Life insurance's word for "premium" — what the customer actually pays, Regular (recurring) or Single (one lump sum, once).

Unit / Fund

For Investment-Linked and Savings products, contributions buy "units" in a fund the customer effectively invests in — a concept Medical has no equivalent for at all.

Charge / Loading

The insurer's own cost (covering the death benefit, admin, etc.) deducted from a fund's value over time, instead of being billed as a separate premium line.

Sub-LOB

Life or Credit Life — whether this is an ordinary Life product, or one that exists purely to protect a bank loan.

Policy Type

Individual or Group — same split as Medical's individual-vs-corporate. Familiar.

Rider / Benefit

An optional (or mandatory) add-on on top of the base plan — e.g. Critical Illness, Accidental Death — configured in Step 3.

MCA (Maker–Checker–Approver)

The same idea as a Medical claim needing supervisor sign-off, formalized: Benefits, Yearly Charges and Pricing each need to be "Proposed" then approved before they take effect.

Rating Table

The rate-per-1,000-of-cover table, banded by age/gender/smoker status, that actually turns a customer's chosen Sum Assured into a contribution amount.

The wizard walks a Product all the way from "just an idea" to "customers can actually be quoted on it," in order. Steps 3–5 each need a second person's approval before their content takes effect — you'll see the exact same Approve button pattern from claims/underwriting sign-off, just applied to product configuration instead.

flowchart LR
    S1["Step 1\nBasic Details\nname it, classify it,\nsay who can buy it"] --> S2["Step 2\nPlan Setup\ncover-amount range"]
    S2 --> S3["Step 3\nBenefits\noptional / mandatory riders"]
    S3 --> G3{{"Propose then Approve\nPRODUCT_MCA"}}
    G3 --> S4["Step 4\nYearly Charges\nfund charge schedule"]
    S4 --> G4{{"Propose then Approve\nPRICING_MCA"}}
    G4 --> S5["Step 5\nPricing\nrate-per-1,000 table"]
    S5 --> G5{{"Propose then Approve\nPRICING_MCA"}}
    G5 --> DONE(["Ready to sell —\nappears in Quotation"])
        

What you'll see first

The step rail at the top always shows where you are

Locked steps (padlock icon) simply mean "the thing this step needs doesn't exist yet" — Plan Setup unlocks the moment a Product is saved; Benefits/Charges/Pricing unlock once a Plan exists. You can't get ahead of the data.

Test tip: confirm a locked step really is unclickable, and that refreshing mid-wizard doesn't silently lose the Product/Plan you already saved (the wizard re-derives its unlocked state from what's actually been persisted, not from client-side wizard progress).

Two fields on the Basic Details form are conditional — they only show up for specific choices elsewhere on the same screen. Both are genuinely easy to miss if you're only skimming for "required" fields.

flowchart TD
    START(["Basic Details form"])
    START --> SUBLOB{"Sub-LOB"}
    SUBLOB -->|"Life"| NOLOAN["Loan Type field — hidden"]
    SUBLOB -->|"Credit Life"| LOAN["Loan Type field — shown\nHome / Personal / Auto /\nConsumer / Credit Card"]
    START --> CHARGE{"Charge Structure Mode"}
    CHARGE -->|"LevelLoaded"| NOTHRESH["Charge Threshold Amount — hidden"]
    CHARGE -->|"CustomerChoice"| THRESH["Charge Threshold Amount — shown\nthe SAR value that decides which\ncharging pattern a customer gets"]
        

Toggle 1

CustomerChoice reveals Charge Threshold Amount

Switching Charge Structure Mode from LevelLoaded to CustomerChoice adds a new number field right below it. Leave it on LevelLoaded and that field never appears — there's nothing to configure, because every customer gets the same even charge pattern regardless of how much they contribute.

Test tip: toggle back to LevelLoaded after filling the threshold, then forward to CustomerChoice again — confirm the value you typed is still there rather than silently cleared.

Toggle 2

Credit Life reveals a whole extra numbered section

Switching Sub-LOB to Credit Life doesn't just reveal one field — it inserts an entire new numbered section, 5. Loan Type, and every section after it renumbers (Term & Eligibility becomes 6, Financial becomes 7, Effective Period becomes 8). This screenshot has Personal loan selected as an example — LifeX's real seeded Loan Type list is Home, Personal, Auto, Consumer and Credit Card.

Test tip: the numbering shift is a good visual regression check — if you ever see Loan Type appear while Sub-LOB still reads "Life," or the numbers fail to shift, that's a real bug, not a cosmetic nit.

Everything below is one form, saved in one shot. The rest of this guide walks it section by section in the same order it appears on screen, with the depth weighted toward the fields that genuinely don't exist in Medical.

Nothing new here

Product Code, Product Name, Product Name (Ar)

Exactly what it looks like — a unique code, a display name, and the Arabic name. Same job as naming a Medical plan. Product Code becomes read-only the moment the product is saved (visible as the greyed-out field in the Edit dialog later in this guide) — it's the permanent identifier everything else links to.

This is the single most important choice on the whole form. In Medical, every plan works the same way — treatment gets reimbursed, coverage resets yearly. In Life, Category decides which of several genuinely different financial promises this product is making. Seven options exist in LifeX today; here's what each one actually commits to.

In this example

Term Life Standard is a plain Term product

Our worked example throughout this guide is deliberately the simplest category: Term, Individual, Life Sub-LOB. It's the closest thing to "just cover, nothing invested" — the fastest one to reason about before the deeper Investment-Linked/Endowment mechanics come into play.

Premium Type is two options: Regular or Single.

• Regular — pay every period (monthly, quarterly, yearly) for the life of the policy. Exactly the same shape as a normal Medical premium. Familiar.
• Single — pay ONE lump sum, once, up front, and never again. This only makes sense because of the investment/savings angle some Life categories have: a Single contribution of, say, SAR 100,000 starts growing inside an Investment-Linked or Savings product from day one. Medical has no equivalent because there's no "growing pot" to fund up front — a Medical premium just buys this year's coverage.

Charge Structure Mode is the hardest new concept in the whole wizard, so it's worth being precise about what it actually does.

For Investment-Linked and Savings-type products, part of every contribution buys units in a fund — like buying shares. The insurer's own cost of running the product (covering the death benefit, admin, and so on) is then deducted from that fund's value over time, instead of being billed as a separate premium line the way a Medical premium is a flat number.

• LevelLoaded — those deductions are spread evenly across the whole policy term. Same percentage taken every year, predictable, regardless of how much the customer contributes.
• CustomerChoice — the deduction pattern depends on how much the customer actually contributes, compared against the Charge Threshold Amount configured here. Contribute above the threshold and the policy gets the smooth LevelLoaded pattern; contribute at or below it and the policy instead gets a front-loaded pattern — heavier charges taken in the earlier policy years.

Sub-LOB is a business-line split within Life itself, and LifeX has exactly two: Life and Credit Life.

Life vs Credit Life

Credit Life protects a loan, not a family

Life is the ordinary case — everything described under Category above. Credit Life is life insurance sold specifically alongside a bank loan: if the borrower dies before the loan is repaid, Credit Life pays off the remaining loan balance to the bank — not a lump sum to the family. It's bought at the moment the loan is originated, and its cover amount shrinks automatically as the loan gets paid down, tracking the loan's own repayment schedule rather than staying fixed like an ordinary Sum Assured.

There is no Medical equivalent at all — Credit Life doesn't exist to cover a person's health costs, it exists purely to guarantee a bank gets repaid.

Policy Type is Individual or Group — one named insured, versus one employer/association buying a single master policy that covers many employees or members. This half of the section really is familiar: it's the same individual-vs-corporate split Medical already has.

Loan Type only appears when Sub-LOB is set to Credit Life (see the screenshot above) — it's the specific bank loan product this cover rides on. LifeX's real seeded options are Home, Personal, Auto, Consumer and Credit Card. Each loan type carries its own risk and eligibility profile — a credit-card balance behaves very differently from a home loan — so Credit Life products are configured per loan type rather than one-size-fits-all.

Entry age vs Policy term

One field you know, one you don't

Min/Max Entry Age is familiar — the age window within which a new customer may buy this product, same idea as Medical's own entry-age rules (18–59 in this example).

Min/Max Policy Term (years) is genuinely new: how many years the policy itself runs for (10–30 years here). Medical policies are typically annual/renewable and simply don't have a multi-year fixed "term" concept.

Test tip: create a Whole Life product and confirm Min/Max Policy Term can be left blank — a Whole Life policy deliberately has no end date to define, so a validation rule that forces this field would be a real bug.

"Contribution" is simply Life insurance's word for "premium" — the amount the customer pays, on whichever schedule Premium Type says. Min/Max Contribution set the allowed range for how much a customer can commit to on this specific product — SAR 100 to SAR 50,000 in our example.

The maximum matters more here than the equivalent cap would in Medical. For Investment-Linked and Savings products, the contribution amount doesn't just decide "how much this costs" — it directly determines how much money actually gets invested into the customer's fund. An unrealistically large contribution isn't only a pricing risk the way an oversized Medical premium might be; it changes how big a fund the product is promising to manage on the customer's behalf. Bounding it protects against unrealistic setups, not just pricing errors.

Effective From / Effective To set the date window during which this exact configuration of the product is sellable and quotable. If the product's rates or terms ever need to change later, that change goes through the same governed propose-then-approve pattern used for Benefits, Yearly Charges and Pricing — never a silent overwrite of what's already live.

Every Product needs at least one Plan — this is where you set how much cover it actually offers.

A Plan is a configuration, not the product itself

Plan Code, Plan Name, Version No, Effective dates

Same naming idea as Product Information above, plus a Version No — a Product can carry more than one Plan over time (e.g. a repriced version), each independently versioned and effective-dated.

The two fields that matter

Cover Amount Range, and Cover as a Multiple of Contribution

Cover Amount Range (Sum Assured) is the min/max lump sum a customer can choose for this Plan — SAR 50,000 to SAR 1,000,000 here. Cover as a Multiple of Contribution is an optional alternate sizing rule: entering 10 means the cover amount is automatically set to 10× whatever the customer contributes yearly, instead of the customer picking a cover amount directly.

The optional (or mandatory) riders a customer can get on top of the base cover — this is the closest thing to Medical's own add-on benefits, just governed more formally.

Tap to include, then configure

Death Benefit, TPD, Critical Illness, Accident Death

LifeX's real seeded benefits are Death Benefit (the base plan itself), Total Permanent Disability, Critical Illness (11 Conditions), Critical Illness (5 Conditions) and Accident Death. Tap a card to include it; if included, you can mark it Mandatory (given to every customer automatically) and set the Min/Max Cover a customer can choose for that specific rider.

In this example

Death Benefit mandatory, Accident Death optional

Death Benefit is marked Mandatory — every customer on this product automatically gets it. Accident Death is included but left optional, so a customer chooses whether to add it. Both get their own Min/Max Cover range, independent of the Plan's overall Sum Assured range.

Nothing applies until approved

Propose Benefits, then a second sign-off (PRODUCT_MCA)

Clicking Propose Benefits doesn't make the benefit list live immediately — it submits the whole set for maker-checker approval. Only after an approver signs off does the configuration actually apply. This is the same governance shape as an underwriting sign-off, just applied to product configuration.

Test tip: propose a change, then re-open the product before approving it — confirm the OLD benefit list is still what a Quotation actually sees until the new one is approved.

This is where Charge Structure Mode (from Step 1) becomes concrete numbers — the actual year-by-year charge schedule for Investment-Linked/Savings-type products.

One row per policy year

Charge % and Allocation % per year

Each row is one policy year, with a Charge Type label, a Charge % (how much is taken as the insurer's cost that year), and an Allocation % (how much of that year's contribution actually gets invested into the customer's fund). Together they should reflect whatever LevelLoaded or CustomerChoice promised back in Step 1.

In this example

Year 1: 5% charge / 95% allocated. Year 2: 2% charge / 98% allocated

A heavier charge in year 1 tapering to a lighter one in year 2 is a common real-world shape — more of the insurer's setup cost recovered early, then a larger share of the contribution flowing into the customer's fund in later years. Like Benefits, this whole schedule is Proposed then requires approval (PRICING_MCA: Senior Underwriter → Head of Underwriting) before it applies.

The last step, and the one that actually calculates money: the rate-per-1,000-of-cover table used to turn a customer's chosen Sum Assured into a real contribution amount.

One row per age band, gender and smoker status

Age Band, Gender, Smoker Status, Rate / 1,000 Cover

LifeX's real seeded age bands are 18-30, 31-40, 41-50 and 51-59. Each combination of Age Band × Gender × Smoker Status gets its own rate — this is standard actuarial banding, conceptually similar to how a Medical premium can vary by age band, just with smoker status added as a Life-specific risk factor.

In this example

A younger non-smoker prices lower than an older smoker

Rate 1.25 for an 18-30 non-smoking male versus 2.10 for a 31-40 smoking female reflects both age and smoker-status risk loading in one number — the rate charged per SAR 1,000 of Sum Assured for that exact band.

The finish line

"Product setup complete!"

Once Pricing is Proposed and approved, the wizard's own progress counter reads 5/5 and shows this banner — the product is now genuinely ready to sell, meaning it will actually appear as a choice inside the Quotation flow.

Test tip: immediately go create a Quotation and confirm the new product/plan actually appears as selectable — "wizard says complete" and "Quotation can actually use it" are two different things worth checking separately.

Two more screens you'll use constantly once a product exists, both reachable from the Products list.

Where you start

Admin → Products

The Products list is where every product you've built shows up, with its Category, Sub-LOB, Policy Type and status — and where the eye and pencil icons on each row open Product 360 and the Edit dialog below.

Read-only, everything in one place

Product 360

The eye icon opens Product 360 — a read-only rollup of everything about the saved product: classification, charge structure, how many Plans and Benefits are configured, plus tabs for Pricing & Structure, Plan & Benefits, Charge & Rating and Usage & Governance. Useful for confirming what actually got saved without re-opening the wizard.

Same fields, different container

Edit Product dialog

The pencil icon opens Edit Product — literally the same field layout as Step 1 of the wizard (Product Information through Effective Period), just in a popup, for tweaking an already-created product without re-running the whole 5-step flow.

A starting list, weighted toward the parts of the wizard most likely to hide a real bug.

• Create one product per Category (all seven) and confirm the fields that should be optional for that category — Max Policy Term for Whole Life especially — really are left blank without a validation error.
• Set Charge Structure Mode to CustomerChoice, fill a Charge Threshold Amount, then quote a contribution above and below that threshold — confirm the two quotes end up with different charge patterns, not just different numbers.
• Set Sub-LOB to Credit Life and confirm Loan Type is genuinely required before the form can be saved, and that section numbering shifts correctly.
• Propose a Benefits / Yearly Charges / Pricing change, then check a live Quotation before approving — confirm it's still pricing off the OLD approved configuration, not the pending proposal.
• Approve a proposal and re-check the same Quotation — confirm it now reflects the new configuration.
• Reject a proposal and confirm the previous configuration is completely unchanged — a rejection should never partially apply.
• Open Product 360 straight after finishing the wizard and cross-check every number shown there against what you actually typed.
• Open the Edit dialog on a saved product and confirm Product Code is read-only while every other field remains editable.