Insurance Models Solution Design

Detailed solution design
INSURANCE COMPANY A IFRS 17
Actuarial Models and Calculations - Disability (AOV/WIA)
Sanitized by Global Markets - EY Knowledge

1
BIA Template information (can be deleted after use)
BIA Template library Link to SharePoint template library
BIA Template category Functional Design
BIA Wiki reference Link naar de BIA Functional Design Wiki
BIA Template date
BIA Template owner BIA Competentiegroep – Feedback over deze

template
2
Version: 0.28
Date: 18-2-2019
Owner: PERSON
Draft prepared by: IFRS 17 project team - Models lead (PERSON)
Version history
Version Date Description Author

0.1 19-9-2018 First draft by Systems & Data LIST DELETED
0.2 3-10-2018 Edits to chapter 2, added scope, list

of change initiatives, placeholders.
Edits to chapter 4.4 added
0.3 12-10-2018 Input Systems & Data
0.4 17-10-2018 Review input Systems & Data
0.5 18-10-2018 Changes regarding review by

Systems & Data Team
0.6 18-10-2018 Input Model Design
0.7 18-10-2018 Input Business Design / Process
0.8 9-11-2018 Comments on the Model Design

section have been processed.
Review comments of embedded

gaps & solution template have been
processes.
0.9 9-11-2018 Review comments on the processes

section have been processed.
0.10 13-11-2018 Edits to section 1, adjusted the

executive summary, added list of
working assumptions.
0.11 14-11-2018 Edits to chapter 4, moved the

working assumptions from the
executive summary to chapter 2.4,
edits to executive summary (added
reference to chapter 4).
0.12 16-11-2018 Edits in chapter 1.2, 2, 3.1 and 3.2

for business requirements
3
0.13 21-11-2018 Edits based on review DSD author.
Deleted requirements mapping
overview that was after the work
done. Added review comments to
be processed.
0.14 22-11-2018 Edits to Table 1 in the executive

summary. Additionally, updated the
text, imbedded files and figures in
chapter 4.4
0.15 28-11-2018 Reviewed input business

requirements, amended minor
items.
0.16 29-11-2018 Review input system-data.
0.17 30-11-2018 DSD author review, minor edits,

various comments.
0.18 4-12-2018 Process reviews PERSONS
0.19 10-12-2018 Review based edits. Edits to

distribution list, working
assumptions in exec summary,
format edits.
0.20 13-12-2018 Added review comments from

PERSON (non-life SME, on behalf of
Bouke Evers). Processed review
comments of DSPM-lead review
(PERSON), PERSONS
(implementation team).
0.21 15-1-2019 Edits based on review comments

INSURANCE COMPANY A PO
(PERSON).
0.22 22-1-2019 Minor edits for DA review version.
0.23 23-1-2019 Edits based on review comments

Quality Assurance (PERSONS).
Edits based on review comments

received following the DA
walkthrough (PERSON).
0.24 8-2-2019 Edits on models (wording,

landscapes) to reflect draft IFRS 17
solution outline and related change
initiatives.
4
0.25 12-2-2019 Edits based on review for edits
made for IFRS 17 solution outline
update.
0.26 14-2-2019 Upgrades to reflect IFRS 17 solution

outline.
Edits based on review by

Implementation Lead (PERSON)
about an IFRS 17 solution outline.
Added new section 5 Change

initiatives, converted suggested
solutions in the format of the recent
update in the DSD template update
and change initiatives log.
Moved working assumptions into a

separate section, added teaming.
0.27 15-2-2019 Review by PERSON for draft IFRS 17

solution outline alignment.
Edits to various suggested solutions

and sections to reflect the IFRS 17
solution outline and reference to
relevant sections.
0.28 18-2-2019 Edits to align change initiatives log

and updates for processes and
controls (objective and disclaimer).
Additional replies to review

comments placed in document to
reflect upgrade for IFRS 17 solution
outline.
Review PERSON and edits to align

with recent draft IFRS 17 solution
outline.
5
Distribution
Version Date Name Version

0.16 30 Nov 2018 - DSD author (PERSON) Version to start review cycle,
total review by DSD author
0.17 3 Dec 2018 - DSPM-leads other than Version for total review by IFRS
DSD author (PERSON) 17 DSPM-leads, to proceed to
MT IFRS 17 review
0.19 10 Dec 2018 - First review MT IFRS 17 Version for review by MT IFRS
and INSURANCE 17 and INSURANCE COMPANY A
COMPANY A group group, to proceed to review by
(PERSON) INSURANCE COMPANY A PO
and PM
0.20 13 Dec 2018 - INSURANCE COMPANY A Version for review INSURANCE

Product Owner (PO, COMPANY A PO and IFRS 17 , to
PERSON) and IFRS 17 proceed to Design Authority
Implementation lead walkthrough
(PERSON)
0.22 22 Jan 2019 - Design Authority Version for Design Authority

members review
0.23 29 Jan 2019 - Design Authority Version for Design Authority

members for approval approval session
0.28 18 Feb 2019 - Design Authority Version for Design Authority

approvalal architecture approval by email round
upgrade
Final
Approvals
Version Date Name approver Approval

0.23 31 Jan 2019 Design Authority Disapproval by PERSON (approval of only “no
regret moves”). Approval by email round.
No quorum for DA approval due to not all DA

members represented.
0.28 18 Feb 2019 (by Design Authority

email round)
6
Teaming
Role Name
Owner PERSON
Management Owner PERSON
Business Requirements PERSON
Process and controls PERSON
Models PERSONS (IFRS 17 SME review)
Data and systems PERSON
INSURANCE COMPANY A PERSONS

Involvment
7
Contents
1 Introduction....................................................................................................................................7
1.1 Executive summary...............................................................................................................7
1.2 Context................................................................................................................................12
1.3 Working assumptions..........................................................................................................15
2 Detailed design scoping................................................................................................................17
2.1 Functional model coverage.................................................................................................17
2.2 IFRS 17 Solution Outline......................................................................................................18
2.3 Business process.................................................................................................................20
3 Policies and Business Requirements.............................................................................................22
3.1 Related policies...................................................................................................................22
3.2 Related business requirements...........................................................................................22
3.3 Reporting timelines.............................................................................................................23
4 Detailed solution design...............................................................................................................24
4.1 Business Design / Process / Use case..................................................................................24
4.1.1 AOV.................................................................................................................................24
4.1.2 WIA.................................................................................................................................33
4.2 Functional design / architecture diagram (optional)...........................................................42
4.3 System design.....................................................................................................................42
4.3.1 System functionalities.....................................................................................................43
4.3.2 User Interface (UI)..........................................................................................................43
4.3.3 Services...........................................................................................................................43
4.3.4 Authorization matrix.......................................................................................................44
4.4 Model design.......................................................................................................................44
4.4.1 Summary of gaps and suggested solutions (to-be model landscape).............................44
4.4.2 Dependencies and other placeholders for the current suggested solutions...................46
4.4.3 Template with gaps and solutions..................................................................................47
4.4.4 Model landscapes...........................................................................................................48
4.5 Data design.........................................................................................................................54
4.5.1 Interfaces (incoming and outgoing)................................................................................55
4.5.2 Functional data model....................................................................................................57
5 Change initiatives.........................................................................................................................59
6 Implementation effort..................................................................................................................66
7 References....................................................................................................................................67
7.1 Document References.........................................................................................................67
8
7.2 List of Abbreviations and Terms..........................................................................................67
8 Appendix A: Business requirements process impact....................................................................68
8.1 AOV Business requirements with a process impact on pre-processing...............................68
8.2 AOV Business requirements with a process impact on run models....................................69
8.3 AOV Business requirements with a process impact on post processing.............................72
8.4 WIA Business requirements with a process impact on pre-processing...............................73
8.5 WIA Business requirements with a process impact on Run models....................................76
8.6 WIA Business requirements with a process impact on post-processing.............................80
8.7 Overview of the Non-Life Disability Products......................................................................82
9 Appendix B - Quality Assurance....................................................................................................83
9
1 Introduction
The purpose of this document is to:
• Demonstrate the end-to-end detailed solution design for the Actuarial models and
calculations – Disability (AOV/WIA) within the INSURANCE COMPANY A IFRS 17 Programme.
• Establish the business processes, controls and systems and data parts that underpin the
delivery of the Detailed Solution Design (DSD) for the Actuarial models and calculations –
Disability (AOV/WIA).
• Establish sufficient detail on the delivery component for the completion of functional
specifications including processes & controls, systems and data components.
• Provide lineage to functional and technical design / configuration documentation.
This DSD needs to be read together with the documented IFRS 17 Solution Outline where further
details on the as-is and to-be architecture aspects are stated. Please refer to section 2.2.
First, some introduction notes about the structure of this DSD.
The document structure is derived from the scope of “Disability” products of INSURANCE COMPANY
A Schade and current working assumptions for IFRS 17 about those products. This DSD covers the
actuarial model landscape (pre-processing/valuation/post-processing) for the “Disability” products
of:
- Arbeidsongeschiktheidsverzekeringen (AOV), and

- Products related to the “Wet werk en Inkomen naar Arbeidsvermogen” (WIA).
There are sections in this document that address AOV or WIA separetely. The reason to do so is that
a working assumption at the start of drafting this DSD had to be adjusted during drafting the DSD.
The prior working assumption was that the AOV and (most of) WIA-products would be measured by
the General Model (GM). The current working assumption is that all WIA-products are eligble for the
Premium Allocation Approach (PAA). This change in working assumptions is due to the determined
change (from GM to PAA) in the IFRS 17 product classification and related measurement approach
for WIA products in Q3 2018.
Following an impact analysis about what it means in the design to go from GM to PAA for WIA, it
appeared the differences between PAA and GM are primarily on the required processes/controls,
data-systems, and to a lesser extent on models. Be aware that while applying PAA, one should always
be able to determine the GM valuation of the Liability For Remaining Coverage (LFRC) when facts and
circumstances arise that the product becomes onerous. Also, a GM valuation is applied to the
Liability for Incurred Claims (LIC).
10
It was considered more efficient to keep 1 DSD in place and only where needed address the specifics
of AOV (GM) and WIA (PAA) separate, compared to drafting 2 separate DSDs (one for AOV and one
for WIA) with a lot of overlap.
1.1 Executive summary
This section provides an executive summary, containing the key take aways from this document.
These key take aways are provided below and are split into:
- The value to progress the DSD in a context of requirements developed in iteration;

- The developed detailed model gaps and solutions in the model landscape of INSURANCE
COMPANY A for Disability products;
- The suggested “no regret moves” for this model landscape;
- The standard process applied to develop a single suggested model solution per model;
The working assumptions applied and their potential impact on solution design are provided in
section 1.3.
The value to progress the DSD in a context of requirements developed in iterations
- The identified detailed gaps and solutions for models, data, systems and processes in this
DSD are based on the high level business requirements 1.
- Level II (more detailed) business requirements are being developed in iterations 2, requiring
future iterations of this DSD too to cover all level II business requirements (and relevant NL
decision papers).
- There are also operational and/or strategic items related to applying the IFRS 17 standard
that need to become clear in the future and can yet affect the solution design 3.
- There are also items not derived from the IFRS 17 standard that nonetheless can impact the
solution design, such as the model run-time available in the IFRS reporting calendar to run
actuarial models. See section 3.3 about currently expected reporting timelines.
- Hence the exact impact of IFRS 17 on the processes still needs to be determined. Impact
summaries on the processes for AOV and WIA are provided in section 4.1.1 and 4.1.2.
- An overview of items on which the model design is dependent and placeholders for open
items, is provided in section 4.4.2.
- Nonetheless, in this context of placeholders for open items (known unknowns), it is
considered very valuable to already develop detailed solutions , as this helps to early identify
the many impacts and required changes to (as-is) actuarial model landscapes to become fit
for purpose for IFRS 17 reporting. Some model changes always have to be made (e.g. to
reflect IFRS 17 groups of contracts), regardless of further detailing of requirements and/or
closing of open items.
1
Delivered in the high level solution design phase
2
First cut-off point as per 27-11-2018. Processing additional requirements entails amongst others to develop an understanding of the
requirements, a gap-analysis and gap-verification, solution development and verification.
3
For example, the number of IFRS 17 groups of contracts to be measured and processed as of transition going forward, which is expected
to depend on the outcome of analyses of IFRS 17 transition approaches.
11
The developed detailed model gaps and suggested solutions in the model landscape of INSURANCE
COMPANY A Disability
- This DSD mainly covers the identified detailed model gaps and solutions, needed to become
fit for purpose of IFRS 17 reporting, for the model landscapes for Disability products
(AOV/WIA);
- The progression of suggested solutions, aside from reviews and approvals, include picking up
any identified no regret moves for next steps in implementation of the design, such as:
o Model documentation for the suggested design solutions (e.g. preparing functional
specifications for the suggested design);
o Model optimizations (e.g. analysis focusing on performance enhancements,
rationalization of models by automation of data transfers and controls);
- The table below provides a high level summary (details in section 4.4.3) per model of:
o Suggested model solutions;
o Whether or not the suggested model solution is considered to be a development for
the future state or intermediate for IFRS 17, and why 4;
o Any expected impacts on the model use and related performance.
o Please note, that the suggested solution following the scope of this DSD excludes
model suggestions regarding the IFRS17 risk adjustment and potentially related the
SII risk margin model.
All identified suggested solutions from this DSD have been renamed into change initiatives and on an
item by items basis are logged in section 5.
Model Summary of suggested solution Is the suggested model Expected impact of

for each model solution future state? suggested Solutions on
model
use/performance
AOV & WIA - SAS Replace the model with fit for Short term: Solution is an A negiligable impact.
(Model ID 3054, purpose data delivery. Ideally this intermediate solution as
Processflow model would become obsolete by the current SAS model is
FN76 AOV, FN76 an automated process of data only adjusted.
WIA) delivery for IFRS 17 calculations
where the data comes from a data
lake with a financial publication Long Term: The SAS
layer. model is replaced by fit
for purpose data delivery
via the data lake as
outlined in IFRS 17
Solution Outline, Section
8.1.
AOV – Generate Replace the model with fit for In the future state fit for A negiligable impact on
4
CME is considered in scope when replacing or building new models in “R”.
12
model
use/performance
folder and data purpose data delivery. Ideally this purpose data will be the model, but may
(Model ID 4301, model would become obsolete by delivered from the data impact processing
Processflow an automated process of data lake directly to the model time.
FN76 AOV) delivery for IFRS 17 calculations environments as outlined
where the data comes from a data in IFRS 17 Solution
lake with a financial publication Outline, Section 8.1
layer. The data delivery must be
adjusted to include the acquisition
expenses and to load multiple
discount curves in the data sent to
Risk Agility.
WIA – Schade This model will most likely remain In the future state fit for N/A
WIA (Model ID unchanged for IFRS 17 and the purpose data will be
3055, functionality of this model must be delivered from the data
Processflow built into the financial publication lake directly to the model
FN76 WIA) layer of the data lake. environments as outlined
in IFRS 17 Solution
Outline, Section 8.1
AOV - In line with the IFRS 17 Solution Solution is future state, Small impact on run
Premieterug xl- Outline Section 7.3 build a model as it is in line with the time. A significant
model (Model ID in R to create undiscounted cash IFRS 17 Solution Outline, impact on entire
4323, flows on IFRS 17 group of contract Section 7.3 processes as it requires
Processflow (cohort). This can be done by keeping track of more
FN76 AOV) converting the current Excel model cash flows.
to R and adjusting the aggregation
routine of that model.
AOV - Excels for In line with the IFRS 17 Solution Solution is future state, A large one off impact
Collective Outline Section 7.3 build a model as it is in line with the to change the triangles
(Model ID 4302, in R to provide current IBNR cash IFRS 17 Solution Outline, from accident year to
Processflow flow reserves (IFRS 17 included in Section 7.3 underwriting year is
FN76 AOV) the best estimate cash flows for expected.
the LIC) on underwriting year. This
can be done by converting the
current Excel model to R and
convert with claims triangles
based on accident year to
underwriting year.
Risk Agility The model must be adjusted to Solution is future state Small impact on run
Model (AOV produce undiscounted cash flows as it uses Risk Agility as in time. A significant
Model ID 2050, on an IFRS 17 group of contract stated in IFRS 17 Solution impact on entire
WIA Model ID level. Outline, Section 7.3 processes as it requires
13
model
use/performance
2077, keeping track of more
Processflow The AOV Risk Agility model must cash flows.
FN76 AOV, FN76 be adjusted to perform
WIA) calculations based on differences
in the contract boundary.
WIA – ResQ The short term solution (before Solution is an Short term: Small to no
(Model ID 4296, IFRS 17 implementation date): intermediate solution as impact on the current
Processflow the model will still run in reporting process.
Keep the current method of
FN76 WIA) Risk Agility.
calculating the IBNR (forms part of
the LIC calculation under IFRS17)
Long term: Will reduce
and use the cash flow functionality
the time required for
in ResQ to develop IBNR cash
reporting as only one
flows.
valuation model has to
run.
The long term solution (expected

after the IFRS 17 implementation
date due to high expected efforts
and external stakeholder
dependencies5):
The IBNR reserve is determined in

the Risk Agility model utilizing an
individual claims reserving
methodology.
WIA – In line with the IFRS 17 Solution Solution is future state Some impact is
Stoplichtenmode Outline Section 7.3 build a model as it uses R, in line with expected as the model
l (Model ID 4297, in R (converting current Excel the IFRS 17 Solution will have to determine
Processflow model) to perform the adjustment Outline, Section 7.3. its calculation on a
FN76 WIA) of the initial expected loss on different aggregation
IFRS17 portfolio level. level
WIA – Scaling In line with the IFRS 17 Solution Solution is future state Some impact is
factors (Model ID Outline Section 7.3 build a model as it uses R, in line with expected on the model
4305, in R (converting current Excel the IFRS 17 Solution as more cashflows are
Processflow model) to produce cash flows here Outline, Section 7.3. produced
FN76 WIA) on accident year basis and
improve the data quality issue in
the source systems to model all
policies in the ResQ model
AOV & WIA – In line with the IFRS 17 Solution Solution is future state Some impact is
5
This development requires a change in reserving methodology which will also require an agreement from external parties (DNB)
14
model
use/performance
Collection Sheets Outline Section 7.3 build a model as it uses R, in line with expected as it requires
(AOV Model ID in R (converting current Excel the IFRS 17 Solution loading more/multiple
3045, WIA Model model) to include the cash flow Outline, Section 7.3. cash flows.
ID 3053, overview per cohort.
Processflow
FN76 AOV, FN76
WIA) Additionally the new R model
must be adjusted to include the
cash flow overview of acquisition
expenses per cohort.
For the R model converting

