Data quality per Solvency II: abbattimento dei silos e ......2012/05/21 · Data quality per...

Data quality per Solvency II: abbattimento dei silos e gestione centralizzata del dato

Massimiliano Neri, [email protected] 22 Maggio 2012

mailto:[email protected]�

CETIF, 22 Maggio 2012

2

La nostra storia comincia all’interno di una cornice di conoscenze provenienti da marchi rinnomati


3

Agenda

1. Introduzione

2. Requisiti funzionali determinati dalla normativa

3. Il problema della compartimentalizzazione del dato (silos)

4. Approccio centralizzato alla gestione del dato

5. Casi di studio

6. Conclusioni


4

Barriera principale per migliorare la gestione del rischio

After the storm: A new era for risk management in financial services

The Economist Intelligence Unit Limited 2009

Presenter

Presentation Notes

Challenge in a short delay= regulatory need+ business need


5

Introduzione

• Solvency II è la prima normativa a stabilire severi requisiti sulla qualità del dato

• Disporre di dati di buona qualità è essenziale per calcolare correttamente le riserve tecniche

• È inutile adottare modelli interni sofisticati senza assicurare che vengano alimentati con dati di alta qualità

Presenter

Presentation Notes

Much effort has been placed, especially with 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 CP 43: This paper deals specifically with the criteria to assess Data Quality, the processes and the systems to use for Data Quality Management, and for the collection, storage and processing of data. Neither of the two papers overrules the other; they should be seen as complementary and indeed both contain cross references to ensure consistency 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 the organization is pursuing. Much of the data used to estimate the technical provisions and to parameterize internal models will be similar and should be subject to the same governance process comments raised by insurance companies and associations during the consultation period. Indeed, in this paper we also point out the areas of the regulation that raised the major concerns and the resolutions taken by CEIOPS based on these concerns


6

Riferimenti bibliografici


7

Agenda

1. Introduzione




5. Casi di studio

6. Conclusioni


8

Sintesi requisiti funzionali normativa europea (1/2)

Storicizzazione del dato • accumulo di dati storici

• Approssimazioni, Decreto Bersani

• Quali dati?

• Rebobinare a versioni precedenti del dato per: • What if analysis

• Fini di supervisione regolamentare

Auditing • Data lineage

• Tracciabilità

• Funzione attuariale e data quality


9

Sintesi requisiti funzionali normativa europea (2/2)

Accuratezza – Controlli di qualità

– Riconciliazione

Granularità • Accuratezza -> singola polizza

Trasparenza


10

Agenda

1. Introduzione




5. Casi di studio

6. Conclusioni


11

Barriera principale per migliorare la gestione del rischio

After the storm: A new era for risk management in financial services

The Economist Intelligence Unit Limited 2009

Presenter

Presentation Notes

Challenge in a short delay= regulatory need+ business need


12

Il problema della compartimentalizzazione del dato (silos)

la causa principale della scarsa qualità dei dati è l'organizzazione dei dati in silos

Tale situazione istiga la duplicazione dei dati e l'inconsistenza dei valori.

I dati vengono organizzati in silos secondo criteri differenti: Tipo di business (vita, danni)

Funzioni differenti all'interno dell'organizzazione (Attuari, Compliance)

Linee di Business differenti

Senior Supervisors Group, “Risk Appetite Frameworks and IT Infrastructure” (December 2010) “confirms that the issue of data aggregation from silos remains a key

challenge”


13

L'origine della configurazione a silos

Cause teoriche Compartimentalizzazione delle funzioni (Risk Management, Funzione

Attuariale, Controllo, IT, ecc) • un potenziale conflitto con le indicazioni strategiche indicate dal top management,

• mancanza di collaborazione tra le funzioni.

• Conseguenza:

• coordinamento propensione al rischio collide con dinamiche scoordinate nei differenti silos

• Program persistence bias

La conoscenza per sua natura è distribuita (Hayek)

mancanza di una teoria soddisfacente per indirizzare aggregazione dei rischio (market vs. credit risk; contagio nelle crisi finanziarie ha determinato un interesse nelle teorie sull’interdipendenza dei rischi)


