Validating Your IFRS 17 Program - PwC

www.pwc.com/insuranceValidatingyour IFRS 17programOctober 2018www.pwc.com/insurance

2 PwC Validating your IFRS 17 programIntroductionIFRS 17 represents the mostsignificant change in accountingstandards in over 20 years. Itintroduces new liabilitymeasurement models with robustrisk and discount calculations.Significant parts of the modelrequire ongoing updating andrevision to reflect emergingexperience and changing economiccircumstances. The standard’soperational impact is particularlysignificant. Insurers have tocompile, organize, and assessadditional policy data,project more granular cashflows, and develop new disclosuresand presentations that arecompletely unlike the onesthey’ve used previously.Considering these dauntingchanges, we expect that seniormanagement and board memberswill demand that the company’sIFRS 17 program undergo rigoroustesting and validation. Fortunately,over the last several years, therehave been significant enhancementsin model risk management thatinsurers can use to address thisdemand. Supported by regulatoryguidance and their own experienceand practical learnings, insurershave established comprehensivemodel validation procedures andcapabilities. Applying them in anorganized and effective combinationwith development testing and auditcan significantly enhance the qualityof IFRS 17 published results.

3 PwC Validating your IFRS 17 programUnderstanding the differencesand commonalities betweendevelopment testing,validation and auditEstablishing clarity regarding thedifferent activities and roles ofdevelopment testing, validation andaudit will be helpful inunderstanding how they can best becoordinated. The chart belowprovides a comparison of the threedifferent review activities in anumber of areas. Some keydifferences are as follows:Development testingDevelopment testing is a commoncomponent of effective programdevelopment. The most widelyrecognized element of this testing isthe use of alternative, checkercalculation routines to test theaccuracy of the calculations for thenew program initiative. Generallythis type of testing occurs whetheror not the new program initiative isimplementing third-party providedsoftware or software the insurer hasdeveloped and coded. The checkercalculations likewise can be thirdparty or in-house. If third-party,then the tester typically chooses atool that enables him toindependently and openly confirmthe calculations’ accuracy.While the main focus is on testingthe calculation routines, sometimesthe work also revisits the conceptualsoundness of the model. In otherwords, is the calculation actuallyaddressing the model’s objective ina sound and proper manner?

4 PwC Validating your IFRS 17 programBecause development testing is conducted inthe midst of development activity, which includesongoing updates and enhancements, the accuracyof model documentation needs carefulconsideration. Model documentation often is notcompleted until all updates and enhancements tothe calculations are complete and there needs tobe careful alignment of model development andaccounting development in order to avoid twodifferent IFRS 17 implementation “islands.” Oncethe documentation is completed, it will benecessary to reconnect the test with the correctmodel version and ensure that 1) changes to thatversion also have been tested, and that 2) thedocumentation of the model provides a clear andaccurate record of the final version.ValidationValidation is more comprehensive thandevelopment testing. It covers all aspectsof a model program from input throughcalculations, to output presentation, and thenusage. Validation identifies any upstream modelsthat supply input; overall model riskmanagement (MRM) program should validatethose models, too.Validations typically follow a prescribed standardtestplan. This promotes comparability acrossmodels. Furthermore, from the perspective ofaiding error detection, starting with acomprehensive list of tasks rather than the modelas presented enables discovery of not only errorsin what is present but also helps uncover whatmight be missing.Insurers need to articulate in their accountingpolicy how they interpret and translate IFRS 17principles and guidelines in the context of theirbusiness circumstances.Conceptual soundness is a key consideration invalidation. This is particularly important for IFRS17. IFRS 17 presents many of its most challengingaspects as principles and guidelines rather thanprescribed rules. Insurers need to articulate intheir accounting policy how they interpret andtranslate these principles and guidelines in thecontext of their business circumstances. Thevalidation’s conceptual soundness review coversthis. Needless to say, an error in interpretationwill lead to an error in the outcome, regardless ofwhether the development test showed thecalculator was accurate or not.Lastly, we note that validation is very focused onboth documentation of the model, which isrequired to conduct an effective validation, andthe validator’s documentation of the validationprocess and its outcome. This also can serve asinput documentation to the audit review.Accurate documentation of the model isespecially important for IFRS 17 becausedocumentation of the results are required fordisclosure purposes. Furthermore, many of theunderlying assumptions and inputs will requireongoing updates to reflect current experience andeconomics. A clear record of the process thatgenerates these assumptions will improve theefficiency and accuracy of subsequent updates.Documentation of the validation also can aidmodel accuracy, especially interimdocumentation provided during the validationprocess, because it can form a punch list ofneeded enhancements (as we discuss below).

