Approaches to Integrating IBNR Solution with IFRS 17 Reserving

IBNR Solution with IFRS 17 Reserving: Which Approach Wins?

How actuarial and finance teams in GCC and global markets can choose integration methods that improve reserving accuracy, pass audits, and cut close cycle times without rebuilding everything from scratch.

✓ Written by IFRS TECH’s advisory team · ✓ Serving GCC, Europe & APAC · ✓ Actuaries + CPAs + CFAs

TL;DR

Getting your ibnr solution with ifrs 17 reserving to work together isn’t just a technical task. It’s the difference between passing your next audit and scrambling through another close cycle. This article compares four integration approaches native SaaS, sub-ledger middleware, API builds, and manual exports, covering cost, accuracy, and compliance risk. You’ll also find a build vs buy breakdown and five questions to ask any actuarial SaaS provider before you sign. Pick your approach, then make it stick.

Why Most Integration Projects Fail Before They Even Start

When IFRS 17 became effective for annual reporting periods starting January 1, 2023, insurers weren’t just adopting a new accounting rule. They were inheriting a data problem they hadn’t fully solved. Every single insurer surveyed in a 2024 Deloitte Canada study reported that their financial reporting processes became longer and more complex after adoption.

That’s worth sitting with. Not some insurers. All of them.

The IBNR problem sits at the center of this. Incurred But Not Reported reserves feed directly into the Liability for Incurred Claims under IFRS 17. If your IBNR solution isn’t integrated correctly with your IFRS 17 reserving engine, you’re producing numbers that are internally inconsistent and auditors have started catching it.

This article covers:

• The four main approaches to IBNR solution integration with IFRS 17 reserving and what each one costs in time, money, and accuracy
• A clear build vs buy comparison with actual cost ranges
• How to choose the right actuarial SaaS for your team’s compliance requirements

IFRS TECH works with insurers across GCC, Europe, and APAC on exactly this kind of integration challenge. The patterns below come from real implementations, not hypotheticals.

The Disconnect Between Actuarial Systems and IFRS 17 Requirements

Here’s the issue that most articles won’t say plainly: traditional IBNR software was designed for one job producing reserve estimates at the aggregate level. IFRS 17 needs something different. It needs those reserves broken down by cohort, discounted for the time value of money, and fed into a Liability for Incurred Claims roll-forward that’s auditable at the group of contracts level.

Most legacy systems weren’t built for that. The output format is wrong, the granularity is wrong, and the timestamps don’t align with what the IFRS 17 measurement engine expects to receive.

That gap between what your IBNR software produces and what your IFRS 17 system needs is exactly what integration is supposed to close. How you close it matters enormously.

What “Integration” Actually Means in This Context

It’s worth being specific. Integration here means the automated, auditable flow of IBNR data run-off triangles, tail factors, projected ultimate claims from your reserving tool into the IFRS 17 calculation engine, in a format that supports cohort-level LIC measurement, discounting, and disclosure.

Manual copy-paste is not integration. Neither is a weekly export to a shared drive. Both are risk sources that auditors have flagged repeatedly in post-implementation reviews.

If you’re still deciding which tools belong in your stack, the comparison in our article on IBNR software solutions is a good starting point before you commit to an architecture.

The Four Main Approaches to Integrating an IBNR Solution with IFRS 17 Reserving

There isn’t one right answer here. The right approach depends on your team size, how much technical debt you’re willing to carry, and how tight your audit requirements are. But there is a clear ranking when it comes to compliance risk and reserving accuracy.

Approach 1 — Native Integration (Actuarial SaaS with Built-In IFRS 17 Engine)

This is the cleanest option. A single actuarial SaaS platform handles IBNR calculation and IFRS 17 measurement in the same system, using the same data model. No translation layer. No format mismatch. IBNR outputs feed directly into LIC calculations, cohort tracking, and disclosure templates without leaving the environment.

The biggest advantage isn’t speed, it’s auditability. When your external auditor asks to trace a specific cohort’s IBNR back to the source triangle, you can do it in one system with a full log. That’s something a two-system setup with a manual handoff can rarely produce.

Platforms like IFRS TECH’s Delta are built on this model, actuarial SaaS providers for IBNR compliance that treat reserving and IFRS 17 measurement as one workflow rather than two systems talking to each other.

The trade-off? You’re locked into that vendor’s methodology. For teams with highly customized triangle methods or unique exposure bases, this sometimes requires negotiation on configuration options rather than true flexibility.

