Risk analyticsmaster

ii
Version: 1.0.207
Copies of this document may be made for your own use and for distribution
to others, provided that you do not charge any fee for such copies and
further provided that each copy contains this Copyright Notice, whether
distributed in print or electronically.
The RiskAnalytics source code and the example code presented in this
book are available at
https://svn.intuitive-collaboration.com/RiskAnalytics/trunk/
RiskAnalyticsPC
This document has been written by various PillarOne core team members:
• Jon Bardola, FS-Consulta GmbH
• J¨org Dittrich, Munich Re
• Benjamin Ginsberg, Intuitive Collaboration AG
• Fouad Jaada, Intuitive Collaboration AG
• Stephan Hartmann, Munich Re
• Stefan Kunz, Intuitive Collaboration AG
• Markus Meier, Intuitive Collaboration AG
• Martin Melchior, Fachhochschule Nordwestschweiz
• Michael Spahn, Intuitive Collaboration AG
• Markus Stricker, Intuitive Collaboration AG
• Jessika Walter, Intuitive Collaboration AG
The PillarOne project was initiated and sponsered by Munich Re.
For further details please get in touch: contact@pillarone.org

Contents
I User Guide 5
1 Introduction 7
2 Getting Started 11
2.1 Installing the standalone version . . . . . . . . . . . . . 12
2.2 Installing the server version . . . . . . . . . . . . . . . . 13
2.3 Your ﬁrst simulation . . . . . . . . . . . . . . . . . . . . 14
2.4 A mini result analysis: MRA . . . . . . . . . . . . . . . 14
3 The command line 15
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Starting the Command Line Interface (CLI) . . . . . . . 15
4 The user interface 17
4.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Frame selection pane . . . . . . . . . . . . . . . . . . . . 19
4.4 Navigation pane . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Data pane . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Partial internal non-life model Podra 25
5.1 Step by step . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Risk Modelling for Insurance Groups 33
7 Life insurance cash ﬂow model 39
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Input parameters . . . . . . . . . . . . . . . . . . . . . . 47
1

2 CONTENTS
7.4 Input parameters . . . . . . . . . . . . . . . . . . . . . . 60
7.5 Running calculations . . . . . . . . . . . . . . . . . . . . 69
7.6 Results and output presentation . . . . . . . . . . . . . 71
7.7 Future development . . . . . . . . . . . . . . . . . . . . 79
8 The application 81
8.1 Input Parameters . . . . . . . . . . . . . . . . . . . . . . 81
8.2 Deﬁning outputs . . . . . . . . . . . . . . . . . . . . . . 82
8.3 Running calculations / simulations . . . . . . . . . . . . 83
8.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
II Reference Guide 85
9 Concepts 87
9.1 Risk Model . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.3 Component . . . . . . . . . . . . . . . . . . . . . . . . . 90
10 Modelling claims 95
10.1 Claims Generators . . . . . . . . . . . . . . . . . . . . . 96
10.2 Reserve Generators . . . . . . . . . . . . . . . . . . . . . 105
10.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 105
10.4 Event Generators . . . . . . . . . . . . . . . . . . . . . . 107
11 Dependency Modelling 109
11.1 Scaling and allocating claims . . . . . . . . . . . . . . . 109
11.2 Dependency models for attritional claims . . . . . . . . 110
11.3 Dependency models for single claims . . . . . . . . . . . 113
11.4 A simple dependency example . . . . . . . . . . . . . . . 113
12 Modelling exposure 117
12.1 Underwriting Segments . . . . . . . . . . . . . . . . . . 117
12.2 Lines of Business . . . . . . . . . . . . . . . . . . . . . . 120
13 Reinsurance 121
13.1 General reinsurance parameters . . . . . . . . . . . . . . 122
13.2 Proportional Reinsurance . . . . . . . . . . . . . . . . . 134
13.3 Non-Proportional Reinsurance . . . . . . . . . . . . . . 137
13.4 Reinsurance Programs . . . . . . . . . . . . . . . . . . . 141

CONTENTS 3
14 Modelling non-life reserves 149
14.1 Calendar Year Method . . . . . . . . . . . . . . . . . . . 150
14.2 Pay-out pattern method . . . . . . . . . . . . . . . . . . 151
15 ALM generators 153
16 Modelling an Insurance Group 155
16.1 Company Segments . . . . . . . . . . . . . . . . . . . . . 156
16.2 Internal Processing of Data . . . . . . . . . . . . . . . . 162
III Developer Guide 167
17 Introduction 169
18 Development environment 171
19 Modularization 173
20 Working on existing plugins 175
20.1 Releasing a plugin . . . . . . . . . . . . . . . . . . . . . 176
20.2 Running it all together . . . . . . . . . . . . . . . . . . . 176
21 Creating your own plugin 177
21.1 Git Hints . . . . . . . . . . . . . . . . . . . . . . . . . . 178
21.2 Environments . . . . . . . . . . . . . . . . . . . . . . . . 178
21.3 User Management . . . . . . . . . . . . . . . . . . . . . 179
22 Scalability 181
22.1 Application Structurue Revisited . . . . . . . . . . . . . 181
22.2 GridGain . . . . . . . . . . . . . . . . . . . . . . . . . . 183
22.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . 183
22.4 Conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . 184
23 Writing business logic: Components 187
23.1 Step-by-Step Component Example . . . . . . . . . . . . 187
23.2 Step-by-Step Example of ComposedComponent . . . . . 189
23.3 Arbitrary Number of Equal Components . . . . . . . . . 192
23.4 Filtering and Allocation . . . . . . . . . . . . . . . . . . 194
23.5 Diﬀerent Behaviors . . . . . . . . . . . . . . . . . . . . . 195
23.6 Accessing External Information . . . . . . . . . . . . . . 199
23.7 Period Store . . . . . . . . . . . . . . . . . . . . . . . . . 199

4 CONTENTS
23.8 Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
24 Testing Business Logic 203
24.1 Purposes and forms of Testing . . . . . . . . . . . . . . 203
24.2 Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 203
24.3 Model Tests . . . . . . . . . . . . . . . . . . . . . . . . . 205
Bibliography 209

Chapter 1
Introduction
Solvency II can be seen as a driver for RiskAnalytics, but it is cer-
tainly not the only one. In general, it is the trend towards embedding
the quantitative output of actuarial and risk management models in
operative processes. This requires more than just correct calculations.
Issues that are becoming more important are: ‘where did the input data
come from?’, ‘who owns the data and who has the right to edit the data
– or to sign it off?’, ‘how do we get the input data in an operationally
safe way into the modeling tools?’, ‘how do we get the output data out
of the modeling tool for reporting?’, ’is the used version documented?’,
‘can an auditor or a regulator review the complete solution efficiently?’,
etc. In short, we forsee that actuarial and risk management applica-
tions will have to reach the same level of reliability, integration and
security as financial applications.1
Most actuarial modeling tools cover only the quantitative aspects of
actuarial models. RiskAnalytics strives to provide a sound base for
a more complete risk management or Solvency II solution. The quan-
titative aspects of the Solvency II framework – ‘Pillar One’ – gave the
software suite its name. But PillarOne.RiskAnalytics, or in short
RiskAnalytics, is more than just an actuarial calculation engine. Au-
ditability, security and process support, which are necessary for ‘Pil-
lar Two’ in the Solvency II framework are also part of RiskAnalytics.
1Not long ago, the financial statements of a group of companies was consolidated
using spreadsheets and copy-pasting information from back and forth. While many
risk management applications still rely on this approach, nobody could imagine not
using professional consolidation software these days.
7

8 CHAPTER 1. INTRODUCTION
‘Pillar Three’ of the Solvency II framework involves disclosure and
transparency, which is related to reporting standards. The calculation
engine of RiskAnalytics can provide the data for internal as well as
external reporting, using industry-standard interfaces for professional
reporting.
PillarOne was initiated at the end of 2007 and sponsored by Mu-
nich Re. Apart from Munich Re, Intuitive Collaboration and Canoo
provided major resources for the developement of the software.
In a nutshell, PillarOne can be characterized by
• Transparency is a major value in risk management. PillarOne
provides the ultimate transparency: all methods and implemen-
tations are licensed under an open source licence (GPL v3) which
guarantees that anybody can get unrestricted access to the de-
scriptions of the used methods and their implementations. Any-
body is allowed to change or extend the implementation. The
only thing which the GPL license forbids is to sell the whole or
parts of the source code or to wrap it in a product with a com-
mercial license.
• IT Standards are virtually nonexistent in most actuarial tools.
PillarOne is a welcome exception since it is built on top of
broadly accepted Java enterprise software components for database
handling, client-server communication, security, etc. In short,
RiskAnalytics is a true enterprise application.
• Flexibility is required for a platform to cover a broad spectrum
of applications. RiskAnalytics makes no assumptions about the
time resolution of models, the level of detail to be modeled, or
which output data will be collected. As a result, RiskAnalytics
can be used for a broad spectrum of quantitative insurance mod-
els, including risk capital or Solvency II models, reinsurance opti-
mization, portfolio or deal valuations, proﬁt testing . . . to mention
a few.
Beyond the non-functional, or architectural, requirements mentioned
above, RiskAnalytics oﬀers a number of cool usability (and other)
features. We mention a few below, with links to further elaborations
for those with whetted appetites.

9
• Compare: The user can simultaneously textually compare two
or more simulation results2
and/or their parametrizations3
.
Compare Graphics: The user can compare results graphically
within a given result set4
. Smoothing algorithms are provided.
• Seamless clipboard integration: Clicking on the top left cell
of a result section selects all of its data, which can then be copied
to the clipboard and pasted to a spreadsheet application with
standard menu commands or keyboard shortcuts5
.
• Dockable tabs: Within the application window, multiple tabs
can be open simultaneously, but only one tab is active at a time.
Dockable tabs allow each tab to be undocked into its own window,
or subsequently returned into the main application window, thus
enabling the user to view and interact with multiple aspects of the
modeling domain in parallel – for example, to compare or copy
data side-by-side; or to open the comments-window separately on
the screen wherever you like.
• Validators: Custom ‘callback’ functions implementing buisiness-
specific ‘rules’ can be written and easily pushed/deployed to ad-
here to enterprise policies or to enforce data integrity at the time
of entry.
• Comments
• Multi Company Model (MCM)
• Batch runs
• Views
•
•
•
2compare simulation results by first left-clicking them while pressing the Ctrl key
to select them, next right-clicking anywhere in the shaded selection to invoke the
context menu, and, finally, clicking on the compare option
3by clicking on the compare parametrizations option from within the result com-
parison
4compare (claims) distributions is invoked in a similar fasion
5e. g., right-clicking for the context menu, using the Edit menu, or using the
keyboard shortcuts Ctrl-c and Ctrl-v directly to copy and paste, respectively

Chapter 2
Getting Started
Following the instructions in this chapter gets you from a to z within
a short time. But only from little a to little z – the remaining chap-
ters cover the A to Z for RiskAnalytics. To stick with the illustra-
tion, RiskAnalytics knows many different font types, even more than
openly available. In this manual, however, we are able to cover only a
few. Please get in touch for more details about more fonts, i.e. how to
use RiskAnalytics in a variety of environments such as solvency and
pricing, life and non-life, direct and reinsurance, one- or multi-period
models: contact@pillarone.org
RiskAnalytics comes in two flavors: A stand-alone version which can
be installed on a laptop or PC and a server version which is required for
an enterprise solution. Since PillarOne is based on Java technology,
it runs on Windows, Unix/linux and MacOS X. In the client-server
version, the client can run a different OS than the server.
Laptops have become fairly powerful, but their disks are significantly
slower than those on servers. Hence, we recommend the standalone
version for evaluation, for development and for anybody who works
more or less alone on a modelling project or has no access to a server
infrastructure, e. g. consultants on the road.
If you just want to have a first glimps at RiskAnalytics, then you
can also play with the client-server version on our test environment on
pillarone.org/pillarone/try-it-online.1
1Be aware that this is a test environment; we may restart the server, clean the
database and restrict the number of users or the number of iterations per user.
11

12 CHAPTER 2. GETTING STARTED
2.1 Installing the standalone version
The standalone version is suitable to be installed on a laptop or desk-
top computer with at least 1 GB of RAM and several GB of harddisk
space – needed for handling the results of your simulations properly
including all details as per your specification. It comes in an abso-
lutely self-contained installer and, apart from the typical client-server
components, it is identical to the client-server version.
The following steps describe how a standalone version can be installed.
1. Download the latest version from pillarone.org.
Note: If you have an earlier version of RiskAnalytics installed,
you will need to update (uninstall and reinstall) some plugins. . . If,
however, you will no longer need the parameters and results from
the earlier installation, you might want to simply and completely
uninstall the earlier installation and rightafter install the new ver-
sion.
2. Install
2.1.1 Database environments
In the standard setup, PillarOneRiskAnalyticscomes with an already
up and running database. No customization needed. Just use it.
However, if you want to use another database, the following gives a first
introduction: By default there is support for two different embedded
databases: mysql (recommended) and derby. Which one will be used
depends on the script used to start risk analytics. These databases are
started and stopped together with RiskAnalytics, which means that it
is not possible to access the database externally when the application
is closed.
If required it is also possible to run the application with an installed
MySQL database (version 5.1 or newer is required). The database must
be accessible at localhost:3306 (3306 being the standard port). A
database called p1rat must be created as well as user with name and
password p1rat with the necessary privileges for the before mentioned
table.
The database and the user can be setup with the following commands:
create database p1rat;
create user ’p1rat’@’localhost’ identified by ’p1rat’;

2.2. INSTALLING THE SERVER VERSION 13
grant all on table p1rat.* to ’p1rat’@’localhost’;
grant file on *.* to ’p1rat’@’localhost’;
This would be sufficient to use RiskAnalytics with a standalone mysql,
however for acceptable performance a script which will setup parti-
tioning and indices should be executed. It can be downloaded at
RiskAnalytics/src/java/mysql.sql
The database is now ready for Risk Analytics. To use this database
with Risk Analytics it is necessary to edit the start script RunRisk-
AnalyticsMySql.cmd and replace -Dgrails.env=mysqlembedded with
-Dgrails.env=mysql
2.1.2 Reset the database
To discard all changed data including results just remove the database
directory in the pillarone temporary directory, which is ~/.pillarone
by default, but can be changed during the installation process. If not
using the embedded mysql, but an installed one, just re-run the script
used to initialize the database.
2.1.3 Accessing results directly
If you want to access the results directly they are saved in the table
single value result. Only mysql can be accessed from outside the
application (because derby runs in the same JVM). Keep in mind that
when you want to access the results from the embedded mysql database
(which runs on port 3307), RiskAnalytics must be running.
2.2 Installing the server version
This will give you a much more powerful set-up, but we recommend that
you do this only if you have ample experience in dealing with server
based installations or if you have a test server at your disposition.
Prerequisits:
• A servlet container, e. g. Tomcat. No need for a fully fledged
middleware.
• A database, e. g. mysql. Note that you may have to edit the
datasource information in the file DataSource.groovy2
.
2Groovy is an open-source scripting language based on Java. See their homepage

14 CHAPTER 2. GETTING STARTED
2.3 Your first simulation
Start RiskAnalytics by either opening the sandbox model from our
server or the already installed version (as explained above). The re-
leases include some demo models and we will use one of them now to
verify that the installation is properly working. In the left pane, expand
the Podra model and you should see the three subitems: Parameters,
Result templates and Results.
Screenshot3
Open the parameters section, right-click on a parameterization that you
want to base your simulation on, and then select run simulation. This
opens the simulation tab and sets the parametrization from which you
launched this view. You now want either to keep the suggested result
template or make your own choice. For the first test run, entering
a value between 100 and 1000 in the number of iterations will be an
appropriate choice before clicking on Run.
Screenshot4
Now lets have a look at the result section. Open the result of the most
recent simulation. There are many ways to look at the data: tables,
graphics, comparison of results. You will find out more on your personal
excursion through your first simulation.
Screenshot5
2.4 A mini result analysis: MRA
If you want to have a look at the tiniest – still meaningful – model
possible, we got something for you: MRA. Consisting of hard-wired
elements such as: one underwriting segment, one claim generator for
attritional claims and one proportional reinsurance contract.6
bls bls blup
or [10] for more information.
3TODO: of the application as it opens
4TODO: of the simulation page
5TODO: result analysis context menu, one or two examples
6TODO: We need such a model and description

Chapter 3
The command line
3.1 Overview
There is a way to run simulations without using the user interface. The
command line application oﬀers the same simulation settings as the UI
and the results are saved to the same database, which means that the
results can later be viewed in the application (if the command line is
run with the same environment).
3.2 Starting the Command Line Interface
(CLI)
The command line application is located in the RiskAnalytics subfolder
of the installation directory. The general syntax is: java [JAVA-OPTIONS]
-jar org.pillarone.riskanalytics.core.cli.RunSimulation.jar [CLI-OPTIONS]
3.2.1 JAVA-OPTIONS
The following Java options should be set:
• -Xmx1024m Sets the maximum heap space to 1024MB. Depending
on the simulation options, it should also run with less memory,
but 1024M should be enough for everything.
• -XX:MaxPermSize=256M Sets the PermGen memory size to 256m.
15

16 CHAPTER 3. THE COMMAND LINE
• -Dgrails.env=environment Sets the grails environment within
which the simulation is run. This mainly defines where the results
are saved to. Possible options are: mysqlembedded: Uses a mysql
database which is started before, and stopped after the simula-
tion. mysql: Uses a already running mysql instance (must run on
localhost:3306, db: p1rat, user: p1rat, pw: p1rat). standalone:
Uses an embedded derby database.
3.2.2 CLI-OPTIONS
The CLI-OPTIONS define the simulation input parameters (the equiv-
alent of the simulation configuration page)
• -parameterization <path>
<path> is the parameterization file which should be used for the
simulation
• -resultConfiguration <path>
<path> is the result configuration file which should be used for
the simulation. The model class must be the same as the param-
eterization file.
• -force (optional)
By default the parameterization and the result template is not
imported if one with the same name already exists. Use this
option to force the import of the files.
• -iterations <number>
The number of iterations to run.
• -name <name>
The simulation name.
• -comment <comment> (optional)
A comment for the simulation run.
• -seed <number> (optional)
The random number generator seed to use for this simulation.
• [-dboutput | -fileoutput <file> | -nooutput]
One of these options must be given. -dboutput saves the results
to the DB defined by the given grails environment. -fileoutput
saves the results to a file and -nooutput does not save any results
at all.

Chapter 4
The user interface
When opening the RiskAnalytics application the user interface ap-
pears as depicted in Figure 4.1. The user interface is aranged in differ-
ent functional areas that are described in Sections 4.1–4.5.
4.1 Menu
4.1.1 File menu
The file menu (cf. Figure 4.2) is used for all regards concerning parametriza-
tion files.
The following commands are available in this menu:
• Run simulation . . . As soon as a parameter file of any model is
opened this command becomes available and starts the dialogue
to run a simulation.
• Refresh reads the current state of the underlaying database and
displays all stored model information in the navigation pane (cf.
Section 4.4).
• Save When an open parametrization or result template is changed
this command becomes enabled in order to save the current mod-
ifications. The standard shortcut STRG + S can also be used
instead.
• Save All works as the proir command except that it saves all
modified parametrizations or result templates.
17

18 CHAPTER 4. THE USER INTERFACE
• Export all Parametrizations (newest version) to folder Since RiskAnalytics
can handle different versions of a parametrization this commant
can be used for only exporting the latest version to a specified
folder.
• Export all Parametrizations to folder In contrast to the previous
function all versions of all parametrizations are exported here.
• Import all Parametrizations from folder This function can be used
in order to import all parametrizations from a specified folder.
4.1.2 Window menu
Without any data opened the Window menu (cf. Figure 4.3) only con-
tains the menu entry Settings where the language of the user interface
can be changed. If parametrizations, result templates or results are
opened the according model is also listed in this menu. Since the data
pane only shows data that belongs to one model this helps to keep track
of the data that is currrently worked on if several models are involved.
4.1.3 Help menu
The menu Help (cf. Figure 4.4) contains the entry About RiskAnalytics
where you can get information about the version, license, credits, used
libraries and system properties.
4.2 Shortcuts
The shortcuts bar contains the most important functions of the File
menu namely
• Refresh
• Save
• Run Simulation . . .
The functions are explained in detail in Section 4.1.1.

4.3. FRAME SELECTION PANE 19
4.3 Frame selection pane
This part of the user interface helps hiding panes that are currently not
needed in order to maximize the space on the screen for the relevant
panes. In its initial state only the navigation pane (cf. Section 4.4)
can be hidden. When using data validation and comments on the data
more options become available in this pane.
4.4 Navigation pane
In the navigation pane all the data processed in RiskAnalytics is
structured in a tree. The tree’s top layer contains all available models
(e. g. Podra) as well as a node called Batches that will be explained
later in this section. The logical structure within all diﬀerent models is
identical thus, when expanding a model by pressing the plus sign next
to its name, the following folders become visible:
• Parametrization
• Result templates
• Results
Since RiskAnalytics is based on the data-driven-modelling paradigm
a parametrization does not only contain pure data but also parts of the
model structure itself. The model itself provides the components that
generally can be proccessed during a simulation run such as claims
generators or underwriting segments. The parametrization deter-
mines the number of the respective components as well as the actual
numerical and type values of the components.
In contrast to the parametrization the result templates are structure-
wise fully determined by the model itself.
4.4.1 Parametrization
When expanding the Parametrization folder all parametrizations that
are available for this model are listed at this place. In some cases a
plus sign is visible next to the parametrization name. This indicates
that diﬀerent versions of a model are available. Right-clicking on the
folder Parametrization opens a context menu
In following fuctions are available:

• Export All cf. file menu.
• Export All (newest versions) cf. file menu.
• Import Select a parametrization file and import it into the database.
If a parametrization is identical to a parametetrization that al-
ready exists in the database no new version is created.
• Import (force) Identical to the previous command except that the
parametrization is imported at any case. If an identical par-
manetrization already exists a new version with identical values
is generated.
• Import all from folder This command imports all parametrization
files from a specified directory into the respective model.
• Run simulation cf. file menu.
• Create default parametrization creates the empty default parametriza-
tion of the current model.
• Delete all deletes all parametrizations of the current model.
Some operations are only available for specific parametrizations. Thus,
the options in the context menu slightly change when right-clicking a
specific paramentrization (cf. Figure 4.6).
In following fuctions are available:
• Open opens the paramerization in the data pane.
• Delete removes the selected parametrization from the database.
Note that a parametrization can only be deleted if no result has
already been generated with it. Other wise you will be asked if
all results based on this parametrization should also be deleted.
• Export cf. file menu.
• Rename opens a dialogue in order to change the name of the
parametrization and all depending versions.
• Run simulation cf. file menu.
• Save as saves the current parametrizations under a different parametriza-
tion name.

4.5. DATA PANE 21
• Create new version If a specific version of the parametrization
should be kept, a new version can be generated keeping the old on
in its current state. If the user wants to open a used parametriza-
tion either it can be opened in read only mode or opened by
generating a new version that is editable again.
• Compare If two or more parametrizations should be compared
they can be selected using the CTRL key. Then the compare
option becomes enabled. The lines in the parametrizations that
differ in structure or in numerical values are highlighted.
4.4.2 Result templates
The resulte template section is very similarly structured as the parametriza-
tions section. Result templates are used in order to determine in depen-
dently from a parametrization what results should be collected during
the simulation and to what granularity. Result templates provide an
easy way to get comparable results for different parametrizations. The
use of templates guarantees that the same type of single result val-
ues are collected without having to specifying it again and again for
different parametrizations.
All available options for dealing with result templates can be seen in
Figure 4.7 that shows the according context menu. The functions are
analogous to the ones of parametrization that are described in Sec-
tion 4.4.1.
The functions that are available in the context menu for a specific result
template are identical as the one for a parametrization thus we refer to
Section 4.4.1 for explanations.
4.4.3 Results
4.5 Data pane

Figure 4.1: Areas of the user interface
Figure 4.2: Expanded ﬁle menu.

4.5. DATA PANE 23
Figure 4.3: Expanded window menu.
Figure 4.4: Expanded help menu.
Figure 4.5: Context menu attached to the Parametrizations folder.
Figure 4.6: Context menu attached to a speciﬁc single parametrization.
Figure 4.7: Context menu attached to the Result templates folder.

Chapter 5
A partial internal model
for a non-life insurance
company: Podra
The Podra Model1
serves two purposes. First, it is a fairly powerful
non-life, primary insurance risk model which can be used as a partial
internal Solvency II model. Second, it can be used as a starting point
for developing custom models – a topic which is taken up in more
advanced sections. The Podra model is a typical representative of a
dynamically extendable model (see the classification of models in REF
TO DO2
). We will use it here for two reasons. Firstly, because we
can build a custom model with a reasonable, pre-defined structure laid
out by an expert, without any programming. And secondly, because it
is a fully published model – i. e., one can reproduce each of the steps
below after downloading the release – making the first section below
an effective tutorial.
Its components are the gross portfolio (underwriting information and
claims generators), the company structure and the reinsurance covers.
Its output provides a good basis to analyize capital at risk, premium,
provisions and claims on different levels. Possible uses are risk analyses,
portfolio optimization and reinsurance structuring.
Please refer to a workshop held in September 2010 in St.Gallen for
1PillarOne Dynamic Reinsurance Analysis[3]
2TODO:
25

26CHAPTER 5. PARTIAL INTERNAL NON-LIFE MODEL PODRA
illustrative examples on pillarone.org
Note: The Podra model is a data-driven model which can be easily
extended by simply adding input data for new claims generators, un-
derwriting segments, etc. The price for this flexibility is performance.
If this flexibility is not needed, then there are ways to build models with
the same business logic which have about half the runtime of an equiv-
alent dynamic model.
5.1 Step by step
The first step is to open the application and select the Podra model.
Within the Podra model, we wish to start from scratch. Hence we
use the context menu within Podra on ‘Parametrisations’ (right-mouse-
click) to create a new default parametrisation. You will find some more
parametrisations within Podra/Parametrisations as examples. Screen-
shot3
Afterwards, name the newly created parametrisation and open it
via the context menu of the parametrisation itself.
In the right pane the (empty) model is shown.
The available segments that can be entered into the model are Under-
writing, Claims Generators, Correlations, Lines of Business and Rein-
surance Program.
Underwriting Information As a first step the underwriting infor-
mation should be feeded into the model. Within the Underwriting con-
text menu there is a button add. Name the new Underwriting segment.
Within the segment, the data can be edited by doubleclick.
The underwriting information contains: maximum sum insured, aver-
age sum insured, premium and number of policies. It is possible to edit
serveral risk bands (they will be used for surplus share treaty reinsur-
ance). Add as many Underwriting segments as you like.
Underwriting information is optional to some extent and can be either
attached to a claims generator (see below) where it can be used for
skaling of distributions or as exposure information for surplus reinsur-
ance contracts; or it can be attached to a Line of Business where it is
used to4
.
3TODO: example parameterizations
4TODO: please explain

5.1. STEP BY STEP 27
Figure 5.1: Podra underwriting information example
Claims Generators The next step is the editing of Claims Genera-
tors. Context menu add creates a new claims generator. Compared to
the underwriting information a claims generator is more complex. It
contains the claims model, the exposure information association, and
the underlying underwiting information.
For the claims generator the type of the claims generator can be se-
lected: Attritional, Frequency Severity and many more. Depending on
the selection there are different ways to define the claims generator ap-
propriately. The model starts with drawing a claim from the selected
claims generator. If a surplus share treaty will be contained in the rein-
surance program, the second step is the allocation of an exposure (sum
insured, pml, eml) to the drawn loss. Therefore the option to selecting
the exposure information allocation can be used.
The combo box ‘claims generator is based on’5
is used to scale the ran-
dom distributions by underwriting information from the underwriting
segments. If no underwriting is provided or applicable, a given fixed
value absolute van be selected.
Correlations Claims generators may interact, or, in other words,
correlate. Correlations can be introduced by adding a Correlations
Matrix using the Context Menu Add of dependencies on the right
pane.
Reserve generators The reserve generators can be introduced like
claims generators. The reserve generators component allows for adding
reserve generators for a certain segmentation. It contains the reserve
5TODO: check name

