Choosing Between IFRS 17 Accounting Engine Vendors: A Selection Methodology

Vendor selection under IFRS 17 is harder than it looks from the outside. The market has matured, which means there are more credible products, which in turn means the easy path of picking the obvious leader is no longer available. Every insurer I have worked with has had to run a real selection process, and most of them have made mistakes on the first pass — usually around scoping, criteria weighting, or confusing the vendor demo with the actual fit.

What follows is the selection methodology I use. It is not the only valid approach, but it is one that has survived real RFPs, real proof-of-concepts, and real regret. It is written for insurers who are past the gap analysis and FIA phases and need to convert “we need a vendor” into “we have signed a contract with the right one for our stack”.

1. Start with what you already have

Before looking at vendors, catalogue the internal components that will remain through go-live. Policy administration systems almost always stay. Some actuarial models will stay and need extension; others are going to be replaced regardless of IFRS 17. The staging platform might persist but will almost certainly need new ETL pipelines.

The output of this step is a honest inventory of what is in, what is out, and what is ambiguous. “Ambiguous” is the category that matters — components that could go either way depending on cost, effort, and the vendor fit. Leaving those unresolved until after vendor selection is the single biggest mistake I see. The vendor shortlist changes materially depending on whether the actuarial model is in or out, whether the staging platform is being replaced, and whether the risk adjustment is being modelled in-house.

2. Define the required new components

Map the components the standard requires that you do not currently have. A typical list includes:

• A CSM engine capable of unlocking and non-unlocking movements on locked-in and current discount curves
• Profitability testing and cohort tagging at contract or group level
• Expense allocation logic for attributable versus non-attributable costs
• Risk adjustment calculation (either in the actuarial model or in the accounting engine)
• An accounting engine that produces IFRS 17-specific journal entries
• Transition calculation tooling for the opening balance sheet
• Disclosure generation aligned with the standard’s presentation requirements

Each of these is a candidate to be built in-house, bought from a vendor, or hybrid. Scope them individually. The worst scoping decision is to treat “IFRS 17 solution” as a single component and ask vendors to bid on it, because that forces bundles and prices you cannot meaningfully compare.

3. Match vendor offerings to your component list

Vendor products fall into three rough categories: pure accounting engines, hybrid engines that include some actuarial capability, and one-stop-shop offerings that bundle the actuarial model, accounting engine, risk adjustment, and disclosures. The trap is assuming a one-stop-shop is automatically better because it is more complete. In practice, modularity is a feature. Most mature programmes end up combining components from two or three vendors plus internal build — because no single vendor is best at every component, and few insurers want to sole-source a regulatory-critical stack.

The component map makes this possible. For each component on your required list, identify which vendors cover it, how well, and at what price. The shortlist emerges from the combinations, not from the vendors individually.

4. Decide what to replace

This is the buy-versus-build decision at component level, not at platform level. Review each internal component you currently have against two questions: how much work is needed to make it IFRS 17-compliant, and how much ongoing cost does it carry after compliance? An actuarial model that takes six months of rework and then requires a senior developer indefinitely to maintain is often more expensive than a vendor module with a licence fee.

The same applies to the staging platform. A staging layer that needs heavy ETL rework to feed the accounting engine may already be at end of life. IFRS 17 is a reasonable trigger to upgrade it, if the economics stack up independently of the standard.

5. The selection criteria that actually matter

Once the component map and vendor shortlist are fixed, you need a scoring framework. The criteria I weight heavily in real engagements:

Price. Licence, implementation, ongoing maintenance, and the cost of the configuration resources you will need on your side. Vendor pricing varies significantly across the market — sometimes by a factor of three for comparable functionality.

Data input requirements. Every vendor handles input data differently. Some want the insurer to do heavy transformation upstream; others ingest rawer data and transform internally. Neither is universally better — the right answer depends on whether your staging layer is a strength or a weakness.

User experience. How many resources will you need, and how quickly can they become productive? Dashboards, data dictionaries, and navigation matter more than the polished demo suggests, because they drive training cost and query turnaround in BAU.

Configuration flexibility. Can you adjust disclosures for regional requirements? Can you handle non-standard methodology choices the business has committed to? Configuration that requires a vendor change request for every minor tweak is a red flag for programmes that still have open methodology decisions.

Traceability. If a journal entry looks wrong, can you lift the bonnet and walk back through the calculation to the input cash flow? A normal resource should be able to trace a result front to back. This is the criterion that predicts audit pain most reliably. Vendors that hide the calculation logic behind a black-box interface create reconciliation debt that compounds every close.

Analytical capability. Slicing and dicing at different levels — group, portfolio, product, channel — matters for management reporting as much as for regulatory reporting. A tool that produces compliant numbers but cannot answer “why did profit move” at a useful granularity pushes that work back onto the actuarial team.

Audit trails, workflows, and controls. How are tasks assigned, access restricted, sign-offs captured? Auditors will test the control environment, not just the numbers. A vendor with strong workflow tooling saves months of control design in the BAU phase.

General ledger integration. Transforming the subledger into a GL-ready format and loading it into the finance stack is often where the programme discovers its data governance weaknesses. Some vendors have strong GL connectors for the major finance platforms; others produce a file and leave the integration to you. That distinction is material, especially for finance teams who have not been close to the programme.

Implementation approach. Vendors range from hands-on (their consultants drive most of the configuration) to hands-off (they provide tooling and documentation, you configure). The right choice depends on your internal capability, the availability of implementation partners, and your appetite for specialist skill dependency after go-live.

6. The RFP and the proof-of-concept

Once criteria are fixed, the RFP should be scored against them explicitly, with weights agreed before any vendor response is read. The weighting exercise is where political pressure tends to appear, and it is much easier to defend scores later if the weights were locked in advance.

A proof-of-concept on the top two or three candidates is nearly always worth the time. A POC against your real data, your real methodology decisions, and one of your actual product lines will surface things no demo reveals — data quality gaps, configuration limits, traceability shortcomings, and the practical experience of working with the vendor’s implementation team. Programmes that skip the POC to save time usually rediscover it as a three-month blocker in configuration.

7. The decision

After the RFP and POC, the decision usually comes down to two or three candidates that are each acceptable. The final choice is rarely about the product and usually about fit — with your component map, your internal team, your regulator’s expectations, and the implementation partner you are likely to use. I have seen insurers pick the “second best” product on paper and run a cleaner programme because the fit was better.

The point of the methodology is not to produce a vendor name deterministically. It is to produce a decision the programme can defend to the board, the audit committee, and the regulator — and that the team will not regret six months into configuration. Vendor selection is reversible in theory and almost irreversible in practice. Treating it with the rigour of an irreversible decision tends to produce the best outcomes.