Upravit

Share via

Analýza a finanční modelování actuarial rizik

Azure Blob Storage
Azure Data Factory
Azure Cosmos DB
Azure HDInsight
Azure Databricks

V posledních několika letech přišli na řadu nových nařízení pojišťovny a společnosti, které poskytují pojistné produkty. Tyto nové předpisy vyžadovaly rozsáhlejší finanční modelování pro pojišťovny. Evropská unie přijala platební schopnost II. Tento zákon vyžaduje, aby advokáti prokázali, že provedli správnou analýzu, aby ověřili, že bude pojištění rozpouštěno na konci roku. Pojišťovny, kteří poskytují proměnlivou anuitu, musí sledovat Actuarial Guideline XLIII s rozsáhlou analýzou peněžních toků aktiv a pasiv. Do roku 2021 budou muset implementovat všechny typy pojistného pojištění, včetně těch, kteří distribuují pojistné produkty, standard 17 (IFRS 17). (IFRS je zkratka pro mezinárodní standardy pro vykazování financování.) Existují i další předpisy v závislosti na jurisdikcích, ve kterých operují pojišťovny. Tyto standardy a předpisy vyžadují, aby při modelování prostředků a závazků používaly výpočetní techniky náročné na výpočetní výkon. Velká část analýzy využije stochasticky generovaná data scénářů nad seriatimovými vstupy věcí, jako jsou aktiva a závazky. Nad rámec zákonných potřeb dělají aktáři poměrně velké množství finančního modelování a výpočtu. Vytvoří vstupní tabulky pro modely, které generují regulační sestavy. Interní mřížky nevyhovují výpočetním potřebám, takže se actuaries neustále pohybují do cloudu.

Actuaries se přesouvají do cloudu, aby získali více času na kontrolu, vyhodnocení a ověření výsledků. Když regulační orgány auditují pojišťovny, musí být aktátoři schopni vysvětlit jejich výsledky. Přechod do cloudu jim umožňuje přístup k výpočetním prostředkům, aby mohli spouštět analýzu 20 000 hodin za 24 až 120 hodin prostřednictvím paralelizace. Mnoho společností, které vytvářejí actuarial software, poskytují řešení, která umožňují výpočty spouštět v Azure. Některá z těchto řešení jsou založená na technologiích, které běží místně i v Azure, jako je vysoce výkonné výpočetní řešení PowerShellu, sada HPC Pack. Jiná řešení jsou nativní pro Azure a používají azure Batch, škálovací sady virtuálních počítačů nebo vlastní řešení škálování.

V tomto článku se podíváme na to, jak můžou vývojáři actuarial používat Azure ve spojení s balíčky modelování k analýze rizika. Tento článek vysvětluje některé technologie Azure, které balíčky modelování používají ke spouštění ve velkém měřítku v Azure. Stejnou technologii můžete použít k další analýze dat. Podíváme se na následující položky:

  • Spouštění větších modelů v kratším čase v Azure
  • Hlášení výsledků.
  • Správa uchovávání dat

Bez ohledu na to, jestli jste vyživotní, nemovitosti a nečasové, zdravotní nebo jiné pojištění, musíte vytvořit finanční a rizikové modely vašich aktiv a závazků. Pak můžete své investice a premium upravit tak, abyste zůstali rozpouštění jako pojištění. Generování sestav IFRS 17 přidává změny do modelů, které aktátoři vytvářejí, jako je výpočet smluvní marže služeb (CSM), která mění způsob, jakým pojišťovny spravují svůj zisk v čase.

Rychlejší spuštění v Azure

Věříte v příslib cloudu: může spouštět vaše finanční a rizikové modely rychleji a snadněji. U mnoha poskytovatelů pojištění ukazuje zadní část výpočtu obálky problém: potřebují roky, nebo dokonce desetiletí, sekvenčního času ke spuštění těchto výpočtů od začátku do konce. Potřebujete technologii k vyřešení problému za běhu. Vaše strategie jsou:

  • Příprava dat: Některá data se pomalu mění. Jakmile je vynucená zásada nebo kontrakt služby, deklarace identity se pohybují předvídatelným tempem. Při příchodu můžete připravit data potřebná pro spuštění modelu, což eliminuje nutnost naplánovat spoustu času na čištění a přípravu dat. Clustering můžete použít také k vytvoření samostatných in pro seriatim data prostřednictvím vážených reprezentací. Méně záznamů obvykle vede ke snížení doby výpočtu.
  • Paralelizace: Pokud potřebujete provést stejnou analýzu na dvě nebo více položek, můžete být schopni provést analýzu současně.

