商品と契約 — 保険料は計算される

一言でいうと

保険商品は、危険率・利率・事業費の3つの仮定で価格が決まり、契約は、申込み・審査・維持・更新・解約・失効のライフサイクルを回ります。保険システムのデータは、この2つの軸の交点です。

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

保険会社に入ったエンジニアが、最初に耳にする言葉は、「この商品は第三分野保険なので、生保・損保の両方が売る」、「純保険料と付加保険料を分けて保存しなければならない」、「失効した契約は解約ではない」のようなものです。商品と契約の構造を知らなければ、契約テーブルの状態カラムがなぜ10種類を超えるのか、保険料カラムがなぜ3つに分かれているのか、理解できません。

生命保険・損害保険・第三分野保険

韓国の保険業は、3つの系統です。

Life          Covers a person's survival or death. Whole life, term, annuity, savings. Fixed-amount benefits.
Non-life      Covers loss to property. Auto, fire, liability, marine. Indemnity: pays the actual loss.
Third sector  Illness, injury, long-term care. Covers people, but can be indemnity or fixed-amount,
              so both life and non-life insurers sell it.

この区分は、規制と会計にそのままつながります。定額補償は、いくら支払うかが契約のときに決まり、実損補償は、事故が起きてはじめて金額が決まります。システムでは、前者は加入金額カラムが核心で、後者は損害査定の手続きが核心です。

保険料は計算される

保険料は、3つの仮定から出ます。予定危険率(どれだけ死亡したりけがをしたりするか。生命表・経験率)、予定利率(受け取った保険料を運用していくら稼ぐか)、予定事業費率(売って維持するのにいくらかかるか)。前の2つで計算したものが純保険料で、事業費を上乗せしたものが、顧客が払う営業保険料です。その差が付加保険料です。

gross premium = net premium + loading
net premium   = risk premium (PV of death/accident benefits) + savings premium (PV of maturity/surrender refunds)
loading       = acquisition cost + maintenance cost + collection cost

定期保険のように返戻のない商品は貯蓄保険料がなく、終身・貯蓄性の商品は、貯蓄保険料の比重が大きくなります。システムが保険料を3つに分けて保存する理由は、あとで準備金・解約返戻金・事業費の実績を、それぞれ別に計算しなければならないからです。

予定利率が下がると、将来の支払額の現在価値が大きくなり、保険料が上がります。金利が下がるときに、保険会社が予定利率を下げて保険料を上げる理由です。

契約のライフサイクル

Application    The customer applies and discloses health and occupation.
Underwriting   The insurer assesses the risk: accept, decline, or accept with conditions (rating, exclusion).
In force       The policy takes effect when the first premium arrives; premiums are paid each period.
Renewal        Renewable riders re-price at set intervals using updated risk rates.
Surrender      The customer ends the policy. Any surrender value is paid out.
Lapse          Unpaid premium past the grace period suspends coverage. It can be reinstated within a set period.

失効と解約は違います。解約は顧客の意思で、失効は未払いの結果であり、失効は復活が可能です。アンダーライティングの結果は、契約条件になります。同じ商品でも、割増された契約は保険料が違い、不担保の契約は、特定の部位の事故を補償しません。この条件が契約データに残っていなければ、あとで請求が来たときに、支払いの可否を判断できません。

商品が変わる速さがシステム設計を決める

保険システムで最もよく変わるものは、コードではなく商品です。新しい特約が出て、料率が変わり、販売が中止されます。その変化をコードで受けると、デプロイが商品発売のスケジュールに縛られます。

商品をデータとして扱います。補償・料率・引受ルールを表に置き、コードは、その表を解釈するエンジンになります。新商品は表に行を入れる作業になり、デプロイなしで出せます。その代わり、表が間違っているときに捕まえる検証が、コードよりも重要になります。

日付が付いていない料率はありません。契約は締結時点のルールで維持されるので、今日の料率で昨日の契約を再計算してはいけません。すべてのルール行に、適用開始日と終了日を置き、照会するときに基準日を必ず一緒に渡します。基準日のデフォルトを今日にしている関数は、いつか、過去の契約を今日のルールで計算します。

契約は状態機械です。申込み、引受審査、成立、維持、失効、復活、解約、満期。この遷移を、コードのあちこちのifに散らしておくと、どの状態で何が可能なのか、誰も語れなくなります。遷移表を1か所に置いて、それだけを見るようにします。

訂正は、元に戻すことではなく、新しいバージョンです。契約内容が変われば、古い内容も残らなければなりません。どの時点でどんな条件だったかが、そのまま支払いの可否を分けるからです。契約テーブルを更新する代わりに、変更履歴を積んで、現在の状態を計算する構造が、長持ちします。

個人情報の重みが違います。病歴、診断名、受取人の関係は、機微情報です。照会ログを残し、画面ではマスキングし、分析系に出すときは、非識別化処理を経ます。「開発のときだけちょっと」運用データをコピーする慣行が、事故につながる場所です。

実務で本当に大切なこと

1つ目に、仮定は商品定義の一部です。危険率表・予定利率・事業費率は、商品・販売時点ごとに違い、契約は、加入当時の仮定で一生計算されます。仮定をコードに埋め込むと、古い契約を計算できなくなります。

2つ目に、状態は保存された値ではなく、日付から計算される値です。失効は未払い日と猶予ルールから出て、満期は満期日から出ます。状態カラムはバッチが書き込んだ複製で、複製は間違うことがあります。

3つ目に、保険料は1ウォンまで再現できなければなりません。どの仮定をどの順序でどう丸めたかが商品定義書にあり、システムは、その順序をそのまま踏まなければなりません。

次のラボで、仮想の生命表と予定利率で定期保険の純保険料を自分で計算し、事業費を上乗せして営業保険料を作ります。