Approach 2 — Sub-Ledger Middleware Integration

Here, your existing IBNR software stays in place. A sub-ledger sits between it and the general ledger, translating actuarial outputs into IFRS 17 measurement data. Solutions like Moody’s RiskIntegrity IFRS 17, Aptitude’s IFRS 17 Solution, and SAS take this approach.

This works reasonably well when your actuarial team has strong ownership of their existing reserving model and can’t migrate it easily. The sub-ledger handles the CSM roll-forward, experience adjustments, and posting logic that your actuarial system was never designed for.

But let’s be honest about the risk. The sub-ledger is only as good as the data it receives. If your IBNR tool outputs quarterly ultimates and your IFRS 17 system needs monthly cashflow projections by cohort, the middleware has to bridge that gap through assumptions. Those assumptions need to be documented, validated, and disclosed. That’s additional governance work that often gets underestimated at implementation stage.

Approach 3 — Build Your Own Bridge Using APIs

Some insurers — mostly larger ones with strong internal IT teams — build custom API connections between their IBNR tool and IFRS 17 system. The data is pulled, transformed, validated, and pushed on a scheduled basis.

This gives you maximum control. You define the field mapping, the validation rules, the timing. You can handle edge cases that a packaged middleware tool might not anticipate for your specific portfolio.

The cost is real, though. Building in-house carries upfront costs of $200,000 to $700,000 with timelines of 8 to 15 months, and that’s before ongoing maintenance. Every time either system is updated, someone has to check whether the bridge still works. That person is usually your most senior IT actuary — the one who also has 14 other things to do at quarter close.

Approach 4 — Manual Export-and-Reformat Workflows

Still common. Probably more common than anyone in this industry would like to admit.

Actuarial team produces IBNR outputs in Excel or a proprietary format. Finance team receives the file, reformats it, loads it into the IFRS 17 system manually. Someone builds a reconciliation check. Someone else signs off on it. Everyone hopes nothing changed in the column structure since last quarter.

This isn’t sustainable — and KPMG said as much in their 2024 governance study, noting that sourcing and cleansing high-quality data remains an unresolved hurdle for many insurers. The manual workflow is usually the reason. Not a lack of talent. A lack of automation.

If this is your current state, the priority is moving off it — not optimizing it.

Build vs Buy: The Real Cost Comparison for IBNR Software Integration

The build vs buy question comes up in almost every IBNR integration project. The answer is almost always “buy” — but not for the reasons people usually give.

It’s not just about cost. It’s about what you’re actually building.

Where Build-Your-Own Projects Consistently Overspend

The teams that go custom-build almost always underestimate three things: the cost of the initial data mapping exercise, the ongoing maintenance burden when either system upgrades, and the documentation required to satisfy auditors that the custom bridge is producing reliable, traceable outputs.

That last one is what kills timelines. An external auditor reviewing a bespoke API bridge for the first time doesn’t have a standard playbook. They ask questions. A lot of questions. Your IT team and actuarial team spend weeks answering them instead of closing the quarter.

One more thing nobody mentions until it’s too late: the person who built the bridge. When they leave the firm, that institutional knowledge often goes with them. What looked like a competitive advantage becomes a liability in about 18 months.

What Purpose-Built Actuarial SaaS Actually Costs

The IFRS 17 software market reached USD 1.41 billion in 2024 and is heading toward USD 4.13 billion by 2033 at a 13.7% annual growth rate, according to DataIntelo’s market report. That growth is driven by exactly this shift, insurers moving away from manual and bespoke approaches toward purpose-built platforms.

For smaller insurers, Deloitte’s 2025/26 Africa Insurance Outlook puts average IFRS 17 implementation costs at around US$110,000 for system upgrades, software, and training. That’s at the low end. Mid-size insurers with more complex portfolios typically see total SaaS integration costs in the USD 150,000 to USD 400,000 range still well below the $700,000 ceiling of a build-from-scratch project, with far less ongoing maintenance risk.

The other factor is time. A pre-built IFRS 17 vendors for scalable compliance category has condensed what used to be 12-month build cycles into 3 to 5 month onboarding timelines. For teams facing the next reporting deadline, that gap matters.

“Insurers that view IFRS 17 implementation as a business transformation opportunity report 32% higher stakeholder satisfaction than those treating it as pure compliance”  KPMG 2024 Insurance Report

Reserving Accuracy: How Integration Approach Changes Your Numbers

This is where it gets technical and where the choice of integration approach has real financial consequences, not just operational ones.

