> 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.
Quali campi sono necessari per modellare il ciclo di vita completo di una polizza assicurativa?
Un record del ciclo di vita della polizza richiede, come minimo: policy_id, quote_id (tracciabilità alla quotazione), insured_id (FK al cliente), product_code, line_of_business, effective_date, expiry_date, written_premium, payment_frequency, status (enum: QUOTATA/VINCOLATA/EMESSA/IN_VIGORE/DISDETTATA/SCADUTA/IN_RUN_OFF), cancellation_reason, cancellation_date, created_at, updated_at. Per i rischi property: aggiungere location_id, tiv, construction_type. Per la responsabilità: aggiungere limit_per_occurrence, aggregate_limit, retroactive_date. Il campo status guida tutti i calcoli finanziari downstream (UPR, premio maturato, rilascio riserve).
Come si calcola la Riserva Premi (UPR) a livello di codice?
UPR per una singola polizza alla data di riferimento D: upr = premio_contabilizzato × (giorni_residui / giorni_totali) dove giorni_residui = MAX(0, expiry_date − D) e giorni_totali = expiry_date − effective_date. Per l'aggregazione per LOB: SELECT lob, SUM(written_premium * GREATEST(0, expiry_date - :report_date) / NULLIF(expiry_date - effective_date, 0)) AS upr FROM policies WHERE status = 'IN_VIGORE'. Per le polizze pluriennali, applicare la stessa formula per ogni segmento annuo, non sull'intera durata contrattuale.
Quali sono i dati minimi per costruire un triangolo attuariale di sviluppo perdite?
Un triangolo di sviluppo richiede: anno_accadimento (o trimestre di accadimento), eta_sviluppo (mesi dall'inizio dell'anno di accadimento alla data di valutazione), perdite_pagate_cumulative, perdite_incorse_cumulative (pagate + riserva caso). Questi quattro campi, raggruppati per LOB e compagnia, consentono il calcolo dei Loss Development Factor (LDF) con il metodo chain-ladder. I builder devono archiviare i sinistri con questa granularità - non solo i saldi totali - per supportare l'estrazione attuariale senza aggregazioni personalizzate.
Come si modella un reclamo del consumatore nel codice?
Record minimo di reclamo: complaint_id, policy_id (nullable se pre-polizza), complainant_type (CONTRAENTE, TERZO, REGOLATORE), received_at (TIMESTAMPTZ), channel (TELEFONO, EMAIL, POSTA, PORTALE, SEGNALAZIONE_REGOLATORE), complaint_reason_code (vocabolario controllato allineato ai codici NAIC o IVASS), complaint_text, status (RICEVUTO/IN_ISTRUTTORIA/RISOLTO/ESCALATO/DEFERITO_IVASS), resolution_at, resolution_code, regulatory_filing_ref (se segnalato a IVASS/DoI). Molti Paesi/Stati richiedono la segnalazione annuale dei reclami all'autorità di vigilanza - archiviare stato e regolatore_notificato booleano con timestamp.
Qual è la differenza tra riserva sinistri e IBNR?
La riserva caso (riserva sinistri) è una stima del pagamento futuro per un sinistro specifico, già denunciato e aperto - fissata dal liquidatore per ogni sinistro aperto. L'IBNR (Incurred But Not Reported) è una stima attuariale aggregata per perdite verificatesi ma non ancora denunciate all'assicuratore. L'IBNR non è a livello di singolo sinistro; è una passività di bilancio calcolata da modelli di sviluppo. I builder archiviano le riserve caso per record di sinistro; l'IBNR è archiviato come record di stima attuariale a livello LOB/periodo.
Come si modella la struttura delle cessioni riassicurative nello schema dati?
Tre tabelle: (1) reinsurance_treaties - treaty_id, treaty_type (QS/SURPLUS/XL/STOP_LOSS), attachment_point, limit, cession_percentage, reinsurer_id, effective_date, expiry_date. (2) cession_statements - statement_id, treaty_id, period_start, period_end, ceded_premium, ceded_losses, ceded_lae. (3) claim_reinsurance_recoveries - recovery_id, claim_id, treaty_id, gross_loss, ceded_amount, net_retained. Non combinare mai gli importi lordi e netti in un unico campo - i depositi regolamentari richiedono separatamente lordo, ceduto e netto per ogni periodo e LOB.
Quali dati QRT Solvency II deve fornire un sistema di polizze?
Il QRT S.05.01 (Premi, sinistri e spese per LOB) richiede: premio contabilizzato, premio maturato, sinistri incorsi, sinistri pagati, spese operative - tutti suddivisi per classificazione LOB di Solvency II (non per codice prodotto interno). Il QRT S.17 (Non-vita) richiede le riserve tecniche best estimate. Il QRT S.19 (Triangoli di sviluppo sinistri) richiede dati cumulativi pagati/incorsi per anno di accadimento e anno di sviluppo. I builder devono mantenere una tabella di mapping dai codici prodotto interni ai codici LOB Solvency II e assicurarsi che tutte le transazioni siano taggate al momento della scrittura, non rimappate al momento della reportistica.
Come si implementa il calcolo del SCR (Solvency Capital Requirement)?
La formula standard SCR è un calcolo modulare: rischio di mercato, rischio di credito, rischio di sottoscrizione vita, non vita e salute - aggregati con una matrice di correlazione. Per il sotto-modulo rischio di sottoscrizione non vita, il modulo rischio premi e riserve utilizza misure di volume (premio maturato netto per LOB) e deviazioni standard dalle calibrazioni EIOPA. I builder importano tipicamente i parametri standard EIOPA da una tabella di configurazione anziché codificarli rigidamente, consentendo aggiornamenti quando EIOPA rivede le calibrazioni. L'output SCR (una singola cifra di capitale) e la sua decomposizione per modulo sono archiviati in un record di calcolo periodico con calculation_date, method e i valori per sotto-modulo.
Quali campi sono obbligatori in un deposito regolamentare assicurativo?
I requisiti comuni per i depositi regolamentari USA includono: filing_type (ANNUAL_STATEMENT, QUARTERLY, RATE_FILING, FORM_FILING), naic_company_code, state_of_domicile, filing_state, doi_tracking_number, filing_date, period_start, period_end, status (PENDING/APPROVATO/OBIETTATO/RITIRATO). I depositi tariffe e moduli richiedono inoltre effective_date_requested, approval_date, objection_reason. I builder devono tracciare i depositi per DoI - un singolo deposito può essere presentato a più stati con numeri di tracking e workflow di approvazione separati.
Che cos'è IFRS 17 e quale modello di misurazione si applica alla maggior parte delle polizze non vita?
IFRS 17 è lo standard contabile internazionale per i contratti assicurativi, efficace dal gennaio 2023. Introduce tre modelli di misurazione: (1) GMM (General Measurement Model) - per contratti vita a lungo termine e complessi; (2) PAA (Premium Allocation Approach) - una semplificazione per contratti a breve durata (≤1 anno di copertura) che approssima la passività per copertura residua come riserva premi; (3) VFA (Variable Fee Approach) - per contratti partecipativi. La maggior parte delle polizze non vita property e casualty è idonea al PAA. I builder devono implementare un controllo di idoneità per ogni gruppo di contratti e registrare il modello di misurazione eletto come campo sul record del gruppo contrattuale.
Come funziona il ciclo di gestione dei reclami NAIC come macchina a stati?
I codici reclamo NAIC definiscono: il motivo del reclamo (15+ categorie: gestione sinistri, marketing, sottoscrizione, fatturazione, servizio polizza, ecc.) e la disposizione (accolto, respinto, ritirato, ecc.). Una macchina a stati per la gestione dei reclami prevede gli stati: RICEVUTO → CONFERMATO → ISTRUTTORIA → IN_ATTESA_RISPOSTA → RISOLTO → CHIUSO (terminale). Percorso di escalation: da qualsiasi stato → ESCALATO_REGOLATORE. Ogni transizione di stato deve registrare transitioned_at, transitioned_by_user_id e reason_note. Gli obiettivi SLA (spesso 30 giorni per la risoluzione) sono tracciati tramite deadline_at = received_at + INTERVAL '30 giorni' (varia per DoI/IVASS).
Come si devono archiviare gli endorsement rispetto alla polizza base?
Un endorsement modifica uno o più termini di una polizza esistente nel corso del periodo di vigenza. Modellare come tabella endorsements: endorsement_id, policy_id, endorsement_number (sequenziale per polizza), effective_date, endorsement_type (ADD_COPERTURA, RIMUOVI_COPERTURA, MODIFICA_LIMITE, MODIFICA_INDIRIZZO, ecc.), change_description, additional_premium (positivo o negativo), issued_at. Non sovrascrivere mai il record di polizza base - lo stato corrente della polizza è la polizza base più tutti gli endorsement efficaci ordinati per data di efficacia. Questo pattern append-only supporta le query di audit a qualsiasi data storica e la ricostruzione regolamentare dei termini di polizza.
Quali dati richiede la modellazione catastrofale dal sistema di polizze?
Input del cat model per location: location_id, latitude, longitude, geocode_quality_code, construction_type (classe di costruzione ISO), occupancy_code (classe di occupazione ISO), year_built, number_of_stories, tiv, replacement_cost_value, deductible_amount, policy_limit. Output del cat model da archiviare: model_vendor, model_version, peril (URAGANO/TERREMOTO/ALLUVIONE/INCENDIO_BOSCHIVO), return_period (anni), modeled_loss_amount, aep_exceedance_probability, run_date. Archiviare gli output in una tabella cat_model_results con chiave (location_id, model_vendor, model_version, peril, return_period).
Come si implementa il CSM (Margine per Servizi Contrattuali) in IFRS 17?
Il CSM rappresenta il profitto non maturato di un gruppo di contratti assicurativi. Al rilevamento iniziale: CSM_0 = VA(flussi_in_entrata_futuri) − VA(flussi_in_uscita_futuri) − RA_0 dove RA è l'aggiustamento per il rischio. Se questo valore è negativo (gruppo oneroso), rilevare immediatamente una perdita e impostare CSM = 0. In ogni periodo successivo: adeguare il CSM per: (a) maturazione degli interessi al tasso di sconto bloccato, (b) variazioni nelle stime dei flussi di cassa futuri relativi al servizio futuro, (c) rilascio nel conto economico man mano che viene prestato il servizio assicurativo (CSM ammortizzato in proporzione alle unità di copertura). I builder implementano il CSM come calcolo a livello di coorte aggiornato ad ogni transazione che tocca quella coorte.
Come si gestisce la cancellazione e la decadenza della polizza nel modello dati?
La cancellazione (su iniziativa dell'assicuratore o volontaria) richiede: cancellation_date, cancellation_reason_code (MANCATO_PAGAMENTO, SOTTOSCRIZIONE, VOLONTARIA_ASSICURATO, REGOLAMENTARE, FRODE), return_premium_amount (calcolo pro-rata o a breve termine), return_premium_paid_at. La decadenza è la cancellazione per mancato pagamento dopo un periodo di grazia - archiviare grace_period_end_date e passare allo stato SCADUTA se il pagamento non viene ricevuto. Reintegrazione: creare un record di reintegrazione collegato alla polizza decaduta. Le regole normative variano per stato - molti DoI richiedono un preavviso (es. 10/20/30 giorni a seconda del motivo della cancellazione). Archiviare cancellation_notice_sent_at e notice_days_required per stato.