Sponsored statement: BNY Mellon

When considering the asset data requirements for Solvency II, a refinement of the sporting metaphor would be a relay race with multiple team members and multiple batons. 

Market risk is a significant contributor to the Solvency Capital Requirement (SCR) of insurance companies. It is also, for many, an area of their risk profile that has not, historically, received the level of scrutiny that will be applied under Solvency II. Insurance companies rightly focus on their insurance activities as their main business, with the task of managing the supporting assets often delegated to in-house or external investment managers. This brings an added complexity to the challenges that insurance companies face in the collection of asset data to support Solvency II’s requirements. What this also means is that a lot of entities’ systems have been well developed to support the liability side of the house, but the asset side has not received the same level of system infrastructure.

It is worth noting that asset data is relevant to all three pillars of Solvency II. Asset information is required under Pillar I for the calculation of the SCR, whether by the standard or internal model. It is also a significant element of the Pillar III reporting requirements, which are extensive particularly when considering the Quantitative Reporting Templates (QRTs) that will form the submission to the regulator. What is sometimes overlooked is the significance of data, including asset data, under Pillar II. 

The Pillar II guidance on governance, monitoring and documentation of data used by the insurance company applies to asset data to the same degree as the date relating to the insurance book. This means that insurers need to ensure that controls and procedures are in place to meet Solvency II’s requirements for data to be complete, accurate and appropriate. Even where insurers rely on external providers or sources, the same onus is placed on data management and quality as for internally maintained data. The data directory under Pillar II extends to asset data and should identify both the source and the use the data is put to within the organisation. The various components of data management are effectively brought together within the Own Risk and Solvency Assessment (ORSA). This increases the frequency the asset data baton is passed in our imaginary relay race as the ORSA is an ongoing process through the year. In our experience, insurers are considering a monthly frequency to the data collection cycle. Additionally, there is the possibility of market or business events that trigger ad-hoc requirements.

So what asset data is required and where will insurance entities obtain it? The starting point for answering these questions is to look at the purpose for which the data is to be used. From a Solvency II point of view, there are two main uses:

1. To support the market risk calculation within the SCR, whether for reporting purposes or as part of the ongoing monitoring within the ORSA; and
2. the supervisory reporting requirements with particular reference to the Pillar II QRTs.

As one of the underlying goals of the QRTs is to enable the supervisor to monitor the risk profile of the insurance entity, it should be no surprise that the data set required for the asset QRTs has many elements in common with the data set required to support the market risk requirements. While there are elements that may be required for market risk calculation that are not on the QRTs – for example, the haircut on repos – these tend to be associated with over-the-counter positions. The following analysis is therefore based on the data required for the QRTs as this generally represents the larger data set.

The asset data elements required can be grouped into the categories set out in table A, below:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

For a complex investor with a wide investment strategy there are some 82 unique data elements required to complete all of the asset QRTs [based on the version in the European Insurance and Occupational Pensions Authority’s (EIOPA’s) November 2011 public consultation]. What is clear from an in-depth analysis of these data elements is that they will not come from a single source. Insurers expecting a single baton from their asset manager are going to be disappointed. 

Figure 1 illustrates the potential data sources of the 82 data elements. This is a representative view and the exact profile of the data sources will differ from insurer to insurer. Some points to note are:

• The term ‘enhanced’ indicates that a data element is likely to be derived from the identified source but that some form of transformation, mapping or enrichment is required. An example of this would be the EIOPA-defined Complementary Identification Code (CIC) that is required. This is constructed from the International Organization for Standardization alpha country code of a security, together with a category/subcategory alphanumeric indicator. The CIC can therefore be derived from security standing data with a mapping table to the EIOPA CIC matrix.
• The source ‘fund manager’ represents the issue of look-through associated with pooled investment vehicles. While the reporting requirement in the QRTs is at a summary level, CIC category by geographic zone and by currency, the data requirements to calculate market risk at the appropriate level are much more granular and line level. This makes the data requirements here as onerous as for segregated asset pools. This is even more complex for those insurers utilising fund of funds structures/managers.

What the above aims to illustrate is that asset data will not be fulfilled solely from the accounting system of the insurer’s asset manager. A high proportion may be obtained or derived from an accounting application, but there are a significant number of others that will not. There are many items that are not stored on the accounting system, for example, ‘contract term’ items such as attachment points or additional enhancements such as CIC codes.

Any insurer that has a main accounting or general ledger system and that is planning on building its solvency solution around this is in for a difficult and very expensive time.

• Accounting systems are often not built to accept the level of detail required for Solvency II.
• They are notoriously difficult to get data into and out of.
• The systems often have little or no data-cleansing or governance tools, which are essential for Solvency II.

The asset data relay race is therefore more complex than perhaps insurers have considered:

• Extensive asset data requirements, whether for SCR or reporting purposes.
•  The same level of data quality/assurance whether internal or external.
• Multiple data sources in terms of the various data elements.
• A number of data providers where multi-manager/third-party administrators are utilised.
• A monthly lap cycle with tight lap times to meet.

How do insurance entities ensure that they do not drop the baton? Our experience as an asset service provider indicates that a system-based solution must be applied. At the core needs to be a data warehouse with flexible input/output facilities, strong data management controls including robust data validation, and transformation/enrichment capabilities.

Our view is that the winning architectures will be modular with separate but best-of-breed asset and liability data warehouse solutions. The fundamental difference in the data attributes and challenges between assets and liabilities, together with the historical focus of the insurer, will see many insurers seeking to supplement their liability infrastructure with a robust solution to address the asset data challenges.

At BNY Mellon, we have developed a robust Eagle PACE™-based solution that supports the asset data governance, quality and reporting requirements imposed on insurance companies by Solvency II and beyond. We can deliver an assured solution including:

• gathering and validating data from you and your partners;
• enhancing the data with vendor feeds and your own management information;
• consolidating and normalising the data as a single source to feed to other specialist systems such as risk engines or general ledgers; and
• provision of flexible reporting output, including in the required Solvency II format.

 

_{BNY Mellon is a corporate brand of The Bank of New York Mellon Corporation and may also be used as a generic term to reference the corporation as a whole or its various subsidiaries. Products and services may be provided by various subsidiaries and joint ventures of The Bank of New York Mellon Corporation, which may include The Bank of New York Mellon (each, the “Bank”), a banking corporation organised and existing pursuant to the laws of the State of New York and operating through its branch at One Canada Square, London E14 5AL, United Kingdom. Registered in England and Wales with FC005522 and BR000818 and authorised and regulated in the UK by the Financial Services Authority.© 2012 The Bank of New York Mellon Corporation. All rights reserved.} 

_{The views expressed herein are those of the author only and may not reflect the views of BNY Mellon. This does not constitute business or legal advice, and it should not be relied upon as such.}

View the article in PDF format

Sponsored content