SEWPZG628T – Dissertation Finance Transformation – TARDIS

FINANCE TRANSFORMATION
TARDIS (Transparent Actuarial Reporting Database Insight – UNISURE)

SEWPZG628T DISSERTATION

By:
Sagar Agrawal
2013HW70753

Dissertation work carried out at

Wipro Technologies, Pune

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE

Pilani (Rajasthan) India

Sept 29, 2017

SEWPZG628T DISSERTATION

Bits ID: 2013HW70753 Page 1 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

FINANCE TRANSFORMATION
TARDIS (Transparent Actuarial Reporting Database Insight – UNISURE)

Submitted in partial fulfilment of the requirements of

M. Tech Software Engineering Degree Program

By:
Sagar Agrawal
2013HW70753

Under the supervision of

(Priyanka Katare, Technical Lead)

Dissertation work carried out at

Wipro Technologies, Pune

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE

Pilani (Rajasthan) India

Sept 29, 2017

Bits ID: 2013HW70753 Page 2 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

Bits ID: 2013HW70753 Page 3 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

Bits ID: 2013HW70753 Page 4 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

Bits ID: 2013HW70753 Page 5 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

Acknowledgements

I am highly indebted to Priyanka Katare for all the guidance and constant
supervision as well as for providing necessary information regarding the project &
also for the support in completing the project.

I would like to express my gratitude towards my examiners, Miss Sona Jain & Mr.
Naman Pandey for their kind co-operation and encouragement which help me in
completion of this project.

I would like to thank Wipro Technologies to provide me with the necessary

infrastructure to undertake and complete the project & BITS Pilani for providing
me with the platform to undertake the project and carry forward the vision.

My thanks and appreciations to my peers in helping me develop the project and

giving me such attention and time.

Bits ID: 2013HW70753 Page 6 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

Bits ID: 2013HW70753 Page 7 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

Contents

1 Introduction..........................................................................................................................................................9
1.1 Purpose.........................................................................................................................................................9
1.2 Business Background..................................................................................................................................10
1.3 Approach.....................................................................................................................................................11
1.4 Scope...........................................................................................................................................................13

2 High Level Macro Design..................................................................................................................................14

2.1 Assumptions................................................................................................................................................14
2.2 Design Decisions........................................................................................................................................15
2.1 High Level System Architecture..................................................................................................................18
2.2 ETL Architecture.........................................................................................................................................18
2.3 Glossary of Key Terms................................................................................................................................22
2.4 List of Figures.............................................................................................................................................23
2.5 Open Issues at Submission of This Draft....................................................................................................23
2.1 Environment Definition...............................................................................................................................23

3 Version Control Process....................................................................................................................................24

4 Archival Strategy...............................................................................................................................................25

5 Source System Dependency...............................................................................................................................26

6 Non-Functional Requirements..........................................................................................................................27

7 Source Specific macro design............................................................................................................................28

7.1 Data Flow Diagram....................................................................................................................................28
7.2 Pre and Post Processing Requirements......................................................................................................28

8 Source Data.........................................................................................................................................................29
8.1 Source Data Specification...........................................................................................................................29
8.2 Extract Process...........................................................................................................................................30
8.3 Staging Source Data...................................................................................................................................30
8.4 Source Data Dictionary..............................................................................................................................31
8.5 Identify the Movement Logic.......................................................................................................................34

9 Database Overview............................................................................................................................................35

10 Data mapping and business rules.....................................................................................................................36

Bits ID: 2013HW70753 Page 8 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

1 Introduction
1.1 Purpose
This document is a Finance Transformation deliverable and represents the interface macro
design for the UNISURE, covering the movement and transformation of data from the UNISURE
source system extract through to the Persistent Actuarial Database (PAD) for Product Families
Unitized NP Pensions, Unitized WP Pensions and Term Assurance. It will serve as the major
source input into the development of off-shore Technical specification for the same functional
scope.

This macro design is one of a number of Finance Transformation designs ultimately concerned
with the production of in-force and movement Model Point Files (MPFs) for consumption by
the Prophet application. For simplicity, the scope of this particular design is highlighted in
yellow in the diagram below:

P1L70 –Product
Families 1 to3

P1L70 – Product
Families 4 to 13

UNISURE

In-Force
and
AR
Movement
Model
Paymaster
(Refresh)
PAD Point Files
for Prophet

