white paper meeting the data quality management may 2011 ... · this paper has been prepared for...

EntErprisE risk ManagEMEnt 29 April 2009

WhitE papErMay 2011

Massimiliano NeriAssociate Director

Contact [email protected]

[email protected]

AsiA (Excluding JApAn)+85 2 2916 [email protected]

JApAn+81 3 5408 [email protected]

Visit: www.moodysanalytics.come-mail: [email protected]

About the AuthorMassimiliano neri is an Associate Director at moody’s Analytics who covers the role of specialist in best practices for enterprise risk management solutions. prior to moody’s Analytics, massimiliano accumulated considerable international-level experience promoting business processes and business rules methodology in the financial sector. massimiliano holds a phD in Applied economics from the Universidad rey Juan carlos in madrid. in the past, he has held several seminars on the microeconomics of risk and uncertainty at luiss Guido carli University in rome, Universidad rey Juan carlos in madrid, and the ludwig von mises institute in the United states.

Meeting the Data Quality Management Challenges of Solvency IIHighlights

» The Solvency II Directive introduces strict requirements for data quality. Insurance companies will need to manage these processes to comply with the Directive. This paper has been prepared for risk managers, actuaries, and Solvency II project and IT managers. It reviews the regulation and outlines the main data quality requirements. It provides best practices for data quality assessment and management, including types of data quality checks and processes, and audit and checking capabilities. The paper demonstrates that a centralized approach to data quality management that leverages technology to automate the process should help insurance companies go beyond the data quality assessment aspects of the Directive, leveraging the benefits of complete, accurate, and transparent data for greater operational effectiveness and stronger risk-based decision making.

2 MEEting thE dAtA QuAlity MAnAgEMEnt chAllEngEs of solVEncy ii

EntErprisE risk ManagEMEnt 29 April 2009mOODY’s ANAlYTics

Table of Contentsimportance of data Quality for solvency ii 3

Note on the Reference Literature 3

criteria to Assess data Quality 4

Data Definition 4

Data Quality Assessment 4

Granularity of Assessment 5

Application of the Principle of Proportionality 5

Data Reconciliation 5

data Quality systems and procedures 6

The Data Quality Management Process 6

Data Collection, Storage, and Processing 7

Auditors and the Actuarial Function 7

Identification of Data Deficiencies 8

Management of Data Deficiencies 8

Moody’s Analytics Best practices for data Quality Assessment and Management 10

A Centralized Approach to Data Quality 10

Types of Data Quality Checks 13

The Data Quality Assessment Process and the User 13

Audit and Tracking 15

conclusions 17

further reading 18



Importance of Data Quality for Solvency IISolvency II is the first regulation that introduces strict requirements for data quality for insurers. Risk management experts agree that good data enables a more accurate calculation of the best estimate (for technical provisions). No previous insurance regulation has provided such detailed specifications for data quality.

Without a doubt, having good quality data is an essential prerequisite to calculating technical provisions correctly. The implementation measures of Solvency II have been conceived to establish guidance for a consistent approach to data quality across Pillar 1 to support an accurate calculation of the Solvency Capital Requirement (SCR) and the Minimum Capital Requirement (MCR).

Much effort has been placed, especially in the Quantitative Impact Study 5 (QIS5), on the development of sophisticated internal models that allow customization of SCR and MCR calculations according to the company’s needs. However, it is less valuable to fine-tune internal models without making sure they are fed with high-quality data.

Note on the Reference LiteratureThe organization that governed the Solvency II Directive, the Committee of European Insurance and Occupational Pension Supervisors (CEIOPS), was replaced by the European Insurance and Occupational Pensions Authority (EIOPA) in January 2011. Because the reference literature has been entirely published by CEIOPS, we refer to that organization throughout this paper.

CEIOPS has published a number of consultation papers dealing with data quality. The most prevalent is CP 43 (later renamed “Technical Provisions – Article 86f Standards of Data Quality”)1, which covers the requirements for data quality for the calculation of technical provisions. This paper deals specifically with the criteria to assess data quality and with the processes and the systems to use for data quality management, and for the collection, storage, and processing of data.

Another paper that highlights data quality is CP 56 (later renamed “Tests and Standards for Internal Model Approval”),2 which focused on undertakings using internal models. Neither of these two papers overrules the other; they should be seen as complementary, and both contain cross-references to ensure consistency.3

