Wyzwania MSSF 17 w obszarze systemów IT

W ramach serii artykułów o standardzie MSSF 17 ukazujących się w „Miesięczniku Ubezpieczeniowym" staramy się regularnie przybliżać Państwu wszelkie zagadnienia i wyzwania związane z wdrożeniem nowej regulacji głównie z perspektywy finansowej, księgowej czy aktuarialnej. Nie są to jednak jedyne obszary, przed którymi ciągle jest wiele pracy w celu przygotowania zakładów ubezpieczeń na 1 stycznia 2021 r., czyli na dzień wejścia w życie MSSF 17. Niniejszy artykuł, w odróżnieniu od poprzednich, opisuje temat regulacji z nieco innej perspektywy, z punktu widzenia obszaru IT, który w wielu przypadkach nie został dokładnie przeanalizowany przez spółki w zakresie wpływu, jaki wywrze na niego MSSF 17. Już na wstępie chcemy podkreślić, że powodzenie całego przedsięwzięcia będzie w znacznej mierze zależało od stopnia, w jakim narzędzia i systemy informatyczne będą w stanie wesprzeć nowe procesy (finansowe, księgowe, aktu-arialne czy raportowania sprawozdawczego).

Obszar IT będzie pełnił ważną rolę zarówno przy wyborze metody pierwszego rozpoznania istniejącego portfela (tzw. transition), czy też przy operacyjnej realizacji wymogów regulacji. Właściwe zrozumienie i udział funkcji IT na każdym etapie wdrożenia regulacji MSSF 17 (począwszy już od fazy koncepcyjnej) jest jednym z kluczowych czynników decydujących o sukcesie. Od samego obszaru IT może to wymagać nawet powołania odrębnych inicjatyw (w ramach programu MSSF 17) oraz konieczności pozyskania dodatkowego wsparcia zarówno z wewnątrz organizacji, jak i od zewnętrznych dostawców usług IT. Największy wpływ na zagadnienia IT MSSF 17 będzie miał w obszarze danych (zarówno źródeł danych, jak i całego procesu ich przetwarzania), zakresie biznesowych funkcjonalności poszczególnych systemów informatycznych, jak i kształcie oraz wydajności całej architektury IT. Kluczowe elementy IT zostały zobrazowane na referencyjnym modelu IT dla obszaru finansów (rys. 1).

Dane

MSSF 17 wymaga wykorzystania znacznie szerszego zakresu danych zarówno w przypadku obecnego, jak i historycznego portfela polisowego. Wiąże się to przede wszystkim z koniecznością stworzenia nowych rodzajów i całej struktury danych np. wykorzystywanych do podziału kontraktów w ramach portfela na jednostki obrachunkowe obejmującego najwyżej 12-miesięczne okresy oraz dodatkowo w rozróżnieniu na polisy:

• polisy, które już w momencie sprzedaży można uznać za stratne,
• polisy, dla których nie występuje istotne ryzyko, że staną się stratnymi, w efekcie niezrealizowania założeń taryfikacyjnych,
• pozostałe polisy.
   

