Practice Management
There are many factors that can make administering a defined benefit plan complicated. One of them, argues a recent blog entry, is information that is missing or incomplete—and it has broad effects and consequences.
In “Addressing Problematic Defined Benefit Data,” an entry in Milliman’s Retirement Town Hall blog, Lisa Grove and Rebecca Coleman discuss how to address problems with DB data. Grove, Consultant and Senior Implementation Manager for the Milliman Employee Benefits Administration Practice, and Connell, Consultant and DB Implementation Manager at Milliman, argue that issues with data directly affect the efficiency of plan administration, and that while addressing them “can become overwhelming,” thoughtful action can not only mitigate them but even largely eliminate them.
Bad Data, Defined
Bad Data, Defined
What constitutes bad data, Grove and Coleman write, can be specific to a particular DB plan. Still, there are some problems that are common; for instance, they note, that for traditional as well as cash balance plans, there often are problems with:
- salary and hours data needed in order to calculate accruals; and
- employment status data needed in order to calculate service.
Grove and Coleman also note that in the case of plans that have existed for a long time, some data may only exist on paper. Also, they observe, some data can be lost when plans are merged into or divested from a plan, such as:
- historical participant indicators;
- grandfathered benefit amounts; and
- identification of deferred participants and vested amounts.
Challenges
It is not unusual for there to be problems with data, Grove and Coleman write. Part of the reason, they suggest, is the transition from data storage on paper to electronic formats. This, they explain, means that it is likely that the data has existed in many forms over the years.
Grove and Coleman suggest that it may be useful, when a plan sponsor or administrator is asked for an indication of what the state of the data is, to keep in mind that the data used in, and the results from, an actuary’s analysis are very different from calculations concerning individual participants. The difference, they say, arises from calculations done as part of the annual valuation used to determine plan liabilities—which are based on approved actuarial assumptions and are not designed to be exact—being very different from calculations concerning individual participants, which are based on the plan’s formula and the historical data concerning each participant.
Consequences of Bad Data
Accuracy of the data used for benefit calculations is critical, say Grove and Coleman, because participants rely on those calculations to help them make important financial decisions. If the data is not accurate, they warn, the consequences can include participants receiving inaccurate calculations when they are making benefit elections and receiving benefits models.
Addressing Bad Data
Grove and Coleman suggest that a good place to start in identifying where there is a problem with data is to look at annual valuation data. This data, they say, can be where to start in determining what information might be missing or incomplete and should list participants:
- actively accruing a benefit;
- with a deferred benefit; and
- currently receiving a payment from the plan.
Valuation files also can be a help, Grove and Coleman say, by extracting data used in the calculations by which those valuations were derived.
Actuaries also can have a role, say Grove and Coleman, by:
- documenting assumptions used;
- indicating the underlying data needed for calculations that is missing; and
- provide direction on how to determine a value for participants for whom there is incomplete data.
Review of data also can identify administrative errors that may have resulted in participants being lost or the need to use voluntary compliance programs.
“Spending the effort to address data issues provides confidence in ongoing administration of the plan and will allow for more accurate valuations in the future,” Grove and Coleman argue.
- Log in to post comments