On Hierarchy of Actuarial Objects: Data Processing from the Actuarial Point of View

Aleksey Popelyukhin, Ph.D.SVP, Technology

samsebe@consultant.com

Sam Sebe LLC

Credo

Statement:Actuaries deserve a convenient tool based on the latest computer technology

Proof: Actuaries are computer literate enough to use

and enjoy well integrated software solution Actuaries did a good job standardizing their

algorithms and data structures Competitive and regulatory pressures require more work to be done faster Other professionals have it

1

Ideal Actuarial System

An ideal data processing solution is a a) transparent to users b) highly efficient storage/retrieval system for c) structured actuarial data (objects) with d) an extremely flexible e) computationally complete f) open calculation engine …

2a

Ideal Actuarial System

... that is, a system which speaks “actuarese” and makes it very easy to express actuarial algorithms and very hard to make mistakes.

The paradigm where goals of abstraction, flexibility, simplicity and reliability

can be easily achieved is Object-Oriented model. 2b

OO computer system

What actuaries have to do about it: Demand it! Communicate specs to software engineers

Classify Actuarial Data Objects Classify Actuarial algorithms

Maintain and constantly improve it Use it and reap enormous benefits

3

Object Orientation

No system can be called object-oriented unless it supports encapsulation (“code and data together”)

inheritance (“new features without rewriting old code”)

polymorphism (“same algorithm for different types of objects”)

OO databases add requirements for persistence (“objects exist even after program stops”) identity (“way to differentiate objects and guarantee their

uniqueness”) 4

Main Statement

Any relationship (“parent-child”) generates a hierarchy Any equivalence criteria (“same-different”) generates

factorization

That is exactly our situation: Inheritance and polymorphism call for class

(“internal”) hierarchy, while the identity required by an OO database

calls for object (“external”) hierarchy 5

Data Objects

chunks (arrays) of structured data, each chunk with its own set of properties 6

AY\Age 12 24 36 48 60

1994 84,454$ 75,305$ 80,885$ 78,853$ 78,444$

1995 83,733$ 84,911$ 82,703$ 73,172$

1996 86,663$ 79,998$ 78,021$

1997 83,581$ 81,435$

1998 79,235$

<Client>: XYZ<State>: CT<LOB >: WC…

Losses

AY\Age 12 24 36 48 60

1994 84,454$ 75,305$ 80,885$ 78,853$ 78,444$

1995 83,733$ 84,911$ 82,703$ 73,172$

1996 86,663$ 79,998$ 78,021$

1997 83,581$ 81,435$

1998 79,235$

<Client>: XYZ<State>: CT<LOB >: WC…

ALAE

AY\Age 12 24 36 48 60

1994 84,454$ 75,305$ 80,885$ 78,853$ 78,444$

1995 83,733$ 84,911$ 82,703$ 73,172$

1996 86,663$ 79,998$ 78,021$

1997 83,581$ 81,435$

1998 79,235$

<Client>: XYZ

<State>: CA<LOB >: WC…Losses

Data Objects categories

How can we tell these 2 “triangles” apart?

7

1. These are not Triangles at all (Shape)

2. Cumulative vs. Incremental (CurrentState)

3. Worker’s Comp vs. Auto (LOB)

4. NorthEast vs. SouthWest (Regions)

premiums

factors

1 1 12 2 3

1 2 32 4 3

WC

AL

(total)NE

(total)SW

4 kinds of categories

While some categories reflect an “actuarial nature” of the object, others are used just to distinguish similar object of the same “nature”.

There are 4 major kinds of categories: 1. Those which define object’s place in a class hierarchy (class attributes)2. Those which define object’s state3. Those which serve identification purposes (dimensions)4. Those used for grouping within dimension (generations) 8

“Internal” hierarchy

9a

Actuarial Object

Actuarial Array Actuarial Method

Row Column Triangle

UltimateInflation DiagonalDiagonals

Counts

Open

Ratios Dollars

Closed Loss ALAE

“External” hierarchy

9b

Regions LOB

States AL GL WC

UW YrsNorthEast

CT

1998

NJ

1998

NY

1997

1998

SouthKS

1998

TX

1997

1998

1st rule of thumb

To determine which hierarchy (“internal” or “external”) an actuarial category belongs to, consider How it will be used:

A. whether or not different members of this category need different algorithms to process them {“Counts” and “Dollars”} vs. {“NY,” “NJ” and “CT”}

B. whether or not different members of this category affect the way algorithms are applied {“Cumulative” and “Incremental”}

C. whether or not members of the category are used to define groups for possible aggregation into subtotals {“NorthEast” and “SouthWest”} subtotals “Locations”

10

Functional Classes

Classes in OO application can be used for different purposes. Classes with the principal responsibility of maintaining

data information are called abstract data types (“Data Objects”) or data managers.