Figure 5.2: Podra claims generator example

Figure 5.3: Podra reserve generator example
development (paid plus reserved) distribution possibly with modifiers.
Additionally the recent year payment portion can be specified to allow
for very simple reserve development modelling. Furthermore the initial
reserves can be specified directly in this component. Within a multi
period model the outgoing reserves of claims generators can be linked
to the reserve component, resulting in increasing the reserve volume of
future periods by the amount of the outgoing reserve of the preceding
period.
Lines of Business Now the risks are defined and may be combined
or allocated on business segments. These are defined in the Line of
Business area. Here again, it is possible to add another Line of Busi-
ness. The next step is to add different Claims generators (or shares
of them) to the dedicated Line of Business. Additionally, to each Line
of Business the Underwriting Information is attached, so we can select
this additionally.
Reinsurance Program Individual Reinsurance covers can be added
to the Reinsurance Program section. The reinsurance cover consists of
a contract (including the type), the inuring priority (see further below),
the covered lines of business, as well as the covered claims generators.
The covered lines of business and the convered claims generators are
sent to the reinsurance contract to be covered.

Figure 5.4: Podra reinsurance contract example
The inuring priority provides the information when a specific contract is
used and from which level e. g. the GNPI is taken. For the reinsurance
program itself the type has to be specified. Depending on the type
there are several options for the necessary parameters.
Result configuration Usually, not all possible result variables are
generated and stored during a simulation run. This is for performance
and disk space reasons. Within the Podra model several result config-
urations can be defined. By opening a result descriptor in the right
pane a tree view with the available output variables is shown. On each
output variable a collection type can be selected. To make a result
variable available in the result set, it should be collected as aggregated
or drill downref to new section6
. This output variables will be found
in the Results after a simulation has been done.
Screenshot7
Evaluation / Simulation On Parameters and Result Descriptors
within the left tree view it is possible to start simulations using the
context menu. The Parameter set and the Result Descriptor to be used
have to be selected in the Simulation window on the right pane. The
simulation run can be started after adding the number of simulatons
6TODO: please include ref
7TODO: Result Configuration

and optionally the random generator seed. The Results of the Podra
model will contain your result set thereafter.
Open the result set to see which variables have been generated. On the
result variables different risk measures (exactly different functionals)
can be displayed by pressing the appropriate buttons. The diverse op-
tions for evaluations include expected value, standard deviation, value
at risk and tail value at risk for a given level of security8
. The full set –
or any branch of the tree – can be copied to the clipboard by selecting
the top element of the branch or tree respectively and pressing ctrl-c.
Screenshot9
Given the model has been evaluated twice with different parameters
the results can be compared using the compare feature selectable in the
treeview. Deviations in all result variables can be shown in absolute
and relative form. Sensitivity tests of paramerters can be done easily
using this feature.
Screenshot10
8TODO: confirm wording
9TODO: Evaluation - simulation
10TODO: Compare

Chapter 6
Non-life risk modelling
for Insurance Groups
The “Multi Company Model” is an extension of the Podra model: It
consists of the same components and hence may serve the same pur-
poses for risk modelling of non-life business of direct insurers; its main
qualification however is to picture the activities of a group of insur-
ance companies, culminating in an additional component that allows
for the assignment of the modelled technical structure to the predefined
business structure. The motivation for providing the extended group
model with RiskAnalytics goes back to statutory requirements per-
taining to group solvency in addition to the regulatory provisions to
which the individual insurance company must comply, and also from a
different point of view namely neither a solo approach or nor a consoli-
dated approach. For a more detailed discussion of group modeling and
related references we point to Chapter 16.
Parametrization
In a first step, we open the application and select the MultiCompany
model12
. The steps for creating a new parametrization correspond to
the outline in Chapter 5, for the sake of convenience however we re-
1The model has to be enabled in the Config.groovy file by adding it to the list of
configuration variable models Add multicompany and restart RiskAnalytics.
2TODO: Where is the description for editing the Config.groovy file?
33

34 CHAPTER 6. RISK MODELLING FOR INSURANCE GROUPS
capitulate the procedure. Within the parametrization menu there are
two tested examples called Three Companies and LE-CRTI (legal
entities and their capital and risk transfer instruments). that may
be used for analysis purposes with or without changing/modifying/ex-
tending the default input parameters. As outlined for Podra, you may
either create a new parametrization or import a .groovy parameter file
by right-clicking on Parameterization and selecting the operation
from the context menu. The newly created (or any other) parametriza-
tion is opened by left double-clicking on it or, as a second possibility,
right-clicking and selecting the Open function in the context menu.
At this stage the model pops up in the right panel listing all the com-
ponents coming with the model, compare Figure 6.1. The model is
similar to Podra with slight extensions in the components Lines of
Business, Reinsurance Market (corresponding to Reinsurance in
Podra), and ALM Generators that are related to the additional com-
ponent Companies; altogether turning Podra into a model suited for
the analysis of group risks. Next, we shortly introduce the new compo-
nent and outline the resulting modifications for the components already
known from Podra.
New component Companies. This component allows to feed into
the model a group of contractual partners of the business lines under
consideration. A new company segment is added by right click on
Companies, selecting the button Add and entering the name of the
(new) insurance company into the pop-up window. Alternatively, an
existing company may be duplicated under a new name by right click
and selecting the button Duplicate.
As illustrated in Figure 6.1 within the company segment, an insurance
rating value3
may be selected for each company from a list with range
between AAA and D and default value No Default.
Modified component Lines of Business. As in Podra we here
define the business classes and relate them to the previously speci-
fied components Underwriting, Claims Generators and Reserve
Generators. In contrast to Podra the single segments show an addi-
tional parameter Company allowing to attach to the dedicated line
of business the associated insurance company by selection from the list
3At present the selected value has no impact on the simulation results.

35
of predefined companies.4
. Note that the whole purpose of Lines of
Business is to manage information that is obtained from other compo-
nents, in other words, the information from other components is sent to
the segments of Lines of Business, filtered according to appropriately
defined rules and re-dispatched to the Reinsurance Market or/and
result descriptors.
Modified component ALM Generators. The component ALM
Generators is extended in the same way as Lines of Business: The
associated company must be attached to the dedicated ALM segment
by selection from the list of predefined companies.
Modified component Reinsurance/Reinsurance Market. Ex-
pectedly, segments of Reinsurance Market distinguish from seg-
ments of Reinsurance in Podra by an additional parameter Reinsur-
ers. Here, the selection of one of the predefined companies is optional
in contrast to the two aforementioned components. Moreover, as rein-
surance treaties may be shared between multiple reinsurers, the user
may enter as many companies as he wants (sensibly up to the num-
ber of insurances in component Companies) together with the signed
share of the treaty. As usual, this kind of parameter may be filled by
double-clicking in the cell attached to Reinsurers.
Result configuration
Due to performance and disk space reasons not all possible result vari-
ables are generated and stored during a simulation run. Analogous to
Podra, within the “Multi Company Model” several result configurations
can be defined. By opening a result descriptor (there is one predefined
template named Aggregate Overview 3, right click on it and select
open) a tree view with the available output variables is shown in the
right pane. On each output variable a collection type can be selected.
For a more detailed overview of various result descriptors we refer the
reader to Chapter 8. Results that are specifically shown for the various
company segments are described in full detail in Chapter 16.
4Note that the lines must be related to a predefined company unless the com-
ponent Companies is kept empty, in which case MultiCompany is identical to
Podra

Simulation/Evaluation
Simulations are started by right clicking on Parameterization or Re-
sult templates. Selecting start simulation in the appearing context
menu the simulation window opens in the right panel. After selecting
the dedicated parametrization, result template and number of itera-
tions the simulation run can be started.
Open the result set to see which variables have been generated. On
the result variables diﬀerent risk measures can be added by pressing
the appropriate buttons. The options for evaluations include expected
value, standard deviation, value at risk and tail value at risk for a given
level of Note: check, pleasesecurity. Any branch of the result tree can
be copied to the clipboard by selecting the top left cell of the branch
and pressing Ctrl-c.
If the model has been evaluated more than once, with diﬀerent parame-
ters, the corresponding result sets can be viewed side-by-side using the
compare feature selectable in the tree view. Deviations in all result
variables can be shown in absolute and relative form. Sensitivity tests
of parameters can be done easily using this feature; see Section 8.4.5
5TODO: Adjustment of bold font for terms in Parametrization.

37
Figure 6.1: Multi Company Model

Chapter 7
Life insurance cash flow
model
The ”Life insurance PillarOne cash flow model” is yet another of the
public available models for RiskAnalytics. It allows modeling the
needs of a life insurance office with respect to a portfolio of unit-linked
life insurance contracts (policies) and a traditional financing life rein-
surance treaty.
The major objective is to model the future cash flows for a life insur-
ance company for pricing (profit testing), valuation and planning pur-
poses (incl. embedded value calculations). The cash flows for the vari-
ous stakeholders (policyholders, distribution channels, expenses, funds
management, reinsurance, taxes, etc.) are calculated.
This chapter describes the functionalities of the PillarOne life insurance
cash flow model from an end-user perspective. Throughout the chapter
a concrete example is used to describe and illustrate the parameters,
functionalities and results derived with RiskAnalytics.
With this open life insurance model, the following parameters can be
described:
• Actual expenses (both company and product-based),
• reinsurance conditions,
• actual model points (existing portfolio) and future business,
• product parameters/characteristics,
39

40 CHAPTER 7. LIFE INSURANCE CASH FLOW MODEL
• demographic assumptions (mortality, disability, lapses),
• economic and solvency assumptions,
• distribution channel commissions, and
• banking expenses.
Looking forward, RiskAnalyticsis also enable to implement useful
stochastic calculations for life insurance in an open available model.
7.1 Introduction
Based on the existing PillarOne software an extension (so-called ”Life
insurance PillarOne cash flow model”) has been built to model the
needs of a life insurance office with a portfolio of unit-linked life in-
surance contracts (policies) and a traditional financing life reinsurance
treaty.
To model the life insurance cash flows with the various stakeholders the
following elements need to be considered, as illustrated in figure 7.1.
At the very beginning there was a concrete project with the need to
perform future cash flow projections of a life insurance company for
pricing (profit testing), valuation and planning purposes (incl. embed-
ded value calculations). The life insurance PillarOne application has
then been developed with the following main objectives:
• Perform cash flow projections on a shorter (e.g. 3 years for plan-
ning purposes) as well as a longer (e.g. 20 years for embedded
and appraisal value calculations) term horizon
• Consider an existing portfolio as well as model future new busi-
ness
• Determine the shareholders’ profitability for the modeled business
• Appropriately consider and analyze the reinsurance treaty (e.g. costs
of financing, pay-back period)
• Apply profit testing techniques on life insurance products and
analyzing LoBs
The components of the PillarOne life insurance calculations and work-
flow can be characterized with chart 7.2.
The building blocks are:

7.1. INTRODUCTION 41
Figure 7.1: Stakeholders’ view of Life Insurance
• Cash flow projection calculation engine for a simple life insurance
policy
• Weighted by actual demographic and lapse experiences
• Aggregation on all policies on entire portfolio
• Consideration of reinsurance cash flows
• Storage of results in a database enabling to derive all kind of
statistics (report-generator, key figures): EV and VIF, new busi-
ness margin, IRR, break-even analysis before/after reinsurance,
perform planning with future new business, sensitivities, etc.
• Consideration of an entire range of assumptions and conditions.
This chapter describes the functionalities of the PillarOne life insurance
cash flow model from an end-user perspective. Throughout the chapter
a concrete example is used to describe and illustrate the parameters,

Figure 7.2: Life Insurance Workflow Calculations and Workflow
functionalities and results derived with the software. The GUI (graphic
user interface) enables to enter a whole range of assumptions and con-
ditions. With a well structured and modular end-user interface all the
necessary input parameters can be captured.
This chapter of the manual is structured in the following way:
• In the next section 7.2 the (high-level) framework of the used
example is presented.
• In subsequent sections the input, calculations and results/output
are described in detail.
• At the end, in section 7.7, we will deal with potential future
development of this life insurance PillarOne cash flow model.
This documentation is based on an illustrative example which includes
the (direct) life insurance (a company with a portfolio of unit-linked
policies) with an associated reinsurance treaty. If there is no interest
in the reinsurance section, one could simply exclude the reinsurance by
setting the quota share reinsurance parameters to 0. All the calcula-
tions and results are done and derived on a deterministic basis.
Please note: The example in this documentation should only be seen
as an illustration. In other words: The parameters, content and result
of this example cannot directly be used in the practical work without
considering further input reflecting the company specific characteris-

7.2. EXAMPLE 43
tics, concrete products, appropriate demographic and economic envi-
ronment, etc.
7.2 Example
When downloading and installing RiskAnalytics you directly get a
preinstalled life example. In this chapter, we will discuss this example
at length. We provide illustrative numbers only and you are free to
change whatever you want.
7.2.1 Product characteristics
We will model three unit-linked products: Two periodic premium prod-
ucts which are designed for different commission payments (com5 and
com4 for e.g. different distribution channels) and a single premium
product. We will denominate the products with ULPPCOM5, ULPP-
COM4 and ULSPCOM5. We will work only in CHF. However, the life
model would also allow capturing segregated currency-pots to reflect
different currencies by converting the data into CHF.
From the gross premium (premium paid by the policyholder) the ex-
penses and charges are deducted. The remaining saving premium is
then added to the actual funds value (saving or funds accumulation
process). To describe the actual products (so-called pricing or ”1st or-
der” basis) we use the following parameters for the expense and cost
structure:
• Acquisition expenses (alpha): 5% of the present values of the paid
premiums, which are amortized over the first 10 policy years
• Collection expenses (beta): between 7% and 8% of the periodic
premium
• Proportional administration expenses (gamma): 0.05% (for peri-
odic premiums) or 0.25% (for single premium) p.a. of the funds
value
• Fixed administration expenses (kappa): between CHF 50 to CHF
100 per policy p.a.
• Costs for mortality risk premium: Monthly calculated according
to the sum at risk in case of death and the pricing mortality table
according to age and gender of the policyholder

• Costs for waiver of premium: Monthly calculated according to
the sum at risk in case of disability and the pricing waiver of
premium table according to waiting period, age and gender of
the policyholder
• Surrender charges: For the periodic premium products 100% of
the funds value linearly falling to 0% of the funds value over the
first 5 policy years.
The following risk benefits could be defined and set at policy level:
• Sum at risk in case of death could be defined as:
– a fixed CHF-amount less the actual funds value and/or as
– a percentage of the sum of the paid premiums.
• Waiver of premiums for the periodic premiums with various wait-
ing periods (e.g. 6, 12 or 24 months).
The expense loadings and costs are either deducted from the (peri-
odic) premium payments or from the funds of the policy. Similarly
the mortality and disability costs (”1st order” risk premiums according
to mortality and waiver of premium tables) are periodically deducted.
The calculations are done on a monthly basis.
7.2.2 Distribution channel commissions
There are two commission payment types or ”scales” (COM5 and COM4):
Either 5% or 4% of the sum of premiums (total paid premiums over
the entire policy duration, but the policy duration will be capped at a
maximum of 25 years). The commissions are paid upfront. However,
in case of policy surrender they have to be refunded (”claw-back”) by
the distribution channel (agent) linearly, in proportion within the first
three policy years; i.e. only after three years the commissions are
fully earned. A general shortfall of the claw-back payment of 2.5% is
assumed. Finally, a portfolio commission of 0.05% p.a. of the mathe-
matical reserves (funds value) will be paid out on a monthly basis.
7.2.3 Actual expenses
The actual expenses (”2nd order” parameters) could be defined on a
company basis and/or on a product-related basis. In addition the ex-
penses could also be linked to inflation. In our example we do not

7.2. EXAMPLE 45
assume total company expenses (no expense over-run). We have actual
initial expenses between CHF 200 and CHF 350 per policy. The actual
administration expenses are varying between CHF 150 and CHF 225
p.a. The expenses are depending on the policy size (sum of total paid
premiums).
7.2.4 Actual demographic assumptions
For the actual mortality (”2nd order”) various, product-related prob-
ability tables could be defined and used. Similarly for the disability
(waiver of premium) and the lapses actual probability tables are as-
sumed in the example. In our example the actual mortality and dis-
ability probability rates are 80% of the pricing assumptions.
7.2.5 Reinsurance section
According to the reinsurance treaty conditions, common or general rein-
surance parameters need to be defined for all the products:
• Various settlement dates and intervals
• Deposit interest rate of 0.25% and reinsurance profit participation
of 90%
• Loss carried forward for all past underwriting years (amounts and
interest rates) and for various currencies separately
• Reinsurance claw-back percentage of 100% and ’cost and risk an-
nual supplement on ceded premium’ of 2%, etc.
Product specific reinsurance parameters - which need to be entered -
are:
• The currency (CHF) and reinsurance quota share percentage of
50%
• Reinsurance acquisition commission of either 5% or 4% of the sum
of the reinsured premiums (total paid premiums to reinsurance
company over the entire policy duration). However, the policy
duration will be capped at a maximum of 25 years. We will have
a (linear) amortization of the reinsurance acquisition commissions
over the first eight years.

• Percentage (25%) of the reinsured beta and kappa expenses which
the reinsurance company will pay (refund) to the insurance com-
pany.
7.2.6 Model point data
The actual portfolio and future sales can be defined:
• The actual portfolio is described policy by policy (policy #, prod-
uct, annual premium, installments p.a. , gender, birth-date, pol-
icy inception date, duration, death benefits, waiver of premium,
actual funds value/mathematical reserves, etc.)
• Similarly, model points (representatives) for future policy data
(sales) can be defined.
• The future sales (number of policies) can be entered for these
model points (representatives) on a monthly basis for the next 10
years, as from the projection start.
In our example the insurance company sold policies only during the
year 2009 (i.e. we have a given portfolio as per 31.12.2009) and the
company plans to sell future new business for the years 2010 to 2012.
Our projection will start as per 1.1.2010 and will be done on a monthly
basis for 254 months, i.e. for more than 20 years.
Finally, some global and economic parameters can be defined. We use
in our example:
• Solvency I: 1% of the funds value, 0.3% of the sums at risk in
case of death, and 20% of the disability risk premiums.
• Banking fees and income: An income (”kick-back”) of 0.25%
of the funds value (rate p.a. , but monthly calculated and ac-
crued), custody expenses of 0.05% of the funds value (rate p.a. ,
monthly accrued), and transactions costs of 0.25% of the net buy-
sell amount (monthly).
• Economic assumptions: Discount rate of 7.5%, risk free rate of
1.5%, investment return on funds of 5%, inflation on expenses of
1%, taxes on statutory result of 25%, initial shareholder capital
(allocated to the specified portfolio and new business) of CHF 1
Mio.

7.3. INPUT PARAMETERS 47
Please note that the end-user could define and implement (parameter-
ize) with this life insurance PillarOne model any number of products,
expense types, demographic assumptions, etc. We simply limited this
example for practical discussion purposes to three illustrative products,
etc.
The above, high-level description of the example will accompany us
during the subsequent sections and illustrate the various parameters
and results (input and output) which we will discuss. When reading
this end-user documentation it would probably be best to have the life
insurance PillarOne model open on your PC with the given ”standard”
parameters of our example.
7.3 Input parameters
Various parameters need to be entered: Product descriptions, company
and distribution channel information, actual portfolio and future busi-
ness (planning) data, reinsurance descriptions, details on demographics
and economics, etc. as illustrated in figure 7.3
7.3.1 Actual expenses
The end-user can define two kinds of expenses: Overall company ex-
penses to reflect the complete expense structure of the company (a.o. used
in embedded value type of calculations) or product related expenses to
reflect the cost-intensiveness of the different kind of products (e.g. used
for profit-testing calculations). Of course one could also define both
kinds of expenses in the same model (e.g. to capture the expenses-over-
run).
Please note that all the expense definitions in this section are referring
to actual expenses (”2nd order”, outgoes) and do not necessarily need
to be directly related to the ”1st order” expenses (pricing, loadings) of
the various products.
Company expenses
The company expenses are characterized by:
• ”company overhead expenses”: Have to be entered in an absolute
amount (CHF) for every month of the envisaged projection period
(40 years or 480 months). However, for our model example we
set all the company overhead expenses equal to 0.

Figure 7.3: The input screen for mentioned parameters

• ”apply inflation on company overhead expenses”: One has to
indicate whether the company expenses need to be indexed with
inflation (true/false).
Product expenses
For all the defined products, expenses need to be entered separately.
To add a product ’right click’ on the ”product expenses” tab and add
a new product. Various expense types (absolute in CHF per policy,
initial and administrative (i.e. annually recurring) as well as policy-
size dependent expenses) need to be defined. We use the ”ulppcom5”
product as example. For the other two products similar parameters are
entered.
• ”product”: ”ulppcom5” needs to be entered this is required for a
clear product/expense allocation required, otherwise the program
is failing).
• ”fixed administration expenses per policy per annum”: We define
them at CHF 100, which in the calculation are then broken down
on a monthly basis.
• ”apply inflation on fixed administration expenses per policy”: To
define whether the expenses need to be indexed with inflation.
• ”fixed initial expenses per policy”: We define them at CHF 100,
to capture e.g. the initial underwriting expenses. These expenses
are charged only once at the beginning.
• ”apply inflation on fixed initial expenses per policy”: To reflect
whether future new business have unchanged initial expenses or
whether these expenses are indexed with inflation.
• ”variable expenses per policy”: We can enter any number (by
changing the ”row count”) of classes for policy sizes in CHF.
Policy size = annual premium times premium payment duration.
Depending on the policy size the ”administration expenses per
policy p.a. ” and ”initial expenses per policy” can be defined.
In our example we allocate (in addition to the above mentioned
fixed expenses) for policies with a sum of premiums below CHF
200’000 administration expenses per policy of CHF 30 p.a. and
initial expenses per policy of CHF 50. For policies with a sum of

Figure 7.4: Variable expenses per policy
premiums of CHF 200’000 or more the administration expenses
are CHF 50 and the initial expenses CHF 100, cf. figure 7.4
In our example the product expenses for the other two products are
very similar to ”ulppcom5”. However, in the real world the expenses
can if necessary be entered with much more sophistication.
7.3.2 Reinsurance
Every underwriting year and currency will be separately treated (ac-
counting series with different conditions; i.e. with separate loss carried
forward amounts and loss carried forward interest rates).
For each settlement period a profit & loss calculation for the reinsurance
is made:
• It consists of
– the ceded reinsurance premium (ceded expenses and costs),
plus
– the surrender claw-back and
– the extra deposit investment income.
• This is reduced by
– the reinsurance commissions (initial and running/recurring),
and
– death and waiver of premium benefits (sums at risk).

• The initial loss (financing via the initial reinsurance commission)
will be carried forward and increased by an interest rate plus an
administrative charge (”Cost and Risk Annual Supplement on
Ceded Premium”). In case that we have a profit, the reinsurer
pays a profit participation to the insurance company.
Please note that saving premiums as well as the surrender payments
need not to be part of the above calculation in case that the funds
remain with the insurance company and are not passed to the reinsurer.
Furthermore, the administrative charge to the reinsurer and the loss
carried forward interest rates are not directly paid by the insurance
company to the reinsurer, but only notionally allowed for in the profit
& loss calculation by increasing the loss carried forward.
The end-user needs to define two kinds of parameter groups for mod-
eling the reinsurance:
• Overall company reinsurance conditions to reflect the general
treaty characteristics (”common reinsurance”)
• Product specific reinsurance parameters to reflect the various
reinsurance conditions (quota share, commissions, amortization/-
payback) on a product level.
Common reinsurance
In this section we enter the general reinsurance treaty characteristics:
• ”First Settlement Period Begin Date”: Enter the beginning of a
month date as from which on the reinsurance calculation should
start. This has to be in-line with the amounts entered under ”loss
carried forward”. We have a US-date format; i.e. MM/DD/YY.
• ”First Settlement Period Ends Before”: This date defines the
duration of the (first) settlement period. Could be e.g. 3 months
after the begin date (in case of quarterly reinsurance settlements).
However, in case we wish to have monthly results (as in our exam-
ple), we enter one month after the begin date (format: MM/D-
D/YY).
• ”First Settlement Date”: Needs to be at least one day after the
above end date (format: MM/DD/YY).

• ”Settlement Interval in Months”: Defines the time for interval of
the settlements periods. In case of quarterly reinsurance settle-
ments we would set 3 months.
• ”Extra Deposit Interest Rate”: The extra interest rate (p.a. ) on
the reinsured funds values (saving accounts) which the insurance
company will pay to the reinsurer (e.g. to pass a part of the ”kick-
back” to the reinsurer). The calculation is done based on the
average fund values over the specified period ”Month Count for
Average Fund Value” (see below). In case of quarterly settlements
we might take the average fund value over the last 4 end of months
(e.g. for end 31.12., 31.1., 28.2. and 31.3.). In our example we
will, however, calculate for every month the average fund value
(begin/end of month) as the basis for the calculation of the extra
deposit interest.
• ”Profit Participation”: The participation (in our case we have
90%) which the reinsurer pays to the insurance company in case
that the loss carried forward becomes positive.
• ”Loss Carried Forward Rates”: Here we define for every un-
derwriting year and currency separately the loss carried forward
amounts and loss carried forward interest rates) shown in figure
7.5. In the past the insurance company in our example sold only
policies during the year 2009 with a loss carried forward amount
(due to the reinsurer) of CHF 147’493. The interest rate which
will be used also in future accounting years for the underwriting
year 2009 is 10%. We need to specify for all the desired future
years (with new business) the loss carried forward interest rate
(in our example in addition to 2009 for the years 2010 to 2012;
i.e. we set the row count = 4). Of course one could have (e.g. due
to different economic situations) in the past different loss carried
forward interest rates or going forward one would like to plan the
new business with different loss carried forward interest rates.
• ”Claw Back Percentage”: In case of a lapse for a given policy
the insurance company will in our example immediately amortize
for this policy all the non-amortized initial reinsurance commis-
sions (i.e. we set the claw-back percentage = 100%). The non-
amortized reinsurance commissions are determined in the follow-
ing way:

Figure 7.5: Loss Carried Forward Rates
– Initial reinsurance commissions paid by the reinsurer,
– minus part of the initial reinsurance commissions which have
been paid back by the insurance company before the lapse
of the policy,
– minus administration and unit expenses as well as the risk
premiums ceded by the insurance company to the reinsurer,
– minus extra deposit investment income ceded for this policy,
– plus/minus (the balance of) the acquisition commissions which
have been reallocated over time
– plus the administration and unit expense running commis-
sions paid by the reinsurer.
For a more detailed understanding of the parameters, see also
next section.
• ”Month Count for Average Fund Value”: The calculation for the
average fund value should be in-line with the settlement interval
(see also above). In our example we simply assume a monthly
calculation and we take the average fund value (begin/end of
month; i.e. we set the month count equal to 2).
• ”Cost and Risk Annual Supplement on Ceded Premium”: The
loss carried forward will be increased by an additional admin-
istrative charge (”Cost and Risk Annual Supplement on Ceded
Premium”: In our example it equals 2% of the ceded premiums).

