Build vs Buy: Life and Annuity Policy Administration Software

When licensing a platform is genuinely the right call

Verisk FAST, Sapiens, Equisoft, Oracle Insurance Policy Administration and Infosys McCamish are real platforms with real conversions behind them, and a carrier with a large open multi product book writing new business across several lines should look at them seriously. You are buying an implemented answer to problems you would otherwise solve from first principles: valuation, riders, unit accounting on variable products, commission structures, general ledger posting and the reporting a regulator expects.

The strongest buying case is regulatory and actuarial breadth. Reserving requirements, illustration rules, statutory reporting and long duration contract accounting all change, and a platform vendor amortises that work across every carrier on the product. A single carrier funding those updates alone is paying for a public good privately, and that cost never stops.

The second buying case is capacity. Platform implementations run through system integrators who have staffed dozens of them, and that muscle memory is worth something on a programme where the failure modes are well known. If your board has approved a multi year modernisation and your operations team can be released to it properly, licensing a platform and running a disciplined implementation is a legitimate route and the honest answer for a certain size of carrier.

When building around the legacy engine beats replacing it

Here is the trap that catches programmes regardless of vendor. A configurable platform still needs somebody to define every exception in your block, and a thirty year block contains exceptions that are undocumented, including manual adjustments made by a person who retired in 2009. Encoding them is where budgets and timelines are consumed, and switching vendor does not remove that work because the difficulty lives in your block rather than in their product.

So the practical build case is coexistence rather than replacement. Put a controlled, versioned service layer in front of the legacy administration system. Move servicing, self service, agent tooling and new business onto the new stack immediately. Write every new product on the new stack from day one. Then convert the legacy block product family by product family, on economics, and accept that some closed blocks should simply run off where they are.

Build when your immediate pain is servicing and speed to market rather than the engine. Ask the service centre what generates calls: address and beneficiary changes, loan quotes, surrender quotes with the charge schedule explained, in force illustrations, premium method changes, fund transfers. Almost none of that requires replacing the calculation engine. It requires a modern interface that can read from and write to it safely.

Build also when a closed block makes the conversion arithmetic fail. Twelve thousand policies paying out over the next fifteen years does not justify a conversion. It justifies a clean interface and a plan for eventual third party administration.

The three cost bands, and what each one buys

A modern servicing and self service layer over the legacy engine, including agent tooling and workflow, runs $120,000 to $300,000 across 4 to 7 months. This is the fastest visible improvement in the whole programme, it is measurable in call volume within a quarter, and it buys the political room for the harder work behind it.

A new product family written entirely on the new stack, including new business, underwriting integration, its own values engine and issue to the same general ledger, runs $200,000 to $450,000 over 6 to 10 months for the first one. Subsequent products in that family are dramatically faster because the crediting mechanics already exist, which is the entire point of doing it this way.

Converting a real in force block with riders and guarantees runs $1 million to $5 million or more across multiple years, whoever performs it and whatever platform sits underneath. Any number materially below that for a complex block should be read as a warning rather than a saving. Cost is driven by the number of distinct product families rather than by policy count, because policies are cheap to move and products are expensive to reproduce.

The costs that surface in month nine

The first is rounding, and it is the specific thing that separates people who have converted a block from people who have read about it. Legacy engines round at particular points in a calculation sequence, so a mathematically equivalent expression that rounds at a different step produces a different cent. Multiply that through monthly deductions across twenty years and the drift becomes visible on a statement. Reproducing the sequence of operations matters as much as reproducing the formula, and no requirements document written by an actuary will say so.

The second is product archaeology. Somewhere in the block is a family sold for six years in the 1990s whose crediting method exists only in patched source code. Reconstructing it is a funded workstream with its own timeline, and its output must be a written specification validated by reproducing historical policy values from real anniversary statements rather than by reading code carefully.

The third is what parallel valuation finds. Running every policy in both systems as at the same date and diffing account value, cash surrender value, death benefit, loan balance and guarantee measures produces a mismatch population. Some are bugs in the new engine, some are undocumented behaviour in the old one, and some are genuine historical errors that have been compounding quietly. You will find those. Decide in advance who signs off on what happens next, because the answer has reserve and market conduct consequences.

The fourth is variable business. Fund accounting and unit valuation are a separate discipline, with their own daily cycle, their own reconciliation to the fund administrator and their own failure modes on a day when a fund price arrives late. Carriers scoping a conversion frequently price variable products as if they were fixed products with more fields, and discover in month nine that they have bought a second project.

The fifth is guaranteed living benefit riders, which are the hardest calculations in the book and the ones most likely to have been amended by endorsement across the life of a product. Every endorsement variant is effectively its own product for specification purposes, and the count of variants is rarely known before someone goes looking.

The sixth is accounting obligations. Long duration contract reporting requirements have their own data demands, and they must be satisfied from the same system that administers the policy. Retrofitting that later is more expensive than specifying it now.

A decision test built on your own product families

List every product family in the block. For each one write four numbers: policies in force, expected years until the family is materially run off, annual new business, and how many people in the company can explain how it calculates. Then sort by the product of policies and remaining years, which approximates how much future administration the family actually demands.

Families at the top with live new business are conversion or platform candidates. Families at the top with no new business are the ones worth converting purely to retire a system. Families at the bottom are runoff candidates, and deciding to leave one where it is should be treated as a legitimate outcome rather than a failure of nerve.

Then apply the fourth column. Any family where only one or two people can explain the calculation carries a timeline risk that is independent of vendor choice, because the specification work depends on their availability and their retirement date. If several families are in that state, the archaeology workstream is your critical path and it should start before any platform selection concludes.

Finally, ask the service centre for last quarter's call reasons and mark each one as engine dependent or interface dependent. If the interface column dominates, you have a $120,000 to $300,000 problem sitting inside a multi million dollar programme, and solving it first is both cheaper and politically wise.

A first ninety days that does not bet the block

Start with the service layer. Define a versioned API over the legacy system that the legacy team owns, keep every transaction the old engine must own where it is, and build the policyholder and agent experience on top. That work is reversible, it produces measurable results inside one quarter, and it establishes the integration discipline every later phase depends on.

In parallel, run product archaeology on the two families that carry the most remaining administration, and require validation against real anniversary statements. Machine assistance genuinely helps here, because generating candidate specifications from decades of legacy source is far faster than reading it by hand. What makes the output trustworthy is the verification, not the generation.

Whichever route you choose, settle ownership in writing before kickoff: the repository, the infrastructure accounts and the unrestricted right to bring in another firm. These contracts will outlive the software vendor, the integrator and probably the current management team, so the logic that honours a guarantee written in 1994 belongs to the carrier that wrote it.

Digital Heroes builds coexistence layers and product engines of this kind, works PRD first so the transaction model and effective date handling are agreed in writing before code, and contracts through an India LLP, a US LLC or a UK LTD so IP assignment happens under your own regulator's jurisdiction. The team is 50 plus people across 2,000 plus delivered projects, holds Fiverr Vetted Pro status, ships its own products including ShopScore and Section Vault, and publishes openly including a YouTube channel with 2.5 million subscribers.

If you would rather someone argued with your brief than agreed with it, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. Nothing about that commits you to the build.