Some critics find occasional overlapping between the two documents.4 In any case, eventual overlapping does not create confusion in the overall data quality strategy that the organization is pursuing. Much of the data used to estimate the technical provisions and to parameterize internal models is similar and should be subject to the same governance process.

We have reviewed this literature and the comments that have been raised by insurance companies and associations during the consultation period. In this paper, we also point out the areas of the regulation that raised major concerns, and the resolutions taken by CEIOPS based on those concerns.

scr - Key quantitative capital requirement defined in the Solvency II Directive. The SCR is the higher of the two capital levels required in Solvency II and provides an approximate 1 in 200 year level of protection.

Mcr - Key quantitative capital requirement defined in the Solvency II Directive. The MCR is the lower of the two capital levels required in Solvency II and provides an approximate 1 in 6 year level of protection.

1 CEIOPS (43/09).2 CEIOPS (56/09).3 “Requirements from the Data Quality Standards for Technical Provisions (see CEIOPS Advice) shall also apply, where applicable, to internal

model data in addition to the requirements set out below.” CEIOPS (56/09), par 5.124. 4 See, for example, CEIOPS (56/09), par 5.176.



Criteria to Assess Data Quality

Data DefinitionWhen using the term data, CEIOPS refers to the information that is used in actuarial and statistical techniques to calculate technical provisions.5 This also applies to data that is employed in setting specific assumptions regarding the valuation of technical provisions.6

Data Quality AssessmentData quality assessment should be performed according to three criteria.

» Appropriateness » completeness » Accuracy

Sometimes, it is difficult for an organization to obtain data that is at the same time appropriate, complete, and accurate. This issue derives from practical difficulties that arise from the constant evolution of insurance products, of the risks, and of the institutional environment surrounding the undertaking.8

This section explains the criteria that are used to assess the quality of data. The next section describes what to do when the assessment reveals deficiencies.

AppropriatenessData must be appropriate to the risks covered and to the calculation of capital required to cover these risks. Data that is appropriate for managing the auto industry might not be appropriate for managing life risk, and vice versa.

Formally speaking, data is appropriate if it complies with the following two requirements.9

– It is suitable for the valuation of technical provisions (for example, for the estimation of liabilities’ future cash inflows and outflows) and/or setting of assumptions.

– It directly relates to the underlying risk drivers of the portfolio of risks under consideration (or more specifically, their relevance).

completenessAccording to the Directive, data is formally complete if three requirements are fulfilled.10

– The data covers all the main homogeneous risk groups in the liabilities’ portfolio.

– The data has sufficient granularity to enable full understanding of the behavior of the underlying risk and the identification of trends.

– The data provides sufficient historical information.

The completeness of the data is assessed by comparison with data from other lines of business or risk factors.

During the consultation period, the following statement from the original text raised much concern.

“For instance, if run-off triangles are used to calculate the best estimate, it is necessary to record separately all payments and the date on which the payment was made, instead of just the total amount paid.”

These definitions characterize data only with reference to insurance liabilities. We recommend that insurance companies consider a broader definition of data that encompasses assets7 and the relationship between assets and liabilities, to give a more comprehensive scope to the data quality assessment.

5 ““Data” refers to all the information which is directly or indirectly needed to carry out a valuation of technical provisions, in particular enabling the use of appropriate actuarial and statistical methodologies”, CEIOPS (43/09), par. 3.56.

6 CEIOPS (43/09), par. 3.58.7 For example: market data, security prices, positions, etc.8 “Changes in the operating environment (such as changes in legislation) may reduce the appropriateness of the historical data, because it becomes less

credible for prediction exercises”, CEIOPS (43/09), par. 3.23.9 CEIOPS (43/09), par. 3.62–3.10 CEIOPS (43/09), par. 3.64–5.



This statement raised the concerns of life and reinsurance companies, which were looking for some kind of payments grouping. However, in the resolutions taken after the consultation, CEIOPS emphasized that all payments must be recorded. In the case of life business, CEIOPS noted that “as a prospective discounted cash flow approach is specified, historical information is generally only required for the purpose of assumption setting.”11

Reinsurers will have the possibility to reflect the cedant’s payment date, rather than their own, in the run-off triangles due to reporting delays.12

AccuracyTo be accurate, data must fulfill four requirements.

– It must not be affected by errors or omissions.

– It must be stored adequately, in a timely manner, and consistently.

– A high level of confidence can be placed on it.

– It must be demonstrated as credible by being used through the operations and decision-making process.

According to the Directive, the criterion of accuracy requires the performance of data and consistency checks.

