Life & P&C claims

Claims you can prove, not just process.

FNOL to adjudication, reserving, payment and recovery on one engine — coverage verified against the policy in force on the loss date, reserves that always match their ledger, payments checked against real limits, and statutory deadlines computed on real business-day calendars.

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

Claims Command Center

Live

Coverage verified

100%

Avg cycle time

4.1d

↓-2.3d

Ledger drift

0

Deadlines on calendar rules

448

Claims throughput, last 8 weeks

Trend

AegisNow Smart Claims is an end-to-end claims platform for Life and P&C carriers covering FNOL, adjudication, reserving, payment and recovery. Coverage is verified at first notice against the product edition in force on the loss date and the check is kept; every reserve movement is recorded on a ledger the claim must agree with; payments are refused when they would breach a limit; and an AI-influenced adverse decision cannot be written without a named human review by someone holding the authority the decision required.

0%of reserve movements recorded on the ledger

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

Why teams choose it

The case for Smart Claims

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

Coverage decided from the terms in force

The policy version and product edition in force on the loss date govern the claim — so a term changed afterwards cannot retroactively alter what was covered.

Reserves that match their ledger

One writer, typed movements, and an invariant asserted across the whole book: the claim's reserve always equals its latest recorded movement.

Payments checked against real limits

Each payment is tested against the limit and sublimit net of prior payments, and refused if it would breach them — with the numbers behind the refusal.

Adverse decisions carry a named reviewer

AI influence is detected rather than declared, and a denial it touched needs a human review by someone holding the same authority the decision required.

Deadlines computed, not estimated

Business days against jurisdiction holiday calendars, effective-dated rules matched on the loss date, and an explicit marker wherever a statutory anchor is substituted.

Evidence that survives scrutiny

Documents carry a content hash, an explicit scan verdict and a retention clock that actually deletes — and nothing is rendered as clean that was never scanned.

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 Smart Claims compounds with the rest of the platform.

FNOL intake & coverage verification

Coverage checked against the policy in force on the loss date, and the check itself is kept.

Learn more

Adjudication under recorded authority

Who may decide is a capability ladder, and an AI-influenced denial needs a named human review before it lands.

Learn more

The reserve ledger

One writer, one ledger: the claim's reserve always equals its latest recorded movement.

Learn more

Payments against real limits

One payment ledger, and a payment that would breach the coverage limit is refused rather than recorded.

Learn more
app.aegisnow.ai/claims

Claims Command Center

Live

Coverage verified

100%

Avg cycle time

4.1d

↓-2.3d

Ledger drift

0

Deadlines on calendar rules

448

Claims throughput, last 8 weeks

Trend

Document evidence you can prove

Real bytes, a content hash, an explicit scan verdict, and a retention clock that actually deletes.

Learn more

Statutory deadlines on real calendars

Business days against jurisdiction holiday calendars, effective-dated rules, and an honest anchor.

Learn more

Recovery: subrogation, salvage and reinsurance

Recoveries as tracked positions against the claim, including cessions to the reinsurance programme.

Learn more

Correspondence, appeals and what was actually sent

Delivery state lives on the record, so a drafted letter can never read as a delivered one.

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

FNOL intake & coverage verification

Coverage checked against the policy in force on the loss date, and the check itself is kept.

A claim opens with a reference allocated from a per-organisation sequence and an idempotency key, so a portal submission retried after a timeout cannot open the same loss twice. Loss date, cause of loss, jurisdiction, reporting channel and the insured and claimant identities are captured at intake rather than filled in later, because every downstream control keys off one of them — coverage off the loss date, the deadline clock off the jurisdiction and the report date, the authority tier off the exposure.

Coverage is verified at first notice instead of assumed. The platform resolves the policy version in force on the LOSS DATE — not the current version — and reads limits, sublimits, deductibles, exclusions and conditions from the effective-dated product edition that policy was written on. Product editions are immutable once written, so a term amended after the loss cannot retroactively change what the claim was entitled to.

The check is kept, not just acted on. Each verification is an append-only row recording what was tested, what was found and why coverage was accepted or refused — check by check. That record is what lets the platform refuse an overpayment months later and show the reasoning, and it is the difference between a coverage position you assert and one you can produce.

