Choosing an IFRS 17 Actuarial Prototype Tool: What a Shadow Model Has to Do

Most IFRS 17 programmes eventually need a second calculation engine alongside the production accounting engine. Call it a prototype, a shadow model, a replication tool — the name varies by firm, the function is the same. It is the thing you use to validate the production engine against a known-good second opinion, to run what-if assessments before the real engine is configured, and to roll CSM forward for transition with confidence.

Choosing this tool well is underrated work. A bad choice wastes months of validation cycles and leaves the team unable to answer the question that matters most on audit: can you independently reproduce the numbers the engine is producing? Here is what I look for when scoping prototype tools with clients.

1. Why a prototype model exists in the first place

The IFRS 17 accounting engine — whether it is a vendor solution or an in-house build — is the production system. It produces the subledger, the disclosures, and the numbers that get audited. A prototype model is the independent second path. It exists to serve a specific set of use cases that the production engine alone cannot answer:

• Validation of the production engine against structured test cases with known expected results, where “known expected” means reproduced outside the engine on purpose.
• Dry runs using real company data, to surface configuration or data issues before the production engine is the dependency for close.
• Transition calculations, where the CSM has to be rolled forward across many years under a chosen transition approach — sometimes with multiple candidate approaches compared side by side.
• Financial impact assessments before the vendor is picked, where the prototype is the only calculation capability the team has.
• Management information, where the flexibility of the prototype is used to produce comparisons, KPIs, and sensitivities that the production engine is not built to expose.

A prototype that supports all five of those is doing more work than many teams recognise when they select it.

2. The three failure modes of a bad prototype

Before talking about what to look for, it helps to name the ways these tools go wrong. On engagements where the prototype choice was regretted later, the cause was almost always one of three things.

ETLs and input formats

The single largest source of wasted time on a prototype project is getting data into the tool’s required shape. If the prototype demands a rigid input schema that does not match how the insurer’s actuarial model and accounting systems produce data, someone has to write and maintain a transformation layer between them. That transformation layer is its own source of bugs, and it has to be validated too, which is a second-order validation problem on top of the real one.

The question to ask any prototype vendor on day one is: what does your tool accept as input, and how much transformation does the insurer have to do before the data fits that shape?

Configuration and flexibility

Every insurer has methodology choices that are not in the IFRS 17 standard itself — the risk adjustment approach, the coverage unit definition, the expense allocation rule, the handling of reinsurance held, the transition approach. The prototype has to be able to mirror these choices precisely, or its output is not comparable to the production engine’s output.

The failure mode here is a tool that is configurable in theory but brittle in practice. Changes to methodology break the tool’s internal assumptions, runtimes blow out after customisation, or the audit trail silently changes shape when a configuration is toggled. The test is not whether the defaults look reasonable. The test is what happens after the first three methodology deviations from those defaults.

Traceability and debugging

When the prototype and the production engine disagree, someone has to figure out why. If the prototype is a black box — numbers go in, numbers come out, no intermediate steps exposed — the team is stuck. They cannot tell whether the difference is a methodology error, a data error, a configuration error, or a bug in one of the two engines.

A good prototype exposes its calculations. Ideally you can export the full workings to a format a reviewer can interrogate directly — Excel live formulas are the most widely-accepted format, because an auditor can trace any figure back to its inputs without needing to understand the underlying tool. The dashboard should let a user drill from a headline number down to the group, contract, and cash flow vectors that produced it.

3. What a good prototype looks like

Matching the three failure modes above, the characteristics that matter on the tools I have seen work well:

Flexible ETL, or none at all

The best prototype tools either accept data in the shape the insurer’s systems already produce, or provide a built-in ingestion layer that maps source locations to internal variables. Either approach removes the transformation burden from the team. The worst tools demand the data in a rigid schema and leave the insurer to build the converter — which is exactly the kind of brittle custom code the prototype is supposed to help avoid.

Methodology configuration, not methodology replacement

The prototype must come with a sensible IFRS 17 methodology baseline — default measurement models, default CSM unlocking rules, default coverage unit patterns. But every single one of those defaults has to be configurable per run, per portfolio, per group, because the production engine’s configuration will diverge from the defaults and the prototype has to match. Configurability has to be a first-class feature, not a customisation layer tacked on.

Traceability to Excel

The pattern I trust most is a backend that does the heavy lifting (typically Python for performance and auditability) combined with an Excel export layer that reveals every calculation as live formulas. This means the computational engine is fast enough to handle real contract volumes, and the audit trail is in the one format every reviewer already reads fluently. Anything less — static reports, PDF dumps, proprietary viewers — makes the audit conversation harder than it needs to be.

4. The use cases that drive the selection

Selection criteria without use cases are abstract. The test for any prototype is whether it handles the five things it is actually being asked to do:

• Validation — does it have a test case generator, a configuration framework, and a comparison tool that takes production engine output and prototype output and highlights the differences automatically?
• Dry runs — once the ETL or ingestion is set up for validation data, does it accept live company data with minimal rework?
• Transition — can it roll the CSM forward across the full transition period on the press of a button, under a configurable transition approach, without manual intervention each year?
• Financial impact assessment — can it produce the income statement and balance sheet comparisons a team needs before the production engine exists, with enough flexibility to model alternative methodologies?
• Management information — does its output layer support building a dashboard that surfaces KPIs and IFRS 4 vs IFRS 17 comparisons without a separate BI tool?

A prototype that handles the first three well and the last two adequately is a strong choice. A prototype that handles only the first one is a test harness, not a prototype.

Closing thought

The prototype’s value shows up as absence — absence of rework, absence of audit delays, absence of transition-calculation panic at go-live. Insurers that skipped the prototype and tried to validate the production engine against itself tend to discover the cost of that choice in the third parallel-run cycle, when they cannot explain a variance and have nowhere independent to reproduce the number.

Spend the time on this decision. The questions to lean on are the three failure modes — input rigidity, configuration brittleness, and opaque calculations — and the five use cases above. Everything else is detail.