14

L'origine della configurazione a silos Cause pratiche: Basilea II (*)

ben nota organizzazione tripartita dei tipi di rischio: rischio di credito

rischio di mercato

rischio operativo

una tendenza generale verso dati di bassa qualità, a causa della: proliferazione della duplicazione dei dati

moltiplicazione degli approcci (eterogenei) al trattamento del dato

Approccio sviluppato seguendo un elevato grado di interazione con il supervisore -> grande sforzo di implementazione che il Risk Manager hanno focalizzato esclusivamente sul compimento dei requisiti regolamentari senza lasciare tempo allo sviluppo di best practices

(*) Crouhy M., Galai D., Mark R. (2006), The Essentials of Risk Management, McGraw-Hill.

Kretzschmar G.L., Kirchner K., McNeil J.M. (2009), ‘An Integrated Framework for I

FRS Fair Value Accounting and Institutional Risk Capital Reporting’


15

Ulteriori problemi creati dalla gestione a silos

All’interno di ogni silos il risk manager sviluppa la loro propria tassonomia dei dati, una pratica che rende problematica l'aggregazione dei dati a valle o attraverso diverse linee di business

Tale circostanza ostacola: – l'innovazione in termini di capacità di eseguire attività che si basano su una

visione aggregata del rischio

– ostacola la capacità di rispondere ai nuovi requisiti normativi (ad esempio, i nuovi requisiti di Basilea III richiedono una visione integrata dei dati di rischio).

Infine, per riporre fiducia sui dati utilizzati per rispondere ai requisiti sul reporting regolamentare è necessario disporre di una “single source of trouth" per i dati di rischio a partire dalla quale Risk Management e Compliance possono generare i QRT.


16

Agenda

1. Introduzione




5. Casi di studio

6. Conclusioni


17

Server di calcolo

Cos’è l’approccio centralizzato al dato in

Data Mart

Risultati Data Scenari

ETL Platform

Dati storici

Sistemi informativi alimentanti

Attività ( equity, bonds, …)

&

Passività (Polizze vita e danni)

Workspace

Workspace

Workspace

Data Quality Checks

Riconciliazione con Contabilità Generale &

Audit

Reporting regolamentare per ISVAP

Gli utenti possono accedere agli stessi dati da viste configurate in maniera diversa

L’attività di ogni utente si svolge in un workspace

dedicato associato a sessionie sicura (autenticazione,

autorizzazione, data access)

Consente di gestire grandi quantità di dati storici con

un accurato dettaglio

Dati contabili

Dati vita

e danni Dati di

mercato

Dati copertura sanitaria

Presenter

Presentation Notes

We provide a Robust, Secure and Exhaustive Data Mart…


18

Inputs for SCR Calculation/Reporting

Prepare data for SCR & Reporting

VALUATION_IMPORT

CASH_FLOW_IMPORT

SCR Calculation

Results of Calculation Engines CASH_FLOW VALUATION

Reporting

SCR

SCR_IMPORT

ASSET_DATA

LIABILITY_DATA

SCR_IMPORT

LIAIBILITY_IMPORT

…_IMPORT

Profondità dell’auditing in base alla centralizzazione dato

Moodys DataMart LIABILITIES_DATA ASSET_DATA …

Calculation Engines

…

VALUATION_IMPORT

CASH_FLOW VALUATION …

…

Interface point 1

Interface point 2

Interface point 3

Interface point 4


19

Approccio centralizzato per la qualità del dato: pattern 1

Results DataScenario

ETL

Data Source Systems

Data Quality AssessmentBefore data import

…..

Presenter

Presentation Notes

In order to pursue a clean and efficient approach to risk data management, risk calculation engines receive input (hypotheses, 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, etc.). This option has the advantage that the owner of each external data source system can manage easily the data quality checks and the associated data correction rules. However, this case bears 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 will be constantly victim of such conflicts; they will be responsible for the data quality in front of the supervisor, but at the same time they will 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, therefore the Solvency II user will not have access to the Data Quality Assessment process. Third, the management of the data quality checks will grow cumbersome. Data quality checks develop in multiple silos therefore they may become duplicated and inconsistent and it can often be problematic to identify who should be responsible for data quality checks that address data across multiple systems.