current Excel collection sheet ID
3045, incorporate the additional
cash flows produced by the new
model for PVI (new built model to
take away an outside adjustment).
(This model could also be used as

the point where all discounting
takes place.)
Table 1 Summary of suggested detailed solutions for models
The suggested “no regret moves” for this model landscape
- A list of suggested “no regret moves” is provided below.

- “No regret moves” are actions that add value when picked up, regardless of the closing of
any open items for IFRS 17.
- The suggested actions below need to be verified, and if needed adjusted, by stakeholders for
model changes ouside of IFRS 17 within the same model landscape (e.g. for remediations for
Solvency II, audit findings, etc.).
Topic Type Model What Why

Architecture Design All Define the future state To become in line with an IFRS 17
for non-life actuarial Solution Outline.
models on the basis of
IFRS 17 Solution
Outline Section 7.3
through determining:
15
- whether the future
state supports Risk
Agility, ResQ and start
writing functional specs
to convert any excel
models to R
- for the pre-processing

data part as outlined in
IFRS 17 Solution
- how to incorporate
the post-processing
into the CMRE
Investigate System All Following IFRS 17 In line with IFRS 17 Solution

replacemen change Solution Outline Outline.
t of the Section 7.1 for any
preprocessi replacement of SAS
ng SAS pre-processing models
models by with FPL functionality.
FPL
functionality
Valuation Prepar AOV - Risk Adjust the model such The current model is not able to
model e, Agility Model that it can perform distinguish different contract
Model calculations based on boundaries in the portfolio. The
Change (ID 2050)
differences in the contract boundary of the AOV
contract boundary. product with combi premium is
different for the riskbased-tarriff
part and the level-tarriff part. AOV
Make all required cash contracts with 1 year contract
flow output available at boundary will not be included in
the IFRS 17 group of the same portfolio of insurance
contracts level. contracts with AOV contracts with
a contract boundary of retirement
age.
Start with
documentating Output is needed per IFRS 17 group
how/what (functional of contract (e.g. cohort).
specifications).
The model must at least be able to

produce undiscounted cash flows
on an IFRS 17 group of contract
level.
16
Valuation Prepare, AOV - Make the cash flow Output needed per IFRS 17 group
model Model Premieterug output available at the of contract (e.g. cohort).
Change xl-model IFRS 17 group of
contracts level.
(ID 4323)
The model must at least be able to
produce undiscounted cash flows
Start with
on an IFRS 17 group of contract
documentating
level.
how/what (functional
specifications).
Valuation Prepare, Documentati Document how and in Currently there is no reserving
model Model on to new which modelling model for the PVI portfolio.
Build build model software to model the Furthermore, this portfolio is a
for PVI PVI portfolio. growing portfolio which is already
above the level of materiality for
INSURANCE COMPANY A Schade.
PAA IFRS 17 Facts and Develop, document Currently there is no process in

Onerous Method circumstance and draft a process to place to determine whether a WIA
contracts ology s determine if a contract contract is onerous. It will be
has become onerous possible to identify further gaps
by facts and and solutions in the process, once
circumstances. Include the facts and circumstance are
the information by defined.
which to do so
Valuation Prepare, AOV - Excels Investigate and Currently the model performs
Model Model for Collective document the: triangle analysis on accident year
Change (ID 4302) basis, however under IFRS 17 it will
- change from
be easier (saves run time) if the
accident year
calculations are performed on
to underwriting
underwriting year.
year by
checking if
claims data is
available on
underwriting
year.
Valuation Prepare, AOV - Excels Investigate and Following the IFRS 17 solution
Model Model for Collective document the: outline, section 7.3
Change (ID 4302)
- Change the
model from
excel to R
Table 2 List of suggested “no regret moves”
17
The standard process applied to develop a single suggested model solution per model
In order to develop suggested solutions that can be traced to business requirements, a standard
process has been applied to all models and outside adjustments in scope of this DSD. The figure
Pros D
Possible S
Business Gap 1 - N e
requirements X* Description
solutions for gap S
1- N p U
Cons S O
M e G
n I L
O G
d N U
D e
E
G T
E n S
L I
L Pros
c T
Possible i E O
Business Gap 1 - N E
requirements Y* Description
solutions for gap e N
1- N D
Cons s
*Note that multiple business requirements can be combined in order to identify one gap
below visualizes this process.
Figure 1 The standard process applied to determine a single suggested model solution per model
1.2 Context
From high level solution design to detailed solution design

In the high level solution design phase of the IFRS 17 project (running till July 2018), the high level
impacts of IFRS 17 on the model landscape, system landscape, data, processes and controls of
INSURANCE COMPANY A have been identified. In the subsequent phase of Detailed Solution Design
(DSD), the goal is to develop solutions to any gaps to become fit for purpose for IFRS 17 reporting, by
the detailed design of processes and controls, systems-data and models.
In this DSD the impacts on the model landscape are further detailed into model gaps, the potential
solutions are identified to close the identified model gaps, and suggested solutions are provided for
this model landscape. This forms the core of this DSD.
The suggested model solutions to get IFRS 17 compliant are provided in section 4.4.1.
Also part of this DSD are the impact analyses towards a to-be design for related processes and
controls and systems-data. This is based on the as-is model landscape, as-is system-data landscape,
as-is processes and controls and identified model gaps and solutions.
Working with requirements developed in iterations

The detailed solution design solutions covered in this DSD are based on the high level business
requirements that have been developed in the high level solution design phase (running till July
2018).
Several NL decision papers, that cover the accounting and methodology choices of INSURANCE
COMPANY A with respect to the IFRS 17 standard, are still being developed within INSURANCE
18
COMPANY A. As such, further iterations will be needed for the business requirements 6 that follow
from the decision papers, as well as further iterations of the DSD to identify any further gaps that
could result from any new requirements, and how these could be resolved.
In addition to new (or more detailed) level II business requirements as described above, there can
also be requirements not specific to the IFRS 17 standard, such as on reporting timelines and derived
run-times.
The high level reporting timelines are clear, but need to be detailed out in the coming period. A need
for shortened model run-times (performance improvement) is taken into account in developing
model solutions. When more detailed reporting timelines are clear, this can impact the gaps and
detailed solutions for processes and controls, systems-data and models.
The high level business requirements were not developed in a context of existing DSDs, which is why
the business requirements taken in scope for processes and for models can differ. See section 3.2
and the references below for the related business requirements. For future iterations the level II
business requirements will serve as the basis for requirements and will provide direct links
underlying dimensions of the DSD (e.g. processes, systems-data, models).
The high level business requirements that were taken in scope for an impact analysis on processes
and controls and for the model gaps and solutions are stated in:
- section Error: Reference source not found for a process perspective;
- section Error: Reference source not found for a models perspective.
Any placeholders (open items), or other potentially relevant items, that may still impact the solution
design from a models perspective and from a process and controls perspective, are also stated in the
above mentioned sections.
Below the current context is provided for the DSD dimensions for processes, systems and data, and
models.
Context of processes
For processes the changes triggered by IFRS 17 business requirements in data, models or systems
need to be taken into account. Changes in one or more aspects can lead to changes in activities,
interfaces, responsibilities, timelines or complexity levels in the end-to-end processes.
Furthermore all these changes can impact controls that are in place, or could lead to other ways of
controlling the dataflow, calculations and information in the end-to-end IFRS 17 process.
The impact on the process and the suggested detailed process solutions are provided in section 4.4.1.
Context of data and systems7
6
These are called Level II business requirements
7
Caveat: conclusions reached in this document are subject to changes upon final decisions taken in the data and system environment and
therefore have to be update accordingly.
19
The functionalities used to process data for the AOV and WIA models are currently situated within
the INSURANCE COMPANY A environment. There are Enterprise Administration Systems that
generate the contract and customer information used. These Enterprise Administration Systems will
be called primary data sources, and include the AESIS and SIA systems, Setting Advisory Database
(SAD) plus other systems that interface directly with external components.
There are additional systems that collect, hold and process information from the primary data
sources, and sends these to the models. These systems will be called secondary data sources, and
include SAS (LAN) and data lake. In the intermediate and future state, the data augmentation
database will also fall within this category. The system landscape (as-is and to-be) is further
detailed in IFRS 17 Solution Outline, Section 8.1.
The functional design is going to make enhancements to current data generated from the secondary
source (SAS LAN/ Data Lake/ Data Augmentation) for enrichment that do not currently exist in the
present landscape of IFRS4 or Solvency II. In the future state, all information from the enterprise
adminstration systems is available in the Data Lake for further processing and enrichment with IFRS
17 data.
The functional design for changes or modifications to the individual components or interfaces that
need adjustments, or complete changes, are not fully known due to ongoing key design decision
discussions (with all relevant stakeholders) regarding data augmentation and CSM vendor
selection8.
Context on actuarial models

For the scope of this DSD, the following types of models are in scope as outlined in IFRS 17 Solution
Outline, Section 7.3:
- Pre-processing models (Model ID 3054, 4301, 3055) : to load, enrich/transform data, as input
to valuation models.
- Valuation models (Model ID 4323, 4302, 2050, 2077, 4296, 4297, 4305) : to project cash flows
and/or discount those cash flows and/or to develop claims triangle analysis 9.
- Post-processing models (Model ID 3045, 3053) : to process output from valuation models for
further reporting including adjustments for unmodeled elements or outside model
adjustments (e.g. scaling of output from valuation models).
The starting point for the models are the models currently used for Solvency II reporting for non-life,
and the output from IFRS 4 calculations for the Unearned Premium Reserves (UPR). When this
document refers to current models, it is referring to models currently used for Solvency II unless
stated otherwize. With regard to current models for LFRC for PAA products, this will be more similar
with current IFRS 4 ‘calculations’; this is derived from the General Ledger. When a Loss Component
(LC) is applicable, the LC can be added mannualy similar compared to an UPR (when this UPR was
included under IFRS4). The suggested detailed solutions per model, to become fit for purpose for
IFRS 17, are developed and provided based on those current models.
The suggested detailed model solutions are provided in section 4.4.1.
8
Refer to the RFP on the CSM vendor selection here:
9
For Non-Life models the run-models can have a different purpose, such as to construct claims triangles.
20
1.3 Working assumptions
The working assumptions applied and expected impact on solution design:
- To allow progress given various open items, several working assumptions are applied;
- The current identified and applied working assumptions are listed below (see also section
Error: Reference source not found).
- The working assumptions and details can still develop (e.g. when new information or insights
emerges, when implementation questions or issues arise).
- This list of working assumptions has to be reviewed in future iterations of the DSD, to see if
requirements and/or business decisions have changed these working assumptions, and if so
how that would impact the solution design.
Type of working assumption Working assumption applied Expected sensitivity of

design solutions to the
working assumption
Unit of account / IFRS 17 groups of Annual cohorts, starting 1-Jan Amount of output and
contracts any required allocation
steps is linear to number
of IFRS 17 groups of
contracts.
Frequency of IFRS 17 reporting At least 2 times per annum, If more runs needed,
runs potentially per quarter more frequent data input
feeds, more model runs,
more data output to
following systems (CSM,
RA, ledger), more
frequent execution of
process controls
Level of model output, for CSM or Per IFRS 17 group of contract If on policy level, impact
Risk Adjustment (e.g. not on an IFRS 17 portolio on amount of data and
level with allocations). process runs (Risk
Adjustment, movement
analysis), to feed
following systems, more
detailed allocation of
acquisition expenses.
Where to discount any cash flows Within the model landscape If outside the model
Disability landscape, easier process
to provide output (easier
to do less). Also,
INSURANCE COMPANY A
Schade has decided not
to disaggregate
Insurance Finance
21
working assumption
Income or Expense; so all
discounting will be on
current discount rates.
Measurement model for AOV General model (GM) If PAA, PAA still requires
GM functionality, change
in process (onerous
based on monitoring
facts and circumstance)
Measurement model for WIA Premium Allocation Approach If GM, under PAA the GM
(PAA) functionality already
needs to be present.
However, the CSM can
have a large impact on
the suggested solutions.
Type of model output, for Risk Present value of expected cash Impact of different
Adjustment, CSM or sub-ledger flows choices mainly on
amount of data, process
runs (Risk Adjustment,
movement analysis) and
input requirements of
subsequent systems.
Acquisition expenses The amortization of the acquitision Building the amortization of
expenses will occur outside the model the acquisition expenses in the
environment. models is relatively simple if
the data needed to do so is
provided in line with the level
of calculations (e.g. IFRS 17
required granularity).
Data Lake The implications of the model This assumption only affects
environment on the data lake is where the initial input data
considered out of scope for this DSD comes from and has limited to
(e.g. if the model environment requires no impact on the processes
input data from the data lake such as and calculations within the
the IFRS 17 group of contracts ID then model environment.
the delivery and development of this
data is not in scope of this DSD)
Amount of time available to run 2.5 workdays to run models in Solutions highly depend
the whole process involving the actuarial model on available time to run
actuarial models environment (see also section all models and control the
3.3) and the working assumption process.
now is that the models start
running on work day 0.5 and
ends the end of work day 3.
22
working assumption
Documentation Working assumption applied Not applicable
that the as-is process flows on
the INSURANCE COMPANY A
process landing page are
reflecting the real as-is way of
working withing INSURANCE
COMPANY A. If deviations are
encountered in the real as-is
compared to the document on
the process landing page, the
IFRS 17 program will reach out
to the INSURANCE COMPANY A
process owner, but will not
correct the as-is. If such a
deviation is important for IFRS
17 and the solution design, this
will be mentioned in this DSD.
Table 3 List of identified and applied working assumptions impacting solution design from this DSD
23
2 Detailed design scoping
In this section the detailed scoping of this DSD is described.
2.1 Functional model coverage
For the development of the detailed design, INSURANCE COMPANY A Group has rolled out a so-
called Finance and Risk Functional Framework. This functional framework describes all the different
components of the end to end financial reporting process and covers different levels of granularity,
ranging from level 1 (least granular) to level 4 (most granular information).
The scope of this document is for:
- INSURANCE COMPANY A Netherlands

- Level 1 – Actuarial
- Level 2 – Actuarial Models and Calculations - Disability
The Level 2 scope of “Actuarial Models and Calculations” is split into separate scopes for:
- Life;
- Pensions;
- Disability (AOV/WIA);
- P&C and Sickness (Schade Object en Ziekteverzuim);
- Reinsurance.
This split is made to allow a more targeted and focused scope to develop detailed solutions for the
impacts on each of the model landscapes of INSURANCE COMPANY A Netherlands 10.
The Level 2 scope is extended in this case to “Disability” only, which will from hereon be referred to
as the scope of “Actuarial Models and Calculations - Disability”. This scope is visualized by the grey
shaded area in the below table linked to the INSURANCE COMPANY A F&R Functional Framework.
Actuarial Level 1
Level 2 Level 3 Level 4
Assumptions Manage & publish actuarial assumptions

Actuarial Develop & maintain actuarial models
Models and
Load & prepare data for actuarial model run Assumptions
Calculations
Reference data
10
The INSURANCE COMPANY A Netherlands model inventory (as-is) and product inventory makes clear which actuarial models and
calculations are used for which insurance products in each model landscape (Life, Pensions, Non-Life).
24
Contract Data
Market Data
Calculate risk constituents (probability, cash flows)
Calculate valuations + movements steps

Calculate underwriting risk measures & capital
Publish actuarial data

Actuarial Analyze & publish value/risk movements
Analysis
Manage & mitigate insurance risk
Analyze actuarial outcome including impact analysis
Risk Determine risk adjustments

Adjustments
Disaggregate risk adjustments
Publish risk adjustment cash flows
Table 4 Breakdown of the Finance & Risk Functional Framework for Actuarial Level 1, to which DSDs
are mapped.
Reference to relevant decision papers (NL decision papers)
In the following table a mapping is provided on the dependencies between the DSD for Actuarial
models and Calculations Disability and the NL decision papers.
NL decision papers Applicable
NL decision paper WG 1.03 Risk Adjustment
NL decision paper WG 1.02 Solvency II vs IFRS 17 HRG assessm. X

NL decision paper WG 1.02 VFA eligibility for SA and GA
NL decision paper WG 1.02 Classification NL Position paper X

NL decision paper WG 1.02 Grouping NL Position paper X
NL decision paper WG 1.04 Discount rate X

NL decision paper WG 2.03 OCI vs P&L X
NL decision paper WG 3.03 Transition accounting
25
NL decision paper WG 2.04 Accounting Mismatch Management
NL decision paper WG 1.01 - Contract boundary X
NL decision paper WG 1.01 - Definition

NL decision paper WG 1.01 - Modification and de-recognition X
NL decision paper WG 1.01 - Separation of components

NL decision paper WG 2.01 - Cash flow definition X
NL decision paper WG 2.02 - CSM accounting X

NL decision paper WG 3.02 - Reinsurance
NL decision paper Premium Allocation Approach X