Alpha

Administrator

Other Sources
(manual policy
feeds)

Figure 1

This design therefore covers the extraction, transformation and loading of data items from the
UNISURE extracts into the target PAD database. The data transformed and stored is that
required to fulfil the stated requirements of the Finance Transformation Prophet Enhancement
team for the valuation of Product Families Unitized NP Pensions, Unitized WP Pensions and
Term Assurance.

Bits ID: 2013HW70753 Page 9 of 38

SEWPZG628T – Dissertation Finance Transformation – TARDIS

The onward transformation of UNISURE data into Model Point Files (MPFs) for consumption by
Prophet will be covered within a separate macro design.

1.2 Business Background

CUSTOMER has outlined a strategic intent to significantly grow and develop its business. This in
turn means that CUSTOMER Finance must change, if it is to provide the right level of service
and support along the agreed dimensions.

To meet this challenge, CUSTOMER is planning to transform its Finance function and the way it
serves its customers. The Finance Transformation programme has been established to address
this need through delivering the following outcomes.

 Deliver a significant reduction in reporting cycle times;

 Develop deep capability in business partnering and strategic business insight;

 Re-engineer processes to create clearer accountability, reduce duplication and drive

efficiency and effectiveness improvements;

 Significantly simplify very complex data feeds and so reduce complexity in Prophet
modelling and reducing reconciliation effort; and

 Restructure the organization to facilitate service quality improvement and cost

reductions and create an inspirational finance leadership team that actively engages
with its people, prioritizes people development and customer service.

The PAD forms a key foundation of the Solution Architecture developed to support these
programmed outcomes, providing:

 A single source of data for in-scope actuarial valuation and reporting

 Data transformations which are documented, agreed and visible to the business via
Informatica’s Meta Data Manager tool

 A logical and physical data model as a representation of business requirements as

opposed to disparate source data structures

Below are the product families to which Unisure data goes as modal point files.

Bits ID: 2013HW70753 Page 10 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Figure 2

1.3 Approach
This macro design has been generated from the following primary inputs:

1 – The UNISURE source extracts specification.

2 – The specification of required signed off business logic based on stakeholder engagement
with the Finance Data Team and consequent validation with the reporting teams

3 – The representation of that business logic in ETL mappings, applied using the following
design principles to the physical and logical models of the PAD and its data transformations:

Principle Explanation Where Applied

The PAD is a model Only required data will be maintained in the PAD, not
of business all available source data. The PAD represents a model PAD PDM
requirements of expressed business requirements.

Bits ID: 2013HW70753 Page 11 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Principle Explanation Where Applied

If policy level data is computed (e.g. aggregations,
selection, etc.,) from the transactional records (cash
Transformed source flows, movements, history, etc.,), the transformation PAD PDM,
data will be stored in will be performed in the inbound ETL and the Source to PAD
the PAD computed value will be stored in the PAD. ETL

Source extract data will be held in the inbound staging

area for the minimum period based on business
Historic source data requirements. Typically this will be a maximum of 2
will not be months (where month to month deltas are required in Source extract
preserved in the order to infer movements). staging
PAD The PAD will build history and will preserve historic
positions. This is not the same as storing historic
source extracts.

All specific Prophet- All the Prophet Related transformations/adjustments

Related will be performed between PAD and outbound
transformations/adj staging.
PAD to Prophet
ustments will be On occasions where a DataMart and Prophet wish to
ETL
performed between receive the same computed value we should store
PAD and outbound both the data before and after transformation
MPF staging (increasing storage, but improving data lineage etc.)
Frequently changing
The use of lookup tables allowing soft-coded business PAD PDM
mappings should be
rules will make the system easier to maintain. (reference
soft-coded using
data),Source to
reference data Exceptions to this rule may be made where there is a PAD ETL,PAD to
lookup tables where performance consideration. Prophet ETL
possible

4 – Specific design activities in accordance with the principles listed above to determine a) the
physical PAD model, and b) whether a particular piece of logic should be applied between
source extract and PAD or between PAD and MPF. The scope of this design excludes PAD to
MPF data transformations for now. It would be included in other few weeks.

Bits ID: 2013HW70753 Page 12 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

1.4 Scope
1.4.1 In-Scope
 Consume the UNISURE source extract and populate the PAD according to stated