Discounting and Risk Adjustment Under IFRS 17 | Where Poor Integration Breaks Down

IFRS 17 requires insurers to discount the expected future cash flows for the Liability for Incurred Claims. That means your IBNR output can’t just be a single ultimate number. It needs to be a payment pattern a stream of projected cashflows by period that can be discounted at the appropriate IFRS 17 rate.

Most traditional IBNR software produces ultimates and development patterns. It doesn’t always produce the per-period cashflow stream IFRS 17 needs.

When integration is done through a manual export, the translation from development pattern to discounted cashflow stream is often handled by a separate Excel model. That model has assumptions. Those assumptions are usually not reviewed quarterly. And over time, they drift from what the actuarial team actually believes about claim payment timing.

That drift shows up as unexplained experience variances in the LIC roll-forward. Auditors ask about them. Nobody has a clean answer.

Native integration platforms handle this by forcing the cashflow projection to live inside the same system as the IBNR calculation. The payment pattern is a function of the triangle output, not a downstream assumption bolted on by the finance team.

Cohort-Level Granularity and Why It Matters for IBNR

IFRS 17 requires that contracts within a group cannot have been issued more than one year apart. For P&C insurers, this means reserving cohorts by policy year rather than the traditional accident year approach and that requires different data than most IBNR systems are set up to produce.

Baker Tilly’s actuarial IFRS 17 review notes that accident year reserves alone may not be acceptable under IFRS 17’s cohort requirements. You can’t just feed your existing chain-ladder output into the IFRS 17 engine and assume the grouping logic is correct. The IBNR software and the IFRS 17 system need to agree on how contracts are grouped before any numbers get produced.

That alignment is trivial if both systems share the same data model. It’s a significant configuration project if they don’t.

And for what it’s worth, a 2023 Deloitte study found that insurers adopting AI-driven reserving models saw reserve accuracy improve by 12 to 18%, reducing volatility in reported earnings. Better tooling produces better numbers. The integration architecture is part of the tooling.

GCC and APAC Insurers Face a Different Set of Constraints

Most of the published guidance on IBNR-IFRS 17 integration was written with European or North American insurers in mind. The GCC context is different and the differences matter for choosing an integration approach.

Manual Processes Still Dominate in the Region

The GCC insurance market is heavily dominated by Motor and Medical lines, with those two classes accounting for between 50% and 80% of market share in the KSA and UAE. Most of these portfolios are well-suited to PAA (Premium Allocation Approach) measurement under IFRS 17. But even under PAA, the IBNR still drives the Liability for Incurred Claims, and that reserve still needs to be cohorted, discounted, and disclosed.

The challenge, as documented by practitioners in the region, is that many GCC insurers rely on manual postings and accounting journal entries due to system limitations not by choice, but because modernization was deprioritized while IFRS 17 compliance was being addressed. That left a lot of insurers compliant on paper but dependent on spreadsheet bridges that can’t scale.

Compliance Improvements Available to GCC Insurers Right Now

The good news is that cloud-based actuarial SaaS has changed the economics for mid-market GCC insurers. You don’t need a $500,000 on-premises deployment to get native IBNR-to-IFRS 17 integration. Purpose-built platforms hosted on cloud infrastructure bring implementation timelines down to 3 to 5 months and eliminate the hardware dependency that blocked many regional firms from upgrading.

For teams evaluating options, IFRS 17 compliance solutions with GCC-specific configuration regulatory report formats, Arabic-language interfaces, SAR-denominated outputs are now available from regional vendors rather than requiring customization from global platforms designed for European markets.

Insurers with strong governance frameworks also close faster. KPMG’s 2024 governance study found that teams with formal implementation committees resolved challenges 50% faster than those without structured oversight. The integration architecture can’t fix a governance gap. But the right platform makes governance easier to build and maintain.

Choosing the Right IBNR Software for IFRS 17 Compliance

A 2024 PwC survey found that 65% of insurers are considering changing their finance or actuarial software within the next five years. That’s not a coincidence. Post-implementation, teams are realizing that compliance was achieved but efficiency wasn’t.

The next wave of decisions won’t be “does this tool handle IFRS 17?” They’ll be “does this tool handle IFRS 17 well enough to run quarterly close in under two weeks without manual intervention?”

Five Questions to Ask Any Actuarial SaaS Provider

1. Does your IBNR output produce per-period cashflow streams, or just ultimates?

   If the answer is “we produce ultimates and you apply a payment pattern externally,” that’s a sub-ledger problem waiting to happen.