Product specific reinsurance
For all the products we need to define a separate section (use the same
name as under the ”products” section) and enter the reinsurance pa-
rameters, in particular: The reinsured quota share of the premium,
the payment of the reinsurance acquisition (initial) commission, the
reinsurance treatment of the recurring expenses as well as the amorti-
zation/payback. In case that a product is not reinsured, we simply set
the quota share equal to 0. To add a product simply ’right click’ on
the ”product specific reinsurance” tab and add a new product.
We use the ”ulppcom5” product as example:
• ”product”: ”ulppcom5” needs to be entered (this - somehow re-
dundant information - is required for a clear product allocation).
• ”currency”: The currency of the product has to be selected.
• ”quota share”: A number in the range of 0 to 1 has to be entered.
In our example we have a 50% quota share reinsurance; i.e. 50%
of the original premium is paid to the reinsurer.
• ”truncated policy duration”: To determine the truncated sum
of premiums (SOPtrunc) the policy duration (in years) is ”trun-
cated” on our example at 25 years, in case the premium payment
duration is larger. If no truncated duration is required on could
e.g. enter 99 years (”lifelong”), or more.
• ”reinsurance acquisition commission”: We can define for various
classes (= row count) of premium payment durations (in years)
the four acquisition commission parameters A, B, C, D. In our
example we only have one class (row count = 1), i.e. for all the
premium payment durations we apply the same parameters. (In
our example we define the class relating to all the premium pay-
ment durations > 0; i.e. we capture all the policies because they
have a premium payment duration which is greater than zero.)
However one could define a row count > 1 and input for various
premium payment durations a separate set for the four acquisi-
tion commission parameters. (To determine which row or class
of parameter set has to be applied: Premium payment duration
is ≥ the indicated values. Of course, in this input table the listed
premium payment durations need to be in strict increasing order.)
Lets use the following abbreviations:

– QS: quota share
– SOP: sum of premiums (over the entire premium payment
duration)
– SOPtrunc: sum of premiums over the truncated premium
payment duration
– A, B, C, D: acquisition commission parameters for a given
premium payment duration
We further define:
”reinsurance acquisition commission” =
max(A; min(B; C + D/(QS × SOP))) × QS × SOPtrunc
Given the values in our example (A=0.05 and B=C=D=0) we
therefore have for all the premium payment durations a reinsur-
ance acquisition commission of 5% of 50% of the truncated (at
25 years) sum of premiums. This is an illustrative and simple
assumption; however, the parameters allow a more sophisticated
parameterization if required.
• ”fixed and beta expenses”: To compensate for the larger admin-
istration work done by the insurance company, the reinsurer pays
back to the insurance company a percentage of the fixed (kappa)
and beta expenses he receives1
. The paid-back percentage is equal
to: 1 − min(A; B + (QS × SOP)/C), where A, B and C are the
parameters for the reinsurance expenses. QS and SOP defined as
above. The Parameter C is a kind of calibration for the SOP and
needs always to be set > 0 (otherwise we would have an error
due to a division by 0), also in the case where QS is equal to 0%.
Please note that for the ”fixed and beta expenses” parameters
the row count has always to be equal to 1. Given the values in
our example (A=B=0.75 and C=1) the reinsurer therefore pays
back 25% of the received fixed (kappa) and beta expenses to the
insurance company.
• ”amortization of acquisition commission in years”: This parame-
ters defines the ”acquisition commission reallocation over time”.
The policyholder has to amortize the charged acquisition commis-
sion over a given period (in our example: 10 years; see later in
the section 7.4 about ”products”). However, the amortization of
1The reinsurer receives the quota share of the original fixed (kappa) and beta
expense loadings.

the reinsurance acquisition commission does not necessarily need
to be done over the same period. In our example we have defined
8 years, i.e. we have to reallocate in a different cash flow pattern
the amortization of the acquisition commission and the insurance
company will pay 1.25 (=10/8) of the original acquisition com-
mission loading times the quota share to reinsurer. However, one
could also imagine another example where the amortization of the
acquisition commission for the reinsurance has a longer duration
than the amortization in the original product. In such a case the
reinsurer would pay-back in a first phase a part of the received
acquisition commission to the insurance company. Please note
that the calculation of the amortization patterns assumes that
the sum of the original acquisition commission loadings (paid by
the policyholder) times the quota share is equal to the sum of the
loadings of the reinsurance acquisition commission.
For the other two products similar parameters are entered. Note please
that there is no reinsurance for the single premium product ”ulspcom5”
(quota share = 0).
7.3.3 Model points and projection starting date
Policy data
In this section we describe the existing portfolio: In our example the
portfolio consists of 100 policies which have been sold in 2009. The so-
called model point (one line in the policy data table) represents one sold
policy. We need to enter the following policyholders’ information, which
in general can (automatically) be extracted from the administration
system:
• ”Policy #”: This could be a number to identify the policy.
• ”Product”: The identifier used in the products section to denom-
inate the product.
• ”Annual Premium”: The amount of the gross annual premium or
of the single premium paid by the policyholder. (If 0 is entered,
the policy is not considered.)
• ”Alpha”: represents the acquisition commission loading paid by
the policyholder. In our example for all the policies α is equal to

5% of the present value of premiums or of the sum of premiums.
However, because in the life insurance model this parameter does
not depend from the product description, one could also imag-
ine that the policies could have variable acquisition commission
loadings.
• ”Installments pa”: The annual installments, e.g. monthly (12),
quarterly (4), half-yearly (2) or annual (1).
• ”Gender”: ’male’ or ’female’.
• ”Birthdate”: In the format YYYY-MM-DD.
• ”Policy Inception Date”: In the format YYYY-MM-DD.
• ”Premium Payment Duration [Years]”: The original payment du-
ration in the policy contract. e.g. for single premium the premium
payment duration is equal to 1.
• ”Policy Duration [Years]”: The original policy duration in the
contract.
• ”Risk Sum (relative)”: In case of death of the policyholder the
funds value (mathematical reserves) plus the ”risk sum (relative)”
will be paid-out. The ”risk sum (relative)” is expressed as a factor
of the sum of premiums.
• ”Minimal Death Benefit”: An absolute amount (in CHF), which
will at least be paid-out in case of death of the policyholder.
In case that the funds value (mathematical reserves) is larger
than the minimal death benefit, only the funds value will be paid
out. The sum at risk is equal to the difference (≥ 0) between
the ’minimal death benefit’ and the funds value (mathematical
reserves).
• ”Waiver of Premium Covered”: ’false’ or ’true’.
• ”Waiver of Premium Waiting Delay”: We have in our disability
tables values for 6, 12 and 24 months of waiting periods. In case
that no waiver of premium is covered, set this value equal to 0.
The sum at risk is calculated as the risk free discounted value of
premiums after the waiting period.

• ”Mathematical Reserves”: The actual reserves are usually ex-
tracted from the administration system and calculated for date as
per the projection start date (in our example as per 31.12.2009).
Projection starting date
In our example we define the begin of the first period with 1.1.2010 (In-
put: DD/MM/YYYY). We have an existing portfolio as per 31.12.2009
and we assume for three years going forward future new business (i.e. for
2010 – 2012).
Future policy data
With the row count we define the number of future model points. In
our example we have three model points; i.e. one for each of the three
products. This describes the kind of policies sold in future. (For this
open available life model, the input (= row count) is limited to 20 model
points.) Of course, one could also define several and different policies
(model points) for one product to capture and reflect the characteristics
of the product for some particular parameters:
• ”Model Points”: The model points are denoted with MP1, MP2
and MP3, etc.
• ”Product”: The identifier used in the products section to denom-
inate the product.
• ”Annual Premium”: The amount of the gross annual premium
paid by the policyholder.
• ”Alpha”: α represents the acquisition commission loading paid by
the policyholder. In our example for all the policies α it is equal
to 5% of the present value of premiums or of the sum of premiums.
However, because in the life insurance model this parameter does
not depend from the product description, one could also imag-
ine that the policies could have variable acquisition commission
loadings.
• ”Installments pa”: The annual installments, e.g. monthly (12),
quarterly (4), half-yearly (2) or annual (1).
• ”Gender”: ’male’ or ’female’.

• ”Age”: Age of the policyholder in years when the policy will be
sold (in future).
• ”Premium Payment Duration [Years]”: The original payment du-
ration in the policy contract. e.g. for single premium the premium
payment duration is set equal to 1.
• ”Policy Duration [Years]”: The original policy duration in the
contract.
• ”Risk Sum (relative)”: In case of death of the policyholder the
funds value (mathematical reserves) plus the ”risk sum (relative)”
will be paid-out. The ”risk sum (relative)” is expressed as a factor
of the sum of premiums.
• ”Minimal Death Benefit”: An absolute amount (in CHF), which
will at least be paid-out in case of death of the policyholder.
In case that the funds value (mathematical reserves) is larger
than the minimal death benefit, only the funds value will be paid
out. The sum at risk is equal to the difference (≥ 0) between
the ’minimal death benefit’ and the funds value (mathematical
reserves).
• ”Waiver of Premium Covered”: ’false’ or ’true’.
• ”Waiver of Premium Waiting Delay”: We have in our disability
tables values for 6, 12 and 24 months of waiting periods. In case
that no waiver of premium is covered, set this value equal to 0.
The sum at risk is calculated as the risk free discounted value of
premiums after the waiting period.
Of course, policies which are sold going forward do not have mathe-
matical reserves to be considered at the beginning of the projection (as
we have in the existing portfolio – see above). The model points for
the future policy data should represent in a reasonable way the char-
acteristics (types) of the policies which are sold in future. The number
of sold policies (model points) is entered in the next session.
Products
The number of sold policies need to be defined by starting in period 0
(this corresponds to the starting of the projection; i.e. to January 2010
in our example): Month by month, for up to 120 periods or 10 years the

Figure 7.6: Future business - entering number of sold policies (by model
points and months)
number of sold policies (as defined above by the model points - future
policy data) can be entered. (Please note that in the open available life
model, the row and column counts can not be changed.)
For the next 3 years we expect in our example total (future) sales of 900
policies for the three products (model points): 200 policies in 2010, 300
policies in 2011 and 400 policies in 2012. With the existing portfolio we
therefore capture and model 1’000 policies in total. This is illustrated
in figure 7.6.
7.4 Input parameters
The following parameters are the core input to describe the products,
through these characteristics of the unit-linked policies. Combined to
these unit-linked products one could also have death benefits and waiver
of premium insurance. These coverages are not further described here;
they are captured on a per policy basis in the policy data description
(see above). However, the costs for these coverages are either charged to
the premium or to the actual funds values (saving account or component
of the product).

One can define as many products as desired, also by using meaning-
ful, internal names: We describe subsequently the parameters of the
(first) product ”ulppcom5” (periodic premium payment and linked to
commission payment rule ”com5”):
• ”Products”: ’Right click’ on ”products” and add a new product
by entering the desired name; in our example ”ulppcom5”.
• ”currency”: Choose the desired currency
Acquisition expenses alpha (α):
• ”alpha calculation base”: The calculation base for the acquisition
commission loading α (which is defined in the model points -
policy data section) could either be the present value of premiums
PV or of the sum of premiums SOP.
• ”technical interest rate for present value of premium”: The tech-
nical interest rate i which is used to calculate the present value
of premiums is in our example 1.75%. The total acquisition com-
missions AC charged to the policyholder are therefore:
AC = α × PV or AC = α × SOP
The AC are amortized over a duration m1 or m2 depending on
various conditions (for the policy duration n and for the annual
premium AP):
• ”alpha threshold policy duration in years”: This is denoted with
T(n) and is in our example 10 years.
• ”alpha threshold annual premium”: This is named with T(AP)
and is in our example CHF 1’000.
• ”alpha amortization time in years min”: This is denoted with m1
and is in our example 10 years.
• ”alpha amortization time in years max”: This is denoted with
m2 and is in our example 10 years. With t we denote the actual
policy year (from 1 to n) and with µ the number of the annual
installments [e.g. monthly (12), quarterly (4), half-yearly (2) or
annual (1)].

The acquisition commissions ACt charged in year t (charged against
the actual premium payment) are then defined by:
ACt =



AC
u · ä
(u)
m1|
if [n < T(n) or AP > T(AP)] and t ≤ m1
AC
u · ä
(u)
m2|
if [n ≥ T(n) and AP ≤ T(AP)] and t ≤ m2
0 otherwise
and where
ä
(u)
t|
=
1 − vt
d(u)
, v =
1
1 + i
, and d(u)
= u · [1 − (1 + i)−1/u
] .
With i we denote the technical interest rate. In our example we
have simplified assumptions where the AC are always amortized
over a fixed period of 10 years (m1 = m2 = 10). The threshold
for the annual premium T(AP) does basically not play a role in
the above formulae. Finally, the product design makes only sense
if the policy duration is at least 10 years (i.e. no policies with a
policy duration n < 10 should be sold).
Collection expenses beta (β):
During the premium payment period the beta expenses β in proportion
to the periodic premium are charged to the policyholder. With the 5
beta parameters (A, B, C, D and E) various cost structures can be
modeled. We define: β = min(A + max(B; (n − C) × D); E), where n
is the policy duration. In our example we have beta expenses varying
between 7% and 8% of the premium:
• ”beta a”: Is set equal to 0.07
• ”beta b”: Is set equal to 0
• ”beta c”: Is set equal to 15
• ”beta d”: Is set equal to 0.001
• ”beta e”: Is set equal to 0.08

Proportional administration expenses gamma (γ):
During the entire policy duration the gamma expenses γ in proportion
to the funds value are charged (by reducing the funds value respectively
the mathematical reserves). In our example we charge 0.05% p.a. of
the funds value.
• ”gamma1 of mathematical reserves”: Is set equal to 0.0005 p.a.
• ”gamma2 of mathematical reserves”: Is set equal to 0 p.a.
We have two gamma parameters. With gamma2 one could e.g. model
a bonus parameter or a kick-back refund to the policyholder by setting
a negative parameter (negative charge). Please note that the gamma
expenses are calculated at the beginning of every month and charged
on a monthly basis; i.e. the above gamma parameters are divided by
12.
Fixed administration expenses kappa (κ):
During the entire policy duration the (annual) kappa expenses κ in
CHF are charged to the policyholder at the beginning of every month
(i.e. 1/12). With the 5 (periodic premium products) respectively 6
(single premium products) kappa parameters (A, B, C, D, E and F)
various cost structures can be modeled.
We deﬁne for the periodic premium products: κ = min(A+max(B; (n−
C)×D); E), where n is the policy duration. And for the single premium
products (i.e. premium payment duration = 1 year): κ = min(A +
max(B; (n × SP/F − C) × D); E), where SP is the single premium.
In our example we have kappa expenses varying between CHF 50 and
CHF 100 p.a. :
• ”kappa a”: Is set equal to 50
• ”kappa b”: Is set equal to 0
• ”kappa c”: Is set equal to 15
• ”kappa d”: Is set equal to 2.50
• ”kappa e”: Is set equal to 100
• ”kappa f”: Is set equal to 0 (as it is n/a for the ”ulppcom5”
product)

Other parameters:
• ”surrender charge of funds”: In case of a surrender a penalty
(charge) in proportion to the funds value is charged to the poli-
cyholder depending on the elapsed time. A variable scale can be
entered. In our example we have a monthly linearly falling charge
(from 100% to 0%) over the first 5 policy years. However, one
could also define a flat (constant) surrender percentage over the
entire policy duration.
• ”mortality table pricing”: The desired mortality table has to be
selected. The risk premium (1/12 of the q(x)) is charged at the
beginning of every month (reduction of policyholders’ funds).
• ”mortality table actual”: The desired mortality table has to be
selected.
• ”waiver of premium pricing”: The desired waiver of premium ta-
ble has to be selected. The risk premium (1/12 of the i(x)) is
charged at the beginning of every month (reduction of policy-
holders’ funds).
• ”waiver of premium actual”: The desired waiver of premium table
has to be selected.
• ”lapses”: The desired lapse table has to be selected.
• ”distribution channel selection”: The desired commission pay-
ment type or ”scale” has to be selected (according to the required
distribution channel remuneration, etc.)
For the other two products similar parameters are entered.
7.4.1 Demographics
Mortality
Two mortality tables have been defined, for pricing purposes and for
actual outcomes:
• ”bfs mort19982003”: Derived from BFS-data (Bundesamt fuer
Statistik) a pricing mortality table with ultimate q(x) for male
and q(y) for female has been entered (to import the data into
PillarOne: simply use copy/paste from Excel).

• ”bfs actual”: The mortality table with the actual values has been
defined as 80% of the pricing mortality table.
For pricing purposes the risk premium charges are determined accord-
ing to the ”age last birthday”. For actual valuation purposes the mor-
tality is calculated by interpolating (i.e. ”exact”).
The end-user can define the size of the table and at which age the
table should start. There are no limits with respect to the number
of mortality tables (and also other tables, e.g. for disability, lapses,
commissions, etc.) one would like to define. To create a new table
simply ’right click’ on ”mortality table” tab and add a new table. For
example one could define a different mortality table for every product.
Disability
Two disability tables have been defined, for pricing purposes and for
actual outcomes (as they are derived from the ”Invaliditaetsstatistik
1996/2000 in der schweizerischen Kollektivlebensversicherung”, SAV
Bulletin 2/2004):
• ”waiver of premium”: Disability table for pricing purposes for
both gender (i(x) and i(y)) and 3 waiting periods of 6, 12 and 24
months, cf. figure 7.7
• ”waiver of premium actual”: This disability table has been cal-
culated as 80% of the pricing disability table.
For pricing purposes the risk premium charges are determined accord-
ing to the ”age last birthday”. For actual valuation purposes the dis-
ability rate is calculated by interpolating (i.e. ”exact”).
The end-user can define the size of the table and at which age the
table should start. There are no limits with respect to the number of
disability tables.
Disability is modeled as an event terminating the policy, like death or
surrender. In case of disability, the policyholder receives his savings
(funds value) at end of month plus the risk free discounted value of
premiums after the waiting period. No reactivations are modeled.
Lapses
Various lapse rate tables have been defined, e.g.:

Figure 7.7: Waiver of premium table for pricing
• ”lapse rate1” (the ’main’ table in our example for the periodic
premium products): To reﬂect that in the 6th year the lapse
rate is increasing again for the periodic premiums because of the
discontinuation of the surrender charge (after 5 years).
• ”lapse rate2”: With continuing falling lapse rates for the single
premium product.
Various other tables have been created for testing purposes (for example
for calculation with one policy): e.g. to simulate ”no lapse”, ”surrender
in year2” or ”surrender in year5”.
7.4.2 Economic assumptions
Further, simple parameters (not e.g. interest curves, remain constant
over the entire projection period) can be entered in the economic as-
sumptions section:
• ”risk discount rate”: 7.5%
• ”risk discount rate sensitivity”: not used
• ”risk free rate”: 1.5%
• ”investment return on funds”: 5.0%

• ”inflation on expenses”: 1.0%
• ”company tax on statutory results”: 25.0%
• ”initial share holder capital”: CHF 1’000’000
7.4.3 Solvency assumptions
Only the capital requirements under the Solvency I regime are modeled
in this life insurance PillarOne model to compute the minimal solvency
capital which is locked-in. In our example we set 100% of the standard
solvency parameters:
• ”solvency margin on mathematical reserves”: 1.0%
• ”solvency margin on sum at risk”: 0.3%
• ”solvency margin on disability premium”: 20% of the annualized
disability (waiver of premiums) risk premiums
The values are calculated at the end of every month.
7.4.4 Distribution channel commissions
Various distribution channels can be defined: ’Right click’ on ”distri-
bution channel commissions” and add a new commission section by
entering the desired name; in our example ”com5”. For ”com5” we
define the following parameters:
• ”acquisition commission”: In our example the insurance company
pays an acquisition commission of 5.0% of the calculation base.
The calculation base could either be the present value of premi-
ums or of the sum of premiums. The acquisition commission is
fully paid out in the month when the policy is sold (i.e. upfront
at the policy inception date).
• ”acquisition commission base”: In our example we select ”sum of
premiums” as calculation base.
• ”discount rate for present value of premiums”: The interest rate
which is used to calculate the above mentioned present value of
premiums. In our example we do not use it.

• ”apply max duration”: We have to select whether or not the
policy duration is capped (or ’truncated’).
• ”max duration in year”: In our example the policy duration will
be capped at a maximum of 25 years.
• ”portfolio commission annualized”: In our example the insurance
company also pays out a portfolio commission of 0.05% p.a. of
the ’mathematical reserves’ (”portfolio commission base”). The
payment is done on a monthly basis (i.e. 1/12).
• ”portfolio commission base”: Is the ’mathematical reserves’ (no
selection possibility).
• ”claw back share”: In case of a surrender the acquisition commis-
sion has to be refunded (”claw-back”) by the distribution channel
(agent) to the insurance company (”non-amortized” part of the
initial or acquisition commissions due by the agent). A variable
(row count) claw-back scale can be entered. In our example we
have a linearly falling claw-back share within the first 3 policy
years (or 36 months). Only after the first 3 years the acquisition
commissions are fully earned.
• ”shortfall of claw back”: Additionally we can define a shortfall of
the claw-back payment; i.e. when the distribution channel fails to
pay back the due part of the acquisition commissions. A probabil-
ity table for the shortfall of claw-back can be entered. (Variable
size of the table is being defined with the row count.) In our
example we assume a general (flat: row count = 1) probability of
shortfall of 2.5% of the claw-back share for all the months.
For the distribution channel commission ”com4” we have the same
input except for the ”acquisition commission”: 4.0%. This could be
justified if e.g. the administrative work done by the insurance company
is varying between the different distribution channels or for various
products.
7.4.5 Banking
The banking transactions are creating additional expenses or other in-
come. We have three types of parameters which can be used to simulate
these effects:

7.5. RUNNING CALCULATIONS 69
• ”other income annualized” (”kick-back”): In some circumstances
the banks are paying a fee to the insurance company (”kick-back”)
to compensate for the various investment processes. In our exam-
ple we assume that the insurance company will get 0.25% p.a. (or
25 bp) of the funds value. The model, however, calculates and
accrues the ’other income’ on a monthly basis (i.e. 1/12).
• ”fund custody expenses annualized”: In our example we assume
for the insurance company fund custody expenses of 0.05% p.a. of
the funds value. These expenses are also calculated and accrued
on a monthly basis (i.e. 1/12).
• ”fund loaded transaction costs”: Finally, in our example, we
also have modeled transaction costs of 0.25% of the net buy-sell
amount (monthly) which the insurance company will have to pay
(0.25% of the monthly change in reserves).
7.5 Running calculations
For doing the calculations there are a few parameters which need to
be entered. Usually the simulation settings are defined by the newest
version of the parameters as illustrated in figure ??:
Important is – in addition to the version of the parameters – the defi-
nition of the duration of the projection (simulation) to start the calcu-
lation of the projections:
”Number of Periods” (in months):
We do (”only”) one run respectively a projection with 254 periods or
months (because of exporting the results with ”copy/paste” into the old
Excel which has only 256 columns). This corresponds to a projection
period of over 21 years. However, one could do without problems also
projections over 40 years or 480 periods (the Excel 2007 version has
enough columns to import this directly).
One could also prepare several runs and start them on a batch-basis
(e.g. over night) to do various calculations and analysis with no further
input and manual interventions.
The run times need to be analyzed for models with larger portfolios.
However, our small portfolio and calculation/projection over 21 years
needed approximately 15 seconds of computation time on an older lap-
top PC.

Figure 7.8: Calculation settings

7.6. RESULTS AND OUTPUT PRESENTATION 71
7.6 Results and output presentation
In this section we comment the results which are presented with a
standard Profit & Loss grid for the statutory net income and some
portfolio information (balance sheet, key figures). The results can easily
be imported into an Excel spreadsheet (”copy/paste”). The results are
illustrated in figure ??
The various positions are presented on a monthly basis; i.e. we calcu-
late and see monthly results. During the year, the data is accumulated
(i.e. the model shows ”year-to-date” information) and at the beginning
of a new year the data start again from zero. One can therefore easily
read from the output the quarterly or half-yearly information and of
course the year-end (December columns). One can ’click’ (drill-down)
on the various profit & loss items and in general one receives a detailed,
technical split (”internal view”) of the elements. Positive figures de-
note an income for the insurance company, negative figures an outgo.
Therefore a positive net income is a profit and a negative net income
is a loss.
7.6.1 Income
The income consists of premiums, investment and other revenues.
Premium
The total premium is directly segregated (presented) into the following
(technical) elements:
• saving premium: Paid premium less the alpha, beta and kappa
expenses.
• alpha: The acquisition commissions which are charged to the
policyholders.
• beta: The beta expenses (collection expenses) which are charged
to the policyholders.
• kappa: The fixed administration expenses (kappa) which are charged
to the policyholders.

Figure 7.9: Results of the calculations (projections)

Investment income
The total investment income is equal to the investment income on the
policyholders’ funds:
• ph funds: Investment income on the policyholders’ funds.
• sh assets and claims reserves: These amounts are not calculated
(Investment income on shareholders’ funds is not presented in the
profit & loss statement; see also comment under net income).
Other income
The total other income includes the portfolio transfer:
• other: Other income respectively ”kick-back” paid by banks.
• portfolio transfer: In the first month of the projection the math-
ematical reserves at the start of the projection.
7.6.2 Outgo
The outgo consists of insurance benefits, commissions paid, expenses,
change in reserves, reinsurance outgo/income and taxes. These ele-
ments are explained in the following sections.
Insurance benefits
The total insurance benefits are the amounts paid to the policyholders.
The payments are financed by reducing the reserves (policyholders’
funds) or by the risk premium payments (which are also financed at
the beginning of every month by reducing the policyholders’ funds).
• death: Payment in case of death according to the actual mortality
table.
• waiver of premium: This (disability) is modeled as an event ter-
minating the policy, similar to a surrender. In case of disability,
the policyholder receives his savings at end of month plus the risk
free discounted value of premiums after the waiting period.
• surrender: Surrender benefit which is paid to policyholders (please
note that the surrender charge is reduced from the policyholders’
funds and flows as an income to the insurance company).

• terminal benefit or maturity payment: The funds value which will
be paid to policyholders when the policies expire.
Commissions paid
The commissions paid relate to the distribution channel and include
all the commission types plus the claw-back less the shortfall of the
claw-back:
• acquisition: Initial commission payment to the distribution chan-
nel in the month of the policy inception.
• portfolio: The ongoing portfolio commission payments.
• nominal clawback: The ”non-amortized” initial or acquisition
commissions (”claw-back”) which are due from the distribution
channel in case of a lapse. This is an income for the insurance
company and has a positive sign.
• clawback shortfall: The shortfall of the above.
Expenses
The total expenses are the actual expenses (”2nd order”) and include
company and product expenses as well as the banking costs:
• company overhead
• fixed initial per policy
• fixed admin per policy
• variable initial per policy
• variable admin per policy
• banking transaction costs
• banking custody expenses

Change in reserves
The total change in reserves consists in negative (outgo) and positive
(income) items for the insurance company:
• saving premium: Same amount (but with negative sign) as the
saving premium under income.
• kappa: Fixed administration expenses (”1st order”), positive amount
(part of the kappa expenses which cannot be deducted from the
premiums, e.g. for single premium products).
• gamma1: Proportional administration expenses (”1st order”),
positive amount.
• gamma2: Proportional administration expenses (”1st order”),
positive amount.
• risk premium for death: Risk premium charged to policyholders
(”1st order”).
• risk premium for waiver of premium: Risk premium charged to
policyholders (”1st order”).
• investment income: Corresponds to the investment income on the
policyholders’ funds (see above, but with negative sign).
• death benefit: Reserves which become free due to deaths of poli-
cyholders (positive amount).
• surrender benefit: Reserves which become free due to surrenders
of policyholders (positive amount).
• waiver of premium benefit: Reserves which become free due to
disability of policyholders (positive amount).
• terminal benefit or maturity payment: Reserves which become
free due to maturity of the policies (positive amount).
• portfolio transfer: Corresponds in the first month of the projec-
tion to the mathematical reserves at the start of the projection
(see other income above, but with negative sign).

Reinsurance outgo
The reinsurance cash flow is generally presented under outgo with two
items, a negative (outgo) and a positive (income) one. Usually, on
a longer term the reinsurance is an expenditure which the life insur-
ance company has. The reinsurance outgo and income positions are
calculated at the end of each month but presented in the output at
the beginning of following month. In case one would need a precise
monthly closing one would need to manually include the reinsurance
positions of the subsequent month to have a ”clean” (correct) accrual
with a corresponding tax adjustment (this can easily be done in Ex-
cel). The reinsurance outgo includes the following positions (calculated
according or in proportion to the quota share of the various products):
• premium risk death ceded
• premium risk disability ceded
• premium alpha ceded
• premium unit expenses ceded [i.e. fixed administration expenses
(kappa)]
• premium admin expenses ceded [i.e. beta (collection) expenses]
• surrender clawback
• extra deposit investment income
Reinsurance income
The reinsurance income includes the following positions:
• reinsurance commissions
• acquisition commission reallocation over time: The acquisition
commission is reallocated over time according to the ”amorti-
zation of acquisition commission in years” parameter (see also
section ”Product specific reinsurance”). This item could have a
positive or negative sign.
• admin running commissions [i.e. beta (collection) expenses]: Rein-
surance company pays back to the reinsurance company a part
of the expenses it receives.