requirements and agreed business rules. The stated requirements are explicitly taken
from Prophet IFAD for Unitized NP Pensions, Unitized WP Pensions and Term Assurance.

 Application of scheduling in line with the Generic OMD macro design

 Application of errors and controls processing in line with the Errors and Controls macro
design

 Movements capture for Non New business and Non Incremental business.

1.4.2 Out of Scope

The following out of scope items are within the scope of separate Finance Transformation
Technology Delivery designs, however out of scope of this document for now. It would be
covered in next few weeks.

 Any Model Point File data production (In force and Movement MPF, GMPF, XMPF).

 The production of any Data marts or the consumption of any Prophet results

 The supply of Assumptions data to the Prophet Application

 Any interaction with Prophet Automation (the processes which control the interface
between the PAD and Prophet)

 Code Release and Version Control mechanisms and processes

 Any storing/archiving of source extracts once these files have been read into the PAD
staging tables

 Reporting of controls data, trend analysis and reconciliation. This design supports the
storage of that data and the subsequent macro design will incorporate the reporting
functionality.

Movements capture for new business and incremental business.

Bits ID: 2013HW70753 Page 13 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

2 High Level Macro Design

2.1 Assumptions
Assumption Justification
The UNISURE source extract, ICMS Consistent with Solution Architecture
Commissions and Asset share factors expectations
extract files would be produced on monthly
basis and will be pushed to a location on
the Unix file system from where it can be
read by Informatica and the GOMD
scheduling tool
The UNISURE extracts will be in Fixed Width Specified in the UNISURE Source extract
ASCII format specifications
Multiple extracts will be provided. Specified in the UNISURE extract
specifications
Business rules for MPF variables which These variables are defaulted to maintain
were not present in Unisure would be the consistency of MPF variables across
defaulted during the MPF generation, so Product families.
not being covered as a part of loading into
PAD
The movements provided on the contract Confirmed with FT BD team.
engine extract are understood to represent
a super-set of Finance Transformation
requirements. These will be grouped and
filtered as required between PAD and MPF
to derive the movements in which Prophet
is interested.
As a part of DFR requirements, Headers and Based on the communication from
footers will be included in Unisure Inforce Customer DFR team.
and Movement extracts from September –
2009 onwards and accordingly the Pre and
Post DFR files shall be loaded into STG.
There is a potential chance of the Based on the communication from
occurrence of duplicates records in the CUSTOMER team.
inforce files due to the structure of inforce
IFAD and these shall be considered as
genuine duplicates and shall be processed

Bits ID: 2013HW70753 Page 14 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Assumption Justification
to the stage tables

2.2 Design Decisions

Design Decision Justification
All the data sets created from the UNISURE Reusability of Dataset’s data created,
source extracts will be staged in simplifying the data flow
intermediate tables between Inbound and
PAD

Due to the various migrations onto the

Unisure systems, though the input file
structure is mostly confirmed, the level of Consistent by the Business Requirement
transformations and grain of processing the
data and generating the model points is
different across the various product
references.

To accommodate these differences within

the Unisure source and conform it across
the different contract engines with the PAD
database and Outbound design, the
inbound design would store data within
PAD at two grains - one catering the grain
of Policy Number, Increment Reference and
Coverage Reference combination and
another grain catering the Policy level data.
All the measure/dimensions will be
populated across PAD with both these
grains, these of course are aggregates for
policy level grain. The outbound design,
would perform a discriminatory selection
depending on the product reference and
transform the agreement data into the
model points.

The grain where a particular policy can be

invested using multiple premium types

Bits ID: 2013HW70753 Page 15 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Design Decision Justification

would be accommodate on the policy -
fund relationship, which indicate the
current position of investments depending
on the premium type.

Cases where the input files behaves

differently across the sub tranches (like
Indemnity Proportion, % LAUTRO Initial
Commission Rate, etc., are selected from
different columns of the source file
depending on the product references) this
will be conformed with in the inbound.
Movements would be captured only from Driven based on the discussions with
the weekly movement extracts and no Unisure Stack team
specific derivations would be made to
populate the movements in the activity
agreement relationship table. The target
activity code and activity effective date
would be populated solely based on the
source movement type and movement
effective date coming from the weekly
movement extract
The initial load to the PAD table Agreement To make sure that all the policies would be
Activity Relationship would be done from available in the table before capturing the
the Inforce snapshot and the load to this changes for all the policies
table from the subsequent months would
happen from the weekly movement
extracts.
SCD Logical Deletes month-on-month: Approach 2 was preferred because of its
We have a requirement for month-on- less number of updates on the PAD table
month logical deletes while loading data where the data will be in huge volumes.
into PAD. A few such scenarios are: Also, for inserts into the temporary table
 Unexpected off's like a policy or a we have the flexibility to use Bulk Load
