SPLICE: Synthetic Paid Loss and Incurred Cost Experience (SPLICE) Simulator

Description

An extension to the individual claim simulator called 'SynthETIC' (on CRAN), to simulate the evolution of case estimates of incurred losses through the lifetime of an insurance claim. The transactional simulation output now comprises key dates, and both claim payments and revisions of estimated incurred losses. An initial set of test parameters, designed to mirror the experience of a real insurance portfolio, were set up and applied by default to generate a realistic test data set of incurred histories (see vignette). However, the distributional assumptions used to generate this data set can be easily modified by users to match their experiences. Reference: Avanzi B, Taylor G, Wang M (2021) "SPLICE: A Synthetic Paid Loss and Incurred Cost Experience Simulator" arXiv:2109.04058.

Author(s)

Maintainer: Melantha Wang wang.melantha@gmail.com

Authors:

• Benjamin Avanzi b.avanzi@unimelb.edu.au

• Greg Taylor greg_taylor60@hotmail.com

• William Ho ho.w@unimelb.edu.au

See Also

Useful links:

• https://github.com/agi-lab/SPLICE

• Report bugs at https://github.com/agi-lab/SPLICE/issues

Development of Case Estimates

Description

Consolidates payments and incurred revisions and returns a full transactional history of all the individual claims (transaction being either a payment or a case estimate revision).

Usage

claim_history(
  claims,
  majRev_list,
  minRev_list,
  k1 = 0.95,
  k2 = 0.95,
  base_inflation_vector = NULL,
  keep_all = FALSE
)

Arguments

Details

This function works to generate the full history of claims paid and incurred estimates by consolidating all the simulated revision quantities. It should be noted that in this consolidation step, we make the following adjustments:

• Major and minor revisions should not occur simultaneously. In the event that they do (which is only possible at the second last partial payment), the major revision takes precedence, and the minor revision be discarded. This will be reflected in the majRev and minRev components of the output list.

• Estimates of incurred loss are specified to be computed in reverse order, and it is necessary that the total incurred estimate is always strictly greater than the cumulative claims paid (except at the final paymen where equality holds). Hence we introduce k1 and k2 to make sure that the revised incurred estimates satisfy

  ky(t) \ge c(t)

  where y(t) represents the total incurred estimate at delay t, k is a constant between 0 and 1, and c(t) is the cumulative claims paid up to time t. When the raw simulated revision multipliers violate this requirement, the case estimates of the total incurred or the outstanding claim payments will be increased to make sure this condition always holds, i.e. this adjustment takes precedence over the raw simulated revision multipliers.

• Inflation adjustment: One can choose to ignore inflation in the incurred estimates (default), or to make allowance for it.

  • If base_inflation_vector == NULL (default), then all case estimates will be computed in values corresponding to time t = 0, i.e. the commencement of the first occurrence period.

  • If base_inflation_vector is provided, then the case estimators will include full superimposed inflation and base inflation only up to the date of the revision, i.e. there is an adjustment for the time elapsed since the immediately preceding revision and no future base inflation beyond the date of valuation.

  • If inflation is involved, it should be noted that the case estimator reviews the base inflation situation only in the process of making a revision. When only a payment is made, the insurer's system automatically writes down the outstanding liability on the assumption of no change in ultimate incurred amount.

Value

A nested list structure such that the jth component of the ith sub-list provides a full transactional history of the jth claim of occurrence period i. The "unit list" (i.e. the smallest, innermost sub-list) contains the following components:

and optionally (by setting keep_all = TRUE),

Major Revisions of Incurred Loss

Description

A suite of functions that works together to simulate, in order, the (1) frequency, (2) time, and (3) size of major revisions of incurred loss, for each of the claims occurring in each of the periods.

Usage

claim_majRev_freq(
  claims,
  rfun,
  paramfun,
  frequency_vector = claims$frequency_vector,
  claim_size_list = claims$claim_size_list,
  ...
)

claim_majRev_time(
  claims,
  majRev_list,
  rfun,
  paramfun,
  claim_size_list = claims$claim_size_list,
  settlement_list = claims$settlement_list,
  payment_delay_list = claims$payment_delay_list,
  ...
)

claim_majRev_size(majRev_list, rfun, paramfun, ...)

Arguments

Value

A nested list structure such that the jth component of the ith sub-list is a list of information on major revisions of the jth claim of occurrence period i. The "unit list" (i.e. the smallest, innermost sub-list) contains the following components:

Details - claim_majRev_freq (Frequency)

Let K represent the number of major revisions associated with a particular claim. The notification of a claim is considered as a major revision, so all claims have at least 1 major revision (K \ge 1).