Podívejme se na tyto položky jednotlivě.

Příprava dat

Data proudí z několika různých zdrojů. V knihách o podnikání máte částečně strukturovaná data zásad. Máte také informace o pojištěných lidech, společnostech a položkách, které se zobrazují v různých formulářích aplikace. Generátory ekonomických scénářů (ESG) vytvářejí data v různých formátech, které mohou potřebovat překlad do formuláře, který může váš model použít. Aktuální data o hodnotách aktiv také potřebují normalizaci. Data burzovního trhu, data peněžního toku o pronájmech, informace o splátkách hypoték a další data o aktivech potřebují při přechodu ze zdroje na model určitou přípravu. Nakonec byste měli aktualizovat všechny předpoklady na základě nedávných dat o zkušenostech. Pokud chcete urychlit spuštění modelu, připravte data předem. V době běhu provedete všechny potřebné aktualizace pro přidání změn od poslední plánované aktualizace.

Jak tedy připravíte data? Nejprve se podíváme na běžné bity a pak se podíváme, jak pracovat s různými způsoby zobrazení dat. Nejprve chcete, aby mechanismus získal všechny změny od poslední synchronizace. Tento mechanismus by měl obsahovat hodnotu, která se dá seřadit. U nedávných změn by tato hodnota měla být větší než jakákoli předchozí změna. Dva nejběžnější mechanismy představují stále se zvyšující pole ID nebo časové razítko. Pokud záznam obsahuje rostoucí klíč ID, ale zbytek záznamu obsahuje pole, která se dají aktualizovat, musíte k vyhledání změn použít něco jako časové razítko poslední změny. Po zpracování záznamů si poznamenejte seřazenou hodnotu poslední položky. Tato hodnota, pravděpodobně časové razítko pole s názvem lastModified, se stane vaším vodoznakem, který se použije pro následné dotazy v úložišti dat. Změny dat je možné zpracovávat mnoha způsoby. Tady jsou dva běžné mechanismy, které používají minimální prostředky:

  • Pokud máte ke zpracování stovky nebo tisíce změn, nahrajte data do úložiště objektů blob. Ke zpracování sady změn použijte trigger události ve službě Azure Data Factory .
  • Pokud máte malé sady změn, které se mají zpracovat, nebo pokud chcete aktualizovat data hned po změně, vložte každou změnu do zprávy fronty, která je hostovaná službou Service Bus nebo frontami úložiště. Tento článek obsahuje skvělé vysvětlení kompromisů mezi dvěma technologiemi ve frontě. Jakmile je zpráva ve frontě, můžete ji zpracovat pomocí triggeru ve službě Azure Functions nebo Azure Data Factory.

Následující obrázek znázorňuje typický scénář. Nejprve naplánovaná úloha shromažďuje určitou sadu dat a umístí soubor do úložiště. Naplánovanou úlohou může být úloha CRON spuštěná místně, úloha plánovače, aplikace logiky nebo cokoli, co běží v časovači. Po nahrání souboru je možné aktivovat instanci služby Azure Functions nebo Data Factory pro zpracování dat. Pokud lze soubor zpracovat za krátkou dobu, použijte funkci. Pokud je zpracování složité, vyžaduje AI nebo jiné složité skriptování, můžete zjistit, že HDInsight, Azure Databricks nebo něco vlastního funguje lépe. Po dokončení se soubor zvětšuje v použitelné podobě jako nový soubor nebo jako záznamy v databázi.

Diagramy znázorňují naplánované nahrávání do služby Blob Storage a pak událost nahrávání aktivující funkci nebo službu Data Factory.

