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.