契約の状態はカラムに書かれていない

一言でいうと

保険契約の状態はどこかに保存された値ではなく、払込履歴と基準日から毎回計算し直される値です。そのため、状態カラムと事実はいつもずれます。

なぜ必要なのか

保険会社の現場に入った最初の週に、こんな依頼を受けます。「この契約、失効処理がされていないようなので、見ていただけますか。」

ログを見ます。エラーはありません。夜間バッチも成功で終わっています。テーブルを開くと、statusカラムに정상(韓国語で「正常」を意味する語です)が入っています。システムは指示されたとおりにすべて実行したと言っているのに、担当者は間違っていると言います。

ここで行き詰まる理由は技術ではありません。「失効」の意味を知らないからです。その言葉の意味を知っていれば、どこを見ればよいかが5秒で決まり、知らなければ1日をログに費やします。

どう動くのか

保険契約は次の順に進みます。

청약 → 인수(언더라이팅) → 성립 → 유지(납입) → 실효 → 부활 → 해지 / 만기

前の3つは人が決める出来事で、後ろのものはほとんどが時間が決めます。この違いがデータの形を分けます。

申込みは、顧客が加入を申請した状態です。まだ契約ではありません。ここで顧客は告知義務を負います。これまでにかかった病気、服用中の薬、職業などです。

引受(アンダーライティング)は、会社がそのリスクを引き受けるかどうかを決める手続きです。結果は次の4つのうち1つです。標準体での引受、保険料割増での引受、特定の部位・疾病を除いた不担保での引受、謝絶です。「申込みが引受で却下された」という言葉は、この段階で謝絶されたという意味です。

成立は、初回保険料が入金され、会社が承諾した時点です。この時点から保障が始まります。

維持は毎回の保険料を払い込む区間で、ここで2つの日付が重要です。払込期日と猶予期間です。期日に払えなくても、すぐに契約が切れるわけではなく、一定期間待ってもらえます。

失効がこのコースの最初の落とし穴です。失効は出来事として起きるものではありません。どの表にも「この契約が失効した」という記録はありません。あるのは未払込の回次1つと猶予ルールだけで、失効日はそこから計算されて出てきます。

납입기일        2026-02-10
유예 만료일     2026-03-31   ← 납입 해당월의 다음 달 말일
실효일          2026-04-01   ← 유예 만료일 다음 날

猶予満了日の当日まではまだ有効です。この1日が実際に紛争を生みます。3月31日に事故が起きれば保険金が支払われ、4月1日に起きれば支払われません。

復活も誤解が多いものです。失効した契約に未払込の保険料を入金すれば自動的に生き返ると思いがちですが、そうではありません。復活は復活申込、告知義務の再履行、審査をもう一度経る必要があります。その間に病気になっていた場合は、不担保が付くか謝絶されることがあります。そのため、失効後に入ってきた入金は、復活イベントがない限り契約を復活させません。

では、なぜテーブルにstatusカラムがあるのでしょうか。毎回計算すると遅いからです。そこで夜間バッチが計算してカラムに書き込みます。その瞬間、次のように分かれます。

status 컬럼   어젯밤 배치가 계산한 '의견'
납입 이력      지금 다시 계산할 수 있는 '사실'

バッチが失敗したり、復活処理を反映できなかったり、後から入ってきた訂正に追いつけなかったりすると、意見と事実がずれます。そしてバッチは黙って失敗します。エラーログが残らないのではなく、残っても誰もそのログをこの契約と結びつけません。

現場での姿

1つ目に、失効と誤って判定された契約には保険金が支払われません。窓口では「失効した契約なので支払えません」と答え、顧客は何か月も争ったあげく、金融監督院に苦情を申し立てます。調べてみると、原因は復活処理バッチが3月に1回失敗したことです。不当な不支払いには支払額に遅延利息が付き、件数そのものが検査での指摘事項になります。

2つ目に、正常のまま誤って残っている失効契約のほうが危険です。顧客は保障が切れたことを知りません。案内状も届きません。その状態で事故が起きると、そのとき初めて知ることになり、その場で会社と顧客の双方が損害を被ります。

3つ目に、復活時に告知義務を改めて受けずに処理した契約は、数年後の請求時点で問題が表面化します。審査で「契約前告知義務違反」として不支払いとなり、顧客は「あのとき誰も聞かなかった」と言います。記録がなければ会社の負けです。

その次のラボですること

まず次の理論で基準日と遡及訂正を見て、そのあとラボに進みます。

契約40件と払込履歴480回次、契約イベント、そして後から入ってきた収納訂正を自分で作ります。そのデータで特定の基準日の契約状態を払込履歴から計算し、システムのstatusカラムと突き合わせて、ずれている契約9件を見つけ出します。ずれの方向は3つに分かれ、方向ごとに顧客が受ける被害が違います。