All I want for Christmas is accurate, complete and appropriate data

Transcription

1 Life conference and exhibition 2010 Jethro Green & Gordon Jennings All I want for Christmas is accurate, complete and appropriate data 7-9 November 2010 All I want for Christmas is accurate, complete and appropriate data - Jethro Green, FSA - Gordon Jennings, AVIVA The views expressed in this presentation are those of the presenters. 1 1

2 Agenda Policyholder data in the life industry Data requirements in Solvency II / TAS-D Aviva s Heritage project Case study: loyalty bonus Case study: unit linked whole of life Case study: non profit deferred annuities Lessons learnt Q&A 2 What is data? Facts or information usually collected from records, experience or observation TAS D, Board for Actuarial Standards all the information which is directly or indirectly needed in order to carry out a valuation of technical provisions Final Advice on Technical Provisions, Standard for Data Quality, y (former Consultation Paper 43), CEIOPS 2

3 TAS-D overview Standard for data used in preparing actuarial information Application: reports from 1 July most UK life actuarial work Assess, define and validate data Accurate Relevant Complete Incomplete / inaccurate data improved or supplemented? Document each stage above 4 Solvency II overview of data requirements Level 1: the Solvency II directive Member States shall ensure that insurance and reinsurance undertakings have internal processes and procedures in place to ensure the appropriateness, completeness and accuracy of the data used in the calculation of their technical provisions. Level 2: final advice from CEIOPS on: Technical Provisions Standard for data quality (former CP 43) Tests and Standards for Internal Models (former CP 56) 5 3

4 Accuracy, Appropriateness and Completeness of Data Technical Provisions (former CP43) Accurate Complete Appropriate Free from material mistakes, errors and omissions Recording is adequate, timely and consistent High level of confidence Credibility shown through use in decision-making Allows recognition of main homogeneous risks groups Enough granularity to identify trends and give full understanding of underlying risks Sufficient historical information available Suitable for purpose Relevant to portfolio of risks Data quality issues Sources of material mistakes, errors and omissions Human error IT failures Operational risk systems and processes System architecture weaknesses Several different systems in use Interface not fully automated Outdated systems Sales channel / outsourcing former CP43, CEIOPS 4

5 Challenges for the UK life firm Current situation Issues to consider Data processes Past errors Business logic not transparent Data cleaning Design of processes Systems Multiple systems Multiple locations Legacy systems Controls and validation Governance and documentation Poorly defined processes Data policy Data definitions (directory) Aviva: a brief history GA GA PM CU CGU CGNU Aviva NU 5

6 Aviva s Heritage project Migration project 20 significant administration systems 2.8 million policies Pensions Life Conventional Unit-linked Product lines closed to new business. 10 Aviva s Heritage project Outsourced: Admin Re (part of Swiss Re) Policy day-to-day administration (Alpha) Parallel reinsurance treaty Retained: Valuation and Accounting Ownership of book and customers Regulatory risks => Ongoing partnership 11 6

7 Case study 1: loyalty bonus Context Product feature to encourage continuity of premiums Popular in 1990s Competition between CU, GA and NU each sold its own variation: Added at claim or anniversary Some extremely complex, impractical to administer and, functionality not built at product launch 12 Case study 1: loyalty bonus Legacy System Identified as too complex to administer on the legacy system Manual methods used as alternative Hence not sustainable as volumes grew Low volumes until 2008 (many 10-year anniversaries) Volumes in force circa 175k (potentially due loyalty bonus during policy life cycle) 13 7

8 Case study 1: loyalty bonus Implications of the policy terms and conditions Claims stage: at claim, loyalty bonus is added based on no. of years premium slice has been paid for. Anniversary stage: on each qualifying policy anniversary, loyalty bonus is added if the premium has been paid for more than 10 years, or the units purchased are more than 10 years old. Data on the legacy system was not held in a format that allows us to calculate the loyalty bonus on the above terms. Data transformation required with some complexities rationalised: tough decisions made. 14 Case Study 1: loyalty bonus Slice 2: Subsequent incremental premium slice Slice 1: Premium slice at inception Total no of units = 1,000 no robust split on legacy system i.e. all in one pot, split 650 slice 1 & 350 slice 2 post migration on Alpha 15 8