Jakmile jsou data v Azure, musíte je použít pomocí aplikace modelování. Můžete napsat kód pro vlastní transformace, spouštět položky prostřednictvím SLUŽBY HDInsight nebo Azure Databricks k ingestování větších položek nebo kopírovat data do správných sad dat. Použití nástrojů pro velké objemy dat vám také může pomoct dělat věci, jako je transformace nestrukturovaných dat na strukturovaná data, a také spouštění jakékoli umělé inteligence a strojového učení nad přijatými daty. Můžete také hostovat virtuální počítače, nahrávat data přímo do zdrojů dat z místního prostředí, přímo volat Azure Functions atd.

Později je potřeba data využívat vašimi modely. Způsob, jakým to uděláte, závisí do značné míry na tom, jak výpočty potřebují přístup k datům. Některé systémy modelování vyžadují, aby se na uzlu, na kterém se spouští výpočet, všechny datové soubory. Ostatní můžou využívat databáze, jako je Azure SQL Database, MySQL nebo PostgreSQL. Můžete použít nízkonákladovou verzi některé z těchto položek a pak vertikálně navýšit kapacitu výkonu během spuštění modelování. To vám dává cenu, kterou potřebujete pro každodenní práci. Navíc poskytuje větší rychlost, jen když tisíce jader požadují data. Za normálních okolností budou tato data při spuštění modelování jen pro čtení. Pokud k výpočtům dochází napříč několika oblastmi, zvažte použití geografické replikace Azure Cosmos DB nebo Azure SQL. Oba poskytují mechanismy pro automatickou replikaci dat napříč oblastmi s nízkou latencí. Vaše volba závisí na nástrojích, které vaši vývojáři znají, jak jste modelovali data, a na počtu oblastí používaných pro spuštění modelování.

Věnujte čas tomu, abyste přemýšleli o tom, kam se mají data ukládat. Zjistěte, kolik souběžných požadavků na stejná data bude existovat. Zamyslete se nad tím, jak informace distribuujete:

  • Získá každý výpočetní uzel vlastní kopii?
  • Sdílí se kopie prostřednictvím umístění s velkou šířkou pásma?

Pokud udržujete data centralizovaná pomocí Azure SQL, pravděpodobně budete mít databázi po většinu času na nižší cenovou úroveň. Pokud se data používají jenom během spuštění modelování a neaktualizují se velmi často, zákazníci Azure se dostanou k zálohování dat a vypnutí jejich databázových instancí mezi spuštěními. Potenciální úspory jsou velké. Zákazníci můžou také využívat elastické fondy Azure SQL. Ty jsou navržené tak, aby kontrolily náklady na databáze, zejména pokud nevíte, které databáze budou v různých časech pod velkým zatížením. Elastické fondy umožňují kolekci databází využívat tolik energie, kolik potřebují, a potom je škálovat zpět, jakmile se poptávka posune jinde v systému.

Při spuštění modelování možná budete muset synchronizaci dat zakázat, aby výpočty později v procesu používaly stejná data. Pokud používáte řazení do front, zakažte procesory zpráv, ale povolte frontám přijímat data.

Můžete také použít čas před spuštěním ke generování ekonomických scénářů, aktualizaci předpokladů aktuálů a obecné aktualizaci dalších statických dat. Podívejme se na generování ekonomických scénářů (ESG). Společnost Actuaries poskytuje generátor úrokové sazby Akademie (AIRG), ESG, který modeluje výnosy státní pokladny USA. AIRG je předepsané pro použití v položkách, jako je ručně oceňovací příručka 20 (VM-20). Ostatní ESG mohou modelovat burzovní trh, hypotéky, komoditní ceny atd.

Vzhledem k tomu, že vaše prostředí data předem zpracovává, můžete také spouštět další části v rané fázi. Můžete mít například věci, které modelujete, které používají záznamy k reprezentaci větších populací. Obvykle to dělá clustering záznamů. Pokud se datová sada aktualizuje sporadicky, například jednou denně, může snížit sadu záznamů na to, co se použije v modelu v rámci procesu příjmu dat.

Podívejme se na praktický příklad. U IFRS-17 musíte smlouvy seskupit tak, aby maximální vzdálenost mezi počátečními daty pro všechny dva kontrakty byla menší než jeden rok. Předpokládejme, že to uděláte snadno a použijete rok smlouvy jako mechanismus seskupení. Tuto segmentaci je možné provést, když se data načtou do Azure, a to tak, že si projdete soubor a přesunete záznamy do příslušných seskupování roků.