• unit running commissions [i.e. fixed administration expenses (kappa)]:
Reinsurance company pays back to the reinsurance company a
part of the expenses it receives
• death benefits in excess of savings
• waiver of premium benefits
• profit participation
Taxes
Taxes are calculated as a simple percentage based on all the above
income less outgo positions.
7.6.3 Net income
The net income only deals with the policyholders’ funds and not with
the shareholders’ funds (which are included under ’portfolio informa-
tion’). It is the sum of the income minus the outgo.
7.6.4 Portfolio information
Following portfolio information (a.o. balance sheet elements) and/or
key figures are calculated at the end of each month:
• total reserves
• solvency margin
• policies in force: Total number of policies.
• policies death: Number of policyholders who died.
• policies waiver of premium: Number of policyholders who became
disabled.
• policies surrender: Number of policyholders who surrendered their
policy.
• policies maturity: Number of policies which came to maturity.
• sums at risk: Total sums of death plus disability (waiver of pre-
mium)

• sums at risk death
• sums at risk waiver of premium: Risk free discounted value of
premiums after the waiting period
• present value index of risk discount rate
• index of risk free rate
• index of investment return on funds
• index of inflation on expenses
• nominal premium ceded to reinsurance
• loss carried forward in reinsurance: Includes the ’cost and risk
annual supplement on ceded premium’.
• shareholder capital: Is equal to the ’shareholder capital’ of the
previous period plus the ’shareholder capital return before taxes’
minus the ’taxes on shareholder capital return’.
• shareholder capital return before taxes
• taxes on shareholder capital return
With the last three lines (above) one could also approximately build-up
a financial position of the shareholder and e.g. compare this with the
required solvency margin. In our example we see that between March
2012 and May 2013 the company would have enough liquidity but the
required Solvency I margin would not be fulfilled.
7.6.5 Subsequent treatment
Separate (batch) calculations could be set-up and done for a single
policy (profit testing purposes), a specific product, a sub-portfolio or
the entire business of the life insurance office. The various results of
PillarOne can easily be imported into an Excel spreadsheet (”copy/-
paste”)2
.
With the grouping function and an Excel-template sheet the monthly
PillarOne results could then easily be presented on e.g. an annual or a
quarterly basis.
2Please note that: Excel 2003 has only 256 columns, which correspond to number
of projected months (runs) if one would simply like to ”copy/paste” the PillarOne
results into Excel.

7.7. FUTURE DEVELOPMENT 79
Subsequent treatment could e.g. be the present value calculations of
the cash flows (value of business in force) or cost of capital derivation
(cost of locking-in), etc.
7.7 Future development of the life insur-
ance PillarOne cash flow model
We hope to receive feedback and input from the users of this life insur-
ance PillarOne model.
We could further develop this first building block on various areas. Here
are some high-level ideas:
• Extend this model for including traditional life insurance prod-
ucts (not only unit-linked)
• Model assets and asset-dependent dynamics of life insurance busi-
ness (e.g. dynamic lapse rates, bonus participation, investment
strategies)
• Enhance to do stochastic simulations (to do TVOG, MCEV, etc.
calculations)
• Perform dynamic ALM-analysis, economic capital and solvency
II calculations, etc.

Chapter 8
The application
8.1 Input Parameters
to open them1
to edit them2
8.1.1 Versions
A parametrization can be in different states: editable or locked; valid
or invalid. If a result is based (depending) on a (valid!) parametriza-
tion, this parameterization is no longer editable but locked. This can
be seen by a small icon of a lock. Unless the result is removed, the
parameters which were used to produce this result stay locked. This
is important to guarantee that the results are reproducable and au-
ditable. Nevertheless, you may want to create different versions of the
input parameters before running any simulation. Often users start with
a base or a planing scenario and then derive for example a high interest
rate scenario or a different reinsurance program.
Note: In such a context many people use the term scenario inter-
changably with parametrization. This stems from the fact that for busi-
ness people the input parameters capture operational options or scenar-
ios: What happens if the interest rates increase or, how does a different
reinsurance program affect the risk capital, etc.?
Most of the parameters in such derived parametrizations are left iden-
tical to the original parametrization and it would be cumbersome to
1TODO: td
2TODO: td
81

82 CHAPTER 8. THE APPLICATION
enter or load them again. RiskAnalytics offers a convenience func-
tion that lets you explicitly create a new version of a parametrization,
i. e. making a copy of a parametrization. Independent of whether the
original parametrization was locked or not, the copy will be editable.
graphic3
8.2 Defining outputs
A model does not define itself which output variables are collected
during a simulation run and then stored for subsequent analysis or
reporting. Different users or even the same user in different situations
may have different requirements. With a new model or model version
the users often start by collecting a lot of output variables because they
want to get a better feel for the model and verify that it performs as
expected. Later on, for the operational use of the model, the actuaries
may get more technical key figures collected and the business people
more of the financial key figures. In principle, you could collect always
all available output variables. People who are building models in Excel
are used to this mode. For Monte Carlo simulation models this gets
very quickly unwieldy. More importantly, the output would not be
tailored to the user of the output: An actuary, a business analyst, a
portfolio manager, etc.
Result templates are used to define which output variables are collected
during a simulation run and at which granularity. Hence, they are the
means to tailor the output to the users.
The different strategies for collecting output data are:
• foo bar
to open them4
to edit them5
8.2.1 Versions
The version behaviour of result templates is analogue to the one for
parametrizations. A result template can be in two states: editable or
locked. The latter happens if a result depends on this result template.
Unless the result is removed, the result template, which was used to
3TODO: graphic
4TODO: td
5TODO: td

8.3. RUNNING CALCULATIONS / SIMULATIONS 83
produce this (dependent) result, stays locked. This is important to
guarantee that the results are reproducable and auditable. Neverthe-
less, you may want to create different versions of a result template
before running any simulation. The typical use case for this is that
a power user defines the templates for less experienced users, or users
who are less familiar with the model.
If you want to derive a result template from another one because you
want to leave large sections of the settings identical to the original result
template, then it would be cumbersome to enter or load them again.
RiskAnalytics offers a convenience function that lets you explicitly
create a new version of a result template, i. e. copy it. Independent of
whether the original result template was locked or not, the copy will
be editable. graphic6
8.3 Running calculations / simulations
complete section7
There are two kinds of models: Deterministic calcu-
lation models and Monte Carlo simulation models. Both are supported
by RiskAnalytics. The common parameters are described here and
the ones which are different (in the two worlds) are described in the
following subsections.
common inputs here
name
comment
parametrization
graphic8
8.3.1 Deterministic calculations
complete section9
no seed, no number of iterations
8.3.2 Monte Carlo simulations
seed optional
number of iterations
6TODO: graphic
7TODO: needs to be done!
8TODO: graphic
9TODO: needs to be done!

84 CHAPTER 8. THE APPLICATION
8.4 Results
The main interface to a result can be opened via the context menu in
the left pane
screenshot
where do we put ‘working with tabs’?

Chapter 9
Concepts
In order to understand the concepts of PillarOne RiskAnalytics, it
is necessary to get comfortable with the words that we use to denote
various aspects in their context, i. e.
• Model contains all the risk drivers, applying them in a specific
order by using a data driven workflow
• Components are the building blocks of a model
• Packets contain the information sent from component to com-
ponent and persisted as results
• Wiring describes the relations among the components of a model
as introduced in Section 9.1 and
• Simulation: executing a model with a specific parameterization
collecting results as described in a result template
• Iteration: one possible realization in a stochastic context, also
referred to as an ‘iteration run’; one specific, actual realization in
a deterministic context
• Period: projection step; i. e. a calender based time interval, such
as a business year
• Results: Resultanalysis, graphically and numericalle by different
graphics and views
87

88 CHAPTER 9. CONCEPTS
as introduced in Section 9.2.
Before entering into more details, let us give some deﬁnitions:
• Persistence
• Parameterization
• Result
• Business Logic
• Collection Mode
•
•
9.1 Risk Model
There are three diﬀerent kinds of models:
• deterministic models especially designed for life modelling
• stochastic models with no time concept
• stochastic models with a time concept
Examples are the models Capital Eagle or Podra.
9.1.1 Model
9.1.2 Components
9.1.3 Packets
9.1.4 Wiring
9.2 Simulation
A simulation runs a risk model a given number of times. Each of
the single executions – all together makeing up a simulation – is an
iteration. In other words, a simulation starts a number of iterations
and works on the collected results. Every iteration runs the model for
a given number of periods.

9.2. SIMULATION 89
Periods can most easily be thought of as business years (but they can
be any regular, calendar-based time interval). Each period may have
a different set of parameters. Periods have a natural sequence, and
output from one period can be transferred as input to the next period.
The number and length of periods is defined in the parameterization.
If all periods are of equal length this may be defined in the model.
different lengt?1
Schematically, for a simulation with m iterations and a parameteriza-
tion defining n periods:
simulation
period 1 period 2 . . . period n
iteration 1 . . . . . . . . . . . .
...
... sip
...
...
iteration m . . . . . . . . . . . .
Simulation
In order to execute a simulation, the user has to select a risk model, a
parameterization and a result template.
Iteration
screen2
deterministic models3
stochastic models4
• The number of iterations required depends upon the statistical
key figures to be evaluated. Generally speaking, more iterations
are required for distributions with fatter tails, and/or evalutaions
of higher/lower quantiles.
• A simulation of a DeterministicModel is called calculation. It
contains one iteration only. It’s results are deterministic and not
stochastic.
1TODO: ; if they are of different length ...
2TODO: shot
3TODO: how to use them???
4TODO: how to use them???

Period
For each period, every component executes the following methods ex-
actly once, after all information from its prerequisite components is
available:
• doCalculation() evaluates incoming information and parameters
and prepares outgoing information
• publishResults() sends the produced information to following com-
ponents or collectors
• reset() prepares the component for the next period
Results
The result is a set of simulation, iteration, period, path, ﬁeld, value.
9.3 Component
Components are the building blocks of models. Most of the business
logic is kept in components. Components have typed interfaces which
receive and send packets from and to other components and parameters.
Thinking of a model as a directed graph, components are the nodes in
such a graph. An edge links a sender interface to a receiver interface of
another component.
Advice
• Try to keep components simple; a component should do one thing,
not many things. This makes it easier to test it and also increases
the chances that it can be re-used. Better buiding two compo-
nents running after one other than only one.
• Before starting to implement any component, draw the directed
graph with pencil and paper. Specify where speciﬁc information is
required and produced. Once the directed graph can be mentally
traversed, it is time to start coding.

9.3. COMPONENT 91
Concept
• The method doCalculation() is executed once only per iteration
and period. Therefore no loops are possible within a single com-
ponent.
• Execution is triggered by the framework: If all wired interfaces
(properties of type PacketList starting with in) have received their
information, doCalculation() is executed. Afterwards, packets to
be sent to following components are available in the out proper-
ties.
• Content of in and out properties is not shared between different
iteration paths and periods. Once the framework has sent outgo-
ing information to following components, the in and out property
lists are cleared.
Implementation Details
• All components are derived from the class
org.pillarone.riskanalytics.core.components.Component
• Use helper methods such as isSenderWired(PacketList sender) to
check if a component will receive information in a specific model
or isReceiverWired(PacketList receiver) to check if a following com-
ponent or a collector is wired to an out property.
9.3.1 Conventions
Conventions make a developer’s life easier by reducing the amount of
code to be written and increasing its readability. In RiskAnalytics,
conventions are used to generate the user interface and database scheme.
Naming convention
Beside clean code and greater readability, naming conventions increase
coding speed in modern IDEs (integrated development environments)
which support code completion.
A component may have several properties. Component property nam-
ing employs four prefixes:

• parm: whenever a variable name starts with parm, it is displayed
on the parameterisation user interface automatically. A parm
property may have one of the following types: int, double, String,
DateTime, enum.
• in: all in variables are of type PacketList. Once they are wired
they receive packets from other components.
• out: all out variables are of type PacketList and can send packets
to other components. It is displayed on the result template user
interface and on the result page if the property was collected. The
collection mode can be specified in the result template.
• sub: a component may have subcomponents. Their name has to
start with sub. They are helpful to provide building blocks and
introduce a hierarchy.
Note: If a component is written in Java, variables starting with any
of these prefixes need a public setter and getter method. In Groovy a
variable declared with no access modifier generates a private field with
public getter and setter (i.e. a property). Therefore it is not necessary
to write any getter or setter methods with default behaviour in Groovy.
Grouping of Components and Parameters in the GUI
The order of parameters, out channels and subcomponents within a
component determines the order in the GUI.
RiskAnalytics comes with a powerful way of deriving a default user
interface for all models, components and its parameters – a model or
component developer does not have to write any GUI code. Yet he can
simply group the parameters.
9.3.2 Composed Component
To prevent modelers from always having to start from scratch, the
concept of composed components enables a degree of re-use by allowing
to define building blocks consisting of several components. Typical
building blocks may be for example lines of business or a reinsurance
program. A composed component is very similar to a model, except
that it can’t be executed.5
The following three sections describe three
different scenarios for composed components.
5TODO: explain

9.3. COMPONENT 93
• static building blocks containing a fixed number of different com-
ponent types
• dynamically composed components containing an arbitrary num-
ber of equal components. They are data-driven in the sense that
the exact number of subcomponents is specified in the data and
not in the model itself. Think of them as containers containing
an arbitrary number of predefined subcomponents, wired accord-
ing to specific rules. Examples: a reinurance program with an
arbitrary number of contracts, an arbitrary number of lines of
business or claims generators.
• multiple calculation phase components. This concept is new and
its API not yet stable.
Static Building Blocks Whenever several components are always
used in the same manner or additional hierarchy levels would facilitate
the understanding of a model, a ComposedComponent is the appro-
priate solution. Composed components may be nested. Furthermore
a ComposedComponent may contain one or many DynamicComposed-
Component.6

Chapter 10
Modelling claims
Using RiskAnalytics usually starts with either selecting an existing
or creating a new parameterization. If you start RiskAnalytics for
the first time, there are already several models with illustrative pa-
rameterizations made available for an easy introduction to the soft-
ware.1
Within a parameterization, there are several subsections to be
addressed before you can run your first simulation (cf. Chapter 5.1 for
an overview) such as the definition of (in order of appearance in the
parameterization tree):
• underwriting information by use of Underwriting Segments†;
• the generation of claims through Claims Generators*;
• the development of incoming reserves at the beginning of a period
through Reserve Generators*;
• Dependencies* between two ore many claims generators;
• Event Generators* allowing the simulation of events for per-
event reinsurance cover or for events affecting several claims gen-
erators; and
• Lines of Business† as a means of grouping the underwriting
segments, claims and reserves, the
1If you produce any teaching material – including parameterizations, it would
be warmly appreciated if you share your insights and teaching material (and not
your company’s secrets) with the community: contact@pillarone.org
95

96 CHAPTER 10. MODELLING CLAIMS
• Reinsurance Program (cf. Chapter 13) reflecting the applicable
reinsurance coverage on (parts of) the portfolio, and
• ALM Generators (cf. Chapter 15).
In this chapter we will focus on the claims-related parameters (marked
with *), whilst in Chapter 12 we will focus on exposure-related param-
eters (marked with †).
Being intertwined with claims – but from previous periods – we also
have a close look at the stochastical development of claims reserves.
Please find more details in Chapter 14 about Modelling Non-Life
Reserves on page 149 ff.
10.1 Claims Generators
Given an empty parameterization, or no Claims Generator respec-
tively, you first have to define a Claims Generator by right clicking
and selecting add in the context menu.
RiskAnalytics’s claim ’A claim is more than a number’ can be proven
easily. Whilst it is possible to generate different claim types – such as
attritional, single or event – each claim consists of a value and a date.
Ceded claims keep a reference to the original claim.
Furthermore event claims have a reference to the event they belong too.
The different claim types are required for reinsurance modeling as dif-
ferent contracts require different levels of information to calculate cor-
rectly the ceded part.
A claims generator consists of a – preferably – descriptive name (e.g. ‘Mo-
tor Hull’) and four elements, namely
• Based on Underwriting Information,
• Claims Model,
• Exposure Information Associaton, and
• Period Payment Portion,
as beeing explained in the following sections.

10.1. CLAIMS GENERATORS 97
Figure 10.1: Claims Generator: Motor Hull Attritional
10.1.1 Underwriting Information
As your first selection, you have to decide on which Underwriting In-
formation your claims generator will be based2
: As a starting point,
you will usually select one underwriting segment per claims generator
and vice versa. Given the situation, where you have data available for
two similar underwriting segments – such as ‘motor tpl own business’
and ‘motor tpl co-insured business’, both with the same characteristics
but internally treated separately for regulatory reasons – you can use
the same claims generator for both of them. This will reduce the main-
tenance of your model as there will be less parameters to update and
less time needed for the simulation procedure.3
Essentially, any Under-
writing Segement as setup within the given parameterization (cf. Sec-
tion 12.1) and an ‘additive’ combination thereof is a valid selection for
basing a claims generator on it.
Having a look at a simulation from the other end, you will find the
following components being usually requesters of underwriting infor-
mation:
• claims generators, as their calibration may be based on sum in-
sured, premium, or number of policies,
2It is also possible to run a simulation for claims generators and reinsurance only.
However, if you want to calibrate the claims generator not only by absolute values
but rather by premium or similar, this information must be provided here.
3However, this simplification will add a maybe unwanted dependency between
the two underwriting segments. Better creaty a duplicate of the first claims gener-
ator by right-clicking on the existing claims generator.

• frequency generators – as an element of claims generators – in
case being calibrated based on number of policies,
• allocation of sum insured to claims,
• proportional reinsurance contracts where they need gross under-
writing information in order to calculate the ceded underwriting
information, or
• working/cat excess of loss and stop loss reinsurance contracts
where as the ceded premium may be specified as GNPI, rate on
line or number of policies.
10.1.2 Claims Model
Depending on the application, a Claims Model Type from Table 10.1
can be selected. The Claims Model Type defines the form of the claims
model; the names and structure of subordinate parameters depend on
it. The default value None provides an empty Claims Generator, pro-
ducing no claims.
The intent of the none type is to easily toggle a claims generator on
or off, e.g. in case you want to use it in the first period but not in the
second period of a multi-period model.
None
This selection is useful for quickly de-activating an already defined
claims generator e.g. for setting up a multi period model where a spe-
cific claims generator is active only during a limited number of periods.
Attritional
Modelling ‘attritional’ claims is started by selection of the claims base
as measure of calibration of the simulated claims. This calibration
directly refers to the underlying underwriting information stored in
Underwriting Segments. Let us choose to scale our claims by sum
insured where the non-scaled claims distribution is given by a lognor-
mal distribution LogNormal(0.8; 0.054). The selection above will result
in non-scaled claims with mean 0.8 and standard deviation 0.054.
The scaled claims, as defined by multiplying a given constant – such as
the sum insured in this example – with the non-scaled claims, are again

ClaimsModelType(Additional)InputFieldsExample
NoneDisabledNoClaimsproduced
AttritionalClaimsBasePremiumWritten
ClaimsDistributionPoisson(λ)
ClaimsModificationTruncated(min,max),Shift
AttritionalwithDatewitharandomincurredDateUniform(0.4,0.8)
FrequencyAverageAttritionalFrequencyBaseNumberofPolicies
FrequencyDistributionBinomial(n,p)
FrequencyModificationCensored(min,max)
FrequencySeveritynoadditionalfields
FrequencySeveritywithDateOccurenceDistributionNormal(µ,σ)
ProduceClaimSingleClaims
SeverityofEventGeneratornoadditionalfields
Table10.1:ClaimsModelTypes

lognormal distributed with parameters LogNormal(0.8 ∗ Sum Insured;
0.054 ∗ Sum Insured).
Assuming we will have to update our model some months later, as a
first step, we might want to update just the sum insured amount, au-
tomatically getting a model based on both the updated sum insured
amounts, to reflect a growing portfolio, as well as the parameters se-
lected during the last exercise. Assuming again that we now want to
update not only the sum insured, but also the mean of the distribu-
tion, which we found to be too low by 3%, selecting Shift as Claims
Modification will allow us to shift the claims manually based on our
calibration exercise.
The parameter used for shifting will modify the distribution before
being applied to the scaling measure; i. e., for a given shifting param-
eter a, a = 0 will result in no shift, while a = 0 shifts the generated
claims either positively or negatively. In descriptive words: claims
generatorshifta = (claims distribution + a) ∗ scaling measure: Assum-
ing a sum insured of EUR 1bn, the claims distributed as specified above
and now shifted by a factor of a = 0.8 ∗ 0.03 = 0.024 would inflate the
simulated claims C: C = LogNormal(0.8 + 0.024; 0.054) ∗ EUR 1bn.
An overview and explanation of all possible selections is given in the
table on page 103.
Attritional with Date
Whereas attritional claims are per default modelled as one aggregated
(i. e. grouped) claim occuring in the middle of the period (e.g. 30 June
of a standardized year), the user has the possibility to select a sta-
tistical method for allocation of a date within the time period to the
simulated claim. In many situations it is important to know, when a
claim occurred, namely for reinsurance contracts incepting during the
period and therefore not covering the whole period as being modelled.
For seasonal business such as a hail cover in Europe it might make sense
to select Uniform(0.4; 0.8) resulting in one attritional claim occuring –
based on the selected claims distribution – sometime between May and
October. If you setup a one-year reinsurance contract with inception
date 1. January, all claims occuring during this period will be covered
by the reinsurance contract. But if you setup a reinsurance contract
with inception date on 1. October, the reinsurance will not cover the
hail claims in each and every iteration.

Frequency Average Attritional
This selection is used for modelling claims with more details than ‘just
attritional’ and less than a classical frequency-severity model as it still
aggregates to claims to being one. While the former (’attritional’) re-
sults in one attritional claim per time period, and the latter (’frequency
severity’) in several claims with different severities, the selection here is
used for modelling one attritional claim as specified above but by using
a different kind of parameterization. The user might select a constant
distribution of 5 resulting in one attritional claim being parameterized
by the number (frequency) of five claims and the severity as specified.
Frequency Severity
A very flexible claims generator is made available through this option:
In addition to specific modelling of both, frequency and severity of the
claims, the user has the option to group the simulated claims to one
event selecting Produce Claim as Aggregate Event Claims; this
has an impact on some reinsurance programs.
Frequency Severity with Date
In addition to the already explained claims model Frequency Sever-
ity the hereby explained model allows the modelling of assumptions
around the occurence of the claims. As default, a uniform(0; 1) dis-
tribution is applied, resulting in equally distributed claims over the
complete time period. Alternatively, for example,
Piecewise Linear((0; 0.25; 0.5; 1); (0; 0.33; 0.66; 1)) would result in an oc-
curence pattern with no occurences from January to March, 33/100 of
claims occuring between April and June, another 33/100 between July
and December and the remaining 34/100 on the latest day of the (stan-
dardized) year. Again, this is important to know namely for reinsur-
ance contracts incepting during the period and therefore not covering
the whole period as being modelled.
Severity of Event Generator
Severity of event generator is selected in case you want to first simulate
severities by use of the Event Generator (cf. the section on Event
Generators on page 107 for more details) and afterwards apply them
to – usually – several underwriting segments: By using this approch,

the Event Generator (cf. Section 10.4) will firstly draw one or sev-
eral event as specified in your parameterization whereof a percentile is
drawn. This percentile then gets applied to the Claims Distribution
here.
10.1.3 Exposure Information Associaton
As in some cases the size of a claim is not sufficient for the following
depending calculations, exposure information, like the sum insured (SI)
and the probable maximum loss (PML) can be attached to the claim.
Especially the surplus reinsurance cover requires to know pairs of expo-
sure and claim size to calculate the coverage.4
Except None there are
two exposure information association mechanisms available: Risk to
Band and Sum Insured Generator; all of them explained further
below.
In principle, there are many different ways of allocating claims to risk
bands. RiskAnalytics offers two different approaches, one of which
is applied to aggregate losses and the other to single losses. In both
approaches, the allocation uses a target allocation that specifies for each
risk class the percentage of claims that should be associated with the
given risk class. In the case of aggregate claims, the target allocation
can always be easily met since aggregate claims can always be split up.
None
In case no exposure association to the claims is needed, this selection is
appropriate. If, on the other hand, the exposure association is needed
but not specified here, the portion of ceded risk is set to zero even if
an instrument such as surplus reinsurance is specified further below in
the parameterization.
Risk to Band
In case of single claims, the following modified procedure is applied:
For an initial guess, the incoming (individual) losses are allocated to
the risk classes by just referring to the claim size, i. e. the claim must
4Surplus reinsurance is a more advanced and more complicated form of propor-
tional reinsurance where the portion covered by the reinsurer depends on the sum
insured (or other quantities) specified for the underlying insured risks. The portion
of the claim ceded to the reinsurer is given by the ratio of the risk ceded divided by
the total risk.

Thisisasummaryofnamesandentriesforcomboboxesasrelatedtoclaimsgenerators.PartI/II
Name,ComboboxDescription
TypeSelectionofClaimsModelType
NoneNoclaimsaregenerated.
AttritionalOneattritionalclaimisgeneratedoccuringinthemiddleofthetime
period:1claimoccuringon30Juneofastandardizedyear.
AttritionalWithDateOneattritionalclaimisgeneratedoccuringduringthetimeperiodbased
onaspecifieddistribution:1claimperperiodwithrandomlydistributed
occurrencedate(attachedtotheclaimforfurtheruse!).
FrequencyAverageAttritionalOneattritionalclaimasperthespecifiedparametersissimulated.
FrequencySeverityDistributionsforboth,frequencyandseverity,arespecified.
FrequencySeveritywithDateFrequencyandSeveritymodelincludingdistributionoftheoccurrence.
Datesareattachedtotheclaimforfurtheruse.
SeverityofEventGeneratorPleaseseethesectionsonseverityofeventgenerator(page101)and
onEventGenerators(page107).
FrequencyBaseSpecificationofmultipletothemeanofthespecifiedclaims
frequency
AbsoluteThemeanofthedistributionispre-determinedasabsolutevalue;
NumberofPoliciesorbythenumberofpolicies.
FrequencyDistributionPleaserefertotheSSJLibrary
Table10.2:ClaimsModel:SummaryandExplanationsofComboboxesPartI/II

Thisisasummaryofnamesandentriesforcomboboxesasrelatedtoclaimsgenerators.PartII/II
Name,ComboboxDescription
FrequencyModificationApplyingamodificationtotheclaimsgeneratorbeforemulti-
plyingwiththeFrequencyBase
NoneNomodificationtotheselectedfrequencydistribution.
TruncatedCuttingthedistributionataspecifiedminimumandmaximumvalue
respectively.Noobservationsoutsidethegivenrangeareobserved.Ap-
plyingadeductibleisanillustrativeexamplefortruncationatthelower
endofthedistribution:lowerclaimsarenotregistered.
Truncated,ShiftCombinationofbothmethodsbyfirsttruncatingandafterwardsshifting
thedistribution.
CensoredCensoringthedistributionataspecifiedminimumandmaximumvalue
respectively.Anyobservationoutsidethegivenrangeis‘rounded’tolie
withintherange.Applyingamaximumsuminsuredisanillustrative
exampleforcensoringatthehigherendofthedistribution:higherclaims
arecuttothemaximumsuminsured.
Censored,ShiftCombinationofbothmethodsbyfirstcensoringandafterwardsshifting
thedistribution.
ShiftAdditiveshiftingofthemeanofthedistributionbytheparameter.
ClaimsBaseSpecificationofmultipletothemeanofthespecifiedclaims
severity
AbsoluteThemeanofthedistributionispre-determinedasabsolutevalue;
PremiumWrittenorbywrittenpremium,
NumberofPoliciesbynumberofpolicies,or
SumInsuredbysuminsured.
ClaimsDistributionPleaserefertotheSSJLibrary
DiscreteEmpirical(cumulative)allowstoloadexternalinformationsuch
asRMS-tables.
ClaimsModificationcf.aboveFrequencyModification
Table10.3:ClaimsModel:SummaryandExplanationsofComboboxesPartII/II