5 PwC Validating your IFRS 17 programAuditAuditing financial statements is perhaps the most widely recognized of the three review activities. Its focus is on suitability of output and consistency withgenerally accepted accounting principles. However, an audit, like validation, also has broad coverage and a comprehensive mandate, including reviewingconceptual soundness,The high degree of independence demanded of the external auditor disconnects the audit team from the development team. This constrains its use as aneffective source of development feedback. Furthermore, the audit typically occurs too late in the process to make enhancements while development is inprogress. As we noted before, IFRS 17 requires a significant degree of interpretation and translation of principles and guidelines. A misalignment ofinterpretation between the developer and auditor late in the process can lead to significant time and resource pressures to make the necessary designchanges.

6 PwC Validating your IFRS 17 programDevelopment testingValidationAuditTypical timing foractivityStarted once development has commencedConducted throughout development processParts can be conducted when development is in progressOften finalized after development is complete and beforeprogram is implementedConducted during year leading up to published financial results,potential quarterly obligationsDry run results (year ending 2020) also need to be auditedDeadline forcompletionFit within overall development timetableand targetSelf-imposed by insurerPrior to public release of audited financial informationStandards governing Often ad hoc, at discretion of developerEmerging industry guidelines defined by common practiceactivitySometimes guidelines at company level orSome professional guidance, e.g. actuarial professionalrecommended by third party program providers bodiesSome general regulatory guidance, e.g. SR 11-7Some program specific regulatory guidance, e.g. for SIIinternal model validationWell defined by professional accounting organizationsPrincipal areas ofreview emphasisCalculation accuracy is primary focus,conceptual soundness and input sometimesalso consideredComprehensive, covering input, conceptual soundness,calculations, output and upstream and downstreamconnectivityBroad mandate but primary focus on suitability of output, otherprogram aspects considered in context of impact on outputRole ofdocumentationMethodology and calculation expectationstypically determined through discussion withdeveloper (rather than via review ofcomprehensive documentation)Documentation is typically not fully developedbefore testing commencesTarget is to have comprehensive documentation in place inorder to conduct and support validationAdequacy of documentation is assessed and reported on aspart of validationIFRS 17 has specific disclosure requirements that need to beaddressed in the documentationBetter documentation makes for a more efficient audit, but audit needsto proceed regardless of whether documentation is robust or notIFRS 17 has specific disclosure requirements that need to be addressedin the documentationReview goalAffirming that calculation programingis accurateMinimizing risk of program errorConfirming output is consistent with accepted accounting practiceDocumentation offindingsTypically informal and ad hocA key deliverable of validation engagementTypically follows a predefined format designed to ensurevalidation is a comprehensive assessmentInformation provided to management and board in format best suitedto circumstances and findingsProfessional rules governing work papers supporting audit opinionOutcome/formalopinionTypically conducted as part of ongoing programdevelopment effort, progress reported alongwith other program development activitiesFormal report, either during development or atconclusion is not typicalValidation report typically identifies shortcomings needingcorrection and timeframe for resolutionInterim findings can be presented to developer andcorrections reviewed by validatorExternal validator could present a formal opinion ofvalidationFormal "pass" opinion issued by auditorFeedback loopOngoing and ad hoc, part of development cycle Comprehensive "punch list" of improvementsrecommended can be issued as validation is in progressFocus is on pass/fail; independence precludes detailed instructions onhow to fix shortcomingsFunctional arearesponsibleProgram developerModel risk management, part of risk function headed byCROExternal auditorStaffing for activityPart of program development staffMRM staff or independent internal or external personnelsupervised by MRMExternal auditorRisk committee of the boardAudit committee of the boardBoard level oversight Indirectly as part of program developmentoversight