Three signals from the last eighteen months point in the same direction. PwC’s 2025 actuarial modernisation survey, EY’s open-source actuarial coding work, and FIS’ SaaS Prophet roadmap all suggest that the next round of actuarial modernisation is being decided one layer below the modelling engine — in the data engineering layer. The engine matters less than people think. The way data flows in and out of it matters more than people realised.

By Johann van Rooyen, FASSA, CEO

How we got here

The first wave of modernisation, in the late 2000s and 2010s, was about the engine. Insurers replaced bespoke spreadsheet-based actuarial models with vendor-grade engines — Prophet, AXIS, MoSes — and the conversation was about modelling capability and run time.

The second wave, broadly 2015 to 2022, was about the cloud. Engines moved from on-premise grids to cloud compute. Run times collapsed; the operational model around them barely changed. The team still pulled the same files, ran the same overlays, and assembled the same packs.

The third wave — the one we are in now — is about whether the engine can be fed and read from in a way that is reproducible, observable and reasonable to audit. That is a data engineering problem, not a modelling problem. The engine itself, in most cases, is no longer the bottleneck.

Why the centre of gravity has moved

Three things are different from the previous waves. First, IFRS 17 made lineage non-optional. A pack that cannot be regenerated bit-for-bit, six months later, from versioned inputs, is not a defensible pack. That is now table stakes — and most estates do not yet meet it.

Second, AI has pulled forward the question of data quality. Whether or not your AI plans materialise, the diligence you are now expected to do on input data quality is materially higher than it was three years ago. That is a data engineering effort.

Third, the sheer volume of regulatory and management reporting has outgrown what the spreadsheet layer can carry. Every new disclosure adds another reconciliation. The marginal cost of running a modern actuarial estate is now dominated by the cost of the surrounding data work, not by the cost of compute.

Practical implications for chief actuaries

  • Treat the data layer as a first-class part of the actuarial estate, not as someone else’s responsibility. The CIO is not going to fix this for you, because the CIO does not know what an actuarial cell or a treaty layer is.
  • Insist on lineage from raw source to disclosed number — and use it. If you cannot trace a movement on the CSM waterfall back to the policy data and the assumption that produced it, you cannot defend it.
  • Stop accepting reporting packs that cannot be regenerated from versioned inputs. Anything you sign should be reproducible by the next person.
  • Hire — or borrow — engineering capability. The ratio of actuaries to engineers on the team that produces your numbers is currently wrong. We see one engineer for every five or six actuaries on most estates; it should be closer to one in three.

Practical implications for CIOs

  • Domain-aware pipelines beat generic ones every time. A pipeline that knows what a policy is, what a treaty cession looks like, and what a reserve cell holds will pay for itself faster than a generic ETL framework that the actuarial team has to bend around.
  • Co-locate actuarial and data engineering capabilities. The handoff is where modernisation programmes die. The team that owns the pipeline should sit close enough to the team that uses the data that they hear each other complain.
  • Resist the urge to build before scoping. The cheapest, highest-yielding first move is to scope the operating layer of a single reporting cycle end-to-end. Do that before you commission a multi-year platform programme.

The shape of what wins

The teams that get this right end up with three properties on their estate. Their reporting packs are reproducible. Their assumptions are versioned. Their data is auditable from source to disclosure. Nothing about that requires AI, no model migration, no big-bang rebuild. It does require disciplined engineering applied to actuarial work — which is exactly the gap most consultancies still cannot fill.

The chief actuary and the CIO are now solving the same problem from two sides. The teams that recognise this and act on it together will compress closes, reduce overlay sprawl and make the next IFRS 17 or SAM review a quieter event. The teams that do not will spend the next three years rediscovering, painfully, that the engine was never the bottleneck.

If you would like to scope this on your own estate, our Data Engineering practice is built to do exactly this work.