The modernization of portfolio management in the company pension scheme (including its neighboring systems, if applicable) requires a decision to be made between in-house development and the purchase of standard software. But what is standard software in company pension schemes? What specific requirements must a company pension scheme management system meet in order to be considered as a solution to the challenges outlined above?
Requirements for company pension scheme portfolio management.
The company pension scheme is primarily underpinned by the Company Pensions Act (BetrAVG). Specific company pension scheme processes include:
The correct mapping of these processes requires a special contract model in which the employer and employee balances are managed separately. Furthermore, the Riester portion and the privately continued portion are separated. This applies not only to the main tariff, but also to any supplementary insurance, which means that an insurance contract in the company pension scheme has the following approximate structure:
All processes must be implemented so that they fully support this contract structure. Furthermore, in the phase of private continuation, one needs to be able to process the contract as if it were a private contract - provided that any contractual agreements between the pension provider and the employee do not explicitly exclude this. For example, the change in the distribution of contributions in the "company pension scheme phase" between the employer, employee and Riester should have no effect on the total agreed upon benefits.
Processing the contributions
Perhaps the most important functional unit in a company pension scheme portfolio management system is the processing of incoming contributions. Life insurers often collect premiums for the direct insurance policies they manage using the debit position principle, as is customary in life insurance, i.e., the present value of the insured pension is equal to the present value of the outstanding premium payments plus the accumulated actuarial reserve. In other implementation channels (e.g. pension pools and funds), "ongoing lump-sum contributions" and/or immediate "actual provision" are common. In the case of an "ongoing lump-sum contribution," the insured person acquires a (small) annuity, i.e. an "annuity module," with each contribution. Ongoing lump-sum contributions are usually paid monthly, often in arrears with the payroll at the end of the month. If the amount of these ongoing lump-sum contributions is fixed, a debit position principle can be used (with an adequate reminder and termination mechanism), otherwise an actual position principle is used, one in which the contribution amount can vary as desired. Every payment has a "tax color-coding," regardless of whether it is an ongoing planned contribution, an ongoing lump-sum contribution, an accepted actual contribution, an additional payment outside the agreed upon contribution payment or a transfer contribution (section 4 Company Pensions Act). In accordance with the Minimum Wage Act, the pension benefits resulting from the contributions must be differentiated between "subsidy pursuant to section 3 no. 63 Minimum Wage Act," "subsidy pursuant to section 40b Minimum Wage Act," "subsidy pursuant to sections 10a and 82 Minimum Wage Act" and "no subsidy." Each pension module has an additional social insurance relevance: Pensions from contributions in privately continued periods are tax-exempt, all other pension modules are subject to social insurance contributions in full. For this reason, the portfolio management system must also separate the pension modules from contributions in private continuation from those paid from contributions in periods without remuneration with an existing employer relationship.
A fundamental component of a viable company pension scheme portfolio management system is a mechanism for fully automated contribution correction. Not only the contribution amount, but also the "tax color-coding" or the social insurance relevance must be correctable with this mechanism without any further context.
Product modeling
Every respectable system of portfolio management includes a component for product modeling. However, this can vary quite a bit. In the simplest version, this component actually manages only the tariff (numeric) parameters (cost, surplus, discount, surcharge, cancellation surcharge rates and similar figures). In convenient systems, this component provides all partial work steps for all business processes in all products. Each of these "code fragments" is then arbitrarily reusable, but also arbitrarily interchangeable. This flexibility deep into every process is essential for standard software in the company pension scheme.
In life insurance, tariffs used in company pension schemes, i.e. for direct insurance, are often not subject to separate Federal Financial Supervisory Authority (BaFin) notifications in accordance with section 143 of the Insurance Supervision Act (VAG). The underwriting described in these rate plans is often identical, or at least very similar for all pension plans of a provider's same benefit range. Furthermore, the structure of the tariff plans, and consequently, the product modules needed for modeling, are structurally similar from one life insurer to the next (the concrete characteristics can, however, be very different). This statement does not apply to pension pools and pension funds, especially if they are regulated. Then there are no similar tariff plans, and each provider has their own "culture" for documenting the tariffs. Sometimes this is done without great detail, or inaccurately. In addition to collective bargaining plans and insurance terms and conditions, those provisions from collective bargaining agreements must also be taken into account that are rarely based on the structure of an insurance contract or pension commitment. Although the processes underpinned by the Company Pensions Act are essentially the same, the concrete implementation, and as a result, the product modules required for modeling, are inhomogeneous from one pension provider to the next. Compared to the direct insurance tariffs of life insurers, a company pension scheme's portfolio management system must also master the following special features:
The insurability of several risks in one tariff and in several contract sections also imposes high demands on the service processes. In the event of the death of an employee, several persons may be entitled to a pension benefit. The amount of this entitlement may be derived from the existing lump-sum death benefit and/or from an agreed upon pension benefit. Such a process may also trigger a lump-sum payment and an annuity payment to one or more eligible individuals. In general, the amount of a lump-sum death benefit in the company pension scheme is currently limited to €8,000, which includes all of the deceased's contracts with the same pension provider. In the event of incapacity for work with proximate cause, the EU pension payable is determined only after taking into account the assumption that contributions will continue to be paid in a fixed amount until a certain age is reached. It goes without saying that despite this implied complexity, a company pension scheme portfolio management system can undertake all the necessary calculations, including the drawing up and issuing of new contracts entirely by machine. In other words, no further manual activity is required once the benefit check has been completed and the eligible persons have been registered.
In this context, the in|sure Ecosphere includes not only a highly flexible, state-of-the-art and efficient portfolio management system - it has a number of useful neighboring systems as well. Would you like to learn more? Then feel free to contact our expert Thomas Dietsch, Senior Business Developer.