Vendor 3.1: Our latest IFRS 17 vendor analysis
10 December 2019
Background
Over the past three years, PwC has undertaken an Insurance Finance & Risk vendor review. Our review considers both the traditional and modernized capabilities required by an insurers finance and risk function, alongside an assessment of the functionality required for IFRS 17. We’re delighted to announce that PwC have refreshed the Insurance Finance & Risk vendor review; version 3.1 is now available across our global PwC network.
Market perspective
During the three years that we’ve undertaken the Insurance Finance & Risk vendor review the insurance industry has experienced significant external and internal disruption. These disruptions have triggered many insurers to increase the level of automated transactional processing and to focus on streamlining reporting & compliance activities. For some insurers, these disruptions have unlocked an opportunity to look at digitization, focusing on performance and driving better business results alongside a wider cost and efficiency agenda.
Since vendor 3.0, we’ve seen an increasing number of IFRS 17 programmes include one or more investments in a digitally-enabled, cloud-based data, ERP or EPM technology. We anticipate that most insurers will need to embark on at least some aspect of finance modernization alongside the adoption of IFRS 17 and/or LDTI.
IFRS 17 market maturity
We have seen a number of vendors who provide IFRS 17 solutions reach a critical mass of six (or more) global clients. Scale brings pressure to deliver but it also creates more clarity on both the development areas and the strengths of these solutions. As a result, roadmaps for the next 12 - 18 months are much clearer and typically involve multiple releases.
Our collective reflection was that much has moved on, but little has changed. IFRS17 remains a very challenging standard and while vendors have moved on with certain aspects of their solutions their roadmaps attest to their being much more to go. At the same time little has changed, the rapid emergence of some later market entrants shows that the “leaders” (by market share) can be caught, and still no one has an end-to-end capability.
For those about to make vendor selections, our report ‘Selecting the right systems vendors for IFRS 17’ in June 2019 set out five critical vendor capabilities which remain relevant today.
Does one size fit all
Functional development across the market is about six months behind where we had expected. At this time, we’d anticipated the “market leaders” to be close to offering an end to end solution however based on the June/July releases most vendors are continuing to work on fundamental capabilities.
Consistent with vendor 3.0, the Accounting led vendors typically have good sub-ledger and accounting rules capabilities but are lagging behind on the calculation engine and cash flow capabilities, whereas the opposite is true for the Actuarial led vendors. The Data led vendors tend to be lacking in full sub-ledger, cash flow and risk adjustment capability. Reinsurance remains a work on for all however with the standard still moving this is somewhat difficult to finalise.
Due to this, a number of clients have started to look at multi-vendor solutions and vendors review their alliances. An emerging question is can we expect one vendor to meet the all the complex requirements of IFRS 17 at an enterprise grade scale?
Deep dive: general insurance data
While the IFRS 17 data challenge is well acknowledged across the industry, most participants and certainly many vendors had focused their attention on the life insurers. We have found that the granularity and fluidity of data required for general insurers surpasses existing requirements and some vendors data models are not yet developed for this large segment of the market.
Below are some data challenges facing general insurers to “explore” with software vendors.
A number of insurers taking advantage of the Premium Allocation Approach ("PAA") simplification, have found the sourcing of 'premium received' records as well as the data required to undertake PAA eligibility testing difficult;
- Likewise, existing data models can lack the robustness to bring together all the data required for a "facts and circumstances" process to identify potentially onerous contracts and then calculate the loss component as required for onerous groups;
- Data required to produce and validate the IFRS17 risk adjustment is likely to be new for many in the general insurance market and this will come with its own set of data needs, another example of this will be in the derivation of discount rates
- Some actuarial vendors, those with a life heritage, assume some data required is held within existing reserving tools (i.e. cashflows) but this is not the case for the majority of general insurers and therefore may need to be derived outside of the vendor data model; and
- Other data modelling challenges arise from the use of binders / third parties, the treatment of outwards reinsurance cover and the identification of all directly attributable fulfilment cashflows.
Deep dive: sub-ledger vs accounting rules engine
Many times, we hear reference to an IFRS 17 sub-ledger or an IFRS 17 accounting rules engine. The terms are often used interchangeability, but there are some important differences that we feel are important to understand.
A basic accounting rules engine will define accounting rules that are applied to business events (or pre-accounted events from a legacy system), transforming that business event into an accounting event. The accounting rules system may perform automated adjustments and be able to account in multiple accounting (GAAP) representations of a single business event. A flexible accounting rules capability will allow the user to define a custom source, event models & accounting rules and be able to store source to target mapping values. In addition, a sophisticated accounting rules engine will also be able to store the detailed business events, accounting events, journals, provide an audit trail and some level of drill down/up capability from transaction to the general ledger posting, with limited support from the legacy systems.
A good sub-ledger should provide all of the above capabilities. The total of the transactions in the sub-ledger should roll up into the general ledger across multiple accounting (GAAP) representations. A subledger allows you to apply different accounting (GAAP) representations to a single transaction either as a full-full or as a lead-delta posting. It is designed to bring together many accounting approaches into a single application, helps enforce the corporate wide accounting standard and reduce complex reconciliation mechanisms which are otherwise difficult to maintain.
In addition, a more sophisticated sub-ledger will able to interface with multiple legacy source systems and general ledgers, it will support automated & manual adjustments and be able to automatically generate reversals for accrual entries. In addition to multi-GAAP, it will perform multi-period accounting, have an inbuilt reporting and reconciliation mechanism across GAAPs and periods and be able to store balances at subledger level. Most sub-ledger vendors have developed user-friendly interfaces for accountants and have a reliable, transparent and predefined set of validations.
As a result of our clarifying the criteria around accounting rules engines vs sub-ledgers some scores have been reassessed due to not fulfilling all of the sub-ledger requirements listed.
Next steps
We expect the timing of version 3.1 will be welcomed by many stakeholders in the insurance (and reinsurance) industry. We know that several of our clients are reviewing earlier vendor decisions and many clients are now fully mobilizing vendor selection processes. The timing is also important for vendors, most have extended and matured their offerings, and our latest analysis includes our insights and experiences with the latest software releases up to and including June/July-2019.
We encourage all our clients to reach out to your local PwC contacts to find out more about vendor 3.1.
