Model Development

As actuarial models continue to grow in complexity, the volume of data they process has increased dramatically. Whether you’re building pricing models, performing reserving analyses, running capital calculations or producing IFRS 17 results, the efficiency of your data layer has become just as important as the modelling logic itself.

For many years, CSV files have been the default way of exchanging data between systems. They’re simple, universally supported and easy to inspect with a spreadsheet or text editor. However, as datasets have grown into the millions of records, the limitations of CSV have become increasingly apparent.

That’s where Apache Parquet comes in.

Now natively supported in Mo.net (from 7.8 onwards), Parquet is a modern file format designed specifically for analytical workloads. It enables actuarial models to read data more efficiently, consume less storage and integrate seamlessly with today’s wider analytics ecosystem.

What is a Parquet File?

Unlike a CSV file, a Parquet file isn’t designed to be read by people. It’s a binary format, so opening one in a text editor simply produces unreadable characters. Instead, Parquet is designed for software.

The easiest way to understand the difference is to compare how the same data is stored.

A CSV file stores information row by row:

PolicyIDAgePremiumClaims
100142425.501
100235310.250
100357689.102
100429275.000

Internally, a Parquet file stores the same information more like this:

Schema
 ├─ PolicyID: Integer
 ├─ Age: Integer
 ├─ Premium: Double
 └─ Claims: Integer

PolicyID
1001
1002
1003
1004

Age
42
35
57
29

Premium
425.50
310.25
689.10
275.00

Claims
1
0
2
0

This isn’t the actual binary structure, but it illustrates the key concept: Parquet stores data by column rather than by row.

That difference unlocks many of the performance benefits that make Parquet so attractive for actuarial modelling.

Faster Model Execution

Consider a pricing model that only requires three variables:

  • Premium
  • Claim Count
  • Exposure

A traditional CSV file might contain dozens or even hundreds of columns:

PolicyIDAgeVehicleRegionPremiumClaim CountExposureOccupation

When Mo.net reads a CSV, every column has to be loaded from disk before the unwanted ones can be discarded.

With Parquet, Mo.net can read only the columns it needs.

Instead of loading the entire file, it simply retrieves:

  • Premium
  • Claim Count
  • Exposure

while skipping everything else.

For small datasets the difference may be negligible. For experience files containing millions of policies, the reduction in disk I/O can significantly improve loading and execution times.

Smaller Files, Lower Storage Costs

Another major advantage of Parquet is file size. The format includes highly efficient compression and encoding techniques, meaning Parquet files are often 50–90% smaller than equivalent CSV files, depending on the characteristics of the data.

For actuarial teams storing years of policy history, claims experience, assumptions and model outputs, these savings can quickly become substantial.

Smaller files also mean:

  • Faster backups
  • Faster transfers between systems
  • Lower cloud storage costs
  • Quicker loading into analytical platforms

Better Data Quality Through Strong Typing

CSV files only contain text. Every application importing a CSV has to decide whether each column represents a number, date or piece of text. Regional settings, missing values and formatting differences can all introduce unexpected issues.

Parquet stores the data type alongside the data itself.

  • Dates remain dates.
  • Numbers remain numbers.
  • Boolean values remain Boolean.

This reduces import errors and removes much of the repetitive data cleaning that often accompanies actuarial workflows.

Built for Large-Scale Analytics

Parquet has become the standard storage format across modern analytics platforms, including Python, R, DuckDB, Spark, Databricks, Microsoft Fabric and many cloud data warehouses. Because Mo.net supports Parquet directly, the same dataset can be shared across multiple analytical tools without exporting separate copies in different formats. This creates a single, consistent source of data across pricing, reserving, capital modelling and reporting teams.

Handling Large Experience Files Efficiently

Many actuarial investigations involve datasets containing tens or hundreds of millions of records. Parquet includes several features specifically designed for these workloads:

  • Columnar storage minimises unnecessary reads.
  • Built-in compression reduces storage requirements.
  • Rich metadata allows software to skip irrelevant sections of a file.
  • Partitioning makes it easy to work with individual years, products or business units.

Together, these capabilities allow Mo.net to process large datasets far more efficiently than traditional text-based formats.

A Better Foundation for Automated Data Pipelines

Modern actuarial modelling increasingly forms part of automated production processes. Data flows from operational systems into data lakes, through validation pipelines, into actuarial models and finally into reporting platforms.

Parquet fits naturally within these workflows because it preserves both data structure and data types. The result is more reliable automated processes, fewer manual interventions and reduced risk of data formatting issues disrupting production runs.

Why It Matters for Mo.net Users

Support for Parquet within Mo.net allows actuarial teams to benefit from industry-standard data technology without changing the way they build models.

Users can take advantage of:

  • Faster data loading
  • Reduced model execution times
  • Smaller data files
  • Lower memory consumption
  • More reliable handling of data types
  • Better integration with modern analytics platforms
  • Improved scalability as datasets continue to grow

These benefits apply across pricing, reserving, capital modelling, IFRS 17 and experience investigations.

Looking Ahead

The actuarial profession is rapidly embracing larger datasets, cloud-native architectures and increasingly sophisticated analytical techniques. Parquet has emerged as one of the foundational technologies enabling that transition.

