法規與監理 2023年10月

保險業需面對四大挑戰

IFRS 17新制施行在即
整理:高永謀

2026年起,台灣會計制度將開始適用IFRS 17,新制施行後,因得產出多個衡量值,子帳系統便應運而生。而子帳系統的操作、維護,與現行的核心系統、精算系統、總帳系統、資料平台的互動,將是保險業未來必須面對的重大課題。

202611起,台灣會計制度將開始適用IFRS 17International Financial Reporting Standards 17,國際財務報告準則第17號)。IFRS 17施行後,將影響台灣眾多產業,而保險業是受衝擊最劇烈的產業之一。為迎接即將到來的變革,台灣保險業者已加快腳步,導入IFRS 17相關系統。

保險業作業模式將有大改變

透過長期、近距離的觀察,及與保險業者密切交流,安永財務管理諮詢服務公司王沛執行副總經理指出,在IFRS 17施行後,保險業的作業模式將有重大改變。在2026年後,對被認定為保險合約者,IFRS 17規範了新的負債衡量方式與揭露要求,四大規範依次臚列如下:

1.將現金流量區分為保險組成部分,與投資組成部分。

2.負債項目包含最佳估計負債(Best Estimate Liability, BEL)、非財務風險之風險調整(Risk Adjustment for Non- financial Risk, RA),與合約服務邊際(Contractual Service Margin, CSM)。

3.除現行財務報表,保險業應揭露BELRACSM期初到期末的各項變動。

4.損益表中的保險收入、保險費用,不同於IFRS 4(國際財務報告準則第4號)的認列方式。

新制將產生子帳系統

在適用IFRS 17前,保險業精算部門僅需將準備金餘額的計算結果,提交給會計部門;會計部門再根據前期、後期的準備金餘額,編製損益表、資產負債表等財務報表。

但在適用IFRS 17後,不僅負債項目區分為BELRACSM,且三者期初至期末的會計處理,處理方式也較昔日精細。例如,在財務報告期間,預期現金流量與實際現金流量的差額,會計部門會根據其屬保費及相關現金流量,或屬投資部分,判斷是否應調整至CSM,其餘則反映至損益上。

在新制施行後,因得產出多個衡量值,子帳系統便應運而生。而子帳系統的操作、維護,與現行的核心系統、精算系統、總帳系統、資料平台的互動,將是保險業未來必須面對的重大課題。

子帳系統出現,將改變保險業的資料處理與結帳流程。唯有精算系統、資料平台的支持,子帳系統才能順利計算、出帳,產生所需資料,並在子帳系統中進行衡量;子帳系統計算所得的衡量值,將可直接連結會計事件,不必人工銜接,即可產出符合IFRS 17規範的財務報表。之後,再將此財務報表提供給總帳系統,以完成結帳作業。

精算、會計與資訊部門都需參與

目前,保險業者的子帳系統,多採用商用套裝軟體,執行步驟大同小異。而子帳系統的核心中樞,即運算邏輯與會計事件之配對,多數子帳系統廠商都建置在系統中,以程式語法處理,另有廠商將變數公式、會計事件列表,以利使用者配對。但無論前者或後者,都得有精算部門、會計部門、資訊部門的人員參與。

值得注意的是,與總帳系統相較,子帳系統若因財務報告準則或政府主管機關要求變更而影響計算邏輯時,需要調整的頻率較高。而與精算系統相較,子帳系統的計算較易,但現僅能修改部分計算公式,或完全無法修改,靈活度較低。而保險業導入精算系統的目的,並非帳務處理,與配對會計事件。

然而,保險業者應當心,子帳系統未來可能面臨四大挑戰,依次為多套系統需後續維護、計算過程不透明且使用者難以即時修改、管理報表功能不足、無預算與實際財務報表偏差分析功能。若子帳系統未持續精進,就可能被其他系統取代。

第一大挑戰源自於子帳系統乃因應IFRS 17施行而生,但保險業者現已有多套系統同時運作中,包括核心系統、理賠系統、總帳系統、精算系統,此後系統維護的人力負擔,將更加沉重。

第二大挑戰源自於當下市場中子帳系統的計算平台,與精算人員使用的計算平台,存有頗大的差異,且前者的計算過程較不透明,而計算公式只能部分修改,或完全無法修改,導致計算結果有誤時,很難透過檢視計算過程,揪出並修正出錯的環節。