Granularity of AssessmentThe assessment of the first two criteria (appropriateness and completeness) should be considered at the portfolio level. However, when required, it must be possible to undertake these assessments with finer granularity. For accuracy, the organization should consider working at the individual item level.13

Application of the Principle of ProportionalityFor portfolios with simple underlining risks (in terms of nature, scale, and complexity), the criterion of accuracy is interpreted in a looser way than for portfolios with complex risks. This is because less data is requested. However, historical data is important and should be collected, because it might become relevant in the future.

Similarly, where the nature, scale, and complexity of underlying risks are higher, superior standards are applied to data quality management. However, sometimes it is not possible to collect large amounts of information in the presence of complex risks (for example, in the case of events with low frequency). In this case, to secure the robustness of the process of data management, the organization should consider complementing the management of internal information with relevant external information and the use of expert judgment.

Data ReconciliationAn important aspect that is linked to the definition of the accuracy criterion is the process of reconciliation. This process allows insurance companies to compare the data with external references to verify its consistency. The term reconciliation refers to outlining the reasons for the differences between data and the consequences of it.14

For example, a process of general ledger reconciliation would involve the following.

– Generation of accounting postings in order to create a balance sheet based on internal data.

– Comparison with the official balance sheet.

– Identification and explanation of the differences, if any.

11 See CEIOPS-SEC (106/09), resolutions 67, 73.12 See CEIOPS-SEC (106/09), resolutions 66, 68, 73.13 CEIOPS (43/09), par. 3.61.14 In a first version of the Directive, it was not clear whether reconciling simply meant identifying differences (if any) or explaining the reasons/

consequences of the differences. Hence, it is not redundant to confirm that reconciling means explaining both differences and reasons/consequences.



Data Quality Systems and ProceduresThe undertaking should adopt systems and procedures that allow insurance companies to properly address the following three areas.

» the process of data quality management » data collection, storage, and processing » External auditors and the actuarial function

Furthermore, the governance of data quality requires insurance companies to specify actions when data deficiencies are identified.

The Data Quality Management ProcessThe process of data quality management is composed of four main steps, which can be organized in a continuous loop, as shown in the following figure.

step 1: data definition The Directive requires that the data describing the business of the undertaking must be appropriate and complete. The definition of the data involves the identification of data requirements that fulfill this criterion. Data requirements should contain a proper description of the single items and their relationship. Our experience with clients also suggests that maintaining documentation of the main dimension of segmentation (for example, by homogeneous risk groups) will support stronger data definition.

step 2: data Quality Assessment Data quality assessment involves validating the data according to the three criteria: appropriateness, completeness, and accuracy. The assessment should consider the channel through which data is collected and elaborated, whether through internal systems, external third parties, or publicly available electronic sources.

step 3: problem resolution The problems that are identified during the assessment of the data quality are addressed in this phase. It is important to document data limitations and enable data historization to demonstrate historical data that justifies to the supervisor the remedies applied to deficient data.

step 4: data Quality Monitoring Data quality monitoring involves monitoring the performance of the associated IT systems, based on data quality performance indicators. The frequency with which data quality is monitored, using key performance indicators, raised significant comments during the consultation period.15 From the resolutions, it emerges that data quality monitoring is decoupled from the audit process, and it involves two dimensions: quantitative and qualitative (“the assessment of data quality may make use of adequate objective measures and indicators, but it cannot be dissociated from expert judgment”).16

15 CEIOPS-SEC (106/09), resolution 314–324.16 CEIOPS-SEC (106/09), resolution 198.

Data Source Systems

ETL

Scenario Data

Results

DataDefinition

Data Q

ualityA

ssessment

ProblemResolution

Dat

a Q

ualit

yM

onito

ring

Data QualityManagement



Data quality could be assessed daily, weekly, or even monthly, and the Directive does not indicate the frequency with which the assessment should be performed. On one side, Moody’s Analytics maintains a preference toward avoiding over-prescription and a one-size-fits-all methodology; on the other side, our experience recommends executing the process as frequently as possible. Three reasons support this approach.

1. When, for example, the data is input into actuarial processes that are performed during daily operations, it is clearly convenient to adopt the most updated version of the clean data.

2. It is useful for risk managers and actuaries to meet board members’ requests for new measurements, especially in times of crisis.

3. Data quality assessment, as we explain in the next section, is a continuous process of monitoring and taking action to improve the quality of the data. It is difficult to assure proper continuity if the data is assessed without the proper frequency.

Data Collection, Storage, and Processing The activity of data collection, storage, and processing should be conducted according to the following requirements.17

