2.1 Product description

Term Life Insurance

• Public product name ‘DeathPlus - Short Term Life Insurance’, Internal ID ‘L71-U’
• Only death benefits, no survival benefits
• Mortality table: Austrian 2010/12 census table unisex (mixed 65:35 from the male:female tables)
• Guaranteed interest rate: 0.5%
• Default contract duration: 5 years (to keep the example short)
• Regular premium payments (constant premiums) during the whole contract

Costs:

• Aquisition costs: 5% of the total premium sum
• Administration cost: 1% of the sum insured per year (both during premium payments as well as for paid-up contracts)
• Unit costs: 10 Euro per year (fixed) during premium payments
• Tax: 4% insurance tax (default)

Surrender Value:

• Reserve minus 10% surrender penalty, also applied on premium waiver

2.2 Tariff implementation (InsuranceTarif)

library(magrittr)
library(MortalityTables)
library(LifeInsuranceContracts)
mortalityTables.load("Austria_Census")

Tarif.L71U = InsuranceTarif$new(
    name = "L71-U",
    type = "wholelife",
    tarif = "DeathPlus - Short Term Life Insurance",
    desc = "Term Life insurance (5 years) with constant sum insured and regular premiums",
    policyPeriod = 5, premiumPeriod = 5,  # premiumPeriod not needed, defaults to maturity

    mortalityTable = mortalityTable.mixed(
      table1 = mort.AT.census.2011.male, weight1 = 0.65, 
      table2 = mort.AT.census.2011.female, weight2 = 0.35
    ),
    i = 0.005, 
    tax = 0.04, 
    costs = initializeCosts(alpha = 0.05, gamma = 0.01, gamma.paidUp = 0.01, unitcosts = 10),
    surrenderValueCalculation = function(surrenderReserve, params, values) { 
      surrenderReserve * 0.9 
    }
);

2.3 Creating a contract

With the above product / tariff definition, it is now easy to instantiate one particular contract for this tariff. All we need to do is pass the tariff and the corresponding contract-specific information (mainly age, sum insured and contract closing) to the InsuranceContract object:

contract.L71U  = InsuranceContract$new(
  Tarif.L71U, 
  age = 35, 
  contractClosing = as.Date("2020-08-18"), 
  sumInsured = 100000);

Just creating the contract will already calculate all cash flows, present values, premiums, reserves, etc. for the whole contract period. They can be accessed through the contract.L71U$Values list.

A full list of all possible arguments can be found in the section [All possible parameters and their default values].

Once the contract is created, all values can be accessed like this:

contract.L71U$Values$premiums

contract.L71U$Values$reserves

Looking back at the definition of the tariff, the only spot where the type of insurance actually came in was the type argument of the InsuranceTarif definition. This is one of the most important flags and is central to correct implementation of a tarif. On the other hand, all it does is to cause different vectors of survival, death and guaranteed cash flows. Once the cash flows are determined, the insurance contract and tariff does not need the insurance type any more.

In our term life example, the insurance contract’s unit cash flows are 1 for death benefits (both when premiums are paid and when the contract is paid-up) and for premiums in advance. All other cash flows (guaranteed, survival or disease cash flows) are zero. Similarly, the cost structure described above and implemented by the LifeInsuranceContracts::initializeCosts() function defines all cost cash flows, which are the starting point for all further calculations (only relevant columns of the data.frame are shown):

contract.L71U$Values$cashFlows

contract.L71U$Values$cashFlowsCosts[,,,"survival"]

• ,,“SumInsured”

• ,,“SumPremiums”

• ,,“GrossPremium”

• ,,“NetPremium”

• ,,“Constant”

• ,,“Reserve”

Once these unit cash flows are set, all insurance contracts are handled identically. First, present values of each of the cash flows are calculated, from which the premiums can be calculated by the equivalence principle.

contract.L71U$Values$presentValues

contract.L71U$Values$presentValuesCosts

• ,,“SumInsured”

• ,,“SumPremiums”

• ,,“GrossPremium”

• ,,“NetPremium”

• ,,“Constant”

• ,,“Reserve”

contract.L71U$Values$premiums

The actual calculation of the premiums has to be in the order gross premium, Zillmer premiuem, then net premium. The reason for this particular order is that some tariffs have a gross premium refund in case of death. So to calculate the net premium, the gross premium is required.

The premiums allow the unit cash flows and present values to be converted to monetary terms (fields contract.L71U$Values$absCashFlows and contract.L71U$Values$absPresentValues). Also, the reserves of the contract can be calculated.

contract.L71U$Values$reserves

Also, the premium composition into costs, risk premium, savings premium and other components is possible.

contract.L71U$Values$premiumComposition

As we see, the whole history and future of the contract is calculated as soon as it is created. It is, however, also possible to modify a contract later on, e.g. by stopping premium payments and converting it to a paid-up contract.

