Given that the effective date of 2023 is now live, newer challenges relating to transition realities are arising significantly across the industry as resource mindsets shift from a project environment to a business-as-usual (BAU) operating environment. The need to balance compliance requirements with operational readiness has become more evident in these latter stages of implementation, highlighting the need for organizations to think beyond the IFRS 17 project as they transition to BAU.
This blog post will explore some of the realities of implementation. It will highlight key themes around challenges, lessons learned, and operational shifts which impact all players across functional teams in the insurance industry.
Balancing IFRS 17 Solution and Operational Requirements
The complexities surrounding the standard implementation were a much-discussed topic during the planning and strategy stages. These discussions focused on achieving data granularity while adopting new technology and process requirements within cost and time constraints. The complexities of the hands-on implementation realities of a vastly impactful program in a legacy operating environment were more strenuous than anticipated for many, as entities faced significant new data requirements across a developing technology solution landscape. Simply put, insurance entities across the globe were faced with implementing a new normal that required new enterprise-wide technologies, redefined processes, and revamped operational environments.
As initially anticipated across the industry, new technologies played a crucial role in complying with the standard.
Throughout 2022, organizations kicked off multiple stages of testing. Through these tests, what has become a high-priority challenge is the lack of fit between existing operational processes, redefined business process requirements, and the technology solution.
Program stakeholders began to face significant requirement gaps in balancing compliance requirements within the BAU operating environment while considering the system capabilities of the technology solutions. These requirement gaps have led them to question what went wrong in the initial implementation strategy.
Ideally, implementation efforts would have kicked off with a detailed gap analysis to assess the viability of these new technology solutions for compliance and organizational fit. The reality was that most insurers had very limited timelines to implement the standard, and so out-of-the-box (“OOTB”) solutions were chosen as an all-encompassing path to meeting compliance while bridging the gap of operational fit. But during testing stages, these companies realized that they needed to customize the so-called OOTB technology to capture the nuances in their specific business requirements. As a result, insurers had to spend more time and money working with subject matter experts (SME) to close the gap between compliance, operational requirements and technology capabilities.
Delays in End-to-End (“E2E”) Test Run Executions
Ideally, testing system functionality with end users will create an opportunity to evaluate assumptions and hypotheses of the business requirements, especially with OOTB solutions. The key purpose of testing system functionality is for insurance entities to validate that the proposed technology solutions are accurate and reflect expected results of business requirements beyond the standard.
The testing of business requirements when implementing new technology can be accomplished through various tests such as parallel runs, dry runs, and transition runs. From experience, there is no such thing as a linear execution exercise regarding test runs. For organizations testing under conditions where multiple factors are new (e.g., new technologies in the ecosystem and redefined processes), such situations are prone to result in program delivery delays. The following table introduces development tests that are included in implementation delivery:
Through the multi-year implementation delivery, insurance companies have progressed through multiple stages of at least one of the above tests. With the effective date of January 2023 no longer ahead of us, entities are focused on closing out efforts on E2E testing for simulation in a production environment. Hence, the following section will highlight challenges in these last stages of implementation. Components of the test run execution for newly adopted technologies will involve these various types of testing as entities evolve through the stages of implementation.
Challenges in the E2E testing phase range across entities, but the underlying issues often can have thematic commonalities, as complicated enterprise-wide projects are not a new phenomenon. What is new are the different circumstances around projects which create high-priority challenges that lead to significant delays in delivery timelines.
In our experience over the past year of IFRS 17 program implementation, some of the common challenges faced with the E2E test framework (planning and execution) include a lack of resource commitment, limited knowledge of the standard and technology, data readiness and pressures around implementation timelines. Let’s look at these more closely:
-
- Lack of Resource Commitment and Alignment—Limited Communication and Collaboration Across Teams
The IFRS 17 program requires significant commitments from multiple areas of the insurance industry, e.g., accountants, actuaries, project management, technology data teams, etc. Each team plays different roles within the project to deliver goals within their units and across teams to meet a common delivery objective. Unfortunately, this is not necessarily the reality of things. More often larger organizations have these teams work in silos with limited communication and collaboration across other groups. This lack of alignment leads to slowness in delivering the E2E testing initiatives. - Limited Knowledge of the Standard and Technology
Accounting standards are a complicated read, and IFRS 17 is no exception. It requires an understanding of the purpose of the standard, along with the complex nuances across business circumstances that are necessary for compliance. As the IFRS 17 program evolved across the globe, so did the subject matter expertise on the critical topics of the standard. Unfortunately, this growth was not at a rate to meet the demand for such resources. Due to the unmatched demand and supply of resources within the industry, it has become increasingly difficult to locate resources that are conversant in the language of IFRS 17. As additional end users from the finance and business teams were exposed to the program during E2E testing, these gaps became more apparent. The resulting impact on meeting testing objectives was E2E strategies that utilized resources with limited knowledge of the standard and technology.
IFRS 17 processes and results will become the new normal for business and financial reporting users by the 2023 year-end. In preparation, opening balances under IFRS 17 will need to be generated and validated by stakeholders and senior management to ensure compliance and the reasonability of the solution. Therefore, a critical understanding of the differences between IFRS 17 vs. IFRS 4 results is a vital knowledge requirement within organizations to ensure the accuracy and completeness of financial outputs. - Data Readiness, Accuracy, and Completeness—Defect Management and Resolution
The testing strategy relies heavily on the quality, availability, and completeness of the entities’ data to develop a reliable solution compliant with the standard. Preexisting poor data quality, lack of tools to generate data at the required granularity, data sourcing from multiple source systems, etc., can become deterrents in the execution of otherwise well-planned E2E test strategies.
During unit testing and integration testing, end users typically mock up smaller data sets to replicate a real portfolio to achieve critical short-term goals. Upon the downstream E2E testing, entities will need to test with real datasets as the focus is on preparation for parallel and transition runs. The disparity in test data strategy at the different testing stages creates critical data defects in the latter stages of implementation. The eventual introduction of more extensive representative data across the integrated solution makes it more difficult for entities to meet delivery timelines as they are often faced with resolving additional defects and unexpected data issues, which subsequently impacts the quality of deliverables. - Pressures Around Implementation Timelines—Strategic Planning vs. Execution
A recurring message in assessing the challenges in E2E testing listed above is the pressure of limited timelines in the IFRS 17 program delivery. The reality of any project is that implementation strategies only capture a limited range of known and unknown variables. It is during the execution stage of an implementation that unpredicted loopholes and unforeseen challenges become apparent. These latter-identified challenges and unknown factors often increase the pressure to deliver within even tighter timelines.
- Lack of Resource Commitment and Alignment—Limited Communication and Collaboration Across Teams
As teams address existing requirements through E2E testing, the challenges mentioned above create additional unforeseen delivery requirements and tasks that must be addressed for go-live in 2023. Implementation teams are negatively affected by these challenges as increasing pressure is on meeting preexisting delivery goals within even tighter deadlines. A static delivery deadline and an unending list of requirements result in short-term decisions taken that are detrimental to the quality of the product delivery.
Conclusion
In summary, entities will face one or more of the above challenges as they strive to close out IFRS 17 implementation efforts in 2023. The lack of resource alignment, limited knowledge transfer, data issues, and defect resolution challenges, among others, have a causative relationship in explaining why entities face timeline pressures with implementation delivery, especially during the user acceptance testing and transition phases. Delays in these phases impact the preparation for transitioning to a production environment and could also reduce end-user confidence in the solution.
Organizations should think forward on how to resolve these foreseeable common issues. Most important is the prioritization of minimum compliance requirements, project management efficiencies, and unwavering leadership support in the following months. Entities will need to prioritize tasks required to meet compliance for their respective 2023 financial year. The IFRS 17 compliance date is unchanging; where the opportunity lies will be appropriately utilizing resources to complete and accurately deliver Day 0[1] and Day 1[2] financial requirements. Several iterative end-to-end dry runs will be an integral part of the transition strategy to ensure a strong position in generating reliable opening balances.
Just as integral is a well-designed and executed target operating model framework, as it combines all the compliance, technology, and operational elements for the new operating environment. Prioritization should focus on resolving critical existing challenges and leveraging SMEs and key program resources while monitoring and regularly assessing for future operational challenges that may arise upon transitioning to a BAU environment. Additionally, it is critical to utilize a robust defect management system that covers the entirety of the E2E solution in a simulated production environment.
Realistically, what is essential is resolving those prioritized tasks for minimum compliance and operational efficiencies in the 2023 financial year. With achieving Day 0 and Day 1 compliance efforts, further consequences and considerations of introducing new technologies and processes into preexisting insurance ecosystems will become apparent. In Day 2, further operational refinements will be needed to maximize the benefits of new technologies across insurance organizations in post-IFRS 17 implementations.
[1] Day 0 is the project stage where requirements are defined, and the solution is enhanced for compliance in the business operating environment
[2] Day 1 is the deployment of the solution from project and testing stage to the production stage in the BAU environment.
Tolani Makanjuola is an analyst at FRG with 6+ years of experience providing strategic support & analysis to establish business technological efficiencies for operational, regulatory accounting, and reporting processes. Tolani has spent the last four years working with diverse financial institutions to implement IFRS17 technology solutions.