先前,安永聯合會計師事務所便已覺察,台灣壽險公司現皆選擇計算過程較透明的精算系統,足證計算平台的透明度高低,將直接影響企業的購買、續約意願。因此,子帳系統廠商勢必得推出計算過程更透明、計算公式更易修改的版本,方能從眾多競爭者中脫穎而出。

第三大挑戰源自於,當下保險業者採用的子帳系統,主要功能為產出IFRS 17財務報表,較少管理報表的功能。然而,IFRS 17生效後,績效指標幾乎與財務報表的項目相同。子帳系統廠商若能強化管理報表功能,當可節省保險業者額外編列管理報表的時間,並降低財務報表、管理報表資料不一致的情況。

而子帳系統沒有預算與實際財務報表偏差分析功能,不易比較實際與預期的差異,保險公司難以藉子帳系統,估算下一年度的目標業績,或擬訂未來的商品策略。其實,保險公司善用已建置的軟體、系統,即可取代子帳系統,且更省時、更省力,計算過程也更透明。

可強化精算系統功能

例如,保險業者若將IFRS 17要求的負債項目滾動計算公式,建置於精算系統中,再輸入實際現金流的數據,即可產出符合IFRS 17規範的衡量值,再透過公司資料庫系統中的會計事件對應表,便能產出各衡量值的會計事件、分錄,並依據IFRS 17揭露要求,製作財務報表與調節表。

對保險業者而言,以精算系統取代子帳系統的計算功能,有兩大好處。第一個好處是,在結帳流程中,可以減少維護一個系統,節省維護人力,並縮短產出報表的時程;第二個好處是,計算邏輯、流程的設計與建置,不僅將更透明,也更易追蹤、修改。

目前,保險業所採用的精算系統,計算技術、建置方式都已相當成熟,若以其完成子帳系統的工作,在遭逢會計準則變更,或公司會計人員必須重新檢視IFRS 17報表內容、會計帳務、計算結果時,不僅陳述方式更清楚,也更容易修改。

除此,以精算系統計算的負債衡量值,可儲存於保險公司的資料庫系統,並配合會計事件對應表,不僅可產出符合IFRS 17揭露要求的財務報表,且採用與財務報表相同的資料,還可進行多項延伸應用。

應考量眾系統一致性

關鍵在於,施行IFRS 17準則的主要目的之一,即是處理IFRS 4造成的資產負債會計衡量不匹配的問題,但子帳系統目前僅能處理負債端的衡量。

而且,採取不同估算法的IFRS 17衡量模型,如GMMGeneral Measurement Model,一般衡量模型)、VFAVariable Fee Approach,變動收費法)、PAAPremium Allocation Approach,保費分攤法),所對應的資產,當有不同的配置,且應考量對應資產的權益類占比、固定收益類占比、監測淨值比,及資產收益率與損益的波動,藉此決定未來的戰略資產配置。

第一項延伸應用為,保險業者若能在精算系統中,建置資產衡量模型,將有助於進行負債端與資產負債管理(Asset Liability Management, ALM)整合,並可更即時、更便利地進行資產負債控管。

第二項延伸應用為,保險業者若能在精算系統中,建置資產衡量模型,因計算ICSInsurance Capital Standard,保險資產標準)時,可使用與財務報表相同的資料,將事半而功倍,還可根據ICS的要求,進行必要的補充。而且,保險業者還可在精算系統平台中,進行資產負債情境加壓計算,以得出各項資本要求(Capital Requirement)。

第三項延伸應用為,因IFRS 17部分績效指標與財務報表的衡量值相同,故保險業者亦可透過精算系統,產出IFRS 17部分績效指標。縱使IFRS 17有新增的績效指標,保險公司亦可即時以精算系統產出,有助於快速提供保險業管理階層客製化的管理報表,以檢視各項績效指標。

第四項延伸應用為,若財務報表預測、衡量值皆產自精算系統,即實際、預測的財務報表衡量值,都記錄在同一個資料庫系統中,在比較預期、實際經驗差異時,可同時降低「資料落地」(人工處理)的頻率與操作風險。

王沛執行副總經理建議保險業者,目前市面上的子帳系統,功能尚不齊備、完善,無法滿足因IFRS 17實施後保險業者衍伸的管理需求。若在精算系統中,建立子帳系統的計算功能,並建置資產衡量模型,就可執行資產負債管理、保險資本標準計算,同時完成客製化管理報表、預算規劃預估,將可大幅提高作業效率,且確保系統間的一致性!

猜你喜歡

2025年8月

AI的零點擊資安攻擊來了

