> Disclaimer: Questo contenuto è destinato esclusivamente a scopi educativi e di riferimento per sviluppatori software. Non costituisce consulenza legale, normativa, attuariale o finanziaria. Consultare un professionista qualificato prima di prendere decisioni basate su questo contenuto.
1. Modellare la Polizza come Event Log Append-Only
Non aggiornare mai un record di polizza in-place. Ogni modifica - endorsement, cancellazione, reintegrazione, adeguamento del premio - deve essere registrata come nuovo evento con timestamp, attore e codice di motivo. Lo stato corrente della polizza si ottiene riproducendo gli eventi dall'inception. Questo pattern soddisfa i requisiti di ricostruzione regolamentare (ispezioni DoI/IVASS, governance Solvency II art. 272), previene la perdita accidentale di dati e abilita snapshot attuariali a qualsiasi data storica.
2. Taggare Ogni Transazione con la Linea di Business al Momento della Scrittura
Il LOB (Linea di Business) deve essere un campo obbligatorio e validato su polizze, sinistri, premi e transazioni finanziarie - mai derivato o inferito al momento della reportistica. Il LOB guida i depositi regolamentari (dichiarazioni statutarie NAIC, QRT S.05.01 Solvency II), i triangoli attuariali e la reportistica gestionale. Archiviare il LOB su ogni riga elimina gli errori di riclassificazione e consente estrazioni accurate senza conoscere le future variazioni del mapping regolamentare.
3. Archiviare il Premio Maturato Separatamente dal Premio Contabilizzato
Il premio contabilizzato è rilevato all'inception della polizza; il premio maturato matura nel tempo. Mantenere entrambi: written_premium (costante dopo la conclusione) e earned_premium_to_date (campo calcolato o colonna materializzata aggiornata ad ogni data di riferimento). Per il calcolo dell'UPR: upr = written_premium − earned_premium. Non confondere mai i due - i depositi regolamentari, i loss ratio e la passività PAA IFRS 17 per la copertura residua dipendono tutti dalla corretta separazione tra maturato e non maturato.
4. Implementare le Riserve Sinistri a Livello di Singolo Sinistro
Le riserve caso devono essere archiviate per sinistro, non aggregate a livello di portafoglio. Ogni revisione della riserva deve essere un nuovo record (append-only) con revised_at, revised_by, previous_reserve, new_reserve e reason. Questa granularità è obbligatoria per: costruzione del triangolo di sviluppo perdite (derivazione LDF attuariale), validazione IBNR (confronto tra sviluppo effettivo e modello), ispezione regolamentare e rilevamento delle frodi (pattern nelle revisioni delle riserve). L'IBNR è una stima aggregata separata a livello LOB/periodo - non collassare mai l'IBNR nei record di singolo sinistro.
5. Separare gli Importi Lordi, Ceduti e Netti in Ogni Tabella
Per ogni quantità finanziaria oggetto di riassicurazione, archiviare tre colonne: gross_amount, ceded_amount, net_retained_amount con il vincolo net_retained_amount = gross_amount − ceded_amount. Non archiviare mai solo gli importi netti. I depositi regolamentari (Schedule P NAIC, QRT S.17 Solvency II), la reportistica gestionale e la liquidazione riassicurativa richiedono tutti i valori lordi e ceduti in modo indipendente. Violare questo pattern richiede una ricostruzione costosa al momento dell'ispezione.
6. Registrare i Metadati dell'Esecuzione del Cat Model con Ogni Stima di Perdita Modellata
Quando si archiviano gli output del modello catastrofale, registrare sempre accanto alla cifra di perdita: model_vendor (es. RMS, AIR, CoreLogic), model_version, peril, return_period_years e run_date. I risultati del cat model sono sensibili alla versione - lo stesso portafoglio produrrà stime di perdita diverse tra versioni del modello. Archiviare i metadati dell'esecuzione consente confronti storici, disclosure regolamentare (versione del cat model usata nel calcolo SCR) e audit trail dei contratti riassicurativi.
7. Usare Vocabolari Controllati per i Codici Motivo dei Reclami
I codici motivo dei reclami assicurativi devono essere mappati a una tassonomia regolamentata. In Italia, allinearsi ai codici IVASS (IVASS Regolamento n. 40/2018 sulla gestione dei reclami). Negli USA, allinearsi ai codici reclamo NAIC (15+ categorie standard). Non usare mai categorie di reclamo in forma libera - impediscono la reportistica aggregata obbligatoria all'autorità di vigilanza, rendono impossibile l'analisi dei trend e falliscono le ispezioni regolamentari. Implementare il vocabolario controllato come tabella di riferimento con l'intervallo di date di validità, in modo che gli aggiornamenti alla tassonomia siano versionati e i record storici conservino il codice originale.
8. Archiviare Ogni Deposito Regolamentare con Tracciamento dello Stato
Ogni presentazione regolamentare (deposito tariffe statale, dichiarazione annuale, QRT Solvency II, SFCR) deve avere un record filings corrispondente che traccia: tipo di deposito, giurisdizione, data di presentazione, numero di riferimento (numero di controllo DoI o ID deposito XBRL), stato corrente (IN_ATTESA / APPROVATO / OBIETTATO / RITIRATO), data di approvazione e dettagli dell'obiezione. Implementare una macchina a stati per i depositi - non inferire mai lo stato di approvazione dall'assenza di obiezione. Molti workflow DoI approvano tacitamente i depositi dopo un periodo di attesa; questa regola "il silenzio è approvazione" deve essere codificata come job schedulato che fa transitare lo stato dopo il termine regolamentare.
9. Implementare il Controllo di Idoneità PAA IFRS 17 come Decisione Documentata
Per ogni gruppo di contratti assicurativi, la decisione di applicare il PAA versus il GMM deve essere formalmente documentata. Il criterio principale - periodo di copertura ≤12 mesi - deve essere valutato al rilevamento iniziale e archiviato come campo sul record del gruppo contrattuale insieme alla data di valutazione e all'ID del valutatore. Per le polizze pluriennali con periodi di copertura annuali, documentare l'analisi specifica di idoneità. I revisori richiederanno evidenza che l'elezione PAA sia stata effettuata con una motivazione documentata, non assunta per default.
10. Versionare la Tabella delle Assunzioni Attuariali
I parametri attuariali (tassi di sconto, fattori di sviluppo perdite, fattori di coda, assunzioni di frequenza/severità dei sinistri) devono essere versionati con date di efficacia, non aggiornati in-place. Ogni record actuarial_run deve fare riferimento alla versione actuarial_assumptions_version utilizzata. Questo consente: (a) ricostruzione di qualsiasi cifra di riserva storica, (b) analisi di attribuzione (quanta parte dello sviluppo delle riserve è variazione del modello vs. esperienza), (c) evidenza di governance ai sensi dell'art. 78 Solvency II che le assunzioni sono state riviste e approvate indipendentemente.
11. Applicare la Regola No-Leakage nel Settlement Riassicurativo
Quando si calcola l'importo dovuto a un riassicuratore nell'ambito di un trattato proporzionale, applicare sempre: premio_ceduto = premio_contabilizzato × percentuale_cessione. Non applicare mai il tasso di cessione al premio maturato per il settlement del premio (i settlement avvengono su base contabilizzata; i rimborsi esperienza o le scale variabili sono calcoli separati). Implementare questo come vincolo di database o asserzione a livello applicativo - gli errori qui impattano direttamente il P&L e possono generare controversie riassicurative.
12. Registrare Tutti gli Output QRT Solvency II con la Versione della Tassonomia XBRL
Ogni presentazione QRT Solvency II deve registrare: taxonomy_version (EIOPA pubblica annualmente), reporting_period, submission_deadline, actual_submission_date, entity_xbrl_id (LEI o identificatore dell'entità XBRL) e l'insieme completo dei punti dati segnalati con chiave ai riferimenti di concetto EIOPA (es. S.05.01.01.01 - premi contabilizzati, lordi). Archiviare i dati rispetto ai riferimenti di concetto anziché alle label leggibili previene gli errori di mapping quando EIOPA aggiorna la tassonomia. Implementare un'estrazione automatica dei QRT che mappa i codici LOB interni alle classificazioni LOB EIOPA tramite una tabella di configurazione aggiornata ad ogni ciclo di tassonomia.
13. Implementare il Monitoraggio dell'Aggregato Catastrofale con Accumulo in Tempo Reale
I trattati riassicurativi aggregati (stop-loss, XL aggregato) hanno punti di aggancio definiti come percentuale del premio maturato o come importo assoluto di perdita su tutte le occorrenze nel periodo del trattato. I builder devono implementare l'accumulo aggregato in tempo reale: somma di claim_reinsurance_recoveries.gross_loss per i sinistri nel periodo del trattato. Emettere un alert quando l'accumulo raggiunge il 70% e il 90% del punto di aggancio. Il mancato monitoraggio dell'accumulo significa che la cedente può superare inavvertitamente l'aggancio senza attivare il calcolo del recupero.
14. Archiviare le Scadenze SLA dei Reclami del Consumatore come Colonne Calcolate
Ogni reclamo del consumatore deve avere una resolution_deadline archiviata come colonna calcolata al momento della creazione: resolution_deadline = received_at + state_sla_days dove state_sla_days proviene da una tabella di configurazione state_complaint_slas (non hardcoded). In Italia, IVASS Regolamento n. 40/2018 prevede termini specifici (tipicamente 45 giorni per le risposte ai reclami); negli USA ogni DoI statale specifica il proprio SLA (tipicamente 15-30 giorni lavorativi). Implementare un job giornaliero che segnali i reclami in avvicinamento alla scadenza (deadline_approaching_at = resolution_deadline − INTERVAL '5 giorni'). Il superamento degli SLA dei reclami può comportare sanzioni da parte dell'IVASS/DoI e costituisce evidenza di fallimenti sistematici nella gestione dei sinistri.