Zaměření na přípravu dat zkracuje dobu potřebnou ke spuštění součástí modelu. Získáním dat v rané fázi můžete ušetřit čas pro spouštění modelů.

Paralelizace

Správné paralelizace kroků může výrazně zkrátit dobu provádění hodin. K tomuto zrychlení dochází tak, že zřetěšíte části, které implementujete, a zjistíte, jak vyjádřit model způsobem, který umožňuje souběžné spuštění dvou nebo více aktivit. Trikem je najít rovnováhu mezi velikostí žádosti o práci a produktivitou jednotlivých uzlů. Pokud úloha stráví více času v nastavení a vyčištění, než se provádí při vyhodnocování, je příliš malá. Pokud je úloha příliš velká, doba provádění se nezlepší. Chcete, aby aktivita byla dostatečně malá, aby se rozložila na více uzlů a aby se v uplynulé době provádění změnila pozitivní rozdíl.

Pokud chcete systém využívat na maximum, musíte porozumět pracovnímu postupu modelu a tomu, jak výpočty komunikují s možností horizontálního navýšení kapacity. Váš software může mít představu o úlohách, úkolech nebo něčem podobném. Tyto znalosti použijte k návrhu něčeho, co může rozdělit práci. Pokud máte v modelu nějaké vlastní kroky, navrhněte je tak, aby se vstupy rozdělily do menších skupin pro zpracování. Tento návrh se často označuje jako vzor bodového shromažďování.

  • Bodový: rozdělte vstupy podél přirozených čar a povolte spouštění samostatných úloh.
  • Shromážděte: po dokončení úkolů shromážděte jejich výstupy.

Při rozdělování věcí také víte, kde se má proces před přechodem dopředu synchronizovat. Existuje několik běžných míst, kde lidé rozdělují věci. U vnořených stochastických běhů můžete mít tisíce vnějších smyček se sadou inflexních bodů, které spouští vnitřní smyčky sto scénářů. Každá vnější smyčka může běžet současně. Zastavíte se v inflexní bodě, pak spustíte vnitřní smyčky současně, vrátíte informace, abyste upravili data pro vnější smyčku, a znovu přejděte vpřed. Následující obrázek znázorňuje pracovní postup. Pokud máte dostatek výpočetních prostředků, můžete spustit 100 000 vnitřních smyček na 100 000 jader a snížit dobu zpracování na součet následujících časů:

Diagramy znázorňují tři samostatné procesy, ke kterým dochází postupně. První je

Distribuce se trochu zvýší v závislosti na tom, jak se to dělá. Může to být jednoduché jako vytvoření malé úlohy se správnými parametry nebo složité jako kopírování 100 tisíc souborů na správná místa. Výsledky zpracování je možné dokonce urychlit, pokud agregaci výsledků můžete distribuovat pomocí Apache Sparku ze služby Azure HDInsight, Azure Databricks nebo vlastního nasazení. Výpočet průměrů je například jednoduchá záležitost, kdy si pamatujete, kolik položek se zatím zobrazilo a součet. Jiné výpočty můžou fungovat lépe na jednom počítači s tisíci jader. Pro ty můžete využít počítače s podporou GPU v Azure.

Většina actuarial týmů tuto cestu zahájí přesunem modelů do Azure. Pak shromáždí data časování v různých krocích procesu. Pak seřadí hodiny pro každý krok od nejdelšího po nejkratší uplynulý čas. Nebudou se dívat na celkovou dobu provádění, protože něco může spotřebovávat tisíce hodin jádra, ale uplynula pouze 20 minut. U každého z nejdéle běžících kroků úlohy hledají vývojáři actuarial způsoby, jak zkrátit uplynulý čas a získat správné výsledky. Tento proces se pravidelně opakuje. Některé actuarial týmy nastaví cílovou dobu běhu, řekněme, že analýza přenocování má cíl běžet do 8 hodin. Jakmile se čas plíží více než 8,25 hodin, část actuarial týmu se přepne, aby se zlepšil čas nejdelší části analýzy. Jakmile dostanou čas zpět do 7,5 hodin, přejdou zpět na vývoj. Heuristiky, které se mají vrátit a optimalizovat, se liší mezi aktárci.