Z kolei dla każdej z tych grup polis pojawi się wymóg utworzenia, przechowywania i przetwarzania kolejnych danych związanych z wyceną w kwotach zdyskontowanych na dany moment czasowy, czy to zupełnie nowych bloków danych będących częścią raportowania MSSF 17 (np. BEL, korekta z tytułu ryzyka RA, marża CSM). Jeszcze większym wyzwaniem wydaje się wysiłek związany z pozyskaniem danych historycznych w celu rozpoznania istniejących portfeli ubezpieczeń w ramach nowych wymogów. W przypadku zastosowania metody w pełni retrospektywnej wymagane będzie odtworzenie poziomu marży CSM na datę początkowego rozpoznania dla każdej jednostki obrachunkowej. Z tego względu firma ubezpieczeniowa będzie musiała pozyskać informacje nie tylko o polisach aktywnych na bieżącą datę, ale również o polisach, które wygasły, ale historycznie wchodziłyby do nadal aktywnych jednostek obrachunkowych. W tej części zadanie może być obarczone dodatkową trudnością w przypadku polis wieloletnich i/lub takich, które były migrowane pomiędzy systemami lub zostały pozyskane w ramach przejęcia innej spółki ubezpieczeniowej. W szczególności, częstą praktyką przy migracji danych do nowego systemu jest pominięcie danych historycznych (np. o nieaktywnych polisach). Z tego względu często trzeba będzie wykonać próbę sięgnięcia do historycznych systemów czy archiwalnych zbiorów danych, które od dawna nie są już wykorzystywane, oraz odnaleźć w nich dane niezbędne do zastosowania na potrzeby metody w pełni retrospektywnej. W takiej sytuacji będziemy musieli się zmierzyć z następującymi kategoriami problemów:

• Identyfikacja źródła danych - dane o polisach, dane aktuarialne mogące służyć do odtworzenia historycznych projekcji aktuarialnych, czy dane 0 polityce, jaką prowadziła spółka, nie są często przechowywane w jednym systemie, ale w wielu różnych już zarchiwizowanych systemach (np. osobno dane o sprzedaży, osobno o naliczaniu 1 księgowaniu składek i osobno o szkodach). Dodatkowo bazy danych tych systemów mogły być archiwizowane w różnym czasie, co dodatkowo utrudnia cały proces identyfikacji źródeł.
• Zapewnienie spójności i wiarygodności danych - dane o historycznych polisach pomiędzy systemami mogą się różnić, dlatego istotne będzie wskazanie systemów, przechowujących prawidłowy obraz danych, który powinien być wykorzystany w kalkulacji sprawozdania.
• Dostępność danych - dane w historycznych źródłach mogą nie być pełne lub mogą wymagać dodatkowej interpretacji (analizy), aby mogły zostać bezpośrednio zastosowane do celów sprawozdawczości wg MSSF 17. W wielu przypadkach może się okazać, że organizacja po prostu nie posiada żadnych danych czy to o historycznych polisach, czy to o szkodach (taka sytuacja może dotyczyć podmiotów, które osiągały wzrost przez proces akwizycji). Dane o nieaktywnych polisach z systemów przejmowanych spółek mogły w ogóle nie być migrowane.
• Jakość danych i format dostępnych danych - w przeszłości dane, których dziś będziemy potrzebować, były wykorzystywane w innych celach, przez co mogą przybierać wiele różnych formatów i standardów, a dodatkowo historycznie mogło się nie przywiązywać wagi do ich poprawności lub kompletności. Proces czyszczenia i ujednolicenia może być konieczny do wykorzystania tych danych na potrzeby raportowania.

Warto mieć na uwadze, że w przypadkach, w których nie będzie możliwe zastosowanie metody w pełni retrospektywnej, to głównie na obszarze IT będzie spoczywała odpowiedzialność za wiarygodne uzasadnienie i udokumentowanie powodów, dla których nie było możliwe uzyskanie wymaganych danych.

Nowe funkcjonalności

Zagadnienie związane z danymi jest tylko jednym z wyzwań, jakie czekają dzisiejsze działy i departamenty IT na drodze do wdrożenia MSSF 17. Dużym wyzwaniem może okazać się umożliwienie realizacji nowych funkcjonalności przez systemy informatyczne.

Warto zauważyć, że często mamy tu na myśli funkcjonalności, które nie są dostępne w ramach obecnych (standardowych) konfiguracji systemów np. finansowo-księgowych. Zmianami, które wydają się najbardziej istotne, są:

• zmiany do systemów polisowych i aktuarialnych umożliwiające przechowywanie i przetwarzanie w systemach nowych rodzajów i struktur danych,
• zmiany do planu kont księgowych, który będzie musiał pozwalać na ujęcie zupełnie nowych pozycji, takich jak korekta z tytułu ryzyka czy marża CSM, oraz powiązanie ich z konkretnymi jednostkami obrachunkowymi (grupami polis),
• umożliwienie jednoczesnego prowadzenia przynajmniej dwóch planów kont, co obecnie nie musi być standardem oferowanym przez systemy finansowo-księgowe,
• wdrożenie w systemach mechanizmów podziału/alokacji kosztów na koszty, które można przypisać do grup polis, i takie, które są kosztami ogólnymi, niedającymi się do tych grup odnieść,
• przygotowanie systemów do generowania nowego kształtu sprawozdania zgodnie z układem wymaganym przez MSSF 17, który istotnie różni się od obecnego,
• zmiany w zakresie interfejsów, np. pomiędzy systemami polisowymi, aktuarialnymi i systemem finansowo--księgowym. Systemy będą musiały szerzej, niż to się działo do tej pory, wzajemnie wymieniać informacje w nich zawarte (np. system aktuarialny będzie wymagał informacji o historycznie rozpoznanych wartościach marży CSM, a system finansowo--księgowy będzie wymagał otrzymania informacji o wyliczonych wartościach RA, CSM i dyskonta).
  
  

Jednym z ciekawych dodatkowych wyzwań będzie zapewnienie takiej konfiguracji systemów, która w 2020 r. wyliczy dwa sprawozdania - jedno zgodne z obowiązującym MSSF 4 oraz MSSF 17 dla celów porównawczych do sprawozdania na 2021 r. W zależności od podejścia spółki może to ograniczyć czas na dokonanie zmian w systemach do dwóch lat.

Architektura

Poprzez konieczność znaczącego zwiększenia stopnia szczegółowości w wykazywanych wynikach finansowych, MSSF 17 niejako równolegle wymusza wprowadzenie zmian w samej architekturze systemów IT. W najtrudniejszej sytuacji będą duże podmioty, które do tej pory nie przykładały wagi do automatyzacji procesów aktuariainych i procesów finansowo-księgowych (w tym w szczególności raportowania finansowego). W świetle nowej regulacji niemożliwe wydaje się dalsze bazowanie wyłącznie na prostych narzędziach typu arkusz kalkulacyjny oraz na operacjach wykonywanych manualnie (choćby w zakresie uzgodnień). Zwiększony zakres danych, stopień skomplikowania i wielowymiarowość wyliczeń oraz analiz mogą wymusić przeniesienie realizacji tych funkcjonalności do dedykowanych systemów informatycznych oraz złączenie ich poprzez automatyczne i wydajne interfejsy. Z tego względu przed przystąpieniem do wdrożenia MSSF 17 od strony biznesowej warto rozważyć, czy nie jest to dobry moment na wdrożenie bądź wymianę przestarzałych i nieelastycznych systemów IT, np. księgi głównej, systemów aktuariainych, prowizyjnych, raportowania finansowego czy nawet samego systemu polisowego. Koszt dostosowania i integracji przestarzałych rozwiązań może być zbliżony do kosztów wdrożenia zupełnie nowego systemu. W ramach tych rozważań warto również zastanowić się nad modelem architektury IT, w którym wykorzystywana będzie hurtownia danych wraz z mechanizmami wspierającymi agregację i wielowymiarową analizę jak data mart lub kostki OLAE Sytuacja podmiotów, które posiadają w miarę nowe i silnie zintegrowane systemy IT umożliwiające wysoki stopień automatyzacji procesów, będzie znacząco odmienna. W ich przypadku działania będą ukierunkowane na zbadanie możliwości wdrożenia zmian w funkcjonalnościach istniejących systemów oraz konieczność poszerzenia integracji np. systemów aktuariainych (prognozujących przyszłe przepływy) z systemami finansowo-księgo-wymi (np. korekta z tytułu ryzyka, marża CSM), co z dużym prawdopodobieństwem będzie również wymagało przemodelowania istniejących automatycznych interfejsów.