» transparency » granularity » Accumulation of historical data » traceability

The property of transparency refers to the fact that the logical connection between inputs and outputs should be clear, rather than a “black box.”18

The granularity of data refers to the detail level of data accumulation in the insurance risk data repository. The finer the level of detail (the policy level, eventually to be aggregated via model points), the more robust will be the calculation process downstream.

Historical data should be stored and accumulated on a regular basis in order to evaluate certain technical provisions. Before the consultation period, the original formulation requested insurance companies to accumulate historical data “in general.” However, the final formulation refers only to “relevant data.”19 Therefore, one might question whether the relevant data could change in the future, because of changes in the operating environment (for example, domestic regulatory changes) or for the launch of new insurance products.

While maintaining a preference for avoiding over-prescription and a one-size-fits-all approach, Moody’s Analytics best practices recommend that insurance groups accumulate as much historical data as possible.”20

Finally, the property of traceability refers to the important requirement that any update to the data must be properly documented and audited.

Auditors and the Actuarial Function Internal and external auditors will be in charge of auditing specific datasets, conducting a formal and systematic exam employing techniques commonly adopted by audit professionals.21

Conversely, the insurance company’s actuarial function does not have the responsibility to execute a formal audit on the data. However, the function is required to review data quality by performing “informal examinations of selected datasets” in order to determine and confirm that the data is consistent with its purpose.

17 CEIOPS (43/09), par. 3.81–8518 LLOYD’S (2010), p. 5. 19 We find the definition of “relevant data” in the definition of the criterion of appropriateness: “[it] directly relates to the underlying risk drivers,”

CEIOPS (43/09), par. 3.62.20 The same comment has been raised and “noted” by CEIOPS, see CEIOPS-SEC (106/09), resolution 244, 247. It should also be recognized that,

although more historical date is better than less, the most recent data is usually more appropriate than older data.21 CEIOPS (43/09), par. 3.40–43. Although many comments sent to the consultation paper requested a more detailed definition of the role and scope

of the analysis conducted by auditors and actuaries, this level of detail is outside the scope of the directive on data quality and has been relegated to CEIOPS (33/09).



Identification of Data Deficiencies The assessment of data quality can return a negative result. This can happen because of the presence of one or more of the following.

» singularities in the nature or size of the portfolio » deficiencies in the internal processes of data collection, data storage, or data quality validation » deficiencies in the exchange of information with business partners in a reliable and standardized way

Many deficiencies are examples of low-quality data that is due to singularities in the nature or the size of the portfolio. For example, there might be a data deficit when the frequency of claims is too low or when the business is too young to dispose of enough historical claims data. Other examples could be due to a low volume of business or to an ample variety of claims that impede building (homogeneous) class probabilities. Moreover, legislation changes might reduce the appropriateness of the historical data, because exogenous changes in the operating environment can reduce the adequacy of the historical data accumulated to predict future behavior.

If the deficiency is due to the internal process of data collection, storage, or data quality validation, the responsibility is often assigned to the IT Department or to the high cost of data collection and maintenance.22 In any case, the supervisor will ask the IT department to take the appropriate remedies to ensure the adequacy of the process.23

During the consultation period, many comments were raised about the speed with which a data deficiency should be fixed. The original text mentioned that the insurance company “should take immediate measures to remedy this situation,” but in the final version “immediate” was changed to “appropriate,” displaying the fact that the fix might require significant IT effort, which should be calendarized according to priorities.24

Management of Data Deficiencies In some cases, to enhance the quality of data, the insurance company might apply adjustments to the data. These adjustments must be justified and documented and should not overwrite the raw data.25 This means that there is a clear requirement for tracing and historizing data modifications.

A best practice to apply adjustments in a controlled, documented, and consistent way is the accumulation of data correction rules to be processed against raw data. The data must remain as is; the corrected data must be stored together with the trace of the adjustment that is applied. To increase the efficiency of the data quality validation activity, the execution of data correction rules should be automated and historized.

When the lack of data is unavoidable (for example, due to the nature or the size of the portfolio), the undertaking can apply further adjustments and/or assumptions to the data in the form of approximations. These approximations can be introduced by applying expert judgment that meets the guidelines contained in CEIOPS (33/09). In any case, the application of approximations is never allowed as a substitute for the adoption of appropriate systems and processes that guarantee the appropriate data quality.

