アクチュアリーと会計・規制 — 未来の約束を今いくらで計上するか

一言でいうと

保険会計は「将来払うお金を、今いくらで計上するか」の問題で、責任準備金(原価)・IFRS17の負債(時価)・K-ICS支払余力(資本)の3つの層が、同じ契約を別の数字で見ます。ここに、保険業法と個人情報の規制が、ITの要求を上乗せします。

なぜこの知識が必要なのか

保険会社の決算システムの要求事項には、「準備金算出バッチ」、「IFRS17エンジン連携」、「K-ICS算出データマート」、「機微情報の暗号化」のような言葉が出てきます。アクチュアリーのチームが使うこれらの言葉の骨格を知らなければ、データ項目がなぜそんなに多いのか、同じ契約の負債が画面ごとになぜ違うのか、決算のたびにシステムがなぜ夜通し動くのかが、理解できません。

責任準備金: 原価で計上する負債

保険会社は、今日受け取った保険料で、数十年後の約束を守ります。その約束のために、今積み立てておくお金が、責任準備金です。定期保険の保険料積立金は、「将来支払う給付の現在価値 − 将来受け取る純保険料の現在価値」です。加入の初期には、受け取る保険料が多く残っているので小さく、あとに行くほど大きくなります。計算に使う仮定は、加入当時の危険率・予定利率です。そのため、原価基準と呼びます。

準備金には、別の部分もあります。まだ支払っていない請求のための支払備金(個別見積額とIBNR)、まだ期間が経っていない保険料のための未経過保険料積立金などです。決算バッチは、これらの部分を、契約・補償単位で計算して、合算します。

IFRS17: 時価で計上する負債

2023年から適用されたIFRS17は、負債を今の仮定で評価します。

BEL   Best estimate liability. Future cash flows (benefits + expenses − premiums) valued at current discount rates.
RA    Risk adjustment. Compensation for uncertainty in those cash flows. The insurer chooses the method.
CSM   Contractual service margin. Unearned profit left after BEL + RA. Held as a liability, released as profit over the coverage period.

CSMが核心です。契約を売った途端に利益をすべて認識できないようにして、サービスを提供した分だけを、毎期間、取り崩していきます。反対に、BEL + RAが保険料より大きければ、CSMは0で、その差は損失要素として、すぐに損失になります。決算システムには、契約グループ別にCSM残高を回すロールフォワードが必要で、仮定が変わるたびに、CSMが調整されます。

K-ICS: 資本で見る健全性

支払余力制度は、会社全体が極端な損失に耐えられるかを見ます。保険・市場・信用・オペレーショナルリスクを、それぞれ資本の要求量に換算し、リスク同士が同時には発生しないという仮定で、相関係数を適用して合算します。可用資本 ÷ 要求資本が支払余力比率で、法定の最低は100%であり、監督当局は、それより高い水準を勧告します(具体的な数値は、時点と制度によって異なります)。ITには、「資産・負債・契約をリスク要因別に分けたデータマート」として降りてきます。

保険業法と個人情報

保険業法は、商品の届出、基礎書類(約款・事業方法書・算出方法書)の管理、募集手続き、資産運用の限度、会計処理基準を扱います。IT的な観点で重要なのは、算出方法書です。保険料と準備金をどう計算するかが、この文書にあり、システムは、この文書をそのまま実装しなければなりません。個人情報の面では、保険が扱う情報が機微情報(健康・疾病)と固有識別情報(住民登録番号)であるという点が核心です。個人情報保護法は、これらの処理に、別途の同意と暗号化のような安全措置を求め、信用情報法が重なって適用されます。請求書類の診断書・診療記録は、最も機微な軸に属するので、アクセス権限・マスキング・保存期間が、要求事項に必ず入ります。

計理計算をシステムに移すときに生じる問題

IFRS17とK-ICSは会計基準ですが、実際には計算システムの要求事項として降りてきます。その要求が、一般的な業務システムと違う点が3つあります。

計算量が多く、その計算を繰り返さなければなりません。契約1件ごとに、将来のキャッシュフローを数十年分作り、それを複数のシナリオで回します。契約が数百万件なら、バッチ時間が数日単位になることがあります。そのため、どこまで計算したかを保存して、途中から再開できる構造が、最初から必要です。全部回してから失敗したら、最初からやり直すことはできません。

同じ入力なら、同じ答えが出なければなりません。監査で、「この数字がどう出たのかを見せてほしい」という要求が来ます。そのためには、計算に使った仮定、料率表のバージョン、コードのバージョンを、結果と一緒に保存しなければなりません。結果だけを保存するシステムは、数か月後にその数字を再現できません。

推定値は、あとで変わります。会計の締め後に仮定が変わったら、その時点から反映するか、過去を計算し直すかが決まっていなければなりません。システム側では、「確定した期間はロックする」というルールとして現れます。ロックがなければ、締めた四半期の数字が静かに変わり、その事実を外部監査で発見することになります。

開発者が計理をすべて知る必要はありませんが、3つは尋ねなければなりません。この数字の基準日はいつか、どの仮定を使ったか、もう一度計算すると同じ値が出るか。この3つが答えになれば、残りはアクチュアリーの担当です。

性能は、たいてい入出力から来ます。契約別のキャッシュフローは、行ではなく列単位で保存して圧縮すれば、大きく減ります。計算そのものより、その結果を読み書きする時間が、バッチの大半を占める場合がよくあります。

実務で本当に大切なこと

1つ目に、同じ契約が、3つの層で違う数字です。原価の準備金とIFRS17の負債が違うのは、エラーではなく、仮定が違うからです。突合するときは、層を混ぜないでください。

2つ目に、仮定はデータであり、バージョンがあります。危険率表・割引率曲線・事業費の仮定は、決算時点ごとに確定し、どの決算でどの仮定を使ったかが、再現の条件です。

3つ目に、機微情報は最小限に扱ってください。準備金と損害率は、診断名がなくても計算できます。分析マートに診断コードが本当に必要かを先に尋ね、必要なら、マスキングとアクセス統制を設計に入れます。

次のラボで、契約5件の責任準備金を計算し、現行の割引率でBEL・RA・CSMを出し、会社の数字で支払余力比率まで一度に作ります。