Accurate transfer of data is critical in the highly complex and fast-moving Financial Services sector. After its introduction in 2014, the requirements of the Solvency II directive increases the need for the timely transfer of data to the regulatory authorities. This guide outlines how data quality and data integration software can be optimised to meet the Solvency II requirements.<\/p>\n
Solvency II redefines the required capital for insurance companies to operate in the EU. The aim is to reduce the risk of insolvency and increase consumer protection. The framework has three main pillars:<\/p>\n
For a company to adhere to the Solvency II requirements, its data strategy for the three pillars must be detailed and robust. Low data quality and poor transfer strategies increase the potential of inaccurate risk capital calculations.<\/p>\n
There are two possible approaches to collating the information available for calculation of Pillar 1\u2019s Technical Provisions (TP) and Solvency Capital Requirements (SCR):<\/p>\n
Both approaches have similar software requirements. The main difference is that the ad hoc option requires the data to be migrated and consolidated on a frequent basis to allow the calculation of the TP and SCR.<\/p>\n
Data migration requirements<\/strong><\/p>\n The optimal data migration software capabilities include:<\/p>\n Data quality requirements<\/strong><\/p>\n Data quality checks should be carried out prior to migrations to assess the current quality of the data and highlight any issues. Software should be able to perform data verification during the migration, validating the data against business and system-level rules. Ideally, the software should also use these rules to validate data as it transfers between internal data silos or external third parties.<\/p>\n Example rules:<\/p>\n Data requires continuous verification: information can contain a multitude of anomalies when entered by users, or when transferred between systems or from third parties. Accuracy, range, and structural verification are a few of the checks required to maintain fit-for-purpose data.<\/p>\n Data reconciliation requirements<\/strong><\/p>\n Ideally, the software should provide reconciliation of information by consolidating information directly from the data stores and comparing that against official data records.<\/p>\n Logging and error reporting requirements<\/strong><\/p>\n During data migration and data verification, logging and error reporting is essential. It should be defined to provide the user with detailed information about data that has failed to adhere to the business and system rules.<\/p>\n Using specialist software to implement parts of the enterprise management system demonstrates that dedicated tools are being used to handle the data. This shows the authorities that the company has a stable platform for data migration, data verification and data cleansing.<\/p>\n For maximum efficiency, it is important that the software provides future proofing by:<\/p>\n Using a specialised tool to provide data management services creates a high level of confidence about the process being created and implemented.<\/p>\n The data management software should provide a clear, stable platform for providing reports to the regulatory body. For instance, our Transformation Manager software uses its migration functionality to generate XBRL files composed of data from the centralised store or workflow data. This involves:<\/p>\n Using a specialised tool like Transformation Manager reduces risk by addressing low-level core component issues directly<\/a>. This enables timely intervention and correction, preventing costly reruns further down the line.<\/p>\n <\/p> \n
\n
\n
\n
Pillar II directives<\/h4>\n
\n
Pillar III directives<\/h4>\n
\n
Further reading<\/h3>\n\n
\n<\/ul><\/div>\n