Pokud chcete spustit všechny tyto možnosti, máte několik možností. Většina actuarial softwaru funguje s výpočetními mřížkami. Mřížky, které fungují místně a v Azure, používají buď sadu HPC Pack, partnerový balíček, nebo něco vlastního. Gridy optimalizované pro Azure budou používat škálovací sady virtuálních počítačů, batch nebo něco vlastního. Pokud se rozhodnete použít škálovací sady nebo Službu Batch, nezapomeňte se podívat na jejich podporu pro virtuální počítače s nízkou prioritou (dokumentace ke škálovacím sadám s nízkou prioritou, dokumenty s nízkou prioritou služby Batch ). Virtuální počítač s nízkou prioritou je virtuální počítač běžící na hardwaru, který si můžete pronajmout za zlomek běžné ceny. Nižší cena je dostupná, protože virtuální počítače s nízkou prioritou se můžou předem snížit, když je kapacita vyžaduje. Pokud máte v časovém rozpočtu určitou flexibilitu, virtuální počítače s nízkou prioritou představují skvělý způsob, jak snížit cenu spuštění modelování.

Pokud potřebujete koordinovat provádění a nasazení napříč mnoha počítači, třeba s některými počítači běžícími v různých oblastech, můžete využít CycleCloud. CycleCloud stojí nic navíc. V případě potřeby orchestruje přesun dat. To zahrnuje přidělení, monitorování a vypnutí počítačů. Dokáže dokonce zvládnout počítače s nízkou prioritou a zajistit, aby náklady byly obsaženy. Pokud chcete popsat kombinaci počítačů, které potřebujete, můžete jít doposud. Možná například potřebujete třídu počítače, ale můžete dobře běžet na libovolné verzi, která má 2 nebo více jader. Cyklus může přidělit jádra napříč těmito typy počítačů.

Hlášení výsledků

Jakmile se balíčky actuarial spustí a vytvoří jejich výsledky, budete mít několik sestav připravených pro regulátory. Budete mít také horu nových dat, která můžete chtít analyzovat, abyste vygenerovali přehledy, které nevyžadují regulační orgány nebo auditoři. Možná budete chtít pochopit profil vašich nejlepších zákazníků. Pomocí přehledů můžete říct marketingu, jak vypadá nízkonákladový zákazník, aby ho marketing a prodej našli rychleji. Podobně můžete pomocí dat zjistit, které skupiny mají největší prospěch z pojištění. Můžete například zjistit, že lidé, kteří využívají roční fyzické informace o problémech se stavem v rané fázi dříve. Tím ušetříte čas a peníze pojišťovací společnosti. Tato data můžete použít k řízení chování v zákaznickém základu.

K tomu budete chtít získat přístup k mnoha nástrojům pro datové vědy i k některým částem pro vizualizaci. V závislosti na tom, kolik šetření chcete udělat, můžete začít s Datová Věda virtuálním počítačem, který je možné zřídit z Azure Marketplace. Tyto virtuální počítače mají verze Windows i Linux. Nainstalovaný, najdete Microsoft R Open, Microsoft Machine Učení Server, Anaconda, Jupyter a další nástroje připravené k přechodu. Pokud chcete vizualizovat data a sdílet přehledy s kolegy, zahoďte trochu jazyka R nebo Python.

Pokud potřebujete provést další analýzu, můžete pomocí nástrojů pro datové vědy Apache, jako je Spark, Hadoop a další, použít HDInsight nebo Databricks. Tyto možnosti použijte, pokud je potřeba provádět analýzu pravidelně a chcete pracovní postup automatizovat. Jsou také užitečné pro živou analýzu velkých datových sad.

Jakmile najdete něco, co je zajímavé, musíte prezentovat výsledky. Mnoho actuaries začne tím, že vezme ukázkové výsledky a připojí je do Excelu a vytvoří grafy, grafy a další vizualizace. Pokud chcete něco, co má také pěkné rozhraní pro procházení dat, podívejte se na Power BI. Power BI může vytvořit několik pěkných vizualizací, zobrazit zdrojová data a umožnit čtenářům vysvětlit data přidáním seřazených záložek s poznámkami.