component/element of a policy option of Informatica.
disappearing from the extracts
 Benefit/Life/Reassurance details on
the policy not populated in the
subsequent extracts

Bits ID: 2013HW70753 Page 16 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Design Decision Justification

 Changes to Fund investments of a
policy; Investments removed or
switches between the funds, etc.
As these are logical deletes from the source
system, they aren’t communicated through
to PAD. Therefore, our ETL would’ve no
information regarding the same.

Now, all the inbound data from the source

month-on-month is a complete snapshot of
data as compared to the previous month.
Therefore, identifying new records and
updated records would be easier as
compared to identifying the deletes per
PAD table/entities.

The following 2 approaches were

considered for implementation:
Approach 1:
Updating all the records from the source
for the current month/load while loading
the target PAD tables for identifying the
residual records & concluding them as
deletes.

Approach 2:
A slim long temporary table will be created
to store all the surrogate keys for the data
corresponding to the current run/month
and later a table-minus-table is computed
between the PAD table and this temporary
table to infer the logical deletes from the
source.
This temporary table would be partitioned
based on the mapping identifier and source
to facilitate a partition truncate once the
logical deletes have been made.

Bits ID: 2013HW70753 Page 17 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Design Decision Justification

A decision was taken to implement

Approach 2.
Change Data Capture (CDC) will not be used This is because if CDC is implemented, We
across the work streams (P1L70, Unisure, would not be in a position to identify
Paymaster and Administrator). records which need to be logically closed in
the PAD tables. The approach for closing
the records in the PAD tables is explained in
the SCD logical deletes design decision.

1.1 High Level System Architecture

2.3 ETL Architecture

The ETL architecture covering the scope of this design. For clarity and simplicity, the key
elements are represented below:

Bits ID: 2013HW70753 Page 18 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

ETL Architecture Flow

PERL SCRIPT

ETL2 ETL3 ETL4 ETL5 ETL6

DB DB
DB DB

Target Files
UNISURE Source Files (139 MPF’s)
Inbound Staging Intermediate Tables
(Fixed width ASCII) PAD Outbound Staging
on Informatica
to store UNISURE
UNIX server data sets

ETL – Using Informatica 8.6 ETL1

DB - Oracle 10g database
DB DB DB
Normal Data Flow
Unprocessed Data Flow
Operational Batch Reference Data
Operational Batch Data Flow Unprocessed Data Lookup Data
Data (GOMD) Files
Lookup Data Flow
Out of scope for
this document

GOMD

Figure 3

The description of the above components and process flow is given below.

GENERIC OMD
Generic OMD is an CUSTOMER scheduling tool. As part of GOMD, a PERL script is the basic
driver to invoke and execute each ETL job throughout the process as explained in the OMD
Macro design document.

OMD Operational Meta Data table will contain data about batch identifiers, for instance: source
system name, received date of the source file, processed date and statuses of each processing
state (such as Pre-PAD Data Stage successful, Loaded to PAD, Post-PAD Data Stage Successful,
MPF created). The data into this table inserted/updated by PERL script only. There will not be
any direct interface to this table from Informatica mapping.

e.g.: PAD is associated with a Batch Identifier, enabling roll back to be handled by the Batch
Identifier when a session fails abruptly. It is expected that a particular ETL job should be re-
started on failure. More details can be found in the OMD Macro Design Document.

Bits ID: 2013HW70753 Page 19 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

UNPROCESSED DATA:
Error handling and controls data structures and processes are represented in the Errors and
Controls macro design. The source specific implementation of that generic design is contained
in Section Error: Reference source not found of this document.

REFERENCE DATA FILES:

These files will be loaded into respective lookup database tables using ETL-1.

LOOKUP DATA:
Reference data is stored in multiple database tables. These tables will be looked up and
required reference values will be retrieved during the processes ETL-3 and ETL-4 which loads
data into PAD and outbound staging tables respectively.

