Actuarial Modelling and Reserving Platform: Why the Close Waits Three Days for a Model Run

Why the actuarial function is a data engineering function wearing a different hat

Quarter end. The valuation actuary needs the policy extract by the third working day. It arrives on the fifth because a field changed in the policy administration system and the extract job failed silently. The data then goes through six preparation steps in a mixture of SQL, a scripting language and two spreadsheets, one of which contains a manual override for a block of legacy business that a former colleague added in 2019 and documented in a cell comment. The model runs overnight, twice, because the first run used the prior quarter's mortality assumption. Results land on day nine. The analysis of movement, which is the part with actual insight in it, gets a day and a half.

The vendor engines are not the problem here. Moody's AXIS, FIS Prophet, WTW RiskAgility and Milliman Arius each do the hard mathematical work competently and are used precisely because nobody sensible rebuilds a projection kernel or a reserving engine from scratch. What surrounds them is where the time and the risk sit: getting data out of policy, claims and general ledger systems into model ready form, holding assumptions with any governance discipline, orchestrating runs at scale, and storing results so that a movement analysis can be produced rather than reconstructed.

The cost of leaving that surround manual is visible in three places. The close is long, which delays every downstream decision. Model risk findings appear in internal audit and regulator feedback, usually about change control and reproducibility rather than about mathematics. And your qualified actuaries spend their expensive time on data preparation, which is both a retention problem and a waste of the thing you are actually paying for.

Problem 1: the data pipeline is a set of scripts nobody owns

Model input comes from policy administration, claims, reinsurance, investments and the general ledger, systems that were never designed to agree with each other. Somebody wrote the extraction and transformation years ago. It has been amended for every product launch since. It runs, and it mostly produces the right answer, and the number of people who genuinely understand it is one.

What a custom build does: treat model data preparation as a controlled pipeline with the same rigour as a financial process. Each step declared and versioned, each run producing a reconciliation to source, meaning policy counts, sums insured and premium reconciled to the administration system and reserves reconciled to the ledger before results are considered valid. Not a report produced afterwards, a gate that fails the run. Overrides remain possible because business reality requires them, but every override is a recorded object with an owner, a reason, an expiry and a value, so the model input file stops carrying invisible history in cell comments.

The immediate payoff is time. In our experience this is where the largest single reduction in close duration comes from, because most reruns are caused by data problems discovered after the run rather than by modelling decisions.

Problem 2: assumptions live in files, and governance is a meeting

A valuation depends on dozens of assumption sets: mortality, lapse, expenses, discount rates, morbidity, claim development factors depending on the business. They are updated through an experience study, discussed at a committee, approved, and then applied by someone copying a table into a location the model reads. The record that a specific approved assumption was used in a specific run is a matter of trust and a folder structure.

What a custom build does: an assumption store where every table is a versioned object with an effective date, an owner, an approval record and a lineage showing which studies supported it. Runs reference assumption versions rather than file paths. Then two questions that are currently hard become trivial: which runs used the superseded lapse table, and what would last quarter's result be under this quarter's assumptions. That second question is the core of movement analysis and today it usually requires a special exercise.

This is also the part that satisfies model governance expectations, including the documentation standards actuaries in several jurisdictions work under. Governance is much easier to demonstrate when it is a by product of how the system works than when it is a policy document describing what people are supposed to do with folders.

Problem 3: runs are long, serial and unrepeatable

A full stochastic run on a large in force book takes hours to days. Teams economise by running less often, which means errors are found late. When a run has to be repeated, reproducing it exactly requires the same model version, the same assumption set, the same data extract and the same settings, and at least one of those is usually reconstructed from memory.

What a custom build does: a run manifest. 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 rather than an investigation. Then orchestration on elastic cloud compute turns a serial overnight run into parallel execution across policy segments or scenarios, which is where the close duration collapses. Reporting standards that require multiple measurement bases have made run volume grow substantially, and the teams that handled that well did it by industrialising execution rather than by hiring.

Note what this does not involve: rewriting the calculation. The vendor kernel keeps doing the mathematics. You are building the harness around it.

Problem 4: results go into files, so analysis of change is rebuilt every quarter

