Servicing, products & programs

A policy admin core you can change without a two-year project.

Endorsements, cancellations, reinstatements and renewals on a validated policy state machine — plus versioned rate books that cannot go effective until their regression pack passes, delegated-authority rules evaluated on every submission, and bordereaux generated from the cession ledger rather than a spreadsheet.

app.aegisnow.ai/dashboard

Policy Admin Command Center

Live

Policies in force

1.34M

Endorsements MTD

18,240

+6%

Renewal retention

89.2%

+2.1pts

Capacity used

71%

Renewal retention rate, last 12 months

Trend

AegisNow Policy Administration is a modern policy admin system (PAS) for carriers and MGAs. Ten policy statuses and eleven lifecycle actions run on a state machine that refuses illegal transitions and writes an append-only event for every legal one; rate books are versioned data, promoted only when a pinned regression pack passes; delegated authority is a rule set every submission is scored against; and premium, claims and risk bordereaux are aggregated from the cession ledger with the query that produced each total stored alongside it.

0%of endorsements completed same-day

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

Why teams choose it

The case for Policy Administration

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

Quoted before it is committed

A cancellation returns its full refund breakdown — earned, unearned, short-rate penalty, refund — without touching the policy. Executing it writes the record, the event and the status as one transaction, or none of them.

Price changes are data, not releases

Rate books version through draft, filed, approved, effective and superseded — and a book cannot go effective until its regression pack has been run, has passed, and is newer than the last edit to the book.

Renewals you can explain

The pipeline is banded by days to expiry and priced by a published loss-ratio band table, so an underwriter can predict the offer beforehand and defend it in a market-conduct exam afterwards.

Binders modelled as rules

Permitted lines, permitted and excluded territories, maximum limit and maximum premium are evaluated on every submission, returning within authority, refer or decline with the breached rule named.

Bordereaux with their provenance attached

Premium, claims and risk bordereaux are aggregated from the cession ledger, and each one stores the ledger and column its total came from — so "where did this number come from" has an answer on the record.

A ledger that explains the money

Every lifecycle transition appends an event carrying who, when, why, the statuses it moved between and the premium delta — and every mutating call on the insurance API is SHA-256 hash-chained.

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 Policy Administration compounds with the rest of the platform.

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

Policy servicing

Typed service requests and money-moving transactions that are quoted before they are committed.

Servicing covers the two things a policy administrator does all day: answering a service request, and changing money on a live policy. Service requests are typed and channelled — address change, beneficiary change, name change, lienholder, payment method, coverage inquiry, duplicate document, NSF, arriving by portal, phone, agent or email — and each opens with an SLA clock and closes with a completion stamp against the user who closed it.

Money changes are quoted first. Asking for a cancellation returns the whole refund breakdown — written premium, days in force against term days, earned, unearned, short-rate penalty and the refund due to the insured — without touching the policy. Only on execution does the platform write the cancellation, append the policy event and move the policy to cancelled. Pro-rata, short-rate and flat are all supported; short-rate carries a penalty on the unearned portion, and the refund arithmetic is a tested, dependency-free function rather than a spreadsheet formula someone re-derived.

Life and annuity servicing goes further, because the numbers there are constrained. A policy loan above the available loan value is refused, not warned about; a partial withdrawal above cash value on a life policy or account value on an annuity is refused the same way. Beneficiary changes snapshot the entire prior designation set as a stored before-value before writing the new one — so a contested beneficiary is a record, not a reconstruction.

What it does

  • Open, route and close typed service requests across portal, phone, agent and email, each with an SLA due date.
  • Quote a cancellation pro-rata, short-rate or flat and return the refund breakdown without writing anything.
  • Execute the cancellation as one transaction — cancellation record, policy event and policy status together, or none of them.
  • Reinstate a cancelled or lapsed policy and record the reinstatement as its own event.
  • Build instalment billing schedules — annual, semi-annual, quarterly, monthly or EFT monthly — with down payment and per-instalment amounts computed.
  • Refuse a life policy loan above the available loan value, and a withdrawal above the available cash or account value.
  • Capture the full prior beneficiary set as a before-value on every beneficiary change.