The default majRev_freq_function specifies that no additional major revisions will occur for claims of size smaller than or equal to claim_size_benchmark (0.075 * ref_claim by default). For claims above this threshold,

where ref_claim is a package-wise global variable that user should define by set_parameters (if moving away from the default).

The idea is that major revisions are more likely for larger claims, and do not occur at all for the smallest claims. Note also that by default a claim may experience up to a maximum of 2 major revisions in addition to the one at claim notification. This is taken as an assumption in the default setting of claim_majRev_size(). If user decides to modify this assumption, they will need to take care of the part on the major revision size as well.

Details - claim_majRev_time (Time)

Let \tau_k represent the epoch of the kth major revision (time measured from claim notification), k = 1, ..., K. As the notification of a claim is considered a major revision itself, we have \tau_1 = 0 for all claims.

The last major revision for a claim may occur at the time of the second last partial payment (which is usually the major settlement payment) with probability

0.2 min(1, max(0, (claim_size - ref_claim) / (14 * ref_claim)))

where ref_claim is a package-wise global variable that user should define by set_parameters (if moving away from the default).

Now, if there is a major revision at the time of the second last partial payment, then \tau_k, k = 2, ..., K - 1 are sampled from a triangular distribution with parameters (see also ptri)

• min = time_to_second_last_payment / 3

• max = time_to_second_last_payment

• maximum density at mode = time_to_second_last_payment / 3.

Otherwise (i.e. no major revision at the time of the second last partial payment), \tau_k, k = 2, ..., K are sampled from a triangular distribution with parameters

• min = settlement_delay / 3

• max = settlement_delay

• maximum density at mode = settlement_delay / 3.

Note that when there is a major revision at the time of the second last partial payment, majRev_atP (one of the output list components) will be set to be 1.

Details - claim_majRev_size (Revision Multiplier)

As mentioned in the frequency section ("Details - claim_majRev_freq"), the default function for the major revision multipliers assumes that there are only up to 2 major revisions (in addition to the one at claim notification) for all claims.

By default,

• the first major revision multiplier g_1 is simply 1 (no meaning);

• the second major revision multiplier g_2 is sampled from a lognormal distribution with parameters meanlog = 1.8 and sdlog = 0.2;

• the third major revision multiplier g_3 is sampled from a lognormal distribution with parameters meanlog = 1 + 0.07(6 - g_2) and sdlog = 0.1. Note that the third major revision is likely to be smaller than the second.

The revision multipliers are subject to further constraints to ensure that the revised incurred estimate never falls below what has already been paid. This is dicussed in claim_history.

The major revision multipliers apply to the incurred loss estimates, that is, a revision multiplier of 2.54 means that at the time of the major revision the incurred loss increases by a factor of 2.54. We highlight this as in the case of minor revisions, the multipliers will instead apply to outstanding claim amounts, see claim_minRev.

See Also

claims

Examples

set.seed(1)
test_claims <- SynthETIC::test_claims_object
major <- claim_majRev_freq(test_claims)
major[[1]][[1]] # the "unit list" for the first claim

# update the timing information
major <- claim_majRev_time(test_claims, major)
# observe how this has changed
major[[1]][[1]]

# update the revision multipliers
major <- claim_majRev_size(major)
# again observe how this has changed
major[[1]][[1]]

Minor Revisions of Outstanding Claim Payments

Description

A suite of functions that works together to simulate, in order, the (1) frequency, (2) time, and (3) size of minor revisions of outstanding claim payments, for each of the claims occurring in each of the periods.

We separate the case of minor revisions that occur simultaneously with a partial payment (denoted ⁠_atP⁠), and the ones that do not coincide with a payment (denoted ⁠_notatP⁠).

Usage

claim_minRev_freq(
  claims,
  prob_atP = 0.5,
  rfun_notatP,
  paramfun_notatP,
  frequency_vector = claims$frequency_vector,
  settlement_list = claims$settlement_list,
  no_payments_list = claims$no_payments_list,
  ...
)

claim_minRev_time(
  claims,
  minRev_list,
  rfun_notatP,
  paramfun_notatP,
  settlement_list = claims$settlement_list,
  payment_delay_list = claims$payment_delay_list,
  ...
)

claim_minRev_size(
  claims,
  majRev_list,
  minRev_list,
  rfun,
  paramfun_atP,
  paramfun_notatP,
  settlement_list = claims$settlement_list,
  ...
)

Arguments

Value

A nested list structure such that the jth component of the ith sub-list is a list of information on minor revisions of the jth claim of occurrence period i. The "unit list" (i.e. the smallest, innermost sub-list) contains the following components:

Details - claim_minRev_freq (Frequency)

Minor revisions may occur simultaneously with a partial payment, or at any other time.

