So why not eliminate the notion of underlying annuities by introducing a new plan design that has both DB and DC characteristics? Under the new design, plan members would receive lump sums at retirement rather than annuities. These lump sums could be determined as a given multiple of pay. For example, an employee retiring with 30 years of service might receive a lump sum equal to three times final pay. Retirees could transfer the lump sum to a Life Income Fund(LIF)and use it to generate an income stream after retirement, just like they do already in DC pension plans.
In a variation of this idea, the existing DB pension formula would be retained but members would receive a commuted value at retirement rather than a monthly pension from the employer. The critical feature in this scheme is that the commuted value would be calculated using a long-term discount rate that is set by the regulators. This rate would reflect the long-term return that a reasonably conservative balanced fund could expect with a small margin of conservatism. For instance, the rate could be set at 6% with the idea that it would change infrequently if at all. This same rate would then be used for accounting purposes as well and would eliminate much of the existing volatility in pension expense. Under this variation, the concept of an annuity is not entirely extinguished but the volatility that employers are so eager to avoid can be eliminated by government decree.
With either approach, employers would have a lot more certainty than under the current DB regime. Of course, some people will argue that this still leaves too much risk with employees. They will say it is dangerous to put large lump sums into the hands of new retirees and that a monthly pension is more prudent. The fact is, however, less than 30% of the private sector workforce is covered by a pension plan of any sort and the majority of those who are covered are participating in a DC plan that provides just such a lump sum. Employees under such a hybrid would be taking on some risk but not nearly as much as they do currently in DC plans and certainly far less than the many employees with no employer-sponsored retirement savings at all.
At a minimum, the Income Tax Act requires that registered DB plans provide level pension payments for life. Most DB plans go farther than that and provide pensions that increase periodically, either automatically based on increases in the Consumer Price Index or on an ad hoc basis.
The requirement to provide a level pension or an increasing pension is based on the premise that a retiree’s income needs never decline over his or her remaining lifetime. This is unlikely to be true. In fact, it can be argued that income needs grow for a while after retirement and then fall at very advanced ages, in real terms and possibly even in absolute terms.
Consider a retiree who is 60. In the years immediately following retirement, that retiree will likely be in relatively good health and may want to travel extensively or take up a new hobby. These types of activities will take money. Also, the retiree may still have children who have not yet left the house and who might need monetary support for a few years to come. None of these expenses are likely to be as much of a drain on the retiree’s resources at 85 as they are at 60. So why not allow DB pensions to fluctuate in retirement? For example, the pension might climb between 60 and 65, level off around age 75, and slowly decline after 80 or so.
The term “fungible” is defined as “being of such a nature that one unit or part can be substituted for another equivalent unit or part in discharging an obligation.” Gold is fungible. Money is fungible. Not DB plans, though. When you try to bring two plans together—say, following a merger or an acquisition—the pre-merger benefits need to be kept separate for the rest of time.
The same usually happens when a DB plan is amended. The only way past service benefits can be changed is if there is a retroactive amendment that improves the plan for all members and for all years of service. This is both costly and scarce these days as employers seek ways to save money, not spend it.
If the retirement system allowed employers the flexibility to change plan provisions retroactively(with some safeguards for members, of course), everyone would win. More flexibility is obviously a good thing for employers. It would also be good for employees because the current constraints on retroactive changes are counter-productive. While they may protect a benefit that has accrued, they make employers less willing to provide DB coverage at all.
The need to effect change retroactively has never been greater given that employers are trying to find ways to scale back their pension promises without adding complexity. It is best to give the employer the right to buy out pension promises that have become too costly. For instance, if a plan provided a 1.5% pension formula and the employer can only afford 1.2%, they should be able to direct their actuary to calculate the incremental cost of the pension accrued to date for each affected employee and to transfer an equivalent lump sum to the employee’s retirement account. Then the entire promise within the plan for past and future service would be based on the new 1.2% formula.
These three ideas have little in common other than they are all outside the realm of current pension thinking. It’s easy to blame governments for imposing rigid pension legislation that is out of step with the times, but have Canadian plan sponsors really done enough to promote out-of-the-box solutions and try to get them approved? The cash balance plan—a hybrid design that is acceptable in the U.S. but not in Canada—came into being because the private sector pushed for it. Plan sponsors should be bolder in their thinking and challenge the inevitable bureaucratic response that what they want to do can’t be done. If enough sponsors do this, maybe the pension system can get the real overhaul it needs.
Fred Vettese is executive vice-president and chief actuary with Morneau Sobeco in Toronto. firstname.lastname@example.org
For a PDF version of this article, click here.