By supporting Parquet, Mo.net gives actuarial teams access to a faster, more scalable and more robust way of managing model data. Rather than treating data loading as a bottleneck, modellers can focus on what matters most—developing better models and delivering insights more quickly.

For organisations looking to modernise their actuarial workflows, adopting Parquet isn’t simply a technical upgrade. It’s an investment in a data platform that’s designed for the future.

Read more

1. Compute Stops Being the Constraint (Finally)

By 2035, raw compute is no longer something modellers think about. Cloud-native execution, massive parallelism, GPU acceleration, and on-demand elasticity mean that “Can we afford to run this?” quietly disappears as a question. What matters instead is how fast insight cycles complete, not how long individual runs take.

This isn’t about bigger models. It’s about orders of magnitude more exploration, i.e. thousands or millions of scenarios becoming routine rather than exceptional.

Once computation becomes effectively infinite, the limiting factor moves somewhere much closer to home.

2. Models Become Modular, Not Monolithic

The 2035 model is unlikely to be a single engine. It’s a composition of components: mortality, lapses, expenses, assets, reinsurance, capital, management actions, each separable, swappable, and independently testable.

This modularity is what allows:

  • Continuous evolution without destabilising everything
  • Parallel development by different teams
  • AI to reason about cause and effect instead of just outputs

Monolithic “all-in-one” engines struggle here. Modular architectures thrive. This is one reason why platforms built around transparent, composable actuarial logic, like Mo.net, age better than those built around opaque execution pipelines.

3. Structured Transparency Replaces Black Boxes

In 2035, transparency is not a philosophical preference but an operational requirement. When models are always on, feeding real decisions, nobody accepts “trust the engine” as an answer. Regulators, boards, and capital providers expect traceability – what changed, why it mattered, and where judgement entered.

This requires:

  • Explicit assumption structures
  • Machine-readable model logic
  • Built-in explainability, not bolt-on documentation

Ironically, this level of transparency is easier to achieve with disciplined platforms than with sprawling bespoke codebases.

4. AI Becomes a Modelling Co-Pilot, not a Feature

AI in 2035 is not a separate tool you “use”, but an embedded capability:

  • Highlighting sensitivities before you ask
  • Surfacing non-linear behaviour automatically
  • Comparing today’s results to historical patterns
  • Drafting explanations, not conclusions

Critically, AI does not decide what assumptions are right but decides where your attention is most valuable. However, this only works if models are fast, structured, and consistent. AI doesn’t cope well with bespoke chaos. It amplifies both good architecture and bad.

5. Data Pipelines Become Boring

In 2026, data integration still consumes a significant amount of end-to-end modelling effort. But by 2035, data pipelines are dull, standardised, and reliable. Not because data got simpler, but because firms finally invested in:

  • Clean interfaces between data and models
  • Clear ownership of transformations
  • End-to-end lineage and business glossaries

When data stops being the daily fire fight, modelling teams can finally focus on thinking again.

6. Governance Moves from Gates to Guardrails

Instead of governance being about approval gates, i.e. “has this run been signed off?”, it becomes about guardrails. This is a subtle but profound shift.

  • Which assumptions are allowed to move?
  • Which ranges trigger escalation?
  • What behaviour is automatically logged and explainable?

Technology enables this by making behaviour observable rather than controlled through friction. Fast models demand smarter governance, not heavier governance.

7. Human Interfaces Catch Up with Machine Speed

One of the least discussed enablers is interface design. In 2035, actuaries don’t scroll through output files. They interact with surfaces, ranges, and dynamic explanations. Visualisation isn’t just cosmetic. The model speaks in shapes and responses, not tables. Without this, even the fastest model is wasted.

Conclusion

Unfortunately, none of these technologies matter in isolation. The real enabler of the 2035 vision is coherence, i.e. models that are fast enough for exploration, structured enough for AI, transparent enough for trust, and governed enough for reality.

That’s why the future doesn’t belong to:

  • Fully bespoke open-source estates, or
  • Fully opaque vendor platforms

It belongs to modelling environments that blend discipline with freedom and treat technology as a way to remove friction, not add ceremony.


Read more

Every few years, life insurance modelling circles back to a familiar idea: “Surely we can build this ourselves now?”

Open-source languages are mature. Cloud infrastructure is cheap and elastic. Numerical libraries are faster than ever. On the surface, the case for fully open-source financial modelling feels stronger than it ever has.

And yet, time and again, large-scale internal build attempts quietly stall, get re-scoped, or end up re-introducing vendor platforms through the back door. This isn’t because open source has failed actuarial modelling. It’s because life insurance modelling turns out to be much more than code.

Read more

Over the last decade a number of free / open source database environments such as PostgreSQL and MySQL have emerged to challenge the traditional players like Microsoft SQL Server and Oracle.  Like PostgreSQL and MySQL, SQLite has found favour with lone developers using limited data sets or developing lightweight applications.  Even users of SQL Server Express Edition have moved to SQLite, where compatibility with the full edition of SQL Server isn’t a significant requirement.

Read more

It is not uncommon for multiple model developers to want to work on the same project. Changes made by each developer need to be added in to a central codebase to ensure there is always one source of the truth. Another common requirement is to be able to carry out code reviews, to check how one version of a model differs from the previous version, or to peer review an individual’s model developments.

Read more