ETL-1:
It consists of Informatica mapping/s which reads the data from reference files/tables and loads
into respective lookup database tables.

SOURCE:
CUSTOMER Valuation system on monthly basis will generate UNISURE extract files. The ETL
source will be the UNISURE source extract files which are generated by this valuation system.
The same files will be copied onto Informatica UNIX server at specified location from where the
Informatica service reads and processes the source data.

ICMS Commission system would be generating the extract on monthly basis. The same would
be copied onto Informatica server on the Unix environment at specified location and then
picked up by the Informatica service to processes it.

Asset Share Factors data would be used for referencing the Fund, Asset Share and Unit Price
calculations

ETL-2:
ETL-2 consists of Informatica mappings which read the data from source UNISURE files and
loads into inbound staging table. During the process if any source record violates the business

Bits ID: 2013HW70753 Page 20 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

or database constraint rule, that record will be populated into unprocessed data table using the
process described in the Error Handling Macro Design.

INBOUND STAGING:
Inbound staging table has similar structure to the source data, with the addition of meta data
fields (e.g. Extract Date, Source File Name, Batch Identifier).

Where required, Inbound Staging will contain the data from the current and prior extract (i.e.
two consequent months of data), allowing movements to be detected via the delta between
two extracts, where movement events or transactions are not provided on the source extract.
The stage table will be partitioned in order to enable historical data to be easily deleted (via
truncating the partition) when no longer required.

ETL-3:
ETL -3 consists of Informatica mappings which reads the data from inbound staging table and
loads into Intermediate tables specific to UNISURE. These intermediate tables will contain the
Data sets derived from the UNISURE inbound staging data.

ETL-4:
ETL -4 consists of Informatica mappings which reads the data from inbound staging table and
loads into PAD table. During the process if any record violates the business or database
constraint rule that record will be populated into unprocessed data table according to the Error
Handling Macro Design.

PAD:
PAD (Persistent Actuarial Database) consists of multiple database tables with predefined
relationships.

The following stages are explicitly out of scope for this design:

ETL-5:
ETL-5 consists of Informatica mappings which read the data from the PAD and loads into
outbound staging table. More details are provided as a part of PAD-MPF Macro.

OUTBOUND STAGING:

Bits ID: 2013HW70753 Page 21 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Data will be staged in the outbound staging before creating the MPF files. More details are
provided as a part of PAD-MPF Macro.

ETL-6:
ETL-6 consists of mappings that will create the MPF files. More details are provided as a part of
PAD-MPF Macro.

TARGET:
The target is Model Point ASCII CSV files with column and business header information. More
details are provided as a part of PAD-MPF Macro.

OTHER PROCESS STAGES:

Post-Prophet, a series of ETL processes will consume Prophet Results, PAD data and other data
sources to fulfil the ultimate business reporting requirements via the Data Marts. These
processes will be specified within the Data Mart ETL macro designs.

2.4 Glossary of Key Terms

Term Description

UNISURE Data related to Pensions

PAD PAD = Persistent Actuarial Data Store. Synonymous with “ODS”
MPF Model Point File
A data file with a defined structure that is used to load required data into
the Prophet tool
ETL Extract Transform Load
The process of extracting data from external sources, transforming it to
fit business needs and ultimately loading it into the end target.
Contract Engine A contract engine is a system that is used to generate and store
contracts. I.e. a policy, pension scheme, pension scheme category etc.

Bits ID: 2013HW70753 Page 22 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Term Description

Prophet Prophet is a modelling tool used by the Actuarial Community. Inputs

include Model Point Files containing policy information taken from the
contract engines/databases.
Prophet calculates liabilities. It analyses at all cash flows on each policy,
for each month, up to 40 years in the future.
Prophet comprises two elements:
• An automation tool which runs Prophet Models as soon as all required
data is available.
• An Actuarial tool which performs deterministic valuations of individual
policy / benefits (individual model points) or summarised (grouped)
models.  This creates two types of results – a record for each input model
point for a fixed time period and a summary for multiple time periods.
Staging A staging area is used as a place to store temporary data for import.
GOMD Generic OMD is an CUSTOMER scheduling tool

2.5 List of Figures

Figure Description
Figure 1 Holistic view of UNISURE in Finance Transformation Solution
Figure 2 ETL Architecture flow
Figure 3 Data flow from Source to PAD

2.6 Open Issues at Submission of This Draft