9 Case study 1: loyalty bonus The outcome Data held in a robust form for both claims calculations and financial reporting. Automated application of loyalty bonus. Policyholder valuations up-to-date and accurate. Policies administered at least in line with terms and conditions i.e. no customer detriment. t 16 Case study 2: unit-linked whole of life Context Unit-linked whole of life assurance Contracts sold in 1990s by all four legacy companies Premium reviewable at 10 years, then every 5 years, then every 1 year at age 70 and beyond. No underwriting at review option to increase premium or reduce cover Easy to sell as seen as cheap life cover (initially!) More akin to renewable term assurance, premiums increase with age at review About 60k in force policies 17 9

10 Case study 2: unit-linked whole of life Monthly premium Policy year since inception 18 Case study 2: unit-linked whole of life Aviva s issue Insufficient functionality on legacy systems i.e. no trigger to perform the reviews automatically. Historic this meant some reviews were missed by the manual process. For reviews that did happen, no direct record

11 Case study 2: unit-linked whole of life Fixing the problem Catch-up exercise prior to migration Putting policyholders back in the position they would have been in, assuming the reviews had been carried out i.e. paying the missed premiums. Managing policyholder expectations a bigger jump at the next review. 20 Case study 2: unit-linked whole of life Outcome All policies up-to-date at point of migration Reviews triggered automatically Next review date is held as a data item makes valuation more robust 21 11

12 Case study 3: non-profit deferred annuities Context Bought-out occupational schemes Three legacy books with separate administration Some held on system, some manual records ( job cards ) with separate valuation database No direct link between the valuation and administration 13k policies directly impacted (in excess of 500m reserve) 22 Case study 3: non-profit deferred annuities The migration Significant data preparation and cleanse exercise Reconciliation between the valuation database and the physical records. Ensuring data on the new platform was robust for both administration and valuation Specifying ing requirements Keying the data Validation / Controls on data entry 23 12

13 Case study 3: non-profit deferred annuities Outcome Administration records now on system Automated and consistent calculations Release of reserves One integrated data source for valuation and administration automatic reconciliation 24 Data quality issues reviewable products deferred products product design multiple systems human error legacy systems outsourcing Heritage risk themes CEIOPS risk factors 13

14 The overriding theme Discipline design ongoing review product cycle implementation administration 26 Assessing your own risk Complexity of group / impact of acquisitions Complexity of product types / product concentration Legacy systems Controls around outsourcing Adequacy of audit Poorly designed processes Interface with valuation systems 27 14

15 Migrating data is like moving house and not just because it s one of the most stressful things you can do. Questions or comments? Expressions of individual views by members of The Actuarial Profession and its staff are encouraged. The views expressed in this presentation are those of the presenters

16 Data quality processes Former CP 43 (Technical Provisions) Data quality management Defining the data Assessment of the quality Resolution of the material problems identified Monitoring data quality Procedures on collection, storing and processing of data Former CP 56 (Internal Models) Data quality process Concept of data quality Validation Use of expert judgement Data updates (frequency and triggers) Data deficiency TAS D Former CP43 (Technical Provisions) Assessment of cause No but must state how it can be improved. Yes and also assess how to improve data quality. Modifying data /usingmargins Yes Yes Fixing the cause No Yes (if related to insufficient internal processes) 16

17 Appendix A: Loyalty bonus premium slice Average premium equals actual premium where there is no premium change during the year Average premium does not equal actual premium where there is a premium change during the year Premium Payment History CUPAS Slices Slice 1 40pm for 48 months Slice 2 60pm for 37 months Slice 3 60pm for 19 months 100pm for months pm for months pm for months pm for months pm for months pm for months Alpha Slices Slice 1 70pm for 48 months Slice 2 30pm for 36 months Slice 3 10pm for 24 months Slice 4 50pm for 12 months 32 Appendix B: Loyalty bonus premium slice Anniversary stage loyalty bonus should be paid out on units in: A as more than ten payments have been made B as although less ten payments have been made units have been held for more than ten years. On Alpha units in A, B and C will all receive loyalty bonus as they are all over ten years in duration. D does not receive loyalty bonus in this example. 17