Wydajność

W przypadku zakładów ubezpieczeń, w których wolumen polis sięga setek tysięcy lub nawet milionów, wyzwaniem może się okazać zapewnienie akceptowalnej wydajności systemów IT. Dotyczy to zarówno momentu dokonywania wyboru metody rozpoznania istniejącego portfela (tzw. transition), jak i późniejszego działania „standardowych" procesów ubezpieczeniowych pod nową regulacją. W szczególności, oprócz zwiększonej ilości danych zbieranych i przetwarzanych dla każdej polisy, w przypadku konieczności stosowania metody w pełni retrospektywnej konieczne będzie ponowne przeliczanie całych portfeli ubezpieczeniowych, co może stanowić nie lada wyzwanie z punktu widzenia wydajności infrastruktury IT. Również dużym wyzwaniem związanym z wydajnością systemów może być konieczność wyliczenia wyników za kolejne miesiące. Jest to szczególnie istotne w przypadku ubezpieczycieli realizujących proces zamknięcia miesiąca w ramach „fast close", gdzie posiadanie np. „wąskich gardeł" może znacząco utrudnić bądź nawet uniemożliwić realizację tego procesu. W przypadku, gdy stosowane rozwiązania nie są łatwo skalowalne, może się to wiązać z dodatkowymi (niemałymi) kosztami. Prawdopodobna wydaje się więc również konieczność dodatkowych zakupów związanych z fizyczną infrastrukturą IT (włączając w to zwiększanie parametrów poszczególnych serwerów i liczby licencji) w celu umożliwienia procesowania wjednym i tym samym czasie wielu zadań obliczeniowych na dużych wolumenach danych. Kolejnym wyzwaniem dla obszaru IT będzie również zapewnienie właściwego środowiska informatycznego na fazę transition. Do podjęcia decyzji, jaka grupa polis będzie rozpoznawana jaką metodą, wymagane będzie przeprowadzenie testowych wyliczeń, które porównają wyniki w zależności od wybranej metody. Oznacza, to, że narzędzia wykorzystywane do wyceny grupy polis powinny być na tyle elastyczne, aby można byto stosunkowo łatwo zmieniać założenia wykorzystywane do kalkulacji dla danej grupy polis. Środowisko informatyczne powinno wspierać przeprowadzenie testów i analiz pozwalających na zaprezentowanie kadrze zarządczej konsekwencji wyboru poszczególnych metod wyceny dla poszczególnych grup polis.

Analizując wpływ regulacji MSSF 17 na obszar IT, nie można pominąć kwestii objęcia wszelkich nowych elementów procesów czy systemów IT już istniejącymi firmowymi mechanizmami mającymi np. zapewnić audytowalność i rozliczalność. Stanowić to będzie jeden z kluczowych elementów na drodze do udowodnienia wiarygodności wyliczeń i wyników prezentowanych w ramach nowego sprawozdania zgodnego z MSSF 17.

Podsumowując, chcielibyśmy podkreślić, że pomimo że wdrożenie MSSF 17 będzie typowo biznesowym zadaniem angażującym przede wszystkim takie jednostki organizacyjne, jak księgowość, finanse czy aktuariat, to jednak końcowy sukces całego przedsięwzięcia będzie w znaczącym stopniu zależał od pracy wykonanej przez obszar IT. Niedoszacowanie zaangażowania, bądź bagatelizacja kwestii technologicznych może w praktyce bardzo szybko utrudnić, a czasem nawet uniemożliwić wdrożenie regulacji. W związku z tym każda organizacja musi pamiętać o niezwłocznym zabezpieczeniu środków w budżecie na ten cel, na najbliższy rok i na kolejne lata, umożliwiając uwzględnienie strumienia technologicznego jako równoległego strumienia prac w programie wdrożenia MSSF 17 od samego początku (od analizy wpływu) aż do samego końca (do momentu uruchomienia nowego procesu).