Classes with the principal responsibility of assisting in the execution of complex tasks called functional classes (“Engines”) or facilitators.

The distinction between abstract data types and functional classes is somewhat similar to the distinction between nouns and verbs in a sentence. 11

2nd rule of thumb

To decide which actuarial operation belongs to the data object (i.e., has to be implemented as a method in the abstract data type) vs. functional class, consider: A. whether or not the algorithm is subject to future modification(s)

always the same “accumulation of the triangle” vs. always improving“calculation of the tail factor”

B. whether or not it is generic or specific “summation of any two triangles” vs.“annualization of the inflation rate”

applicable only to inflation vectorC. whether or not it is interactive (user interruptible)

automatic “extraction of the last diagonal” vs. “loss development method”, which requires user selection

12

Implementation

Possible design of an Ideal Actuarial System may include the following tasks: actuarial data arrays can be implemented as a hierarchy of

abstract data types actuarial methods can be wrapped into functional classes persistence can be achieved by storing objects in an Object-

Oriented (or Object-Relational or just plain Relational) Database links to Actuarial Data Mart can be added to import object’s data

and to export results of analysis a flexible user interface can be added to finalize construction of

the OO actuarial system 13

Illustration-syntax

(Spreadsheet)

=(sum(C35:C39)-max(C35:C39)-min(C35:C39))/3

(OO)

AgeToAgeFactors.Average (Type:=ExclHiLo, _ LastDiagonals:=5)

14a

Illustration-abstraction through encapsulation

cell (i, j) of the triangle maps to cell k = (i + j - 2)(i + j - 1)/2 + i of the 1-D array

14bthis space-conscious arrangement doesn’t affect user or program

AY\Age 12 24 36 48 60

1994 112,605$ 100,406$ 107,847$ 105,138$ 104,592$

1995 111,644$ 113,215$ 110,271$ 97,562$

1996 115,551$ 106,665$ 104,029$

1997 111,442$ 108,581$

1998 105,647$

AY\Age 12 24 36 48 60

1994 112,605$ 100,406$ 107,847$ 105,138$ 104,592$

1995 111,644$ 113,215$ 110,271$ 97,562$

1996 115,551$ 106,665$ 104,029$

1997 111,442$ 108,581$

1998 105,647$

1 2 4 7 113 5 8 126 9 13

10 1415

1 2 4 7 113 5 8 126 9 13

10 1415

112605$ 100406$ 111644$ 107847$ 113215$ 115551$ 105138$ 110271$ 106665$ 111442$ 104592$ 97562$ 104029$ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 151 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Illustration-inheritance

Triangle is a Matrix (Range) with a few extra Properties and Methods: DiagonalsToColumns DiagonalsToRows RowsToDiagonals ColumnsToDiagonals DiagonalToVector(DiagonalNumber) VectorToDiagonal(DiagonalNumber) LastDiagonal 14c

Illustration-inheritance (cont.)

DiagonalsToRows 14d

112,605$ 100,406$ 107,847$ 105,138$ 104,592$ 112,605$

111,644$ 113,215$ 110,271$ 97,562$ 111,644$ 100,406$

115,551$ 106,665$ 104,029$ DiagonalsToRows 115,551$ 113,215$ 107,847$

111,442$ 108,581$ 111,442$ 106,665$ 110,271$ 105,138$

105,647$ 105,647$ 108,581$ 104,029$ 97,562$ 104,592$

Average of the last 3 Diagonals Average of the last 3 Rows

(easier to implement)(harder to implement)

Illustration-engine

Loss Development (Chain-Ladder) Method:

EstimateOfUltimate = InputTriangle.LastDiagonal(asColumn) * _ UserSelectedFactors (default:= InputTriangle.AgeToAgeFactors.Average(Medial, 5))

14e

Recommended Reading

1. David Brown. An Introduction to Object-Oriented Analysis. Objects in Plain English. 1997, Wiley

2. Mary E.S. Loomis. Object-Oriented Databases: The Essentials. 1995, Addison-Wesley

3. Michael Bhala, William Premerlani. Object-Oriented Modeling and Design for Database Applications. 1998, Prentice Hall

The Whole Picture

Watch Your TPAWatch Your TPAA Practical Introduction to Actuarial Data Quality Management, 1997A Practical Introduction to Actuarial Data Quality Management, 1997

On HierarchyOn Hierarchyof Actuarial Objectsof Actuarial ObjectsData Processing from the Actuarial Point of View, 1998Data Processing from the Actuarial Point of View, 1998

Let Me SeeLet Me SeeVisualization and Presentation of Actuarial Results, 1999Visualization and Presentation of Actuarial Results, 1999

The Big PictureThe Big PictureActuarial Process From the Data Management Point of View, 1996Actuarial Process From the Data Management Point of View, 1996