When data is adjusted, the assessment of data quality should be conducted at a more granular level, “as it would be made with a view to fit a specific methodology or to review the appropriateness of specific assumptions and parameters.”26

If the data quality assessment suggests it, the insurance company can complement internal data with externally retrieved data (third parties or market data). In the event that external data is adopted, it should be subject to the data quality assessment according to the following qualifications.27

– The appropriateness and completeness test should be conducted at the portfolio level; it can be conducted, if relevant, at a finer level of granularity (individual items).

– The accuracy test is challenging because external information is not collected at the individual level. The test therefore must be conducted on the basis of the reliability of the source of information and the consistency and stability of the source’s processes of data collection at publication.

22 CEIOPS (43/09), par. 3.19.23 CEIOPS (43/09), par. 3.22. 24 See CEIOPS-SEC (106/09), resolutions 274–285.25 For example, “to adapt historical data in case of changes in the operating environment or changes in legislation,” CEIOPS (43/09), par. 3.72.26 CEIOPS (43/09), par. 3.86.27 CEIOPS (43/09), par. 3.89



Moody’s Analytics Best Practices for Data Quality Assessment and Management

A Centralized Approach to Data QualityTo pursue a clean and efficient approach to risk data management, risk calculation engines receive input (hypotheses and parameters, for example) from a centralized risk data repository (Risk Data Warehouse). In this repository, users can define a common meaning to the data across all its various stakeholders (actuaries, IT, financial engineers, risk managers, accountants, and so on).

This approach is widely accepted in the risk management industry, so the next question is: Where should we position the data quality assessment process in reference to the centralized risk data repository? Three options are available for the application of data quality checks. The following section reviews the three options, analyzing their advantages and disadvantages.

Data Quality Pattern One: Data Quality Check in Decentralized Data Source SystemsData quality assessment is performed in the data source systems before importing the data into the Risk Data Warehouse.

ETL

Risk Data Warehouse

DataScenarioResults

Data quality assessmentbefore data import

Data Source Systems

This option has the advantage that the owner of each external data source system can easily manage the data quality checks and the associated data correction rules. However, this case also has a number of disadvantages.

First, in cases where the governance of the data is affected by conflicts between data owners, the users of the data for risk purposes are constantly victims of such conflicts; they are responsible for the data quality in front of the supervisor, but at the same time they do not have the power to fix the data with appropriate reactivity because this activity depends on others.

Second, owners of external data systems are often positioned on the IT side; in such cases, the Solvency II user does not have access to the data quality assessment process.

Third, the management of the data quality checks will become cumbersome. Data quality checks develop in multiple silos, so they can become duplicated and inconsistent. It can often be difficult to identify who should be responsible for data quality checks that address data across multiple systems.



Data Quality Pattern Two: Data Quality Check in ETL toolsData imported into the Risk Data Warehouse is usually performed through an Extract-Transform-Load (ETL) tool. The data is extracted from the source system, transformed in some way, and then loaded into the Risk Data Warehouse.

A possible option is to have data quality checks performed during the transformation phase of the ETL process. This is a natural position for the data checks, from an IT perspective. However, this solution has at least three disadvantages.

First, the data checks are embedded in an extremely technical tool; therefore, the user (the risk manager or actuary) does not have access to the data checks.

Second, the management of a large set of data quality checks can become difficult. An ETL tool is usually configured to manage a number of data flows into the Risk Data Warehouse, and there would be data quality checks inside each data flow. The consequence is that data checks can suffer the same discrepancies mentioned in the preceding example (such as duplication and inconsistency).

Finally, and most important, data quality checks performed during data loading would filter out low-quality data, with the result that not all the available data is loaded into the Risk Data Warehouse. Moody’s Analytics advises against this practice because low-quality data is actually useful for users. The users can analyze the data to understand why it is of low quality, and based on this assessment they can decide what to do with it – use it in the risk calculations, correct it temporarily, and so on.

ETL

Risk Data Warehouse

DataScenarioResults

Data quality assessmentduring data import

Data Source Systems



Data Quality Pattern Three: Data Quality Checks in the Data Warehouse

This option allows users to have direct access to the data quality checks even if the users are not directly responsible for the data quality. This means that the users, in their ordinary activity of modeling and back testing, can have a view of the data quality assessment and can address each single check. For example, they can disable or enable a data check in order to execute what-if analysis (verifying the difference in the results by feeding a certain data into a calculation process). Furthermore, based on the data quality checks that are active in the system, users could apply updates directly to the data without IT intervention. These activities would be impossible in the two previous cases.

