Life & P&C underwriting

A premium you can re-derive years later.

Versioned rate books and a deterministic factor waterfall for Life and P&C — every rating run stored with its named steps, delegated authority evaluated as a rule set before bind, and a requirements ledger that reports what is actually outstanding.

Book a demoSee the platformInteractive demo
app.aegisnow.ai/dashboard

Underwriting Command Center

Live

Cases in queue

412

↓-38

Rate books effective

1 / line

Avg time to decision

2.6d

↓-1.4d

Fac referrals open

27

Applications decided per week, last 8 weeks

Trend

AegisNow Underwriting Workbench is an underwriting platform for Life and P&C carriers. Rate books are versioned data rather than a release, and a candidate book cannot be promoted unless its regression pack passed after the last edit. Every rating run stores its named steps and the book version that produced it, so a premium is reproducible on demand. Delegated authority is a rule set returning within-authority, refer or decline — naming the rule that broke — and evidence requirements are tracked on a ledger that reports what is outstanding and overdue.

0 waysa rate book promotion can be refused

Illustrative outcome. We will map Underwriting Workbench to your own data, frameworks and targets in a working demo.

Why teams choose it

The case for Underwriting Workbench

Rate, decide and refer on one governed underwriting desktop.

Pricing changes are data, not releases

Rate books are versioned records moving through draft, filed, approved, effective and superseded, with exactly one book effective per line at a time.

The promotion gate you cannot walk around

A book cannot be promoted if its regression pack was never run, failed, or predates the last edit — so passing the tests then tweaking a factor is closed off.

Every premium is reproducible

Each rating run stores its named steps and the rate book code and version behind them, which is what a rate examiner or a coverage dispute actually asks for.

Authority evaluated, not remembered

Permitted lines, jurisdictions, maximum limit and maximum premium are evaluated per submission, returning within, refer or decline and naming the rule that broke.

Capacity checked against the real programme

Retention, jumbo and auto-bind limits come from the actual treaty book — the same treaty model the claims side uses to pursue recoveries.

Extraction that admits uncertainty

Inbound submissions become fields with a per-field confidence, and low-confidence ones are held for review rather than written through as certain.

Inside the module

Capabilities that ship on day one

Every capability runs on the shared data fabric, the governed Cortex brain and the evidence ledger — so Underwriting Workbench compounds with the rest of the platform.

Submission intake & extraction

Inbound submissions become structured fields with a confidence per field, and low-confidence ones go to a human.

Learn more

Rating engine & rate books

A deterministic factor waterfall over versioned rate books, and promotion is refused unless the regression pack passes.

Learn more

Appetite rules & binding authority

Delegated authority as a rule set evaluated on every submission: within, refer or decline.

Learn more

Evidence requirements ledger

Every requirement tracked with status, age and SLA — and ordering is a recorded action, not a vendor integration.

Learn more
app.aegisnow.ai/dashboard

Underwriting Command Center

Live

Cases in queue

412

↓-38

Rate books effective

1 / line

Avg time to decision

2.6d

↓-1.4d

Fac referrals open

27

Applications decided per week, last 8 weeks

Trend

Underwriter case workbench

Queues, requirements, notes and decisions on one case record with its own event trail.

Learn more

Facultative & treaty capacity

Retention, jumbo and auto-bind limits checked against the real treaty programme before the pen moves.

Learn more

Model registry & governed decisions

Every model versioned with a champion/challenger role, and a governed write-back that can refuse.

Learn more

Quote, illustration and issue handoff

One record from quote through decision to issued policy, with the rating run travelling with it.

Learn more
Capability detail

What each capability actually does

Each section below is directly linkable, so a specific answer can be cited on its own rather than buried in a page.

Capability 01

Submission intake & extraction

Inbound submissions become structured fields with a confidence per field, and low-confidence ones go to a human.

A submission arrives as an ACORD form, a broker email, a schedule of values or a loss run, and the first job is turning it into fields something can reason about. Extraction returns each field with the value, the method that produced it and a confidence — and the confidence is used, not decorative: fields below the bar are held for review rather than written through as though they were certain.