contract.L71U = contract.L71U$premiumWaiver(t = 3)
contract.L71U$Values$reserves

2.4 Creating tables with various parameters

When prototyping a new product or creating marketing material, it is often needed to create tables of premiums, reserves, benefits or surrender values for different parameters (e.g. different ages, maturities and sums insured for the marketing department, or different guaranteed interest rates, mortality tables or costs for the product development group).

This can be easily done by the functions contractGridPremium() or contractGrid(). They take one argument axes, which gives the parameters for the axes of the table (more than two dimensions are possible!), while all other parameters are passed unchanged to InsuranceContract$new().

First, let us create a grid of premiums for different ages and maturities (for sum insured 100,000 Euro):

grd = contractGridPremium(
  axes = list(age = seq(20, 80, 5), policyPeriod = seq(10, 40, 5)),
  tarif = Tarif.L71U, 
  contractClosing = as.Date("2020-08-18"), 
  sumInsured = 100000
)
grd

One can also pass more than two dimensions to the axes:

grd = contractGridPremium(
  axes = list(age = seq(20, 80, 10), policyPeriod = seq(10, 40, 10), sumInsured = c(10000, 50000, 100000)),
  tarif = Tarif.L71U, 
  contractClosing = as.Date("2020-08-18")
)
grd

• , , sumInsured=10000

• , , sumInsured=50000

• , , sumInsured=100000

One can use any of the parameters of the InsuranceContract$new() call in the axes argument, even the tarif or mortalityTable parameters. This means that one can create tables comparing different tariffs, or showing the effect of different life tables.

In the following example, we use the tarif Tarif.L71U, but instead of the unisex table (mixed 65:35 from male:female tables), we use the male mortality tables of the Austrian census from 1870 to 2011 (with a contract period of 10 years fixed, and varying ages):

grd = contractGridPremium(
  axes = list(mortalityTable = mort.AT.census["m", ], age = seq(20, 80, 10)),
  tarif = Tarif.L71U, 
  sumInsured = 100000,
  contractClosing = as.Date("2020-08-18")
) 
grd

4.1 Creating the tariff

The InsuranceTarif class provides a way to define an abstract insurance product. The most important parameters to be passed in the InsuranceTarif$new() call are:

A typical call looks like the following for a pure endowment with gross premium refund upon death and a linearly decreasing surrender penalty:

Tarif.PureEnd = InsuranceTarif$new(
  name = "Example Tariff - Pure Endowment",
  type = "pureendowment",
  tarif = "PE1-RP",
  desc = "A pure endowment with regular premiums (standard tariff)",

  mortalityTable = mort.AT.census.2011.unisex,
  i = 0.005,
  # Costs: 4% acquisition, where 2.5% are zillmered, 5\% of each premium as beta costs, 
  #        1%o administration costs of the sum insured over the whole contract period
  costs = initializeCosts(alpha = 0.04, Zillmer = 0.025, beta = 0.05, gamma.contract = 0.001, gamma.paidUp = 0.001),
  unitcosts = 10,

  # Yearly premiums get no surcharge, monthly premiums add +4%
  premiumFrequencyLoading = list("1" = 0, "12" = 0.04),
  premiumRefund = 1,  # Full gross premium refund upon death
  tax = 0.04,         # 4% insurance tas

  surrenderValueCalculation = function(surrenderReserve, params, values) {
    n = params$ContractData$policyPeriod
    # Surrender Penalty is 10% at the beginning and decreases linearly to 0%
    surrenderReserve * (0.9 + 0.1 * (0:n)/n)
  }
)

Many parameters do not need to be given explicitly, but instead use sensible defaults (like the premiumPeriod, which by default equals the whole contract period, i.e. regular premium payments over the whole contract duration).

To create a similar tariff with some changes, one can call the createModification method of the InsuranceTarif clas, which takes as arguments all insurance parameters that should be changed for the new tarif.

To create a single-premium version of the pure endowment shown above, one can simply use a call like:

Tarif.PureEnd.SP = Tarif.PureEnd$createModification(
  name = "Example Tariff - Pure Endowment (SP)",
  tarif = "PE1-SP",
  desc = "A pure endowment with single premiums",
  premiumPeriod = 1
)

library(MortalityTables)
mortalityTables.load("Austria_Census")
mortalityTables.load("Austria_Annuities_AVOe2005R")
  # Costs: 4% acquisition, where 2.5% are zillmered, 5\% of each premium as beta costs, 
  #        1%o acquisition costs of the sum insured over the whole contract period
example.Costs = initializeCosts(
  alpha = 0.04, Zillmer = 0.025, 
  beta = 0.05, 
  gamma.contract = 0.001, gamma.paidUp = 0.001
)
example.Surrender = function(surrenderReserve, params, values) {
    n = params$ContractData$policyPeriod
    # Surrender Penalty is 10% at the beginning and decreases linearly to 0%
    surrenderReserve * (0.9 + 0.1 * (0:n)/n)
}

