IFRS 17 Vendor Solutions: A Market Scan

The IFRS 17 accounting-engine market matured fast. In the space of three years it went from a handful of early-stage products that required heavy professional-services support to a crowded market with mature offerings, clear documentation, and multiple live deployments at mid-to-large insurers. If your company has not yet chosen an IFRS 17 accounting engine, the good news is that the market is no longer a research project — it is a selection exercise against a reasonably stable set of options. The bad news is that the options segment differently from how they appear in the marketing material, and understanding the segmentation is where the selection starts.

What follows is the market as I see it from the practitioner side. I have worked on vendor assessments across three jurisdictions and seen implementations of several of the solutions listed below. The segmentation holds; the individual product positioning inside each segment drifts as vendors add features.

1. What an IFRS 17 accounting engine actually does

Before the segmentation, the definition. An IFRS 17 accounting engine takes IFRS 17 inputs — expected cash flows, actuals, discount curves, risk adjustment, grouping reference data — and produces two outputs: an IFRS 17 subledger containing the full set of journal entries at the level of granularity the standard requires, and the disclosure tables that support the measurement.

That is the shared core. Every vendor on the market does this. What varies is everything around the core: where in the insurer’s system architecture the engine plugs in, what inputs it accepts without transformation, whether it performs modelling or only measurement, and whether it handles the downstream integration to the general ledger and financial reporting stack.

The shape of the engine you need depends on what the rest of your architecture looks like. An insurer with strong in-house ETL capability and a modern actuarial modelling platform needs a different engine from one whose only existing systems are a policy administration database and a general ledger.

2. Category one: pure accounting engines

Pure accounting engines accept data inputs in a tightly specified format and produce a subledger and disclosures. They do not transform data. They do not run actuarial models. They do not produce general-ledger-ready journals without an intermediate mapping step.

This category is for insurers who have the upstream infrastructure to feed the engine correctly. A mature actuarial modelling environment, a dedicated data staging layer, an ETL team. In that context a pure accounting engine is the right choice: it does one job, it does it well, and it does not impose opinions on the architecture around it.

The risk in this category is input rigidity. Because the engine does not transform inputs, anything that does not arrive in the exact shape of its data dictionary is either rejected or silently misinterpreted. Data-dictionary fluency is a required skill on both sides of the vendor relationship.

3. Category two: hybrid accounting engines

Hybrid engines are pure accounting engines with add-on components. The add-ons vary by vendor but typically include a data-staging layer with configurable ETL, a data warehouse for intermediate storage, light actuarial modelling capability (often strongest for non-life), and subledger-to-general-ledger transformation.

The hybrid category is the commercially busy middle of the market. It suits insurers who have some upstream capability but not all of it. A common pattern: the insurer has a mature life actuarial system but no non-life modelling capability, and wants the engine to handle non-life measurement natively. Another common pattern: the insurer has strong actuarial modelling but weak ETL, and wants the engine’s staging layer to absorb the transformation work.

The tradeoff in the hybrid category is that the add-ons are rarely best-in-class individually. A hybrid engine’s modelling component is typically not as powerful as a dedicated actuarial platform. Its ETL is typically less flexible than a dedicated data staging tool. What it offers is integration and simplification — one vendor, one contract, one integration project, one support relationship.

4. Category three: one-stop-shop offerings

One-stop-shop offerings combine everything: ETL, data warehouse, actuarial modelling (life, non-life, and risk adjustment), assumption management, measurement, subledger, and general-ledger transformation. Some also include regulatory reporting modules, financial consolidation, and the disclosure-production layer.

This category suits insurers who either have no existing infrastructure to plug an engine into, or who are using IFRS 17 as the trigger to replace their existing stack. Greenfield implementations, insurers in emerging markets with immature legacy systems, and groups deliberately standardising across multiple subsidiaries are the buyers who end up here.

The cost and implementation timeline of one-stop-shop solutions is higher, but so is the potential simplification. An insurer who successfully deploys a one-stop-shop solution ends up with fewer vendors, fewer integration points, and a single system of record for IFRS 17. An insurer who deploys one partially ends up paying for capability they do not use, locked to a stack that is expensive to escape.

5. How to read the market list

Several vendors sit across categories. The same vendor may sell a pure accounting engine to a large multinational and a one-stop-shop offering to a mid-sized insurer in a different market. Marketing material often lists all the capability the vendor has built across the product range without making clear which configuration a particular buyer would end up with.

The first question to ask any vendor is which category their solution falls into for the configuration you would deploy. Not what the product does in total — what the product does in the shape you would buy. A one-stop-shop solution deployed as a pure accounting engine is an expensive way to buy a pure accounting engine. A pure accounting engine extended into a one-stop-shop role through configuration is typically an engineering project that outlives the implementation team.

6. What varies beneath the category

Within each category vendors differ on several axes that matter more than marketing pages suggest.

Input flexibility — how wide is the range of input shapes the engine accepts without transformation. A narrow range means more ETL work outside the engine; a wide range means more opinionated internal behaviour that the insurer has to understand.

Audit trail — how granular is the record the engine keeps of every measurement decision and every journal generated. Weak audit trails create downstream governance work that auditors will eventually find.

Performance at scale — how the engine behaves at full book volume. Several engines that passed evaluation on pilot data sets developed performance problems at the scale of a large non-life portfolio. Testing at representative volumes is load-bearing.

Configurability of grouping and cohorting — how easily the engine can be reconfigured when the insurer’s grouping decisions change. Some engines treat grouping as near-immutable; others treat it as a runtime parameter. The difference matters several closes later.

Release cadence — how frequently the vendor ships new versions, and what the impact on existing implementations is. Some vendors release quarterly with tight backward compatibility; others ship annually with wider-impact changes.

Local-regulatory overlay — whether the engine handles jurisdiction-specific requirements layered on top of IFRS 17, such as local GAAP reconciliation or statutory reporting in parallel.

These are the axes that differentiate. They are rarely compared on a like-for-like basis in vendor marketing material, and they tend to be what distinguishes a good fit from a bad fit once the category is right.

Closing thought

The IFRS 17 vendor market is large and reasonably mature. The useful first cut is the three categories — pure accounting engines, hybrids, and one-stop-shop offerings — because they map cleanly to which shape of insurer infrastructure the engine is designed to complement. Once the category is right, the axes within a category narrow the selection to two or three products that are genuine options. That narrowing is the piece of the selection exercise that actually produces a good fit. Starting from a long list of vendor names without the category lens is how evaluation projects extend into six months and still produce a decision the organisation is not sure about.