LifeX Platform
by ACESS MEDITECH
Service Requests — Feature & Workflow Guide
Every change a policyholder can ask for after a policy is issued moves through one consistent, reviewable process. This guide is a clickable directory of all 25 request types — each with its full end-to-end workflow, its real intake screen, and, where money actually moves, the exact calculation with a worked example.
One consistent front door. Whatever the policyholder is asking for, it's raised the same way, reviewed the same way, and leaves the same audit trail behind. Nothing is a silent edit; every change is a request first, and the policy only changes once that request is approved.
Click any tile in the Request Directory below to jump straight to that type's full workflow, its real intake fields, and its calculation if it has one.
One Consistent Process
Every request — whatever it is — is raised, reviewed, and approved through the same generic workflow engine, so nothing is a silent edit and every change leaves the same audit trail.
Request Directory
All 25 request types at a glance. The four core-engine types — the ones with real dual-approval, live NAV, and same-day rules — lead the grid. Click any tile to jump to its full end-to-end workflow, intake screen, and calculation.
How Every Request Moves
Every one of the 25 request types follows the same reviewable path. Policy Surrender and Fund Switching are the two deliberate exceptions — both need a second, different approver (maker≠checker) because they move real money against real NAV. Their reversals (Surrender Reversal, Fund Switch Reversal) stay single-actor — an administrative undo, not a new financial decision. See their own cards below.
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(["Request raised against a policy"]):::startEnd --> B["Purpose-built intake form
captures exactly what this change needs"]:::process B --> C(["Status: Submitted"]):::process C --> D{"Reviewed by an
authorized reviewer"}:::decision D -- "Reject (reason required)" --> D1(["Status: Rejected
policy left exactly as it was"]):::fail D -- "Approve" --> E["The real change is applied first
checked against the policy's live data"]:::process E --> F{"Passes validation?"}:::decision F -- "No -- out of bounds, insufficient funds,
unverifiable bank account, etc." --> F1(["Blocked with the exact reason
request stays Submitted, correctable"]):::fail F -- "Yes" --> G(["Status: Approved / Completed
the policy now reflects the change"]):::success
Money Movement & Payables
Anything that adds money to a policy or takes it out. A withdrawal is never just marked "paid" — it's recorded as a real amount owed to the policyholder's bank account, ready for transfer.
A general goodwill or overpayment refund, not tied to any withdrawal or claim.
The maker enters the exact amount; the system never derives it. This is the one payable type LifeX doesn't compute automatically, because a goodwill refund has no formula to compute — it's a human decision, recorded honestly as one.
Withdraws part of the policy's current investment value, redeemed proportionally across every fund the policy actually holds — not by target allocation%, since that can have drifted from what's really held.
A voluntary extra contribution, purchased into the policy's funds at today's price, split across the policy's own fund allocation percentages.
Withdraws value previously added through a Top-Up. The exact same real proportional-redemption math as Partial Withdrawal (see its worked example above) — tracked under its own tag for reporting only.
Catches up a missed premium. The exact same real unit-purchase math as Top-Up (see its worked example above), tagged separately for arrears reporting.
Restructures an outstanding amount into a new payment plan instead of collecting it immediately — a real recorded plan, not just a status flag.
Fund Management
For investment-linked policies only — controlling which funds the policy's money is actually in.
Changes where future contributions are invested. Money already invested is completely untouched — a different concept from Fund Switching below.
Moves money already invested from one fund to another. Production-grade engine: 5 switch methods, real charges, forward-pricing NAV rules, and a full maker≠checker lifecycle — the second deliberate exception alongside Surrender.
Undoes the policy's most recently completed Fund Switch — restores the exact units in both funds and reverses any switch charge posted to GL. Same-day only, by explicit design: reversing a switch from an earlier day would price against today's NAV, making it a new trade wearing a reversal's clothes, not a real undo. Stays single-actor (not maker≠checker) — an administrative undo, not a new financial decision.
Payment & Banking Administration
How, when, and from where premiums are collected — and where money is sent back to.
Temporarily suspends the requirement to pay premiums. No financial calculation — a status flag only.
Ends an active payment holiday and resumes the normal premium schedule.
Updates how premiums are collected.
Changes which day of the month premiums fall due.
Updates the bank account for future payables. The account is checked for a valid bank code and, where the verification service is configured, that it genuinely belongs to the policyholder.
Same real bank-account verification as Update IBAN, used when the request is specifically about correcting an account number.
Coverage & Plan Changes
Changes that reshape the policy itself. None of these compute a new premium (see each card's own honest note); all are validated against the real, currently configured limits.
Changes the ongoing premium amount.
Rejected on approval if the new amount falls outside the product's own configured minimum/maximum contribution. No premium is recalculated — the rating engine that prices a new policy isn't re-run for an existing one.
Changes the coverage amount.
Adds an optional coverage from the plan's own catalog.
Moves the policy to a different plan or product.
Customer & Policy Data
Keeping the people behind the policy accurate and verified.
Updates the policyholder's Know-Your-Customer verification status. Tracked per individual customer — not applicable to a Group/master policy.
Submitting this request does not flip KYC status by itself. Only Approving it does. If a downstream check (e.g. Surrender's eligibility) still fails right after raising this, check whether it's still sitting at Submitted.
Adds, removes, or updates the policy's beneficiaries.
Cancellation & Termination
The four ways a policy's life can end early — each with its own real rule for what, if anything, gets refunded.
Ends the policy in exchange for its current cash value, calculated automatically per product type. The full engine has its own dedicated guide; summarized here for the directory.
Reverses a completed Surrender — restores the policy, its investment holdings, and the related payable exactly as they were. Its own approval stays single-actor by design (not maker≠checker), since it's an administrative undo, not a new financial decision.
Cancels a policy within its cooling-off window (a fixed number of days from the policy's start date) and refunds every premium collected in full. Automatically blocked once the window has closed.
Voids a policy for a material misstatement at application. Same full-refund formula as Cooling-Off above — no time window, since this is an underwriting-decision voidance, not a customer-initiated one.
Guardrails We Enforce
Rules that cut across many request types above — every one of them is a live check against real data, not a policy written down and hoped for.