Implements

  • Pro-rata, short-rate and flat cancellation
  • Unearned premium refund calculation
  • Instalment plans: annual → EFT monthly

See it in the product

Open Policy Servicing, switch to the policy book, pick an in-force policy and press Quote cancellation. The refund panel — written premium, days in force over term days, earned, unearned, short-rate penalty, refund — comes back from the server, and the policy is untouched until you press Execute.

Capability 02

Product factory & rate books

Versioned products, coverages and rating factors, promoted only when 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 that reads 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 are applied to 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 the question a rate examiner or a coverage dispute actually asks.

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 is run 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 is the important one — 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 of business.
  • 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, base, technical and final premium, 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.
  • Pin an expected premium and tolerance per representative risk and run the whole pack against a candidate book.
  • 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

Open Pricing Recommendation under Underwriting and load a rated submission. The stored rating run replays the whole waterfall step by step — base rate, each factor, each loading — stamped with the rate book code and version that produced the number.

Capability 03

Binding authority

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

A binder is modelled as a rule set rather than a PDF in a shared drive: the lines the coverholder may write, the jurisdictions they may and may not write in, the maximum policy limit and the maximum premium. Every submission is evaluated against its program'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 — not a generic warning that something is wrong somewhere.

That verdict then gates the bind. Straight-through issue is unavailable on any submission that is not within authority. 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 program's binder as permitted lines, permitted and excluded jurisdictions, a maximum policy limit and a maximum premium.
  • Evaluate every submission against its program and return within authority, refer, or decline.
  • Name the breached rule and the breaching value rather than returning a generic warning.
  • Withhold straight-through issue from any submission that is not within authority.
  • 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 verdict: within / refer / decline
  • Coverholder referral memoranda

See it in the product

Open Binding Authority, pick a program and push a limit or a jurisdiction past the binder. The verdict flips from within authority to refer or decline as you type, names the rule that broke, and drafts the referral memo — there are four preset breach scenarios on the panel if you would rather not invent one.

Capability 04

Bordereaux automation

Premium, claims and risk bordereaux aggregated from the cession ledger, each storing the query that produced its total.

A bordereau here is not typed into a spreadsheet and it is not an estimate. You choose a treaty, a period and a type, and the platform runs the aggregate itself. A premium bordereau sums ceded premium across the non-reversed cessions whose period falls in the range. A risk bordereau sums the ceded amount. A claims bordereau counts and sums recoverable amounts on recoveries notified in the period. The row count and the total are the result of that query, not a figure someone keyed in.

It also records which query produced them. Every generated bordereau stores the ledger and the column it aggregated, in words, and the screen shows you that provenance string rather than asking you to trust the number. When a reinsurer asks where a total came from, the answer travels with the bordereau.

The lifecycle is enforced by the server rather than by convention. A bordereau moves from draft to submitted, and from submitted to accepted, queried or rejected; a queried bordereau can go back to submitted or be rejected; accepted and rejected are terminal. Any other move is refused outright, and the interface only ever offers transitions the server would allow. A query cannot be raised without a note — so a disputed bordereau always carries the reinsurer's reason in their own words, and stays re-submittable instead of quietly closing.

What it does

  • Generate a premium bordereau as the sum of ceded premium on non-reversed cessions falling in the period.
  • Generate a risk bordereau from ceded amounts, and a claims bordereau from the count and sum of recoverables notified in the period.
  • Store the ledger and column each total was aggregated from, and surface that provenance on the bordereau itself.
  • Reference every bordereau uniquely within the organisation, against its treaty, counterparty, period and currency.
  • Enforce draft → submitted → accepted / queried / rejected server-side, refusing any other move.
  • Require a note before a reinsurer's query can be raised, and keep the queried bordereau re-submittable rather than closed.
  • Build MGA premium and claims bordereaux down to the line — gross, agent commission, MGA commission, premium tax, net, and the ceded split per capacity provider.
  • Export those line-level bordereaux as RFC 4180 CSV with a reconciled totals row.

