Long Term Protection Model in R. Dr. Urszula Gasser, Senior Pricing Actuary

Transcription

1 Long Term Protection Model in R Dr. Urszula Gasser, Senior Pricing Actuary

2 2 Disclaimer The following presentation is for general information, education and discussion purposes only. Views or opinions expressed, whether oral or in writing do not necessarily reflect those of PartnerRe nor do they constitute legal or professional advice.

3 The need 3

4 4 Life insurance Gives protection against loss resulting from death (or serious illness) of an insured

5 5 Life insurance Gives protection against loss resulting from death (or serious illness) of an insured

6 6 Life reinsurer needs to model underlying risk need for specialized tools

7 The model 7

8 8 What about Mr Bloggs? healthy

9 9 What about Mr Bloggs? healthy dead

10 10 What about Mr Bloggs? healthy lapsed dead

11 11 What about Mr Bloggs? healthy early cancer lapsed dead

12 12 What about Mr Bloggs? healthy early cancer lapsed dead

13 13 What about Mr Bloggs? healthy early cancer severe cancer lapsed dead

14 14 What about Mr Bloggs? healthy early cancer severe cancer lapsed dead

15 15 What about Mr Bloggs? healthy early cancer severe cancer early and severe cancer lapsed dead

16 16 What about Mr Bloggs? healthy early cancer severe cancer early and severe cancer lapsed dead

17 17 What about Mr Bloggs? l h x(d) healthy q x i 1 x i 2 x early cancer i 1 x* i 2 x severe cancer i lb1->lb2 x(d) i lb2->lb1 x(d) l lb1 x(d) l lb1+lb2 x(d) early and severe cancer l lb2 x(d) q lb1+lb2->dead x(d) q lb2->dead x(d) lapsed q lb1->dead x(d) dead q x,i x,l x mortality rate, incidence rate, lapse rate d duration (months) in given state

18 And what about Mrs Bloggs? 18

19 19 To model Mr & Mrs Bloggs policy we decided to build our own, Long Term Protection Model for pricing

20 The tool 20

21 21 LTPM pricing tool needs to be User friendly Easy to access Simple to set-up Fast to calculate Straightforward to interpret Flexible Stable Secure Auditable

22 22 We decided to do it in R as opposed to most tools used in the re/insurance industry, because these come often with: Legacy issues (too heavy) Calculation constraints (some things are not possible) Access issues (desktop versions, use of workers, external clouds) Transparency issues (black-box) Maintenance issues (costly upgrade, adaptation)

23 23 Why R? Becoming the standard analytics tool at university level and in many industries Free Open source Meets our needs Fast Flexible Reduces the number of platforms we maintain

24 24 R is an excellent fit but we also need an infrastructure to support all the tool requirements

25 The workflow 25

26 26 First, let s look at the steps in the calculation Input data

27 27 Steps in the calculation Shiny web interface Input data

28 28 Steps in the calculation Dedicated server Shiny web interface Input data

29 29 Steps in the calculation Dedicated server Shiny web interface Code repository with version control and issue tracker Input data

30 30 Steps in the calculation Dedicated server Shiny web interface Code repository with version control and issue tracker Input data

31 31 Steps in the calculation Dedicated server Shiny web interface Code repository with version control and issue tracker Input data

32 32 Steps in the calculation Dedicated server Shiny web interface Code repository with version control and issue tracker Input data

33 33 Steps in the calculation Dedicated server Shiny web interface Code repository with version control and issue tracker Output data Input data

34 The interface 34

35 35

36 web interface 36

37 37 web interface collaboration

38 38 web interface collaboration choice of model version

39 39 web interface collaboration choice of model version intuitive names

40 40 web interface collaboration choice of model version intuitive names upload of the input data

41 41

42 42

43 43

44 44

45 45

46 46

47 47

48 48

49 49 Content of a run Input Output Model code + Gitlab reference Run log file Run ZIP

50 The anatomy 50

51 51 GitLab repository LTPM Shiny apps LTPMcreate LTPMrun R packages as git submodules LTPMcalc LTPMlogging LTPMinput GitLab project

52 52 Shiny applications There are two Shiny applications in the LTPM: 1. LTPMcreate: the main application where pricing exercises can be defined and runs can be created. 2. LTPMrun: an interface to each individual run which displays run details (e.g. input files and settings), status messages, and provides access to results.

53 53 GitLab repository LTPM Shiny apps LTPMcreate LTPMrun R packages as git submodules LTPMcalc LTPMlogging LTPMinput GitLab project

54 54 GitLab repository LTPM Shiny apps LTPMcreate LTPMrun R packages as git submodules LTPMcalc LTPMlogging LTPMinput

55 55 R packages To support the calculations we have created three R extension packages: 1. LTPMcalc: includes all functionality for the actual calculations for the multi-state model. 2. LTPMinput: functionality to convert user input (i.e. spreadsheets) to an intermediate format (i.e. CSV). 3. LTPMlogging: functionality to allow all scripts and applications to log time-stamped information to the console or to a file on disk.

56 56 GitLab repository LTPM Shiny apps LTPMcreate LTPMrun R packages as git submodules LTPMcalc LTPMlogging LTPMinput

57 57 GitLab repository LTPM Shiny apps LTPMcreate LTPMrun R packages as git submodules LTPMcalc LTPMlogging LTPMinput GitLab group GitLab project

58 Packages as git submodules GitLab view 58

59 59 Anatomy of LTPMrun execute.r install.r LTPMlogging Shiny application input.r LTPMinput calc.r LTPMcalc

60 60 Executable R scripts The LTPMrun application has one R script to execute a full calculation run called execute.r. This script defines three execution steps, each implemented in a separate R script: 1. install.r: installation of R extension packages required by the run, 2. input.r: reading and conversion of input file(s) provided by the user, 3. calc.r: perform the calculations.

61 61 LTPMcalc The R package which implements the actual model functionality including the multi-state model. The multi-state model is a Markov chain, which is a discrete-time Markov process. Implementation details can be found in the package vignette.

62 Flexibility and adaptability 62

63 63 Choice of actuarial model version User can choose between: - the latest released version - past released versions - customized version created by themselves - customized version created by other user Master branch V1.0 V2.0 V3.0 V4.0 V5.0 Branch 1 Branch 2 Tags

64 64 Choice of actuarial model version list of git tags list of git branches

65 Quality assurance 65

66 66 How do we ensure that the model is correct? We can never guarantee that the model is completely free of errors and bugs. To minimize errors, we apply standard practices for quality assurance in software development: 1. Many small unit tests for individual functions. 2. Integration (i.e. end-to-end) tests using precalculated results. 3. User testing.

67 67 GitLab Source code version control using Git. Issue tracker to track bugs and our progress in fixing these. Continuous Integration (CI) pipelines to automatically test on the target system all changes committed to the source code repository. - performed in target environment - immediate upon push - notifications can be send to Slack

68 GitLab - Continuous Integration 68

69 Questions? 69