Extracted parties are resolved against the existing book rather than created blindly. Candidate matches are returned with their scores so an operator sees why a submission was linked to an existing insured, and an ambiguous match is a decision someone makes rather than a silent merge of two accounts.

Nothing is applied to a real submission until a human accepts it. Extraction produces a proposal; the apply step is separate, gated and audited. That separation is the point — it means an extraction error is a rejected suggestion rather than a corrupted submission that has to be traced back later.

What it does

  • Extract structured fields from inbound submission documents, each with its value, method and confidence.
  • Hold low-confidence fields for review instead of writing them through as certain.
  • Resolve extracted parties against the existing book and return candidate matches with scores.
  • Keep extraction as a proposal, with a separate, gated and audited apply step.
  • Record the extraction run so a field's origin is answerable later.

Implements

  • ACORD submission forms
  • Per-field confidence and method provenance
  • Human-accepted apply step

See it in the product

Run extraction on a submission and look at the result before applying it: each field carries its method and confidence, and the submission itself is unchanged until the apply step is called.

Capability 02

Rating engine & rate books

A deterministic factor waterfall over versioned rate books, and promotion is refused unless the regression pack passes.

A rate book is a versioned record per line of business: a base rate, the factor tables that modify it, the increased-limit ladder and the loadings. Changing a price is a data change, not a release. Books move through draft, filed, approved, effective and superseded, and only one book per line is effective at a time — promoting a new one supersedes the outgoing one in the same transaction.

The engine reading it is a deterministic factor waterfall with no hidden state. A property risk is rated as total insured value per thousand at the base rate, then multiplied by occupancy, construction, protection-class band and territory, then by the increased-limit factor for the chosen limit, before catastrophe, expense and profit loadings reach the technical premium. A life risk starts from a mortality rate interpolated between age nodes for the smoker status, then class factor, then table rating in configurable steps, plus flat extras. Every step is named, returned and stored with the run alongside the rate book code and version — so a premium quoted today can be re-derived years from now, which is what a rate examiner or a coverage dispute actually asks for.

What stops a bad rate reaching the book is the regression pack. Representative risks are pinned with an expected premium and a tolerance, and the pack runs against a candidate book. Promotion is refused three ways: if the pack was never run, if it failed, or if the book has been edited since the last run. That last one matters most — it means you cannot pass the tests, tweak a factor and promote anyway.

What it does

  • Version a rate book through draft, filed, approved, effective and superseded, with one effective book per line.
  • Rate property risks on occupancy, construction, protection class 1–10, territory and increased-limit factors, then CAT, expense and profit loadings.
  • Rate life risks on mortality interpolated by age and smoker status, class factor, table-rating steps and flat extras.
  • Store every rating run with its named steps and the rate book code and version that produced it.
  • Re-quote any submission against any rate book without persisting anything, so a proposed change can be tested against real risks.
  • Refuse promotion when the regression pack was never run, failed, or predates the last edit to the book.
  • Supersede the outgoing book and roll back to it later, both as role-gated, audited transactions.

Implements

  • Increased-limit factor (ILF) ladders
  • Protection class 1–10 banding
  • Age and smoker mortality interpolation
  • Rate book lifecycle: draft → filed → approved → effective → superseded

See it in the product

Edit a factor on an approved rate book and try to promote it. Promotion is refused because the book now postdates its last regression run — passing the pack and then tweaking is exactly the path that is closed.

Capability 03

Appetite rules & binding authority

Delegated authority as a rule set evaluated on every submission: within, refer or decline.

Appetite and delegated authority are modelled as a rule set rather than a PDF in a shared drive: the lines that may be written, the jurisdictions permitted and excluded, the maximum policy limit and the maximum premium. Every submission is evaluated against its programme's rule set before it can be bound.

The verdict is three-valued, and the distinction is the whole point. A line outside the binder or an excluded jurisdiction is a decline. A jurisdiction outside the permitted list, a limit above the maximum or a premium above the maximum is a referral. Anything else is within authority. The evaluation names the specific rule that broke and the value that broke it, rather than a generic warning that something somewhere is wrong.

That verdict gates the bind. A referred risk cannot be bound until the referral is explicitly acknowledged, and a declined risk cannot be bound at all. The platform also drafts the referral memorandum listing each breach, so the request going to the capacity provider is written from the same facts that produced the verdict rather than retyped from memory.