Table 5 Overview of relevant NL decision papers and their relevance for this DSD
Business requirements and/or other relevant items not yet in scope
The actuarial models and calculations need to deliver IFRS 17 required outputs to following systems
and/or calculations in the IFRS reporting chain in an auditable fashion. To do so, the actuarial models
require inputs from preceding systems or calculations, next to being able to process those inputs into
required outputs for following systems or calculations (e.g. Risk Adjustment, CSM).
For this DSD version some relevant IFRS 17 methodologies and business requirements are not final
yet and provide placeholders on the design. From a process perspective, the placeholders are
provided in section 4.1. From a models perspective the placeholders are provided in section 4.4.
These placeholders, when final, can impact the gaps and/or detailed solutions through the required
outputs and/or inputs to the actuarial models and calculations and/or the functional design of
models, and/or the related processes and controls, and/or the systems-data design.
2.2 IFRS 17 Solution Outline
This DSD is based on the IFRS 17 solution outline. The latest (draft) version of the solution outline can
be accessed using the link below:
LINK DELETED
An overview of the current INSURANCE COMPANY A Netherlands system architecture landscape (for
non-life) can be found in the IFRS 17 Solution Outline, section 7.4.
26
Furthermore, the future state has been depicted in paragraph 8.1 of this document. Below the to-be
system overview has been included:
Cost data
Realised (Premiums / Claims) CFs - Creditor / Debtor (P)
Gl data
GL postings
CSM
A C D
B D
Data Data Publication General Ledger
storage Layer IFRS 17 Calculation
administration
& consolidation
PeopleSoft
Fit for Fin. Assump.
purpose BEL CFs
Finance systems dataset 1 nVision
(Aenvoud) Realised CFs
(Creditor / RA Shock CSM ARE
Debtor)
Fit for Actual CFs* & D
Asset purpose Cost data
Assets Reporting
data dataset 2
(SCD / MIAR)
Opening
Liability Balance MTP Tax
..
Underwriting data
systems Invoiced / GL
Incurred CFs postings Annual
PowerBI
reports
.. GL data
Cost allocation Cost data Various
engine
Asset & Glo ria
Liability E
Cost .. Financial modelling
assumptions data
Assump Assump
tions tions
CMRE ResQ
Tagged ...
BEL CFs RAFM
SAD data D
Logic & cognition
RA Igloo
Data augmentation G
Market Custom analysis and lab
data
Market data
RA
BEL Cash flows
*Actuals CFs (used for IFRS 17 calculations) = Realised for premiums, Incurred for expenses and Incurred/reported for claims
Figure 2. The DRAFT simplified view of the finance application landscape at the introduction date of
IFRS 17
In-scope of for this DSD are the systems and data flows as depicted in the Figure below (a part taken
from the financial application landscape indicated further below).
27
Figure 3. The DRAFT simplified view of the the actuarial model environment in the finance
application landscape at the introduction date of IFRS 17
The IFRS 17 Solution Outline is expected to be approved on Feb 22 2019. Once approved the link to
the approved solution outline will be provided here.
2.3 Business process
Chapter 2.3 Business Process AOV
The business process that is in scope of this DSD is the process labeled as FN76 Opleveren Cijfers
MVN SII incl. LAT AOV:
- FN 76 Opleveren cijfers MVN SII incl. LAT Schade – AOV
The actuarial processes are different for the products AOV and WIA, therefore these processes are
split. Most of the process steps of the FN 76 process are in scope of this DSD. However, several of the
process steps are in scope of various other DSDs.
In the table below the process steps that are outside of the scope of this DSD are listed, as well as the
DSD in which they will be covered.
AOV process steps that are not in scope:
Process Description process step DSD in scope

step
1.1 Deliver policy extracts Liability Data Management
1.2 Deliver claims & policy data Liability Data Management
15 Data processing SAS-LAN AOV Sub Ledger11
11
This feeds the General Model in the As-Is processes; as Sub Ledger (Accounting Rule Engine) functionality will be placed before General
Ledger this will be the DSD in scope
28
step
16 Determine correction AOV (premium refund) Insurance operations
26 Draft and yield movement analysis Multiple (e.g. Actuarial
models, Risk Adjustment,
CSM, Financial
Consolidation and
Reporting)
27 Fill in the RO template (SF-SCR, P&L) Sub Ledger14
28 Book in PeopleSoft (BEL, MVM) Sub Ledger14
29 Deliver templates to RO (SharePoint) Financial Consolidation and
Reporting
30 Analyze and draft FRP Financial Consolidation and
Reporting
31 Deliver FRP (SharePoint) Financial Consolidation and
Reporting
Table 6 AOV process steps that are not in scope for this DSD
Chapter 2.3 Business Process WIA
The business process that is in scope of this DSD is the process labeled as FN 76 Opleveren Cijfers
MVN SII incl. LAT WIA:
- FN 76 Opleveren cijfers MVN SII incl. LAT Schade – WIA
Since the actuarial processes and the approaches are different for the products AOV and WIA, these
processes are split.
Most of the process steps of the FN 76 process are in scope of this DSD. However, several of the
process steps are in scope of various other DSDs. In the table below the process steps that are
outside of the scope of this DSD are listed as well as the DSD in which they will be covered.
WIA process steps that are not in scope:

step
21 Make and deliver movement analysis Multiple (e.g. Actuarial models,

Risk Adjustment, CSM, Financial
Consolidation and Reporting)
22 Fill in RO template (sf-SCR, P&L and booking) Sub Ledger14

23 Book in PeopleSoft (BEL, MVM) by accounting Sub Ledger14
24 Deliver RO templates (SharePoint) Sub Ledger14

25 Analyze and make narrative Financial Consolidation and
29
Reporting
26 Deliver narratives (SharePoint) Financial Consolidation and
Reporting
Table 7: WIA process steps that are not in scope
30
3 Policies and Business Requirements
This section provides the related policies, business requirements and reporting timelines, or
references to the sections further describing those.
3.1 Related policies
The NL decision papers relevant to this DSD are provided in section 2.
3.2 Related business requirements
The business requirements considered relevant for this version of the DSD are based on the high
level business requirements as delivered in the high level solution phase, as delivered in the file
“INSURANCE COMPANY A – IFRS 17 BR and GAP assessment v2.6_20180713”.
Not all high level business requirements are taken into scope for this DSD.
For the high level business requirements that are taken in scope of this DSD for process impacts,
please refer to:
- Section 4.1.1.1 for AOV;
- Section 4.1.2.1 for WIA.
For the high level business requirements that are taken in scope of this DSD for model gaps and
solutions, please refer to:
- Section 4.4.3, this section contains the gaps and solution template, which includes the high
level business requirements to which the model gaps and solutions are identified.
For the next iterations of this DSD, this section will provide the set of relevant level II business
requirements taken in scope of that DSD version, as embedded file and in tabulated form (business
requirement ID and description).
In the following table all high level business requirements relevant for the DSD Actuarial models and
Calculations Disability are presented.
BR ID Topic
BR.1.01 - 8 Definition/boundaries
BR.1.01 - 18 Definition/boundaries
BR.1.02 - 7 Classification and grouping
BR.1.02 - 10 Classification and grouping
BR.1.03 - 4 Risk adjustment
BR.1.04 - 5 Discounting
BR.2.01 & BR 2.03 - 7 Cash flows and OCI & PL
31
BR.2.02 - 15 CSM accounting
BR.3.04 - 3 P&C accounting
Table 8 Business requirements in scope
Note that the above table presents the high level business requirements that are directly related to
this DSD. However, other high level business requirements could have an indirect relationship with
the DSD in terms that they serve as input data or output data. For a full overview of this mapping
please note the DSD tagging tab in the level II business requirements Excel sheet (to be included in
the next version of this document).
3.3 Reporting timelines
The end-to-end to-be process, including models, systems and data should be able to meet the IFRS
17 reporting timeliness, which are further detailed in the following draft document: INSURANCE
COMPANY A reporting timelines. An overview of the current to be IFRS 17 reporting timelines is given
in the figure below.
Figure 2 Overview of the to-be IFR17 reporting timelines
Following the end-to-end to-be financial reporting process timelines, the existing working
assumption as defined in section 1.2 is that all data relevant for putting together the P&L should be
available in Peoplesoft on Workday 6. Furthermore, the earnings flash should be available to MT NL
on workday 8 and submitted to INSURANCE COMPANY A group on workday 9.
32
Based on ongoing discussions with FIM reporting in relation to the IFRS 17 reporting timelines the
current assumption is that the run-time of all Actuarial Models for Disability insurance related
contracts (AOV and WIA) is 2,5 workdays.
33
4 Detailed solution design
This section provides the detailed solution design for the parts of business processes, of the
functional architecture, of the systems, of the models and of the data.
4.1 Business Design / Process / Use case
For processes, the changes triggered by IFRS 17 business requirements in data, models or systems
need to be taken into account. Changes in one or more aspects can lead to changes in activities,
interfaces, responsibilities, timelines or complexity levels in the end-to-end processes.
Next to impacts on processes, all these changes can impact the controls that are in place, or could
lead to other ways of controlling the dataflow, calculations and information in the different DSD’s
and the entire IFRS 17 process.
For this DSD the impact of the IFRS 17 business requirements on the as-is Actuarial models processes
for AOV and WIA have been analyzed. For an overview of the AOV and WIA products, please refer to
appendix 8.7.
4.1.1 AOV
Management summary
At this stage many discussions are pending, the results of which determine the impact of IFRS 17 on
the processes. Those discussions are related to at least the following topics:
- Contract boundaries
o Currently the AOV product line of INSURANCE COMPANY A consists of two AOV products:
AOV combi premium and AOV level premium. For the level premium product, the contract
boundary is already clear and covered in the NL decision paper on contract boundaries.
o For the AOV combi premium product there is a possibility that administratively the risk
premium period will be split from the level premium period. This will affect the actuarial
model since it has to be run more often.
- Classification of IFRS 17 group of contracts / cohorts

o Contracts need to be categorized into IFRS 17 group of contracts (cohorts). How this will be
done and on what level of granularity is yet to be decided.
- Treatment of onerous contracts
34
o A new feature under IFRS 17 is the separation between ‘non-onerous’, ‘onerous’ and ‘other
contracts’. Based these categories, contracts will further be assigned to cohorts. How the
tags will be assigned to the groups of contracts is yet to be decided.
- Treatment of acquisition costs
The processes need to be updated to capture the following:
o The process should be able to identify and determine acquisition costs at a IFRS 17 groups of
contracts level, which requires more details in the (cost) assumption setting.
o At initial recognition the present value of expected insurance acquisition costs will be
determined. Then, the portion of premiums that relates to the recovery of insurance
acquisition cash flows of each of the years of coverage need to be determined. At
subsequent measurements those amounts will be recognized as insurance service expenses.
o It needs to be decided if the acquisition costs will be included in the cash flow models, or
allocated after the models.
- Treatment of contract boundaries

o Processes should be in place that are able to track the contract boundaries over time and
reassess the contract boundaries of the products at each reporting date. Evidently, the cash
flow models should be able to perform calculations based on IFRS 17 contract boundaries.
- Multiple locked-in discount curves

o The General Model uses multiple locked-in multiple discount curves for CSM calculations.
Discussions are pending on where these calculations will take place in the process and in
which models. In addition, it is yet to be determined how these curves will be retrieved and
where they will be stored.
- Functionalities of the CSM tool

o The design of the to-be process is dependent on the functionalities of the CSM tool, which
are not fully designed at this stage. The following items are still open:
 The level of granularity that is required by the CSM tool and the format of this input
data.
 The signaling and timing of the delivery of the input data.
Based on these items, additional controls need to be defined.\
- Data Lake
o In the to-be target IT Architecture all data flows via the Data Lake (as outlined in IFRS 17
Solution Architecture, Section 8.1). Any direct link between (source) systems and the
model environment will be replaced by a link with the Data Lake.
More details on the impact of these topics are elaborated upon in the following chapters.
35
Approach
A starting point for describing the AOV process is the INSURANCE COMPANY A FN 76 process
template (as presented in the below) and corresponding process description (FN 76 Opleveren cijfers
MVN SII incl. LAT Schade – AOV).
Working assumption applied that the as-is process flows on the INSURANCE COMPANY A process
landing page are reflecting the real as-is way of working withing INSURANCE COMPANY A. If
deviations are encountered in the real as-is compared to the document on the process landing page,
the IFRS 17 program will reach out to the INSURANCE COMPANY A process owner, but will not
correct the as-is. If such a deviation is important for IFRS 17 and the solution design, this will be
mentioned in this DSD.
In order to indicate the process impact of the IFRS 17 business requirements which are relevant for
this process, the business requirements are mapped to the INSURANCE COMPANY A current process
template. The as-is process flow is divided into three parts: pre-processing, run models and post-
processing.
Subsequently, a high level to-be process flow is prepared which includes control objectives split in
three categories: correctness, completeness and timeliness.
Please refer to the embedded PDF files:
Description PDF File
INSURANCE COMPANY A process flow FN 76 EMBEDDED FILES DELETED

FN 76 Opleveren cijfers MVN SII incl. LAT
Schade – AOV
INSURANCE COMPANY A As is process flow

including Business requirements
To be process flow including control

objectives
Table 9 Process templates AOV
36
4.1.1.1 Business requirement mapping
For this DSD a predefined set of high level business requirements related to Actuarial Models were taken into account.
The business requirements were mapped on the as-is processes to determine the impact of IFRS 17.
The business requirements were classified into the following two categories:
1. Business requirements with an undefined process impact, since the required information is not yet available (e.g.
because of pending discussions);
2. Business requirements which will most likely have an impact on the process (refer to Mapped business requirements).
Business requirements with undefined process impact

The business requirements listed in the table below might have an impact on the Actuarial Model process, but since sufficient
information is lacking the impact has yet to be determined.
Business requirements which do not have an impact and are out of scope for this topic are not included in this DSD.
BR ID Business requirement description Impact on process
1.01-7 Data should be (made) available to assess This is related to data

whether a change in contract's term results in: requirements that are in scope of
1) A contract becoming out of scope of IFRS 17,
the DSD: Base data management
and insurance operations. In this
2) Change of cluster, DSD the impact on the as-is
3) Change of risk insured. process needs to be determined
before the impact on the
Data should be (made) available to create processes within the actuarial
appropriate de-recognition and re-recognition
models DSD can be determined.
entries, for example updates of policy numbers.
There will be a modification

process that links into the
actuarial model process, this
modification process is in scope of
the Insurance Operations DSD.
1.01-8 Models should have the functionality/capability to The actuarial process impact of
treat changes in cash flows caused by the this required capability still needs
modification (not meeting any of the conditions in to be determined.
paragraph 72) of a contract as changes in
estimates of fulfilment cash flows, requiring
models to use updated cash flow projections at There will be a modification
every reporting period. process that links into the
actuarial model process, this
modification process is in scope
37
of the Liability Data Management

DSD.
2.01-7 Process should be in place to measure the More information is required

expected value of the future cash flows accounted regarding the specific changes
for under the General Model at the required level made to linear models before the
of unit of account. potential process impact can be
determined.
3.02-12 Models should have the capability/functionality to To be determined in the DSD

perform the calculation of reinsurance receivables related to reinsurance.
based on the modified General Model. This entails
measuring the receivables.
Table 10 Business requirements with undefined process impact
Mapped business requirements
The business requirements with an expected impact are mapped on the as-is process flow.
The table below provides an overview of the steps and names in the as-is process flow that are
expected to experience a process impact from one or multiple business requirements.
The table is divided in three sections: pre-processing, run models, and post-processing, as shown in
the first column. Within a certain section it is possible that multiple process steps are impacted by the
same business requirements.
Section Process Process step name Model ID Business Requirements
step
Pre- 1 Selection relevant SAD items for AOV 2.01-13

processing
Pre- 8 Prepare input files for Risk Agility runs with 4301 2.01-24
processing macro
2.01-27
Run 10 Run Risk Agility (Azure) –AOV 2050 1.01-4
models
1.02-7
1.04-5
1.04-6
2.01-6
38
step
2.01-8
2.01-9
2.01-24
2.01-27
Post- 11 Gather output 4300 2.01-8

processing
2.01-27
Table 11 Process steps in scope
In the remainder of this paragraph the impacted process steps for each of the 3 sections above are
discussed. A brief description of the process step is provided, followed by a reference to applicable
table in the appendix, which provides more details on the impact of the business requirements.
The specific impacts from the business requirements on the described process step are located in:
- Appendix 8.1, for pre-processing steps;
- Appendix 8.2, for run-models steps;
- Appendix 8.3, for post-processing steps.
Pre-processing
Process step 1: Selection relevant SAD items for AOV
The input files originate from several databases. Extracts are provided by BIS, but additional
transformations on the data is necessary to prepare the data for the Risk Agility model.
The following IFRS 17 topic is expected to have an impact on this process step:
- Data
Additional data should be made available, such as data to determine the categorization of
contracts in groups. This data should be captured in the datalake or in another module. Based on
the outcomes the process will be adjusted accordingly and controls will be revised or newly
designed.
- Non market variables
39
In the current process, non market variables are not taken into account. A process should be
created to generate non market variables in order to measure the expected value of the future
cash flows accounted for under the General Model. Although the generation of non market
variables is not part of this DSD, it does have an impact the DSD Actuarial Models as the models
should have the capability to use these variables. The non market variables will be retrieved
from the SAD.
Control objective:
Controls should be in place which ensure that the models pick up the non market variables that
are needed for an estimation of the expected cash flows (completeness/timeliness). These non
market variables should be kept up to date so that the models always pick up the latest version
of these variables (accuracy).
Process step 8: Prepare input files for Risk Agility runs with Macro
Both the input files and assumption files for the Risk Agility runs are prepared with an Excel macro.
The following IFRS 17 topics are expected to have an impact on this process step:
- Acquisition costs
Models should have the capability to recognize the acquisition costs over the coverage period as
required under IFRS 17. The current process should be updated to be able to determine
acquisition costs on the required level of granularity under IFRS 17.
Control objective:
Controls should be in place which ensure that the right level of acquisition costs is picked up in
the calculations and is spread over the right coverage period (completeness and accuracy).
- Feed from the Data Lake