Bits ID: 2013HW70753 Page 23 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Issue Planned Resolution

The full volume Post DFR files for The communication is already sent to CUSTOMER DFR
Inforce and Movement extracts teams requesting for the files
have not yet been received and this
might impact the testing of the
POST DFR code.

1.1 Environment Definition

Tools Version Function

AIX 5.3 Operating System

Oracle 10g Database

Informatica 8.6 ETL tools to perform all the Extract Transform

and Load functions

GOMD CUSTOMER tool used for scheduling in the

Finance Transformation Programme.

Bits ID: 2013HW70753 Page 24 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

3 Version Control Process

The control of specific code releases, and the management of the Informatica repository, is out
of scope of this design. As Release Management activities, they will be specified elsewhere.

Bits ID: 2013HW70753 Page 25 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

4 Archival Strategy

Archiving breakdown will include:

 File storage (Source file staging, MPF staging),

 Database staging areas

 PAD.

Bits ID: 2013HW70753 Page 26 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

5 Source System Dependency

Not applicable for UNISURE system.

Bits ID: 2013HW70753 Page 27 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

6 Non-Functional Requirements

All Non-functional requirements are captured in Requisite Pro. They include response times,
data storage, tracking of data, data lineage, access levels and security etc.

In addition to the documents referenced above, the following ‘Issue Resolution’ requirement
was captured during the design review:

"In the event that reference data used to load a given source system data feed into the PAD is
found to be corrupt, incorrect or incomplete then it must be possible to re-supply or amend the
reference data and re-run the staging to PAD mapping to resolve the errors.  In practice, this
would mean:  

Policies that had previously been written to the Unprocessed Data table being successfully
loaded to the PAD
Policies that had previously been loaded to the PAD being written to the Unprocessed Data
table
Policies that had previously been written to the PAD being again written to the PAD but with
changed data values 

The re-running of Staging to PAD processes will first require the manual deletion of inserted
records on the basis of batch identifier, and the re-setting of record end dates and current flags
for those records which have been updated. This is expected to be a manual BAU process,
though the necessary SQL statements are expected to be provided to aid testing.

Any PAD batch activities which are dependent on the successful load of this source system feed
(e.g. MPF production) should not commence until users confirm that the data loaded to the
PAD for the given source system is of sufficient quality (i.e. that the Unprocessed Data has been
examined and any reprocessing of the kind described above has taken place). This requirement
should be handled by the creation of GOMD meta data and the configuration of GOMD for
Finance Transformation."

Bits ID: 2013HW70753 Page 28 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

7 Source Specific macro design

7.1 Data Flow Diagram
The diagram represented below gives the flow of data from the Source to PAD.

Figure 4

7.2 Pre and Post Processing Requirements

Not applicable for UNISURE

Bits ID: 2013HW70753 Page 29 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

8 Source Data
8.1 Source Data Specification
The UNISURE source data is transmitted in fixed width ASCII files. Data is split across 3 extracts,
each containing multiple files.

The 3 extracts are listed below:

Interface
Description
Name
The extract will transmit the below 3 files on a monthly basis
NUCBL.DESIGNER.DATA.TCBDLEL.UNLOAD
ICMS NUCBL.DESIGNER.DATA.TCBCNDL.UNLOAD
commission NUCBL.DESIGNER.DATA.TCBDEAL.UNLOAD
shapes(3 files) Note:- ICMS is descoped because Unisure is dealing with Existing
Business whereas ICMS is dealing with New Business
For future enhancement, We are just loading data up to Stage
Unisure to The extract will transmit the below 20 files on a monthly basis
valuation NUWJL.FTP.UN.MHLY.FILE01.CRExxxxx.DEL500
inforce NUWJL.FTP.UN.MHLY.FILE02.CRExxxxx.DEL500
interface(20 NUWJL.FTP.UN.MHLY.FILE03.CRExxxxx.DEL500
files) NUWJL.FTP.UN.MHLY.FILE04.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE05.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE06.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE07.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE08.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE09.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE10.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE11.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE12.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE13.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE14.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE15.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE16.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE17.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE18.CRExxxxx.DEL500
NUWJL.FTP.UN.MHLY.FILE19.CRExxxxx.DEL500

Bits ID: 2013HW70753 Page 30 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