Moreover (as discussed in the second pattern), it is beneficial to import all data, including low-quality data. This enables users to assess low-quality data and take appropriate actions.

The main disadvantage of this approach is that users who want to apply permanent corrections to incorrect data would have to act on the source systems directly. This might be seen as a limitation, because the data checks and the correction rules would reside in two different places in the IT architecture. However, we should consider that often the owner of the risk data, in the Risk Data Warehouse, does not coincide with the owner of the data source systems. Therefore, one could incur IT governance conflicts by applying a change in the legacy systems.

The ability to temporarily correct data in the Risk Data Warehouse while waiting for the corrections to be made in the upstream data source systems seems to be a good compromise. This allows the risk manager and the actuary to bypass this problem and demonstrate compliance to the relevant supervisor.* *Data updates are confined to those users who have the required pre-defined permissions to perform them.

ETL

Data quality assessmentafter data import

Risk Data Warehouse

DataScenarioResults

Data Source Systems



Types of Data Quality ChecksBest practices suggest that insurance companies should consider four types of data quality checks.

technical checks These represent technical constraints addressing one or more fields in the data model (even across multiple data tables), such as referential integrity constraints. An example of a technical check could be the following: the book code of an insurance policy does not correspond to any entry in the deal book table.

functional checks These represent functional constraints that are applied to one or more fields in the data model (even across multiple data tables). For example, the birth date of a customer must be prior to the value date of a policy; or the gender of a customer must be male, female, or a company.

Business consistency checks Business consistency checks refer to a specific business meaning of the data and are often associated to data that describes insurance products. These constraints can be applied to one or more fields in the data model (even across multiple data tables). For example, the value of the premium periodicity must be coherent with the type of policy.

general ledger reconciliation From time to time, the data loading activity might be affected by temporary errors or by the omission of portions of data. If, by mistake, a small portion of the portfolio is not loaded, the data quality checks will not reveal any anomaly, the risk calculations will be run, and eventually the results will not display any significant variance (given the small effect of the missing data). The data will be sent to the supervisor containing a bug. Instead, by inserting a reconciliation check, a simple version of the accounting balance sheet can be compared with a balance sheet that is reconstructed based on the imported data.28 This can display problems such as importing a group of 50 policies where the comma disappeared in the value field, leaving all values multiplied by 100. Another example relates to issues associated with foreign exchange rates and foreign subsidiaries not assigning the same common meaning to data.

Each type of data quality check is monitored by a different type of user. For example, technical checks are evaluated and managed by IT, while functional checks are managed either by users with a functional profile (a risk manager) or by users with a technical profile. Business consistency checks are managed by business users (risk managers and actuaries) who are responsible for managing products and single policies. Finally, the general ledger reconciliation is managed by a functional profile that resides at the interface with the accounting department.

The Data Quality Assessment Process and the User The preceding section outlines the importance of giving users access to the data quality assessment process. This section reviews further aspects of this requirement. For example, the Directive assigns specific responsibilities of informal data quality examination to the actuarial function.29

According to Moody’s Analytics best practices, data checks should be expressed in natural language for the user and should be manageable with maximum flexibility, as shown in the following table.

28 The importance of reconciliation with accounting data is recognized in the regulation in CEIOPS (CP 43/09), 1.3.29 CEIOPS (43/09), par. 3.40–43.

Example of a data check



The result of the data quality checks influences the daily activities of actuaries and risk managers.

Moody’s Analytics recommends that insurance companies adopt an infrastructure that allows users to assess the quality of the data through a user-friendly environment that does not require IT intervention. For example, an actuary might want to consider the quality level of a mortality table before performing a given task. A risk manager executing back testing on a certain model might want to directly fix a data inconsistency or calibrate the model in order to circumvent it momentarily.

Furthermore, data quality checks should have different levels of severity to be governed by the actuary or the risk manager. For example, a relevant data quality check may highlight an inconsistency that does not compromise a calculation, while the violation of a mandatory data quality check may determine the exclusion of the data from the calculation.

The following figure shows a user-friendly environment and recognizes three main tasks.

– A list of policies in error

– For each policy, the list of data checks that are violated

– For each data check that is voliated, a graphical identification of the filed error, to enable the user to act on the data (based on the permission status of the user)30

30 Obviously, any software tool that supports this data quality process should also enable automatic correction of inconsistencies.

the figure shows a list of policy errors, the data checks violated, and a graphical identification of the filed error.