In the to-be IT architecture all source systems feed the Data Lake before entering the model
environment or any other system. Any direct link between the model environment and the
source systems will hence be eliminated.
For the specific impact from the business requirements on each described process step above please
refer to appendix 8.1.
Run models
Process step 10 Run Risk Agility (Azure) – AOV
40
The FIM Schade actuary uses both the run calendar and the input and assumption files to run the Risk
Agility scenarios on the Azure server12.
- Cash flows
IFRS 17 requires cash flow projections for current and future cash flows on cohort level. This
higher level of granularity (compared to the as-is situation) is currently not captured by both the
models and Peoplesoft. The cash flows from the models will be the input for the CSM and Risk
Adjustment tools. When designing the to-be process this should be taken into account.
Control objective:
Controls should be in place which ensurethat the right cash flows are picked up completely on a
per granular level basis and that all levels are calculated (completeness/accuracy).
NB: Using the current calculation capacity this extends the run times of the models.
- Discount curves
The models are currently not able to calculate fulfilment cash flows using multiple discount rates.
Following the IFRS 17 requirements the fulfilment cash flows should be calculated at inception
and during the subsequent reporting periods. Hence the process should be adjusted in a way it is
possible to both use and store the locked-in and current discount rates. The design of the to-be
process facilitating this is still dependent on the functionalities of the CSM and Risk adjustment
tools.
Control objective:
Controls should be in place which ensure that the right discount cure is picked up by the model,
both differentiating between different kinds of locked-in rates and inception vs subsequent
measurement discount rates. (accuracy)
- Acquisition cost
In the current state (acquisition) costs are calculated on a higher level than IFRS 17 groups of
contracts. Models should be able allocate acquisition cost appropriately in accordance with the
IFRS 17 requirements.
Control:
Controls should be in place which ensure that the right level of acquisition costs is picked up in
the calculations and is spread over the right coverage period (completeness and accuracy).
12
This text is copied from the current process description of FN 76 AOV.
41
Post processing
Process step 11: Gather output
The FIM Schade employee collects the output from the MoSes run for the various scenarios. 13
The following IFRS 17 topics are expected to have an impact on the run models section:
- Cash flows
IFRS 17 requires cash flow projections for current and future cash flows on product level. This
models and PeopleSoft. The cash flows from the models will be the input for the CSM and Risk
Control objective:
There should be a control in place that makes sure that the right cash flows are picked up on a
per granular level basis and that all levels are calculated.
4.1.1.2 To-be process flow
Based on the aforementioned impact of the business requirements on the process a high level to-be
process flow was derived including control objectives. As previously indicated, the control objectives
are split in three categories, namely: correctness, completeness and timeliness. In the table below all
control objectives (across the three categories) are listed.
Appendix D - Control objective
For the designed processes in the IFRS 17 solution design it is expected that the following
control objectives are met and controls will be automated to the highest level possible in the to-

be processes:
# Correctness (inc. granularity)
1 Input data for the financial reporting and models/systems/next source in the process needs to be
13
This text is copied from the process description of FN 76 AOV.
42
100% correct and equal to the output data from the previous source
2 Input data complies with INSURANCE COMPANY A policies and data requirements
Data sourced from EUCs must be subject to the controls as outlined in the EUC standard by
3
INSURANCE COMPANY A
4 Segregation of duties between preparer and reviewer
Output from manual steps must be checked by a second employee before sending it to the next
5
step in the process
The system is configured to total/calculate information correctly. If there is a need for manual
6
calculation, a second employee checks before sending it to the next step in the process.

# Completeness
In order to produce and transfer complete data between the systems, IT General Controls are
7
performed periodically and interface / handshake controls should be in place.
A log is maintained for interface processing and logs errors and exceptions. Exception/error
8 reports are produced, reviewed, and resolved by management on a regular basis, including
correction and resubmission, as appropriate.

# Timeliness
9 Data needs to be delivered within the timing agreement of the SLA with the other department
10 Models need to run within the pre-defined timelines
Processes need to be performed within the pre-defined timelines including model runs, system &
11
interface throughput, manual throughput
Outcomes of models/calculations are being reported according to the timelines of the reporting
12
policies
13 Monthly bookings need to booked in the general ledger on the first day of the following month
14 Daily bookings need to be processed in the source systems at the latest, at the following day
Table 12: Control objectives
43
EMBEDDED FILE DELETED
4.1.1.3 List of impediments
These impediments were not taken into account in the DSD, whenever the impediment is cleared, the
process impact will be included in a new version.
List of overall impediments applicable to Description of impediment

the current DSD
Sub ledger functionality The sub ledger (the Accounting Rule Engine)
functionality will deliver a list of output
requirements to optimize processing of results
from the actuarial model process. This list of
output requirements needs to be embedded in
the current output formats.
Roll forward (movement analysis) The movement analysis will deliver a list of
output requirements to optimize processing of
results from the actuarial model process in the
movement analysis. This list of output
requirements needs to be embedded in the
current output formats.
CSM The CSM functionality will deliver a list of

output requirements to optimize processing of
results from the actuarial model process. This
list of output requirements needs to be
embedded in the current output formats. In
some cases the model output will need to be
restructured in such a way it meets the output
44
List of overall impediments applicable to Description of impediment
the current DSD
requirements.
Risk Adjustment The Risk Adjustment functionality will deliver a

list of output requirements to optimize
processing of results from the actuarial model
process. This list of output requirements needs
to be embedded in the current output formats.
Reinsurance Due to IFRS 17 requirements, the valuation of

reinsurance models will change from the
current valuation process. For valuation of
reinsurance contracts, cash flow data is
needed from the underlying contracts. This
cash flow data is an output for the actuarial
model process. A separate valuation run is
needed to assess the reinsurance contract.
Reporting of discounting effect (P&L vs Insurance contracts that have the VFA
OCI) classification will have a disaggregation option
to split the interest rate effect between OCI
and PL. When this option is chosen the
actuarial model process should split the cash
flow effects between the locked-in and current
rates. This is an output requirement that can
have an effect on the models and the post
processing.
Acquisition costs When the allocation costs need to be

disaggregated over time, the models need to
be able to take this into account. This will
deliver an input requirement for the models.
Model solutions Since the process of choosing the model

solutions is not finalized, the impact on the
process and controls is unclear.
Business requirements level II Since the business requirements level II are

still in development, the impact on the
processes and controls is unclear (and will
become clear when the business requirements
level II are developed).
Table 13 List of impediments
4.1.1.4 Reference documentation

# Document Link to document Download
date
1 Process flow FN 76 Opleveren cijfers MVN SII LINK DELETED 8-10-2018
45
date
incl. LAT Schade – AOV
2 Process description FN 76 Opleveren cijfers 8-10-2018

MVN SII incl. LAT Schade – AOV
Table 14 Reference Documentation AOV
46
4.1.2 WIA
Summary
At this stage the exact impact of IFRS 17 are still dependent on ongoing discussions. Those discussions
are mainly related to the following topics:
- Applying the Premium Allocation Approach (PAA):

o At this stage, the working assumption is that the PAA will be applied for WIA products.
The contract boundary for WIA products is 1 year, hence applying the PAA approach is
allowed under IFRS 17. PAA concerns the valuation of the Liability for Remaining
Coverage (LFRC) component of IFRS 17, which is similar to the Unearned Premium
Approach which INSURANCE COMPANY A already applies for IFRS 4 calculations.
However, the General Model still has to be applied for onerous contracts and for the
Liability for Incurred Claims.
- Treatment of onerous contracts

o A new feature under IFRS 17 is the separation between ‘non-onerous’ and ‘onerous’.
Under the PAA approach a group of contracts are considered to be non-onerous at initial
recognition, unless ‘facts and circumstances’ indicate this group will become onerous.
This is different compared to the General Model approach, where a negative CSM
indicates a group of contract is onerous. How this will impact the actuarial models
process is still to be determined.
- Classification of IFRS 17 group of contracts / cohorts

o Contracts need to be categorized into IFRS 17 group of contracts. How this will be done
and on what level of granularity is yet to be decided.
- Treatment of acquisition costs

o The current process should be updated to be able to determine acquisition costs at a
IFRS 17 groups of contracts level, which requires more details in the (cost) assumption
setting.
o It needs to be determined if acquisition cash flows are part of the Liability for Remaining
Coverage or are recognized as an expense. Based on that, the process needs to be
updated.
- Treatment of contract boundaries

o Processes should be in place that are able to track the contract boundaries over time and
reassess the contract boundaries of the products at each reporting date. Evidently, the
cash flow models should be able to perform calculations based on IFRS 17 contract
boundaries.
- Multiple locked-in discount curves

o Under PAA, the General Model is applied for onerous contract and for incurred claims.
Therefore, the Multiple locked in discount curves are in scope of this DSD. The General
47
Model uses multiple locked-in discount curves for CSM calculations. Discussions are
pending on where these calculations will take place and how and where these curves will
be retrieved and stored.
- Functionalities of the CSM tool

o The design of the process is dependent on the functionalities of the CSM tool, which will
be applied for the calculation of the loss component. The following items are still open:
 The level of granularity that is required by the CSM tool and the format of this
input data.
 The signaling and timing of the delivery of the input data.
o Based on these items, additional controls need to be defined.
- Data Lake
o In the to-be target IT Architecture all data flows via the Data Lake (as outlined in IFRS 17
Solution Architecture, Section 8.1). Any direct link between (source) systems and the
model environment will be replaced by a link with the Data Lake.
The impact of these topics is elaborated upon in more details in the following chapters.
Based on the outcome of those discussions the processes should be redesigned, this will be done in next
versions of the DSD, depending on when the discussions are finalized.
Approach
A starting point for describing the WIA process is the INSURANCE COMPANY A FN 76 process template
(as presented below) and corresponding process description (FN 76 Opleveren cijfers MVN SII incl. LAT
Schade – WIA).
In order to indicate the process impact of the IFRS 17 business requirements which are relevant for this
process, the business requirements are mapped to the INSURANCE COMPANY A current process
template. The as-is process flow is divided into three parts: pre-processing, run models and post-
processing.
Subsequently, a high level to-be process flow is prepared which includes control objectives split in three
categories: correctness, completeness and timeliness.
Please refer to the embedded PDF files:
48
Description PDF File
INSURANCE COMPANY A process flow FN 76 EMBEDDED FILES DELETED

Opleveren cijfers MVN SII incl. LAT Schade –
WIA
INSURANCE COMPANY A As is process flow

including Business requirements
To be process flow including control objectives
Table 15 process templates WIA
4.1.2.1 Business requirement mapping

The design scoping for this DSD has a predefined set of business requirements to be taken in scope as For this DSD a predefined
set of level I business requirements related to Actuarial Models were taken into account.
The business requirements were mapped on the as-is processes to determine the impact of IFRS 17.
The business requirements were classified into the following two categories:
1. Business requirements with an undefined process impact, since the required information is not yet available (e.g.
because of pending discussions);
2. Business requirements which will most likely have an impact on the process (refer to Mapped business requirements).
Business requirements with undefined process impact

The business requirements listed in the table below might have an impact on the Actuarial Model process, but since sufficient
information is lacking the impact has yet to be determined.
Business requirements which do not have an impact and are out of scope for this topic are not included in this DSD.
1.01-7 Data should be (made) available to assess This is related to data requirements
whether a change in contract's term results in: that are in scope of the DSD: Base
1) A contract becoming out of scope of IFRS 17,
data management and insurance
operations. In this DSD the impact
2) Change of cluster, on the as-is process needs to be
3) Change of risk insured. determined before the impact on
the processes within the actuarial
Data should be (made) available to create models DSD can be determined.
appropriate de-recognition and re-recognition
entries, for example updates of policy numbers.
There will be a modification

process that links into the actuarial
model process, this modification
process is in scope of the Insurance
Operations DSD.
49
1.01-8 Models should have the functionality/capability to The process impact of this required
treat changes in cash flows caused by the capability still needs to be
modification (not meeting any of the conditions in determined.
paragraph 72) of a contract as changes in
estimates of fulfilment cash flows, requiring
models to use updated cash flow projections at
every reporting period.
2.01-7 Under PAA, the General Model is applicable for More information is required in
onerous contracts and for incurred claims. Hence, order to determine the possible
a process should be in place to measure the process impact.
expected value of the future cash flows accounted
for under the General Model at the required level
of unit of account.
3.02-12 Under PAA, the General Model is applicable for To be determined in the DSD
onerous contracts and for incurred claims. Hence, related to reinsurance.
models should have the capability/functionality to
perform the calculation of reinsurance receivables
based on the modified General Model. This entails
measuring the receivables.
Table 16: Business requirements with undefined process impact
Mapped business requirements
The business requirements with an expected impact are mapped on the as-is process flow.
The table below provides an overview of the steps and names in the as-is process flow that are
expected to experience a process impact from one or multiple business requirements. The table is
divided in three sections: pre-processing, run models, and post-processing, as shown in the first
column. Within a certain section it is possible that multiple process steps are impacted by the same
business requirements.
step
Pre- 1 Sub process WIA-Input (Data) 1.02-3

processing
2.01-13
Pre- 4 Make basis set assumptions SII/MVIS/IFRS 4299 2.01-13
processing LAT
2.01-24
2.01-27
Pre- 19 Consolidate WIA 3.04-6

processing
3.04-11
50
step
Run 6 Run RAFM WIA 2077 1.04-5

models
1.04-6
2.01-6
2.01-8
2.01-9
2.01-24
2.01-25
2.01-27
2.02-4
3.04-14
3.04-15
Post- 7 Process RAFM output to ResQ input 4299 2.01-8

processing
2.01-27
Table 17 Process steps in scope
In the remainder of this paragraph the impacted process steps for each of the 3 sections above are
discussed. A brief description of the process step is provided, followed by a reference to applicable
table in the appendix, which provides more details on the impact of the business requirements.
The specific impacts from the business requirements on the described process step are located in:
- Appendix 8.4, for pre-processing steps;
- Appendix 8.5, for run-models steps;
- Appendix 8.6, for post-processing steps.
Pre-processing
Process step 1: Sub process WIA-input (data)
The WIA input files originate from several databases. Extracts are provided by BIS, but additional
transformations on the data is necessary to prepare the data for the RAFM model.
 Data
Additional data should be made available, such as data to determine the categorization of
contracts in groups. This data should be captured in the datalake or in another module. Based
51
on the outcomes the process will be adjusted accordingly and controls will be revised or newly
designed.
 Non market variables

In the current process, non market variables are not taken into account. A process should be
created to generate non market variables in order to measure the expected value of the future
cash flows accounted for under the General Model, which will be applied for onerous contracts
and for claims data. Although the generation of non market variables is not part of this DSD, it
does have an impact the DSD Actuarial Models as the models should have the capability to use
these variables. The non market variables will be retrieved from the SAD.
Control objective:
Controls should be in place which ensure that the models pick up the non market variables that are
needed for an estimation of the expected cash flows (completeness/timeliness). These non market
variables should be kept up to date so that the models always pick up the latest version of these
variables (accuracy).
Process step 4: Make basis set assumptions SII/MVIS/IFRS LAT
The assumptions from the SAD are used to provide the calculation framework for SII/MVIS/IFRS LAT
- Non-market variables
Refer to the impact as described for process step 1.
- Acquisition costs
Models should have the capability to recognize the acquisition costs over the coverage
period as required under IFRS 17. The current process should be updated to be able to
determine acquisition costs on the required level of granularity under IFRS 17.
Control objective:
Controls should be in place which ensure that the right level of acquisition costs is picked up in the
calculations and is spread over the right coverage period (completeness and accuracy).
Process step 19: Consolidate WIA
Both the figures for IFRS and SII are consolidated, after calculating the BEL, SCR-WIA and MVM for SII
and the BEL and MVM – LAT for IFRS.
52
Following our working assumptions, the PAA will be applied for WIA. This approach is a simplification of
the Building Block Approach, where fulfilment cash flows do not have to be calculated for the liability
for remaining coverage. The determination of the liability for remaining coverage under the PAA is very
similar to the current Unearned Premium Reserve method, which is determined in the General Ledger
(PeopleSoft).
However, the General Model still has to be applied for onerous contracts. A split-off therefore needs to
be put into place before the data is booked into the General Ledger.
The following IFRS 17 topic is expected to have an impact on this process step:
 Liability for remaining coverage for onerous contracts

Following the PAA, a loss component has to be determined in case an IFRS 17 group of
contract is considered to be onerous. The loss component should be equal to the amount
the fulfilment cash flow under the General Model exceeds the carrying amount of the
liability of remaining coverage under the PAA. For the calculation of the fulfilment cash
flows the General Model will be used. The process needs to be adjusted to facilitate this.
Control objective:
Controls should be in place which ensure that the loss component is calculated with the correct
variables at the right level of granularity (accuracy) and is booked timely (timeliness). Any
adjustments made to the loss components need to be monitored and checked. (accuracy)
 Discount curves loss component

The loss component should be discounted against current cash flows. This will be covered
in the discount rate paper that is still pending for INSURANCE COMPANY A. The model
should have the functionality to pick up the right discount curve for the loss component.
This is similar to the functionality of discounting other components in the actuarial model
process.
Control objective:
Controls should be in place which ensure that the right discount cure is picked up by the model, both
differentiating between different kinds of locked in rates and inception vs subsequent measurement
discount rates. (accuracy)
Run models
Process step 6: Run RAFM WIA
FIM Schade runs the RAFM models for WIA. The MoSes model for WIA is used to calculate MVN,
MCVNB and LAT.
Although the Premium Allocation Appraoch will be applied for WIA, the General Model is still applicable
for the LIC and for onerous contracts, hence all business requirements related to the GM are also in
scope for WIA.
 Cash flows
IFRS 17 requires cash flow projections for current and future cash flows on product
53
level. This higher level of granularity (compared to the as-is situation) is currently not
captured by both the models and Peoplesoft.
The cash flows from the models will be the input for the CSM and Risk Adjustment tools. When
designing the to-be process this should be taken into account.
Control objective:
Controls should be in place which ensure that the right cash flows are picked up on a per granular level
basis and that all levels are calculated.
 Discount curves
The models are currently not able to calculate fulfilment cash flows using multiple discount
rates. Following the IFRS 17 requirements the fulfilment cash flows should be calculated at
inception and during the subsequent reporting periods. Hence the process should be
adjusted in a way it is possible to both use and store the locked-in and current discount
rates. The design of the to-be process facilitating this is still dependent on the
functionalities of the CSM and Risk adjustment tools.
Control objective:
Controls should be in place which ensure that the right discount cure is picked up by the model, both
differentiating between different kinds of locked in rates and inception vs subsequent measurement
discount rates. (accuracy)
 Acquisition cost
