grs valuation module - introduction course october 2012 michael pierce brussels

GRS Valuation Module - Introduction Course

October 2012

Michael Pierce

Brussels

MERCER 222 April 2023

Two Day Plan

• We assume you have– Some understanding of valuation calculations – familiarity with Windows and Excel

• Our approach – introduce programming screens one by one– provide opportunities for hands on experience – allow ample opportunities for questions


Agenda

• Liability valuations

• What is GRS and why do we use it?

• Hierarchy ideas

• Data programming screens

• Tables Tool

• Liability programming screens

• Excel output file

• Sample scheme programming

• Reviewing output

• Where to get more help


Basic Liability Ideas


Basic Liability Ideas

• What do we need to value liabilities

– Data– Benefits structure (rules)

Also need …….

– Assumptions– Tables

Use these to calculate benefit

amounts

to put a present value on these

benefit amounts {

{


Data

• Demographic data– Date of births, date of hires, sex……..

• Financial data – Salaries, contributions, pensions….

• Identifiers– By types - Active, deferred, pensioner– By groups - Exec versus staff etc…– By individual - EEID


Benefit Structure

• From Plan Rules or members’ booklet

• How do we calculate? Eligibility Service Pensionable salary Retirement benefits Death benefits Ill health benefits Withdrawal benefits


Typical benefits

• Using the data provided and the rules of the scheme for each member we can calculate benefit amounts accrued like the following typical benefits:– Retirement benefits

15% * Salary * Service

– Death benefits 4 * Salary


Assumptions

• What kind off assumptions will we need to value benefits?– Economic

Discount rate (i) Salary increases (e)

– Demographic Salary Scale Percentage married Spouses age difference Pre and post retirement mortality if applicable Ill health retirement mortality


Assumptions continued

• Level of retirements – may be a range

• Level of ill health retirements

• Level of withdrawals


Tables

• Where assumptions are different at each age tables are more efficient.

– Mortality– Salary scale – Retirement– Ill health – Withdrawal


Standard Liability Calculation Formula

• Recall your Actuarial Calculations experience:

PV = tPx * decrement * vt * benefit


Member Pensioner

• Formula for a member pensioner would something like:

– PV = Pension * ax + Spouses pension * ax/y


Active Member

• Formula for an active member in an on going valuation would be something like:

PV = Accrued benefit * (1+ e) (NRA – x) * v (NRA – x) * tpx


GRS

– In short - its an organised efficient tool with more powerful calculation and peer review capabilities

– A lot more detail later!

– GRS is new to you, so it’s easy to get lost in different screens but try not to just tick boxes etc - think about why each screen is necessary

– remember that basic calculations are the same; GRS is just a tool to help you specify all of the elements of the calculation


What is GRS and why do we use it?


What is GRS?

• Global Retirement System

• Mercer’s global tool– maintain databases – value liabilities – produce valuation reports

• Windows based system – parameter screens to define benefits– simple programming language– output written to Excel spreadsheets


Advantages of Using a Global Tool

• Consistency in approach for global clients

• Domestic clients benefit from an efficient process

• Mercer itself benefits– consistent capability “promoted” to external market– facilitates transfer of people / work– reduces E&O exposure

• Allows for consistent Funding, Accounting and Solvency valuations


GRS Modules

• 5 Modules, or sections of GRS– Data– Assets– Valuation– Cost – Reporting

• Various modules in use around the world

• Our focus will be on the Valuation module


Hierarchy Ideas


Hierarchy Ideas

• Organising of client files is done by GRS

Part to Organise Part of GRS

Clients and specific schemes

Client and Plan

Various projects (and date done at)

Component

Type of member being valued (active vs. inactive)

Data Group


Hierarchy IdeasClients, Plans, Components, Scenarios & Events

Client

Plan 1

Plan 2

Component 1

Component 2

Scenario 1

Event 1

Active Data Group

Inactive Data Group

Event 2

Active Data Group

Inactive Data Group

Scenario 2


Hierarchy Ideas

Go to GRS for screen walk-through


Data Programming Screens



• GRS needs member data in order to calculate liability results– where data is coming from– how data file is organized (what data is included)– output options

• Need to set specifics for each Data Group– actives– inactives


• 4 parameter screens relate to data– Data Layout– Individual Output– Test Cases– Future Valuation



Data Programming ScreensData Layout

• Data source (data module or DOS file) and precise location

• What data is in that file

• Data Group Key– if more than one Data Group is using same source, flag to show

who belongs in this group

• Subtotal Breaks– (optional) request for additional breakdown of output


Data Programming ScreensData Layout - GRS Specific Data Fields

• Certain fields needed for GRS to run data (not necessarily needed when working in Excel)

ETY / ELY Status codes

EEID Unique employee identification number

EBIRTH Member’s date of birth

EHIRE Date joined company (actives only)

ERETIRE Retirement date (inactives only)


Data Programming ScreensData Layout - GRS Specific Data Fields

• Standard names for some other common GRS data fields

ESEX Member’s sex (M or F)

EMEMB Member’s joining scheme date

PAYyyyy / SALyyyy Earnings information, by year

ETEST Test case indicator


• Request additional output file – not automatically created

• Results provided on an individual member basis

• Request specific results, e.g.– accrued liabilities– normal cost– pensionable earnings– accrued benefit, etc.

Data Programming ScreensIndividual Output


Data Programming ScreensTest Cases

• Part of Excel output file is a detailed summary of calculations for selected individuals

• This is where you define how those individuals will be picked from the date file– from flag (ETEST)– specific member (provide EEID)– first records on file (not recommended)

• Useful to pick someone who was a test case last time for comparison purposes


Data Programming ScreensFuture Valuation

• Used only when running a future valuation

• Not in the scope of this course


Tables Tool


Tables Tool

• Library of tables that can be reference elsewhere in GRS– tables used for various decrements or factors– use tool to add, modify, or view tables

• Accessed through “Tables” menu in GRS

• Vary by class and type– class: who can modify / add them– type: what decrements you can use them for

• Opens up an Excel tool so you can use cut/paste functions and formulas when creating new ones (or if you want to use table outside of GRS)


Tables ToolClass of Table

• 3 classes of tables– National– Office– Client

• Only GRS supervisors can modify National and Office tables

• Anyone with access to that client can modify Client tables

• Examples:MR/FR - National mortality table

Willy - Withdrawal tables


Tables ToolType of Table

• Type of table is important when it comes to its use– E.g. when selecting a mortality table for use in your run, GRS will

only give you a list of “mortality” tables to pick from

• Many types, including:– death decrements– withdrawal decrements– salary scale by service– general by age– two dimensional


Tables Tool



Liability Programming Screens



• In order for GRS to calculate liabilities, you need to define – benefit structure (what kind of benefits are being valued)– benefit definitions (components like service, formula, pension form)– assumptions – projections– how to combine above into benefit values

• Need to define coding for each Event & each Data Group– some coding may overlap between data groups– some coding may overlap between events



• 5 screens for coding liability calculations– Benefits / Decrements– Building Blocks– Define– Liabilities Needed– Plan Infrastructure

• Note that coding for building blocks is shared for all Events in the same Scenario– NEED TO BE CAREFUL


Liability Programming ScreensBenefits / Decrements

• Define structure of decrements to be used and benefits to be valued– RET, WTH, DIS, & DTH (pre and post retirement)

• Define decrements (tables)– attach tables for each decrement– indicate time frame over which to apply the decrement table

• Define benefits valued under each decrement– start and/or stop ages for benefits– adjustments (e.g. early retirement factors)– form of payment (includes annuity/lump sum, cost of living -

escalation)


Liability Programming ScreensBuilding Blocks

• As the name indicates, building blocks are key definitions used in other areas of programming

• IMPORTANT– Building Blocks are shared across Events and Data Groups (if

applicable)– need to ensure changes to these are done carefully so as not to affect

other runs (Events)



• There are 11 in total but the key ones used in Ireland are:– Age / Eligibility– Service– Annuity– Cost of Living– Salary Scale– Two-dimensional table



• Data Subgroups– different members of a scheme may have slightly different benefit

provisions although their benefits are substantially the same example: execs get service from EHIRE, staff from EMEMB

– for certain Building Blocks you can code one definition but have multiple “sub definitions” to allow for those minor differences

– ALWAYS use data subgroups if you can; if you can’t accommodate the difference with subgroups or on the define screen, then use a second data group

• Building Blocks that can have data subgroups include age/eligibility, service, annuity (inactives only), and salary scale



• Age / Eligibility – define key criteria based on age, service, and specific dates – used to specify start/stop ages for benefits and decrements– example: vesting, earliest retirement age, normal retirement age

• Service– calculate service based on elapsed time from member dates (e.g. DOH

or DOJS), data field, and beginning or ending dates– also define how future service is assumed to accrue

• Salary Scale– flat rate or table



• Annuity– form of payment (annuity or lump sum)– immediate or deferred– guarantee periods– assumptions on marital status and spouse age– mortality (pre and post retirement)– cost of living adjustments to apply

• Cost of Living– revaluation and / or pension escalation– may or may not be included in annuity definition


Liability Programming ScreensLiabilities Needed

• What kind of liabilities to calculate – funding, solvency, FAS 87– can run one of each in the same run although we don’t advise running

funding and solvency together as a separate solvency event is required when programming a funding proposal

– Hopefully you won’t have to worry about funding proposals for a while

• Define interest rate and salary scale to be used for each liability type

• Additional tabs for future valuation as well– again, beyond scope of today


Liability Programming ScreensPlan Infrastructure

• Miscellaneous assumptions and methods

• Mandatory retirement assumption (age and/or service based)

• Default marital assumptions (age of spouse and % married)


Liability Programming ScreensDefine

• 3 sub tabs:– Define Benefit– Define Solvency – Output Fields

• Only area of GRS Valuation Module where basic programming knowledge is needed


Liability Programming ScreensDefine Benefit side-tab

• Used for Funding and Accounting runs

• Main function of this screen is to assign values to each benefit defined on Benefit Structure tab– RET01, RET02, DTH01, etc. for actives– BEN01, BEN02, etc. for inactives

• This is done with “free form” coding, using a number of tools:– special calculations– functions– logic



• Special calculations are designed to simplify common components of the benefit definition. Most commonly used are:– salary projection (actives)

specify data field (PAYnnnn or SALnnnn) and salary scale to project stream of future earnings

– salary averaging (actives) if benefit is based on final average salary, define how average

should be calculated calculates average salary in each future year based on salary

projection– benefit payments (inactives)

define stream of benefit payments

• Other special calculations include user defined projection, accumulation (for contributions), and final average benefit



• Built-in functions perform simpler common calculations, including:– Truncate– Round– Minimum

note that there are two ways to code the minimum of x and y MIN(x,y) - introduced with version 7.0.2 x < y - only way to code this prior to 7.0.2

– Maximum similar to minimum, can be coded as MAX(x,y) or x > y

– Age Range specify a single date or range of dates at which to calculate the

line of code Ex: TOTSERV = SERV ::: at NRA :::



• Last major tool to be understood is basic coding language

• Basic logical construct is IF/THEN/ELSE/ELSEIF/ENDIF– ELSE and ELSEIF are optional– can nest IF statements

• To compare two values, use the alphabetic operands (EQ, NE, LT, LE, GT, GE)

• To assign a value, use the mathematical operators (=, +, -, *, /, ^)

• Use boolean operators to combine statements (AND, OR, NOT)

• Use ** to add comments to code– important to document code thoroughly



• Sample define screen coding:

&SALPRJ01 - project pay

BFT = SALPRJ01 * SERV * .15

RET01 = BFT


Excel Output File


Excel Output File

• Excel file produced every time a run is completed – includes information for all data groups and all liabilities included

together in that event

• Names of tabs and what’s included are standard for every run

• Open up through GRS– View command on Event menu

• When viewing output, remember you are still in GRS environment. You MUST use OK or Cancel buttons or File -> Return to GRS to close output file. – if you want to manipulate file, save copy to client directory


Excel Output File

• Output divided into 7 main sections:– control totals

system values useful when checking– parameters

record of coding on each screen at time of run– results

statistics and liability totals– tables– test cases

very detailed trace of calculations for select individuals– individual output

selected results by individual member


Excel Output FileControl Total Tabs

• Tabs: – Control Totals Summary– Parameter Control Totals– Data Control Totals

• Look quite cryptic but are actually very useful when checking runs– control totals are system value representing every character coded on

screen– for more information, see GRS intranet site

• Data Control totals shows you any records being dropped, errors


Excel Output FileParameter Tabs

• Summarise assumptions and programming calculations used

• Tabs:– Scenario Info– Event Info– Building Block Info– <Data Group> Group Info (one for each data group)


Excel Output FileResult Tabs

• Statistics, various types of liabilities and service cost

• Tabs:– Valuation Summary– Statistics (by data group and breaks)– Liabilities (by data group and breaks)– FAS 87 (by data group and breaks)– Output Fields (by data group and breaks)

• Valuation Summary tab – one page summary of the key statistics and liability results

• FAS 87 & Output Fields tabs will not be produced automatically– need to run FAS, or– ask for specific result output


Excel Output FileTables Tabs

• Record of all tables and their values used in the run

• Usually too large to print out


Excel Output FileTest Cases Tabs

• One tab for each member, for each liability type as requested on Test Case Output tab

• Detailed record of liability and normal cost calculations for each benefit

• Can be overwhelming at first, but fundamental checking tool


Excel Output FilePrinting Options

• Straight from Excel– usual methods

• Print GRS Val Output– can be accessed from File menu or from Val Results Explorer– use checkboxes to select which tabs (and portions of tabs) you want to

print– automatically adds headers and footers and formats output


Excel Output File

Go to output walk-through


Sample Scheme Programming (Tips)


Sample Scheme Programming

• Best way to learn GRS?– get your hands dirty!


Sample Scheme Programming

• Quickly review– Data– Assumptions– Benefit Definitions– Programming

• You should now see where all these pieces are fitting in– Active vs. Inactive Data Groups– Data screens– Liabilities screens


Sample Scheme ProgrammingProgramming Checklist

• When coding from scratch, best to– follow a particular order– give some thought to how client benefits are defined– have a summary of data and benefit definitions on hand

• This checklist helps to give some order to programming


Reviewing Output


Reviewing Output

• Programming is only one part of the process

• Getting reasonable and sensible results in another!

• Will touch on– errors and warning messages– control totals (output file)– test cases (selection and checking)– general liability checks


Reviewing OutputErrors and Warning Messages

• Produced before actual run starts– Gives data group and programming screen where error is found– Gives a bit of a standard message to explain problem

• Can run event with “warnings” (but may not want to!)

• Can not run event with “fatal errors”

• Need to trace back to programming to double check if error is seen

• May initially think coding is fine– will come with experience– may also come with a fresh eye– Best to look at it yourself first and then ask co-worker for help


Reviewing OutputControl Totals

• These are a quick way to spot changes or errors

• Data control totals– will spot if correct number of members were run– will check various data fields for errors (layout may be off)

• Parameter control totals– only useful for comparing different runs– will pin-point where change was made– key tool used by people checking your work


Reviewing OutputTest Cases

• Whole session on its own, but basically– is data read in properly?– can you match results of annuities, decrements, projections etc.– are flags and programming on Define screen working as expected– can you follow PV calculation

• Need to select proper members for checking– especially if multiple definitions or formulas depending on member group

• Various tools for checking– decrement checker spreadsheet– annuity tables or Actuary add-in – calculator!


Reviewing OutputGeneral Liability Checks

• Need to know ball-park of results expected– thousands, millions, billions?

• Need to check each liability total (by benefit type) – are any blank?– Aggregate should be > Accrued– are any Aggregate and Accrued values the same?

• Need to check normal cost totals as well– in line with method (PUC - 1 year cost, Attained Age - all future service

cost)


Reviewing Output

• More rules of thumb and standard checks– will come with time

• Best to ask whoever is checking your work– understand what they are checking – ask for expected change in results if they are asking for multiple runs

(assumption changes especially)

grs valuation module - introduction course october 2012 michael pierce brussels

Documents