What it does

  • Allocate a claim reference from a per-org sequence and reject a duplicate submission through an idempotency key.
  • Resolve the policy version in force on the loss date rather than the version in force today.
  • Read limits, sublimits, deductibles, exclusions and conditions from the effective-dated product edition the policy was written on.
  • Record every coverage decision as an append-only verification row naming the test, the finding and the reason.
  • Capture jurisdiction and reporting channel at intake, which the statutory-deadline engine anchors on.
  • Open the claim's event trail at intake, so the file starts as a record rather than a state.

Implements

  • Effective-dated policy and product terms
  • Immutable product editions
  • Append-only coverage decision record

See it in the product

Open a claim under Claims and look at its coverage panel. The limits shown are read from the product edition in force on the loss date, and the verification history lists each check with its finding — not a single 'covered' flag.

Capability 02

Adjudication under recorded authority

Who may decide is a capability ladder, and an AI-influenced denial needs a named human review before it lands.

Adjudication is an act by an identified person under a recorded authority, not a score crossing a line. The decision — approve, deny or partial — is made by a user holding the capability for it, and the required tier rises with the claim: exposure, litigation, catastrophe linkage and SIU status each push the decision up the ladder. A user without the tier is refused, and the refusal names the factor that raised it.

Where an AI system influenced an adverse decision, the platform detects that rather than trusting the caller to declare it. Omitting the run identifier does not make a decision AI-free: governed runs citing the claim are found anyway. An AI-influenced denial, partial reduction or SIU referral cannot be written without a recorded human review, and the reviewer must hold the same capability the decision itself required — a determinative model output escalates the review to supervisor. There is no second, weaker approval ladder for AI.

What lands is an adverse-decision register entry and, alongside it, a consumer-recourse record opened in the same transaction: what the consumer was told, through what channel, and whether they contested it. Its notice fields start empty on purpose. An internal notification row is not evidence that anyone was actually told, and the record refuses to imply otherwise.

What it does

  • Raise the required authority tier from claim exposure, litigation status, catastrophe linkage and SIU flag, and name the factor that raised it.
  • Refuse a decision from a user who does not hold the capability, rather than logging a warning and proceeding.
  • Detect AI influence from governed runs citing the claim, so an omitted run identifier does not launder the decision.
  • Block an AI-influenced denial, partial or SIU referral that has no recorded human review.
  • Require the reviewer to hold the same capability the decision required, escalating to supervisor for determinative model output.
  • Open a consumer-recourse record in the same transaction as the adverse decision, with notice fields empty until a notice is actually recorded.
  • Write the decision, the event and the register entry as one transaction, or none of them.

Implements

  • NAIC Model Bulletin on the use of AI by insurers (alignment, not certification)
  • Adverse action record with consumer recourse
  • Capability-gated decision authority

See it in the product

Attempt an AI-influenced denial with no human review recorded: the API returns 403 adverse_decision_review_missing and the claim is unchanged. Approve the review as a user without claims authority and it returns 403 adverse_decision_reviewer_unauthorised.

Capability 03

The reserve ledger

One writer, one ledger: the claim's reserve always equals its latest recorded movement.

Every change to a reserve is a movement on a ledger, and the ledger is the only way a reserve moves. One function appends the movement and updates the claim in the same transaction; nothing else may set the figure. The invariant — the claim's reserve equals the newAmount of its latest movement — is asserted by a test that runs against the whole book, not stated in a comment.

Movements are typed, so the history answers why and not merely how much: an initial set, an increase on adverse development, a decrease, a drawdown caused by a payment, and a close. A drawdown carries the identifier of the payment that caused it, which makes cause and effect linkable rather than inferable from timestamps. Each movement records the amount either side of it, read from the claim rather than from the previous ledger row — so a gap in the history cannot silently propagate into the next movement's arithmetic.

This exists because the invariant was quietly false. The payment path used to compute the new reserve and write it onto the claim without appending anything, so the reserve moved and the ledger never knew. Reconciliation ran toward the claim, not the ledger: the cached figure was what the business had acted on, so the fix appends the missing movement rather than rewriting history to fit the record. Reconstructed movements are stamped as reconstructed and are distinguishable from ones captured as they happened.

What it does

  • Append the movement and move the claim in one transaction, through the single reserve writer.
  • Type each movement as set, increase, decrease, payment drawdown or close.
  • Link a drawdown to the payment that caused it.
  • Record the amount either side of every movement, read from the claim so a ledger gap cannot propagate.
  • Keep incurred equal to paid plus reserve as the reserve moves.
  • Refuse to drive a reserve below zero.
  • Report any claim whose cached reserve disagrees with its latest movement, as a checkable query rather than an assertion in prose.
  • Distinguish reconstructed history from movements captured at the time.

