To submit Solvency II data to supervisors, insurers must get to grips with XBRL and automated data handling. In this article, DataTracks explains its approach
After two false starts, the Solvency II pillar 3 reporting regulations are all set to come into force in January 2016. The new requirements ask for stringent reporting of risk data. After the global economic meltdown of 2008, it was only natural that stricter rules for the protection of customer money (and assets) began to get considered, and it is probably a little surprising that it has taken so long in the first place.
However, now that it is here, insurers have a huge hill to climb both in terms of the granularity of the data that they collect and the reporting format. DataTracks' Solvency II solution, DT Solvency II, lets insurers file their quantitative reporting templates (QRTs) easily, accurately and fast. Two delivery models provide flexibility to insurers based on their requirements.
XBRL rules
Supervisors require insurers to submit information in extensible business reporting language (XBRL). XBRL is a markup language, not a programming language. Therefore, it is not a tough technology for any company to master, per se. However, the various 'grammar' and validation rules that come with an XBRL adoption, along with the zero-error tolerance context of financial information, make XBRL difficult and somewhat scary.
The large amounts of data that insurance companies have are too onerous for manual handling on a regular basis
DataTracks has a long history with providing high-quality XBRL services to companies across the world. XBRL information usually happens to be critical information and experience of the degree that DataTracks can boast of is an invaluable resource. The reputation that DataTracks has in quality is also unparalleled, as certain XBRL quality studies in the US attest to.
Organising data
Insurance organisations have very large amounts of data. There is a lot of granular data that insurance companies collect about their transactions. Not all of it needs to be reported and not all of it is even required for calculations of items that need to be reported. However, all of this data needs to be kept organised and it needs to be made available to reporting front-ends quickly and accurately.
DT Solvency II works on the principle of mapping data source items directly to Eiopa templates through a data point model. The mapping process essentially creates pipelines for data items. Whenever a number changes in the source, that change flows through the pipeline to the Eiopa template.
Automation
The large amounts of data that insurance companies have are too onerous for manual handling on a regular basis. Software automation is critical for speed and accuracy. Like all automations, compliance reporting automation requires significant investments of time and money for the initial set-up process. This is one of the reasons software automation for compliance requirements is difficult for organisations.
Take the example of a detailed chart of accounts. From a compliance (and management) point of view, details of each account may not be necessary. Some aggregation of those accounts is needed for reporting and decision-making.
This implies that an automation system would need to be set up to aggregate all those accounts to a single value. This process, called mapping, has to be done once. After that, whenever data changes in any of the accounts, it flows in to the aggregation via a calculation (usually weighted addition).
Audit control
When large amounts of data are handled, minor changes to data are difficult to keep track of. Often, these changes happen because someone finds an error somewhere and corrects it leading to a change in linked numbers. Sometimes, there could be inadvertent omissions that lead to changes in certain aggregations. It is, therefore, critical for software solutions to have good control mechanisms. Audit trails, of course, are a point of parity and any reporting system in an industry such as insurance that does not provide reliable audit trails is just not acceptable. Commenting or in-tool discussion threads (template-level or cell-level) are an added bonus and help make the tool more self-contained.
Solvency II compliance requirements place an extra reporting burden on insurers. But in the long run, it is good for customers and for the insurers themselves
DT Solvency II solution contains four control features: audit trail; access restriction to specific report type and specific templates within each report type; commenting; and version compare (between two different reporting periods as well as between different versions within the same period). Version comparing is useful in pinpointing differences when source data changes, and in performing variance analysis between periods.
Delivery
DataTracks offers its Solvency II solution in two delivery models. The Lite model provides downloadable Excel-based blank templates from a DataTracks portal.
Clients fill in data every quarter and upload these filled-up templates back onto the portal. The XBRL file will be generated and kept ready at the portal, where the client can download it and submit to the regulator.
The Enterprise model is the integrated solution that we have been talking about. The Enterprise model itself can be subscribed to in two ways depending on whether database connections are implemented or spreadsheet-as-data-source is used. This latter scenario will occur when insurance companies are short of time to integrate with the source but have everything in spreadsheets.
Solvency II compliance requirements place an extra reporting burden on insurers. But in the long run, it is good for customers and for the insurers themselves. During these growing pains, however, insurers need support and DataTracks, with its extensive experience in XBRL technology and in the rigors of compliance, is a great partner to have.
Channels:Software - IT
Companies:DataTracks