Implements

  • Premium, claims and risk bordereaux
  • RFC 4180 CSV export
  • Per-capacity-provider ceded splits

See it in the product

Open Bordereaux under Reinsurance and press Generate against a treaty and a period. The confirmation quotes the exact ledger column the total was aggregated from, and the detail drawer carries that provenance next to the lifecycle stamps and any reinsurer query note.

Capability 05

Renewal management

A pipeline banded by days to expiry, priced by a published loss-ratio band table.

Renewals are worked from a pipeline banded by days to expiry — overdue, inside seven days, eight to thirty, thirty-one to sixty, sixty-one to ninety — computed from each policy's own expiration date, so the queue is ordered by the only deadline that matters.

Pricing the renewal is a published rule rather than a black box. The expiring loss ratio maps to a rate change through a band table: above 80% adds 15%, above 65% adds 7%, below 45% takes 5% off, and everything between moves 2%. A loss ratio above 100% returns a non-renewal recommendation, and a change of 15% or more is flagged as a rate-up rather than a routine renewal. An underwriter can predict the outcome before running it and reproduce it afterwards — which is what a market-conduct examiner asks for, and what a model score cannot give them.

The decision and its offer are then recorded: renew, rate up, re-underwrite or non-renew, against a status of pending, offered, bound, lapsed or declined. Processing a renewal appends a renewal event to the policy's own ledger carrying the new premium, so the renewal shows up in the policy history rather than only in a renewals report.

What it does

  • Band the expiring book by days to expiry, including overdue, from each policy's real expiration date.
  • Derive the offered premium from the expiring premium and the prior loss ratio using a published band table.
  • Return a non-renewal recommendation above a 100% loss ratio, and flag any change of 15% or more as a rate-up.
  • Record the renewal decision — renew, rate up, re-underwrite, non-renew — and its status through pending, offered, bound, lapsed or declined.
  • Append a renewal event carrying the new premium to the policy's event ledger.
  • Render a renewal offer as a downloadable PDF built from that policy's own terms.

Implements

  • Loss-ratio banded rate change
  • Decisions: renew / rate-up / re-underwrite / non-renew
  • Days-to-expiry pipeline banding

See it in the product

Open Renewals: the timeline bands the expiring book by real days to expiry, and selecting a policy and pressing Send Renewal Offer renders and downloads the offer as a PDF carrying that policy's expiring premium, rate change, proposed premium and effective date.

Capability 06

Lifecycle orchestration

A validated state machine with an append-only event behind every transition.

A policy holds one of ten statuses — quote, bound, issued, in force, reinstated, non-renewed, cancelled, lapsed, expired, terminated — and eleven actions move it between them. Each action declares the statuses it is legal from. An illegal move is refused with a conflict rather than quietly applied: you cannot activate a cancelled policy, or bind one that was never quoted.

The same rule set drives the interface. The buttons on a policy are computed from what the state machine permits from its current status, so a screen cannot offer an action the API would reject. There is one definition of the lifecycle and both sides read it — which is why the demo and the API never disagree about what is possible.

Every transition is one database transaction: the policy update and an append-only event carrying the event type, the status it came from and went to, the effective date, the premium delta, the reason, the acting user and a payload. Cancelling with a method embeds the entire refund calculation in that payload and books the refund as a negative premium delta — so the ledger explains the money, not just the status change. Above that sits a SHA-256 hash-chained audit log over every mutating call on the insurance API, scoped per tenant, rooted at a genesis hash, with secrets redacted before they are written.

What it does

  • Model ten policy statuses and eleven lifecycle actions, each declaring the statuses it is legal from.
  • Refuse an illegal transition with a conflict response rather than applying it.
  • Compute a policy's available actions from the state machine so the interface can only offer legal moves.
  • Write the policy update and its event in one transaction — both, or neither.
  • Record event type, from-status, to-status, effective date, premium delta, reason, payload and acting user on every event.
  • Embed the full cancellation calculation in the event payload and book the refund as a negative premium delta.
  • Hash-chain every mutating call on the insurance API with SHA-256 over the preceding hash, scoped per tenant.