The output that matters to the chief actuary is not a reserve number, it is the movement: how much of the change came from new business, from experience variance, from assumption changes, from model changes, from discount rate movements. Producing that requires results from multiple runs on a consistent grain, and if results land as flat files in folders, the analysis is assembled by hand every quarter by a senior person.

What a custom build does: land results in a structured store at the grain you actually analyse, typically product, cohort, measurement basis and reporting period, with the manifest attached. Then movement analysis becomes a query across runs rather than a spreadsheet exercise, and roll forward, sensitivities and disclosure tables are generated rather than assembled. The by product is that the numbers presented to the board and the numbers in the disclosure come from the same source, which removes an entire category of reconciliation work at year end.

Problem 5: segregation of duties barely exists

In many teams the same person can change an assumption, run the model, and produce the reported result. Nobody intends this. It happens because the tooling is files and folders and the controls are conventions. It becomes an audit finding, and the remediation is usually a manual checklist that adds work without much real control.

What a custom build does: make roles explicit. Assumption approval separated from assumption authoring, production runs executable only from approved model and assumption versions, development runs clearly marked and unable to feed reporting, and every state change logged immutably. Actuaries sometimes resist this until they see the version that works, which allows unrestricted experimentation in a sandbox and applies control only at the boundary where a number becomes a reported one.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the data pipeline with source reconciliation gates, a controlled override register, the assumption store with effective dating and approval, and run manifests with reproducible execution runs $110,000 to $250,000 and ships in 16 to 20 weeks. A full platform adding orchestrated parallel runs on elastic compute, a results warehouse supporting movement analysis and sensitivities, disclosure and reporting output, role based segregation of duties, and integration with your vendor engine's automation interface runs $300,000 to $800,000 phased over 9 to 18 months.

What pushes the number up: the number of source systems, particularly if you carry legacy administration platforms from acquisitions, which is common and where the data is worst. Multiple measurement bases running in parallel. Reinsurance, because ceded modelling multiplies the data complexity in ways teams consistently underestimate. And any requirement to run on premises rather than cloud, which removes the elasticity that makes orchestration valuable.

What keeps it down: doing one product line end to end first. A pipeline built for every line at once will be an abstraction nobody trusts, whereas one line proven through a full close gives you a template and a credibility you will need internally.

Build versus buy, and the line we would not cross

Do not build the calculation kernel. AXIS, Prophet, RiskAgility and Arius represent decades of specialised development and validation, and replacing them is a project with a poor risk adjusted return unless you are doing something genuinely unusual. We would talk you out of it.

Do not build at all if you are a small insurer with one product line, a stable book and a reserving process that runs in a day. The overhead of a controlled platform is not justified and the money is better spent on actuarial capability.

Build the surround when two or more of these are true. First, data preparation consumes more actuarial time than analysis. First close after a reporting standard change is a good moment to notice this. Second, you cannot reproduce a valuation from twelve months ago without an investigation. Third, model runs are so long that you run less often than you would like. Fourth, internal audit or a regulator has raised model governance, change control or segregation of duties. Fifth, you carry legacy administration systems whose extracts are maintained by one person.

The framing that helps boards approve this is straightforward. You have already bought the mathematics. What you have not bought is the industrial process around it, and every hour your qualified actuaries spend on data preparation is an hour not spent on the judgement you actually hired them for.

How to choose a developer for an actuarial platform

Ask them what they would not build. A good answer starts by refusing to replace the vendor calculation engine and focusing on data, assumptions, orchestration and results. A developer who offers to rebuild your projection model is either inexperienced or selling you a decade of work.

Ask how they would reproduce a valuation from a year ago. The answer must include a manifest pinning model version, assumption versions, input data fingerprint and parameters. If they describe backups and folders, they have not built a controlled analytical system.

Ask what they have automated against a vendor engine specifically. Driving AXIS, Prophet or Arius through their automation interfaces is real integration work with real quirks, and the honest answer names the engine and the mechanism. Also ask about their experience with reconciliation controls to a general ledger, because a pipeline without gates is a pipeline that ships bad numbers faster.

Ask who owns the code and settle it in the contract before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. An actuarial platform holds the evidence chain behind reported liabilities, and that chain must remain yours regardless of who you work with next year.