Taming the complexity of
regulatory reporting
Before everything began to change, financial and regulatory reporting requirements for UK re/insurance companies remained relatively static for a prolonged time. That was then. Now insurers are face-to-face with the reporting requirement double-whammy of Solvency II’s Pillar III and the impending International Financial Reporting Standard (IFRS) IV Phase II.

Risk carriers fortunate enough to possess a Lloyd’s franchise are staring down a triple, having already met the Lloyd’s minimum standards refresh, coming into force at the beginning of last year. To say insurance reporting is evolving is like declaring smartphones an improvement on pocket calculators.

Many insurers operate internationally and use differing insurance vehicles, and inevitably complex group structures make up today’s insurance companies. Along with this there are additional demands and requirements placed on insurance companies, from different regulators to differing accounting standards. Despite the recent convergence of these standards there are still many challenges in relation to combining data from a company’s different insurance vehicles.

Anyone who has not prepared an overhaul of their reporting systems and protocols had better do so very quickly. Those who have should expect to do so again. And again. If the right steps are taken, reporting can and should be relatively easy, despite the complexity of the new regimes. The overriding goal should be to develop a reporting system with flexibility as its primary characteristic. In the old environment, when only companies and their activities changed, but overarching reporting requirements remained relatively consistent, systems could be tweaked or patched to get the outputs demanded by regulators and others. Companies with uncomplicated business plans could even manage it with just an Excel spreadsheet. That simply will not work any more and things are not going to get any simpler with the passage of time.

Unfortunately most re/insurers’ legacy data systems were not originally built with the flexibility required to operate effectively in today’s regime. Report data comes in multiple formats from many different sources, normally drawn from some sort of rigid data warehouse. The software used to generate reports tends to be inaccessible to those people within an organisation who own or work with the pertinent data, so when report content has to change, specialist IT resource is often needed to facilitate these changes.

Traditional Reporting System

Quantemplate reporting system

Moving parts
To complicate matters, the requirements of various regulators are rather different. The data needed for financial reporting to Lloyd’s can, for the most part, be generated under the UK’s generally accepted accounting principles (GAAP), but has to be parsed and formatted to meet Lloyd’s rules. The outputs, however, are substantially different from those the Prudential Regulation Authority requires, which are based on International Accounting Standards (IAS) and Financial Reporting Standards (FRS). London market re/insurers with both kinds of entities must already cope with a dual reporting burden.

That weight will multiply with the introduction of IFRS IV Phase II, which sets out new ways to account for insurance liabilities, and will require another, further, different set of reports to be generated. Trying to reconcile Lloyd’s (in UK GAAP) with IAS and FRS is a major issue.

Companies facing this challenge need the flexibility to deliver either, depending on the day of the month, into whatever form of report is immediately necessary. They need to do so with clear visibility of the calculation assumptions that lie behind the reports, and the flexibility to back-test against old reports produced in different ways, to ensure the information presented is comparable.

All this means the various components of a company’s information can no longer sit alone. The immediate challenge is Pillar III reporting. All datasets used to support reporting must be fed into the overall Solvency II framework and own risk solvency assessment (Orsa) analyses. Data from multiple sources within firms must tie up to Orsa reports, even though the people involved in generating the data are usually members of different teams, sometimes even working in different physical locations. A risk team preparing Orsas, a financial department preparing quarterly reports, and the audit group that reviews everything should all be able to use and access the same data, with the same timestamps. Ideally, it would all come from a consistent source, allowing everyone involved to draw down the bits of information they need.

This new reporting regime will undoubtedly evolve before it is fixed and finalised, which means it will be impossible to get Pillar III reporting right the first time. We can expect requirements to change, sometimes frequently, for at least the next four or five years, until the system is bedded down and workable for everyone. That approach, of course, creates uncertainty, which in turn creates additional challenges for re/insurance companies.

Systems that mitigate the uncertainty and help reporting companies to manage it will be a boon. Insurers need to be armed with a flexible reporting tool that support regular changes to the content of the reports they must produce. They need to allow such outputs to be reconstituted very quickly, as and when requirements change. Already the quarterly reporting demands of Pillar III leave very little time to implement and test changes to reporting systems between deadlines, which can help companies to spot modalities between old and current reports more easily. Without such testing, errors are easily made, so the ability to do so lies at the foundation of the credibility and accountability of entity reporting.

Regulation now means information gathering is no longer practiced with a single end in mind. Re/insurers must have systems in place to compile and categorise data so that it can be drawn down in one way for one purpose on one day, and in different ways for other reasons a day later. Systems that allow the user to bring together data from multiple sources, and to chop and change the combinations at will, without obscuring the calculations originally applied to generate the source data, are necessary to retain the overall flexibility of the system, and to tame the complexity of regulatory reporting.
The Federated
Data Model
Taming the complexity of
regulatory reporting
Insurance models
for the technology age
Understanding changing
distribution channels
Making each business
line count
Brokers as
risk consultants
Four steps to
data-driven reinsurance
Portfolio steering
in the soft cycle
What is
responsive reserving?
The price is tight,
but is it right?
Improving data capture
through collaboration