10.2. RESERVE GENERATORS 105
fit in between the lower and the upper limit of the risk band. Based
on the selection such as Premium, an algorithm re-alocates the single
claims to higher risk bands where needed in order to allow a best-fit to
the weight per band as set by Premium (in this example).
Sum Insured Generator
The sum insured generator produces the required exposure information
using the claim and the maximum sum insured. The claim (Xi) is used
as generated from the claims generator, the maximum sum insured or
PML is taken from the appropriate underwriting information. The sum
insured is calculated using the following formula SIi = a(PML−Xi)+
Xi. The random distribution a, usually a ∈ [0, 1], is configurable by
the parameters of the sum insured generator.
Furher details on surplus reinsurance are explained in Section 13.2.2 on
page 135.
10.1.4 Period Payment Portion
The parameter period payment portion p is part of the reserve model
(cf. Section 10.2). The share p ∈ [0, 1] is the part of a generated claim
which is paid during the current period. The share 1 − p is shown as
reserved at the end of the period.
10.2 Reserve Generators
The reserve generators provide an additional option to model random
effects of IBNyR/IBNeR. As a volume parameter the initial reserve
volume can be put in. The reserve generator allows for the types listed
below5
.
More details are explained in the specific chapter on page 149 ff.
10.3 Dependencies
This is a short overview only. For more details, please refer to chapter
11 on pages 109ff.
Given a portfolio with two underwriting segments, for instance motor
hull private and motor hull commercial, dependencies in-between
5TODO: tbd

Figure 10.2: Reserve Generator
these two underwriting segments will occur: By selecting a dependency
for two or more underwriting segments, all attritional and/or attri-
tional with date claims will be modelled with the specified depen-
dency.
Figure 10.3: Dependencies
Figure 10.4: Dependency Matrix
Whilst such dependecies are usually not linear, they are modelled by
use of copulae belonging to these families:
• Normal (Gaussian), specified by a dependency matrix
• Frechet upper bound, applied to a target, i. e. a claims gener-
ator
• No Correlation, i. e. independent targets
• T-Copula, specified by the degrees of freedom and a dependency
matrix

10.4. EVENT GENERATORS 107
• Gumbel, specified by parameters Lambda, the dimension and
the targets
Whilst further details on how to use dependencies in RiskAnalyticsare
given in the respective chapter on page 109 ff..Details on the implemen-
tation of these copulae can be found here www.link.meplease; details
on how to calibrate the dependency structure given a specific portfo-
lio are usually provided together with spezialized calibration software.
PillarOne RiskAnalytics releases come with parametrizations that
furnish examples of companies having dependencies between selected
underwriting segments.
10.4 Event Generators
Event Generator vs Event Correlation in MCM 6
An insurance contract
always specifies the covered risk: Some reinsurance contracts cover the
complete balance sheet of a company (such as Stop Loss), others only
cover one specific building or vehicle (such as facultative reinsurance
cover for the construction of a tunnel). XL treaties usually either are
specified as per risk or per event. In the latter case, an often high
number of – relatively – small claims lead to a large loss for the insur-
ance company; however, none of these small claims would be covered by
reinsurance separately. So we would have to select a claims generator
with the option Produce Claims: Aggregated Event.
Figure 10.5: Event Generator
If you select an Event Generator it will simulate the severity of an
event by determining the percentile – as number between 0 and 100.
If for example, the percentile of 84% is drawn, this percentile is fed to
the claims generators where the option severity of event generator
is selected. Depending on the loss distribution for each underwriting
6TODO: todo

segment the loss amount will be calculated depending on the speciﬁed
percentile.7
7TODO: This section needs rewording and more explanation. the ﬁrst paragraph
is really misleading!

Chapter 11
Dependency Modelling
11.1 Scaling and allocating claims
If an attritional claim is simply a fraction of another claim, then this
is a dependency structure, albeit a very simple one. Of course, we
could explicitly re-scale the claims distribution and capture the new
distribution parameters. But for various reasons this may not always
be the best solution. If for example we get market loss distributions
from an external provider, then for review and audit reasons we capture
these original parameters and scale the claims to the appropriate scale
of the portfolio. Another reason may be that the same claims source
is used with different scalings in different parts of a model. And a
third application is if one quickly wants to perform a simple sensitivity
analysis with respect to a claims distribution.
Figure 11.1 shows that scaling factors are entered in the multi-dimensional
parameter called Share. This multi-dimensional parameter is used to
associate the claims generators to the lines of business and set their
scaling factors. The term Share suggests another use of this scaling:
Parts of a claims can be allocated to different lines of business. This
may be necessary if policies cover multiple risks, but the historic data
may not be sufficient to calibrate claims distributions for each risk
which are covered by the policy. In the cases in which we talk about
allocating claims to multiple lines of business their shares usually add
up to 1. This is not the case if for example a market loss is scaled. In
fact, in some cases scaling factors which are greater than 1 may make
sense. Hence, there is no validator which checks that the shares add
109

110 CHAPTER 11. DEPENDENCY MODELLING
Figure 11.1: Scaling or allocating claims
up to 1 and/or each share is less than 1.
11.2 Dependency models for attritional claims
Copulas offer a way to construct joint distributions with given marginals.
This is a frequently encountered problem in actuarial work. If one cause
leads to several different claim types, e. g. property damage and fire fol-
lowing, then there exists a joint distribution of these claims. If we fit
claims distributions to the claims, one per claims type, then these are
the marginal distributions of an unknown joint distribution. Hence, to
sample from these marginal in a correlated way, we need to construct
a joint distribution.
For an introduction to mathematical foundations of copulas see [14].
For a discussion more focused on insurance risk applications we refer the
reader to McNeil et al article in [13]. It is important to notice that there
are also other ways to model dependencies, e. g. causal dependencies.
Impact1
RiskAnalytics offers different copulae (compare Figure 11.3 further
below):

11.2. DEPENDENCY MODELS FOR ATTRITIONAL CLAIMS 111
Figure 11.2: 4-dimensional normal copula
• Comonotonic or the Frechet upper bound, i. e. the maximal pos-
sible correlation. This corresponds to drawing from all claims
distributions a claim which corresponds to the same percentile.
This copula has no parameters.
• Normal
• Student t
• Gumbel
It is not hard to add other copulas. Let us know which ones you use
and we will add them to the library. For a copula model we always
have to specify its parameters and which claimstributions should be
correlated, i. e. the marginal distributions. Some copulas may have no
parameters.
It is beyond the scope of this manual to discuss which copula model can
be applied in which situation and for what reasons. As demonstrated
in Figure 11.3, the choice of copula has a major inﬂuence on the de-
pendency structure and needs careful consideration. Figure 11.2 shows
a normal copula which correlates four attritional claims generators.

Figure 11.3: Comparison of comonotonic, normal and Gumbel copulas

11.3. DEPENDENCY MODELS FOR SINGLE CLAIMS 113
11.3 Dependency models for single claims
If we are working with a frequency-severity model to produce single
claims, then the most obvious way to correlate these single claims is
to postulate a common cause model. In other words, we assume that
the claims stem from the same underlying events. This does not imply
that the claim sizes must be correlated; but usually this will be the
case. Hence, for each iteration we can draw one claims frequency per
simulation period for all correlated single claims. And for each of the
claim events we can proceed as in the attritional claims case.
It is worthwhile noting that even if some single claims are correlated
that does not force us to correlate all single claims. For example, if
you work with Poisson distributed claims frequencies, then it is easy to
split the frequency into a common event frequency and an idiosyncratic
claims frequency. The two average frequencies, the parameters of the
Poisson process for the event and the idiosyncratic process, have to add
up to the total average frequency. This holds because the sum of two
Poisson processes with parameters λ1 and λ2 is again a Poisson process
with parameter λ1 + λ2.
11.4 A simple dependency example
The following example shows how the above discussed dependency
models can be combined in a practical case. It is worthwhile noting
that this is a simple example and yet, the resulting correlation struc-
ture is already fairly complex. We do not mean to discourage mod-
ellers from using such dependency models. But their structure and
the calibration of their parameters needs to be carefully reviewed and
validated. The limitation of dependency modeling is deﬁnitely not a
technical one. What can be modelled in RiskAnalytics by far exceeds
what most actuaries can soundly explain and validate. Hence, the slo-
gan for dependency modeling should deﬁnitely be: Keep it as simple
as possible.
Let us assume that we have the two lines of business property and
motor hull. For each of these lines of business we model independent
large losses using a frequency severity model with Poisson frequency
and Pareto severity. The parameters can be seen in the section ‘In-
denpendent LargeLosses’ in Figure 11.4. For the large claims which
stem from catastrophic events we assume a common cause model with
a Poisson frequency and Pareto severities which are correlated using a

Figure 11.4: Typical dependency structure for two lines of business

11.4. A SIMPLE DEPENDENCY EXAMPLE 115
Figure 11.5: Split of the aggregate claims into the three risk types. On
the horizontal axis is the claim size in monetary units and the vertical
axis is the contribution of each claims type to the aggregate.
student-T copula. Finally, for the attritional claims we use lognormal
distributed claims which are correlated using a normal copula.
This is an absolutely standard dependency structure and the marginal
distributions as well as the copulas are not exotic. The resulting ag-
gregate claims have a complex structure as shown in Figure 11.5. For
small aggregate claims there are hardly any cat claims involved. With
increasing size of the aggregate claims the contribution of the single,
non-cat claims and the attritional claims decrease.

Chapter 12
Modelling exposure
Whilst we started our focus on modelling exposure and claims by ﬁrstly
looking at the claims generators in chapter 10 (this makes sense, as in
the real world, claims occur even without being exposed to insurance
contracts), we will now learn how to model the exposure of an insur-
ance company by use of a simple two-level hierarchy. The ﬁrst level of
the hierarchy consists of Underwriting Segments and the second of
Lines of Business. The former consists of the lowest available level of
underwriting information, such as motor hull or motor tpl; the latter
either consists of one line of business only or of a group of lines of busi-
ness: motor = motor hull ∪ motor tpl. Depending on the granularity
of the available data, underwriting segments might be granular to any
level you can dream of: type of business, currency, region, legal entity,
etc. It is your professional judgement on the data available on which
level you want to run simulations. Modelling every single contract will
most often be too granular, modelling the whole company only will
most often be too general.1
12.1 Underwriting Segments
For the sake of convenience, a new underwriting segment can either be
built by right-clicking on Underwriting Segment and selecting add
– resulting in an empty underwriting segment – or by right-clicking
1Both extremes are existing in the real life: A reinsurer covering a niche might
model contract by contract; a relatively small legal entitiy within a relatively large
group will be modelled as one underwriting segment.
117

118 CHAPTER 12. MODELLING EXPOSURE
Figure 12.1: Underwriting Segments
Figure 12.2: Underwriting Segments: Details for Property shown in a
4/9 matrix above
an existing segment and selecting duplicate: The latter will copy all
information from the ‘parent’ underwriting segment to the ‘child’ being
saved under a new name.
The underwriting information contains per segment: maximum sum in-
sured, average sum insured, premium and number of policies. It is pos-
sible and often appropriate to edit serveral risk bands: These risk bands
will be used for surplus share treaty reinsurance (cf. Section 13.2). It
is important to remember these risk bands are directly interlinked to
each other as shown in the following table:
Note: Therefore, it is not possible to ‘group’ a heterogenious portfolio
after the merger of two companies, even if one of them with higher
insured amounts, the other with lower insured amounts etc. This would
rather be achieved by building a Line of Business as explained in the
next section.
Double-clicking on the cell next to Underwriting Info opens a table
where you select the number of bands needed and type in the criteria

12.1. UNDERWRITING SEGMENTS 119
Figure 12.3: Lines of Business
Risk band ri Minimum Sum Insured Maximum Sum Insured
r1 0 max1 = User Input
r2 max1 max2 = User Input
r3 max2 max3 = User Input
. . . . . . . . .
Table 12.1: Risk Bands
for each band:
• maximum sum insured: The upper bound of the range of
sums insured. The lower bound is given by the upper bound of
the previous class (in the previous row) or 0, cf. Table 12.1.
• average sum insured: The average sum insured of the policies
included in the given risk class. By deﬁnition, the average should
be smaller than or equal to the maximum sum insured of the given
row, but larger than the maximum sum insured of the previous
row.
• premium: The total premium of all the policies included in the
risk band.
• number of policies: The number of policies included in the risk
band.
Note that the risk bands have to be in ascending order.

120 CHAPTER 12. MODELLING EXPOSURE
12.2 Lines of Business
Lines of business are built by the union of one or several underwriting
segments; exposing them to claims generators and reserve filters.
As now the risks are defined they may be combined or allocated to
business segments. Adding a new line of business (right-click, as usual)
opens three sets of parameters: Adding different claims generators (or
shares2
of them) to the dedicated Line of Business, as well as Reserve
Filters (cf. Section 10.2). Finally, to each Line of Business the Under-
writing Information is attached, completing the information needed in
this area.
If you want to further cascade the grouping, i. e. looking at Non Life
business consisting of motor and fire, sticking with the above example,
you have to setup a line of business on the level of the existing granular
underwriting segments: Non Life = motor hull ∪ motor tpl ∪ fire. This
allows separate modelling of company-wide effects such as inflation for
underwriting segments in specific countries.3
2The share might be greater than 1 in case you want to scale the distribution.
3TODO: Is this true?

Chapter 13
Reinsurance
The reinsurance components model the reinsurance contracts. The fol-
lowing discussion explains how the different claims model types (cf. Sec-
tion 10.1.2) are processed by the reinsurance components. It is not
meant to explain all the different features and options of reinsurance
contracts. Here and there we make a comment about the effects of rein-
surance, because these effects can easily be visualized in RiskAnalytics.
But overall, we assume that the reader has a basic understanding of
reinsurance. For details about reinsurance we refer the reader to [8, 11].
Each reinsurance contract has a strategy defining the contract type.
Parameters common to all strategies are:
• Share covered by reinsurer, defining the share signed
• Inuring Priority, which is used if the user can add and remove con-
tracts (see Section 13.4.2). It defines the order in which contracts
are processed within a reinsurance programm. Claims and under-
writing information are first processed by the contract with the
lowest inuring priority. The resulting net is then processed by
the contract with the next higher inuring priority. If several con-
tracts have the same inuring priority, they are applied in parallel.
Parallel contracts may be used in combination with “covered by
reinsurer” if a contract is split among several reinsurers. Another
use case consists of several XL layers.
The remainder of this chapter is structured as follows:
121

122 CHAPTER 13. REINSURANCE
• General reinsurance paremeters being used for (almost) every
reinsurance contract are explained in section 13.1, including an
extensive part on commission
• Modelling Proportional Reinsurance follows in section 13.2, while
• Modelling Non-Proportional Reinsurance follows in section 13.3
• 13.4 are covered in the closing section of this chapter
13.1 General reinsurance parameters
Some parameters are common to all reinsurance contracts.
13.1.1 Associating claims, lines of business and re-
serves to reinsurance contracts
In some form or another we have to deﬁne which claims are covered and
hence which claim generators should send their claims to the reinsur-
ance component. The most obvious selection is to associate claim gen-
erators directly with a reinsurance component. For reinsurance com-
ponents which cover reserves the analogue is to directly associate the
reserve generators. But claim generators or reserve generators can also
be associated indirectly with a reinsurance component by specifying
which lines of business are covered by the contract. In this case rein-
surance contract covers the claims and/or reserve generators which are
associated to the covered lines of business. The lines of business and
peril criteria can be combined with a logical and. This allows to set-
up a reinsurance contract which only covers some perils from a line of
business.
At ﬁrst glance this looks as if chosing a line of business and a peril
is identical to just chosing the peril. Indeed it is identical, but only
if there are no preceeding reinsurance contracts which cover the same
peril, i. e. the gross claims from this peril are covered by the reinsurance
contract, and the perils are 100% associated to a line of business.
To specify what is covered by a reinsurance contract, we have to com-
plete the section Cover in the reinsurance component (see Figure 13.1).
Since a reinsurance contract can cover multiple perils or lines of busi-
ness, these parameters are set in a multi-dimensional parameter. A
typical situation is that the claims are modeled with an attritional, a

13.1. GENERAL REINSURANCE PARAMETERS 123
Figure 13.1
Figure 13.2
frequency-severity and a cat distribution and all of them are covered
by the reinsurance contract.
13.1.2 Partially underwritten reinsurance contracts
A reinsurance contract needs not be placed 100% in the market. The
fraction which is underwritten can be speciﬁed in the contract section
of a reinsurance contract (see Figure 13.2). In the interface it is called
Covered by Reinsurer. First the ceded claims are calculated as if
this fraction were 1, i. e. 100% of the contract is covered by a reinsurer.
After these contract speciﬁc-calculations are done, then the fraction is
applied to obtain the ceded claims.
To reduce credit risk exposure towards reinsurers, reinsurance contracts
are often placed with several reinsurers. If this credit risk is not mod-
elled, then the sum of the parts covered by all reinsurers participating
at a contract can be added up and used as the fraction covered by

reinsurer. Hence, if for example two reinsurers participate with 50%,
then we can still model one reinsurance contract with a fraction of 1.
If the credit risk of reinsurance is modelled, then this contract has to
be modelled as two identical contracts – one in detail, the second by
duplicating the first – with the same injuring priority, but each with
the appropriate fraction from the corresponding reinsurer.
13.1.3 Contract basis
If the claims covered by a reinsurance contract are directly coming
from a claims generator, then this parameter has no effect. But in the
context of reinsurance programs a reinsurance contract has to define
whether it covers the net or the ceded claims of the preceeding contract
(see Figure 13.2please check the figure1
).
Taking the net claims of the preceeding contracts as the gross claims
for the next contract is usually done in primary insurance models where
the insurer is interested in its net claims. Taking the ceded claims of
the preceeding contracts as the gross claims for the next contract is
typically done in retrocession models.
13.1.4 Injuring priority
Like the contract basis, the injuring priority is only used in the con-
text of several reinsurance contracts, i.e. a reinsurance program. In a
reinsurance program, the injuring priorities of the involved contracts
defines the order in which the contracts are applied. It is a positive
integer. Several contract may have the same injuring priority if they
are to be applied in parallel; for example different layers of a WXL
cover. In the following we first explain the contracts before we con-
tinue to structure reinsurance programs (see section 13.4) by means of
the injuring priority.
13.1.5 Reinsurance Commission
In reinsurance, the primary insurance company usually pays the rein-
surer its proportion of the gross premium it receives on a risk. The rein-
surance commission is another factor that plays an important role in
determining the price of reinsurance: The reinsurer allows the company
a commission on gross premium received, large enough to reimburse the
1TODO:

company for the commission paid to its agents, plus internal admin-
istration expenditures, loss adjustment costs, taxes and its overhead2
.
The commission may be calculated by the reinsurer as the difference
between premium and expected claim burden after deduction of his
profit expectations.
Interpreting the commission as a reimbursement of the direct insurers
expenses different strategies for designing reinsurance commission have
evolved. In what follows we consider three different forms to calculate
commission:
1. The fixed commission is the most common form of reinsurance
commission obtained by a fixed percentage of the ceded written
premiums,
2. the profit commission providing one way of taking the actual rein-
sured business into account, and
3. the sliding scale commission that is a way of encouraging the
cedant to write profitable business just as the profit commission.
We also outline the bouquet commission as an integral part of the
component Reinsurance, respectively Reinsurance Market for the
‘Multi Company Model’. As the name implies the essential feature of
this additional (sub)component is the application of one of the three
commission strategies (fixed, profit, sliding) to a bundle of reinsurance
treaties.
Fixed Commission
The fixed commission with its clear contractual agreements is easy to
handle and allows for predictability in the primary- and reinsurer’s
planning process. With the predetermined (ceded or fixed) commission
rate cfix and the ceded premium written Pceded the formula for the
commission Cfix reads
Cfix = cfix · Pceded. (13.1)
The direct insurer’s operating costs will be fully defrayed if the fixed
commission rate matches the cost ratio of the primary insurer given by
the ratio between costs and written premium.
2In this illustrative example, we do not consider economical strategies of both,
the insurer as well as the reinsurer, by setting the commission in a way of optimizing
the profit of each involved party, but rather assuming the commission shall be
determined as fair means of sharing costs.

Example: A primary insurer and a reinsurer conclude a 25% quota
share treaty in the accident line of business.3
The written premium
that the direct insurer obtains from the policyholders is 100 million,
the operating costs are 30 million and the expected claim burden is
60 million. The primary insurer cedes 25% to the reinsurer who thus
receives 25 million premium and must pay 15 million of the expected
losses. The commission rate is determined to be 30%, hence 7.5 million
is returned to the direct insurer as his commission. Due to consistency
of commission and cost ratio, both contractual partners can expect a
profit of 10% of the received premium, that is, 0.1 = 7.5/75 = 2.5/25.
Figure 13.3: Fixed commission strategy in “Multi Company Model”
Note: In the RiskAnalytics parametrization form as illustrated in
Figure 13.3 the user may find the parameter name Commission after
selecting Fixed Commission for the Commission Type. In abuse
of notation it should be clear from the context that the value that is
associated to this parameter is the commission rate cfix.
Profit Commission
It is often felt to be inappropriate to have a fixed commission that is
given independently of the actual profits and losses resulting from the
3Notice that this example strongly simplifies reality in that operating costs of
the reinsurer are simply ignored.

(reinsurance) contract. If the results are good (and commission rate
was below the actual direct insurer’s costs), the direct insurer wants
to participate in the profits by a more equitable share in the expenses
leading to a partial reimbursement. On the other hand, if results are
poor following from high losses the reinsurer may want some compensa-
tion. Profit share agreements and variable (sliding-scale) commissions
discussed in the next section allow for a more flexible adjustment of the
commission.
Contingent Commission (or Profit Commission) is defined as “an al-
lowance payable to the ceding company in addition to the normal ceding
commission allowance. It is a pre-determined percentage of the rein-
surer’s net profits after a charge for the reinsurer’s overhead, derived
from the subject treaty4
.” For the purpose of this terminology the for-
mula to derive the profit commission Cprofit is given by means of a
percentage cprofit ∈ [0, 1] of the net profit as follows5
Cprofit = Cfix + max 0, Pceded − E − Cfix − Lceded · cprofit , (13.2)
where Cfix is a fixed commission given by Equation (13.1) and Pceded
are the ceded written premium, , E the reinsurer’s expenses, and and
Lceded ceded losses (given by the ceded claims), respectively. Note that
the formula clearly reveals that only the positive profit is taken into
account, that is, if the net profit is negative, the cedent does not get
any allowance additional to the fixed commission. Moreover for the
parametrization it is important to mention that the expenses E of the
reinsurer are given by a cost (or expense) rate eRI of the premium
received, explicitly,
E = eRI · Pceded . (13.3)
We exemplify the idea of profit sharing commissions by returning to
the example in Section 13.1.56
with one modification: Due to heavy
competition the direct insurer is forced to lower his premium income by
a percentage of the original premium in order to maintain the accident
line of business.
Example: We consider the quota share treaty from the example in
above with a reduced written premium of 90 million rather than the
original 100 million. Let us assume for the moment that commission is
based on the fixed commission strategy with 30% commission rate as
4source: http://www.captive.com/service/signetstar/GlosRein.html
5TODO: Adapt variable names to make them consistent in the whole document.
6TODO: Define an example environment so that direct references are possible.

before. Without doing any explicit calculations, we easily observe that
the reinsurer gains a marginal profit (neglecting his expenses) realized
at the expense of the direct insurer’s profit owing to the disparity of
commission ratio and cost ratio > 30%. Nevertheless, the reinsurer
does not want to share in the economic inefficiency of the primary
insurer and may expect a better profit rate. Hence, the reinsurer on
his part suggests a profit commission strategy on the basis of a 10%
fixed commission rate and the expectation to get a net profit after profit
commission of 2.5 million. Presetting the reinsurer’s expenses to 0.25
million, the profit commission rate may accordingly be contractually
specified by the expected net profit of the reinsurer
netProfit = Pceded − E − Cfix − Lceded = 5.0 million . (13.4)
leading to a profit share of 50%, hence cprofit = 0.5
Figure 13.4 illustrates the parameters that have to be specified by the
user in the corresponding parametrization form after selecting the Com-
mission Type Profit Commission.
Figure 13.4: Parameters for profit commission strategy
The parameters commission ratio and Profit Commission Ratio
correspond to the variables cfix and cprofit used in Equations (13.1)&(13.2).

The expense rate of the reinsurer eRI is stored in the parameter Cost
Ratio R/I to compute the reinsurer’s expenses due to formula (13.3).
If Loss Carried Forward is enabled by clicking the checkmark, we
are left with another parameter Initial Loss Carried Forward that
is not included in equation (13.2). The motivation for including the
feature Loss Carried Forward into the commission strategy is given
by the request of the reinsurer to settle his losses from the reinsurance
treaty with future profits in subsequent periods resulting in a diminish
of the “commissionable” profit that is given for equation (13.2) accord-
ing to
comProfit := max 0, netProfit , netProfit = Pceded−E−Cfix−Lceded .
(13.5)
In the modified situation, a mathematically rigorous derivation of the
commissionable profit is based on a simple recursion in a multiple pe-
riod model with periods n ∈ {0, 1, . . . , N} allowing for a loss carry-over
of period n to period n + 1 for all n = 0, . . . , N − 1. The variables in
formula (13.2) thus have to be indexed by the respective period they
belong to resulting in
Pceded → P
(n)
ceded , E → E(n)
, Cfix → C
(n)
fix , Lceded → L
(n)
ceded .
Rather than using the net profit of the reinsurer to compute the com-
missionable profit we now use a modified net profit denoted modProfit(n)
and characterized by an additional term for the losses (negative profit)
from the preceding period n − 1. With the above preparations the
equation for the modified net profit in period n + 1 is expressed for all
n ≥ 0 as
modProfit(n+1)
= P
(n+1)
ceded − E(n+1)
− C
(n+1)
fix − L
(n+1)
ceded + min 0, modProfit(n)
.(13.6)
The above equation recursively defines the sequence of modified net
profits {modProfit(n)
}n≥1 and can be solved as soon as the initial con-
dition modProfit(0)
is given. Now the additional parameter Initial
Loss Carried Forward comes into play by using the thereby prede-
termined value in order to define
modProfit(0)
= P
(0)
ceded−E(0)
−C
(0)
fix −L
(0)
ceded−{Initial Loss Carried Forward} .
Note that subtracting the last term on the right hand side of the above
equation is completely consistent with equation (13.6) in that losses are
in general defined by negative profits. We furthermore remark that the

approach is carried out from the reinsurer’s perspective. As a natural
implication the user has to be aware of the fact that the parameter
Initial Loss Carried Forward in the user parametrization stands
for the loss of the reinsurer.7
In a last step we define the commissionable profit comProfit(n)
for pe-
riod n similar to (13.5) according to
comProfit(n)
= max 0, modProfit(n)
, n ≥ 0 ,
that is used to define the profit commission C
(n)
profit. The overall formula
for the profit commission that is payable for period n hence reads
C
(n)
profit = C
(n)
fix + comProfit(n)
· cprofit . (13.7)
Note that cost ratio eRI, fixed rate cfix and profit rate cprofit are con-
stants that are given independently of the period n, but the fixed com-
mission and the reinsurer’s expenses expressed as
C
(n)
fix = cfix · P
(n)
ceded , E(n)
= eRI · P
(n)
ceded .
do depend on the period by the ceded written premium.
Sliding Scale Commission
The sliding-scale commission is another instrument to effectively en-
courage the direct insurer to influence the results of the reinsurance
contract by his underwriting policy, appropriate risk selection, rating,
etc. It may be considered as a kind of “provisional” commission as the
amount directly depends on the result of the ceded business indicated
by the loss ratio of the ceded business
lceded :=
Lceded
Pceded
∈ R0
+
in a given calendar or cedent year. In so doing, the ceding commission
Cslide given by
Cslide = cslide · Pceded
is decreasingly linked to the loss ratio by defining the sliding commis-
sion rate cslide = cslide(lceded) as a function of the loss ratio lceded and
stipulating
l
(1)
ceded < l
(2)
ceded =⇒ cslide(l
(1)
ceded) ≥ cslide(l
(2)
ceded) .
7TODO: clarify if initial loss carried forward may be negative