In the current state (acquisition) costs are calculated on a higher level than IFRS 17 groups
of contracts. Models should be able allocate acquisition cost appropriately in accordance
with the IFRS 17 requirements.
Control objective:
Controls should be in place which ensure that the right level of acquisition costs is picked up in the
calculations and is spread over the right coverage period (completeness and accuracy).
Post-Processing
Process step 7: Process RAFM output to ResQ input
The output per product type from WIA is combined into a consolidated file for WIA by an employee
from FIM Schade.
The following IFRS 17 topics are expected to have an impact on the run models section:
- Cash flows
IFRS 17 requires cash flow projections for current and future cash flows on product level. This
54
models and PeopleSoft. The cash flows from the models will be the input for the CSM and Risk
Control objective:
There should be a control in place that makes sure that the right cash flows are picked up on a per
granular level basis and that all levels are calculated.
4.1.2.2 To-be process flow (incl. control objectives)
Based on the aforementioned impact of the business requirements on the process a high level to-be
process flow was derived including control objectives. As previously indicated, the control objectives
are split in three categories, namely: correctness, completeness and timeliness. In Table 12: Control
objectives all 15 control objectives (across the three categories) are listed.
EMBEDDED FILES DELETED
55
LOGO DELETED
4.1.2.3 List of impediments
These impediments were not taken into account in the DSD, whenever the impediment is cleared,
the process impact will be included in the new version of the DSD.
List of overall impediments Description of impediment

applicable to the current DSD
Sub ledger functionality The sub ledger functionality will deliver a list of output
requirements to optimize processing of results from the
actuarial model process. This list of output requirements
needs to be embedded in the current output formats.
Roll forward (movement The movement analysis will deliver a list of output
analysis) requirements to optimize processing of results from the
actuarial model process in the movement analysis. This list
of output requirements needs to be embedded in the
current output formats.
CSM The CSM functionality will deliver a list of output

requirements to optimize processing of results from the
actuarial model process. This list of output requirements
needs to be embedded in the current output formats.
Risk Adjustment The Risk Adjustment functionality will deliver a list of

output requirements to optimize processing of results from
the actuarial model process. This list of output
requirements needs to be embedded in the current output
formats.
Reinsurance Due to IFRS 17 requirements, the valuation of reinsurance

models will change from the current valuation process. For
valuation of reinsurance contracts, cash flow data is
needed from the underlying contracts. This cash flow data
is an output for the actuarial model process. A separate
valuation run is needed to assess the reinsurance contract.
Reporting of discounting effect Insurance contracts that have the VFA classification will
(P&L vs OCI) have a disaggregation option to split the interest rate
effect between OCI and PL. When this option is chosen the
actuarial model process should split the cash flow effects
between the locked-in and current rates. This is an output
requirement that can have an effect on the models and the
post processing.
Acquisition costs When the allocation costs need to be disaggregated over

time, the models need to be able to take this into account.
This will deliver an input requirement for the models.
Model solutions Since the process of choosing the model solutions is not
finalized, the impact on the process and controls is
unclear.
483198496.docx, July 2, 2019 page 56/115

LOGO DELETED
List of overall impediments Description of impediment

applicable to the current DSD
Business requirements level II Since the business requirements level II are still in
development, the impact on the processes and controls is
unclear (and will become clear when the business
requirements level II are developed).
Table 18: List of impediments
4.1.2.4 Reference documentation

date
1 Process flow FN 76 Opleveren cijfers MVN SII incl. LINK DELETED 8-10-2018
LAT Schade - WIA
2 Process description FN 76 Opleveren cijfers MVN SII 8-10-2018

incl. LAT Schade - WIA
Table 19 Reference documentation WIA
483198496.docx, July 2, 2019 page 57/115

LOGO DELETED
4.2 Functional design / architecture diagram (optional)
The current as-is actuarial system that needs to be changed in line with the IFRS 17 Solution
outline is defined in the IFRS 17 Solution Outline, Section 7.3.
The data sources considered in this flow represent only those data interfaces that directly feed the
models in pre-processing or other models with data required for the model runs in scope of this DSD.
The Data Source Layer consists of the primary data sources, while the Extract, Transform, Load (ETL)
layer is the secondary data source. The model environment is made up of the pre-processing models,
valuation models, other post-processing models and the reporting models.
Please find an overview of the current state systems design for Disability in the IFRS 17 Solution
Outline, section 7.4.1.
In the to-be state, that is based on the current level-2 business requirements, data needs to be
enhanced with new IFRS 17 attributes that will be fed into the models. This enhancement could be
based on group of contracts (portfolio), cohort or policy level. It is assumed that the current data
types will be retained, but enhanced with the additional IFRS 17 data requirements.
In the future state all augmented data that will be fed into the models will pass through the data
lake. Any new (or future) data source (could be data from external sources e.g. new discount rates, fx
rates) will also be linked to the data augmentation and will be available in the data lake. The new
models or model changes will specify what exact input data is required for its model runs.
In the future state design, the Finance Publication Layer (FPL) within the data lake will provide data
publication sets that are accessible by the models. This process will be managed by an end-to-end
run orchestrator functionality.
To-be systems landscape:
Please find in section Error: Reference source not found an overview of the future state system
design. For information on the to-be functional data design, please refer to section Error: Reference
source not found. Please be aware that discussions are ongoing within the Base Data Management
DSD regarding what specific datasets will be relevant to collect and whether data will be delivered on
a group of contract level, by cohorts, by products and policy. The as-is state is also being analysed to
determine where these dataset will come from at the source level/layer.
4.3 System design
483198496.docx, July 2, 2019 page 58/115

LOGO DELETED
To-be systems landscape:
In the to-be state, all data is stored in the data lake. The To-Be data flows are oultined in IFRS 17
Solution Outline, Section 9.1.1.
Please note that any future state represented is still under review and only shows possible solutions
that could change depending on:
1. vendor selection for the CSM that will determine the real data augmentation layer
2. pending decisions regarding the SAD with Finance Transformation
3. level 2 business requirements regarding system and data specifications
4. project management timelines with respect to dependency timelines between the DSD and
functional specifications needed for data and systems design
Data augmentation
A data augmentation functionality needs to be incorporated that is able to augment current source
systems data with the necessary IFRS 17 components. This functionality needs to make all required
data available under IFRS 17 in order to perform the classification and grouping of an insurance
contract at inception. This functionality is in detail descriped in the Reference Data Management and
Liability Data Management DSD’s, please refer to these documents if more information is needed.
4.3.1 System functionalities
The as-is system functionalities mostly consist of data files in Excel and/or flat file formats that are
exported from SAS (LAN) and fed into the models environment. In the to-be state, new system
functionalities are described in the Solution Outline (see section 7.2) and additional insight is
provided in the Systems and Data design context (see 9.1.1).
The outcome of current analysis of data to be collected and processed within the Insurance
Operations and Base Data Management DSD’s will provide further insight to determine how much
system functionalitites will be adapted to fit the IFRS 17 data requirements for the models.
System Description GAP IFRS 17 Solution

SAS LAN The function of the SAS This system combines the This data must be
LAN is to transform the data from multiple data sourced via the
(AOV and WIA)
format of the data and sources (policy and claims data lake so the
combine data and provide data) to create one single data can be
this data to the other dataset which will be used augmented with
systems and models. in the Risk Agility model. the IFRS 17
Currently the policy data required data.
483198496.docx, July 2, 2019 page 59/115

LOGO DELETED
System Description GAP IFRS 17 Solution

and claims data do not This functionality
include the additional is in detail
information required under descriped in the
IFRS 17. Reference Data
Management and
Liability Data
Required Situation: Management
Additional data such as: DSD’s, please
refer to these
- to which portfolio a documents if
policy and claim more information
belongs to is needed.
- to which cohort a
policy and claim
belongs to
- onerous/not
onerous label for
policies
- contract boundary
- Insurance
acquisition cash
flows per cohort
Will have to be included in

the dataset created by the
system.
Discount rate Discount rates need to be Discount rates are The Finance
storage system stored at inception and currently stored within the Transformation
every subsequent SAD, but current setup is
measurement. not in line with IFRS 17
team will setup
requirements. the basic
infrastructure
(including
interfacing), this
will be addressed
in the DSD
Assumptions.
Table 20
4.3.2 User Interface (UI)
There are no known user interfaces yet at this stage, until after decisions about the data
augmentation system has been determined. This impact will be included in section 4.3.
4.3.3 Services
483198496.docx, July 2, 2019 page 60/115

LOGO DELETED
This is not yet applicable at this stage. The to-be architecture for dependend tools CSM, Risk
Adjustment and Data Augmentation is depicted in IFRS 17 Solution Outline, Section 7.2
4.3.4 Authorization matrix
To be further elaborated in version 2 of this DSD and dependent on the outcome of the
dependencies (see 4.4.2).
This paragraph will describe:
- User groups, their roles and rights and corresponding actions

- Security considerations
4.4 Model design
In this section first a summary of the identified gaps and solutions regarding the Model Design of the
actuarial models for the Non-Life Disability products are described. The Non-Life Disability products
can be categorized by AOV and WIA. A complete overview of the Non-Life Disability products can be
found in Appendix 8.7.
The following deliverables are included and described in this section:
- As-is model landscape (2 = 1 for AOV, 1 for WIA)

- Suggested Draft IFRS 1714 model landscapes (2 = 1 for AOV, 1 for WIA)
- Template with gaps and solutions (1, covering AOV and WIA)
The set of business requirements that have been used to identify the detailed model gaps and
solutions are provided in the template for gaps and solution and embedded in appendix 8.1 to 8.6.
The working assumption is that AOV is considered under the General Model Approach (GM) and WIA
is considered under the Product Allocation Approach (PAA).
The main difference between the two approaches is the modelling for the liability for remaining
coverage for non-onereous contracts. The PAA is expected to require only minor adjustments to the
current IFRS 4 approach for the liability for remaining coverage. However, if contracts become
onereous, a loss component has to be determined. Determining the loss component requires a
similar calculation as via the General Model. As a result, in the model landscape for WIA both the
PAA and the GM needs to be in place.
14
The suggested model solutions are to become IFRS 17 compliant. Suggested model solutions for IFRS 17 could be future state ready. To
determine that, it needs to be clear what the future state is for the model landscape of Disability covering all reporting frameworks, in
order to determine if the IFRS 17 suggested model solution fit that future state or not.
483198496.docx, July 2, 2019 page 61/115

LOGO DELETED
4.4.1 Summary of gaps and suggested solutions (to-be model landscape)
Below a summary is provided about the IFRS 17 related gaps and suggested solutions:
1. Almost all Non-Life models need to be changed to meet the IFRS 17 requirement regarding
grouping of contracts. The output from all current pre-processing, valuation, Excel tools and post-
processing modules are not at the required IFRS 17 group of contract level.
2. For each model, detailed solutions are included in the ‘gap and solution template’, which take
into account both the ‘technical’ model requirements and process requirements. The table below
provides a summary.
Model Summary Suggested Solution
AOV & WIA - SAS (ID 3054) Replace the model with fit for purpose data delivery. Ideally this
model would become obsolete by an automated process of data
delivery for IFRS 17 calculations from a data lake with a financial
publication layer.
AOV – Generate folder and Depending on the to-be architecture for the data delivery to the
data (ID 4301) actuarial models, as outlined in IFRS 17 Solution Outline, Section 7.3,
adjust the model to:
For AOV, the model must be adjusted to load multiple discount

curves and keep track of (through the use of a matrix) which discount
curve is used per group of insurance contract. Furthermore, the
model must be adjusted to deliver the additional run plans required
by IFRS17 to Risk Agility model.
(In the Finance Transformation team there is already a plan to make

the whole data inflow process automated.)
WIA – Schade WIA (ID 3055) This model will most likely remain unchanged under IFRS 17 and the
functionality of this model must be built into the financial publication
layer of the data lake.
AOV - Premieterug xl-model Rebuild in R. Make the cash flow output available at the group of
(ID 4323) contracts level. This can be done by providing each record fed in (as
input) to the model to contain an identifier of the group of contracts
that record belongs to.
It would be most efficient and save implementation time if all

discounting took place in a new special built discounting model
which can be used for all the discounting of all non-life product
group. Therefore, the model must produce undiscounted cash flows
on group of contract level.
AOV - Excels for Collective (ID Rebuild in R. Adjusted to provide IBNR cash flow reserves on
483198496.docx, July 2, 2019 page 62/115

LOGO DELETED

4302) underwriting year. This must be done by converting the current
claims triangles based on accident year to underwriting year. The
model can the produce cash flows of the IBNR reserves based on the
cash flow pattern from the AOV individual model.
AOV - Risk Agility Model (ID Make all required cash flows output available at the group of
2050) contracts level (within the contract boundary). This can be done by
providing each record fed into (as input) the model to contain:
- an identifier of the group of contracts that record belongs to.
- the contract boundary for that record (this will require the contract
variable in the model to be a dynamic variable that depends upon
this input).
Furthermore, the model must be adjusted to produce acquisition

expense cash flows. This can be done by loading in a total acquisition
expense per cohort and an allocation rule which allocates the total
expense to different years in the projections.
It would be most efficient and save implementation time if all

discounting took place in a new special built discounting model
which can be used for all the discounting of all non-life product
group. Therefore, the model must produce undiscounted cash flows
on group of contract level.
WIA – Risk Agility Model (ID Adjust the model to aggregate the individual participant cash flow
2077) projections to cohorts based on the label assigned to each policy in
the input data. This adjustment implies a change in the aggregation
cycle of the Risk Agility model.
Furthermore, the model must be adjusted to produce acquisition

expense cash flows. This can be done by loading in a total acquisition
expense per cohort and an allocation rule which allocates the total
expense to different years in the projections.
Adjust the input loading process of the model to include the

additional IFRS 17 data. This data is:
- Onerous/not onerous label for policies,
- Contract boundary;
- Cohort/Portfolio label.
WIA – ResQ (ID 4296) The short term solution:
483198496.docx, July 2, 2019 page 63/115

LOGO DELETED

Keep the current method of calculating the IBNR reserve and make
use the cash flow option in ResQ to create the required cash flows
per accident year.
The long term solution (expected not before the IFRS 17

implementation date due to high expected efforts and external
stakeholder dependencies):
The IBNR reserve is determined in the Risk Agility model utilizing an

individual claims reserving methodology15.
WIA – Stoplichtenmodel (ID In line with the IFRS 17 Solution Outline Section 7.3 build in model in
4297) R (convert current Excel) to perform the adjustment of the initial
expected loss on IFRS 17 portfolio level.
WIA – Scaling factors (ID 4305) Adjust the model to produce cash flows here on accident year basis
and improve the data quality issue in the source systems to model all
policies in the ResQ model.
For ease of calculation a fixed 2% discount rate is assumed in the

WIA ResQ model and this model will then convert the liability
calculations from a 2% interest rate to the current market discount
rate.
AOV & WIA – Collection Sheets In line with the IFRS 17 Solution Outline Section 7.3 build a model in
(ID 3045 & 3053) R (converting current Excel model) to include the cash flow overview
per IFRS 17 cohort.
Additionally the new R model must be adjusted to include the cash

flow overview of acquisition expenses per cohort.
In line with the IFRS 17 Solution Outline Section 7.3 build a model in
R (converting current Excel collection sheet ID 3045) to incorporate
the additional cash flows produced by the model for PVI (new built
model to take away an outside adjustment).
(This model could also be used as the point where all discounting
takes place.)
Table 21 Summary of suggested detailed solutions for models
15
This development requires a change in reserving methodology which will also require an agreement from external parties (DNB)
483198496.docx, July 2, 2019 page 64/115

LOGO DELETED
- For each outside adjustment, detailed solutions are included in the ‘gaps and solutions template’,
taking into account both the ‘technical’ model requirements and process requirements. The table
below provides a summary
.Outside adjustments Summary Suggested Solution
AOV (PET AOV Col, Pools, Allocate the provision to the required cohort level.
Volmacht, Tuchtzaken)
AOV & WIA (IBNR, case A small part of the provision is scaled, mainly due to data quality
reserves, VPU) issues. This part should be allocated the provision to the required
cohort level.
WIA (PVI) Currently, a new model for the PVI products is being built. It is
assumed that this model will be ready before the implementation of
IFRS 17 in 2021.
Table 22 Summary of suggested detailed solutions for outside adjustments
4.4.2 Dependencies and other placeholders for the current suggested solutions
As explained earlier in sections 2 and 3, for this DSD version some IFRS 17 methodologies and
business requirements have not yet been finalized. These unfinished parts provide uncertainties, or
placeholders, as these can impact the required outputs and/or inputs to the actuarial models and
calculations, or the functional design of models. When these placeholders are clarified, this could
impact the identified gaps and solutions, or provide additional gaps.
In addition to dependencies on IFRS 17 methodologies and business requirements, the model gaps
and solutions can also be impacted by future reporting timeline requirements, to achieve IFRS
auditability, for this please see section 3.3. Potentially related, the critical path regarding runs times
could depend on the total number of (IFRS 17) groups of contracts a model has to process. This is
currently not yet clear, and depends on the outcome of actually mapping all insurance contracts to
IFRS 17 groups of contracts (e.g. cohorts).
For example, a model solution can depend on the amount of run-time that is available in the IFRS 17
reporting calendar to deliver IFRS 17 output in an auditable fashion. In the high level solution design
it was already concluded that the run-times from (the combination of) models need to improve. At
the time of writing this DSD version, the future IFRS 17 reporting timelines are under discussion; it
still needs to be determined what the available run-time will be for the models in scope of this DSD.
In terms of methodologies, the following topics need further investigation:
- Movement analysis (roll-forward / attribution analysis);

- Cash flows (incl. level and scope of expense assumptions, identification of any non-distinct
investment components);
- Risk Adjustment (also under the PAA for the liability of incurred claims).
483198496.docx, July 2, 2019 page 65/115

