Solvency II Data quality and controls

Transcription

1 Solvency II Data quality and controls Presentation by David Roberts 15 July 2011

2 Regulatory guidance on data quality EIOPA/LLOYD S CEIOPS DOC 37/09 (formerly CP43) paragraphs 3.56 to 3.90 Level 1 text: Article 82 Member States shall ensure that insurance and reinsurance undertakings have internal processes in place to ensure the appropriateness, completeness and accuracy of the data used in the calculation of their internal provisions. CEIOPS DOC 33/09 paragraphs 3.32 to 3.37 and FSA Level 1 text: Article 84 Insurance and reinsurance undertakings shall demonstrate the appropriateness of the level of their technical provisions as well as the applicability and relevance of the methods applied and the adequacy of the underlying statistical data used. SYSC G Management information A firm's arrangements should be such as to furnish its governing body with the information it needs to play its part in identifying, measuring, managing and controlling risks of regulatory concern. Three factors will be the relevance, reliability and timeliness of that information.

3 Defining good data quality Presentation by Peter Kumik 15 July 2011

4 Purpose of today s presentation Solvency II data quality Appropriate response Checklist of issues Toolkit to use

5 What is the problem? Simple to define Good quality data Evidence of this Nothing new but increased external scrutiny Systems are complex Multiple applications Multiple suppliers History of development Mergers & acquisitions Different uses of data require different tests of adequacy

6 Foundations of good data quality Systems Infrastructure Data processing Reporting People Suitability for role with clear responsibilities Training Understanding of systems, policies & procedures Controls Input & output Documentation Technical & user

7 How do you define what is relevant? Define the data that is used to deliver significant information Data is not the same as the system Don t waste time on non-critical data One size does not fit all To ensure data quality you must look across all the foundations All Data Pricing Exposure Solvency II Model

8 What is good data quality? Data should be good enough for the purpose for which it is to be used Data will normally be good enough if: it is not a source of misleading output decisions made on the basis of that output are well-founded information is available in a timely and appropriate manner Data is not good enough if: output has to be adjusted for underlying data issues decisions need to take into account adjustments to deal with data issues information is not available in a timely and appropriate manner

9 The organisational data model Capturing Storing Processing Underwriting Compliance Claims Data Warehouse Solvency II MI MI Finance Generally a validated environment Generally an unvalidated environment Model Input

10 The need for more structured data Telephone Number x Tel1 Tel2 2 Work Mobile Contact ID 1271 ID Type Home Office Mobile Number Country Extension

11 Reporting accuracy Policy LOB Customer AR1786 AC BF2698Z F abj Premium 126,700 12, , ,988 23,015 7,688 LOB Code Description Private Taxi Motor Trade Commercial LOB Taxi Motor Trade Commercial Total Total Premium 164, , , ,925 =? 1 2 3

12 Risk areas Storing the same data in more than one place Restructuring data Data errors not being adjusted at source Historical data anomalies Cut-off & timing Lack of appropriate skill sets Processes that are no longer understood Lack of understanding of data provenance and content How do you know the data is complete and accurate (controls)?

13 Real world examples Managing agent IT making changes directly to data warehouse (and without informing users): inaccurate management reports. Managing agent Two parallel databases unable to cross reference: inability to reconcile payments to claims. Motor insurer Legacy data different shape to replacement system format: inability to combine historical data with current data for reporting and reconciliation purposes.

14 Summary There is nothing new apart from increased scrutiny Regulatory language vague define an appropriate & proportionate response Focus on significant data No standard methodology that will solve the problem Checklist of issues to focus on Proven techniques to verify and evidence good data quality

15 Validating and evidencing data quality Presentation by Ian Singer 15 July 2011

16 General approach to validation and documentation Key words Proportionality not perfection Appropriateness suitable and pragmatic Completeness in context Accuracy in context Guidelines Proportionality is a key concept within Solvency II. Appropriateness suitable for the intended purpose Completeness sufficient in total and in granularity Accuracy free from material mistakes, errors, omissions Documentation - the test standard is whether another, suitably skilled, individual could reproduce the results based on the documentation and data alone.

17 Validating and evidencing good data quality Data capture Data processing systems field validation/control reports External feeds data validation/control reports Validating Data Processes Usage standard reporting/spreadsheets/ad-hoc reporting Independent review internal or external Evidencing Data flows Process documentation Test results

18 What to test and how to test it Significance of data risk assessment Level of significance Level of likely error Level of existing controls Source of data internal/external 3 rd party vs in-house Bespoke vs package Testing methodology - tailored approach Type of testing Frequency of testing Sample size Assign responsibility for definition and execution Independent verification

19 Validation methods options and when to use them Controls testing should be 100% provable Control processes Control totals hash/financial/record counts Independent data source Sanity checks Finance and IT other departments where relevant Sample testing might be 100% provable Source documents to entered data Entered data to data warehouse/reporting solution Data point testing probably not 100% provable Points in the grid Database queries Specialist review High risk always Medium risk - often Low risk - sometimes

20 Appropriate documentation Systems and processes Data flow diagram significant data only ETL Extract, Transform, Load Key processes description Key controls description Evidence Control sheets Test results Independent reviews

21 Conclusion Data quality does not need to be perfect Assessing precisely whether the data quality is sufficient is likely to be judgemental and involve heavy use of the proportionality principle. It will be difficult to define an exact threshold of data quality which must be passed. This means documentation of decisions is essential. Deciding on whether the data quality requirements are met, given application of proportionality, will be a difficult task. This is no different to the current situation. Documentation The test standard is whether another, suitably skilled, individual could reproduce the results based on the documentation and data alone.

22 This guide is prepared as a general guide. No responsibility for loss occasioned to any person acting or refraining from action as a result of any material in this publication can be accepted by the author or publisher. Always seek professional advice before acting. Littlejohn