What it does

  • Model each programme's authority as permitted lines, permitted and excluded jurisdictions, a maximum limit and a maximum premium.
  • Evaluate every submission against its programme and return within authority, refer, or decline.
  • Name the breached rule and the breaching value rather than returning a generic warning.
  • Require an explicit referral acknowledgement before a referred risk can be bound, and block a declined risk outright.
  • Draft the referral memorandum listing every breach, ready for the capacity provider.

Implements

  • Binder schedules: lines, territories, limits, premium
  • Three-valued authority verdict
  • Referral acknowledgement before bind

See it in the product

Submit a risk with a limit above the programme maximum. The verdict comes back as refer, naming the limit rule and the actual value, and the bind is unavailable until the referral is acknowledged.

Capability 04

Evidence requirements ledger

Every requirement tracked with status, age and SLA — and ordering is a recorded action, not a vendor integration.

Underwriting evidence is managed as a requirements ledger against the case: what is needed, why, who it was requested from, when it was ordered, when it arrived, and how long it has been outstanding. Requirements carry status through required, ordered, received and waived, each transition stamped with the user who made it, and the case view surfaces what is overdue rather than leaving an underwriter to notice.

Life and P&C requirements sit on the same ledger with different vocabularies — attending physician statements, laboratory panels, prescription histories, MIB and motor vehicle records on one side; loss runs, statements of values, schedules and inspection reports on the other. The summary view aggregates by status and category and reports what is outstanding and overdue, which is what an operations lead actually needs to work a queue.

One thing this deliberately does not claim: ordering is a recorded action inside the platform, not a call to a vendor. Marking a requirement ordered records the intent, the vendor named and the timestamp — it does not transmit a request to a bureau or laboratory. Connecting a real evidence vendor is integration work with credentials and contracts behind it, and until that exists the ledger tracks the process honestly rather than implying an automation that is not there.

What it does

  • Track every requirement through required, ordered, received and waived, stamped with the user who moved it.
  • Carry Life and P&C evidence types on one ledger — APS, labs, prescription history, MIB and MVR alongside loss runs, SOVs, schedules and inspections.
  • Report outstanding and overdue requirements by status and category for queue management.
  • Age each requirement against its due date so what is late is visible without being sought.
  • Record the vendor named on an order and the time it was placed, as an internal record of intent.

Implements

  • Life evidence: APS, labs, prescription history, MIB, MVR
  • P&C evidence: loss runs, statements of values, schedules, inspections
  • Requirement lifecycle with SLA ageing

See it in the product

Open the requirements summary on a case: counts by status and category, what is outstanding, and what is overdue. Ordering a requirement records the vendor and timestamp on the row — no external request is made, and the platform does not claim one was.

Capability 05

Underwriter case workbench

Queues, requirements, notes and decisions on one case record with its own event trail.

A case is the unit of underwriting work: the submission, the risk, the requirements, the notes, the rating runs and the decision, held together with an event trail rather than scattered across a mailbox and a spreadsheet. Queues are worked by ownership and age, and a case carries its own SLA clock so ageing is a property of the work rather than a report someone runs weekly.

Decisions are recorded with their rationale and the state of the file at the time — which rate book version produced the premium, which requirements were satisfied, which authority verdict applied. That combination is what makes a decision reconstructable rather than merely logged: a decision with a timestamp and no context answers when, and nothing else.

Life-specific assessment sits on the same record. Impairment ratings, debits and credits, and financial underwriting worksheets are captured against the case, so the mortality assumption a premium rests on is visible next to the premium rather than derived somewhere else and typed in.

What it does

  • Hold submission, risk, requirements, notes, rating runs and decision on one case record with an event trail.
  • Work queues by ownership and age, with an SLA clock on the case itself.
  • Record each decision with its rationale and the file state that produced it, including the rate book version.
  • Capture impairment ratings, debits and credits, and financial underwriting worksheets against the case.
  • Keep the trail append-only, so the history of a decision is not editable after the fact.

Implements

  • Impairment debits and credits
  • Financial underwriting worksheets
  • Append-only case event trail

See it in the product