In general, the postulation may be realized by using any monotoni-
cally decreasing function, practical purposes however will delimitate
the choice to a clearly arranged amount. Easy and safe to handle
implementations for instance are given by continuous piecewise linear
functions defined by a finite number of tuples . The implementation
in PillarOne is built on another widely-used class of functions char-
acterized by piecewise constancy though at the expense of right-sided
continuity. Figure 13.5 shows a typical left-continuous step-function
(given by the sum of characteristic functions of disjoint subsets) that
may be used to generate a commission rate. As loss ratios are elements
of R+
0 , we are considering step-functions on the non-negative axis that
may be entirely defined by a finite number of tuples with jump dis-
continuities and corresponding values together with an initial provision
rate at lceded = 0.
Figure 13.5: Typical step-function for Sliding Scale Commission.
After selecting Sliding Scale Commission the parametrization form
simply has to be filled by the so-called commission bands as illustrated
in Figure 13.6a. To this end, the corresponding values are entered into
the form that is shown in Figure 13.6b obtained by double-clicking on
the blue marked cell next to Commission Bands8
.
8TODO: Comparison of sliding and profit commission

(a) Sliding Scale Commission
(b) Commission Bands
Figure 13.6: Parameters for sliding scale commission.
The values shown in Figure 13.6 correspond to the step-function as
displayed by Figure 13.5.
Note: The first entry in Commission Bands has to be given by the
zero loss ratio otherwise evoking a validation error. To avoid mistakes,
the loss ratios have to be entered in strictly increasing order. Further-
more, the step-function specified by the commission bands has to be
monotonically decreasing which is a reasonable settlement in practice.
Bouquet Commission
In the preceding sections we have discussed different commission strate-
gies so far considered as integral part of each reinsurance contract.
RiskAnalytics supplies an extended implementation thereof by addi-
tionally providing the allocation of a selected commission strategy to a
bundle of reinsurance treaties.
To this end, the subcomponent Bouquet Commissions is considered
as the second structural element of the business component Reinsur-
ance, respectively Reinsurance Market. It allows for dynamically
adding (one or several) commission strategies that are applied to a
bundle of reinsurance contracts .

Figure 13.7: Subcomponent Bouquet Commissions
As usual, a new segment is created by right-clicking on Bouquet Com-
missions, selecting Add and entering the dedicated name. Each seg-
ment consists of two parameters Commission and Aﬀected Rein-
surance Contracts permitting to select the commission type from the
list of implemented commission strategies and the designated reinsur-
ance contracts by opting for None, All, or Selection. In the latter
situation the applicable contracts are chosen by double clicking on
the right cell, setting the row count in the tab to the number of con-
tracts and picking from the predeﬁned reinsurance treaties.
The computation of the amount of commission is accomplished as de-
scribed in the preceding sections implying the same set of predeter-
mined parameters that are associated to the particular commission
strategy. The important feature intrinsic to the component Bouquet
Commissions as an entity may be described best by the hierarchic
application of the single segments with respect to the selected reinsur-
ance contract bundles: For each contract from the union of all contract
bundles commission is allowed once only with top down priority. In
doing so, commissions that are derived from single contracts within the
component Reinsurance Treaties (respectively Reinsurance Pro-
gram) are left unconsidered. This may be mathematically expressed by
the sequence of contract bouquets B1, B2, . . . , Bn hierarchically ordered
according to the entry in the parametrization form. The commission
strategy predetermined in segment i = 1, . . . , n is then applied to the

reduced set
Bi ∪i−1
j=1 (Bi ∩ Bj)
rather than Bi excluding duplex allowance. To exemplify the idea let
us consider the parametrization as given in Figure 13.7 that is based
on two reinsurance contracts “quota share motor hull” and “quota
share accident”, and two bouquet commissions strategies “bouquet
commission motor” applicable to “quota share motor hull” and “bou-
quet commission all” applicable to both reinsurance treaties. In the
user parametrization “bouquet commission motor” is the foremost bun-
dle resulting in a sliding scale commission for “quota share motor hull”
that is added to the commission inherent to the reinsurance treaty. The
next executable segment “bouquet commission all” is applied only to
“quota share accident” excluding the already considered treaty “quota
share motor hull”.
13.2 Proportional Reinsurance
The following proportional reinsurance components are available in
RiskAnalytics:
• Quota share with various options for setting limits
• Surplus
• Loss portfolio transfer
The order in which the claims are processed by a proportional contract
does not matter, as long as there are no non-linear features added to
a proportional contract. If there are limits involved, then we have to
attach dates to the claims; both incurred and paid. This way the claims
can be sorted and then properly be processed by the contract limits.
Instead of dates, we can also work with fractions of a simulation period.
Note: Working with fractions of periods is computationally more effi-
cient, and as long as we are treating all days in a period equally – no
weekends or banking holidays – this is equivalent to working with dates.
Attritional claims distributions are calibrated using the sum of many
small claims with different incurred dates, but all lying in a well-defined
time period. So by definition, an attritional claim does not have an in-
curred date since it is an aggregate of many small claims. In order to
be able to model more complicated reinsurance programs and propor-
tional contracts with limits, we nevertheless associate an incurred date

13.2. PROPORTIONAL REINSURANCE 135
with attritional claims. To learn how to set the date of an attritional
claim, see Section 10.1.2.
Reinsurance components for proportional contracts process all claim
types (see Table 13.1).
attritional single claims event claims
quota share x x x
surplus x (see ) x x (see )
loss portfolio transfer x x x
Table 13.1: Claims types processed by proportional reinsurance com-
ponents
13.2.1 Quota Share
The quota share is a simple form of proportional reinsurance, and has
many extensions for setting limits:
• annual aggregate limit (AAL)
• annual aggregate deductible (AAD)
• event limit
Some of these limits can be combined, e. g. AAD and AAL.
13.2.2 Surplus
Surplus reinsurance is a more advanced and more complicated form of
proportional reinsurance. In contrast to quota share reinsurance, the
portion covered by the reinsurer depends on the sum insured9
speciﬁed
for the underlying insured risks. All the risks with sum insured up to
a certain retention are fully covered by the reinsured - the exceeding
part up to a certain limit is then covered by the reinsurer. The portion
of the claim ceded to the reinsurer is given by the ratio of the risk ceded
divided by the total risk.
As a result, the modeling of surplus reinsurance requires additional
information - a manifest link of the claims to the underlying risks. We
will give details on how this link can be provided. Note that for the
9or other quantities used to characterize the underlying risk such as ’probable
maximum loss’ (PML).

other reinsurance treaty types modeled in RiskAnalytics no such link
is needed.
We see two different approaches to model the link between risk and
claims information:
• Attach risk information while generating the claims: Typically,
start with the risk information and use risk-dependent character-
istics for simulating the claims. This method is called ‘risk to
band’.
• Attach risk information after generating the claims: Here, we can
start with standard claims generators and try to map the claims
to the risks such that suitable characteristics on the risk portfolio
are met. This method is called ‘Sum insured generator’.
The risk information is captured in the underwriting segments (see
section 10.1.1) and in the claims generators one can refer to the ex-
posure information by selecting either one of the above methods (see
section 10.1.3.
Generally, we consider the first approach more sound and we suggest
using this whenever possible. However, more detailed data (including
claims per risk or per risk class statistics) are needed for a calibration
of such risk-dependent claims generators. Therefore, we opt for the
second approach in case not all data are available for a calibration of
risk-dependent claims generators. Here, suitable ‘RiskAllocator’ com-
ponents are used which are typically based on more general risk port-
folio characteristics.
In addition to the general contract parameters, the surplus-specific pa-
rameters are:
• Retention (R) of the surplus contract. It must be specified in
the same units as the sum insured.
• Number of lines (L) the contract covers. This implies that the
contract covers up to a limit of L · R.
• The default ceded loss share. This parameter is used to ced
claims for which no risk information is available.
For a risk with sum insured v the proportion of the claim ceded to the
reinsurer is then given by
ρ(v) =
min(L · R, (v − R)+)
v
(13.8)

13.3. NON-PROPORTIONAL REINSURANCE 137
For each claim, this risk information (v) is used to compute the fraction
ceded given by the above formula (13.8). For losses for which no risk
information is found, the default ceded loss share is used as the fraction
ceded.
Note: At the moment, different retentions specified for different claims
types can only be modeled by using different surplus components and
allocating the associated claims accordingly. Different claims types and
different retentions should be considered when setting up the model.
However, work on generalizing the component to allow for specifying
different retentions for different claims types is in progress.
13.2.3 Loss portfolio transfer
The loss portfolio transfer is an quota share on reserves. On the user
interface of RiskAnalytics it looks exactly like a quota share without
the additional limits feature. It is up to the user to map the appropriate
reserves into this contract by selecting the type ‘Reserves’ in the setion
Cover.
13.3 Non-Proportional Reinsurance
The following non-proportional reinsurance components are available
in RiskAnalytics:
• working excess of loss (WXL)
• catastrophe excess of loss (CatXL or CXL)
• stop loss
• adverse development cover
• Goldorak
• Finite Re
10
Aggregate event claims are not processed by the WXL component. In
contrast, the CXL does not process attritional and single claims. A
reinsurance component which does not process a particular claim type
10TODO: We need some explanation on per risk, per event cover, where appro-
priate.

simply feeds the gross claims (the input) of this type directly to the
net claims (the output).
attritional single claims event claims
WXL x
CXL x
stop loss x x x
adverse development cover x x x
Goldorak11
(x) (x) x
Finite Re x x x
Table 13.2: Claims types processed by non-proportional reinsurance
components
Unlike proportional reinsurance components (Table 13.1), which pro-
cess any claim type, non-proportional reinsurance components can only
process some claim types (see Table 13.2).
13.3.1 Working Excess of Loss
13.3.2 Cat-XL
13.3.3 Stop Loss
13.3.4 Adverse Development cover
13.3.5 Goldorak
The goldorak contract is a reinsurance type mainly used in the French
market. It is a mixture of an Cat-XL (cf. Section 13.3.2) and a Stop
Loss (cf. Section 13.3.3) i. e. depending on a given threshold it either
behaves as CXL or SL. Thus for this type of contract we need all
the parameters of the two individual treaties as well as an additional
threshold parameter according to which the effective sub-contract is
chosen.
Goldorak parameters:
• Premium base
• Premium
11Depending on the effective sub-contract only event claims may be affected.

13.3. NON-PROPORTIONAL REINSURANCE 139
• Goldorak SL Threshold
The parameters Premium base and Premium have already been ex-
plained above. The Goldorak SL Threshold determines the absolute
value of the sum of all claims above which the specified SL sub-contract
is applied. If the total sum of all claims is smaller than this threshold
the CXL is applied. Thus except the premium related parameters all
necessary remaining parameters of the sub-contracts are listed below.
CXL parameters:
• (CXL) attachment point
• (CXL) limit
• (CXL) aggregate limit
• (CXL) reinstatement premiums
Stop loss parameters:
• Stop loss attachment point
• Stop loss limit
Typically, the Goldorak SL Threshold is equal to the stop loss limit.
13.3.6 Finite Reinsurance Contract
The finite reinsurance contract is a multi-period contract consisting of
two parts: an experience account and a risk component.
Input
Model Inputs:
For each period t, the finite reinsurance component re-
ceives a list of claims C. These can be either the ceded
or the net claims produced by another reinsurance com-
ponent. This choice is decided by the model developer
and cannot be changed at runtime by a model user.
User Inputs:
T he total premium P(t) of the finite reinsurance con-
tract collected in the time period t (for 0 ≤ t)

Figure 13.8: An example of ﬁnite reinsurance output
The fraction of premium α(t) which is allocated to
the experience account.
Output
Experience Account:
premium Pea(t)
claims Cea(t)
balance B(t) of the experience account
Risk Part:
premium Prisk(t)
claims Crisk(t)
balance Rrisk(t) from the outset until the end of period
t
A sample ﬁnite reinsurance output for three time periods is
shown in Figure 13.11.
Validation
none implemented, but should be:
P(t) > 0
0 ≤ α(t) ≤ 1
Calculation
• Pea(t) = a(t) · P(t)
• Prisk(t) = (1 − a(t)) · P(t)

13.4. REINSURANCE PROGRAMS 141
• Cea(t) = min{B(t − 1) + Pea(t), C(t)}
• Crisk(t) = C(t) − Cea(t)
• B(t) = B(t − 1) + Pea(t) − Cea(t)
• Rrisk(t) = Rrisk(t − 1) + Prisk(t) − Crisk(t)
Note:
Both premiums (Pea & Prisk) are deterministic since α and
P are.
We take B(t − 1) and Rrisk(t − 1) to be 0 for time periods
t − 1 before the contract started.
The deﬁnition of Cea(t) ensures that B(t) ≥ 0.
13.4 Reinsurance Programs
For the examples in the following reinsurance sections, we will work
with a property and a motor hull line of business. The claims which we
associate to the property line are generated using three diﬀerent types
of claims generators:
• attritional claims using an annual aggregate distribution (denoted
Propattr)
• single claims using a frequency-severity model (denoted Propsingle)
• aggregate cat event claims using a frequency-severity model (Propcat)
The claims which we associate to the motor hull are generated using
two types of claims generators:
• attritional claims using an annual aggregate distribution (denoted
Mattr)
• single claims using a frequency-severity model (denoted Msingle)
Let us assume that we want to model the reinsurance structure for
the property line shown in Figure 13.9. The attritional claims from
Propattr are not processed by the WXL and CXL components.
Note: This has implications for calibrating the distribution of the at-
tritional claims generator. Only claims which are completely in the
retention — in this example, below 1 Mio or possibly even less than 1

Figure 13.9: Excess of loss

Mio to have a safety margin — should be used to determine the distri-
bution.
The inuring priority, an integer value > 0, is used to express the
order in which the reinsurance contracts process claims. If two rein-
surance contracts need to receive the same claims information, then
their inuring priority needs to be set to the same value. Thus, in our
example, the two WXL layers must have the same inuring priority in
order to both receive the claims from Propsingle.
As in reality, each layer is a separate contract. This has the advantage
that we can vary some of the parameters per layer, e. g. how much is
placed or with which reinsurer it is placed. The latter is only necessary
if we want to model reinsurance default. A disadvantage of model-
ing each layer as a separate contract is that PillarOne cannot easily
validate whether the retentions and covers of the different layers have
meaningful values. It is the user’s responsiblity to make sure that the
retention of the second layer (5 Mio in our example) is not below the
sum of the retention plus the cover of the first layer. Theoretically,
the retention of the second layer could be larger than 5 Mio; but in
practice, it does not make sense to have a gap between consecutive
layers. During the initial parametrization these conditions are usually
observed. The danger is that during a reinsurance optimization process,
the retention and layers are changed individually. It is thus necessary
to check at least the parameters of all other contracts with the same
inuring priority.
Reinsurance contracts are usually grouped within a reinsurance pro-
gram. PillarOne can model reinsurance programs either per line of
business, or globally with multiline coverage, or even using a mixture
of both concepts.
PillarOne models reinsurance programs as either ‘static’, with a fixed
number of serial, ordered contracts, or as ‘dynamic’, allowing the user
to add and remove contracts within the graphical user interface and to
define the order in which they are applied.
The GUI allows each contract’s ‘strategy’12
to be specified (example
further below). Currently implemented strategies13
(and the abbrevia-
tions we employ for them, if any) are given in Figure 13.4.14
12In business language, the ‘contract type’. As a PillarOne (model) developer,
these are ContractStrategy classes, since they embody a methodological choice; we
also refer to them as ‘reinsurance components’ or just ‘components’.
13we list the strategies that are of general interest; trivial, WCXL and Aggrega-
teXL are not discussed here.
14TODO: introduce a ContractStrategies figure near here

13.4.1 Simple Reinsurance Programs
Consider a reinsurance program with a fixed number of three reinsur-
ance contracts, which are processed in serial order:
• Each of the three reinsurance contracts can select its own rein-
surance component for one of the available contract types as in
Figure 13.4. This ‘strategy’ (contract type/component) selection
is made in the GUI under Parameterization → Model Name → in
the left pane, and under Reinsurance Program → Contract Name
→ Contract Type → Type in the right pane.
• Net claims of contract 1 will be transfered to contract 2, in which
those formerly net claims will be interpreted as gross claims.
This type of reinsurance program is provided in the Capital Eagle
Model (where the parameter inuring priority is not available because
the processing order is predetermined).
Alternatively to this type of static reinsurance program, with a fixed
order and number of contracts, there is also a dynamic version avail-
able. The dynamic version provides the user with greater flexibility in
determining both the number of contracts, and the order in which they
are processed. This dynamic concept is provided in the model Podra
and explained in the following section.
13.4.2 Dynamic Reinsurance Programs
A dynamic reinsurance program enables the user to specify the number
and order of contracts with the parameterization.
• In order to add an additional contract to the reinsurance program,
right click on reinsurance program and select ‘Add’.
• To remove a contract, right click on it and select ‘Remove’.
• Each reinsurance contract can select its own reinsurance compo-
nent for one of the available contract types given in Figure 13.4.
The procedure is described in the previous Section (13.4.1).
• The order of the contracts is defined with the parameter inuring
priority, which assumes positive integer values.

Figure 13.10: Adding or removing a contract from a dynamic reinsur-
ance program
– The contract with the smallest inuring priority will be the
first executed. If several contracts have the same inuring
priority, they will be applied on the same ‘gross’ claims and
underwriting figures.
– If a program has several excess of loss (XL) layers, add as
many contracts as layers are required15
and set the inuring
priority to an equal number.
– In order to keep a program flexible for extensions, one can
use e. g. multiples of ten (10, 20, 30, . . . ) as inuring pri-
orities. The gaps leave room to place further contracts as
needed within the processing sequence.
15TODO: clarify this passage! Does it mean: ‘add as many contracts as each layer
requires, using ascending inuring priorities for subsequent layers and equal inuring
priorities for each contract within the same layer’?

If a model shouldn’t allow a user to edit the number and order of
contracts, it should use a static program as described in the previous
Section 13.4.1.
13.4.3 Dynamic Multiline Reinsurance Programs
A dynamic multiline reinsurance program is not part of any line of busi-
ness. However, the dynamic multiline reinsurance program is usually
attached on the same level as lines of business in the model tree.
• Dynamic multiline reinsurance programs have the same proper-
ties as dynamic reinsurance programs.
• Each contract has an additional ‘covered lines’ property. Double-
click on the list16
in order to select the covered lines using combo
boxes.
13.4.4 Multiline Reinsurance Contract with Default
This contract allows to define the lines covered and the reinsurer acting
as counterparty on the contract.
Once the reinsurer is defined, it is possible to model the reinsurer’s
probability of defaulting. The model should contain a reinsurer rating
table and default probabilities per rating. If a reinsurer defaults, all
contracts with this reinsurer will stop ceding claims.
If a contract is placed at different reinsurers, this can be modeled by
selecting combinations of ‘covered by reinsurer’ and ‘reinsurer’.
13.4.5 Finite Reinsurance Contract
The finite reinsurance contract is a multi-period contract consiting of
two parts: an experience account and a risk component.
Input
Model Inputs:
For each period t, the finite reinsurance component re-
ceives a list of claims C. These can be either the ceded
or the net claims produced by another reinsurance com-
ponent. This choice is decided by the model developer
and cannot be changed at runtime by a model user.
16TODO: the list of contracts?

Figure 13.11: An example of finite reinsurance output
User Inputs:
the total premium P(t) of the finite reinsurance con-
tract collected in the time period t (for 0 ≤ t)
The fraction of premium α(t) which is allocated to
the experience account.
Output
Experience Account:
premium Pea(t)
claims Cea(t)
balance B(t) of the experience account
Risk Part:
premium Prisk(t)
claims Crisk(t)
balance Rrisk(t) from the outset until the end of period
t
A sample finite reinsurance output for three time periods is
shown in Figure 13.11.
Validation
none implemented, but should be:
P(t) > 0
0 ≤ α(t) ≤ 1
Calculation

• Pea(t) = a(t) · P(t)
• Prisk(t) = (1 − a(t)) · P(t)
• Cea(t) = min{B(t − 1) + Pea(t), C(t)}
• Crisk(t) = C(t) − Cea(t)
• B(t) = B(t − 1) + Pea(t) − Cea(t)
• Rrisk(t) = Rrisk(t − 1) + Prisk(t) − Crisk(t)
Note:
Both premiums (Pea & Prisk) are deterministic since α and
P are.
We take B(t − 1) and Rrisk(t − 1) to be 0 for time periods
t − 1 before the contract started.
The deﬁnition of Cea(t) ensures that B(t) ≥ 0.

Chapter 14
Modelling non-life
reserves
After successfully setting up a model for premium risks modelling the
reserve risks is certainly important. Reserve generators are accessible
similar to claims generators e. g. within the Podra model there exists a
Dynamic Composed Component Reserve Generators. By selecting add
in the context menu of Reserve Generators a reserve generator can be
added. It consists of a descriptive name and
• Initial Reserves
• Reserves Model
• Reserve Distribution
• Period Payment Portion
explained in the following sections.
We distinguish between two diﬀerent methods,
• Calendar Year Method
• Pay-Out Pattern Method
The Calendar Year Method is derived from standard reserving prin-
ciples. A calendar year starts with knowing about a reserve portfolio
consisting of real liabilities and the initial reserve representing their
estimated volume. We aim in tracing the risk during one period or
149

150 CHAPTER 14. MODELLING NON-LIFE RESERVES
calendar year. Note: The following can be equally well applied to a
model using a quarter or monthly period length. Within one calendar
year reserve loss payments are made and and the outgoing reserve is
set. Deviations of the sum of reserve loss payments and outgoing re-
serves from the initial reserves may be called risk. So we generate the
mentioned sum of payments and outgoing reserves as a random vari-
able. The initial reserve of the next period or next calendar year can
be set to the outgoing reserve of the current. Pay-out ratios are fixed
and can be set for reserves and first year losses seperately.
The Pay-Out Pattern Method is derived from the observed pay-out
patterns. Depending on the pay-out pattern each loss is allocated to
the model periods. The reserves can be set as the sum of all future loss
payments of the preceding periods.
14.1 Calendar Year Method
14.1.1 Initial Reserves
The Initial Reserves of the calendar year are currently handeled
within the reserve generator component. They are not tracked by an
individual component like the Underwriting Information in the claims
generators. Therefore the parameter initial reserves is used.
14.1.2 Reserves Model
There exist three types of the reserve model, depending on the usage
of the initial reserves value. They are Absolute, Initial Reserves
and Prior Period. All of them having a modifyable reserve distribu-
tion. The type absolute defines the result of the reserve distribution
as an absolute value of paid plus reserved. Using initial reserves scales
(multiplies) the result of the reserve distribution by the initial reserve.
And the Prior Period method scales the reserve distribution with the
outgoing reserve of the prior period when available resp. the initial
reserve in the first period.
14.1.3 Reserve Distribution
Please refer to Subsection 10.1.2 for details on modifyable reserve dis-
tributions.

14.2. PAY-OUT PATTERN METHOD 151
14.1.4 Period Payment Portion
The Period Payment Portion gives the option to split the generated
value for the sum of paid and reserved to these values. It is the relative
share of the payment in the recent period.
14.2 Pay-out pattern method
The Pay-out pattern method generates a pay out pattern with each
claim.

152 CHAPTER 14. MODELLING NON-LIFE RESERVES

Chapter 15
ALM generators
Asset libility mismatch (ALM) risk is an important part of the insurer’s
set of risks. The models for technical insurance risks are modeled on a
very granular level. To model the ALM risk, it is necessary to incorpo-
rate an economic scenario generator (ESG). The outcome, an ALM risk
random distribution, can be put in RiskAnalytics using the ALM gen-
erators component. The component is dynamic, so that several ALM
generators can be used in a model.
The parametrization of ALM generators is similar to that of attritional
claims.
Usually, ALM generators are of type Absolute, so the generated value of
the modiﬁable distribution is stored as the ALM end of period value.
The initial volume is stored in the appropriate parameter. Additional
types may be introduced to scale the distribution by Absolute Result,
Relative Value or Relative Result.
153

154 CHAPTER 15. ALM GENERATORS

Chapter 16
Modelling an Insurance
Group
As is the case for single corporations, the consolidated insurance group
must meet group solvency regulatory requirements to preserve finan-
cial stability of the group and protect policy holders and beneficia-
ries.1
Within the European Union, large-scale changes are in progress
based on the proposal of the Solvency II Framework Directive, en-
tailing a shift of competence for group supervision from national solo-
supervisory authorities to a genuine Group Supervisor on the European
level ([1, 5, 15, 17]).
There are currently two internationally prevalent approaches to mod-
elling relevant group risks, exhibiting varying perspectives. A very nice
outline of the basic principles of these approaches is given in Circu-
lar 2008/44 of FinMa ([6, 7]), from which we quote:
The first approach models the risks of a group on a con-
solidated basis as if the group were a single legal entity
(“consolidated group modeling”). As a consequence, the
lead supervisor can determine whether the group satisfies
capital adequacy requirements as based on its external lia-
bilities. In so doing, intra-group liabilities are not modeled
as it is implicitly assumed that assets are freely transferable
within the group.
1An Insurance Group consists of several insurance companies, while an In-
surance Conglomerate must own both insurance and banking companies.
155

156 CHAPTER 16. MODELLING AN INSURANCE GROUP
The second approach is based on modeling the risks of the
individual legal entities of a group, possibly forming a clus-
ter, and thus models the relations between these units in
addition to the external relations (“granular group model-
ing”). In this second method uniform rules are applied to
assess the risks of the assets and liabilities of the individual
legal entities, in addition to the risks resulting from the rela-
tions within the group. This second method enables FinMa,
in its capacity of lead supervisor of the group, to determine
whether any risk potential is posed to policyholders and
the financial stability of the group by individual parts of
the group itself for other parts of the group or for the group
as a whole, and whether the individual parts of the group
aid the others as needed or whether other risk-mitigating
measures are available.
In the SST it is assumed that granular group modeling is
applied, with consolidated group modeling additionally be-
ing permitted upon application by the group with FINMA
or being requested by FINMA. The “group SST” is based
on granular group modeling, which can be supplemented by
consolidated group modeling.
The “Multi Company Model” provided by RiskAnalytics may serve
as an appropriate internal model for granular determination, quantifi-
cation, and analysis of all relevant risks of insurance conglomerates.
In what follows we discuss the implementation of the model, its find-
ings in extension to the Podra model, and the internal processing of
data related to specific group segments. Instructions for creating a
parametrization in the group model are given in Chapter 6.
16.1 Company Segments
As usual, a new insurance company may be created by right-clicking on
Companies and selecting Add in the appearing context menu. An-
other possibility is to right-click on an existing company and choose
Duplicate in the context menu leading to a one-to-one copy of the ex-
isting segment. Each company segment consists of a rating parameter
that has to be selected from a list with rating values ranging from AAA
to D. Rating parameters play an important role for the quantification

16.1. COMPANY SEGMENTS 157
of contingency risks, particularly in regard to the Solvency II Frame-
work a precautionary approach in selecting business partners should
be taken. To this end, credit-worthiness and solvency information from
rating agencies may serve as an important mean to guarantee long-term
competitive advantages. For a comprehensive discussion about the im-
portance of rating for reinsurances, the interested reader is referred
to [4].
Each predefined company segment represents a legal entity2
belonging
to the insurance group built by the union of all the company segments.
Hence, in contrast to the Podra model that provides a tool for modeling
the exposure of one insurance company only, we now have to specify the
respective insurance unit when editing risks, reinsurance contracts, etc.
In so doing, we obtain a consistent possibility of correct valuation of
the assets and all liabilities of all the legal units of the insurance group
and modeling all the relevant risks of the individual legal units. In view
of the fact that capital and risk transfers, such as loans or reinsurance
contracts, are frequently used among the legal entities of an insurance
group, the “Multi Company Model” provides an important and sound
base for managing the risks of groups on a granular perspective level.
The feature of including multiple legal units into the model exhibits its
utility after running the simulation and opening the preselected result
descriptor. For the sake of illustration we will consider an example
below, for starters we focus on the result template as shown in Fig-
ure 16.1.
In the template we nicely see that the result descriptor shows the ac-
tivities of each of the single units of the group separately. As outlined
in Chapter 8 the model does not define which output variables have to
be collected during the simulation. Instead, the user has to determine
before starting the simulation if at all and to which granular level (rang-
ing from the coarse-grained Aggregated to the fine grained Single)
he wants to collect each of the positions listed below subcomponents
(which is a placeholder for the single entities). The items that are
shown in the result tree-view may be roughly separated into claims,
underwriting information and financial results. In order to apply the
model correctly we have to understand how the resulting items listed
in Figure 16.1 are fed into the company segments. This is explained
2Or a so called Cluster, i. e. well-defined set of legal entities. Clustering is
usually allowed for non-significant legal entities or where some legal entities cover
the same risk but consist of two carriers. The latter might be the case if one legal
entity is funded by a SPV (”Special Purpose Vehicle”); or for fully fronted business.

Figure 16.1: MultiCompany: Results for segments of component
Companies
in full detail in Section 16.2. Another issue worth discussing is how
claims3
and underwriting information are split up into
• gross claims and gross underwriting information,
• gross claims of primary insurer and gross underwriting informa-
tion of primary insurer,
• gross claims of reinsurer and gross underwriting information of
reinsurer,
• ceded claims and ceded underwriting information,
• net claims and net underwriting information, and
• net claims of primary insurer and net claims of reinsurer.
This breakup of information is rooted in the fact that an insurance
company 4
may be fully licensed to transact general primary insurance
and reinsurance business.
3We restrict to claims and note that the following discussion applies to the
developed claims as well.
4We speak here of a single unit of the group and NOT of the group as an entity.

We close this section by exemplifying the aforementioned matter by
means of three imaginary companies “Mars Re”, “Venus” and “Pluto
Re”, each of them trading in the primary- as well as re-insurance busi-
ness. At first view the set up of the example may be a disincentive to
the user, however in anticipation of the following section it also gives an
idea of the internal handling of information. As will be clear below, the
example is constructed as a small tutorial where the user is requested
to create a parametrization in PillarOne leading to a simulation model
that renders the outlined results.
Example: The three insurance companies “Mars Re”, “Venus” and
“Pluto Re” are trading in different classes of business, contingently
purchasing reinsurance from one or several reinsurers. The contracts
(direct business with related reinsurance contracts) are shown in Ta-
ble 16.1 below, where each column belongs to one class of business.
line of business: motor Venus motor Mars Re motor Pluto Re accident Mars Re
direct insurer: Venus Mars Re Pluto Re Mars Re
reinsurance treaty: QS motor Venus QS motor Mars — QS accident Mars
reinsurer: Mars Re — — Pluto Re: 0.7, Venus: 0.3
Table 16.1: Insurance business activities and contractual relationships
Note that the last entry in the last column denotes a reinsurance con-
tract that is shared between two reinsurers registered with associated
portions. Moreover the line of business “motor Pluto Re” has no speci-
fied reinsurance contracts, whereas “motor Mars Re” reinsures its busi-
ness but with an reinsurer that is unknown here5
. Having listed all the
necessary information, we may process the incoming information of
claim burdens and underwriting segments and allocate it to the prede-
fined companies. In the next two tables we give a list of all the incoming
gross and ceded information allowing for calculating the profit of each
of the three companies in the group.
The attentive reader may have noticed that underwriting information
for the line “motor Venus” is listed twice in Table 16.2. This may result,
e. g. from a partition into motor third party and motor comprehensive
cover6
. As an exercise we evaluate the results for the single insurance
5This corresponds exactly to the parametrization where the user is not forced
to select a reinsurer from the list of companies in contrast to the lines of business
component.
6We are aware of the fact that subsuming such segments under one line of busi-
ness is a rather ‘quick and dirty’ approach.

written premium line of business
packet 1 1 mio motor Venus
packet 2 2 mio motor Mars Re
packet 3 0.5 mio motor Venus
packet 4 1.8 mio accident Mars Re
packet 5 0.05 mio motor Pluto Re
ceded written premium line of business reinsurance
packet 1 0.1 mio motor Venus QS motor Ven
packet 2 0.4 mio motor Mars Re QS motor Ma
packet 3 0.05 mio motor Venus QS motor Ven
packet 4 0.9 mio accident Mars Re QS accident M
Table 16.2: Incoming underwriting information: gross info (left side), ceded
info (right side)
claims line of business
packet 2 1.0 mio motor Mars Re
packet 4 1.2 mio accident Mars Re
packet 5 0.04 mio motor Pluto Re
ceded claims line of business reinsurance contract
packet 1 0.15 mio motor Venus QS motor Venus
packet 2 0.2 mio motor Mars Re QS motor Mars
packet 3 0.02 mio motor Venus QS motor Venus
packet 4 0.6 mio accident Mars Re QS accident Mars
Table 16.3: Incoming claims burden: gross claims (left side) and ceded
claims(right side)
units of the group that will be shown in the result descriptor when the
collector Aggregated is selected. To this end, the reader is invited to
1. compute the results by hand in order to understand the specific
characteristic of Companies and,
2. to practice the handling of the simulation tool by filling the
parametrization form of the “Multi Company Model” with pa-
rameters and values reflecting the situation given in Tables 16.1, 16.2
and 16.3.
After running the simulation the results can be taken from the result
template. In Figure 16.2 the aggregated results are illustrated for the
insurances “Mars Re” and “Pluto Re”, while for “Venus” the problem
is accomplished step-by-step.
We start our considerations with the remark that the business activity
of an insurance company is quantified by merging operations in the
direct insurance business with the reinsurance business implying for
the example that “Venus” not only obtains premiums from the left-
sided list in Table 16.2, but also from possible reinsurance business
listed on the right-hand side of Table 16.2. Explicitly: Subsequently

using the monetary unit one million, the total gross premium Pgross of
“Venus” is derived as the sum7
Pgross = P(P I)
gross + P(RI)
gross , P(P I)
gross = 1.5 , P(RI)
gross = 0.27 ,
where P(RI)
gross originates from the cession of the business line “acci-
dent Mars Re” (0.9 ceded premium) weighted with the “Venus”-share
of 0.3 in the reinsurance treaty. The resulting net premium Pnet =
Pgross −Pceded then results by subtracting from Pgross the total of ceded
premiums Pceded = 0.15 of “Venus”, and reporting also the direct in-
surer’s portion P(P I)
net of the net premium, we end up with
Pnet = 1.62 , P(P I)
net = 1.35 .
Note that the net results are not reported for exclusive reinsurance
business as by definition and excluding retrocession8
it corresponds to
P(RI)
gross.
In the same way we handle the designated commission where it is clear
that the commission in gross portfolios of direct insurance business is
zero by default. Moreover notice about the sign convention for com-
missions that becomes clear when compared to premiums. Following
the guidance for premiums we then obtain for gross, ceded and net
commissions Cgross, Cceded, Cnet
Cgross = −0.135 , Cceded = −0.03 , Cnet = Cgross−Cceded = −0.105 .
Splitting these results into exclusive reinsurance and primary insurance
business yields
C(RI)
gross = Cgross , C(P I)
net = −Cceded .
Table 16.3 finally supplies the results for the claims (or losses) denoted
by L. Using the above rules for sub- and super-indexing we end up
with
Lgross = L(P I)
gross + L(RI)
gross , L(P I)
gross = 1.7 , L(RI)
gross = 0.18
for the gross losses, Lceded = 0.17 for ceded claims and
Lnet = Lgross − Lceded = 1.71 , L(P I)
net = L(P I)
gross − Lceded = 1.53 .
for net results.
7We use the abbreviations PI and RI for primary insurer and reinsurer, respec-
tively.
8At this stage PillarOne does not allow for cover strategies that apply to pre-
defined reinsurance contracts.

16.2 Internal Processing of Data
9
For the understanding of the model it is of utmost importance to get
an overall picture of the internal handling of the information stemming
from the parametrization defined by the user. We will now discuss this
issue in full detail with the help of the Companies component pro-
cessing information about claims, underwriting segments, and financial
results.
The value of Financial Results as listed in Figure 16.1) is evaluated
in a direct way using the fact that each segment of ALM Generators
has a parameter Company forcing the user to attach to one segment
of Companies. By this means progression is straightforward in that
each segment of ALM Generators generates output value(s) stored
in a variable that is marked with the associated company. We finally
obtain a list of results collecting outputs of all the ALM segments. In
a next step this list is sent to all segments of the component Compa-
nies. To put it roughly, for each of these segments the incoming list
is filtered with respect to the company-marker that is attached to the
result variables. If the company under consideration is “Venus” we will
pass through the list and collect all results that are marked with com-
pany “Venus”, whereas the leftover is discarded. The “Venus”-labeled
results are summed up and finally prepared by the dedicated result
descriptor.
Handling of gross claims is slightly more sophisticated in that segments
of Claims Generators are not attached to the component Compa-
nies directly. Instead, interrelation is given indirectly via the compo-
nent Lines Of Business acting as a kind of intermediary. As nicely
illustrated in Figure 6.1, each segment of Lines of Business has two
parameters that are of interest here: The parameter Company at-
taching the participating insurance unit to the dedicated business line,
and the parameter Line of Business Claims – Shares providing
the link between segments of Companies and Claims Generators.
Figures 16.3 and 16.4 10
give a rough sketch of internal handling of
the data that is based on the component-coupling as outlined before.
With these preparations it is easy to understand how gross claims are
processed: The claim packets are sent to all of the objects of Lines
of Business, where their member variable claim.line is instantiated
with the business line under consideration if and only if it is related to
9TODO: Where to place this section?
10TODO: This and the next figure need a revision. I am open for suggestions!