Implements

  • Case reserve movement ledger
  • Incurred = paid + reserve
  • Provenance-stamped reconstructed history

See it in the product

Open Reserving and take any claim with payment history. Every figure the claim shows has a movement behind it, typed and dated, and a payment drawdown names the payment that caused it.

Capability 04

Payments against real limits

One payment ledger, and a payment that would breach the coverage limit is refused rather than recorded.

Claim payments run through a single canonical ledger that also produces the general-ledger postings and the disbursement record, so the money movement, the accounting entry and the payee instruction come from one write rather than three systems agreeing later. A payment draws the reserve down as a typed movement on the reserve ledger in the same transaction.

Payments are checked against the coverage that was verified at first notice — the limit and sublimit from the product edition in force on the loss date, less what has already been paid. This is not a display concern. When the check was introduced it found two claims already paid over their each-occurrence limit, and the derived limits on file had been raised to fit the payments rather than the payments constrained by the limits.

Recovery flows back through the same ledger. Subrogation, salvage and reinsurance recoveries are recorded against the claim they belong to, so net incurred is a computed position rather than a figure someone maintains alongside the gross one.

What it does

  • Write the payment, the GL posting and the disbursement from one transaction.
  • Draw the reserve down as a typed movement linked to the payment.
  • Check each payment against the limit and sublimit from the product edition in force on the loss date, net of prior payments.
  • Refuse a payment that would breach the limit rather than recording it and reporting the breach afterwards.
  • Record subrogation, salvage and reinsurance recoveries against the claim so net incurred is computed.
  • Keep the payment history immutable and attributable to the user who authorised it.

Implements

  • Canonical payment ledger with GL postings
  • Per-occurrence and aggregate limit checking
  • Sublimit and deductible application

See it in the product

Attempt a payment that would take a claim past its each-occurrence limit. It is refused with the limit, the paid-to-date and the shortfall — the numbers the refusal was based on, not a generic error.

Capability 05

Document evidence you can prove

Real bytes, a content hash, an explicit scan verdict, and a retention clock that actually deletes.

A claim document is stored content, not a filename. Uploads are written through an object-storage layer that returns a SHA-256 of what was actually stored, the size measured from the bytes rather than declared by the client, and the content type sniffed from the file — a PNG uploaded as text/plain is recorded as the mismatch it is. Downloads are issued as short-lived signed URLs rather than open paths.

Every document carries its evidence state explicitly, and the interface refuses to round it up. A record with no stored object reads as no file attached, with no download button — not a button that fails. A scan status of skipped renders as not scanned, never as clean, because the absence of a verdict is not a pass. A size figure that was declared rather than measured is labelled as declared. None of these states is inferred from another: a digest proves the object is unchanged, which is not the same as proving the content is what it claims.

Retention is enforced rather than described. Each document carries a retention class, a retain-until date and a legal-hold flag; a sweeper purges expired documents, deletes the bytes, nulls the storage pointer and appends an audit event naming what was deleted. The content hash deliberately survives the purge — the row becomes a tombstone that can still identify the document if a copy surfaces later. A document under legal hold is never purged, and the guard is asserted again at the delete site rather than trusted to the selection query.

What it does

  • Hash stored content with SHA-256 and measure size and content type from the bytes, not from the client.
  • Issue downloads as short-lived signed URLs rather than open storage paths.
  • Render a record with no stored object as no file attached, with no download control at all.
  • Render an unscanned document as not scanned rather than clean, and never derive a safety badge from the digest.
  • Purge expired documents on a schedule, delete the bytes and append an audit event naming what was deleted.
  • Keep the content hash after purge so the row remains identifiable as a tombstone.
  • Refuse to purge a document under legal hold, asserted at the delete site and not only in the selection query.
  • Record a declared-but-unmeasured size as declared, so it cannot be mistaken for a measurement.

Implements

  • SHA-256 content addressing
  • Retention classes with legal hold
  • Signed, expiring download URLs

See it in the product

Upload a file on a claim's Documents page, then request its download: you get a signed URL and bytes whose hash matches the digest on the row. Ask for a legacy record with no stored object and the API returns 409 with the reason, and the page shows no file attached rather than a broken download.

