Life and Annuity Policy Administration Software Problems: The 5 That Break Conversions, and How to Avoid Them

Why does the big bang conversion fail so reliably?

Because the difficulty lives in your block rather than in anybody's product, and a single cutover date forces you to solve all of it at once.

A configurable platform still needs someone to define every exception you carry, and thirty years produces a great many, several of them undocumented manual adjustments made by a person who left long ago. The configuration effort to encode them is where budgets go, and choosing a different vendor does not reduce it. What a big bang adds is that the whole programme has one deadline, so every product family, every rider and every historical oddity has to be correct on the same morning.

The failure pattern is consistent. Year one is discovery and it goes well. Year two is configuration and the exception list keeps growing. Year three the parallel run produces a mismatch population nobody expected, triage takes longer than the build, and the date slips. By then the programme has consumed the budget that would have funded anything smaller and more useful.

The alternative is not heroic. Put a controlled service layer in front of the legacy administration system, move servicing, self service, agent tooling and new business onto the new stack, write every new product there from day one, then convert the legacy block selectively by product family on economics. A closed block of twelve thousand policies paying out over fifteen years does not justify a conversion. It justifies an interface and a plan for eventual run off.

What goes wrong when values do not reproduce to the cent?

Everything downstream, and it starts with a decision made early and quietly.

Teams new to this treat the requirement as accuracy and build to a tolerance. There is no tolerance. A universal life policy issued decades ago with a secondary guarantee is a contract, and the cost of insurance table, the guaranteed crediting floor and the shadow account calculation that keeps the no lapse guarantee alive are terms rather than parameters. A difference of a few cents on a cash surrender value is not a rounding artefact, it is a wrong answer on a legal obligation multiplied by the size of the block.

The second failure is proving correctness with a test plan instead of a parallel run. A test plan checks the cases someone thought of. What you need is every policy calculated in both systems as at the same valuation date and diffed on account value, cash surrender value, death benefit, loan balance and every guarantee measure, with the mismatch population triaged.

Then plan for what triage finds, because it will find three categories: bugs in the new engine, undocumented behaviour in the old one, and genuine historical errors that have been quietly compounding. That third category is the one nobody prepares for. Decide before the run who signs off on each category and what happens when a policyholder has been credited incorrectly for years, because discovering that mid programme without a decision path stops everything.

Why does retroactivity break systems that were not designed for it?

Because it is not a feature, it is a property of the data model, and retrofitting it means rewriting the engine.

A back dated premium changes every subsequent monthly deduction, every interest credit, every surrender charge position and possibly whether a lapse should have occurred at all. A reinstatement reverses a lapse and reprocesses two years. A late arriving exchange lands with an effective date in the past. These are not edge cases, they are Tuesday.

A system that stores a current balance and mutates it can only handle this with reprocessing routines that everyone fears, because nobody can predict what they will touch. A system that separates effective date from processing date on every transaction, holds the policy as an ordered transaction history and derives values by replay treats a back dated premium as an insert followed by a deterministic replay, with the difference between old and new value sets recorded as an auditable adjustment.

The trap is that replay costs more in the first release and delivers nothing visible, so it is the first thing cut when a schedule tightens. That decision looks efficient in month three and defines whether the system is maintainable in year five. Insist that any developer raises retroactive processing in the first conversation. If they do not, they have not built one of these.

What happens when nobody can explain how the old products work?

You discover it in the middle of engine work, which is the worst possible moment.

Somewhere in the block is a product family sold for a handful of years in the 1990s with a crediting method described in a specification that no longer exists electronically. The people who could explain it have retired. The code is the only remaining documentation and it has been patched repeatedly, sometimes to fix a defect and sometimes to implement a decision nobody recorded.

Teams that treat this as a discovery task inside the build get blocked repeatedly and unpredictably, because every unexplained behaviour stops a developer until an actuary can look at it, and the actuary has a day job. The estimate was written assuming specifications exist.

Fund product archaeology as an explicit workstream that runs before any engine work on that family. Its output is a written specification per product, validated by reproducing historical policy values from real anniversary statements rather than by review alone. Machine assistance genuinely earns its place here, because reading decades of legacy source and generating candidate specifications is far faster than reading it manually. What makes the output trustworthy is the verification against real statements, not the generation, so never let the generated document become the authority.

Should you build custom or license an established platform?

If you are a carrier with a large multi product open block, ongoing new business across several lines and the balance sheet to fund a multi year implementation properly, licensing an established platform is legitimate and often right. Verisk FAST, Sapiens, Equisoft, Oracle Insurance Policy Administration and Infosys McCamish are real products with real conversions behind them, and you are buying implemented answers to problems you would otherwise solve from first principles.

What you are not buying is an escape from the exception work. Be clear eyed about that when comparing a licence plus integrator engagement against a build, because the specification effort appears in both columns.

Build, or more precisely build around, when two or more of these hold. Your block is closed or closing and the conversion economics do not work. Your immediate pain is servicing and speed to market rather than the engine. You are launching a product line the legacy platform cannot express this year. You are a smaller carrier or a fraternal where licence plus integrator fees exceed the value of the block being administered. Or you have already attempted a big bang, stopped it, and need something that delivers before the next board meeting.

How do hidden costs get into a policy administration quote?

Five places, and none of them are development rates. The first is product count rather than policy count. Policies are cheap to move and products are expensive to reproduce, so a quote written against a block size is measuring the wrong thing. Ask how many distinct product families, riders and crediting methods are in scope, and price on that.

The second is variable business. Fund accounting and unit valuation are a separate discipline with their own daily processing, their own reconciliation and their own failure modes, and they are frequently mentioned late.

The third is guaranteed living benefit riders. These are the hardest calculations in the book, they interact with everything, and a programme that scopes them as one more rider will discover otherwise during the parallel run.

The fourth is reporting and accounting obligations. Long duration contract reporting requirements have their own data demands that must be satisfied from the same system, and retrofitting the necessary history is expensive.

The fifth is your own actuarial capacity. Every specification, every triage decision and every sign off needs skilled people who already have full workloads. A plan that does not name them and protect their hours will slip regardless of how good the developer is.

What separates a programme that delivers from one that stalls?

Three things. The first is that something reaches production early. A modern servicing and self service layer over a controlled interface to the legacy engine addresses what policyholders and agents actually complain about, meaning loan quotes, surrender quotes with the charge schedule explained, beneficiary changes, in force illustrations and allocation changes. Call volume moves within a quarter, and that visible result buys the political room for the harder work behind it. Programmes whose first deliverable is eighteen months away lose their sponsor before they land.

The second is that correctness is proved rather than asserted. A full parallel valuation over the entire block, a triaged mismatch population and a named person signing off each category is the only acceptable evidence, and it should be in the plan from the start with the compute and the calendar time it needs.

The third is that the carrier owns the logic. The repository, the infrastructure accounts and the unrestricted right to bring in another firm should be settled in writing before kickoff. These contracts will outlive the software vendor, the integrator and probably the current management team, and the calculation that honours a guarantee written decades ago belongs to the company that wrote the guarantee.