The inconsistencies detected by data quality checks should be analyzed by the user at different levels of granularity: from an aggregated level to the finest level of detail. From this point of view, it is useful to leverage drill-down technologies such as OLAP cubes.

Audit and Tracking We have already discussed the requirements of the Directive for tracking and auditing activity. In the following figure we emphasize an audit example for a data change performed on the gender of an insured person:

The following figure shows a table concerning non-life liabilities.

olAp cubes enable users to view data from the aggregated view to the finest level of data.



Finally, we must emphasize the importance of audit and tracking data changes in the context of group consolidation. Managing data at the group level is much more complicated than managing data at the single entity level, because the data auditor and the user might sit far away from each other. A centralized view of the data managing the entire group ensures consistency between the data that feeds the solvency capital calculated in the decentralized entities, and the head of the group.

Furthermore, this approach tremendously facilitates the auditing process, especially when the supervisor makes enquiries such as “Who changed the data in this entity, and why?” and “Did the group-level calculation involve the new or the old version of the data?”

Furthermore, the tracking of data associated to the update performed on the bid price of a security might have the following affect.



ConclusionsSolvency II is the first regulation to provide clear guidelines on how to manage data quality for insurers. This paper has reviewed the content of the regulation, simplifying it and making it accessible to risk managers, actuaries, and Solvency II project and IT managers.

The average insurance company is unprepared for the data quality requirements of the new regulation. This is due to at least three factors.

» the actuarial function is often used to apply professional judgment to the available data for the calculation of the best estimate.

» some insurance companies have been accumulating historical data for many decades. nevertheless, data has typically been collected for daily operational purposes, rather than for the calculation of technical provisions.

» insurance it legacy systems are often outdated, and they are typically organized in multiple silos across different departments; this causes duplication of data and inconsistency of values.

Even the strictest application of the new Directive will not eliminate the expert judgment exercised by the actuarial function. Indeed, the undertaking should interpret the Directive with the goal of making the expert judgment as transparent as possible so that it can be quickly and easily understood by top management.

The core data quality requirements of the Directive focus on the data quality assessment process. The presence of expert judgment means that this process is both quantitative and qualitative. This paper provides a number of best practices that enable insurance companies to leverage technology as a decision support tool (for effective application of expert judgment) and to automate the quantitative aspects of the data quality assessment process.

This paper shows that the application of systematic data quality checks allows insurance companies to increase the reliability of the assessment. The application of a consistent methodology for data correction is vital, to avoid arbitrariness and to enable robust results when data quality must be validated and audited. To this extent, it is also important to leverage a technical platform that allows users to audit and track data quality and manage data correction.

Finally, this paper provides two suggestions that go beyond the Directive. First, the data quality assessment should be conducted as frequently as possible to provide timely calculations. Second, we recommend the accumulation of as much relevant historical data as possible, because it will be extremely valuable for future historical analysis.



Further ReadingCEIOPS (33/09), “CEIOPS Advice for L2 Implementing Measures on SII: System of Governance / CEIOPS’ Resolutions on Comments Received,” former CP 33, https://eiopa.europa.eu/fileadmin/tx_dam/files/consultations/consultationpapers/CP33/CEIOPS-L2-Final-Advice-on-System-of-Governance.pdf

CEIOPS (CP 43/09), “Consultation Paper No. 43, Draft CEIOPS’ Advice for Level 2 Implementing Measures on Solvency II: Technical Provisions – Article 85 f, Standards for Data Quality,” 2 July 2009

CEIOPS (43/09), “CEIOPS Advice for Level 2 Implementing Measures on Solvency II:Technical Provisions – Standard for Data Quality,” former CP 43, https://eiopa.europa.eu/fileadmin/tx_dam/files/consultations/consultationpapers/CP43/CEIOPS-CP-43-09-L2-Advice-TP-Standards-for-data-quality.pdf

CEIOPS-SEC (106/09), “Summary of Comments on CEIOPS-CP-43/09 Consultation Paper on the Draft L2 Advice on TP - Standards for Data Quality,”https://eiopa.europa.eu/fileadmin/tx_dam/files/consultations/consultationpapers/CP43/CEIOPS-SEC-106-09-Comments-and-Resolutions-Template-on-CEIOPS-CP-43-09.pdf

CEIOPS (56/09) “CEIOPS’ Advice for L2 Implementing Measures on SII: Tests and standards for internal model approval,” former CP 56, https://eiopa.europa.eu/fileadmin/tx_dam/files/consultations/consultationpapers/CP56/CEIOPS-L2-Advice-on-Tests-and-Standards-internal-model-approval.pdf