16.2. INTERNAL PROCESSING OF DATA 163
the peril (that is, the origin of the claim) by means of the parameter
Line of Business Claims. Hence ﬁltering of claims in the company
segments is carried out by means of the member variable claim.line
pointing to the business line with assigned parameter Company. For
managing of ceded claims we refer to Figure 16.4 and remark that un-
derwriting information is processed analogously to claims by using the
component Underwriting rather than Claims Generators (compare
Figure 6.1).

(a) Aggregated results for “Mars Re”

16.2. INTERNAL PROCESSING OF DATA 165
Claim Packet:
claim.amount = 500, claim.peril = motorSingle, claim.line = null
Segment ``motor single‘‘
Claims Generators with segments peril
if claim.peril in LineOfBusinessClaims
then claim.line = motor
Parameter LineOfBusinessClaims = [motor attritional (0.7), motor single (0.3)]
Parameter Company = venus
Claim Packets
if {Parameter Company} of claim.line equals venus
then claim.amount → ∑ gross claims
Claim Packets
Lines Of Business with segments line
Segment ``motor‘‘
Companies with segments company
Segment ``venus‘‘
Figure 16.3: Internal handling of gross claims in Companies

Claim Packet:
claim.amount = 500, claim.peril = motorSingle, claim.line = motor
if (claim.peril or claim.line) in Cover
then evaluate cededClaim.amount,
set cededClaim.line = claim.line, cededClaim.peril = claim.peril,
cededClaim.contract = quotaShareMotor
Parameter Cover = [line = motor]
Parameter Reinsurers = [mars (0.7), pluto (0.3)]
Claim Packets
if {Parameter Company} of cededClaim.line equals pluto
then cededClaim.amount → ∑ ceded Claims
else if pluto in {Parameter Reinsurers} of cededClaim.contract
then share*cededClaim.amount → ∑ gross claims
cededClaim Packets
Reinsurance Program with segments contract
Segment ``quota share motor‘‘
Companies with segments company
Segment ``pluto‘‘
Figure 16.4: Internal handling of ceded claims in Companies

Chapter 17
Introduction
This part of the RiskAnalytics documentation is meant for software
developers who want to change or extend business logic, or simply add
new features to the RiskAnalytics application. To develop code which
is maintainable and ﬁts well with the PillarOne framework, it helps
to understand the basic concepts which are described in Chapter 9.
Adopters of RiskAnalytics are free to modify source code, e.g. to
add features for their own or a client’s use. RiskAnalytics is released
under the GPL license, and hence, anything which is compliant with
this license is allowed.
If you would like some of your changes to be included in an oﬃcial re-
lease of RiskAnalytics, please get in touch with a core team member.1
1Code contribution to an open source project is by necessity discretionary, in
both directions: contributors should not reveal information that should remain
private to their enterprise, such as information from (or about) their clients, while
the core project team must exercise some degree of control to maintain the goals of
the project, such as commonality or performance requirements.
169

Chapter 18
Development
environment
First you need the source code which can be downloaded from the
PillarOne website, www.pillarone.org. Apart from the business
logic which is completely written by the core team and the community
members, RiskAnalytics is built on top of leading software frame-
works. The most prominent one is Grails1
, which itself contains the
Spring framework, Hibernate and ULC, to mention the most impor-
tant ones. You don’t need to download and install these frameworks
separately. The RiskAnalytics source distribution contains the ap-
propriate versions of these frameworks.
To download the source distribution. . .
Developing with such a sizable software system is more than just editing
files. Hence, we recommend that you set up an integrated development
environment (IDE). The core team uses IntelliJ IDEA and consequently
the source distribution contains the project files for setting up the com-
plete RiskAnalytics source code in IDEA. The project can also be set
up in Netbeans or Eclipse.
For source code versioning we use Git. Anyone can obtain read ac-
cess, by following the steps below. First you should configure your Git
username and password for the project:
git config user.name ”Your Name”
1Grails is the open-source web application framework based on Groovy. See
their homepage for more information.
171

172 CHAPTER 18. DEVELOPMENT ENVIRONMENT
git config user.email ”your.email@email.com”
Git usernames can also be configured globally, but (at least on Win-
dows) this is not recognized when committing through IDEA.
When the project is started for the first time, IDEA might complain
that path variables are not set. They have to be set once globally
and are necessary to allow for stable project files. If IDEA does not
complain, they can be set at File → Settings → Path variables.
• PILLARONE GRAILS: Should be set to the location where the
modified Grails 1.2.0 version was checked out (see above)
• USER HOME: Should be set to your user home direcotry (where
the .grails folder is)

Chapter 19
Modularization
RiskAnalytics is split up in diﬀerent modules, currently core, appli-
cation and business logic. As RiskAnalytics is a Grails application, a
module is actually a Grails plugin.
For our own and modiﬁed public plugins we use our own Grails plugin
repository, which is located at: https://svn.intuitive-collaboration.
com/GrailsPlugins/
Read only access does not require authentication, but a SVN account
is required to release plugins into our repository.
173

174 CHAPTER 19. MODULARIZATION

Chapter 20
Working on existing
plugins
Our plugins are based on a modified version of Grails 1.2.0, which is also
available from Git. gitaccess@svn.intuitive-collaboration.com:riskanalytics-
grails.git
The project files of the plugins are already configured correctly to use
this grails version, however you will need to set GRAILS HOME to the
correct folder if you want to use grails commands on the CLI.
The core and application plugins can be obtained from our Git reposi-
tory:
git clone git://github.com/pillarone/risk-analytics-core.git
git clone git://github.com/pillarone/risk-analytics-application.git
Additional plugins are no longer checked into the repository, because
we have our own plugin repository now. Plugins are defined in appli-
cation.properties and will be downloaded automatically.
Changes to the plugin can be commited and pushed to git as usual.
However it is only possible to change files inside the plugin scope. For
example, the application plugin cannot change anything in
riskanalytics.core.*. If such a change is required, a new version of
the core plugin must be released and then installed in the application
plugin.
175

176 CHAPTER 20. WORKING ON EXISTING PLUGINS
20.1 Releasing a plugin
At first the distribution location (Grails plugin repository to save the
plugin) must be defined. The discovery location, which is used to down-
load plugins, is already defined in BuildConfig.groovy.
To avoid to accidently commit SVN credentials the distribution location
should not be defined at the same place. Instead a /.grails/settings.groovy
file should be created and the following line added:
grails.plugin.repos.distribution.pillarone =
”https://username:password@svn.intuitive-collaboration.com/GrailsPlugins/”
Before releasing, the plugin version number has to be corrected in the
file RiskAnalytics*GrailsPlugin.groovy. If everything is set up, the
plugin can be released using the release-plugin ant target.
It is probably a good idea to tag the Plugin release in git: git tag -m
‘tagged plugin version x.y’ ‘v.n.n’
20.2 Running it all together
As the development is now split up between the different plugins, de-
veloping the UI means that there are only simple test models available
and there is no UI for developing business logic. This should encourage
to write test cases instead. However sometimes it is necessary to run
for example a business logic model with the UI available. For this case,
a ‘development runner’ project is available from git.
git clone gitaccess@svn.intuitive-collaboration.com:riskanalytics-devrunner.git
The external dependencies required by core and application are already
included. The location of the RiskAnalytics plugins to be used can
be configured in BuildConfig.groovy. That way it is possible to run and
test a complete application, which uses the current plugin ‘Snapshots’
contrary to the plugin projects which use only released plugin versions
and usually only depend on the core plugin.
However this project should only be used as ‘application runner’ and
NOT to edit files of other plugins! All changes and running tests should
be done in the individal plugin project.

Chapter 21
Creating your own
plugin
All grails plugins are based on a Grails 1.3.4. However due to a
bug in the Groovy 1.7.4 compiler, we replaced it with Groovy 1.7.5.
You should therefore use that version which can be obtained from:
gitaccess@svn.intuitive-collaboration.com:riskanalytics-grails.git
Make sure the environment variable GRAILS HOME points to the above
mentioned grails and PATH includes GRAILS HOME/bin. Then simply
run grails create-plugin PluginName to create a new plugin.
21.0.1 Deﬁne PillarOne repository
To be able to download from our plugin repository, add the following
lines to BuildConﬁg.groovy:
grails.project.dependency.resolution = {
inherits "global" // inherit Grails’ default dependencies
log "warn"
repositories {
grailsHome()
grailsCentral()
}
def myResolver = new URLResolver()
177

178 CHAPTER 21. CREATING YOUR OWN PLUGIN
myResolver.addArtifactPattern "https://build.intuitive-collaborati
resolver myResolver
}
Most plugins will need the risk-analytics-core plugin: grails install-
plugin risk-analytics-core The core plugin and all its dependencies will
then be downloaded and installed. Also the file YourPluginGrailsPlu-
gin.groovy should be edited, to define name, version, dependencies and
more. An example *GrailsPlugin.groovy and an example build.xml file
can be obtained from the Core or Application plugin.
It is also recommended to update the Config.groovy & DataSource.groovy
files, because certain options should be set. The easiest way to do this
is to look at the corresponding files in the core & application projects
and take the necessary options from there.
21.1 Git Hints
• Working on a branch
– create the branch locally using git branch –track 0.5.x re-
motes/origin/0.5.x
– switch the working branch using git checkout 0.5.x
21.2 Environments
As Risk Analytics is a Grails application we also use Grails’ support for
different environments. The environment Risk Analytics runs in is de-
fined at startup with the parameter -Dgrails.env=environment-name.
We use the environments for the database connection settings (in grails-
app/conf/DataSource.groovy) and several other application settings in
grails-app/conf/Config.groovy.
It is possible to add new environments by editing these files and copy-
pasting existing environments. This is typically done when a new
database product will be used.
For more information see: http://grails.org/doc/latest/guide/3. Con-
figuration.html#3.2 Environments

21.3. USER MANAGEMENT 179
21.3 User Management
The server version of RiskAnalytics includes a user management, which
includes login, saving of user preferences and the user information is
linked to modelling items. The user management is based on Spring
Security and there are two pre-deﬁned roles, ROLE USER who can use
the application and ROLE ADMIN who can additionaly manage the
users.
New users can be added in the BootStrap of your application. An ex-
ample of how to add new users can be found in the class CoreBootStrap
in the core plugin.

180 CHAPTER 21. CREATING YOUR OWN PLUGIN

Chapter 22
Scalability
The principle behind stochastic simulations as applied in RiskAnalytics
is to generate a large number of so called independent, identically dis-
tributed realizations of the future (’iteration’) and then to statistically
analyze the ensemble of all these iterations.
The accuracy (conﬁdence) of the results can be improved by increasing
the number of iterations, i.e. the ensemble the statistical estimates are
based on. Typically, asking for better accuracy of the results implies
longer runtimes. This is not necessarily true if
• a larger number of computing resources (CPU’s) is available and
• the software used to run the simulation is capable of distributing
the computations to many CPU’s.
Stochastic simulations are an ideal candidate to distribute the compu-
tations since independent iterations can be generated just as well on
diﬀerent CPU’s.
22.1 Application Structurue Revisited
The RiskAnalytics platform is split up into three modules:
• core which provides a basic infrastructure such as data access and
reporting services and for setting up and running models;
• application which, basically, contains the graphical user interface;
181

182 CHAPTER 22. SCALABILITY
• business logic.
The SimulationRunner is part of the core module and is the component
from which the stochastic simulations are configured, started and run.
The following basic steps are processed in a simulation run:
• Pre-simulation actions
– Instantiating a model
– Loading of input data
• Simulation
– Computing the random scenarios (n iterations with m peri-
ods each)
– Writing the raw simulation output to a file
• Post-simulation actions 1
– Loading data from file
– Computing the statistics
– Storing the statistics output in the database
The computational intensive and time consuming part of a simulation
run clearly is the simulation itself. In order to achieve scalability it
is sufficient to distribute the computation of the random scenarios.
Here it is important to assure that all iterations remain stochastically
independent. Furthermore it is important to obtain reproducibility in-
dependent of the computing grid configuration (e.g. number of nodes).
1Up to RiskAnalytics 1.1 the raw simulation output was automatically written
to the database as part of the postsimulation actions. In view of eliminating the
bottleneck of the data persistence layer to obtain a scalable distributed solution this
approach was changed: Now the raw simulation output is written to local files and
only the statistics output is written to the database. The raw simulation output
can be loaded into the database on demand.

22.2. GRIDGAIN 183
22.2 GridGain
Since 1.2 scalability is a standard feature of the platform. The appli-
cation should scale on a single multi-core laptop as well as on a grid
consisting of multiple computing resources. No additional deployment
overhead is needed; once set-up and configured, the simulations are
automatically distributed. The framework used for distributing the
computations is GridGain2
. GridGain is open source, java-based hence
multi-platform and allows simple deployment. It allows to be integrated
smoothly into the existing platform with minimal intrusion. By using
a threaded architecture, it scales well on a multi-core single machine
and on multiple computing resources combined to a grid.
22.3 Implementation
In this section a short description of the implementation of the comput-
ing and data persistence part in the gridified RiskAnalytics application
is given.
22.3.1 Computing
As discussed in 22.1 the Simulation Runner, used to start a stochastic
simulation, consists of 3 steps. The ”Simulation” step is computing the
random scenarios during multiple iterations. These iterations are inde-
pendet from each other and can therefore be run in parallel. In order
to achieve this using the GridGain Framework, the following changes
and additions to RiskAnalytics have been made:
• The total number of iterations is split into blocks. Each block is
allocated to a grid job which then processes the iterations.
• A grid job is basically an execution unit which can be run on a
grid node. Multiple grid jobs run in parallel. A grid job consists
of a simulation configuration, a list of simulation blocks and the
execution routine. The simulation configuration describes all run-
time aspects e.g. numberOfIterations, numberOfPeriods, the pa-
rameterization, etc. A simulation block specifies the iterations to
2For more information about GridGain check www.gridgain.com

be processed and how to handle the random number generation.
The execution routine creates and starts a Simulation Runner.3
• There is actually one grid node embedded in the Riskanalytics
application. This grid node is always active and acts as master
node. The master node is responsible for creating jobs and dis-
tributing them to other grid nodes (slave nodes). These slave
nodes process the iterations included in the assigned blocks and
send the intermediate results back to the master node. The mas-
ter node then also manages the data persistence (see 22.3.2).
• The number of created grid jobs per simulation run is chosen
equal to the number of cpus (or cores) in a grid.
22.3.2 Data persistence
Following changes and additions have been made to support the local
file persistence:
• The master node is continuously storing the received intermediate
simulation results.
• This raw data consisting of iteration meta information and simu-
lated values is no longer automatically stored into a database but
directly written in binary form into files.
• As soon as all grid jobs have finished their simulation run, the re-
duce method of the master node is called. This method processes
the statistical analysis of the raw data (post simulation process)
and stores the statistical characteristics into a database.
22.4 Configuration
A grid consists of several computing resources on which a distributed
task can be executed. To allow this distributed computing, a consider-
able amount of communication and coordination between the comput-
ing resources is necessary. GridGain provides the necessary commu-
nication and coordination out-of-the-box, meaning no additional con-
figuration effort is needed to add grid nodes to an existing grid. The
3As of RA 1.2 the Simulation Runner executes just the pre-simulations actions
and the simulation actions; the post-simulation actions are no longer part of the
Simulation Runner and are called later (see 22.3.2).

22.4. CONFIGURATION 185
communication is done via network broadcasting, so each grid node in
the same subnet automatically joins the grid.
As mentioned in 22.3.1 there is already a grid node embedded in the
RiskAnalytics application. When executing a simulation run, this mas-
ter node is executing the application multi-threaded by considering all
available cpu cores of its host system. If an additional grid node should
join the grid make sure the host system is running in the same subnet
as the Riskanalytics application system and follow these instructions to
set up a GridGain node:
1. Unzip gridgain-3.0.0c-win.zip
2. Set GRIDGAIN HOME environment variable to the path you un-
zipped (e.g. C:gridgain-3.0.0c-win)
3. Copy the Riskanalytics library RiskAnalytics.jar to
gridgain-3.0.0c-winlibsext
4. Adjust gridgain-3.0.0c-winconfigdefault-spring.xml
Replace:
1 <!−−
<property name=”p2PLocalClassPathExclude”>
<list>
<value>org.springframework.∗</value>
<value>org.openspaces.∗</value>
6 <value>org.hibernate.∗</value>
</list>
</property>
−−>
with
1 <property name=”p2PLocalClassPathExclude”>
<list>
<value>org.apache.commons.logging.∗</value>
<value>org.slf4j.∗</value>
</list>
6 </property>
5. Execute gridgain-3.0.0c-winbinggstart.bat A successful
start shows on the prompt:
>>> GridGain started OK

6. Start the Riskanalytics application. On the prompt of the gridgain
node following message should be visible (as soon as the applica-
tion has started):
>>> Node JOINED [nodeId8=..., addr=[...], CPUs=...]
>>> Topology snapshot [nodes=2, CPUs=...]
7. When you start a simulation run with at least 2000 iterations (so
at least 2 jobs are generated and can be distributed), you should
be able to follow the log output of this simulation run on the
GridGain prompt.

Chapter 23
Writing business logic:
Components
The following examples can all be found within in the RiskAnalytics
source code repository:
RiskAnalyticsPC/src/groovy/org/pillarone/riskanalytics/domain/
examples/groovy.
23.1 Step-by-Step Component Example
We create a component providing a premium value to other compo-
nents. The premium will be the product of number of policies and the
price per policy parameter.
• Create a new Groovy or Java class in the corresponding package.
(Line 1, 6)
Domain classes can be found in src/groovy/org.pillarone.riskanalytics.domain
• The class has to extend org.pillarone.riskanalytics.core.components.Component
(Line 6)
• The class has two parameters parmNumberOfPolicy and parmPri-
cePerPolicy (Line 8, 9) The order in which the parameters are
deﬁned is also the order how they will be displayed in the UI. If
parameters are inherited from superclasses, the parameters of the
superclass are displayed ﬁrst.
187