20



ETL

Data Source Systems

Data Quality AssessmentDuring data import

…..

Presenter

Presentation Notes

This is a natural position to have 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 (risk manager or actuary) does not have access to them. Second, the management of a large set of data quality checks can become difficult. An ETL is usually configured to manage a number of data flows into the Datamart, and you would have data quality checks inside each data flow. The resulting consequence is that data checks may suffer the same discrepancies mentioned in the previous case (such as duplication and inconsistency). Finally, and most importantly, data quality checks performed during data loading would filter out low quality data, with the result being that not all the available data is loaded into the Risk Data Warehouse. We advise against this practice because disposing of low quality data is actually useful for users. They can analyze the data to understand why it is of low quality and based on this assessment decide what to do with it – use it in the risk calculations or not, correcting it temporarily or not.


21



ETL

Data Source Systems

Data Quality AssessmentAfter data import

…..

Best Practices: importare "tutti" i dati, compresi quelli di scarsa qualità, in modo che l'utente possa valutarli e prendere le decisioni appropriate.

Presenter

Presentation Notes

ADV This option allows users to have direct access to the data quality checks (even if they 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 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 or not a certain data into a calculation process). Furthermore, based on the data quality checks 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. BP: Moreover (as discussed in the second pattern) it is beneficial to import all the data, including the low quality data. This will enable the user to assess low quality data and take appropriate decision (for example, should the data be used for a specific calculation?). DIS The main disadvantage with this approach is that users who want to apply permanent corrections to incorrect data, would have to act on the source systems directly. This may be seen as a limitation because the data checks and the correction rules would reside in two different places in the IT architecture. However, the owner of the risk data, in the Data Warehouse, does not coincide with the owner of the data source systems. Therefore, one may incur IT governance conflicts by applying a change in the legacy systems. BP: Hence, the possibility to temporarily correct data in the Data Warehouse while waiting for the application of the proper fixes in the upstream data source systems seems a good compromise to allow the risk manager and the actuary to bypass this problem and be demonstrate compliance for the relevant supervisor.


22

Tipi di controlli di qualità dei dati

Controlli tecnici Il "codice" di una polizza non corrisponde a nessuna voce nella tabella dei codici dei contratti

Controlli funzionali

La data di nascita di un cliente dev’essere precedente alla data di sottoscrizione della polizza.

Il sesso del cliente deve essere “maschio”, “femmina” o una “società”.

Controlli di business

Il valore della “periodicità del premio“ deve essere coerente con il tipo di polizza.

Riconciliazione con la contabilità generale

Importazione di un gruppo di 50 polizze, il punto decimale scompare in un campo con valore monetario, lasciando tutti i valori moltiplicati per 100.

Un altro esempio riguarda gli aspetti connessi al tasso di cambio e al significato che assegnano le consociate estere ai valori monetari.

Presenter

Presentation Notes

These represent technical constraints addressing one or more fields in the data model (even across multiple data tables), such as referential integrity constraints. These represent functional constraints applied to one or more fields in the data model (even across multiple data tables). Business Consistency Checks refer to a specific business meaning of the data and are often associated to data describing insurance products. From time-to-time the data loading activity may be affected by temporary errors or 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, risk calculations will be run and eventually the results will not display any significant variance (given the small impact of the missing data). The data will be sent to the supervisor containing a bug. Instead, by inserting a reconciliation check, we can compare a simple version of the accounting balance sheet with a balance sheet reconstructed based on the imported data. Each type of data quality check is monitored by a different type of user. For example, technical checks shall be evaluated and managed by IT, while functional checks shall be managed either by users with a functional profile (a risk manager) or with a technical profile. Business consistency checks shall be managed by business users (risk managers and actuaries) that are in charge or managing products and single policies. Finally, the general ledger reconciliation shall be managed by a functional profile that resides at the interface with the accounting department.


