System Workflow Overview

LifeX — End-to-End Business Workflow

A single, high-level map of how a policy moves through LifeX — from master data and product design, through sales and underwriting, to policy issuance, servicing, claims, reinsurance and finance — for both Life and Credit Life, Individual and Group.

Prepared for: Client Review Document type: High-Level Process Overview Scope: Full platform, all active modules Date: 31 August 2026

LifeX is organized around one central idea: every product, price, sale, treaty and financial account moves through the same handful of stages — set up, priced, sold, serviced, and settled — and every change to a business-critical rule (product design, pricing, underwriting rules, reinsurance treaties, chart of accounts) passes through a single, uniform maker-checker approval engine before it goes live. This means one governance model to explain, audit and trust across the entire platform, rather than a different approval process per module.

The diagram below is the one-page mental model. Every section after it zooms into one lane of this map in more detail — each ending in, or feeding, the same downstream stages (Policy → Servicing / Claims / Reinsurance → Finance).

flowchart LR
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef gate fill:#0891b2,stroke:#155e75,color:#ffffff,stroke-width:1.5px;

  MD["Master Data"]:::process --> PP["Product & Pricing"]:::process --> SA["Sales
(Quotation)"]:::process
  SA --> UW["Underwriting"]:::process
  UW --> SA
  SA --> PO["Policy
Administration"]:::process
  PO --> SV["Servicing"]:::process
  PO --> CL["Claims"]:::process
  PO --> RI["Reinsurance"]:::process
  SV --> FI["Finance &
Accounting"]:::process
  CL --> FI
  RI --> FI
  GV[["Governance —
Maker / Checker"]]:::gate
  GV -. governs .-> PP
  GV -. governs .-> SA
  GV -. governs .-> RI
  GV -. governs .-> FI

Key

How to Read These Diagrams

Every diagram in this document uses the same six visual building blocks, so once you've read one flow, you can read all of them.

Start / End — where a process begins or finally concludes

Process Step — an action taken by a user or the system

Decision — a fork based on a real condition

Governance Gate — a maker-checker approval checkpoint

Successful Outcome — the process completes as intended

Rejected / Declined — the process stops short of completion

01 Foundation

Master Data & Product Setup

Every sale in LifeX traces back to a product that was built once, priced once, and approved once. Reference data (lines of business, product types, loan types, nationalities, genders, currencies) underpins every product; pricing and product design changes are both independently governed before a product can be sold.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef gate fill:#0891b2,stroke:#155e75,color:#ffffff,stroke-width:1.5px;

  A(["Master Data Setup"]):::startEnd --> B["Configure reference data:
Line of Business, Sub-LOB, Product Type,
Genders, Nationalities, Loan Types"]:::process
  B --> C["Define Product
(Life or Credit Life family)"]:::process
  C --> G1[["Approve — PRODUCT_MCA"]]:::gate
  G1 --> D["Configure Plan, Coverages & Riders"]:::process
  D --> E["Build Rating Table
(age band / group size / loan tenure)"]:::process
  E --> G2[["Approve — PRICING_MCA"]]:::gate
  G2 --> F["Link Reinsurance Treaty Scope (optional)"]:::process
  F --> Z(["Product Active — Ready to Quote"]):::startEnd

Two independent gatesProduct design and pricing are approved separately — a pricing correction doesn't require re-approving the whole product.

One master-data spineIndividual, Group, Life and Credit Life products all draw from the same reference lists, so a nationality or loan-type list only needs to exist once.

Reinsurance-aware from day oneA product can be linked into a treaty's scope at setup, so cessions are ready the moment the first policy is issued.

Reference

Real Product Catalog — by Sub-LOB & Product Type

The live, actively sellable products behind every flow in this document, grouped by Sub-Line of Business and Product Type. All belong to the same Life line of business and share the setup and governance shown in section 01.

Sub-LOB	Product Type	Product	Code
Life	Term	Term Insurance Plan	TERM
Life	Group	Group Term Life Plan	GRP_TERM
Life	Savings	Personal Protection & Savings Plan	PS_PERSONAL
Life	Savings	Personal Protection & Savings Plan (Level Loaded)	PS_PERSONAL_LL
Life	Savings	Kids Protection & Savings Plan	PS_KIDS
Life	Savings	Kids Protection & Savings Plan (Level Loaded)	PS_KIDS_LL
Life	Retirement	Pension (Retirement) Plan	PENSION
Life	Retirement	Single Premium Pension (Retirement) Plan	SPP
Credit Life	Term	Credit Life — Home Finance	CL_HOME
Credit Life	Term	Credit Life — Personal Finance	CL_PERSONAL
Credit Life	Term	Credit Life — Auto Finance	CL_AUTO
Credit Life	Term	Credit Life — Consumer Finance	CL_CONSUMER
Credit Life	Term	Credit Life — Credit Card	CL_CREDITCARD
Credit Life	Term	Credit Life Term Basic	TERM1011

2 Sub-Lines of BusinessLife and Credit Life, both under the Life line of business.

4 Product Types in active useTerm, Group, Savings and Retirement — each mapped only to the Sub-LOBs it is valid for (Credit Life, for example, is Term-only by design).

14 actively sellable productsEverything above is live and prices real quotations today; a handful of legacy/test products have been retired and are intentionally not shown.

02 Sales · Life

Individual Life — Quotation to Policy

A dedicated entry point for single-life business. Medical disclosure automatically routes higher-risk answers to underwriting before the quotation can ever be submitted for commercial approval.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef gate fill:#0891b2,stroke:#155e75,color:#ffffff,stroke-width:1.5px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;
  classDef fail fill:#fde8ed,stroke:#9f1239,color:#3f0a17,stroke-width:1px;

  A(["Start: New Individual Quotation"]):::startEnd --> B["Select Customer, Product & Plan"]:::process
  B --> C["Enter Coverage / Contribution / Duration"]:::process
  C --> D["Complete Medical Questionnaire"]:::process
  D --> E{"Any answer
triggers referral?"}:::decision
  E -- "Yes" --> F["Medical Referred
(Underwriting review)"]:::process
  E -- "No" --> H["Medical Cleared"]:::process
  F --> H
  H --> I["Fund Allocation & Beneficiaries
(investment-linked plans)"]:::process
  I --> G1[["Submit for Approval — QUOTATION_MCA"]]:::gate
  G1 --> J{"Approved?"}:::decision
  J -- "No" --> K(["Rejected"]):::fail
  J -- "Yes" --> L["Accepted"]:::process
  L --> M["Convert to Policy"]:::process
  M --> Z(["Policy Issued"]):::success

Risk-aware disclosureSpecific "yes" answers on the medical questionnaire automatically flag a quotation for underwriting review — this isn't a manual judgment call by the sales user.

Investment-linked readyFund allocation and beneficiary capture appear only where the plan design calls for them.

One conversion, one policyConverting an accepted quotation issues exactly one individual policy, carrying its coverage, contribution and beneficiary data forward.

03 Sales · Life

Group Life — Quotation to Policy

Group business starts from a scheme sponsor (a company as customer) and a member census, rather than a single life — pricing responds to group size, and one master policy covers the whole roster.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef gate fill:#0891b2,stroke:#155e75,color:#ffffff,stroke-width:1.5px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;
  classDef fail fill:#fde8ed,stroke:#9f1239,color:#3f0a17,stroke-width:1px;

  A(["Start: New Group Scheme"]):::startEnd --> B["Set Up Scheme
(Sponsor / Company as Customer)"]:::process
  B --> C["Bulk-Upload Member Census (CSV)"]:::process
  C --> D["Create Group Quotation
(Plan, Group Size, Coverage)"]:::process
  D --> E["Contribution Estimate
(group-size banded rating)"]:::process
  E --> G1[["Submit for Approval — QUOTATION_MCA"]]:::gate
  G1 --> F{"Approved?"}:::decision
  F -- "No" --> K(["Rejected"]):::fail
  F -- "Yes" --> H["Convert to Group Policy"]:::process
  H --> Z(["Master Policy Issued"]):::success
  Z --> I["Member Roster Maintained"]:::process
  Z --> J["Periodic Group Billing Batches"]:::process

Company as customerA scheme sponsor is onboarded as a customer in its own right, distinct from the individual members it covers.

Census by upload, not by handMembers are added through a bulk census template rather than one-by-one data entry — built specifically to remove that bottleneck for large groups.

Billing runs on its own cadenceOnce issued, a group policy generates periodic billing batches independent of the one-time issuance approval.

04 Sales · Credit Life

Credit Life — Individual & Group

Credit Life reuses the exact same quotation and approval engine as ordinary Life business — what's different is that the sum covered is tied to an outstanding loan balance rather than a freestanding sum assured, and it can be sold either against one borrower or across a lender's whole portfolio.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;

  A(["Start: Select Credit Life Product"]):::startEnd --> B["Capture Loan Details:
Loan Type, Amount, Tenure, Interest Rate"]:::process
  B --> C["Cover Amount Tied to
Outstanding Loan Balance"]:::process
  C --> D{"Individual borrower
or lender portfolio?"}:::decision
  D -- "Individual" --> E["Individual Credit Life Quotation"]:::process
  D -- "Group / Portfolio" --> F["Group Scheme + Bulk Borrower Upload
(loan fields included)"]:::process
  E --> G["Same Approval & Issuance Flow
as Life (sections 02 / 03)"]:::process
  F --> G
  G --> Z(["Policy Issued — Linked to Loan Account"]):::success

Loan-linked coverHome, Personal, Auto, Consumer and Credit Card loan products each carry their own loan-type-specific rating.

No parallel process to maintainBecause it shares the Individual/Group quotation engine, every improvement to underwriting or approval automatically applies to Credit Life too.

Portfolio-scale onboardingA lender's entire borrower book can be brought on cover through the same census-upload mechanism used for Group Life.

05 In-Force Policy

Policy Servicing — Service Requests

Everything a policyholder or admin might need after issuance — surrender, fund switching, top-ups, payment holidays, KYC and IBAN updates, beneficiary changes and more — flows through one request-and-approval mechanism.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;
  classDef fail fill:#fde8ed,stroke:#9f1239,color:#3f0a17,stroke-width:1px;

  A(["Start: Raise Service Request"]):::startEnd --> B["Select Request Type
(19 types — Surrender, Fund Switch,
Top-Up, IBAN / KYC Update, etc.)"]:::process
  B --> C["Submitted"]:::process
  C --> D["In Review"]:::process
  D --> E{"Approved?"}:::decision
  E -- "No" --> K(["Rejected"]):::fail
  E -- "Yes" --> F{"Structured, automatable
request type?"}:::decision
  F -- "Yes" --> G["Effectuated Automatically
(policy / customer record updated)"]:::process
  F -- "No" --> H["Logged for Manual Follow-Up"]:::process
  G --> Z(["Completed"]):::success
  H --> Z

19 recognized request typesCovering financial changes (top-up, withdrawal, fund switch), administrative changes (IBAN, KYC, payment method) and coverage changes.

Half are self-executing on approvalNine of the nineteen types — including Surrender, Fund Switching and Beneficiary changes — apply their effect automatically the moment they're approved, with no separate manual step.

Every request is still loggedTypes that aren't yet automated are still tracked end-to-end for audit and follow-up, never silently dropped.

06 In-Force Policy

Claims

A claim is registered against a specific policy, reviewed, decided, and — on approval — flows straight into a finance payment voucher, so the payment side never has to be re-keyed.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;
  classDef fail fill:#fde8ed,stroke:#9f1239,color:#3f0a17,stroke-width:1px;

  A(["Start: Register Claim"]):::startEnd --> B["Capture Claimant,
Event & Diagnosis Details"]:::process
  B --> C["Attach Supporting Documents"]:::process
  C --> D["Submitted"]:::process
  D --> E["Under Review"]:::process
  E --> F{"Approved?"}:::decision
  F -- "No" --> K(["Rejected"]):::fail
  F -- "Yes" --> G["Claim Payment Voucher Generated"]:::process
  G --> Z(["Paid / Closed"]):::success

Full intake on recordClaimant identity, event date, place, cause/diagnosis and attending physician are captured against every claim, not just an amount.

Documents travel with the claimSupporting documents are attached and retained against the claim record itself.

Approval triggers payment, automaticallyAn approved claim doesn't wait on a second finance-side data entry step — the payment voucher is generated straight from the decision.

07 Risk Transfer

Reinsurance — Treaty to Cession

Treaties (Quota Share, Surplus or Excess of Loss) are set up once, with participants and a defined scope of eligible products. From that point on, every qualifying policy cedes automatically — no manual cession entry.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef gate fill:#0891b2,stroke:#155e75,color:#ffffff,stroke-width:1.5px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;

  A(["Start: Define Treaty
(Quota Share / Surplus / Excess of Loss)"]):::startEnd --> G1[["Approve — TREATY_MCA"]]:::gate
  G1 --> B["Add Participants
(Reinsurer shares, Lead)"]:::process
  B --> C["Define Scope
(eligible Products)"]:::process
  C --> D(["Treaty Active"]):::success
  D --> E["Policy Issued
(from Sales flow)"]:::process
  E --> F{"Product within
Treaty Scope?"}:::decision
  F -- "No" --> H["Retained 100% by Insurer"]:::process
  F -- "Yes" --> I["Cession Generated
(Gross / Ceded / Retained / Net Premium)"]:::process
  I --> Z["Cession Ledger → Finance"]:::process

Treaty terms are approved before they're liveRetention, cession percentages, commission and participant shares all pass through governance before a treaty can accept business.

Scope decides the cession, not the salespersonWhether a policy cedes — and to which treaty — is determined purely by whether its product is in that treaty's approved scope.

Cession splits are calculated, not estimatedGross, ceded, retained and net premium are all recorded per cession, feeding directly into financial reporting.

08 Money Movement

Finance & Accounting

Every premium receipt, claim payment, commission and reinsurance settlement posts as a voucher against a governed chart of accounts, closes into fiscal periods, and feeds statutory Zakat computation.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef gate fill:#0891b2,stroke:#155e75,color:#ffffff,stroke-width:1.5px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;

  A(["Start: Chart of Accounts Setup"]):::startEnd --> G1[["Approve — FINANCE_CONFIG_MCA"]]:::gate
  G1 --> B["Map Party-Type Accounts
(Bank, Premium Income, Claims, Commission)"]:::process
  B --> C["Define Approval Thresholds
(authority limits by amount)"]:::process
  C --> D["Transactions Posted as Vouchers
(Premium Receipt · Claim Payment ·
Commission · Manual / Journal / Adjustment)"]:::process
  D --> E["Posted to General Ledger"]:::process
  E --> F["Fiscal Period Open / Close"]:::process
  F --> H["Zakat Computation"]:::process
  H --> Z(["Financial Reporting"]):::success

Chart of Accounts is governedReclassifying or deactivating a GL account proposes a change for approval — it never silently reclassifies live financial history.

Thresholds gate the size of a decisionApproval Thresholds set the authority limits transactions must respect, independent of the voucher-posting mechanics themselves.

One posting model, every sourceWhether the money originates from a premium receipt, a claim payout or a reinsurance settlement, it lands in the ledger through the same voucher structure.

09 Cross-Cutting

Governance — The Maker-Checker Engine

This is the one mechanism referenced by every gate in every diagram above. It is deliberately the same engine everywhere — Product, Pricing, Underwriting rules, Reinsurance Treaties and Finance Configuration all propose, snapshot, approve and version through it, rather than each area inventing its own approval logic.

flowchart TD
  classDef startEnd fill:#7c3aed,stroke:#4c1d95,color:#ffffff,stroke-width:1px;
  classDef process fill:#eef0f6,stroke:#94a0c2,color:#1b2033,stroke-width:1px;
  classDef decision fill:#fdf1de,stroke:#92400e,color:#1b2033,stroke-width:1px;
  classDef success fill:#e4f7ee,stroke:#047857,color:#052e21,stroke-width:1px;
  classDef fail fill:#fde8ed,stroke:#9f1239,color:#3f0a17,stroke-width:1px;

  A(["Start: Authorized User
Proposes a Change"]):::startEnd --> B["Applies to:
Product · Pricing · Underwriting Rules ·
Reinsurance Treaty · Finance Configuration"]:::process
  B --> C["Change Snapshotted as a New Version"]:::process
  C --> D["Submitted into the Workflow Engine"]:::process
  D --> E["Routed to the Correct Approver Role"]:::process
  E --> F{"Approved?"}:::decision
  F -- "No" --> K(["Rejected — Live Data Unchanged"]):::fail
  F -- "Yes" --> G["Version Applied to the Live Record"]:::process
  G --> H["Full Version History Retained"]:::process
  H --> I["Rollback = a New Version
(requires its own approval)"]:::process
  I --> Z(["Governed Change Complete"]):::success

Propose, don't overwriteA change is captured as a full snapshot before it ever touches the live record, so the "before" state always exists.

Rollback is forward-onlyUndoing a change creates and approves a brand-new version rather than silently reverting — the audit trail only ever grows, never gets rewritten.

One engine, five domainsProduct, Pricing, Underwriting, Reinsurance Treaties and Finance Configuration all share this exact mechanism today.

Completeness

Feature Coverage Checklist

Every active module in the platform, and where it is represented in this document.

Module	Represented In	Governed?
Master Data (LOB, Sub-LOB, lookups)	01 · Master Data & Product	✓
Product & Plan Design	01 · Master Data & Product	✓ PRODUCT_MCA
Rating & Pricing	01 · Master Data & Product	✓ PRICING_MCA
Individual Life Quotation	02 · Individual Life	✓ QUOTATION_MCA
Underwriting & Medical Referral	02 · Individual Life	Referral logic
Group Schemes & Bulk Member Upload	03 · Group Life	✓ QUOTATION_MCA
Group Billing	03 · Group Life	—
Credit Life (Individual & Group)	04 · Credit Life	Shares Sales engine
Policy Administration & Issuance	02 – 04	—
Service Requests (19 types)	05 · Policy Servicing	Approval + auto-effect
Claims	06 · Claims	Approval workflow
Reinsurance Treaties & Participants	07 · Reinsurance	✓ TREATY_MCA
Cessions	07 · Reinsurance	Auto-generated
Chart of Accounts	08 · Finance	✓ FINANCE_CONFIG_MCA
Vouchers & General Ledger	08 · Finance	—
Fiscal Periods & Zakat	08 · Finance	—
Approval Thresholds	08 · Finance	Defines authority limits
Maker-Checker Governance Engine	09 · Governance	The engine itself
Customer / Product / Treaty 360 Views	Cross-cutting reporting surfaces on top of every module above	—