Actuarial Modelling Platform Problems: The 6 That Delay Every Close, and How to Avoid Them

Why does the data preparation scope get underestimated so often?

Every actuarial platform proposal contains a line about data integration, and almost every one of them prices it as plumbing. It is not plumbing. Model input comes from policy administration, claims, reinsurance, investments and the general ledger, and those systems were never designed to agree with each other. What exists today is a chain of extraction and transformation written years ago, amended for every product launch since, understood properly by one person.

The reason this is specific to insurance rather than generic is legacy. Most carriers of any age run administration platforms inherited through acquisition, and the older the block, the worse the data. Fields carry meanings that changed in 2011. A product code was reused. A manual override sits inside the input file with its reasoning in a cell comment written by somebody who left.

The fix is to make discovery a deliverable rather than a phase. Before code, walk one product line end to end and write down every source, every transformation, every override and every reconciliation somebody currently performs in their head. Then agree the gates: policy counts, sums insured, premium and reserves reconciled to the administration system and the ledger before results count as valid, with the gate failing the run rather than producing a report nobody reads. In our delivery experience this exercise takes three to five weeks on a mixed book and is the highest return work in the project, because most reruns are caused by data problems found after the run rather than by modelling decisions.

What goes wrong when you migrate historical assumptions and results?

Teams plan to load several years of assumptions and results so the new platform can produce movement analysis from day one. Two things break that plan.

First, historical assumption tables usually exist as files, not as governed objects. There is a folder per quarter and a naming convention that changed twice. Which table was approved, by whom, and which runs consumed it, is a matter of trust rather than record. Loading those files gives you versions without provenance, which is worse than not loading them, because the platform now implies a governance history that does not exist.

Second, historical results were produced by model versions you can no longer execute. Recomputing them under the current model gives numbers that do not match what was reported, and you are one board question away from an awkward conversation.

What works: load historical results as reported, immutably, marked as imported rather than computed, with whatever provenance you genuinely have and an explicit gap where you do not. Load historical assumption tables as reference data with the same honesty. Start governed versioning at go live. Then movement analysis for the first year compares a governed period against an imported one, which is slightly awkward for four quarters and correct forever afterwards. Reconstructing provenance you never recorded is not migration, it is invention, and internal audit will treat it that way.

Why does the vendor engine automation break after launch?

The build orchestrates runs against an engine you did not write. Moody's AXIS, FIS Prophet, WTW RiskAgility and Milliman Arius each expose automation interfaces, and driving them is real integration work with real quirks. It works in testing. Then it breaks, and it breaks for reasons that have nothing to do with your code.

The common causes are an engine upgrade that changes an output layout, a model change made by an actuary that adds an output the pipeline does not expect, a licence or grid capacity limit hit when parallel execution finally gets used properly, and file locking behaviour under concurrency that never appeared when one person ran one job at a time.

Three practices prevent most of it. Pin the engine version in the run manifest and treat an upgrade as a change requiring a regression run against a known result set, rather than as an infrastructure task performed on a Saturday. Validate model outputs against a declared schema on arrival, so an unexpected column fails loudly at the boundary rather than quietly shifting a field downstream. And test at the concurrency you intend to run at, not at one job, because the failure mode you care about only appears when twelve segments execute at once. Budget an allowance for engine upgrade regression work every year, in the same way you would budget for a regulatory change.

What happens when model governance and segregation of duties are not covered?

This is the gap that turns into an audit finding, and it is usually not covered because nobody puts it in the requirements. In most teams the same person can change an assumption, execute the model and produce the reported result. Nobody intended that. It happens because the tooling is files and folders and the controls are conventions.

The finding, when it arrives, is rarely about mathematics. It is about change control and reproducibility: which assumption was used, who approved it, what version of the model ran, and whether the result presented to the board can be recreated. Remediation imposed after the fact is almost always a manual checklist and a second signature, which adds effort without adding real assurance because the underlying artefacts are still files.

Building it in is cheaper than retrofitting it. Separate assumption authoring from assumption approval. Allow production runs only from approved model and assumption versions. Mark development runs so they cannot feed reporting. Log every state change immutably. The design detail that stops actuaries resisting all of this is a genuinely unrestricted sandbox: experiment freely, apply control only at the boundary where a number becomes a reported one. Teams that impose control on exploration get worked around within a month, and then the platform holds the ceremony while the real work happens in spreadsheets again.

Should you build custom or configure what you already own?

If you are a small insurer with one product line, a stable book and a reserving process that completes in a day, do not build. The overhead of a controlled platform is not justified and the money buys more actuarial capability instead. We say this in first conversations and it costs us work.

Before assuming a build, get your engine vendor's implementation consultant to demonstrate what the platform already offers for batch execution, run management and results extraction, and confirm what your licence actually covers. AXIS, Prophet, RiskAgility and Arius are substantial products and teams routinely use a fraction of what they hold. If a single product line's close is slow mainly because runs are executed by hand, configuring the engine's own scheduling may be most of the answer for a fraction of the cost.

And do not build the calculation kernel under any circumstances. Those engines represent decades of specialised development and validation. Replacing one is a project with a poor risk adjusted return, and any developer who offers to rebuild your projection model is either inexperienced or selling you a decade of work.

Build the surround when data preparation consumes more actuarial time than analysis, when you cannot reproduce a valuation from twelve months ago without an investigation, when runs are so long you run less often than you would like, or when audit has raised change control. Two or more of those together makes the case.

How do hidden costs get into an actuarial platform quote?

Five places, and a developer who has done this raises them unprompted.

• Legacy source systems. Each inherited administration platform is its own extraction problem with its own undocumented meanings. Quotes priced against the modern platform and delivered against three legacy blocks absorb the difference as change requests.
• Reinsurance. Ceded modelling multiplies data complexity in ways teams consistently underestimate, because the treaty structure has to be represented and the data to support it is often incomplete.
• Parallel measurement bases. Running more than one basis is not a reporting option bolted on at the end. It shapes the results store, the run volume and the movement analysis.
• On premises deployment. A requirement to avoid cloud removes the elasticity that makes orchestration valuable, so you pay for the orchestration and keep the queue.
• Engine upgrade regression. An annual allowance, not a surprise. Without it, the first upgrade after go live becomes an unplanned project.

What holds the number down is doing one product line end to end through a full close before touching the others. A pipeline designed for every line at once becomes an abstraction nobody trusts.

What separates an actuarial build that works from one that fails?

Working builds have a run manifest and use it. Every execution records the model version, the assumption set versions, a fingerprint of the input data, the parameters and the environment, and results are stored against that manifest permanently. Reproducing a prior valuation becomes a command. If a prospective developer answers the reproducibility question with backups and folder conventions, they have not built a controlled analytical system.

Working builds also gate at the front rather than reconcile at the back. The reconciliation to source is a precondition of a valid run, not a report produced afterwards. Overrides remain possible because business reality requires them, but each one is an object with an owner, a reason, a value and an expiry, so the input file stops carrying invisible history.

Failing builds usually got the engineering right and the sequencing wrong. They built for every product line simultaneously, went live at a year end, and discovered during the busiest close of the year that three assumptions were wired to the wrong tables. Prove one line through a real quarter with the old process still running beside it, adjudicate every difference with the valuation actuary, and only then extend. The parallel quarter is not caution, it is how you find the places where the previous process was quietly doing something nobody documented.