23

Il processo di valutazione della qualità dei dati e l’utente

Best practices: espressione dei controlli di qualità in linguaggio naturale


24


Best practices: consentire agli utenti di valutare la qualità dei dati attraverso un ambiente user-friendly

Presenter

Presentation Notes

For example an actuary may 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 may 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.


25


Best Practices: analizzare le incongruenze rilevate dai controlli di qualità a diversi livelli di granularità

Presenter

Presentation Notes

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.


26

Agenda

1. Introduzione




5. Casi di studio

6. Conclusioni


27

Caso di studio 1: uno dei principali gruppi italiani

Contesto:

• 11 entità, una in applicazione per modelli interni con ISVAP

• Architettura di gruppo per motori vita, danni e aggregazione

• Organizzazione delle fonti alimentanti in silos

Necessità:

• Adozione di un modello dati di riferiemento, sia per chi adotta standard formula che modelli interni

• Adozione di capabilities out of the box per velocizzare l’implementazione della data quality (evitare di realizzare nuovamente la ruota)

• Facilità di integrazione con modelli vita e danni esitenti

Soluzione:

» Inserilento di un layer SII fra motori e datawarehouse esistenti per creare un repositorio centralizzato a supporto di: – Alimentazione motori, accogliere output intermedi e finali calcolo flussi e SCR

– Supporto per generazione report regolamentari (QRT)


28

Caso di studio 2: entità italiana di gruppo internazionale Contesto:

• Modelli (sia vita che danni) centrallizzati sulla capogruppo francese

Necessità:

• Necessita di raccolgire secondo un modello dati comune, tutte le fonti alimentanti per abilitare i processi di alimentazione dei motori di casa madre

• Capacità di modellazione delle polizze dell’entità italiana secondo metodologie di gruppo (flessibilità)

Soluzione:

» Costituzione di un datamart centralizzato per – Alimentazione motori di casa madre

– Storage dei risultati

– Generazione report regolamentari (QRT) ISVAP


29

Agenda

1. Introduzione




5. Casi di studio

6. Conclusioni


30

Conclusioni

1. In generale le compagnie assicurative non sono preparate a compiere i requisiti di qualità dei dati della nuova normativa. Ciò è dovuto a tre fattori:

a) La funzione attuariale applica spesso l’expert judgment ai dati a disposizione per calcolare il Best Estimate.

b) Alcune compagnie di assicurazione hanno accumulato dati storici, anche per decenni. Tuttavia, spesso le informazioni sono state raccolte per il funzionamento dell'operatività quotidiana, piuttosto che per il calcolo delle riserve tecniche.

c) I sistemi IT delle compagnie di assicurazione sono spesso obsoleti e organizzati in silos che appartengono a dipartimenti diversi (duplicazione dei dati e incoerenza nei valori).

2. La valutazione della qualità dei dati (Data Quality Assessment) è il requisito centrale

3. Abbattimento dei silos

4. Gestione centralizzata del dato orientata alla funzione attuariale e di Risk Management

Presenter

Presentation Notes

Solvency II is the first regulation to provide clear guidelines on how to manage data quality. In this paper we have reviewed the content of the regulation, simplifying it and making it accessible to Risk Managers, Actuaries and IT Managers. Even the strictest application of the new Directive will not eliminate the expert judgment exercised by the actuarial function. Rather, the undertaking should interpret the Directive with the vision of rendering transparent the expert judgment as much as possible, auditable and promptly understandable by top management The presence of expert judgment means that this process is both quantitative and qualitative. In this paper we have provided a number of best practices that allow 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. The application of a consistent methodology for data correction is vital, to avoid arbitrariness and enable robust results when data quality must be validated and audited.

Data quality per Solvency II: abbattimento dei silos e ......2012/05/21 · Data quality per...

Documents

Transcript of Data quality per Solvency II: abbattimento dei silos e ......2012/05/21 · Data quality per...