188 CHAPTER 23. WRITING BUSINESS LOGIC: COMPONENTS
• The class has an output channel outPremium (Line 11) in order
to send premium information to other components.
• Premium has to be calculated (Line 14), wrapped in a packet and
added to the output channel (Line 15). Once doCalculation() has
ﬁnished, the framework will send this premium packet to following
.nents being wired to PremiumCalculation.outPremium.
package org.pillarone.riskanalytics.domain.examples.groovy
import org.pillarone.riskanalytics.core.components.Component
4 import org.pillarone.riskanalytics.core.packets.PacketList
class PremiumCalculation extends Component {
double parmNumberOfPolicy
9 double parmPricePerPolicy
PacketList<PremiumPacket> outPremium = new PacketList<PremiumPacket←
>(PremiumPacket)
void doCalculation() {
14 double premium = parmNumberOfPolicy ∗ parmPricePerPolicy
outPremium << new PremiumPacket(value: premium)
}
}
Let’s say we want another component providing index information
which inﬂuences the price per policy. In order to cover this use case we
write a component with extended functionality:
• Add an additional input channel inIndex (Line 7)
• Adjust the premium calculation: build the product of all received
indices (Line 14 - 15) and adjust the price per policy accordingly
(Line 14)
import org.pillarone.riskanalytics.core.packets.PacketList
4
class PremiumCalculationWithIndex extends PremiumCalculation{

23.2. STEP-BY-STEP EXAMPLE OF COMPOSEDCOMPONENT189
PacketList<IndexPacket> inIndex = new PacketList<IndexPacket>(IndexPacket←
)
9 void doCalculation() {
double level = 1.0
for (IndexPacket idx in inIndex) {
level ∗= idx.value
}
14 double pricePerPolicy = parmPricePerPolicy ∗ level
double premium = parmNumberOfPolicy ∗ pricePerPolicy
outPremium << new PremiumPacket(value: premium)
}
}
For the sake of completeness, the following listing contains the Ind-
exPacket and PremiumPacket classes. Both classes are derived from
SingleValuePacket having a value property.
3 import org.pillarone.riskanalytics.core.packets.SingleValuePacket
class IndexPacket extends SingleValuePacket {
}
8
import org.pillarone.riskanalytics.core.packets.SingleValuePacket
13 class PremiumPacket extends SingleValuePacket {
}
23.2 Step-by-Step Example of Composed-
Component
We create a component composed of a frequency and claims size gen-
erator.
• Create a new Groovy class in the corresponding package (Line 1,
2).
Domain classes can be found in src/groovy/org.pillarone.riskanalytics.domain
Caveat: Composed components have to be deﬁned in a Groovy

class, as wiring would not work with a Java class in the current
implementation.
• The class has to extend (see Line 9):
org.pillarone.riskanalytics.core.components.ComposedComponent
• The class has two sub-components subIndexProvider and subPremi-
umCalculation. Make sure all sub-components name start with
sub! Components not starting with sub will not be displayed in
any of the user interfaces. (Line 11, 12)
• The class has an output channel outPremium (Line 14) in order
to send premium to other components such as claims generators
or reinsurance contracts.
• As this composed component does not have any input channels,
we have to deﬁne which component is executed ﬁrst in doCalcu-
lation() (Line 17).
Caveat: As composed components contain no business logic by
itself, it is not necessary to implement doCalculation(). The only
exception are composed components without any (wired) in chan-
nels. Similar to the starting components concept in a model, do-
Calculation() is required for triggering. If any input channel is
wired, ComposedComponent.doCalculation() has to be used!
• Each composed component has to implement the abstract wire()
method. Wiring between the sub-components is done similar
to the wiring in models using WireCategory. (Line 21-23). As
sub-components are nested we have to make sure that the infor-
mation provided or required outside the composed component is
replicated. This is done with the so called PortReplicatorCategory
(Line 24-26).
Caveat: Using the PortReplicatorCategory the properties on the
left and right side have to be either both in or both out properties,
whereas for WireCategory the left side property has to be an in
and the right side an out property.
1 package org.pillarone.riskanalytics.domain.examples.groovy
import org.pillarone.riskanalytics.core.components.ComposedComponent
import org.pillarone.riskanalytics.core.wiring.WiringUtils

23.2. STEP-BY-STEP EXAMPLE OF COMPOSEDCOMPONENT191
6 import org.pillarone.riskanalytics.core.wiring.WireCategory
import org.pillarone.riskanalytics.core.wiring.PortReplicatorCategory
class IndexedPremium extends ComposedComponent {
11 IndexProvider subIndexProvider = new IndexProvider()
PremiumCalculationWithIndex subPremiumCalculation = new ←
PremiumCalculationWithIndex()
>(PremiumPacket)
16 protected void doCalculation() {
subIndexProvider.start()
}
void wire() {
21 WiringUtils.use(WireCategory) {
subPremiumCalculation.inIndex = subIndexProvider.outIndex
}
WiringUtils.use(PortReplicatorCategory) {
this.outPremium = subPremiumCalculation.outPremium
26 }
}
}
In order to model a ’global’ and a line specific inflation, an in channel
accepting an additional external index is required.
• The class has an input channel inIndex (Line 10)
• As inIndex is wired to the second sub component of the work-
flow, the implementation of doCalculation() in the super class is
required and therfore not overwritten.
Note: The method isReceiverWired(inIndex) (Line 13), which is
implemented in the base class Component, returns true if any out
property of another component is connected to inIndex. Therefore,
it is not mandatory to wire all channels.
• Finally, it is necessary to provide the index information to the in-
dex provider component using the closure1
PortReplicatorCategory
to wire them (Lines 25–27).
1A Groovy closure is an object declared within matching curly brackets contain-
ing a code block, optional argument declarations and, implicitly, a call() method.
When and how many times this method is called (and, as a result, the contained code
block gets executed) depends on the context within which the closure is declared.
See [9], particularly the Formal and Informal Guide pages for more information.

3 import org.pillarone.riskanalytics.core.packets.PacketList
import org.pillarone.riskanalytics.core.wiring.PortReplicatorCategory
import org.pillarone.riskanalytics.core.wiring.WiringUtils
import org.pillarone.riskanalytics.core.wiring.ITransmitter
8 class AdvancedIndexedPremium extends IndexedPremium {
PacketList<IndexPacket> inIndex = new PacketList<IndexPacket>(←
IndexPacket)
protected void doCalculation() {
13 if (isReceiverWired(inIndex)) {
// corresponds to super.super.doCalculation() which is not possible
for (ITransmitter transmitter : allInputReplicationTransmitter) {
transmitter.transmit()
}
18 }
subIndexProvider.start()
}
void wire() {
23 super.wire()
if (isReceiverWired(inIndex)) {
WiringUtils.use(PortReplicatorCategory) {
subPremiumCalculation.inIndex = this.inIndex // code within ←
closure
}
28 }
}
}
23.3 Arbitrary Number of Equal Compo-
nents
Composed components consist of a variable number of subcomponents,
each of the same type. The number of subcomponents is deﬁned in the
parameterization. According the available records in a database2
the
same number of sub-components are instantiated.
2TODO: clarify the english!

23.3. ARBITRARY NUMBER OF EQUAL COMPONENTS 193
Concept
• A dynamically composed component is similar to a composed
component, in the sense that it contains components, but also
different, in the sense that it contains a variable number of com-
ponents of a specific type. The type of these components has to
be defined in the function abstract Component getDefaultSubCom-
ponent()
• The wire() and doCalculation() methods follow exactly the same
concepts as for a composed component.
• The abstract class DynamicComposedComponent handles adding,
removing, naming and other checks for all derived classes. The
components are administered using a private list of component
called componentList.
• This concept enables a data driven modelling. The Podra model
actually contains nine void containers (underwriting segments,
claims generators, reserve generators, dependencies, event gener-
ators, segments, reinsurance, ALM generators and structures).
• Models using dynamically composed components typically in-
clude several filter components for allocation. As an example
the reinsurance program and all its reinsurance contracts will re-
ceive all claim and underwriting packets. Not all of them will
be treated by every contract. As the wiring is fixed and can-
not be optimized, it is necessary to filter packets. Therefore as a
drawback of the higher flexibility a lower performance has to be
accepted.
• The higher flexibility increases the potential of parameterization
errors3
.
Step-by-step example
We create a dynamically composed component containing reinsurance
contracts.4
• Create a new Groovy class in the corresponding package (Line 1,
2). Domain classes can be found in src/groovy/org.pillarone.riskanalyti
3TODO: This is not part of the concept but a warning.
4TODO: (sku): add an easier example

• Composed components have to be defined in a Groovy class as
wiring would not work with a Java class in the current implemen-
tation.
• The class has to extend
org.pillarone.riskanalytics.core.components.DynamicComposedComponent
(Line 2)
• The DynamicPremiumCalculation has an arbitrary number of Pre-
miumCalculation components. Their default instantiation is de-
fined in getDefaultSubComponent(). The method is called when-
ever an application user right clicks on the dynamic premium
calculation and adds a new premium calculation component.
import org.pillarone.riskanalytics.core.components.DynamicComposedComponent
6
class DynamicPremiumCalculation extends DynamicComposedComponent {
PacketList<IndexPacket> inIndex = new PacketList<IndexPacket>(←
IndexPacket)
>(PremiumPacket)
11
void wire() {
replicateInChannels this, ’inIndex’
replicateOutChannels this, ’outPremium’
}
16
Component createDefaultSubComponent() {
return new PremiumCalculation()
}
}
23.4 Filtering and Allocation
Whenever a reallocation is needed, loops become unavoidable in the
model graph.5
There are specific composed components containing com-
ponents being executed in different phases.
5TODO: Provide example here.

23.5. DIFFERENT BEHAVIORS 195
The concept and implementation is relatively new. The API is not yet
stable. The current implementation allows two phases. It is used to
reallocate ceded and net claims and underwriting information to lines
of business in order to display resulting gross, ceded and net figures in
one place.
An example implementation is ConfigurableLob. The components
• MultipleCalculationPhaseComposedComponent
• MultiPhaseDynamicComposedComponent
can be found in the package org.pillarone.riskanalytics.core.components.
23.5 Different Behaviors
In order to provide a preferably small and well structured set of com-
ponents combined with a high user flexibility, component parameters
may be defined in an exchangable strategy6
. A strategy may consist of
an arbitrary number of parameters or containing even a specific imple-
mentation. In order to implement flexible behavior several classes are
required:
• an interface extending IParameterObject and common methods
needed for all behaviors. This interface is then used in the com-
ponent as type of the parameter and for accessing different func-
tionality of a behavior.
• a class per behavior implementing the interface mentioned before
• a type class extending AbstractParameterObjectClassifier contain-
ing a list of all available behaviors
• components containing a strategy parameter have to be adjusted
accordingly
As a use case for a strategy different index calibrations should be sup-
ported. As a consequence all strategies of the example will need to
provide an index. This component producing the IndexPacket has to
correctly handle the different use cases. In order to easily access meth-
ods available in all strategies an interface is required:
6TODO: provide example

package org.pillarone.riskanalytics.domain.examples.groovy;
import org.pillarone.riskanalytics.core.parameterization.IParameterObject;
5 public interface IIndex extends IParameterObject {
double getIndex();
}
The implementation for this behavior is trivial as the strategy keeps
only the parameters and does not contain any index transformation
logic. getType() (Line 7) and getParameters() (Line 11) are methods
of the IParameterObject interface. It’s up to the developer to split up
implementation code between component and strategy class. Reinsur-
ance contracts might be an interesting example. Contract strategies
contain the speciﬁc contract logic and the components the common
implementation.
2
class RelativeIndexStrategy implements IIndex {
double changeIndex
7 Object getType() {
IndexType.RELATIVEPRIORPERIOD
}
Map getParameters() {
12 return [’changeIndex’: changeIndex]
}
double getIndex() {
return changeIndex
17 }
}
The type class contains all available strategies as a static type including
the default parameters for each strategy. Variable names should not
contain any special characters like underscores. The user interface will
provide all strategies in the combobox being part of the static list all.
All the other methods are required e. g. for im-/export and the UI.
2

23.5. DIFFERENT BEHAVIORS 197
import org.pillarone.riskanalytics.core.parameterization.←
AbstractParameterObjectClassifier
import org.pillarone.riskanalytics.core.parameterization.IParameterObjectClassifier
import org.pillarone.riskanalytics.core.parameterization.IParameterObject
7 class IndexType extends AbstractParameterObjectClassifier {
public static final IndexType ABSOLUTE = new IndexType(”absolute”, ”←
ABSOLUTE”, [”index”: 1d])
public static final IndexType RELATIVEPRIORPERIOD = new IndexType(”←
relative prior period”, ”RELATIVEPRIORPERIOD”, [”changeIndex”: 0d])
12 public static final all = [ABSOLUTE, RELATIVEPRIORPERIOD]
protected static Map types = [:]
static {
IndexType.all.each {
17 IndexType.types[it.toString()] = it
}
}
private IndexType(String displayName, String typeName, Map parameters) {
22 super(displayName, typeName, parameters)
}
public static IndexType valueOf(String type) {
types[type]
27 }
public List<IParameterObjectClassifier> getClassifiers() {
return all
}
32
public IParameterObject getParameterObject(Map parameters) {
return IndexType.getStrategy(this, parameters)
}
37 static IIndex getStrategy(IndexType type, Map parameters) {
IIndex index
switch (type) {
case IndexType.ABSOLUTE:
index = new AbsoluteIndexStrategy(index: parameters[’index’])
42 break
case IndexType.RELATIVEPRIORPERIOD:
index = new RelativeIndexStrategy(changeIndex: parameters[’←
changeIndex’])
break
}
47 return index
}

}
The implementing component can query the parameter for the used
strategy (Line 20, 23) and the index value. To keep the prior period
index a member variable is added (Line 14). This member variable has
to be reset for every iteration (Line 29). Explanations on the scope
concept is available in the next section.
import org.pillarone.riskanalytics.core.simulation.engine.PeriodScope
6
class FlexibleIndexProvider extends Component {
PeriodScope periodScope
11 IIndex parmIndex = IndexType.getStrategy(IndexType.ABSOLUTE, [’index’: 1←
d])
PacketList<IndexPacket> outIndex = new PacketList<IndexPacket>(←
IndexPacket)
double priorIndex = 1d;
16 protected void doCalculation() {
if (periodScope.getCurrentPeriod() == 0) {
initIteration()
}
if (parmIndex.getType().equals(IndexType.ABSOLUTE)) {
21 outIndex << new IndexPacket(value: parmIndex.getIndex())
}
else if (parmIndex.getType().equals(IndexType.RELATIVEPRIORPERIOD)←
) {
outIndex << new IndexPacket(value: parmIndex.getIndex() ∗ ←
priorIndex)
}
26 priorIndex = outIndex[0].value
}
private void initIteration() {
priorIndex = 1d
31 }
}

23.6. ACCESSING EXTERNAL INFORMATION 199
23.6 Accessing External Information
By default a component is unaware of the simulation context. If busi-
ness logic is depending on specific dates context information can be
injected. There exist three different, nested scopes:
• SimulationScope provides information being valid throughout the
whole simulation such as the number of iterations, model, param-
eter dao, result configuration, output strategy (file/database) and
the IterationScope.
• IterationScope provides information being valid throughout a sin-
gle iteration such as the current iteration number, number of
periods, period stores and the PeriodScope.
• PeriodScope provides information being valid for a single period
such as the current period. If a model is based on exact dates
specific methods are available in order to get the current and next
period start date.
The injection of information is done by simply adding a property of the
required scope to a component. Java components will need according
getter and setter methods additionally.
23.7 Period Store
A PeriodStore is used whenever a Component needs a memory in order
to access data of former periods or prepare data that the Component
itself will need in future periods. The content may be any kind of
objects e. g. packets being sent out in future periods. Period stores are
cleared after an iteration. Period stores are injected and governed by
the framework. The component itself can only read and write elements
to it7
. Index handling is done by the framework. Elements are accessed
with a relative index e. g. elements of the current period will be accessed
with index 0, previous with -1. If a component is written in Java
getPeriodStore() and setPeriodStore(PeriodStore periodStore) have to be
implemented.
7TODO: What is ‘only’ refering to? Does it mean, no modifying or deleting?

23.8 Packet
• Packets are type safe objects sent from a source component to a
target component using a channel.
• A packet may contain any kind and number of objects.
• For convenience a packet implementation should overwrite String
toString(). It makes debugging much easier.
• When is an implementation of the following methods required?
– equals
– hashCode
– compareTo
TODO: provide answer.
• Content modiﬁcation (Copy/not copy transmitter)
TODO: explain
Business Logic in Packets
Generally packets should be kept lean. However there are cases where
it is useful including business logic in them.8
Storing and Displaying Packets
There are two base classes allowing to persist and display results: Sin-
gleValuePacket and MultiValuePacket.
• For SingleValuePacket, the value property is displayed in the re-
sult view. It’s name can be conﬁgured, by overwriting String
getValueLabel().
• For MultiValuePacket, all numeric properties are displayed in the
result view according their order in the packet class. Derived
classes should override the method getValuesToSave() in order to
limit displayed properties.
Note: If a packet class is implemented in Java, getters and setters
have to be written. Use IDE refactoring features to do this.
8TODO:

23.8. PACKET 201
Packet Pooling for Performance Optimization
TODO: Implementation still missing.

Chapter 24
Testing Business Logic
24.1 Purposes and forms of Testing
In order to avoid changes breaking existing code different kinds of tests
are required to provide an immediate feedback to the developer. Ac-
cording to our code contribution process all tests have to be executed
before changes are committed into the source code repository. Further-
more the webapplication hudson will execute all test cases again and
provide feedback to the committer if any test has failed.
Two different kinds of tests of business logic which we utilize are:
• unit tests, for testing single components, strategies, packets or
wiring; and
• integration tests, to check that model simulations run consistently
and completely1
.
24.2 Unit Tests
• Directory structure: Each source class should be accompanied by
a corresponding unit test class with a parallel classpath e. g., test
class
ClaimsAggregatorTests in test/unit/org.pillarone.riskanalytics.domain.pc.aggregato
tests source class
1this implicitly includes regression tests, so that old parametrization files will
still run in newer RiskAnalytics releases
203

204 CHAPTER 24. TESTING BUSINESS LOGIC
ClaimsAggregator in src/groovy/org.pillarone.riskanalytics.domain.pc.aggregators.
• Directory structure: A unit test has to be placed in the corre-
sponding package to the source class, e. g. ClaimsAggregatorTests
has to be placed in test/unit/org.pillarone.riskanalytics.domain.pc.aggregators
as ClaimsAggregator is placed in src/groovy/org.pillarone.riskanalytics.domain.pc.a
• Each unit test class is written in Groovy, has to end with *Tests
in order to be found by the Grails test framework and be derived
from GroovyTestCase.
• Test cases are a mean to document the usage of a component,
therefore every test class should include a method testUsage() as
documentation of the basic usage of a component.
• If business logic calculations is done with doubles or floats, results
won’t match completly. Therefore it is possible to define an .
assertEquals ’message’, 4, component.testFigure, 1E-8
• If a component contains code throwing exceptions, it’s necessary
to test if this failures really occure. The syntax is as follows:
shouldFail IllegalArgumentException, { component.doCalculation()
}
The first argument of shouldFail is the expected exception, the
second contains a closure with the code to be executed in order
to get the exception.
TODO: code snippet throwing the same exception type in several
blocks: how to make sure exception was thrown where expected?
Evaluating exception message?
• If objects are used in several test methods it is recommended to
create them in static methods. Example from org.pillarone.riskanalytics.domain.p
static ReinsuranceContract getContract0() {
return new ReinsuranceContract(
3 parmContractStrategy: ReinsuranceContractStrategyFactory.←
getContractStrategy(
ReinsuranceContractType.QUOTASHARE,
[”quotaShare”: 0.5,
”commission”: 0.0,
”coveredByReinsurer”: 1d]))
8 }

24.3. MODEL TESTS 205
This contract can then be used in any other test class. Add
parameters to the static functions to get a more flexible usability.
Be aware that a new object should be created in every call of the
static method to avoid side effects between tests.
• When testing several components it won’t be sufficient to call do-
Calculation() of the first component as this won’t trigger follow-
ing components. Instead start() has to be called. This method
includes publishing of results to following components. Unfortu-
nately it includes the clearing of the out channel lists too. In-
specting out channels for results won’t work in this case. There-
fore the TestProbe concept was introduced. It is a probe that
can be connected to any out channel and will collect published
content, making it available after start() has been executed. An-
other scenario for using TestProbe is to immitate an out channel
to be wired in order to trigger calculations. Whenever a Test-
Probe is connected to an out channel isSenderWired() will return
true. Example: def inChannelWired = new TestPretendInChannel-
Wired(claimsGenerator, ”inEventSeverities”) Examples:
Use def probeGross = new TestProbe(aggregator, ”outUnderwriting-
InfoGross”) to pretend an out channel is wired and
List quotaShareNet = new TestProbe(quotaShare, ”outUncovered-
Claims”).result to collect outcome from quotaShare.outUncoveredClaims.
Details about the differences of doCalculation(), execute() and
start() can be examined in the source code of org.pillarone.riskanalytics.core.comp
• In order to pretend an in channel to be wired TestPretendInChan-
nelWired has to be used. If an in channel of a component is wired
to such a component isReceiverWired() will be true.
• Whenever a ComposedComponent is tested internalWiring() has to
be called before start() is executed. Omitting internalWiring() will
result in an execution of the first component within a composed
component only.
24.3 Model Tests
Model tests run a simulation on a specified model and optionally check
its output. The ModelTest class and associated framework code provide
a simple yet extensible way to test that simulations run completely

(without runtime errors) and consistently (reproducibly) across release
versions.
Like simulations, model tests take as input a model, a parametrization,
and a result template. The first element, the model (class name), is
required; the latter two, parametrization and result template (names)
have defaults if they are not given explicitly. Additional options specify
• how many iterations to run (default: 10),
• whether the model test should compare the results collected (de-
fault: no), and if so, where the reference data can be found (de-
fault naming convention applies)2
• whether the results should be saved to a file or a database (de-
fault: file), and
• the test result’s display name and filename3
.
When collected, the model simulation result consists of tuples of (it-
eration, period, path, field, value). When saved to a file, each tuple
appears on one line of a so-called tab-delimited text file with extension
.tsl. 4
The result template defines which values – i. e., which (path,
field) combinations – to collect.
The driver for each model test is a Groovy class extending ModelTest.
Each ModelTest subclass implements a method, getModelClass, to tell
the framework which model (class) it is testing. Likewise, the method
shouldCompareResults, wich returns a boolean value5
, tells the frame-
work whether to collect the results defined in the result template. These
are the required ModelTest elements.
This forces the model testing framework to instantiate the model at
runtime, and then run a simulation on it using the assigned parameters
and result template. If the option to save the results to a file was
selected, the results are written to a file in the directory . If the option
to compare results was selected, the results are compared with those in
a file of the same format, which must be given in the directory . Any
differences result in the test failing. If there are no runtime errors and
no differences between the reference result set and the test’s result set,
the test passes.
Through this mechanism, one can adopt the following methodology
to initially verify specific aspects of a model, and subsequently en-
2TODO: verify this statement!
3TODO: or database tablename?
4TODO: Where and when is the output directory specified or configured (e. g.
at run or compile time)?
5true or false

24.3. MODEL TESTS 207
force the same behavior, saving the specification as an artifact 6
in
RiskAnalytics.
1. Generate specific parametrizations and result templates for a
model, targeting specific behavior.
2. Run the corresponding model test, saving a result file with no
comparison.
3. Inspect and verify the results (once; iterating to this point until
correct).
4. Copy the result file into RiskAnalyticsPC/test/data/.
5. Change the test class option to subsequently require comparison,
using the copied file from the previous step as the reference result.
The model test class AggregateDrillDownCollectingModeStrategyTests il-
lustrates many of the points mentioned above.
This section is not yet finished!7
6more precisely, a regression test. These codify and guarantee application be-
havior, acting as a measurestick/safeguard/constraint to protect against unintended
side-effects or incompatible interpretations resulting from future code development
efforts. This helps not only to fulfill the enterprise-level goals of transparency and
standards compliance, but also to efficiently expend development efforts while reach-
ing them.
7TODO: check veracity of and expand/expound on these statements! e. g., Ag-
gregateDrillDownCollectingModeStrategyTests

Bibliography
[1] The insurance groups and solvency ii, 2007.
[2] Stephen P. D’Arcy, Robert J. Finger, Charlse C. Hewitt,
Charles L. McClenahan, Gary S. Patrik, Matthew Rodermund,
Margaret Wilkinson Tiller, Gary G. Venter, and Ronald F. Wiser.
Foundations of Casualty Actuarial Science. Casualty Actuarial
Society, 4th edition, 2001.
[3] J¨org Dittrich, Ali Majidi, Norbert Kuschel, and Laurent Berthaut.
PillarOne Dynamic Reinsurance Analysis (PODRA): The easy
way. http://www.munichre.com/publications/302-06030_en.
pdf, February 2009.
[4] Kathleen Ehrlich and Margarita von Tautphoeus. Solvency II and
reinsurance: How important is a reinsurer’s rating? http://
www.munichre.com/publications/302-06232_en.pdf, Novem-
ber 2009.
[5] FINMA. Circular 2008/29: Internal business transactions
– insurance groups. http://www.finma.ch/e/regulierung/
Documents/finma-rs-2008-29-e.pdf, 20 November 2008.
[6] FINMA. Circular 2008/44 SST: Swiss Solvency Test
(SST). http://www.finma.ch/e/regulierung/Documents/
finma-rs-2008-44-e.pdf, 28 November 2008.
[7] FINMA. Rundschreiben 2008/44 SST: Schweizer Solvenztest
(SST). http://www.finma.ch/d/finma/publikationen/
Documents/finma-rs-2009-sammlung-d.pdf, 28 November
2008.
209

210 BIBLIOGRAPHY
[8] K. Gerathewohl. Reinsurance principles and Practice. Verlag Ver-
sicherungswirtschaft, Karlsruhe, 1980.
[9] groovy.codehaus.org. Groovy – closures. http://groovy.
codehaus.org/Closures. See also the Formal and Informal Guide
pages.
[10] Dierk Koenig, Andrew Glover, Paul King, Guillaume Laforge, and
Jon Skeet. Groovy in Action. Manning Publications Co., Green-
wich, CT, USA, 2007.
[11] P. Liebwein. Klassische und moderne formen der
Rückversicherung. Verlag Versicherungswirtschaft, Karlsruhe,
2009.
[12] Thomas Mack. Schadenversicherungsmathematik. Deutsche
Gesellschaft für Versicherungsmathematik, Schriften-
reihe Angewandte Versicherungsmathematik. Verlag Ver-
sicherungswirtschaft, Karlsruhe, 2nd edition, 2002.
[13] Alexander J. McNeil, Rüdiger Frey, and Paul Embrechts. Quanti-
tative Risk Management. Princeton University Press, 2005.
[14] Roger B. Nelson. An introduction to copulas. Springer Series in
Statistics. Springer, 2nd edition, 2006.
[15] David Sehrbrock. Gruppenaufsicht unter Solvency II. Zeitschrift
für die gesamte Versicherungswissenschaft, 97, Supplement 1:27–
36, 2008.
[16] Heinz Stettler, Fritz Eugster, Michael Kuhn, and numerous spe-
cialists. Reinsurance Matters. A manual of the non-life branches.
Swiss Reinsurance Company, 2nd edition, December 2005.
[17] HM Treasury. Supervising insurance groups under Solvency II: a
discussion paper. http://www.abi.org.uk/Solvency_II/15588.
pdf, November 2006.

Risk analyticsmaster

More Related Content

What's hot (17)

Similar to Risk analyticsmaster (20)

Recently uploaded (20)

Risk analyticsmaster