Capability 06

Statutory deadlines on real calendars

Business days against jurisdiction holiday calendars, effective-dated rules, and an honest anchor.

Claims-handling deadlines are computed, not estimated. Rules are effective-dated and matched on the loss date, each carrying its jurisdiction, the triggering claim event, the number of days, whether those days are business or calendar days, and the rule for rolling a due date that lands on a weekend or holiday. Nine calendars covering more than 1,200 holidays back the arithmetic, with observed-date handling verified against history rather than assumed.

The distinction between business and calendar days is the point. Fifteen business days from a Monday is twenty-one calendar days, so a rule whose own text says business days and is measured in calendar days holds the file to a window a week shorter than the law allows. Deadlines are also bound to the obligation the rule describes, not inferred by pattern-matching its display name — renaming a rule in an admin screen must not silently change what the compliance report measures.

Where a statutory anchor is not held, the platform says so on the row rather than substituting silently. Accept-or-deny is anchored by statute on receipt of proof of loss; where that fact is not recorded, first notice is substituted and every affected deadline is flagged as substituted — which makes the resulting breach count an upper bound and labels it as one.

What it does

  • Match effective-dated deadline rules on the loss date, per jurisdiction and claim event.
  • Count business days against the jurisdiction's holiday calendar, with observed-date rules for weekend-adjacent holidays.
  • Roll a due date landing on a non-business day according to the rule's own roll convention.
  • Bind each rule to the obligation it describes rather than inferring it from the rule's name.
  • Flag every deadline computed from a substituted anchor, and report the resulting counts as upper bounds.
  • Persist the computed status so the compliance view and the claim file cannot disagree.
  • Record the statutory citation on a rule, or leave it null rather than storing a description of a body of law as if it were a citation.

Implements

  • NAIC Model 900 claims-handling timeframes
  • State prompt-pay and unfair-claims-practice deadlines
  • Business-day arithmetic with observed-date holidays

See it in the product

Open Compliance Monitor. Each deadline shows the rule, its jurisdiction, whether it counts business or calendar days, the calendar used, and — where the statutory anchor is not held — an explicit substituted-anchor marker.

Capability 07

Recovery: subrogation, salvage and reinsurance

Recoveries as tracked positions against the claim, including cessions to the reinsurance programme.

Recovery is treated as part of the claim rather than a follow-on task. Subrogation and salvage cases open against the claim they belong to, carry their own status and events, and post recoveries back to the claim ledger so gross and net incurred are both derivable from the same record.

Reinsurance recovery runs against the real treaty programme rather than a spreadsheet of expected credits. Cessions are computed from the treaty structure — quota share, excess of loss and aggregate stop loss — and recoveries move through a status graph that refuses illegal transitions: a draft recovery cannot be billed without first being notified and acknowledged, and every transition leaves a trail entry.

The engine holds a hard identity: gross loss equals ceded plus net, tested rather than asserted. That test exists because the engine once reported the entire gross book as ceded and zero net retained loss — an aggregate stop loss with no attachment point had been coerced to attach at zero. A treaty missing the term that makes it computable is now skipped and reported as skipped, not silently attached at a default.

What it does

  • Open subrogation and salvage cases against the claim, with their own status, events and recoveries.
  • Post recoveries back to the claim ledger so gross and net incurred both derive from one record.
  • Compute cessions from quota share, excess of loss and aggregate stop loss treaty structures.
  • Enforce the recovery status graph — draft, notified, acknowledged, billed, collected — and refuse transitions that skip a step.
  • Leave a trail entry on every recovery transition.
  • Skip and report a treaty whose terms make it uncomputable, rather than attaching it at a defaulted value.

Implements

  • Quota share, excess of loss and aggregate stop loss
  • Gross = ceded + net identity
  • Recovery status graph with audit trail

See it in the product

Run the reinsurance apply step and check the totals: gross loss less ceded equals net, to the cent. Add a stop loss with no attachment point and it appears in the skipped list instead of absorbing the book.

Capability 08

Correspondence, appeals and what was actually sent

Delivery state lives on the record, so a drafted letter can never read as a delivered one.

Correspondence is drafted from templates and rendered to a stored object, and its delivery state is recorded on the row rather than assumed from its existence. The state machine includes a state for recorded but not transmitted, which is the one that matters: without it, a locally rendered letter and a letter a provider accepted would have to share the word sent, and that is exactly how the defect this replaced was written.