LOGO DELETED
In terms of DSDs, the most relevant DSDs that are not yet delivered but are expected to impact the
required output from the models in scope of this DSD are:
- DSDs for Accounting (CSM, sub-ledger, general ledger);

- DSDs for Actuarial models and calculations (Reinsurance, Risk Adjustment).
In terms of DSDs, the most relevant DSDs that are not yet delivered but are expected to impact the
inputs to the models in scope of this DSD are:
- DSD for Assumptions (e.g. discount rates, (non-) financial risk assumptions);
- DSD for Base Data Management (Reference Data, Liability Management).
4.4.3 Template with gaps and solutions
In the template with gaps and solutions the models which are included in the as-is model landscape
are included.
The outside adjustments, which are added to the calculated provision in the post module after the
valuation models, are also included in the template with gaps and solutions.
For each model and outside adjustment, the following steps were performed and are included in the
‘gap and solution template’, to determine the suggested solutions:
- Based on the business requirements the IFRS 17 model gaps were determined.
- Based on these IFRS 17 gaps, possible solutions that could close gaps have been identified
(also using meetings with FIM Non-Life).
- Thereafter, one preferred suggested solution is determined per model, by combining the gap
solutions. These suggested solutions are based on:
1. The identified pros and cons of the solution options,
2. The possibility to use/adjust the existing model, or the requirement to develop a new
model, and
3. The dependencies within INSURANCE COMPANY A and/or other parties.
Pros D
Possible S
Business Gap 1 - N e
requirements X* Description
solutions for gap S
1- N p U
Cons S O
M e G
n I L
O G
d N U
D e
E
G T
E n S
L I
L Pros
c T
Possible i E O
Business Gap 1 - N E
requirements Y* Description
solutions for gap e N
1- N D
Cons s
*Note that multiple business requirements can be combined in order to identify one gap
483198496.docx, July 2, 2019 page 66/115

LOGO DELETED
Figure 3 The standard process applied to determine a single suggested model solution per model
The ‘gap and solution template’, which has been verified by INSURANCE COMPANY A content
contacts, is provided below16.
LINK DELETED
A full description of the information that is included in the ’gap and solution template’ is included in
the first sheet of the Excel Workbook.
4.4.4 Model landscapes
For both AOV and WIA, 2 models landscapes have been created:
1) As-is model landscape

2) Suggested Draft for IFRS 17 model landscape
In order to create the to-be model landscape, the suggested solutions per model with respect to the
IFRS 17 requirements were defined. These changes to the as-is landscape are based on the suggested
solutions as described above.
In addition a model landscape showing the changes to the as-is landscape is created, serving as the
link between the as-is model landscape and the Suggested Draft for IFRS 17 model landscape; this
helps to visualize all expected impacts in one overview.
The model landscapes provide an overview of the models, and the link between these models. Each
model landscape consist of five columns in which the following information is included:
Column type in model Information on this column type

landscape
Source data The source data consist of policy data (e.g. SIA/Aesis), financial
data (SAD), data that serve as input for the calculation of
expenses, input needed for the valuation in the non-linear
models (e.g. ESG-scenarios).
Preprocessing / data loading The preprocessing is the part of the process before the valuation
models. In the preprocessing assumptions- and parameter files
for the valuation models are generated from the source data.
16
This template is not updated for changes due to an upgrade of the DSD for alignment with the IFRS 17 solution outline and/or any other
changes since this template was verified by INSURANCE COMPANY A content contacts. The change initiatives tabulated in this DSD are
updated for an upgrade for the IFRS 17 solution outline.
483198496.docx, July 2, 2019 page 67/115

LOGO DELETED
Column type in model Information on this column type

landscape
Valuation Models The main calculations take place in the valuation models. ResQ is
used for triangle modulation for IBNR for the WIA product and
the Risk Agility Models are used to determine expected cash
flows for the disability products.
Excel tools and post modules The post processing is the part of the process after the valuation
models. In the post processing for the disability products relate to
scaling and preparing IFRS 4 LAT results.
Results The results column provides the models which are used to
provide the ‘final’ numbers for several frameworks (LAT/SII) given
the different inputs.
Table 23 Explanations to column types included in the model landscapes
In the next paragraphs the current Solvency II and IFRS 4 reserving process for the AOV and WIA
portfolio will be presented separately. This includes an overview of the models currently used. We
identified which models will be replaced, changed or omitted for IFRS 17 calculations.
4.4.4.1 AOV
The first as-is process relates to IFRS 4 and SII AOV reserving. The models in this process are
presented in the table below:
Model ID Model name As-is system Suggested solution for

IFRS 17
3051 Schade AOV SAS-LAN SAS As outlined in the IFRS
17 solution outline for
pre-andpost-
processing models
Model t.b.v. folders MS Excel As outlined in the IFRS
met inputdata en 17 solution outline for
4301
assumpties - AOV pre-andpost-
processing models
(expected Financial
Publication Layer of
the Data Lake).
4301 AOV Collectief MS Excel R

2050 AOV Risk Agility Risk Agility Risk Agility
3045 AOV Collection Sheet MS Excel R

3056 Non-Life SII Risk MS Excel N/A (models with
483198496.docx, July 2, 2019 page 68/115

LOGO DELETED

IFRS 17
Adjustment specific IFRS 4 or SII

purpose are not in
scope if IFRS 17
design)
4288 Consolidation LAT MS Excel N/A (models with

specific IFRS 4 or SII
purpose are not in
scope if IFRS 17
design)
4289 SII Movement Analysis MS Excel N/A (models with
specific IFRS 4 or SII
purpose are not in
scope if IFRS 17
design)
Table 24: An overview of the models in the AOV model landscape
The working assumption is that AOV products are not considered PAA eligible, so the AOV insurance
contracts require measurements via the General Model.
The as-is model landscape for AOV reserving is presented below, including the embedded file. In the
overview presented below the models that are suggested to be deleted are colored red, to be
modified colored amber, to be unchanged colored green. The models colored red are relevant for SII
reporting purposes.
483198496.docx, July 2, 2019 page 69/115

LOGO DELETED
Figure 4: Impacts of suggested solutions on the model landscape for AOV
Below a suggested/possible solution of the model landscape for the AOV portfolio under IFRS 17
requirements is presented, including the embedded file. Please note, this is only a suggested
(possible) solution that can still be subject to change and as such should by no means be considered
as the final solutions for the future state. The solutions are final when the final iteration (version) of
the DSD is approved.
483198496.docx, July 2, 2019 page 70/115

LOGO DELETED
Figure 5 Suggested draft IFRS 17 model landscape for AOV
4.4.4.2 WIA
The second as-is process relates to IFRS 4 and SII WIA reserving. The models in this process are
presented in the table below:

IFRS 17
3054 Schade WIA SAS LAN en SAS SAS Financial Publication
MF Layer of the Data Lake
3055 Schade WIA-rekenblad input MS Excel Financial Publication
483198496.docx, July 2, 2019 page 71/115

LOGO DELETED

IFRS 17
Layer of the Data Lake

4301 WIA Generate folders MS Excel Financial Publication
Layer of the Data Lake
2077 WIA Risk Agility Risk Agility Risk Agility
4299 Combines Output Risk Agility SAS R

4296 WIA-ResQ ResQ ResQ
4297 Stoplichtenmodel MS Excel R

4305 Schalingsfactoren IBNR MS Excel R
3053 WIA Collection Sheet MS Excel R

3056 Non-Life SII Risk Adjustment MS Excel N/A
4289 SII Movement Analysis MS Excel N/A

Table 25 An overview of the models in the WIA model landscape
The working assumption is that the WIA portfolio is PAA eligible 17, hence this requires only minor
adjustments to the current IFRS 4 approach for the liability for remaining coverage. However, if
contracts become onereous18, the loss component part in the liability for remaining coverage has to
be determined. This requires calculations similar to those under the General Model. As a result, both
the PAA and the GM functionality (and data) needs to be in place in the model landscape for WIA.
The as-is model landscape for WIA reserving is presented below, including the embedded file. Models
to be deleted, modified or remain unchanged are colored red, amber and green in this overview. The
models colored red are relevant for SII reporting purposes.
17
This working assumption has changed in the course of drafting this DSD
18
Regardless of the process how this is determined.
483198496.docx, July 2, 2019 page 72/115

LOGO DELETED
Figure 6 Impacts of suggested solutions on the model landscape for AOV
Below a suggested/possible solution of the model landscape for the WIA portfolio under IFRS 17
requirements is presented, including the embedded file. Please note, this is only a suggested
(possible) solution which is still subject to change and should by no means be considered the future
state solution. The solutions are final when the final iteration (version) of the DSD is approved.
483198496.docx, July 2, 2019 page 73/115

LOGO DELETED
Figure 7 Suggested draft IFRS 17 model landscape for WIA
4.5 Data design
Data lake
The data lake will be used to store reference data, used for the reporting models, and discount
curves. Furthermore, the liability data used in the models will be sourced via the data lake. The data
from the enterprise resource systems is ingested into the data lake on a real time or frequent basis.
Augmented data
In the future state, based on the current level-2 business requirements, existing data needs to
enhanced with IFRS 17 attributes based on group of contract level and cohorts that will be fed into
the models.
Discount rate curves and assumptions
483198496.docx, July 2, 2019 page 74/115

LOGO DELETED
Discount rate curves and assumptions into the new reference database tables need to be clearly
defined and identified distinctly by the following attributes:
 New date
 Discount period
 Amount
Assumptions stored should be designed to store historic references to all underlying data; process
will determine possibility and architecture for daily frequency of data supplied, stored and run.
The technical design will work on the assumption that the new SAD environment will be ingested to
the Data Lake. The connectivity settings and access rights between SAD and the Data Lake would be
set accordingly for each category of users.
Application enhancements
Application enhancements are yet to be determined at this time as the models and structures will be
determined in a future date during implementation. However, these will be described, with draft
designs in a functional design document:
* Addition of new tables - list of tables and depiction in the Data model diagram
 This will follow the process and systems architecture to be designed.
* Deletion of tables
 This will be defined within the normal change configuration policy and process for
the functionality
* Changes to tables – inclusion/exclusion of elements
 This will be defined within the normal change configuration policy and process for
the functionality
* Changes to internal or Domain tables if any
 This will follow any standard change configuration policy and process designed for
the functionality
The above is pending information collation from both the level 3 and 4 requirements by the business
requirements team, and validation by models team
New Application development
* Tables to be created and the fields’ info- list of tables and depiction in the Data model diagram
 Yet to be determined
483198496.docx, July 2, 2019 page 75/115

LOGO DELETED
* Internal or Domain tables if any
This would be supplied when the section above has more granularity.
4.5.1 Interfaces (incoming and outgoing)
All required data from the data lake is provided by the Finance Publication Layer as data publication
sets (see the IFRS 17 Solution Outline Section 8.1). Data required for IFRS 17 will be modified using
data in the data augmentation functionality, this functionality will be incorporated in the data lake.
At least the following IFRS 17 attributes need to be added:
 Portfolio
 Profitability indicator (onerous/non-
onerous/other)
 Cohort
 Classification (GM/VFA/PAA)
 Contract boundary
 Coverage Unit measure
 OCI/PL Indicator
 Effective yield vs. Projected credited rate
approach.
 Discount curve
 Link with reinsurance contract
AOV Interfaces:
# Input Definition Supplier Customer Impact of Description of Impact

(From) (To) IFRS 17
1 Policy and All data SIA Data Lake Low Data is already available in
claims the data lake
data
2 Policy and All data AESIS Data Lake Low Data is already available in
data
3 Policy and Data ID: 291 Data SAS (LAN) Medium Design new publication set
claims and IFRS 17 to provide required data
483198496.docx, July 2, 2019 page 76/115

LOGO DELETED
data data Lake according to Data ID: 291

and additional IFRS 17 data
4 Assumptio Assumption SAD SAS (LAN) High The IFRS 17 discount rates
n s, discount (within are to be stored in the Data
curves and Data Lake (this is part of Finance
costs Lake) Transformation)
5 Input for Data ID 293: SAS Data Lake High Within the SAS LAN the
models Data for (LAN) current data and IFRS 17
models data needs to be combined
for input into the models.
So the current data flow
needs to be linked on a
IFRS 17 risk group level
with the information from
the data augmentation
functionality.
6 Input for Data for Data Model High Design new publication set
models models Lake Environm to provide the required
ent data to the model
environment (includes IFRS
17 data)
7 Output Output Model Data Lake High Output data of the models
from models Environ needs to be ingested in the
models ment Data Lake
WIA Interfaces:
# Input Definition Supplier Customer Impact of Description of Impact

(From) (To) IFRS 17
1 Policy and All data SIA Data Lake Low Data is already available in
data
2 Policy and All data AESIS Data Lake Low Data is already available in
data
3 Policy and All data Robidus Data Lake High Data is not available in the
claims data lake
data
4 SUAG Data Lake High Data is not available in the

data lake
483198496.docx, July 2, 2019 page 77/115

LOGO DELETED
5 Policy and Data ID: Data SAS (LAN) Medium Design new publication set
claims 2284, 2285, Lake to provide required data
data 2286, 2287, according to Data ID: 2284,
2288, 2291, 2285, 2286, 2287, 2288,
2292 and 2291, 2292 and additional
IFRS 17 data IFRS 17 data
6 Assumptio Assumption SAD SAS (LAN) High The IFRS 17 discount rates
n s, discount (within are to be stored in the Data
curves and Data Lake (this is part of Finance
costs Lake) Transformation)
7 Input for Data ID 300: SAS Data Lake High Within the SAS LAN the
models Data for (LAN) current data and IFRS 17
models data needs to be combined
for input into the models.
So the current data flow
needs to be linked on a
IFRS 17 risk group level
with the information from
the data augmentation
functionality.
Input for Data for Data Model High Design new publication set
models models Data Lake Environm to provide the required
id: 300 and ent data to the model
301 environment according to
current data id 300 and 301
(includes IFRS 17 data)
Output Output Model Data Lake High Output data of the models
from models Environ needs to be ingested in the
models ment Data Lake
4.5.2 Functional data model
Discount rate curves and assumptions into the new reference database tables need to be clearly
defined and identified distinctly by the following attributes:
 New date
 Discount period
 Amount
Assumptions stored should be designed to store historic references to all underlying data; process
will determine possibility and architecture for daily frequency of data supplied, stored and run.
483198496.docx, July 2, 2019 page 78/115

LOGO DELETED
The technical design will work on the assumption that the new SAD environment will run in the
datalake; this is a pending architectural decision. The connectivity settings and access rights between
SAD and the datalake would be set accordingly for each category of users:
Application enhancements
Application enhancements are yet to be determined at this time as the models and structures will be
determined in a future date during implementation. However, these will be described, with draft
designs in a functional design document:
* Addition of new tables - list of tables and depiction in the Data model diagram
 This will follow the process and systems architecture to be designed.
* Deletion of tables
 This will be defined within the normal change configuration policy and process for the
functionality
* Changes to tables – inclusion/exclusion of elements
 This will be defined within the normal change configuration policy and process for the
functionality
* Changes to internal or Domain tables if any
 This will follow any standard change configuration policy and process designed for the
functionality
The above is pending information collation from both the level 3 and 4 requirements by the business
requirements team, and validation by models team
New Application development
* Tables to be created and the fields’ info- list of tables and depiction in the Data model diagram
* Internal or Domain tables if any
This would be supplied when the section above has more granularity
483198496.docx, July 2, 2019 page 79/115

LOGO DELETED
5 Change initiatives
No. Functi Busin Item Description Work Target No Deliver Statu
onal ess stream date regrets y team s
domai Req. (P /M / (Y/N)
n Ref. BR /
S&D)
AM_DA_ Actuar Replace the AOV & WIA - SAS S&D N Non-
1 ial model with (Model ID 3054), Life
fit for Processflow FN76 AOV,
purpose data Processflow FN76 WIA:
delivery.
(ID3054)
Replace the model with
fit for purpose data
delivery. Ideally this
model would become
obsolete by an
automated process of
data delivery for IFRS
17 calculations where
the data comes from a
data lake with a
financial publication
layer.
AM_DA_ Actuar Replace AOV – Generate folder M N Non-

2 ial model with and data (Model ID Life
FPL 4301)
functionality Replace the model with
and include fit for purpose data
the delivery delivery.
of
acquisition
expenses Ideally this model
and multiple would become obsolete
IFRS 17 by an automated
discount process of data delivery
curves (ID for IFRS 17 calculations
4301) where the data comes
from a data lake with a
financial publication
layer. The data delivery
must be adjusted to
include the acquisition
483198496.docx, July 2, 2019 page 80/115

LOGO DELETED

n Ref. BR /
S&D)
expenses and to load

multiple discount
curves in the data sent
to Risk Agility.
AM_DA_ Actuar Replace pre- WIA – Schade WIA S&D N Non-

3 ial processing (Model ID 3055), Life
WIA with FPL Processflow FN76 WIA:
functionality This model will most
(ID 3055) likely remain
unchanged for IFRS 17
and the functionality of
this model must be
built into the financial
publication layer of the
data lake.
AM_DA_ Actuar Build model AOV - Premieterug xl- M N Non-

4 ial to create model (Model ID 4323), Life
undiscounte Processflow FN76 AOV:
d cash flows In line with the IFRS 17
on IFRS 17 Solution Outline
group of Section 7.3 build a
contract model in R to create
(cohort) undiscounted cash
level. (ID flows on IFRS 17 group
4323) of contract (cohort).
with This can be done
by converting the
current Excel model to
R and adjusting the
aggregation routine of
that model.
AM_DA_ Actuar Build model AOV - Excels for M N Non-