For the former case, we sample the occurrence of minor revisions as Bernoulli random variables with default probability parameter prob_atP = 1/2.

For the latter case, by default we sample the number of (non payment simultaneous) minor revisions from a geometric distribution with mean = min(3, setldel / 4).

One can modify the above sampling distributions by plugging in their own prob_atP parameter and rfun_notatP function, where the former dictates the probability of incurring a minor revision at the time of a payment, and the latter simulates and returns the number of minor revisions at any other points in time, with possible dependence on the settlement delay of the claim and/or other claim characteristics.

Details - claim_minRev_time (Time)

For minor revisions that occur simultaneously with a partial payment, the revision times simply coincide with the epochs of the relevant partial payments.

For minor revisions that occur at a different time, by default the revision times are sampled from a uniform distribution with parameters min = settlement_delay / 6 and max = settlement_delay.

One can modify the above sampling distribution by plugging in their own rfun_notatP and paramfun_notatP in claim_minRev_time(), which together simulate the epochs of minor revisions that do not coincide with a payment, with possible dependence on the settlement delay of the claim and/or other claim characteristics (see Examples).

Details - claim_minRev_size (Revision Multiplier)

The sampling distribution for minor revision multipliers is the same for both revisions that occur with and without a partial payment. In the default setting, we incorporate sampling dependence on the delay from notification to settlement (setldel), the delay from notification to the subject minor revisions (minRev_time), and the history of major revisions (in particular, the time of the second major revision).

Let \tau denote the delay from notification to the epoch of the minor revision, and w the settlement delay. Then

• For \tau \le w / 3, the revision multiplier is sampled from a lognormal distribution with parameters meanlog = 0.15 and sdlog = 0.05 if preceded by a 2nd major revision, sdlog = 0.1 otherwise;

• For w / 3 < \tau \le 2w / 3, the revision multiplier is sampled from a lognormal distribution with parameters meanlog = 0 and sdlog = 0.05 if preceded by a 2nd major revision, sdlog = 0.1 otherwise;

• For \tau > 2w / 3, the revision multiplier is sampled from a lognormal distribution with parameters meanlog = -0.1 and sdlog = 0.05 if preceded by a 2nd major revision, sdlog = 0.1 otherwise.

Note that minor revisions tend to be upward in the early part of a claim’s life, and downward in the latter part.

The revision multipliers are subject to further constraints to ensure that the revised incurred estimate never falls below what has already been paid. This is dicussed in claim_history.

Important note: Unlike the major revision multipliers which apply to the incurred loss estimates, the minor revision multipliers apply to the case estimate of outstanding claim payments i.e. a revision multiplier of 2.54 means that at the time of the minor revision the outstanding claims payment increases by a factor of 2.54.

See Also

claims

Examples

set.seed(1)
test_claims <- SynthETIC::test_claims_object

# generate major revisions (required for the simulation of minor revisions)
major <- claim_majRev_freq(test_claims)
major <- claim_majRev_time(test_claims, major)
major <- claim_majRev_size(major)

# generate frequency of minor revisions
minor <- claim_minRev_freq(test_claims)
minor[[1]][[1]] # the "unit list" for the first claim

# update the timing information
minor <- claim_minRev_time(test_claims, minor)
# observe how this has changed
minor[[1]][[1]]
# with an alternative sampling distribution e.g. triangular
minRev_time_notatP <- function(n, setldel) {
  sort(rtri(n, min = setldel/6, max = setldel, mode = setldel))
}
minor_2 <- claim_minRev_time(test_claims, minor, minRev_time_notatP)

# update the revision multipliers (need to generate "major" first)
minor <- claim_minRev_size(test_claims, major, minor)

Generate Data of Varying Complexity

Description

Generates datasets under 5 scenarios of different levels of complexity (here "complexity" means the level of difficulty of analysis).

Usage

generate_data(
  n_claims_per_period,
  n_periods = 40,
  complexity = c(1:5),
  data_type = c("claims", "payments", "incurred"),
  random_seed = NULL,
  verbose = TRUE,
  covariates_obj = NULL
)

Arguments

Details

generate_data() produces datasets of varying levels of complexity, where 1 represents the simplest, and 5 represents the most complex:

• 1 – simple, homogeneous claims experience, with zero inflation.

• 2 – slightly more complex than 1, with dependence of notification delay and settlement delay on claim size, and 2% p.a. base inflation.

• 3 – steady increase in claim processing speed over occurrence periods (i.e. steady decline in settlement delays).

• 4 – inflation shock at time 30 (from 0% to 10% p.a.).

• 5 – default distributional models, with complex dependence structures (e.g. dependence of settlement delay on claim occurrence period).