「安全始於設計」原則,近年來已經逐漸在資安界扎根。與其在寫完程式之後,才用人工或自動化工具找出漏洞,還不如一開始就選擇那些在語言層級上本就無法寫出某些類型錯誤的程式語言。舉例來說,若捨棄各種已有數十年歷史的C語言,改用如Rust等較為現代的語言,便能從根本上排除大量的資安漏洞。然而,就在傳統軟體界逐漸接受這個新思維的同時,人工智慧的迅速崛起,卻大幅動搖了這項理念。一旦給了大型語言模型(LLMs)讀取或操作系統資源的權限,它卻可能出現邏輯來源不明、行為難以預測的狀況。有時候,這些風險可以靠修改提示語的上下文、交由其他模型進行驗證,或者為特定錯誤情境設計固定回應來處理。但因為LLMs背後的技術邏輯是由資料訓練出來的,不是人工設計的,這些方法只能頭痛醫頭、腳痛醫腳,無法用來確實防護整體資安。因此,大型語言模型的安全並不是靠設計就能確保不會出錯,而是靠統計方法降低出錯的機率。儘管這些都是眾所周知的危險,但直到2025年6月EchoLeak事件,這些風險才真正首次爆開。微軟Copilot自推出之初就充滿爭議,它的預設權限極廣,且不完全透明。其中最令人擔心的,就是使用Copilot+的電腦,會定期截取使用者的螢幕畫面,並搜尋畫面中的內容。Copilot+甚至還會自動掃描使用者的Email信箱,將冗長的內容整理成簡短摘要。EchoLeak攻擊就利用了這個功能。它向受害者發送電子郵件,而收件者甚至不需要打開Email或點擊任何內容,就可以製造資安界公認最難防範也最高明的「零點擊」(Zero-Click)攻擊。這封Email內含惡意指令,讓LLM反過來對自己發動攻擊,協助攻擊者搜尋系統上最機敏的資料,然後將這些資料外洩出去,在這段過程中它可以繞過許多原本保護機密資訊的安全措施。雖然這個漏洞目前並未在真實環境中被使用,而且微軟已經修補完成,但相同原理的攻擊,未來很有可能產生。EchoLeak攻擊的技術稱為「提示語注入」(Prompt Injection),也就是讓使用者透過特定語句,說服模型忽略系統的原始設定。最著名例子就是「忽略所有先前指令」。這種攻擊之所以難以預防,是因為LLM目前不具備有效的「輸入清理機制」(Input Sanitation)。傳統資料庫系統可以設計防線,讓系統將像「Drop Table」這類的語句視為純文字資料,而不是實際執行的刪除指令。但對LLMs來說,每一段文字都被一視同仁當作指令,沒有明確區分命令與內容。攻擊者正是透過這種混淆來下達他們真正的指令。專家正在開發一些針對提示語清理的解決方案,可能即將問世。德國研究團隊在2025年1月的論文中提出一個辦法:將系統內建的指令,轉譯成一種只有AI才能看懂的秘密語言。AI在處理語言時,會把大量的輸入壓縮進有限的語意空間,因而可能出現語意重疊的情況,使得看似亂碼的字串也會被模型認為具有特定含義,這種特性有點像是看到一個特定的雜訊畫面,卻能接收到某個具體意義。透過這類作法,模型能更明確區分內建系統指令與一般使用者的對話內容,避免將惡意語句誤認為內部指令。然而,這類方案依然基於大型語言模型的黑箱特性,專家目前還在爭論它到底算不算是本文一開始提到的「安全始於設計」的理想。假設這類方案能逐漸改良並逐漸推廣,類似EchoLeak的攻擊空間將會大幅縮小。但真正該擔心的是,LLM的資安漏洞無邊無際。根據開放網路應用安全計畫(OWASP)組織2025年提出的「LLM十大安全漏洞」(OWASP Top 10 for LLMs),提示語注入僅是最關鍵的一種攻擊方法,但並非唯一。當AI能夠主動幫我們執行的任務數量越來越多,種類越來越廣,「過度代理」(Excessive Agency)這類問題也將日益複雜,成為資安領域的重要挑戰。隨著AI深入各種工作流程,企業對它的管理方式將不再只是資安層面的防禦問題,會更像是新進員工的培訓與信任建立過程。剛導入的AI系統不宜立刻接手敏感任務,但若完全不建立起任何信任關係,企業恐怕也將錯失這場自網際網路以來最具顛覆性的技術革命。(作者為金融研訓院̮外聘研究員;譯者為劉維人)