For administrators, DB scheme closures have become routine and there are ‘three Cs’ that summarise much of the required activity; calculation, communication and crystallisation. However, despite all the experience and practice the industry has had in managing scheme closures, some common administration mistakes still crop up.

Like marriages, splits rarely result in a clean break, and pensions are no exception. When DB schemes close to accrual, the inevitable next step is for members to start building benefits through a defined contribution (DC) arrangement. And, with contract-based DC membership now outstripping that of occupational trusts, members will probably be set up with a whole new set of records with a separate organisation.

Sounds simple, but the realities of supporting members, delivering against negotiated settlements and providing flexible options means that few schemes and sponsors ever get a clear split between DC and DB accrual.

When DB scheme closures first started, it was commonplace for the DB administrator to be asked to maintain communication with members of the DC arrangement to preserve continuity. Many employers felt that their employees would benefit from a single point of contact for all of their pension enquiries, thereby making the transition to a new type of arrangement simpler and more cohesive. While administrators readily accepted this challenge (for an additional fee); for many schemes the result has been a disjointed, slow and frustrating experience for administrator and member alike.

Without access to the underlying data and the ability to manage it first-hand, DB administrators become nothing more than a post-box. This results in messages being passed back and forth between the member and the insurer, which often only adds to response times. Few front-line administrators who do this would say that they are truly delivering a value-added service and would likely argue that it is only the sponsor who benefits from this costly, single-point-of-contact approach.

To soften the blow of DB closures, many sponsors and trustees have looked for creative ways to link and consolidate the new and old worlds. Permitting DC to DB transfers-in at retirement or allowing the use of DC funds to supplement scheme cash are just two of the conventional methods adopted to provide cohesion across a member’s total reward package. But with so much focus and emphasis going into completing the closure process and setting up the new scheme, very few administrators have ever looked at implementing robust procedures to effectively handle this ever-more-common event.

Any interaction between multiple agents requires careful planning. Investment must be made in automated interfaces that can secure and ease the flow of information between parties. Often, this doesn’t happen at the end of a development lifecycle for a DB scheme.

At the point a DB scheme is closing, the administrator is usually focussed on ensuring that the final significant member transaction completes successfully and accurately. Specifying and building new interfaces and processes with a new provider is somewhat of a rarity, with ad-hoc manual processes usually fulfilling the short-term need. Without the investment in these solutions, member processes will suffer, culminating in delays, errors and omissions.

Ill thought-through or rushed post-closure operations will be costly in the longer term. Members will pay the price with delays and errors, sponsors will spend too much for a service that doesn’t add any value and trustees won't benefit from an efficient low-risk operation. Schemes that have already closed as well as those about to embark on this journey would all benefit from reviewing how the old world interacts with the new.