The voluntary phase of the digital pension tracking system is approaching and regular operation will start as early as the end of 2023. In the meantime, the German Central Authority for the Digital Pension Tracking System (ZfDR) has published further details on the implementation of the system.
The purpose of this article is to inform you about what data you need to prepare and to provide prior the start of the process.
Identification data
An integral part of every insurance product is always the underlying partner data. However, in the case of the digital pension tracking system, the commonly used first and last names and address data are not used for identification. Rather, in this scenario, the pension fund only needs to infer a specific partner based on two attributes and respond to the ZfDR's inquiry.
These two attributes are the date of birth and the tax ID – or the tax identification number (Section 139b of the German Tax Code (AO)), as it is called in full. Until now, the tax ID has played only a subordinate role and, for reasons of data protection, may not be collected and stored without a valid reason – which is why, especially in the case of older policies, the insurer usually does not even know the tax ID.
However, since the pension funds must be able to provide information from the start of regular operations when the ZfDR begins making these inquiries, it is important to be prepared, because only with a complete inventory of tax IDs may an inquiry from the digital pension tracking system be justifiably rejected. In order to cope with the prompt collection of this considerable amount of data, the German Federal Central Tax Office (BZSt) has expanded its well-known Machine Inquiry Procedure (MAV) to include an additional reason for inquiry. On this basis, the pension fund can request information about a customer's tax ID from the BZSt, even without a prior customer inquiry. In view of the fact that all pension funds will be required to complete their partner data in the coming months, it can also be expected that that there will be a significant increase in the volume of inquiries to the pension authority, with the corresponding delays in processing.
Policy data
Once this structural foundation for tax IDs has been put into place, the next step is to provide the actual data and values to be reported for the company's own customers.
The response data set submitted to the ZfDR includes the construct of a "claim" for the pension beneficiary for this purpose. Such a claim must be submitted for each existing policy, the specific form of which depends heavily on the underlying insurance product.
In addition to the obvious values, such as policy start date and benefit start date, the values for rate type and product type must also be taken into account. While it is quite easy to narrow down the rate type to the appropriate value, this is less straightforward for the product type key. In this case, based on the underlying insurance product, a pillar must first be selected, and then a specific subcategory must be chosen in which to place the claim in question. However, since the keys available for selection are not so clearly defined, the matter must first be dealt with in detail so that the pension claims can later be correctly documented by machine.
Status report
Thirdly, in most cases, the pension fund is obliged to send the most recent status report for each claim. This is sent as a PDF file, which must be an integral part of the data set. However, the ZfDR places additional requirements on the exact form of the document.
For example, the status reports must comply with the PDF/UA standard for accessibility and the PDF/A standard for long-term archiving. Specifically, the PDF/A-2a format is recommended.
As with the previous obligation to provide information, an updated status report must be made available at least once a year.
Finally, there is the question of the technical infrastructure for establishing nearly synchronous communication with the ZfDR. Since a response must be provided within a maximum of 30 seconds, this requires the use of a highly available system. This system must be integrated into the existing company network, yet it must be accessible from the outside, while also being secured.
We recommend using in|sure GovInterface from in|sure Ecosphere for all these tasks, from completing the tax IDs and preparing the policy data, to storing the data and making it available to the authorities.
Want to learn more about our evolutionary regulatory reporting software solution? Then please feel free to contact our expert Thomas Dietsch, Senior Business Developer.