Implements

  • Append-only policy event ledger
  • SHA-256 hash-chained audit log
  • Effective-dated lifecycle transactions

See it in the product

Open the Policy Ledger under Insurance and select a policy. The action buttons are exactly the transitions the state machine permits from its current status and no others, and the event ledger below shows each transition with its actor, effective date and premium delta.

Capability 07

Capacity & program tracking

Placement capacity refused on the slip, and a ceded position that will not show figures that do not reconcile.

The hardest capacity rule in the platform is the one that refuses a write. Signed lines on a treaty or a layer cannot exceed 100%: every participation write re-sums the placed lines inside the same transaction, and an over-placement is rejected with the current signed percentage, the requested percentage, the resulting percentage and how much line was actually available. You find out at the moment of over-placement rather than at the audit.

The ceded position is computed rather than asserted. Premium cession derives ceded premium from real policy premium and the treaty's cession percentage, applies proportional treaties in sequence, and refuses to invent premium for excess-of-loss treaties — those are reported as skipped, with the reason, in a panel that names every treaty not in the position. The position screen then checks its own arithmetic: if gross minus net does not equal ceded, it says so and tells you not to rely on the figures, instead of rendering a number that does not add up.

Programs roll up from their treaties — treaty count, premium, limit and maximum capacity — and a limit that was never recorded is reported as not recorded rather than as zero, because those are different facts. On the delegated-authority side, committed capacity per provider is tracked against ceded premium per program, with a utilisation warning as the panel fills.

What it does

  • Refuse any participation that would take signed lines on a treaty or layer above 100%, inside the transaction.
  • Return the current, requested, resulting and available signed percentages on that refusal.
  • Derive ceded premium from real policy premium and treaty cession percentage, applying proportional treaties in sequence.
  • Skip excess-of-loss treaties rather than fabricating a premium for them, and name every skipped treaty with its reason.
  • Check gross minus net against ceded, and refuse to present a position that does not reconcile.
  • Roll programs up from their treaties, distinguishing a limit that is zero from one that was never recorded.
  • Track committed capacity per capacity provider against ceded premium per program, with a utilisation warning.

Implements

  • Signed lines ≤ 100% on every slip
  • Quota share, surplus, excess-of-loss and stop-loss structures
  • Proportional cession applied in treaty sequence

See it in the product

Open Gross / Ceded / Net under Reinsurance. Beside the position there is a panel naming every treaty that is not in it and why it was skipped, and a reconciliation check that replaces the figures with a warning if gross minus net does not equal ceded.

Capability 08

Compliance & filings support

Rate filings with a guarded workflow and hash-stamped documents, framework attestations, and surplus-lines tax to the remittance.

A rate filing is a record with the actuarial substance attached: indicated versus proposed change, target versus actual loss ratio, credibility, jurisdiction, filing and effective dates, and a status across draft, internal review, submitted, pending, approved, rejected, withdrawn and disapproved. Filings in the actuarial workflow run on a guarded state machine — ready for review, submit, acknowledge, approve, object, withdraw — where an illegal transition is refused and the regulator's own reference is captured on submission. To be exact about what that means: the platform tracks the filing and holds its evidence, it does not transmit it to the regulator for you.

The filing document is genuinely rendered rather than exported from a template you cannot inspect. The PDF is produced server-side, the bytes are hashed with SHA-256, and the hash and byte size are stored alongside the document, which then downloads only within the organisation that owns it. If a filed document is ever questioned, the copy in your hands can be checked against the hash recorded when it was produced.