5 ial to provide Collective (Model ID Life
current IBNR 4302), Processflow
cash flow FN76 AOV:
reserves (in In line with the IFRS 17
IFRS 17 Solution Outline
included in Section 7.3 build a
the best model in R to provide
estimate current IBNR cash flow
483198496.docx, July 2, 2019 page 81/115

LOGO DELETED

n Ref. BR /
S&D)
cash flows reserves (IFRS 17

for the LIC) included in the best
on estimate cash flows for
underwriting the LIC) on
year. (ID underwriting year. This
4302) can be done by
converting the current
Excel model to R and
convert with claims
triangles based on
accident year to
underwriting year.
AM_DA_ Actuar Adjustment Risk Agility Model (AOV M N Non-

6 ial to produce Model ID 2050): Life
undiscounte The model must be
d cash flows adjusted to produce
on an IFRS undiscounted cash
17 group of flows on an IFRS 17
contract group of contract level.
level. (ID
2050)
AM_DA_ Actuar Adjustment Risk Agility Model (AOV M N Non-

7 ial to produce Model ID 2077): Life
undiscounte The model must be
d cash flows adjusted to produce
on an IFRS undiscounted cash
17 group of flows on an IFRS 17
contract group of contract level.
level. (ID
2077)
AM_DA_ Actuar Adjustment (AOV Model ID 2050) M N Non-

8 ial for ability to The AOV Risk Agility Life
perform model must be
calculations adjusted to perform
based on calculations based on
differences differences in the
contract
boundary.
483198496.docx, July 2, 2019 page 82/115

LOGO DELETED

n Ref. BR /
S&D)
(ID 2050)
AM_DA_ Actuar Adjustment (AOV Model ID 2077) M N Non-

9 ial for ability to The AOV Risk Agility Life
perform model must be
calculations adjusted to perform
based on calculations based on
differences differences in the
contract
boundary.
(ID 2077)
AM_DA_ Actuar Adjust model WIA – ResQ (Model ID M N Non-

10 ial for IBNR cash 4296, Processflow FN76 Life
flows, Short WIA):
term The short term solution
solution (ID (before IFRS 17
4296) implementation date):
Keep the current
method of calculating
the IBNR (forms part of
the LIC calculation
under IFRS17) and use
the cash flow
functionality in ResQ to
develop IBNR cash
flows.
AM_DA_ Actuar Build model WIA – ResQ (Model ID M N Non-

11 ial for IBNR cash 4296, Processflow FN76 Life
flows, Long WIA):
term The long term solution
solution (ID (expected after the IFRS
4296) 17 implementation
date due to high
expected efforts and
external stakeholder
dependencies):
The IBNR reserve is
determined in the Risk
Agility model utilizing
an individual claims
483198496.docx, July 2, 2019 page 83/115

LOGO DELETED

n Ref. BR /
S&D)
reserving methodology.
AM_DA_ Actuar Rebuild for WIA – M N Non-

12 ial an initial Stoplichtenmodel Life
expected (Model ID 4297,
loss on Processflow FN76 WIA):
IFRS17 In line with the IFRS 17
portfolio Solution Outline
level (ID Section 7.3 build a
4297) model in R (converting
current Excel model) to
perform the
adjustment of the initial
expected loss on IFRS17
portfolio level
AM_DA_ Actuar Rebuild WIA – Scaling factors M N Non-

13 ial model and (Model ID 4305, Life
data quality Processflow FN76 WIA):
to produce In line with the IFRS 17
cash flows Solution Outline
on accident Section 7.3 build a
year basis (ID model in R (converting
4305) current Excel model) to
produce cash flows
here on accident year
basis and improve the
data quality issue in the
source systems to
model all plocies in the
ResQ model
AM_DA_ Actuar Rebuild AOV & WIA – Collection M N Non-

14 ial model to Sheets (AOV Model ID Life
include cash 3045)
flows per In line with the IFRS 17
IFRS 17 Solution Outline
group of Section 7.3 build a
contract model in R (converting
( cohort) (ID current Excel model) to
3045) include the cash flow
overview per cohort.
483198496.docx, July 2, 2019 page 84/115

LOGO DELETED

n Ref. BR /
S&D)
Additionally the new R

model must be
adjusted to include the
cash flow overview of
acquisition expenses
per cohort.
Incorporate the
additional cash flows
produced by the model
for PVI (new built
model to take away an
outside adjustment).
(This model could also

be used as the point
where all discounting
takes place.)
AM_DA_ Actuar Rebuild AOV & WIA – Collection M N Non-

15 ial model to Sheets (WIA Model ID Life
include cash 3053)
flows per In line with the IFRS 17
IFRS 17 roup Solution Outline
of contract Section 7.3 build a
(cohort) (ID model in R (converting
3053) current Excel model) to
include the cash flow
overview per IFRS 17
group of contract
(cohort).
Additionally the new R

model must be
adjusted to include the
cash flow overview of
acquisition expenses
483198496.docx, July 2, 2019 page 85/115

LOGO DELETED

n Ref. BR /
S&D)
per cohort.
AM_DA_ Actuar Future state Define the future state S&D Y Non- Done
16 ial of all non-life for non-life actuarial Life
actuarial models on the basis of
models IFRS 17 Solution Outline
Section 7.3 through
determining:
- whether the future

state supports Risk
Agility, ResQ and start
writing functional specs
to convert any excel
models to R
- for the pre-processing

data part as outlined in
IFRS 17 Solution
- how to incorporate
the post-processing
into the CMRE
AM_DA_ Actuar IFRS 17 Follow IFRS 17 Solution S&D Y Non-

17 ial solution Outline Section 4.1 for Life
outline any replacement of the
replacement SAS model functionality
SAS model by the Data Lake.
functionality
AM_DA_ Actuar Functional AOV - Risk Agility M Y Non-

18 ial specs to Model (ID 2050): Life
adjust the Adjust the model such
model such that it can perform
that it can calculations based on
perform differences in the
calculations contract boundary.
based on
differences
in the Start with
contract documentating
boundary (ID how/what (functional
483198496.docx, July 2, 2019 page 86/115

LOGO DELETED

n Ref. BR /
S&D)
2050) specifications)
AM_DA_ Actuar Functional AOV - Risk Agility M Y Non-

19 ial specs for Model (ID 2050): Life
cash flow Make all required cash
output flow output available at
available at the IFRS 17 group of
the IFRS 17 contracts level.
group of
contracts
level. (ID Start with
2050) documentating
specifications)
AM_DA_ Actuar Cash flow AOV - Premieterug xl- M Y Non-

20 ial output at the model (ID 4323) Life
IFRS 17 Make the cash flow
group of output available at the
contracts IFRS 17 group of
level. (ID contracts level.
4323)
Start with
documentating
specifications)
AM_DA_ Actuar Documentati Build New Model for M Y Non-

21 ial on to new PVI. Document how Life
build model and in which modelling
for PVI software to model the
PVI portfolio.
AM_DA_ Actuar Documentati Develop, document and P Y Non-

22 ial on of process draft a process to Life
and determine if a contract
identification has become onerous by
of facts and
information circumstances. Include
need for the information by
becoming which to determine so.
onerous
483198496.docx, July 2, 2019 page 87/115

LOGO DELETED

n Ref. BR /
S&D)
based on
facts and
circumstance
s
AM_DA_ Actuar Document AOV - Excels for M Y Non-

23 ial data Collective (ID 4302): Life
requirement Investigate and
s to change document the:
from
- change from
accident year
accident year
to
to underwriting
underwriting
year by
year (ID
checking if
4302)
claims data is
available on
underwriting
year.
AM_DA_ Actuar Functional AOV - Excels for M Y Non-

24 ial specs to Collective (ID 4302) Life
change the Investigate and
model from document the:
Excel to R (ID
- Change the
4302)
model from
excel to R
Table 26 Detailed Change Initiatives for DSD Disability (AOV/WIA)
483198496.docx, July 2, 2019 page 88/115

LOGO DELETED
6 Implementation effort
The inputs for the table below on implementation effort can be determined once implementation
changes following the design are going to be requested.
Project budget (optional)
Type of cost Expenses Total

Labor
…
Total
Schedule information
Project phase (Use N/A if not applicable) Phase start date Phase end date
Proposal
Initiation
Analysis & design
Development
Testing & verification
Implementation & rollout
Close out
Milestones Milestone dates
Vendor information
Will external vendors be undertaking the Project? [Yes/No]
If yes, please provide details:
Type of Vendor Product/Personnel/Service requested:
Reason for vendor assistance:
483198496.docx, July 2, 2019 page 89/115

LOGO DELETED
Project staffing
Role Name
483198496.docx, July 2, 2019 page 90/115

LOGO DELETED
7 References
7.1 Document References
Reference Document name Date
[1]
[2]
7.2 List of Abbreviations and Terms
Term/Abbreviation Explanation
ARE Accounting Rules Engine

BEL Best Estimate Liability
BS Balance Sheet
CF Cash Flow
CoA Chart of Accounts

CSM Contractual Service Margin
DA Data Augmentation System

DAC Deferred Acquisition Costs
DSD Detailed Solution Design

DTH Data Lake Transfer Hub
FPL Finance Puclication Layer

FSLI Financial Statement Line Item
GL General Ledger
GM General Model
LFRC Liability for Remaining Coverage

LIC Liability for Incurred Claims
483198496.docx, July 2, 2019 page 91/115

LOGO DELETED
Term/Abbreviation Explanation
OCI Other Comprehensive Income
PAA Premium Allocation Approach

PAS Policy Administration System
PSA Project Start Architecture

RA Risk Adjustment
SAD Setting Advisory Database

SIA Systeem Inkomen INSURANCE COMPANY A
SL Sub Ledger
TVOG Time Value of financial Options and Guarantees
UPR Unearned Premium Reserve

VFA Variable Fee Approach
483198496.docx, July 2, 2019 page 92/115

LOGO DELETED
8 Appendix A: Business requirements process impact

The appendix provides:
- The various business requirements with a process impact, split between

 AOV and WIA, and each further split in
 Processes for pre-processing/run-models/post-processing;
- An overview of the Disability products.
8.1 AOV Business requirements with a process impact on pre-processing
BR ID BR Description Impact on process
2.01-13 Process should in place to It should be noted that

generate non-market* generating non-market
variables necessary to variables is in scope of the
measure the expected value of DSD assumptions. However,
the future cash flows models should be able to use
accounted for under the these variables.
General Model at the required
level of unit of account. Determining the impact on the
Examples of non-market process in more detail is still
variables are: dependent on the outcome
of the NL position papers.
1) Renewal expenses
2) Mortality/morbidity
3) Persistency
4) Claim frequencies.
* All other variables than

market variables.
Non-economic variables
should be stored and tracked
over time (initial recognition
and subsequent periods) at
the required level of
granularity, potentially in SAD.
Table 27: Business requirements that have a process impact on pre-processing, step 1: Selection
relevant SAD items for AOV
2.01-24 This business requirement is In the current state

related to the acquisition cost (acquisition) costs are
attribution in IFRS 17. The exact calculated on a higher level
business requirement that than IFRS 17 groups of
483198496.docx, July 2, 2019 page 93/115

LOGO DELETED
follows from the standard is still contracts. Acquisition costs are

under analysis and depending on only attributed to new
the interpretation in the NL contracts and not to renewals.
position paper.
Determining the impact on the
process in more detail is still
dependent on the NL position
papers with more details on
how (acquisition) costs must
be treated under IFRS 17. The
current process should be
updated to be able to identify
and determine acquisition
costs at a IFRS 17 groups of
contracts level, which requires
more details in the (cost)
assumption setting.
2.01-27 Models should have the Determining the impact on the
functionality/capability to process in more detail is still
recognise the acquisition costs dependent on the NL position
over the coverage period as paper with more details
required. regarding in which way the
current systems and models
must be adjusted to take into
This should be done in the account acquisition costs
following way: insurance revenue according to IFRS 17.
related to insurance acquisition

cash flows must be determined
by allocating the portion of
premium that relate to
recovering those cash flows to
each reporting period in
systematic way dependent on
time. Note that the same amount
should be recognised as
insurance service expense as
well.
Table 28: Business requirements that have a process impact on pre-processing, step 8 Prepare input
files for Risk Agility runs with macro
8.2 AOV Business requirements with a process impact on run models
1.01-4 Models should have the The AOV Risk Agility model is
functionality/capability to not able to distinguish
measure the onerous contract's between onerous and non-
483198496.docx, July 2, 2019 page 94/115

LOGO DELETED
1.02-7 liability, the liability for remaining onerous contracts. Discussions

coverage and loss component on the treatment of onerous of
and any subsequent decrease in non-onerous contracts are still
the fulfilment cash flows of the ongoing.
onerous groups.
1.04-5 Models should have the Discussions are ongoing on the

functionality/capability to treatment of discount curves.
measure the value of the The 2 possible solutions are
fulfilment cash flows with a the following:
current discount rate at the
- Solution 1: Adjust the model
following time instances:
and the input file to make it
1) inception; suitable for loading multiple
discount curves
2) subsequent reporting periods,
- Solution 2: Perform
based on appropriate yield
Discounting Cash Flows in a
curves (e.g. effective yield and
separate model, the output of
projected credit approach) for
the valuation model are
each group of insurance
undiscounted future Cash
contracts.
Flows.
In addition, it needs to be
There should be a mapping decided where the different
between the assets backing-up types of discount curves will be
certain insurance contracts on stored and how they will flow
the required level of granularity into the process.
(essential for the current book
Based on the outcomes of
yield approach) as required by
these discussions the process
IFRS 17.
impact can be determined.
1.04-6 Systems should have the In the to-be situation a CSM

functionality/capability to store and Risk Adjustment tool will
discount rates over time. be added to the process,
which will use multiple and
locked-in discount rates. A
Systems should have the new specialized
functionality/capability to store system/module might be
locked in discount rates for each required to store the discount
IFRS 17 groups of contracts to rates at inception and every
determine CSM amortization and subsequent measurement.
impact of changes in fulfilment
cash flows on CSM (subsequent
measurement). More detailed information is
required on the discount rate,
e.g. where it will be stored
Systems should have the and derived.
functionality/capability for
483198496.docx, July 2, 2019 page 95/115

LOGO DELETED
deriving the locked-in discount

rates for a group of contracts,
where policies have been issued
through the IFRS 17 groups of
contracts period (less than one
year), a weighted average
approximation of discount rates
may be used.
2.01-6 The following cash flows within The insurance acquisition costs
the boundary should be should be included in the cash
included:
flow modelling.
Investment returns (note that
the ability must be in place to
dependent on the NL decision
separate investment paper, which will provide more
components from cash flows to details regarding in which way
the policyholders), the current systems and
models must be adjusted to
take into account acquisition
Allocation of insurance costs according to IFRS 17.
acquisition cash flows
attributable to the portfolio to
which the contract belongs.
2.01-8 Models should have the In the to-be process cash flow
functionality/capability to projection needs to be done on
measure the expected value of a more granular level, both for
the future cash flows accounted future period cash flows as for
for under the General Model at current cash flows. This
the required level of unit of functionality is currently not
account. captured by both Peoplesoft
and the models. This will have
Under the General Model and an impact on Peoplesoft or the
VFA models, the fulfilment cash newly introduced sub-ledger,
flows can be measured at: models and therefore on the
process as well. More detailed
a) the IFRS 17 Group of Contracts
information is required on this
level; or
functionality to determine the
process impact in more detail.
b) Fulfilment cash flows can be
calculated at a higher level of
aggregation, and then allocated
to the IFRS 17 Group of Contracts
level.
[See for the definition of the unit

of account BR. 1.02-1].
2.01-9 Data should be (made) available In the current Solvency II linear
to measure the expected value models, calculations are
483198496.docx, July 2, 2019 page 96/115

LOGO DELETED
of the future cash flows performed on a modelling

accounted for under the General group level, whereas under
Model at the required level of IFRS 17 this must be done at a
unit of account. more granular level.
Also under IFRS 17 a

distinguishment needs to be
made between experience
variance to the current period
cash flows and the future
period cash flows. Currently
only future period cash flows
can be provided.
More detailed information is

required to determine the
2.01-24 Feature must be in place to In the current state
calculate an appropriate (acquisition) costs are
allocation of acquisition costs in calculated on a higher level
accordance with the than IFRS 17 groups of
requirements. contracts. Acquisition costs
are only attributed to new
contracts and not to renewals.
Moreover, with respect to
operating expenses the following
allocation abilities must be in Determining the impact on the
place: process in more detail is still
1. Allocate transaction based
costs to group of insurance papers with more details on
contracts how (acquisition) costs must
2. Allocate policy administration
current process is to be
charges (billing changes and
surcharges) to group of
insurance contracts and determine acquisition
3. Allocate fixed and variable contracts level, which requires
overhead costs to group of more details in the (cost)
insurance contracts (also for assumption setting.
reinsurance group of contracts).
Furthermore, the current best
estimate expense assumptions
need to be adjusted in a way to
include these expenses in the
calculation of the BEL
483198496.docx, July 2, 2019 page 97/115

LOGO DELETED

over the coverage period as papers with more details
following way: insurance revenue according to IFRS 17.

well.
2.02-4 Systems should have the A process needs to be set up
functionality/capability to around the CSM. More detailed
determine the contractual information is required on the
service margin at initial CSM tool functionality, data
recognition, at the required level input and output to determine
of unit of account. the process impact in more
detail.
Table 29: Business requirements that have a process impact on run models, step: 10 Run Risk Agility
(Azure) – AOV
8.3 AOV Business requirements with a process impact on post processing
the future cash flows accounted future period cash flows as for
for under the General Model at current cash flows. This
the required level of unit of functionality is currently not
captured by both PeopleSoft
account.
an impact on PeopleSoft or the
newly introduced sub-ledger,
Under the General Model and models and therefore on the
VFA models, the fulfilment cash process as well. More detailed
flows can be measured at: information is required on this
a) the IFRS 17 Group of Contracts functionality to determine the
483198496.docx, July 2, 2019 page 98/115

LOGO DELETED
level; or process impact in more detail.

aggregation, and then allocated
to the IFRS 17 Group of Contracts
level.

follows from the standard is still contracts. Acquisition costs are
under analysis and depending on only attributed to new
position paper.

assumption setting.

required.
regarding in which way the
This should be done in the
account acquisition costs
following way: insurance revenue
according to IFRS 17.
483198496.docx, July 2, 2019 page 99/115

LOGO DELETED