NUWJL.FTP.UN.MHLY.FILE20.CRExxxxx.DEL500
NUWJL.FTP.UN.WKLY.CRExxxxx.DEL500
The extract will transmit the below 3 files on a monthly basis
Asset share NUVRP.PRODUS.P.PRICES.CREYYMM.INP.G0001V00
factors and NUVRP.PRODUS.P.SPRICE.CREYYMM.INP.G0001V00
W/P fund NUVRP.PRODUS.P.FTGIPP.CREYYMM.INP.G0001V00
ID's(5 files) NUVRP.PRODUS.P.FTGNG.CREYYMM.INP.G0001V00
NUVRP.PRODUS.P.FTGNGG.CREYYMM.INP.G0001V00

The Inforce and Movement files come in two sets, one set without headers and footers until
August – 2009 and would be termed as Pre-DFR files the files that arrive after August -2009 will
have headers and footers and would be termed as POST DFR files and the files would be
processed by two different ETL processes.

8.2 Extract Process

Once all the data files are available on the ETL server, the files will be connected to the
Informatica source components and then processed further.

8.3 Staging Source Data

Input data will be staged within a dedicated set of database inbound staging tables within the
Persistent Actuarial Data store staging schema.  The staging tables will need to be able to store
at least two entire versions of the source data in order to allow change data capture and
movement detection.

The metadata stored in the staging tables facilitates the identification of the source file and
batch identifier from which the policy got loaded.

Using Transformation logic (based on assumptions made out of available UNISURE SAS code,
and validated by CUSTOMER) the 3 UNISURE source extract files provided in section 13.1 of this
document will be merged and 10 data sets will be created. These data sets will be stored in
intermediate tables for further processing to PAD.

The Inbound stating tables are:

 WH_STG_UNISURE
 WH_STG_UNISURE_ICMS_DLEL
 WH_STG_UNISURE_ICMS_DEAL
 WH_STG_UNISURE_ICMS_CNDL

Bits ID: 2013HW70753 Page 31 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

 WH_STG_UNISURE_MOV
 WH_STG_UNISURE_ASF_GNGG
 WH_STG_UNISURE_ASF_GIPP
 WH_STG_UNISURE_ASF_GNG

 The Intermediate tables are

 WH_STG_UNISURE_POL
 WH_STG_UNISURE_INCCOV
 WH_STG_UNISURE_BENCOMDA
 WH_STG_UNISURE_ASSNG
 WH_STG_UNISURE_UNTS
 WH_STG_UNISURE_ICMS
 WH_STG_UNISURE_ASH_FCTR
 WH_STG_UNISURE_FPHA_AGR_PRMM
 WH_STG_UNISURE_AGR_BNFT

In the process of loading the data from inbound staging to intermediate tables the data is split
and grouped which is discussed in detail in the Data Mapping sheet in section 15.

8.4 Source Data Dictionary

The below mentioned provides the source data dictionary. This data dictionary is created from
the UNISURE source layouts.

Code
Variable Source Name
polref Policy number *
inrref Increment reference *
covref Coverage reference *
prdref Product ref
prdref Product ref
prdvr_no Product version no.
schemeno Scheme number
prefix Prefix
territ Territory
p_lcon Life contingency

Bits ID: 2013HW70753 Page 32 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

currdta Policy currency date

currdta Policy currency date
currdta Policy currency date
surname1 Surname
dob1a DoB
sex1 Sex
smkr1 Smoker
distchan Distribution channel
agt_type Agent type
agid Agent code
element Element Type
serps_t SERPS Type
bencomda Benefit Start Date
bencomda Benefit Start Date
benamt1 Benefit amount
matdta Maturity Date
alloc Allocation Type
premtype Premium Type
premstat Premium Status
freq Premium Frequency
premium Premium Amount
premium Premium Amount
prmcsdta Premium Ceasing Date
prmindex Premium Indexation
indemnyt Indemnity Indicator
i_enhanc Initial Commission Enhancement Rate
incomrte Initial Commission Enhancement Rate
r_enhanc Renewal Commission Enhancement Rate
eiloc EILOC code
fund_bc Fund Based Commission Rate
purch_da Purchase date
cal_yr Calendar year of unit purchase
polfeew #N/A
commrate Commission Rate
comforpc Commission Foregone Percent
polfee Policy Fee *
wvrprem Policy Fee Waiver *
al_rate1 Allocation Rate 1
al_rate2 Allocation Rate 2
al_rate3 Allocation Rate 3