Open a decided case and read its trail: the decision, the rationale, the requirements that were satisfied, and the rate book code and version behind the premium — all on the record rather than reconstructed.

Capability 06

Facultative & treaty capacity

Retention, jumbo and auto-bind limits checked against the real treaty programme before the pen moves.

Capacity is checked against the actual treaty programme rather than an underwriter's memory of it. Treaties carry their retention, their cession percentage, the jumbo limit and the auto-bind limit, and a risk is measured against them: within auto-bind, above auto-bind and needing facultative placement, or above the jumbo limit and outside the programme entirely.

Facultative referrals carry the file. A submission pack goes to the reinsurer with the risk, the rating run and the evidence position attached, and the reinsurer's response is tracked against the case rather than living in an inbox. The case cannot quietly proceed as though placed while the response is outstanding.

The same treaty structures drive the claims side, which is what keeps the two consistent. Quota share, excess of loss and aggregate stop loss are modelled once; the cession an underwriter relies on at bind and the recovery a claims handler pursues after a loss read the same programme, rather than two systems each holding their own view of what was ceded.

What it does

  • Model treaty retention, cession percentage, jumbo limit and auto-bind limit per treaty.
  • Measure a risk against the programme and classify it as within auto-bind, facultative, or beyond the jumbo limit.
  • Send a facultative submission pack carrying the risk, rating run and evidence position.
  • Track the reinsurer's response against the case rather than in an inbox.
  • Share one treaty model with the claims-side recovery engine, so bind and recovery read the same programme.

Implements

  • Retention, jumbo and auto-bind limits
  • Quota share, excess of loss, aggregate stop loss
  • Facultative submission and response tracking

See it in the product

Rate a life risk above the auto-bind limit on its treaty. It is classified as requiring facultative placement, and the referral carries the rating run rather than a re-keyed summary.

Capability 07

Model registry & governed decisions

Every model versioned with a champion/challenger role, and a governed write-back that can refuse.

Underwriting models are held in a registry rather than deployed and forgotten: framework, version, line of business, status, and a champion or challenger role, so which model is actually in force is a fact on record. Promotion between roles is an audited action, and a model's history is visible rather than replaced.

Where a model informs a real write, the write goes through a governed evaluation that can refuse it. This is the same control the claims side uses, and it is deliberately shared: an automated action either passes the gate or does not happen, and the run is recorded with its inputs, its citations and its outcome. An agent run that cannot cite what it read is not evidence of anything, which is why citation is part of the record rather than an optional extra.

One honest limit. The registry stores model performance metrics, but in the demo dataset those metrics are seeded rather than measured — drift in particular is generated, not observed. Real drift monitoring means a scoring pipeline comparing live feature distributions against a training baseline on a schedule, and that pipeline is not part of what ships here. The registry is the place such measurements belong; it does not manufacture them.

What it does

  • Register each model with its framework, version, line of business, status and champion or challenger role.
  • Make promotion between roles an audited action with visible history.
  • Route model-informed writes through a governed evaluation that can refuse the action.
  • Record each governed run with its inputs, citations and outcome.
  • Store model performance metrics against the registered model rather than alongside it.

Implements

  • Champion / challenger model roles
  • Governed write-back evaluation
  • Run-level citation of inputs

See it in the product

Open the model registry and check which model holds champion for a line of business, then look at a governed run: it names the model version, the inputs it read and the outcome the gate returned.

Capability 08

Quote, illustration and issue handoff

One record from quote through decision to issued policy, with the rating run travelling with it.

A quote is not re-derived on the way to a policy. The rating run that produced the premium travels with the case through decision and into issue, so the number on the schedule is the number the engine produced, traceable to the rate book code and version that produced it.

Life illustrations run from the same product definition as the policy that follows, which is what stops the two drifting. An illustration produced under one product edition and a policy issued under another is a common source of disputes, and the platform holds the edition rather than the assumption.

Issue hands to policy administration as a continuation of the same record rather than a re-entry. The policy carries the submission, the decision and the rating provenance forward, so a servicing question years later can reach the underwriting file that answers it.