We remark that this by no means defines the limits of the complexity that can be generated with SPLICE. This function is provided for the convenience of users who wish to generate (a collection of) datasets under some representative scenarios. If more complex features are required, the user is free to modify the distributional assumptions (which, of course, requires more thoughts and coding) to achieve their purposes.

Value

A named list of dataframes:

See Also

generate_claim_dataset, generate_transaction_dataset, generate_incurred_dataset

Examples

# Generate datasets of full complexity
result <- generate_data(
  n_claims_per_period = 50, data_type = c('claims', 'payments'),
  complexity = 5, random_seed = 42)

# Save individual datasets
claims <- result$claim_dataset
payments <- result$payment_dataset

# Generate chain-ladder compatible dataset
CL_simple <- generate_data(
  n_claims_per_period = 50, data_type = 'claims', complexity = 1, random_seed = 42)

# To mute message output
CL_simple_2 <- generate_data(
  n_claims_per_period = 50, data_type = 'claims', verbose = FALSE, random_seed = 42)

# Ouput is reproducible with the same random_seed value
all.equal(CL_simple$claim_dataset, CL_simple_2$claim_dataset)

Generate Incurred Dataset

Description

Generates a dataset of transaction records that tracks how the case estimates of the total incurred, the outstanding claim payments, and the cumulative claims paid change over time. A sample dataset is included as part of the package, see test_incurred_dataset.

Usage

generate_incurred_dataset(claims, incurred_history)

Arguments

Value

A dataframe that takes the same structure as test_incurred_dataset.

See Also

test_incurred_dataset

Incurred Triangles

Description

Outputs the full square of claims incurred by occurrence period and development period. The upper left triangle represents the past, and the lower right triangle the unseen future.

Users can modify the aggregate level by providing an aggregate_level argument to the function. For example, setting aggregate_level = 4 when working with calendar quarters produces an incurred square by occurrence and development year.

We refer to the package vignette for examples on changing the aggregation granularity: vignette("SPLICE-demo", package = "SPLICE")

Usage

output_incurred(
  incurred_history,
  aggregate_level = 1,
  incremental = TRUE,
  future = TRUE
)

Arguments

Details

Remark on out-of-bound transaction times: This function includes adjustment for out-of-bound transaction dates, by forcing any transactions that were projected to fall out of the maximum development period to be counted as if they were made at the end of the limiting development period. For example, if we consider 40 periods of development and a claim of the 21st occurrence period was projected to have a major revision at time 62.498210, then we would treat such a revision as if it occurred at time 60 for the purpose of tabulation.

Value

An array of claims incurred to date.

Incurred Case Estimates Dataset

Description

A dataset of 31,250 records of transactions (partial payments and incurred revisions) associated with the 3,624 claims described in SynthETIC's test_claim_dataset. The ⁠_inflated⁠ version includes inflation adjustment in the case estimates, while the ⁠_noInf⁠ version excludes any inflation effects.

Usage

test_incurred_dataset_noInf

test_incurred_dataset_inflated

Format

A data frame with 31,250 rows and 9 variables:

claim_no

claim number, which uniquely characterises each claim.

claim_size

size of the claim (in constant dollar values).

txn_time

double; the "absolute" time of transaction (on a continuous time scale).

txn_delay

delay from notification to the subject transaction.

txn_type

character; nature of the transactions, "Ma" for major revision, "Mi" for minor revision, "P" for payment, "PMa" for major revision coincident with a payment, "PMi" for minor revision coincident with a payment.

incurred

double; case estimate of total incurred loss immediately after the transaction.

OCL

double; case estimate of outstanding claim payments immediately after the transaction.

cumpaid

double; cumulative claim paid after the transaction.

multiplier

revision multipliers (subject to further constraints documented in claim_history), NA for transactions that do not involve a revision. Note that major revision multipliers apply to the incurred losses, while minor revision multipliers apply to the outstanding claim payments.

See Also

generate_incurred_dataset

The Triangular Distribution

Description

Density, distribution function, quantile function and random generation for the triangular distribution with parameters min, max and mode.

Usage

ptri(q, min, max, mode)

dtri(x, min, max, mode)

qtri(p, min, max, mode)

rtri(n, min, max, mode)

Arguments

Details

The triangular distribution with parameters min= a, max = b, mode= c has density:

and distribution function:

for a \le c \le b.

Value

dtri gives the density, ptri gives the distribution function, qtri gives the quantile function, and rtri generates random deviates.

Examples

ptri(c(0, 1/2, 1), min = 0, max = 1, mode = 1/2)
dtri(c(0, 1/2, 1), min = 0, max = 1, mode = 1/2)
plot(function(x) dtri(x, min = 0, max = 1, mode = 1/2), 0, 1)