Bits ID: 2013HW70753 Page 33 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

al_rate4 Allocation Rate 4

al_per1 Allocation Period 1
al_per2 Allocation Period 2
al_per3 Allocation Period 3
al_per4 Allocation Period 4
basetafc Base TAFC
pclautro % of Lautro
commtype Commission Type
afcsign Total AFC Sign
age_adj Age Adjustment Rating
Weighted Explicit External Fund Manager Charge
eefmc (EEFMC)
sunits #N/A
fbcend_da FBC End date
fbcfreq FBC Frequency
fbcstrt_da FBC Start date
occlass Occupation class
termfact Term Factor Rate
indemi Indemnify Indicator
comshape Commission Shape
chgdur Charge Duration
agepay Age / Payment Factor
prntschm Parent Scheme Reference
baseterm Secondary Base TAFC
secondaf Secondary Charge Start Date
elec_result Wagner Voting Status
elec_numbe
r Wagner election id
agtyp Original Agreement Type Code
agtyp Original Agreement Type Code
apwfreq #N/A
apwamnt #N/A
apwdate #N/A

Bits ID: 2013HW70753 Page 34 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

8.5 Identify the Movement Logic

Movements will be captured by comparing the current extract against the previous extract,
rather than from source-supplied transactions. Staging at any point of time will hold one month
of history extract to allow comparison of two sequential extracts.

The Activity table (WH_PAD_ACTVTY) will hold all the data related to movements for a
particular policy. The data mapping sheet for the target WH_PAD_ACTVTY table contains details
of how to populate this table.

Bits ID: 2013HW70753 Page 35 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

9 Database Overview

A fully comprehensive overview of the database is covered in the Physical Design Model (PDM)
document. The following are the list of the tables that are applicable for the source to PAD
macro design of UNISURE.

Table Name Description

WH_PAD_AGRMNT_ACTVTY_RLTNS
HP Activity Agreement Relationship
WH_PAD_AGRMNT Agreement
WH_PAD_DIMENSION_MSTR Dimension Master
WH_PAD_FNCL_PRDCT_HLDG_AGR Financial Product Holding
MNT Agreement
WH_PAD_FPHA_SUPP FPHA Measures
WH_PAD_KY_LKP Key Lookup
WH_PAD_PARTY Party
WH_PAD_PSN Person
WH_PAD_RLTNSHP_MSTR Relationship Master
WH_PAD_FND_AGRMNT_RLTNSHP Fund Agreement Relationship
WH_PAD_UNT_PRICE Unit Price
WH_DATE Generic date dimension
WH_PAD_LDG Load details
WH_PAD_AST_SHR_FCTR Asset Share Factors
Asset Share Factors for
WH_PAD_AST_SHR_MVMNT movements

Bits ID: 2013HW70753 Page 36 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

10 Data mapping and business rules

This section will have a mapping sheet which will provide the following mappings

 Staging Table Mapping

 Agreement Table Mapping

 Party Table Mapping

 Person Table Mapping

 Financial Product Holding Agreement Table Mapping

 Financial Product Holding Agreement Supplementary Table Mapping

 Agreement Activity Table Mapping

 Relationship Master Table Mappings

 Asset Share Factors Table Mapping

 Loading Table Mapping

In the mappings, Extract Date is the last day of the month for which extract is provided. For
example for August 2017’s extract date is 31/08/2017, for September 2017 it is 30/09/2017.

Bits ID: 2013HW70753 Page 37 of

38
SEWPZG628T – Dissertation Finance Transformation – TARDIS

Plan of Work:

No
Planned
of Specific Deliverable in terms
Tasks to be done Duration Status
task of project
(Weeks)
s
Requirement
1 2.5 IFAD’s, Solution design Completed
Gathering

2 Analysis & Design 2.5 Design Doc & Mapping sheets Completed

Test case and plan

3 1 Test cases Completed
preparation
3 Build & Unit testing 3 Unit tested code & UTC Work in Progress
Acceptance test results and
4 System Testing 4 Work in Progress
Quality test results
Deployment & Implementation plan &
5 1 Work in Progress
Implementation Deliverable code
6 Documentation 2 SOP’s & SHS, User manuals Work in Progress

Bits ID: 2013HW70753 Page 38 of

38