Tarif.Endowment = InsuranceTarif$new(
  name = "Example Tariff - Endowment",
  type = "endowment",
  tarif = "EN1",
  desc = "An endowment with regular premiums",

  mortalityTable = mort.AT.census.2011.unisex,
  i = 0.005,
  costs = example.Costs,
  unitcosts = 10,
  tax = 0.04,         # 4% insurance tax
  surrenderValueCalculation = example.Surrender
)

Tarif.Life = InsuranceTarif$new(
  name = "Example Tariff - Whole/Term Life",
  type = "wholelife",
  tarif = "Life1",
  desc = "A whole or term life insurance with regular premiums",

  mortalityTable = mort.AT.census.2011.unisex,
  i = 0.005,
  costs = example.Costs,
  unitcosts = 10,
  tax = 0.04,         # 4% insurance tax
  surrenderValueCalculation = example.Surrender
)

Tarif.ImmAnnuity = InsuranceTarif$new(
  name = "Example Tariff - Immediate Annuity",
  type = "annuity",
  tarif = "Ann1",
  desc = "An annuity with single-premium",
  premiumPeriod = 1,

  mortalityTable = AVOe2005R.unisex,
  i = 0.005,
  costs = example.Costs,
  tax = 0.04         # 4% insurance tax
)

# Premium periods and deferral periods can also be given as a function of other
# contract parameters (like the age at contract inception, etc.)
Tarif.DefAnnuity = InsuranceTarif$new(
  name = "Example Tariff - Deferred Annuity",
  type = "annuity",
  tarif = "Life1",
  desc = "A deferred annuity (life-long payments start at age 65) with reg. premiums",

  policyPeriod = function(params, values) { 120 - params$ContractData$age},
  deferralPeriod = function(params, values) { 65 - params$ContractData$age},
  premiumPeriod = function(params, values) { 65 - params$ContractData$age},
    
  mortalityTable = AVOe2005R.unisex,
  i = 0.005,
  costs = example.Costs,
  tax = 0.04,         # 4% insurance tax
  surrenderValueCalculation = example.Surrender
)

# An example dread-disease tariff, morbidity is assumed linearly increasing with age
ddTable = mortalityTable.period(name = "Linear dread-disease table", 
                                ages = 0:100, deathProbs = 0:100/500)
Tarif.DreadDisease = InsuranceTarif$new(
  name = "Example Tariff - Dread-Disease",
  type = "dread-disease",
  tarif = "DD1",
  desc = "A dread disease insurance with a lump-sum payment upon diagnosis",

  sumInsured = 50000,
  mortalityTable = mort.AT.census.2011.unisex,
  invalidityTable = ddTable,
  i = 0.005,
  costs = example.Costs,
  unitcosts = 10,
  tax = 0.04,         # 4% insurance tax
  surrenderValueCalculation = example.Surrender
)

4.2 Creating a contract

While the tariff describes the general product features, the contract object holds the data of a concrete contract. All insurance parameters (see section [All possible parameters and their default values]) can be given to override tarif defaults.

However, the most important and often used parameters are:

For the pure endowments defined above, a typical contract would be created like this:

contract.PureEnd = InsuranceContract$new(
    Tarif.PureEnd,
    age = 50, policyPeriod = 20, 
    premiumFrequency = 12,
    sumInsured = 100000,
    contractClosing = as.Date("2020-07-01")
  )

contract.PureEnd$Values$premiums

contract.PureEnd$Values$premiumComposition

Due to the full premium refund in case of death, there is only very little biometric risk involved. If the premium refund is not included in the contract, then we have a negative biometric risk over the whole period (i.e. negative risk premium, because upon death the existing reserves is shared with the collective). The premium refund can be overridden directly in the contract call:

contract.PureEnd.NoRefund = InsuranceContract$new(
    Tarif.PureEnd,
    age = 50, policyPeriod = 20, 
    premiumFrequency = 12,
    sumInsured = 100000,
    contractClosing = as.Date("2020-07-01"),
    premiumRefund = 0
  )

cbind(`With refund` = contract.PureEnd$Values$premiums, `Without refund` = contract.PureEnd.NoRefund$Values$premiums)

cbind(
  `Gross premium with refund` = contract.PureEnd$Values$premiumComposition[,"gross"],
  `Gross premium w/o refund` = contract.PureEnd.NoRefund$Values$premiumComposition[,"gross"],
  `Risk premium with refund` = contract.PureEnd$Values$premiumComposition[,"risk"],
  `Risk premium w/o refund` = contract.PureEnd.NoRefund$Values$premiumComposition[,"risk"]
)

To create a single-premium contract, one can either use the single-premium tarif defined above, or simply pass premiumPeriod=1 to the call:

contract.PureEnd.SP1 = InsuranceContract$new(
    Tarif.PureEnd,
    age = 40, policyPeriod = 45, premiumPeriod = 1,
    sumInsured = 100000,
    contractClosing = as.Date("2020-07-01")
  )
contract.PureEnd.SP2 = InsuranceContract$new(
    Tarif.PureEnd.SP,
    age = 40, policyPeriod = 45, # premiumPeriod already set by tariff!
    sumInsured = 100000,
    contractClosing = as.Date("2020-07-01")
  )

all_equal(contract.PureEnd.SP1$Values$reserves, contract.PureEnd.SP2$Values$reserves)
#> [1] TRUE

4.3 Premium Waivers

After a while, many customers do not want to pay premiums for the contract any more and convert the contract to a paid-up contract. The unit benefit cash flows from that moment on stay the same, but the sum insured is adjusted, so that the existing reserve is able to cover all future benefits and costs. Furthermore, paid-up contracts typically have differen costs / loadings. Additionally, the surrender penalty is usually applied to the reserve before the conversion.

Waiving premiums and recalculating the sum insured is very easy, one just calls the method InsuranceContract$premiumWaiver(t = ..) on the existing contract.

contract.PureEnd.NoRefund.Prf = contract.PureEnd.NoRefund$clone()$premiumWaiver(t = 7)
contract.PureEnd.NoRefund.Prf$Values$reserves

Notice that the contract changes are made directly to the contract (“reference semantics”). This is different from the typical behavior of R, where any change to e.g. a data.frame leaves the original data.frame intact and instead returns a modified copy.

5.1 Valuation

The calculation of all contract values is controlled by the function InsuranceContract$calculateContract() (using methods of the InsuranceTarif object) and follows the following logic:

1. First the contingent (unit) cash flows and the transition probbilities are determined.
2. The actuarial equivalence principle states that at time of inception, the (net and gross) premium must be determined in a way that the present value of the future benefits and costs minus the present value of the future premiums must be equal, i.e. in expectation the future premiums ove the whole lifetime of the contract will exactly cover the benefits and costs. Similarly, at all later time steps, the difference between these two present values needs to be reserved (i.e. has already been paid by the customer by previous premiums).
3. This allows the premiums to be calculated by first calculating the present values for all of the benefit and costs cash flow vectors.
4. The formulas to calculate the gross, Zillmer and net premiums involve simple linear combinations of these present values, so the coefficients of these formulas are determined next.
5. With the coefficients of the premium formulas calculated, all premiums can be calculated (first the gross premium, because due to potential gross premium refunds in case of death, the formula for the net premium requires the gross premium, which the formula for the gross premium involves no other type of premuim).
6. With premiums determined, all unit cash flows and unit present values can now be expressed in monetary terms / as absolute cash flows (i.e. the actual Euro-amount that flows rather than a percentage).
7. As described above, the difference between the present values of premiums and present values of benefits and costs is defined as the required amount of reserves, so the reserves (net, gross, administration cost, balance sheet) and all values derived from them (i.e. surrender value, sum insured in case of premium waiver, etc.) are calculated.
8. The decomposition of the premium into parts dedicated to specific purposes (tax, rebates, net premium, gross premium, Zillmer premium, cost components, risk premium, savings premium, etc.) can be done once the reserves are ready (since e.g. the savings premium is defined as the difference of discounted reserves at times \(t\) and \(t+1\)).
9. If the contract has (discretionary or obligatory) profit sharingB mechanisms included, the corresponding [ProfitParticipation] object can calculate that profit sharing amounts, once all guaranteed values are calculated. This can also be triggered manually (with custom profit sharing rates) by calling the methods InsuranceContract$profitScenario() or InsuranceContract$addProfitScenario().

5.2 Cash Flows

An insurance contract is basically defined by the (unit) cash flows it produces: Together with the transition probabilities (mortalityTable parameter) the present values can be calculated, from which the premiums follow and finally the reserves and a potential profit sharing.

For example, a term life insurance with regular premiums would have the following cash flows:

• premium cash flows: 1, 1, 1, 1, 1, …
• survival cash flows: 0, 0, 0, 0, 0, …
• guaranteed cash flows: 0, 0, 0, 0, 0, …
• death benefit cash flows: 1, 1, 1, 1, 1, …

A single-premium term life insurance would look similar, except for the premiums:

• premium cash flows: 1, 0, 0, 0, 0, …

A pure endowment has no death benefits, but a survival benefit of 1 at the maturity of the contract:

• premium cash flows: 1, 1, 1, 1, 1, …
• survival cash flows: 0, 0, …, 0, 1
• guaranteed cash flows: 0, 0, 0, 0, 0, …
• death benefit cash flows: 0, 0, 0, 0, 0, …

An endowment has also death benefits during the contract duration:

• premium cash flows: 1, 1, 1, 1, 1, …
• survival cash flows: 0, 0, …, 0, 1
• guaranteed cash flows: 0, 0, 0, 0, 0, …
• death benefit cash flows: 1, 1, 1, 1, 1, …

A (deferred) annuityB has premium cash flows only during the deferral peroid and only survival cash flows during the annuity payment phase. Often, in case of death during the deferral period, all premiums paid are refunded as a death benefit.:

• premium cash flows: 1, 1, …, 1, 0, 0, 0, …
• survival cash flows: 0, 0, …, 0, 1, 1, 1,…
• guaranteed cash flows: 0, 0, 0, 0, 0, …
• death benefit cash flows: 1, 2, 3, 4, 5, …, 0, 0, …

A terme-fix insurance has a guaranteed payment at maturity, even if the insured has already died. The premiums, however, are only paid until death (which is not reflected in the contingent cash flows, but rather in the transition probabilities):

• premium cash flows: 1, 1, 1, 1, …, 1
• survival cash flows: 0, 0, 0, 0, …, 0
• guaranteed cash flows: 0, 0, 0, …, 0, 1
• death benefit cash flows: 0, 0, 0, 0, …, 0

6.1 Frequency charges

Typically, an insurance premium is calculated with yearly premiums paid in advance. If premiums are paid more often per year (Parameter premiumFrequency or benefitFrequency set to a value larger than 1, typically 2 for half-yearly, 4 for quarterly, or 12 for monthly payments), part of the interest during the year is lost, as well as the premiums for the remainder of the year if the insured event happens. So usually there is some kind of extra charge included:

• A frequency charge is added on the gross premium => Parameter premiumFrequencyLoading and benefitFrequencyLoading are set to a list with keys “1”, “2”, “4” and “12” and values that correspond to the extra charge (as a factor on the gross premium, i.e. a percentage).
• The premium or benefit payments are calculated (approximately) as payments \(k\)-times per year using yearly death / incidence probabilities. This calculation is typically using some approximations in \(k\) => Parameter premiumFrequencyOrder and benefitFrequencyOrder set to a value larger than 0.
• Contracts with \(k>1\) have higher cost loadings on the gross premium. => Parameter costs is implemented a function with signature \(function(params, values)\), which accesses params$ContractData$premiumFrequency to return different expense rates for different premium payment frequencies.
• If the guaranteed interest rate is 0%, the exact moment of payment during a year is irrelevant for the guaranteed values. However, if a yield larger than 0% is achieved, it is assigned to the contract via profit participation. So it makes sense adjust profit participation rates depending on the premium frequency rather than modifying the premium. The higher the profit participation, the higher the effect of the \(k\)-th yearly premium payments and the higher the modification of the rates can be. => Parameter getInterestProfitRate of the profit scheme can be implemented as a function that modifies the rate depending on the premium or benefit frequency (similar to the cost adjustment mentioned in the previous item).

Tarif.Life.FrequencyLoading = Tarif.Life$createModification(
  name = "Term life (frequency loading)",
  premiumFrequencyLoading = list("1" = 0.0, "2" = 0.01, "4" = 0.015, "12" = 0.02)
)
Tarif.Life.FrequencyApprox1 = Tarif.Life$createModification(
  name = "Term life (k-th yearly, approx. 1.Ord.)",
  premiumFrequencyOrder = 1
)
Tarif.Life.FrequencyApprox2 = Tarif.Life$createModification(
  name = "Term life (k-th yearly, approx. 2.Ord.)",
  premiumFrequencyOrder = 2
)
Tarif.Life.FrequencyApprox3 = Tarif.Life$createModification(
  name = "Term life (k-th yearly, exact)",
  premiumFrequencyOrder = Inf
)

Tarif.Life.FrequencyExpense = Tarif.Life$createModification(
  name = "Term life (modified gamma costs)",
  costs = function(params, values) {
    switch (toString(params$ContractData$premiumFrequency),
        "12" = initializeCosts(alpha = 0.04, Zillmer = 0.025,  beta = 0.05,  gamma.contract = 0.00127, gamma.paidUp = 0.001),
        "4" = initializeCosts(alpha = 0.04, Zillmer = 0.025,  beta = 0.05,  gamma.contract = 0.00119, gamma.paidUp = 0.001),
        "2" = initializeCosts(alpha = 0.04, Zillmer = 0.025,  beta = 0.05,  gamma.contract = 0.0011, gamma.paidUp = 0.001),
        initializeCosts(alpha = 0.04, Zillmer = 0.025,  beta = 0.05,  gamma.contract = 0.001, gamma.paidUp = 0.001)
    )
  }
)

Of course, the loadings and costs mentioned above are not necessarily mathematically derived to offset the interest effect of k-th yearly payments. Rather, they are often simply decided by the management. Thus, the three approaches implemented here can have quite different results:

contractGridPremium(
  axes = list(tarif = c(Tarif.Life.FrequencyLoading, Tarif.Life.FrequencyApprox1, 
                        Tarif.Life.FrequencyApprox2, Tarif.Life.FrequencyApprox3, 
                        Tarif.Life.FrequencyExpense),
              premiumFrequency = c(1, 2, 4, 12)),
  age = 40, policyDuration = 20,
  sumInsured = 100000,
  contractClosing = as.Date("2020-09-01")
) %>% kableTable

6.2 Security loadings

Although most mortality tables and expense loadings already have a certain amount of security margins included, often a tariff (mostly protection products) adds an additional security loading directly to the net present value of the benedits.

This can be easily implemented using the parameter security:

contractGridPremium(
  axes = list(age = seq(30, 60, 10), security = 10*(0:5)/100),
  tarif = Tarif.Life,
  policyDuration = 20,
  sumInsured = 100000,
  contractClosing = as.Date("2020-09-01")
) %>% kableTable(digits = 2)

10.1 Fixed yearly premium increases

With this kind of increases, the initial contract valuation (i.e. the determination of the premium at contract inception) already takes into account that the premium will not stay constant over the whole period, but increases by a constant factor each year. The sum insured is calculated by the equivalence principle so that the expected present value of all future benefits and costs equals the expected present value of all future (i.e.  increasing) premium payments.

This type of yearly premium increase by a fixed factor can be implemented by the parameter:

• premiumIncrease … The factor, by which the premium increases yearly. Default is 1.0 (no increase in premium).

In the following example, we create a 10-year endowment contract with constant premiums over the whole period and another one with idential parameters except that the premium increases by 4% each year:

# For comparison: Contract with constant premiums
contract.Endow.Constant = InsuranceContract$new(
  tarif = Tarif.Endowment,
  sumInsured = 10000,
  age = 50, policyPeriod = 10,
  contractClosing = as.Date("2020-09-01")
)
# Contract with 4% yearly premium increase and same sum insured
contract.Endow.PremInc = InsuranceContract$new(
  tarif = Tarif.Endowment,
  sumInsured = 10000,
  premiumIncrease = 1.04,
  age = 50, policyPeriod = 10,
  contractClosing = as.Date("2020-09-01")
)
premium.comparison = data.frame(
  `Sum Insured` = contract.Endow.Constant$Values$basicData[,"SumInsured"],
  `Constant Premium` = contract.Endow.Constant$Values$basicData[,"Premiums"],
  `4% Yearly Increase` = contract.Endow.PremInc$Values$basicData[,"Premiums"],
  check.names = F
  )

premium.comparison %>% pander

10.2 Fixed yearly benefit increases with constant premium

With this kind of increases, the premium will stay constant over the whole contract maturity, but the death and/or survival benefit (or the annuity payment) will increase by a fixed factor each year. This is typically to safeguard the benefit against inflation, so that the value of the annuity payment or death benefit does not diminish due to inflation. The initial contract valuation (i.e. the determination of the constant premium at contract inception) already takes into account that the benefits will not stay constant over the whole period, but increases by a constant factor each year.

This type of yearly benefit increase by a fixed factor can be implemented by the parameters:

• annuityIncrease … The factor, by which potential annuity payments increase yearly. Default is 1.0 (no increase in annuity benefits)
• deathBenefit … The vector of death benefits (relative to the sum insured, which for endowments describes the survival benefit)

In the following example, we create a 10-year endowment contract with constant premiums over the whole period and another one with idential parameters except that the premium increases by 4% each year:

# For comparison: Contract with constant premiums
contract.TermLife.Constant = InsuranceContract$new(
  tarif = Tarif.Life,
  sumInsured = 10000,
  age = 50, policyPeriod = 10,
  contractClosing = as.Date("2020-09-01")
)
# Contract with 4% yearly increase in sum insured (final survival benefit is 10.000)
contract.TermLife.SumInc = InsuranceContract$new(
  tarif = Tarif.Life,
  sumInsured = 10000,
  deathBenefit = (1.04)^(0:20),
  age = 50, policyPeriod = 10,
  contractClosing = as.Date("2020-09-01")
)
premium.comparison = data.frame(
  `Const S.I.` = contract.TermLife.Constant$Values$absCashFlows[,"death"],
  `Const. Premium` = contract.TermLife.Constant$Values$absCashFlows[,"premiums_advance"],
  `4% sum increase` = contract.TermLife.SumInc$Values$absCashFlows[,"death"],
  `Premium w. sum increase` = contract.TermLife.SumInc$Values$absCashFlows[,"premiums_advance"],
  check.names = F
  )
premium.comparison

For annuities, the benefit increase is not handled through deathBenefits, but rather through the parameter

• annuityIncrease … yearly increase factor of the annuity payments