Around the filing sit the checks. Compliance attestations are scoped to a policy, a portfolio or a filing, tagged to the framework they answer to, and carry a status and severity until someone attests — at which point the attester and the timestamp are recorded against it. Surplus-lines placements are calculated through to the remittance: premium tax and stamping fee against the state schedule, the total to remit, and whether the state is a stamping-office or direct-file jurisdiction. And policies are checked against minimum limits by line, attached forms, data completeness and advance notice, with each finding carrying its citation.

What it does

  • Hold indicated and proposed change, target and actual loss ratio, credibility, jurisdiction and decision dates on every rate filing.
  • Guard actuarial filing transitions — ready for review, submit, acknowledge, approve, object, withdraw — and refuse illegal moves.
  • Capture the regulator's own reference when a filing is marked submitted.
  • Render the filing document to PDF server-side, hash the bytes with SHA-256 and store the hash and size with it.
  • Serve a filing document only to the organisation that owns it.
  • Track attestations by scope and framework, recording the attester and the timestamp on each one.
  • Calculate surplus-lines premium tax, stamping fee and total to remit against state schedules, flagging stamping-office versus direct-file states.
  • Check policies against minimum limits by line, attached forms, data completeness and advance notice, with a citation on each finding.

Implements

  • NAIC rate filing
  • Solvency II
  • IFRS 17
  • RBC
  • LDTI
  • APRA
  • State surplus-lines premium tax and stamping fees

See it in the product

Open Rate Filing & Indication under Insurance, pick a filing and generate its PDF. The document is rendered server-side and stored with its SHA-256 hash and byte size, and the download is scoped to your organisation.

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

Who it serves

  • Policy operations leaders
  • Product managers
  • MGA program managers
  • Underwriting operations
  • Carrier delegated-authority teams

Aligned to

  • NAIC model laws
  • State DOI form & rate filings
  • Surplus lines regulation
  • Lloyd's delegated authority standards
  • GDPR / CCPA
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%
FAQ

Policy Administration FAQ

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

Endorsements, cancellations (pro-rata, short-rate or flat), reinstatements, renewals, and typed mid-term service requests across portal, phone, agent and email. Each runs as a guided transaction with effective-date handling, and each appends an event carrying the acting user, the reason, the statuses it moved between and the premium delta.

Products, coverages and rating factors are versioned data rather than code. A rate book carries its base rate, factor tables, increased-limit ladder and loadings, and moves through draft, filed, approved, effective and superseded — so changing a price does not require an IT release. Any submission can be re-quoted against any book without persisting, to test a change against real risks first.

A regression pack pins an expected premium and tolerance against representative risks. Promotion to effective is refused three ways: if the pack was never run, if it failed, or if the rate book has been edited since the last run — so you cannot pass the tests, tweak a factor and promote anyway. Promotion is role-gated, supersedes the outgoing book in the same transaction, and can be rolled back.

Each program's binder is modelled as rules: the permitted lines, the permitted and excluded jurisdictions, the maximum policy limit and the maximum premium. Every submission is evaluated against them and returns within authority, refer or decline, naming the rule that broke and the value that broke it. Straight-through issue is withheld outside authority, a referred risk needs an explicit acknowledgement before it can be bound, and the platform drafts the referral memo listing each breach.

Premium, claims and risk bordereaux are aggregated by the platform from the cession ledger for a chosen treaty and period — ceded premium, ceded amounts, or recoverables notified in the period — and each generated bordereau stores the ledger and column its total came from, so the provenance travels with the number. The lifecycle is server-enforced: draft to submitted, then accepted, queried or rejected, with any other move refused and a note required before a query can be raised. Transmission to the reinsurer is your existing channel; the platform produces, tracks and evidences the bordereau.

The pipeline is banded by real days to expiry, including overdue. The offered premium comes from a published loss-ratio band table rather than a model score — above 80% adds 15%, above 65% adds 7%, below 45% takes 5% off, everything between moves 2%, and above 100% returns a non-renewal recommendation. An underwriter can predict the offer beforehand and reproduce it in an examination afterwards.

See Policy Administration on your data

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

Policy Administration — Service the book, launch products and run MGA programs on one core. | AegisNow Insurance