Administration of defined contribution schemes (DC) is often quoted as being easy or simple when compared to their more mature defined benefit (DB) counterparts. “It’s just like running a bank account” and “all you have to do is multiply one number by another,” are two of the most common remarks associated with administering this type of arrangement.
The misconception about the perceived simplicity of administering DC schemes is borne out of three beliefs. The first is the comparative conceptual simplicity of DC; it’s easier to explain to members, at least in accumulation phases, than DB. And, because it’s easy to explain, it must be easy to administer. The second is that technology has performed much of the heavy lifting from an early start, removing the possibility of error or risk from the process. And thirdly, that most of the cost and attention of trustee boards has gone into focussing on DB issues so, therefore, DC must always run like clockwork.
Like many things that appear simple or straightforward, scratch the surface with DC and you will find an intricate and complex web of processes, systems, and data. If we know one thing about pensions administration, it’s that data has been a persistent issue.
Be in no doubt that a huge amount of data is needed for DC scheme administration.
Over a forty year membership, a defined benefit member will have a minimum of 135 data points. Assuming the member doesn’t move to a new house, change marital status or amend any of their contact details, then this is the base number of data items held on their record. It’s just enough to calculate their benefit and write to them to tell them what it is. For a DC member, the number of data items you need to do the same job is 3,615.
Each one of those 3,615 points represents a potential risk. Miscalculated salaries, an incorrect unit price, process delays, or system failures all have the potential to derail the closely choreographed orchestra of administrator, investment manager, sponsor, and member. When you overlay this with the time criticality of investment cycles, you start to build a picture of the true complexity of achieving a well-managed DC administration operation.
Even with the best run systems, processes, and skilled people at the helm, things can still go wrong; nothing and nobody is infallible. But, when things go wrong in DC the path taken to resolve the issue is always longer, more complex, and inevitably costlier than when compared to DB schemes.
When a DB benefit has been miscalculated, even if it is a historic case, then the assessment and correction can usually be actioned within a few hours.
If the data you need is at hand, then all you need to do is to recast the calculation; a pen, paper and calculator will be the extent of the tools you’ll call on.
If something goes wrong with a historic DC transaction then forget a quick fix as you’ll need to look at every single transaction that occurred after the mistake took place; remember that figure of 3,615 data items. Considering the impact the mistake had on investment allocations, pricing, and switches then a very long standing issue could take weeks to fix. Once the problem has been diagnosed and a fix established, then implementing it will mean you will also need to call on a range of specialists covering systems, investments, and accounting.
In all the cases of DC error correction I’ve seen, the overall cost of the mistake on the liability has always been dwarfed by the cost of time spent on implementing the fix.
With the cost of rectification often being significantly higher than the impact of the error itself, you might be tempted into inventing a pragmatic, more financially beneficial solution for the affected members. The Regulator, however, takes a very dim view of this practice and expects trustees to take whatever steps are necessary to reinstate the correct level of benefits, even if it costs much more to correct than compensate.
Some of the most common errors associated with DC administration are:
• Misquoted salaries and contributions from the sponsor
• Delayed investment cycles due to mismatched or missing contributions and supporting schedules
• Mispriced or repriced unit allocations
Thankfully, years of platform and process development have been invested in making end to end DC administration processes more robust and accurate. Those that have been most successful have looked to the points of data exchange between agents and invested in putting in place automated, technology-led solutions. One of the biggest innovations that has had the most positive effect on data quality and efficiency has been the interface between administrator and employer. Auto-enrolment has pushed contribution submissions and live data validation online, meaning that sponsors are forced to submit and validate contributions before they enter the process flow.
The importance and significance of reconciliations in this environment cannot be overstated.
Regular and frequent reconciliation is absolutely essential in assuring the robustness and security of processes. Reconciliations will quickly identify whether everything is running as expected and if any part of the network of interactions is failing.
Nobody should be under the misconception that DC is simple or that it can be entirely reduced to a push button exercise.
While it does rely more on technology than any other type of administration process, it can still be subject to data input or process failures. Ensuring that processes are robust, well managed, regularly audited and reconciled is fundamental to achieving longterm success. If you are dismissive of the skills and expertise needed to administer DC then you may just fall victim to a very long, complex, and expensive rectification programme.
Member Services Manager – Trafalgar House