QUESTION: My Valuation / Core Projection takes a long time to run. Are there ways to change my setup to make it run faster?

ANSWER: Yes, by using WinTech’s Grid Platform. The Grid Platform is a separate software product requiring a separate license. Without a license, ProVal will use up to 4 local processors. With a license, ProVal can use an unlimited number of local processors. In addition, a license allows the use of an unlimited number of grid agent processors on your network. See What's New in ProVal 3.04 for details.

In addition, there are some other techniques that can be used to speed up execution times:

1. Data: Group Data. Use ProVal's Group Data tool to compress seriatim data. Rerun your valuation with Grouped Data and then use ProVal's Scaling Factors tool to calculate scaling factors and ensure liability changes are within a tolerable level.

2. Data: Minimize New Entrants. The number of new entrant records greatly impacts core projection processing speed. Consolidate to as few new entrant records as possible and eliminate new entrant records with tiny weightings (e.g., Count=1 vs. other records with Count=1000).

3. Benefit formulas: Use Subformula components. If a certain computation on several components appears several times (e.g. “A + B #MAX C” appears in Retirement, Termination and Death benefits), then the underlying operations will occur several times. Placing this type of repetitive calculation in a Subformula component will speed processing, in addition to enhancing readability.

4. Benefit formulas: Avoid excessive #ELSEIF structures. If different benefit structures are combined using many #IF-#ELSEIF-#ENDIF types of statements (e.g. for different union locations or business classifications), then all of the underlying Benefit Formula Components will be calculated first before ProVal evaluates the benefit formulas and finds out that some of the components may have been unnecessary. Excessive #ELSEIF structures based on database fields should be broken into multiple Benefit Definitions when possible, using Selection Expressions to exclude as many records as possible.

5. Benefit Definitions: Remove excessive or immaterial optional forms. Each optional form coded in ProVal –either in its own, separate (i.e., a second), Benefit Definition or using the Optional forms parameter of the Benefit Definition (thus using only one Benefit Definition) – is functionally a separate Benefit Definition that requires evaluation. If any optional forms do not have a material impact on liabilities or cash flows (e.g., 5 year certain J&S as compared to J&S without a certain period), consider removing them.

6. Benefit Definitions: Minimize Post-decrement death benefits. Payment Forms of the “Post-decrement Death Benefit” type (in the U.S. qualified mode, typically used for “REA” benefits) are very computationally intensive for active records, requiring calculation of both decrement from active status and subsequent death before the benefit is triggered. If these payment forms are immaterial (especially for a Core Projection), removing them can improve runtimes. If they are retained, the parameter setting in the Payment Form that runs fastest is having the “beneficiary determined at” decrement.

7. Valuation Assumptions: Turn off unnecessary liabilities. In the U.S. qualified, Canadian registered and German pension modes, some liabilities (such as target, funding and Teilwert liabilities, in those respective modes) will always be calculated, but other liabilities will not be evaluated unless requested in the Valuation Assumptions. Turn off calculation of any liabilities that are not necessary for your analysis (for example, you may omit PBGC variable premium and actuarial liabilities in U.S. qualified mode, solvency liability in Canadian mode and PSVaG and additional liabilities in German mode).

8. Benefit formulas: Eliminate unnecessary lump sum factors. Lump sum factors are calculated “on the fly” during the Valuation / Core Projection process and take significant processing power. In addition, in the U.S. qualified or Canadian modes, if lump sum factors or optional forms are assumed to use underlying interest / mortality rates, they will be valued multiple times if several liabilities are calculated under different assumptions (e.g., target, PBGC and PUC liabilities may require three different calculations in U.S. qualified mode). If lump sum factors are based on fixed interest and mortality bases, they may be specified as Benefit Component Tables to save processing time. Also see #5 above.

9. Core Projections: Turn off unnecessary sensitivities. If you need just a baseline forecast of liabilities and don’t plan to vary inflation, interest or lump sum rates in a forecast, you could run only the baseline. Note that ProVal is smart enough to skip the lump sum sensitivities if they don’t apply.

10. Valuations (OPEB): Turn off + .01 / - .01 trend sensitivities. These trend sensitivities are frequently needed for accounting disclosure purposes and are run, by default, whenever accounting assumptions are used, but the Valuation will run substantially faster if they are turned off.

11. Valuations and Core Projections: Turn off unnecessary subtotals. ProVal accumulates subtotal results on disk. In comparison to using the computer’s memory (which is used to accumulate the grand totals), disks are much slower.

12. Valuations and Core Projections: Turn off projected benefit payments. In a Valuation with subtotals (see #9 above), turn off projected benefit payments (behind the Census Data button) if you aren’t going to need them. In a Core Projection, you can turn off projected benefit payments (behind the Sensitivities button) – either completely or just for sensitivities other than the baseline, except as required for certain calculations (e.g., PPA effective interest rates in US qualified mode).