It is obvious by now that drastic measures are required to handle the looming pension crisis in Europe as – because of demographic developments – a smaller number of salary earners will need to pay for the state pension income of an increasing amount of pensioners.
European governments and professional organisations have realised the urgency of the issue and governments have stimulated the creation of additional saving products. Despite these efforts, the defined contribution (DC) type of products currently available in several European countries are faced with a disappointingly slow pick-up.
The reason for this disappointing pick-up by the public may well be that the design of the products simply does not meet their needs.
The DC product design we currently see is not the cure for the European pension crisis. So which pension products do we need?
Were the current pension products developed with peoples’ needs in mind or with product offerings in mind?
The best starting point for a pension product engineer is where there is no legacy at all and where one can start with a fresh piece of paper on the drawing board. In the case of no legacy one of the first questions a product developer asks is ‘what is the product expected to deliver?’ and ‘along what dimensions is the product concept communicated to future product buyers?’. Other issues to be addressed at the start are: what are the recommendations made by industry bodies related to product design, and what are the particular generally appreciated product features by participants in, for example, DB schemes?
Recommendations made in a recent report by the European Financial Services Round Table (EFSRT) include: product transparency (full, frank, and easily understood disclosure of terms and provisions), proper product information provision (for example timely, accurate, and user-friendly statements of projected pension income at retirement), and portability (= ability of a pension holder to transfer his or her pension or annuity to another provider at a fair transfer value). User-friendliness is another requirement, ie, individuals and employers using the product should easily understand where they stand and make decisions accordingly.
In the US the Department of Labor has formulated pension product scheme ‘principles’ relating to cost effectiveness, diversification of investments and ‘wise and careful’ investment. The US based National Defined Contribution Council (NDCC) is promoting more total fee disclosures by pension product providers. In general the observation is made in the US that there is a wide disparity seen between pension product plan design and participants investment behaviour as: 1) there is no adequate diversification by participants; 2) not enough participation in plans in general; 3) many participants do not contribute enough; 4) fees charged are often considered as too high; and 5) there is a lack of advisory function.
For one thing, DB schemes do meet some of the criteria as formulated by the EFSRT. DB arrangements are, for example, easy to understand for the participants and the costs and investment risks all seem to be ultimately borne by the employer, not the employee. That’s is one of the reasons why some US organisations including the American Academy of Actuaries, and pension money managers are suggesting that 401(k) DC plans are to be combined with traditional defined benefit plans into one product (referred to as DBk), combining the best features of both.
Knowing all this, a pension fund could choose to design and construct their own individual pension products offering according to their specific participant specifications and taking the above mentioned recommendations and features into account.
In doing so the above two charts provide important guidelines.
The first chart is a guideline on product definition. Instead of defined individual pension (DC) products along terms of how investments are made, the product could be defined in terms of what the product does for the participant. This may be a definition of the target capital (in terms of probabilities) with additionally a product module defined in terms of (expected) pension income bought with the target capital.
The distinction made here is between product definition in the saving period and the pay-out period. The saving period product definition can be seen as being composed of different product definition (evolution) steps. The first (evolution) step is defining a product along the investment options that are being offered and the amount of the (monthly) contribution. This is how the current product definition of DC pension products is defined. However utility modules in product definition can be added subsequently, by defining products in expected risk/return terms and by defining products in terms of the target saving capital in a certain future moment. Products defined along this last dimension can be referred to as DBk or as Defined Capital® pension products. Here a bridge is made between saving products and pay out products.
The connection with the pay out product is being made by adding the price of the annual pension pay out (varieties are possible including indexing and partner pension) to arrive at a pension product in terms of yearly pension income. And – surprise – adding this last product utility module results in something that is very similar to defined benefit. The only difference is that it is formulated as an individual Defined Benefit® product. A number of Defined Capital® products and individual Defined Benefit® products are currently under development by our firm for application in the European market.
Now we know what type of product we want and we can focus on the engineering process. In this process, there is no need to take legacies into account.
The point is that any saving product can be considered as consisting of several functions making up a total process which is the heart and nervous system of the product.
Chart 2 is an illustration of these functions as embedded in a pension saving product.
A pension provider in need of an individual savings plan has the option to acquire an existing ‘retail’ pension product (possibly modified to accommodate for pension regulations) as a total ‘bundled’ external solution. For smaller plan providers this seems the route to go, assuming that the product definition provided is something similar they are looking for. This can mean acquiring a white-labelled fund supermarket infrastructure or incorporating a product range of a single mutual fund provider.
Larger plan providers should seriously consider another interesting variant to outsourcing. The formula is to bundle functions provided by specialty providers into ‘no legacy’ tailored products which enables them to combine functions provided by specialty outside parties with internal core competencies.
This ‘bundling’ approach implies that functions (such as portfolio management, fund accounting and transfer agency) are acquired separately from different best in class providers and are connected together.
For larger plan providers the advantages of this approach include control over the specifications of the product (product definition is ‘distributor based’), transparency and cost efficiency. Other benefits for providers include new opportunities for rewards for innovation and competitiveness.
In comparison, cross-border life assurances initiatives already are being taken, where different product functions from different providers are bundled into specific product solutions for specific markets. The principles behind these initiatives are that companies can distil the best features from different operations across Europe and apply them to chosen target markets.
One service typically already acquired as an unbundled function by European pension funds is portfolio management of certain parts of the investment portfolio. When migrating to DC products these pension funds can use their manager selection capabilities and negotiation power to hire external managers for some DC portfolios as well. The economies of scale thus achieved will obviously benefit the DC product buyers.
One area that needs specific attention though is the interface with participants, called the transfer agency (TA) function. This is the communication and transaction processing channel between the pension plan provider and the participants of the pension plan. It is typically a function, which is not developed extensively with DB pension providers. It is a function which can be easily acquired from TA specialty providers but have to be integrated into a pension fund participant DB administration.
When addressing solutions for the looming pension crisis and the question why recent pension saving plan initiatives have not been successful there are two conclusions. One is that investment products should be defined according to what they do for pension savers, and this requires a fresh look at products definition. The other conclusion is that larger pension plan providers should build their own DC plans by bundling services of specialty providers. In doing so, a firm step is taken towards a solution to the current pension product crisis.
Jeroen Tielman is founder and CEO of Fund Partners based in the Netherlands

Topics