LLOYD’S (2010), “Solvency II, Detailed guidance notes, March 2010, Section 4 - Statistical quality standards,” http://www.lloyds.com/The-Market/Operating-at-Lloyds/Solvency-II/Information-for-managing-agents/~/media/Files/The%20Market/Operating%20at%20Lloyds/Solvency%20II/Dry%20run%20guidance/Section4.pdf


110513

© copyright 2011, moody’s Analytics, inc., and/or its licensors and affiliates (together, “mOODY’s). All rights reserved. All iNFOrmATiON cONTAiNeD HereiN is prOTecTeD BY cOpYriGHT lAW AND NONe OF sUcH iNFOrmATiON mAY Be cOpieD Or OTHerWise reprODUceD, repAcKAGeD, FUrTHer TrANsmiTTeD, TrANsFerreD, DissemiNATeD, reDisTriBUTeD Or resOlD, Or sTOreD FOr sUBseQUeNT Use FOr ANY sUcH pUrpOse, iN WHOle Or iN pArT, iN ANY FOrm Or mANNer Or BY ANY meANs WHATsOeVer, BY ANY persON WiTHOUT mOODY’s priOr WriTTeN cONseNT. All information contained herein is obtained by mOODY’s from sources believed by it to be accurate and reliable. Because of the possibility of human or mechanical error as well as other factors, however, such information is provided “as is” without warranty of any kind and mOODY’s, in particular, makes no representation or warranty, express or implied, as to the accuracy, timeliness, completeness, merchantability or fitness for any particular purpose of any such information. Under no circumstances shall mOODY’s have any liability to any person or entity for (a) any loss or damage in whole or in part caused by, resulting from, or relating to, any error (negligent or otherwise) or other circumstance or contingency within or outside the control of mOODY’s or any of its directors, officers, employees or agents in connection with the procurement, collection, compilation, analysis, interpretation, communication, publication or delivery of any such information, or (b) any direct, indirect, special, consequential, compensatory or incidental damages whatsoever (including without limitation, lost profits), even if mOODY’s is advised in advance of the possibility of such damages, resulting from the use of or inability to use, any such information. The credit ratings and financial reporting analysis observations, if any, constituting part of the information contained herein are, and must be construed solely as, statements of opinion and not statements of fact or recommendations to purchase, sell or hold any securities. NO WArrANTY, eXpress Or implieD, As TO THe AccUrAcY, TimeliNess, cOmpleTeNess, mercHANTABiliTY Or FiTNess FOr ANY pArTicUlAr pUrpOse OF ANY sUcH rATiNG Or OTHer OpiNiON Or iNFOrmATiON is GiVeN Or mADe BY mOODY’s iN ANY FOrm Or mANNer WHATsOeVer. each rating or other opinion must be weighed solely as one factor in any investment decision made by or on behalf of any user of the information contained herein, and each such user must accordingly make its own study and evaluation of each security and of each issuer and guarantor of, and each provider of credit support for, each security that it may consider purchasing, holding or selling. mOODY’s hereby discloses that most issuers of debt securities (including corporate and municipal bonds, debentures, notes and commercial paper) and preferred stock rated by mOODY’s have, prior to assignment of any rating, agreed to pay to mOODY’s for appraisal and rating services rendered by it fees ranging from $1,500 to approximately $2,400,000. moody’s corporation (mcO) and its wholly-owned credit rating agency subsidiary, moody’s investors service (mis), also maintain policies and procedures to address the independence of mis’s ratings and rating processes. information regarding certain affiliations that may exist between directors of mcO and rated entities, and between entities who hold ratings from mis and have also publicly reported to the sec an ownership interest in mcO of more than 5%, is posted annually on moody’s website at www.moodys.com under the heading “shareholder relations — corporate Governance — Director and shareholder Affiliation policy.” credit monitor, creditedge, creditedge plus, creditmark, DealAnalyzer, eDFcalc, private Firm model, portfolio preprocessor, Gcorr, the moody’s logo, the moody’s KmV logo, moody’s Financial Analyst, moody’s KmV losscalc, moody’s KmV portfolio manager, moody’s risk Advisor, moody’s KmV riskcalc, riskAnalyst, riskFrontier, expected Default Frequency, and eDF are trademarks or registered trademarks owned by mis Quality management corp. and used under license by moody’s Analytics, inc.

white paper meeting the data quality management may 2011 ... · this paper has been prepared for...

Documents