In the following example, we create a 10-year endowment contract with constant premiums over the whole period and another one with idential parameters except that the premium increases by 4% each year:

# For comparison: Contract with constant annuity
contract.Annuity.Constant = InsuranceContract$new(
  tarif = Tarif.DefAnnuity,
  sumInsured = 1200,
  age = 55, 
  policyPeriod = 10,
  deferralPeriod = 5,
  premiumPeriod = 5,
  contractClosing = as.Date("2020-09-01")
)
# Contract with 4% yearly increase in annuity benefits
contract.Annuity.Increasing = InsuranceContract$new(
  tarif = Tarif.DefAnnuity,
  sumInsured = 1200,
  annuityIncrease = 1.04,
  age = 55, 
  policyPeriod = 10,
  deferralPeriod = 5,
  premiumPeriod = 5,
  contractClosing = as.Date("2020-09-01")
)
# Contract with 4% yearly increase in premiums and in annuity payments
contract.Annuity.IncreasingBoth = InsuranceContract$new(
  tarif = Tarif.DefAnnuity,
  sumInsured = 1200,
  annuityIncrease = 1.04,
  premiumIncrease = 1.04,
  age = 55, 
  policyPeriod = 10,
  deferralPeriod = 5,
  premiumPeriod = 5,
  contractClosing = as.Date("2020-09-01")
)
premium.comparison = data.frame(
  `Const. Annuity` = contract.Annuity.Constant$Values$absCashFlows[,"survival_advance"],
  `Const. Premium` = contract.Annuity.Constant$Values$absCashFlows[,"premiums_advance"],
  `4% Annuity Increase` = contract.Annuity.Increasing$Values$absCashFlows[,"survival_advance"],
  `Premium w. Ann.Increase` = contract.Annuity.Increasing$Values$absCashFlows[,"premiums_advance"],
  `Inc.Premium w. Ann.Increase` = contract.Annuity.IncreasingBoth$Values$absCashFlows[,"premiums_advance"],
  check.names = F
  )

premium.comparison %>% pander

10.3 Dynamic Increases

With dynamic increases, the contract initially is written with a fixed sum insured and constant premiums over the whole contract period. The future increases are not considered at all.

After the initial contract inception, either yearly or when a consumer price index changes by a value larger than a given threshold, the sum insured is increased (either by a fixed amount or by an amount determined by the index change) and the premium is adjusted accordingly. Internally, the original contract is left untouched and the increase is modelled by a separate contract with the same key parameters, only with shorter duration and a sum insured that represents only the increase. The premium for this increase is calculated like a separate contract with only the difference in the over-all sum insured as its sum insured.

Each dynamic increase then adds another separate tiny InsuranceContract object and the over-all values are the sums of all those contract blocks (sometimes also called “contract slices”).

The InsuranceContract class provides a method to add a dynamic increase:

• InsuranceContract$addDynamics(t, NewSumInsured, SumInsuredDelta, id, ...)

Only one of NewSumInsured (new total sum insured) and SumInsuredDelta (only the difference between old and new sum insured) is needed. This method adds a new contract block to the given InsuranceContract, starting at time \(t\) with SumInsuredDelta as its sum insured and its premium calculated from the shorter contract period and the sum insured delta. These blocks for dynamic increases are stored in the contract’s $blocks list of children. The values stored in the contract are then simply the sum of all its children.

Here is an example of a 10-year endowment, which has dynamic increases at times \(t=5\), \(t=7\) and \(t=8\):

# For comparison: Contract with constant annuity
contract.Endowment.Dynamics = InsuranceContract$new(
  tarif = Tarif.Endowment,
  sumInsured = 10000,
  age = 40, 
  policyPeriod = 10,
  contractClosing = as.Date("2020-09-01"),
  id = "Initial contract"
)$
  addDynamics(t = 5, NewSumInsured = 11000, id = "Dynamic at 5")$
  addDynamics(t = 7, NewSumInsured = 12000, id = "Dynamic at 7")$
  addDynamics(t = 8, NewSumInsured = 13500, id = "Dynamic at 8")

# Over-all contract sum insured and premiums for all blocks combined
contract.Endowment.Dynamics$Values$basicData[,c("SumInsured", "Premiums")] %>% pander

11.1 Advance profit participation (premium rebate)

To implement advance profit participation, one still needs to create a ProfitParticipation object, which can be empty. The contract parameters advanceProfitParticipation and advanceProfitParticipationInclUnitCost then define the premium rebate. They can be set either in the profit scheme or in the tariff definition. The latter is usually the easier way, as one profit scheme might be applicable to multiple different tariffs with different advance profit participation rates.

As an example, we will use our Tarif.Life whole life tarif defined above and add a \(38\%\) advance profit participation on the premium:

profit.Advance.V1 = ProfitParticipation$new(
    name = "Profit Scheme for advance profit participation, V 1.0",
    advanceProfitParticipation = 0.38
);

