Life insurance policy administration systems hold the data a carrier needs to bill, value and pay a policy: the owner, the plan code, the face amount, the premium, the account value, the loan balance, the transaction history. They do not hold the contract that was issued, which is a printed document filed state by state and kept, if at all, as an image in a separate archive. For an in-force block that gap is where service breaks: the representative can see what a policy is worth but not what its contract says about borrowing, lapsing or converting, and a policy issued in 1998 may already be on its third admin system. Botminds' In-Force Policy Servicing works beside the admin systems rather than replacing them: it reads their values read-only, reads each policy's own scanned contract from the imaging archive, and identifies the form version and state variant from the form library. This guide explains what each system holds, why the contract is missing, and the inputs, with owners, that a go-live needs.
Screens and counts below come from the solution's sample, a fictional carrier named Larchmere Mutual Life. The records rules quoted are New York's, which are explicit; other states' rules differ in detail.
What the admin system holds, and what only the contract says
In the policy administration system: The loan balance, the rate code, the date interest was last charged.
Only in the issued contract: How the maximum loan is computed, when interest is charged, how loaned value is credited, when a loan ends the policy.
In the policy administration system: The paid-to date, the grace status, the date a notice went out.
Only in the issued contract: The grace period, who must be notified and how long before termination.
In the policy administration system: This month’s cost of insurance and expense charges, as deducted.
Only in the issued contract: The guaranteed maximum rates the charges may never exceed.
In the policy administration system: The cash value and the default option code.
Only in the issued contract: The nonforfeiture options, the table of values and which option applies if the owner does nothing.
In the policy administration system: This year’s dividend and the option on file.
Only in the issued contract: Which options the form and its state variant allow.
In the policy administration system: Rider codes, often with end dates.
Only in the issued contract: The conversion window, the plans offered and each rider’s terms.
What is a life insurance policy administration system, and what data does it hold?
A life insurance policy administration system is the system of record for in-force policies: it issues, bills, values and changes them, and feeds the general ledger, tax reporting and claims. Its data is structured: plan codes, rates, dates and amounts that drive calculations.
On a universal life policy the useful fields for service are the ones the sample's values agent reads at each valuation: account value, surrender charge, loan balance, net cash value, monthly deduction, cost basis and tax status. On whole life they are the cash value, dividend and option, paid-up additions and loans. These are the right source for today's numbers, and the solution never recalculates one; a second, unaudited cash value is a worse problem than a slow one.
What the system holds about the contract is usually a code: a plan code that points at a product definition, sometimes a form number, often not the state variant, and not the text. The product definition encodes the calculations the system performs. It does not encode the clauses the system has no reason to compute, such as who must receive a lapse notice or which dividend options the Pennsylvania variant added.
Why does the admin system not hold the policy contract?
Because the contract is a filed legal document, issued on paper and kept as an image, while the admin system was built to compute. The two were separate from the start, and the separation survives every conversion: values migrate, documents get a pointer at best.
Records rules require the documents to exist all the same. New York's records regulation requires every insurer to keep, for each policy, "the contract or policy forms issued including the declaration pages, endorsements, riders, and termination notices", "for six calendar years after the date the policy is no longer in force" or until after the examination that reviews it, whichever is longer (11 NYCRR §243.2(b)(1)). For a whole life policy issued in 1979 and still in force, that is a retention period already approaching half a century.
The same regulation explains why so many contracts are on microfilm or in scans. Records "may be maintained in any durable medium", and once an original is transferred, the insurer "may destroy the original record after assuring that all information contained in the original record, including signatures, handwritten notations, or pictures, is contained in the durable medium" (11 NYCRR §243.3(a)). The image, not the paper, is now the contract of record, and it has to be findable and legible when a policyowner asks what it says.
Form versions and state variants: why one product has many contracts
One product can have many contracts because every policy form must be approved state by state and revised over time. New York's rule is typical: "No policy form shall be delivered or issued for delivery in this state unless it has been filed with and approved by the superintendent", and a policy form includes any "rider or endorsement thereto" (N.Y. Ins. Law §3201). A product sold in fourteen states for seven years can leave a dozen printed variants and several revisions, each with slightly different terms.
The form library: every product and rider form, with its state variants
The form library is therefore the first input of any contract-reading service, and the hardest to assemble. It needs every form ever issued, its revisions and its filed state variants, with the years each was used. Then each policy has to be tied to the right one, which is where the papers sometimes disagree: the sample's 1984 Pennsylvania whole life policy carries a scan of the base form, while the filed Pennsylvania variant adds a dividend option. A specialist decided which governs, and the decision became one of the library's 38 variant rules.
What a decades-old block looks like: one policy, two systems, 28 years
A decades-old block is a stack of systems, each holding part of a policy's life. The sample policy below was issued in Ohio in 1998, moved from one admin system to another in 2011, changed its death benefit option in 2016, lost two riders to age, changed beneficiaries and took a loan. Its history now draws on 41 admin notes, seven documents and two systems.
28 years on one policy, each event with its source
Public data on how old such systems get comes from government, not insurers, and is an analogy rather than a measure of life carriers. The US Government Accountability Office found that the eleven most critical federal legacy systems it reviewed "ranged from about 23 to 60 years old" and "collectively cost approximately $754 million annually to operate and maintain"; eight of the eleven "use outdated languages", ones GAO says fewer and fewer people can still support (GAO-25-107795, July 2025; the migration side is covered in legacy policy administration systems).
How old critical systems get: the GAO's federal analogy
23–60yrs
age of the eleven most critical federal legacy systems GAO reviewed
$754M
a year to operate and maintain them, together
8of 11
written in outdated languages
7of 11
operating with known cybersecurity vulnerabilities
Do we need to replace our admin system to use AI?
No. An AI service layer that reads the admin systems as they are, and never writes to them, can go live without a conversion, and that is the safer order: replacement projects take years, and the contract gap survives them anyway.
The regulators' own survey shows why this matters. Among life insurers in the NAIC's 2023 survey that were not using, planning or exploring AI, the reasons included "Reliance on legacy systems/IT" (NAIC Big Data and AI Working Group, December 2023). A tool that needs a modern admin platform waits for one. In the sample configuration, In-Force Policy Servicing connects read-only to two admin systems (one holding values and notes for issues from 1971 to 2011, the other for 2012 to 2019), to the imaging archive, to the in-force projection engine, which runs on request, and to correspondence since 2004, which it reads and drafts into. Nothing is migrated.
Where a carrier is converting anyway, the two efforts help each other: the form library and the policy-to-form links built for service are exactly the mapping a conversion needs. The conversion itself, and why legacy systems are hard to leave, is covered in legacy policy administration systems.
What you bring to go live: the inputs and who owns each
Six inputs make a contract-reading service work, and each has an owner who is usually not in IT. The table lists them with what happens when one is missing, because a gap in any of them shows up as answers the agents refuse to give.
Six inputs for an in-force service go-live, with their owners
| Input | What it is | Usual owner | If it is missing |
|---|---|---|---|
| Form library | Every product and rider form issued, its revisions and filed state variants, with issue years | Product management and compliance (form filing) | The form version cannot be confirmed, so answers stop and escalate |
| Contract images | Each policy’s issued contract, riders and endorsements, linked to the policy number | Records management and the imaging archive | Nothing to cite: the question goes to Records for retrieval |
| Admin system access | Read-only values and notes from every system the policy has lived on | IT and in-force operations | Values cannot be read; the agents never estimate them |
| Projection engine | The company’s own in-force projection, callable per policy and scenario | Actuarial | No what-if: loan and stopped-premium answers lose the lapse year |
| Service rules | Who may be told what, review thresholds, tax wording, what happens when papers disagree | Head of in-force service with compliance | Defaults apply until the carrier sets its own |
| Letters and past questions | Reply templates and a sample of questions the specialists already answered | Service operations and quality | Replies in a generic format; no back-test answer key |
How do you digitize old policy contracts so they can be cited?
Digitizing old policy contracts for service means more than scanning: each page has to be legible, indexed by section, and tied to the right policy and form version. A contract that exists only as an unindexed image is findable by a person with an afternoon, not citable on a call.
The work runs in four passes. Retrieve: pull the images from microfilm, the imaging archive or the policy file, and note which roll or source each came from. Read: extract the text page by page and measure legibility; pages that cannot be read are listed, not guessed. Index: tie each passage to its section and page, so an answer can cite "§7.4, page 12". Link: attach each contract to its policy and to the form version and state variant in the library. In the sample, 14,618 of 14,736 form pages were read and indexed, 99.2%; the rest are reported on the form library, so a representative knows before a call which forms need a retrieval.
Before go-live: what to check on your contracts and systems
- Can every in-force policy be tied to a form number?
Count the policies whose plan code maps to no form, or to several.
- Is every filed state variant in the library?
Compare issue states in the admin system with the variants on file for each form.
- Where are the images, and how legible?
Sample twenty policies per decade of issue and score the scans.
- Do riders and endorsements travel with the contract?
Death benefit option changes and beneficiary endorsements are often filed separately.
- Which systems has each policy lived on?
Conversion dates matter: history before a conversion may sit in an archived system.
- Can the projection engine be called per policy?
One case at a time, with the scenario inputs a what-if needs.
- Who decides when the papers disagree?
Name the specialists, and agree how their decisions become rules for the form.
Once these inputs are in place, the solution's first test should be a back-test on questions already answered; the policy servicing co-pilot guide lists what to ask during it, and the in-force ROI guide turns the results into a business case. To see the form library and the policy history in the solution, start from In-Force Policy Servicing.
What is a closed block, and does it change service?
In statute, a closed block is the participating business a mutual life insurer sets aside when it converts to a stock company. New York's demutualization law requires that participating policies "in force on the effective date of the reorganization shall be operated by the reorganized insurer as a closed block of participating business", with assets allocated to it (N.Y. Ins. Law §7312). In everyday use, carriers also call any block no longer sold a closed block.
Either way, service gets harder in the same places. Closed-block policies are old by definition, so they carry the most form versions, the oldest scans and the most conversions. Dividend questions on a demutualization closed block can also turn on the reorganization plan's rules for the block, which the service desk needs alongside the contract. A closed block is where a contract-reading service pays back first.
Questions people ask
What is a legacy policy administration system?
An admin system the carrier keeps running for older policies, usually because converting them to a newer platform costs more than it saves. Legacy systems typically hold values and transactions for closed or older products, often in older languages, and depend on staff who know them; the GAO reports the same pattern in federal systems aged 23 to 60 years.
What data is in a policy admin system?
Structured policy data: owner, insured, plan code, issue date and state, face amount, premium and mode, account or cash value, surrender charge, loans, dividends and options, rider codes, transactions and notes. It holds what the carrier computes and processes, not the text of the contract that governs those computations.
How long must a life insurer keep the policy contract?
State rules vary. New York requires the issued policy forms, endorsements and riders to be kept for six calendar years after the policy is no longer in force, or until after the examination that reviews it if later. For a long-lived whole life policy that can mean several decades.
Do we need to move policies to a new admin system before using AI for service?
No. A service layer that reads each system read-only, plus the contract images and the form library, can go live on the systems you have. A conversion can come later, and the form-to-policy mapping built for service will help it.
How do you handle form versions and state variants?
Build a form library that lists every form, revision and filed state variant with its issue years, tie each policy to one, and stop when the evidence conflicts. In the sample, when a policy's scan, issue state and variant disagree, the agents write no answer and a specialist decides; the decision becomes a variant rule for the next policy on that form.