What it does

  • Carry the rating run from quote through decision to issue, with its rate book code and version.
  • Run life illustrations from the same product definition the issued policy will use.
  • Hand the case to policy administration as a continuation, not a re-keyed entry.
  • Keep the submission, decision and rating provenance reachable from the issued policy.

Implements

  • Effective-dated product editions shared with policy admin
  • Rating provenance carried to issue

See it in the product

Open an issued policy and follow it back: the decision, the case and the rating run that produced the premium are all reachable, with the rate book version that priced it.

Built for the people who own the risk

Made for your team, aligned to your frameworks.

Cortex skill-agents draft the work, cite their sources and write every action to the evidence ledger — so Underwriting Workbench accelerates the people accountable for it without putting your audit posture at risk.

Who it serves

  • Chief Underwriting Officers
  • Life & P&C underwriters
  • Underwriting operations leaders
  • New-business teams
  • Reinsurance managers

Aligned to

  • NAIC model laws
  • VM-20 / PBR
  • NY Reg 187
  • HIPAA (evidence data)
  • State DOI rate & form rules
CortexAI reasoning copilot
Grounded

Shared device fingerprint with the ring94
Repair shop tied to a prior SIU case87
Loss pattern matches the closed cluster81
SourcesPolicy ledgerClaims graphSIU casebook
Confidence94%
Works better together

Pairs with the rest of the platform

Underwriting Workbench shares one core with every other module — combine it to extend coverage without adding integration debt.

Smart Claims

Every decision on the file has an author, a rule and a record.

Policy Administration

Service the book, launch products and run MGA programs on one core.

Actuarial Platform

Every assumption versioned, every run reproducible, every sign-off logged — and uncertified data refused.

Cortex AI

AI that drafts and assists across insurance — but never decides ungoverned.

For your industrySee how Underwriting Workbench works in regulated sectors.
Life, annuity & retirement carriers

Life & Annuities

From accelerated underwriting to automated death claims.

Explore Life & AnnuitiesPersonal & commercial lines carriers

P&C Insurance

Quote-to-claim on one core, with the combined ratio in view.

Explore P&C InsuranceTreaty, facultative & life reinsurance

Reinsurers

See assumed portfolios clearly — and settle them cleanly.

Explore Reinsurers
FAQ

Underwriting Workbench FAQ

What evaluation teams want to know before a demo — answered plainly.

Yes. Life evidence (APS, labs, prescription histories, MIB, MVR) and P&C evidence (loss runs, statements of values, schedules, inspections) sit on the same requirements ledger and run through the same case management, rating and referral fabric, with line-specific rules and paths.

Yes, and that is the design goal. Every rating run stores its named steps — base rate, each factor, each loading — alongside the rate book code and version that produced it. A rate examiner or a coverage dispute asks how this number was reached, and the answer is on the run rather than reconstructed from a spreadsheet.

The regression pack. Representative risks are pinned with an expected premium and a tolerance, and promotion is refused three ways: if the pack was never run, if it failed, or if the book has been edited since the last run. The third is the important one — you cannot pass the tests, tweak a factor and promote anyway.

No, and it does not claim to. Marking a requirement ordered records the intent, the vendor named and the timestamp on the ledger; it does not transmit a request to a bureau or laboratory. Connecting a real evidence vendor is integration work with credentials and contracts behind it. What ships is honest tracking of the process, including what is outstanding and overdue.

A risk is measured against the treaty's actual retention, jumbo and auto-bind limits and classified as within auto-bind, needing facultative placement, or beyond the programme. The referral carries the rating run and evidence position rather than a re-keyed summary, and the reinsurer's response is tracked against the case.

Each model is registered with its framework, version, line of business and champion or challenger role, and promotion between roles is audited. Model-informed writes pass through a governed evaluation that can refuse the action, and each run records its inputs and citations. One limit stated plainly: performance metrics in the demo dataset are seeded, not measured — real drift monitoring needs a scoring pipeline comparing live feature distributions against a training baseline, and that is not part of what ships.

See Underwriting Workbench on your data

Book a working session and we will map your sources, workflows and frameworks onto Underwriting Workbench — and show Cortex reasoning over them live.

Book a demoExplore the platformInteractive demo
Underwriting Workbench — Rate, decide and refer on one governed underwriting desktop. | AegisNow Insurance