2. How does your system handle cohort grouping under IFRS 17?

   Ask for a worked example using policy-year cohorts, not accident-year. The answer will tell you how deeply the IFRS 17 logic is embedded in the reserving layer.

3. What does your audit trail look like at the cohort level?

   Can you trace a disclosed LIC figure back to the source triangle in one system, without leaving the platform?

4. How many valuation runs can the system execute per reporting period?

   IFRS 17 typically requires 14 or more base, sensitivities, projections. If the system slows significantly under that load, your close cycle will suffer.

5. What does the data model look like between your IBNR module and your IFRS 17 measurement engine?

   Are they the same model, or does data move between them via export? This single question separates native integration from everything else.

For a broader view of how different vendors handle these questions, the analysis in our guide on IFRS 17 software vendor shortlist covers the major platforms with side-by-side criteria.

I’ll also admit this: I don’t have long-term data on how AI-assisted reserving tools perform over multiple IFRS 17 reporting cycles at scale. The accuracy gains from Deloitte’s 2023 study are promising, but most of those implementations are 18 to 24 months old. Whether they hold up through a hard market cycle with significant reserve development is still an open question. Teams evaluating AI-augmented IBNR software should weight vendor track record in volatile years, not just benchmark accuracy on stable portfolios.

The integration approach that worked in 2023 may need to handle significantly different reserve volatility in 2026 and beyond. Worth asking about before you commit.

What You Now Know

• There are four main approaches to connecting an IBNR solution with IFRS 17 reserving — native SaaS integration is the most audit-ready, manual exports are the most common and the most fragile
• Build-your-own costs $200K to $700K upfront with ongoing maintenance risk; purpose-built actuarial SaaS brings that down significantly while cutting time-to-live from 12+ months to 3 to 5 months
• Reserving accuracy under IFRS 17 depends on cohort-level cashflow data, not just aggregate ultimates — and that requires the IBNR and IFRS 17 systems to share a data model, not just exchange files

The integration decision isn’t just technical. It’s a disclosure decision. Every reserve number that appears in your IFRS 17 financial statements traces back to how and how well your IBNR solution connects to your reserving engine. Teams that get this right run faster close cycles, face fewer audit queries, and produce more accurate cohort-level numbers than competitors still relying on manual bridges.

The IFRS 17 data management systems that support this kind of native integration exist now and are deployable within a quarter. The question isn’t whether to upgrade. It’s whether you do it before or after your next stressful close.

Frequently Asked Questions

What is an IBNR solution in the context of IFRS 17 reserving?

An IBNR solution is actuarial software that estimates claims incurred but not yet reported. Under IFRS 17, these estimates feed into the Liability for Incurred Claims and must be produced at cohort level, discounted for the time value of money, and supported by an auditable cashflow projection — requirements that go beyond what traditional IBNR tools were designed to meet.

What are the main approaches to integrating IBNR software with IFRS 17 systems?

There are four: native integration through a single actuarial SaaS platform, sub-ledger middleware that sits between the reserving tool and general ledger, custom API bridges built internally, and manual export-reformat workflows. Native integration through purpose-built actuarial SaaS produces the fewest audit issues and the lowest ongoing maintenance cost for most insurers.

How does the choice of IBNR integration approach affect reserving accuracy?

Poor integration introduces translation errors between the actuarial output and the IFRS 17 measurement engine, particularly around cashflow timing, cohort grouping, and discounting logic. A 2023 Deloitte study found that insurers using purpose-built reserving tools improved accuracy by 12 to 18%, largely by removing the manual steps where errors accumulate.

What should GCC insurers specifically consider when choosing an IBNR solution for IFRS 17?

GCC insurers should prioritize platforms with PAA-ready IBNR workflows, cloud deployment options, and regional regulatory report formats. Many regional insurers are still on manual processes that can’t scale cloud-based actuarial SaaS with native IFRS 17 integration now makes upgrading feasible within a standard budget and timeline for mid-market carriers.

Should insurers build or buy an IBNR solution for IFRS 17 compliance?

For most insurers, buying is the right answer. Build-your-own projects typically cost $200,000 to $700,000 upfront, take 8 to 15 months, and create ongoing maintenance dependencies on specific internal staff. Purpose-built actuarial SaaS platforms cut those numbers significantly while providing out-of-the-box audit trails, disclosure templates, and IFRS 17 measurement logic that custom builds have to replicate from scratch.