Uchovávání dat

Velká část dat, která do systému přinášíte, musí být zachována pro budoucí audity. Požadavky na uchovávání dat se obvykle liší od 7 do 10 let, ale požadavky se liší. Minimální uchovávání zahrnuje:

  • Snímek původních vstupů modelu To zahrnuje aktiva, závazky, předpoklady, ESG a další vstupy.
  • Snímek konečných výstupů To zahrnuje všechna data použitá k vytváření sestav, které jsou prezentovány regulačním subjektům.
  • Další důležité, přechodné výsledky. Auditor se zeptá, proč váš model přišel s nějakým výsledkem. Potřebujete zachovat důkazy o tom, proč model provedl určité volby nebo přišel s konkrétními čísly. Mnozí pojišťovny se rozhodnou zachovat binární soubory použité k výrobě konečných výstupů z původních vstupů. Po dotazování pak model znovu spustí, aby získal novou kopii zprostředkujících výsledků. Pokud se výstupy shodují, měly by zprostředkující soubory obsahovat také vysvětlení, které potřebují.

Během spuštění modelu aktaři používají mechanismy doručování dat, které můžou zpracovávat zatížení požadavku ze spuštění. Po dokončení spuštění a už nejsou potřebná data, zachovávají některá data. Minimálně by měl pojištění zachovat vstupy a konfiguraci modulu runtime pro všechny požadavky na reprodukovatelnost. Databáze se zachovají pro zálohy ve službě Azure Blob Storage a servery se vypínají. Data o vysokorychlostním úložišti se také přesunou do levnější služby Azure Blob Storage. V Blob Storage můžete zvolit datovou vrstvu použitou pro každý objekt blob: horkou, studenou nebo archivní. Horké úložiště funguje dobře pro často používané soubory. Studené úložiště je optimalizované pro občasný přístup k datům. Archivní úložiště je nejvhodnější pro uchovávání auditovatelných souborů, ale úspora cen se snižuje na latenci: archivovaná latence dat vrstvy se měří v hodinách. Přečtěte si službu Azure Blob Storage: Horká, studená a archivní úroveň úložiště, abyste plně porozuměli různým úrovním úložiště. Pomocí správy životního cyklu můžete spravovat data z vytváření až po odstranění. Identifikátory URI pro objekty blob zůstávají statické, ale místo, kde je objekt blob uložený, je v průběhu času levnější. Tato funkce ušetří spoustu peněz a bolesti hlavy pro mnoho uživatelů Azure Storage. Informace o ins a outs najdete v tématu Správa životního cyklu služby Azure Blob Storage. Skutečnost, že můžete automaticky odstranit soubory, je úžasná: znamená to, že omylem nechtěně rozbalíte audit odkazem na soubor, který je mimo rozsah, protože samotný soubor se dá automaticky odebrat.

Důležité informace

Pokud má systém actuarial, který spouštíte, místní implementaci mřížky, bude tato implementace mřížky pravděpodobně spuštěna i v Azure. Někteří dodavatelé mají specializované implementace Azure, které běží v hyperškálování. V rámci přesunu do Azure přesuňte také interní nástroje. Zákony všude najdou, že jejich dovednosti v oblasti datových věd dobře fungují na svém přenosném počítači nebo s velkým prostředím. Hledejte, co váš tým už dělá: možná máte něco, co používá hluboké učení, ale trvá hodiny nebo dny, než se spustí na jednom GPU. Zkuste na počítači spustit stejnou úlohu se čtyřmi špičkovými grafickými procesory a podívejte se na časy spuštění; pravděpodobnosti jsou dobré, že uvidíte výrazné zrychlení pro věci, které už máte.

Při vylepšování se ujistěte, že jste také vytvořili synchronizaci dat pro podávání dat modelování. Spuštění modelu se nedá spustit, dokud nebudou data připravená. To může zahrnovat přidání určitého úsilí, abyste odeslali pouze data, která se změnila. Skutečný přístup závisí na velikosti dat. Aktualizace několika MB možná není velký problém, ale snížení počtu gigabajtů nahrávání hodně urychlí.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Další kroky