Only a provider acceptance can move a record to sent, and a database constraint makes the alternative unexpressible — a transmitted state with no provider reference is rejected by the schema, not by a code path someone can bypass. Failures record the actual provider error, retries increment an attempt count, and a delivery webhook is what advances a record to delivered.

This is load-bearing beyond the outbox. The compliance engine reads correspondence to decide whether a statutory acknowledgement was given, and it previously counted any outbound row — crediting claims with an acknowledgement on the strength of a timestamp the code had written itself. Acknowledgement now requires actual transmission, and appeals and ombudsman referrals run on the same record so the file shows what the claimant was told and when they contested it.

What it does

  • Render correspondence from templates to a stored object with a content hash.
  • Record delivery state on the row, including an explicit not-transmitted state for anything a provider never accepted.
  • Reject a transmitted state with no provider reference at the database level.
  • Record the provider's actual error on failure and increment an attempt count on retry.
  • Advance a record to delivered only on a delivery callback, never on a local action.
  • Count only genuinely transmitted correspondence toward a statutory acknowledgement.
  • Run appeals and ombudsman referrals against the same record, with the claimant's contest recorded.

Implements

  • NAIC Model 900 § 4(B) acknowledgement
  • Provider-acknowledged delivery states
  • Appeals and ombudsman referral trail

See it in the product

Send a letter with no provider configured. It records as not transmitted with a reason — not as sent — and the acknowledgement rule declines to count it toward the statutory deadline.

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 Smart Claims accelerates the people accountable for it without putting your audit posture at risk.

Who it serves

  • Chief Claims Officers
  • Claims adjusters & examiners
  • SIU & fraud investigators
  • Claims operations leaders
  • Reserving actuaries

Aligned to

  • Unfair Claims Practices
  • NAIC claims model regulations
  • HIPAA
  • State prompt-pay rules
  • GDPR
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

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

Underwriting Workbench

Rate, decide and refer on one governed underwriting desktop.

Policy Administration

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

Customer 360

One view of every policyholder, household and interaction.

Cortex AI

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

For your industrySee how Smart Claims 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 InsuranceHealth, disability & group carriers

Health & Group Benefits

Group administration, fast claims and fair outcomes at scale.

Explore Health & Group Benefits
FAQ

Smart Claims FAQ

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

An identified user holding the capability for that decision. The required authority tier rises with the claim's exposure, litigation status, catastrophe linkage and SIU flag, and a user without the tier is refused — with the factor that raised it named in the refusal, rather than a warning logged while the write proceeds.

The platform detects the influence rather than trusting the caller to declare it — omitting the run identifier does not help, because governed runs citing the claim are found anyway. The denial cannot be written without a recorded human review, and the reviewer must hold the same capability the decision required; a determinative model output escalates the review to supervisor.

Because it has to equal the newAmount of its latest ledger movement, and that invariant is asserted by a test across the whole book. One function appends the movement and moves the claim in the same transaction; nothing else may set the figure. Any claim that disagrees with its ledger is reportable as a query.

No. Each payment is checked against the limit and sublimit from the product edition in force on the loss date, net of prior payments, and a breaching payment is refused with the limit, the paid-to-date and the shortfall. When this check was introduced it found two claims already paid over their each-occurrence limit.

From effective-dated rules matched on the loss date, counting business days against the jurisdiction's holiday calendar with observed-date handling — because fifteen business days from a Monday is twenty-one calendar days. Where a statutory anchor such as proof-of-loss receipt is not recorded, first notice is substituted and the deadline is flagged as substituted rather than presented as measured.

It drafts and renders it, and records what actually happened to it. Delivery state lives on the record and includes an explicit not-transmitted state; only a provider acceptance can move a record to sent, enforced by a database constraint rather than a code path. Correspondence that was never transmitted does not count toward a statutory acknowledgement.

Claims-handling timeframes under NAIC Model 900 and state prompt-pay and unfair-claims-practice rules are computed per jurisdiction; adverse decisions are recorded in a form aligned to the NAIC Model Bulletin on the use of AI by insurers. Alignment is not certification — the bulletin is adopted state by state, and adoption analysis and the written AI systems programme remain the carrier's.

See Smart Claims on your data

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

Book a demoExplore the platformInteractive demo
Smart Claims — Every decision on the file has an author, a rule and a record. | AegisNow Insurance