well.
Table 30: Business requirements that have a process impact on post processing, step: 11 Gather
output
8.4 WIA Business requirements with a process impact on pre-processing
1.02-3 Data should be (made) available According to the IFRS 17

upon inception of the contract models team, additional data
and recorded in order to such as to which IFRS 17
determine categorization in groups of contracts a policy
and claim belongs to will have
groups.
to be included in the one
single dataset created by the
model. The 2 possible
At a minimum the following data solutions are the following:
should be (made) available in
dimensions/fields at the contract
level for IFRS eligible policies Solution 1: The model is
should be captured within the adjusted to include the
Data Lake or another module: additional information in the
created dataset (this solution
- Portfolio is valid given that there is no
datalake).
- IFRS 17 groups of contracts
- Group (Onerous vs. Non-

Onerous) Solution 2: The model is
adjusted to:
- Measure Classification (BBA vs.
a) Obtain the data from the
VFA vs. PPA)
datalake.
b) Include additional
information required by IFRS
17 in the create dataset.
Based on the outcomes the

process will be adjusted
accordingly and controls will
be revised or newly designed.
483198496.docx, July 2, 2019 page 100/115

LOGO DELETED

generate non-market* variables generating non-market
necessary to measure the variables is in scope of the
expected value of the future DSD assumptions. However,
cash flows accounted for under models should be able to use
the General Model at the these variables.
required level of unit of account.
Examples of non-market
variables are: Determining the impact on the
1) Renewal expenses
dependent on the outcome
2) Mortality/morbidity of the NL position papers.
3) Persistency
4) Claim frequencies. This business requirement is

only applicable for onerous
contracts and for incurred
* All other variables than market claims, as the General model
variables. then applies.
Table 31: Business requirements that have a process impact on post processing, step: 1 Sub process
WIA-Input (Data)

generate non-market* variables generating non-market
necessary to measure the variables is in scope of the
expected value of the future DSD assumptions. However,
cash flows accounted for under models should be able to use
the General Model at the these variables.
required level of unit of account.
Examples of non-market
variables are: Determining the impact on the
1) Renewal expenses
dependent on the outcome
2) Mortality/morbidity of the NL position papers.
3) Persistency
4) Claim frequencies. This business requirement is

* All other variables than market claims, as the General model
variables. then applies.
483198496.docx, July 2, 2019 page 101/115

LOGO DELETED

follows from the standard is still contracts. Acquisition costs
under analysis and depending on are only attributed to new
position paper.
current process should be
assumption setting.

over the coverage period as paper with more details
following way: insurance according to IFRS 17.
revenue related to insurance
acquisition cash flows must be
determined by allocating the In case a contract is non-
portion of premium that relate to onerous, the PAA is applied.
recovering those cash flows to For the calculation of the
each reporting period in liability for remaining
systematic way dependent on coverage, discussions are still
time. Note that the same ongoing on whether insurance
amount should be recognised as acquisition cash flows are
insurance service expense as recognized as an expenses or
well. insurance cash flows are
deducted from the received
premiums.
Table 32: Business requirements for process step 4: Make basis set assumptions SII/MVIS/IFRS LAT
3.04 - 6 Process should be in place for If contracts are considered to

reflecting the LFRC on the ledger be onerous, a loss component
483198496.docx, July 2, 2019 page 102/115

LOGO DELETED
(including any movements in the has to be determined for all

year) from the actuarial system. IFRS 17 groups of insurance
contracts. This loss component
will be determined by
comparing the liability for
remaining coverage following
the PAA method and the
fulfilment cash flow related to
the remaining coverage of the
group under the General
Model. The loss component
should be equal to the amount
the fulfilment cash flow under
the General Model exceeds the
carrying amount of the liability
of remaining coverage.
A process will need to be

designed to determine this
loss component.
3.04 - 11 Models should have the Refer to BR 3.04-6.
functionality/capability to
perform valuations of the
onerous contracts for which the
PAA method is used. For this
purpose the following should be
calculated (in any time during
the coverage period that a
contract is onerous):
1. Carrying amount of the LFRC

in line with BR.3.04 - 3
2. Fulfilment cash flows that

relate to the remaining coverage
of the cohort.
In other words, when an onerous

group has been identified the
measurement principles of the
GMM should be applied to
calculate the loss component,
adding a layer of complexity to
the PAA.
Table 33: Business requirements for process step 19: Consolidate WIA
8.5 WIA Business requirements with a process impact on Run models

1.04-5 Models should have the Discussions are ongoing on

functionality/capability to the treatment of discount
measure the value of the curves. The 2 possible
fulfilment cash flows with a solutions are the following:
current discount rate at the
483198496.docx, July 2, 2019 page 103/115

LOGO DELETED
following time instances: - Adjust the model and the

input file to make it suitable
1) inception;
for loading multiple discount
2) subsequent reporting periods, curves
based on appropriate yield - Perform Discounting Cash

curves (e.g. effective yield and Flows in a separate model, the
projected credit approach) for output of the valuation model
each group of insurance are undiscounted future Cash
contracts. Flows.
In addition, it needs to be
decided where the different
There should be a mapping types of discount curves will
between the assets backing-up be stored and how they will
certain insurance contracts on flow into the process.
the required level of granularity
Based on the outcomes of
(essential for the current book these discussions the process
yield approach) as required by impact can be determined.
IFRS 17.
This business requirement is

claims, as the General model
then applies.
1.04-6 Systems should have the In the to-be situation a CSM

functionality/capability to store and Risk Adjustment tool will
discount rates over time.
be added to the process, which
will use multiple and locked-in
discount rates. A new
Systems should have the
specialized system/module
functionality/capability to store
locked in discount rates for each
might be required to store the
IFRS 17 groups of contracts to discount rates at inception and
determine CSM amortization and every subsequent
impact of changes in fulfilment measurement.
cash flows on CSM (subsequent More detailed information is
measurement). required on the discount rate,
e.g. where it will be stored and
derived.
Systems should have the
functionality/capability for

deriving the locked-in discount This business requirement is
rates for a group of contracts, only applicable for onerous
where policies have been issued contracts and for incurred
through the IFRS 17 groups of claims, as the General model
contracts period (less than one then applies.
year), a weighted average
approximation of discount rates
483198496.docx, July 2, 2019 page 104/115

LOGO DELETED
may be used.
the boundary should be should be included in the cash
included:
flow modelling.
Investment returns (note that
the ability must be in place to
separate investment papers with more details
components from cash flows to regarding in which way the
the policyholders), current systems and models
Allocation of insurance according to IFRS 17.
acquisition cash flows
attributable to the portfolio to
which the contract belongs.
measure the expected value of
a more granular level, both for
the future cash flows accounted
future period cash flows as for
for under the General Model at
the required level of unit of
current cash flows. This
account. functionality is currently not
captured by both Peoplesoft
Under the General Model and an impact on Peoplseoft or the
VFA models, the fulfilment cash newly introduced sub-ledger,
flows can be measured at: models and therefore on the
process as well. More detailed
a) the IFRS 17 Group of
Contracts level; or information is required on this
aggregation, and then allocated This business requirement is
to the IFRS 17 Group of only applicable for onerous
Contracts level. contracts and for incurred
then applies.

2.01-9 Data should be (made) available A new process is required that

to measure the expected value can determine the experience
of the future cash flows variance (i.e. deviation of
accounted for under the General expected vs incurred). More
Model at the required level of detailed information is
unit of account. required on this functionality
to determine the process
483198496.docx, July 2, 2019 page 105/115

LOGO DELETED
impact in more detail.

then applies.
2.01-24 A new process is required that In the current state

can determine the experience (acquisition) costs are
variance (i.e. deviation of calculated on a higher level
expected vs incurred). More than IFRS 17 groups of
detailed information is required contracts. Acquisition costs are
on this functionality to determine only attributed to new
the process impact in more contracts and not to renewals.
detail.
Feature must be in place to process in more detail is still
calculate an appropriate dependent on the NL position
allocation of acquisition costs in
accordance with the how (acquisition) costs must
requirements. be treated under IFRS 17. The
Moreover, with respect to
operating expenses the following
allocation abilities must be in
place:
1. Allocate transaction based more details in the (cost)
costs to group of insurance assumption setting.
contracts
2. Allocate policy administration

charges (billing changes and
surcharges) to group of insurance
contracts
3. Allocate fixed and variable

overhead costs to group of
insurance contracts (also for
reinsurance group of contracts).
Furthermore, the current best
estimate expense assumptions
need to be adjusted in a way to
include these expenses in the
calculation of the BEL.
483198496.docx, July 2, 2019 page 106/115

LOGO DELETED
the boundary should be included: should be included in the cash
flow modelling.
Allocation of insurance
acquisition cash flows Determining the impact on the
attributable to the portfolio to process in more detail is still
which the contract belongs. dependent on the NL position
papers with more details
Systems should have the current systems and models
functionality/capability to must be adjusted to take into
calculate an appropriate account acquisition costs
allocation of acquisition costs in according to IFRS 17.
accordance with the
requirements.

required.
following way: insurance revenue
each reporting period in claims, as the General model
systematic way dependent on then applies.
well.
3.04 - 14 When using the PAA method, the For PAA products at
insurer may choose to discount INSURANCE COMPANY A
the liability for incurred claims. Schadeverzekering NV, it was
In this case it may be chosen to decided in the DA not to
disaggregate the insurance
disaggregate the insurance
483198496.docx, July 2, 2019 page 107/115

LOGO DELETED
finance income. finance income or expense.

This means all discounting in
the liability for incurred claims
If the insurer chooses to use this will be done on the basis of
option, then the insurance current discount rates.
finance income or expense in the
P&L should be determined using
the discount rate as specified in
BR.1.04 - 1 to BR.1.04 - 6 at the Based on that decision process
time instant the claim incurs. facilitating the disaggregation
of income and expenses does
not have to be designed.
However, discussions are

pending on whether to build in
this functionality in case this is
desired in the future.
3.04 - 15 Models should have the Refer to BR 3.04-14.
functionality/capability to apply
locked in interest rate to
contracts for which BR.3.04 - 14
holds.
Table 34: Business requirements for process step 6: Run RAFM WIA
8.6 WIA Business requirements with a process impact on post-processing

the future cash flows future period cash flows as for
accounted for under the current cash flows. This
General Model at the required functionality is currently not
captured by both PeopleSoft
level of unit of account.
an impact on PeopleSoft or the
newly introduced sub-ledger,
Under the General Model and models and therefore on the
VFA models, the fulfilment process as well. More detailed
cash flows can be measured at: information is required on this
a) the IFRS 17 Group of
Contracts level; or

aggregation, and then
allocated to the IFRS 17 Group
483198496.docx, July 2, 2019 page 108/115

LOGO DELETED
of Contracts level.
[See for the definition of the

unit of account BR. 1.02-1].
attribution in IFRS 17. The calculated on a higher level
exact business requirement than IFRS 17 groups of
that follows from the standard contracts. Acquisition costs are
is still under analysis and only attributed to new
depending on the contracts and not to renewals.
interpretation in the NL
position paper.
assumption setting.

required.
following way: insurance
revenue related to insurance
acquisition cash flows must be
determined by allocating the
portion of premium that relate
to recovering those cash flows
to each reporting period in
then applies.
time. Note that the same
amount should be recognised
as insurance service expense
483198496.docx, July 2, 2019 page 109/115

LOGO DELETED
as well.
Table 35: Business requirements for process step 7: Process RAFM output to ResQ input
483198496.docx, July 2, 2019 page 110/115

LOGO DELETED
8.7 Overview of the Non-Life Disability Products
INSURANCE COMPANY A has the following disability products, which can be split in AOV and WIA.
The AOV products are:
 AOV Collectief
 AOV Individueel
 AOV Individueel with Premium Resitution
The WIA products are:
 WIA Excedent
 WIA Aanvulling / Lite / Upgrade
 WIA 35-min / Bodem
 WIA PVI
483198496.docx, July 2, 2019 page 111/115

LOGO DELETED
9 Appendix B - Quality Assurance

The following check list should be considered throughout the development and review cycle and
completed by the DSD Management Owner prior to seeking approval from the DA.
This checklist was added while this version of the DSD was in the review cycle.
Ref Subject Initials resp. Date Comments resp. Blocking

person person issues y/n
QA-1  DSD template is used DB New template N

in most recent was available
template version after this DSD
entered the
review cycle.
Hence the most
recent template
is not applied
throughout this
document.
Elements with
practical
relevance are
adjusted,
change
initiatives log in
section 5 later
added.
This Quality
Assurance
checklist added.
QA-2  DSD version control in DB Document N
compliance with name
document name convention is
convention not clear
QA-3 All requirements are DB Based on high N
elaborated in the DSD. level design
Requirements a.o. come phase
483198496.docx, July 2, 2019 page 112/115

LOGO DELETED
from: requirements.
Lineage in next
 accounting policy
version to be
 business requirements
clear by design.
 non functionals, such
as performance
 fit/gap analyses
 High Level Solution
Design
 Key design decisions
 Decisions DA
 Level 2 requirements
QA-4  All relevant policies are DB Not included N

incorporated in DSD in yet, in scope of
separate tables. next version.
Policies are mentioned
in Design &
Implementation
Guide / checklist
QA-5  All relevant DB No. Upfront not N

stakeholders are clear who are
involved in DSD set up all the
(a.o. Information stakeholders.
Security, FIM BI, Stakeholders
Control Office Finance, have developed
Architects) during
 Indicate which
preparing the
stakeholder categories
DSD
are mandatory
(introduction of
categories and which
“the factory”).
are non-mandatory
 Indicate who was the

representing person
QA-6  Governance of the DSD DB Yes N
review process is
followed
QA-7  Review comments are DB Yes, but as N
processed before processed
presenting to the review
combined DA (issue comments (not
raiser / issue solver + as audit findings
date new issue and and finding
date issue solved is remediation
clear)
planning)
483198496.docx, July 2, 2019 page 113/115

LOGO DELETED
QA-8  ‘No regrets’ are clear DB Yes N

and categorized per
delivery team
(Factory / IFRS17)
QA-9  All items ‘to be DB Captured in N

defined, to be decided chapter Error:
on, etc.’ are monitored Reference
and captured in source not
separate sections of found
the DSD
QA-10  DSD based on latest DB No. The DSD

versions of template was
documentation changed while
(attachments, etc.) this DSD version
was long in
review.
QA-11  DSD walkthrough is DB Yes, this

planned / held process was
 Questions or issues are introduced
captured and answers while the DSD
are tracked was in review
cycle.
QA-12  Requirements from DB

DSD are incorporated
in requirements
traceability matrix
QA-13  DSD version DB Version control

traceability is maintained.
maintained in a
separate section of the
DSD
 Traceability of
underlying documents
is maintained in a
separate section of the
DSD
QA-14  Changes are DB Yes. The log was
documented in the introduced
Change Initiative Log during the
review cycle.
Table 36 QA Checklist
483198496.docx, July 2, 2019 page 114/115

LOGO DELETED
483198496.docx, July 2, 2019 page 115/115

Insurance Models Solution Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Insurance Models Solution Design

Uploaded by

Copyright:

Available Formats

Detailed solution design

INSURANCE COMPANY A IFRS 17

Actuarial Models and Calculations - Disability (AOV/WIA)

Sanitized by Global Markets - EY Knowledge

BIA Template library Link to SharePoint template library

BIA Template category Functional Design

BIA Wiki reference Link naar de BIA Functional Design Wiki

BIA Template date

BIA Template owner BIA Competentiegroep – Feedback over deze

Draft prepared by: IFRS 17 project team - Models lead (PERSON)

Version Date Description Author

0.2 3-10-2018 Edits to chapter 2, added scope, list

0.3 12-10-2018 Input Systems & Data

0.4 17-10-2018 Review input Systems & Data

0.5 18-10-2018 Changes regarding review by

0.6 18-10-2018 Input Model Design

0.7 18-10-2018 Input Business Design / Process

0.8 9-11-2018 Comments on the Model Design

Review comments of embedded

0.9 9-11-2018 Review comments on the processes

0.10 13-11-2018 Edits to section 1, adjusted the

0.11 14-11-2018 Edits to chapter 4, moved the

0.12 16-11-2018 Edits in chapter 1.2, 2, 3.1 and 3.2

0.14 22-11-2018 Edits to Table 1 in the executive

0.15 28-11-2018 Reviewed input business

0.16 29-11-2018 Review input system-data.

0.17 30-11-2018 DSD author review, minor edits,

0.18 4-12-2018 Process reviews PERSONS

0.19 10-12-2018 Review based edits. Edits to

0.20 13-12-2018 Added review comments from

0.21 15-1-2019 Edits based on review comments

0.22 22-1-2019 Minor edits for DA review version.

0.23 23-1-2019 Edits based on review comments

Edits based on review comments

0.24 8-2-2019 Edits on models (wording,

0.26 14-2-2019 Upgrades to reflect IFRS 17 solution

Edits based on review by

Added new section 5 Change

Moved working assumptions into a

0.27 15-2-2019 Review by PERSON for draft IFRS 17

Edits to various suggested solutions

0.28 18-2-2019 Edits to align change initiatives log

Additional replies to review

Review PERSON and edits to align

Version Date Name Version

0.20 13 Dec 2018 - INSURANCE COMPANY A Version for review INSURANCE

0.22 22 Jan 2019 - Design Authority Version for Design Authority

0.23 29 Jan 2019 - Design Authority Version for Design Authority

0.28 18 Feb 2019 - Design Authority Version for Design Authority

Version Date Name approver Approval

No quorum for DA approval due to not all DA

0.28 18 Feb 2019 (by Design Authority

Management Owner PERSON

Business Requirements PERSON

Process and controls PERSON

Models PERSONS (IFRS 17 SME review)

Data and systems PERSON

INSURANCE COMPANY A PERSONS

First, some introduction notes about the structure of this DSD.

- Arbeidsongeschiktheidsverzekeringen (AOV), and

1.1 Executive summary

- The value to progress the DSD in a context of requirements developed in iteration;

The value to progress the DSD in a context of requirements developed in iterations