Tarif.Life.withPP = Tarif.Life$createModification(
  name = "Example Tariff - Whole/Term Life with profit sharing",
  tarif = "Life1PP",
  profitParticipationScheme = profit.Advance.V1
)

contract.LifePP = InsuranceContract$new(
  tarif = Tarif.Life.withPP,
  age = 40, policyPeriod = 10,
  sumInsured = 100000,
  contractClosing = as.Date("2019-09-01")
)

The premium composition shows that the profit participation

contract.LifePP$Values$premiumComposition

11.2 The ProfitParticiption class

The profit participation scheme of a tarif is represented by an object of the ProfitParticipation class. While the InsuranceContract.Parameters list contains elements for the profit rates, the implementation of the calculation of the profit parts is done by functions defined in the ProfitParticipation constructor.

This scheme is passed to the InsuranceTarif or InsuranceContract via the profitParticipationScheme parameter. `

There are different types of profit participation assignments, based on the type of risks they are based upon:

• Interest profit: total credited rate (minus guarantee) applied to some kind of reserve
• Risk profit: risk profit rate applied to the risk premium, capital or the sum insured
• Expense profit: expense profit rate applied to the sum insured
• Sum profit: rate (depending on sum insured) applied to the sum insured
• Terminal bonus: yearly attributions are collected and paid out only on contract maturity
• Terminal bonus fund: Part of the ongoing profit allocation is not immediately attributed to the contract, but stored in a special reserve and paid out only on maturity.

Each of these profit components in general depends in some way on a profit rate and a basis to which the rate is applied. So each component has the general functional form: \[Profit^{type}_t = Calc\left(Rate^{type}_t, Basis^{type}_t\right)\] The most common calculation function is a simple multiplication, i.e. \(Calc(r, b) = r\cdot b\), but other functions are possible, to

The (default) parameters that can be passed to the ProfitParticipation constructor are:

For the calculation of the profit participation, the ProfitParticipation class holds a list of function pointers to calculate each component of profit participation, as outlined above. For each of interest, risk, expense, sum, terminal and terminal bonus fund the following three functions can be given:

• Profit rate: return the profit rate as a function from the values of the contract

  Function signature: function(rates, ...)

• Profit base: The quantity on which to apply the rate. Typically this function returns either the current reserve, the previous reserve (or some combination), the sum insured or the current risk premium.

  Function signature: function(rates, params, values, ...)

• Calculation: A function taking the rate and the base and calculate the profit assigned for the specific profit component. Most common are a simple multiplication of base and rate, but other formulas are possible, too.

  Function signature: function(base, rate, waiting, rates, params, values, ...)

Thus, the constructor of the ProfitParticipation class also takes the following parameters:

In addition, the following parameters define functions for reserves:

• getTerminalBonusReserve … Calculate the reserve for the terminal bonus from the bonus assignments (old tariffs often use some kind of discounting or conditional reserving for the terminal bonus reserve)

  Function signature: function(profits, rates, terminalBonus, terminalBonusAccount, params, values)

To calculate the actual benefits paid out from profit participation, the following parameters take the corresponding functions (signature: function(profits, rates, params, values, ...) )

ProfitScheme.example = ProfitParticipation$new(
  name = "Example Profit Scheme, V 1.0",
  profitComponents = c("interest", "risk", "expense", "sum", "TBF"),

  getInterestOnProfits    = PP.rate.interestProfitPlusGuarantee,
  getInterestProfitBase   = PP.base.meanContractualReserve,
  getRiskProfitBase       = PP.base.ZillmerRiskPremium,
  getExpenseProfitBase    = PP.base.sumInsured,
  getSumProfitBase        = PP.base.sumInsured,
  getTerminalBonusFundBase = PP.base.totalProfitAssignment,
  
  mortalityProfitRate = 0.15,
  expenseProfitRate = 0.01,
  sumProfitRate = function(params, ...) {if (params$ContractData$sumInsured > 1000000) 0.005 else 0;},
  terminalBonusFundRate = 0.3,
  
  calculateSurvivalBenefit      = PP.benefit.ProfitPlusTerminalBonusReserve,
  
  calculateDeathBenefitAccrued  = PP.benefit.ProfitPlusInterestMinGuaranteeTotal,
  calculateDeathBenefitTerminal = PP.benefit.TerminalBonus,
  calculateSurrenderBenefitAccrued = PP.benefit.ProfitPlusHalfInterestMinGuaranteeTotal,
  calculateSurrenderBenefitTerminal = function(profits, ...) {  profits[, "TBF"] / 2 },
  calculatePremiumWaiverBenefitAccrued = PP.benefit.Profit,
  calculatePremiumWaiverBenefitTerminal = function(profits, ...) {  profits[, "TBF"] / 2 },
  
  profitClass = NULL
)