はじめに
これまでの記事でLOS(ローンの誕生)とCSS(審査の頭脳)を扱いました。しかし、与信システムの中でコードの行数が最も多く、バッチが最も複雑で、監査が最も頻繁に覗き込む場所は、実は実行以後の世界 — 事後管理(LMS、Loan Management System)の領域です。ローンは実行された瞬間から数年間、毎日利息が付き、毎月返済が入り、一部は延滞し、そのまた一部は不良債権(NPL)となって償却または売却されます。このすべての流れが、元帳、会計、引当金、監督報告と整合性を保たなければなりません。
事後管理システムが難しいのは、「時間」が一級市民だからです。すべての金額は基準日に従属し、昨日の処理結果が今日の入力になり、過去を遡及して直した瞬間、その上に積み上がったすべての計算が崩れます。本稿では、返済スケジュールの生成から、延滞管理、資産健全性分類と引当金、督促・回収、NPL処理、債務調整、監督報告まで — ローンの「その後」をシステムの視点で最後まで追いかけます。
先にお断りしておくと、本稿はシステムアーキテクチャとドメインに関する技術解説であり、特定の金融商品の勧誘や投資・法律上の助言ではありません。規制・会計に関する内容は執筆時点の一般的な理解に基づくため、実際の適用時には必ずコンプライアンス・会計・法務部門のレビューを受けてください。
事後管理ドメインの地形図
ローン口座が実行された後に関与するシステムを一望すると、次のとおりです。
+--------------------------------------+
| 与信元帳 (Loan Ledger) |
| 口座マスター / 返済スケジュール / |
| 取引履歴 |
+---+--------+--------+--------+-------+
| | | |
+-------------+ | | +--------------+
v v v v
+---------------+ +----------------+ +-----------+ +----------------+
| 利息/返済処理 | | 延滞管理 | | 健全性 | | 引当金エンジン |
| - 日次利息計上 | | - バケット遷移 | | 分類 | | - IFRS 9 ECL |
| - 収納/充当 | | - 延滞利息 | | - 5段階 | | - Stage判定 |
| - 繰上返済 | | - 期限利益喪失 | | - FLC | | - 会計連動 |
+---------------+ +-------+--------+ +-----------+ +----------------+
|
+------------+-------------+
v v
+--------------+ +----------------+
| 督促・回収 | | NPL処理 |
| - コール配分 | | - 償却(write-off)
| - 約束(PTP) | | - 売却(プール構成)
| - 行為規制 | | - 債務調整の反映 |
+--------------+ +----------------+
| |
+------------+-------------+
v
+--------------------------+
| 監督報告 / 情報系 |
| - 業務報告書, 延滞率 |
| - 信用情報集中機関への登録|
+--------------------------+
各ボックスは別々のシステムかもしれませんし、一つのLMS内のモジュールかもしれませんが、データフローの方向は同じです。元帳が事実(facts)の源泉であり、延滞・分類・引当金・回収・報告はすべて元帳から派生します。派生システムが元帳と異なる数字を持った瞬間から、事故は始まっています。
返済スケジュールの生成
実行(記帳)時点で最初に作られる成果物が返済スケジュールです。返済方式は大きく三つです。
| 方式 | 毎月の返済額 | 元金返済パターン | 総利息 | 主な用途 |
| --- | --- | --- | --- | --- |
| 元利均等 | 一定 | 初期は少なく後期に増加 | 中間 | 住宅担保、リテール信用 |
| 元金均等 | 徐々に減少 | 毎月同額 | 最少 | 法人の設備資金など |
| 期日一括 | 利息のみ | 満期に全額 | 最多 | 極度性、短期、賃貸保証金ローン |
三方式の計算をコードで見ると次のとおりです。金額計算には必ずdecimalを使い、切り捨て・四捨五入のルールを商品条件として明示しなければなりません。
from decimal import Decimal, ROUND_DOWN, ROUND_HALF_UP
UNIT = Decimal("1") # 最小通貨単位への丸め用
def round_unit(amount: Decimal, mode=ROUND_DOWN) -> Decimal:
"""最小単位の処理。切り捨て/四捨五入は商品条件に従う。"""
return amount.quantize(UNIT, rounding=mode)
def equal_installment(principal: Decimal, annual_rate: Decimal,
months: int) -> list[dict]:
"""元利均等: 毎月の返済額が同一。
返済額 = P * r * (1+r)^n / ((1+r)^n - 1), r = 月利
"""
r = annual_rate / Decimal("12")
factor = (Decimal("1") + r) ** months
payment = round_unit(principal * r * factor / (factor - Decimal("1")),
ROUND_HALF_UP)
schedule, balance = [], principal
for seq in range(1, months + 1):
interest = round_unit(balance * r)
principal_due = payment - interest
if seq == months: # 最終回で端数調整
principal_due = balance
payment = principal_due + interest
balance -= principal_due
schedule.append({"seq": seq, "payment": payment,
"principal": principal_due,
"interest": interest, "balance": balance})
return schedule
def equal_principal(principal: Decimal, annual_rate: Decimal,
months: int) -> list[dict]:
"""元金均等: 毎月の元金返済額が同一、利息は残高基準。"""
r = annual_rate / Decimal("12")
base_principal = round_unit(principal / Decimal(months))
schedule, balance = [], principal
for seq in range(1, months + 1):
interest = round_unit(balance * r)
principal_due = base_principal if seq < months else balance
balance -= principal_due
schedule.append({"seq": seq,
"payment": principal_due + interest,
"principal": principal_due,
"interest": interest, "balance": balance})
return schedule
def bullet(principal: Decimal, annual_rate: Decimal,
months: int) -> list[dict]:
"""期日一括: 毎月利息のみ、満期に元金全額。"""
r = annual_rate / Decimal("12")
schedule = []
for seq in range(1, months + 1):
interest = round_unit(principal * r)
principal_due = principal if seq == months else Decimal("0")
schedule.append({"seq": seq,
"payment": principal_due + interest,
"principal": principal_due,
"interest": interest,
"balance": principal - principal_due})
return schedule
実務で押さえるべきディテールがいくつかあります。
- **端数調整**: 回次ごとの切り捨て誤差が累積するため、最終回で残高基準の調整を行います。「最終回の返済額が他の回と少し違う」のは正常であり、これを隠そうとして中間の回をいじってはいけません。
- **日割計算ルール**: 上の例は月単位ですが、実際には返済日間の日数(365/366、うるう年処理)で利息を日割計算する商品が多くあります。日数計算のコンベンション(actual/365など)を商品マスターの属性として持たせるべきです。
- **据置期間**: 据置期間中は利息のみを支払い、据置終了後に元金の分割が始まります。スケジュール生成器は据置区間と返済区間を別々のパラメータで受け取る必要があります。
- **変動金利の再設定**: 金利が変わったら、残りの回次のスケジュールだけを再生成します。すでに過ぎた回次は絶対に再計算しません — この原則は後の「落とし穴」の節で改めて強調します。
返済処理 — 正常、繰上、一部
収納と充当順序
返済処理の核心は、入ってきたお金をどこに先に充てるか、すなわち**充当順序(appropriation order)**です。一般的な順序は費用(法的費用など)、利息(延滞利息を含む)、元金の順ですが、約定と内部ポリシーによって変わり得るため、コードにハードコーディングせず、商品・口座の属性として外部化すべきです。
from decimal import Decimal
def apply_payment(received: Decimal, dues: dict) -> dict:
"""収納額を充当順序どおりに配分。duesは基準日現在の未収項目。"""
order = ["fees", "overdue_interest", "interest", "principal"]
applied = {}
remaining = received
for bucket in order:
due = dues.get(bucket, Decimal("0"))
take = min(remaining, due)
applied[bucket] = take
remaining -= take
if remaining <= Decimal("0"):
break
applied["unapplied"] = remaining # 残余額は前受金として処理
return applied
配分結果は会計仕訳と1:1で対応しなければならず(利息収益、元金回収、仮受金など)、残余額(前受金)の扱いは、次回の自動充当か即時返金かをポリシーとして定めておきます。
繰上返済
満期前に元金の全部または一部を返すのが繰上返済です。システム観点の処理は次のとおりです。
- **全額繰上返済(完済解約)**: 基準日までの日割利息 + 元金残高 + 繰上返済手数料を算出して収納し、口座を解約状態へ遷移させます。担保があれば担保解除(根抵当の抹消)プロセスが後続でつながります。
- **一部繰上返済**: 元金残高が減った後の残りのスケジュールをどうするか、顧客が選択します — 回次あたりの返済額を減らして満期を維持、または返済額を維持して満期を短縮。どちらの場合も未来の回次だけを再生成します。
- **繰上返済手数料**: 通常「繰上返済元金 x 手数料率 x 残存期間/総期間」の形のスライディング方式が使われ、免除期間(例: 実行後3年経過)と免除条件が商品属性に入ります。
繰上返済手数料 (例示の構造)
手数料 = 繰上返済元金 x 料率 x (満期までの残存日数 / 貸出総日数)
例: 残高1億ウォンのうち5千万ウォンを返済、料率1.2%、
総期間1,095日のうち365日経過 (残存730日)
手数料 = 50,000,000 x 0.012 x (730 / 1,095)
= 400,000ウォン
自動引落と収納チャネル
返済の収納は、自動引落(CMS)、バーチャル口座、窓口、アプリの即時出金など、複数のチャネルから入ってきます。チャネルごとに収納確定の時点が異なるため(自動引落は引落結果ファイルが届いて初めて確定)、「収納受付」と「収納確定」を状態として分離し、確定前の金額が延滞判定に誤って反映されないよう基準日処理に注意が必要です。返済日が休日であれば翌営業日に繰り延べられますが、繰り延べられた日までは延滞とみなさない休日ルールも、スケジュールエンジンが知っていなければなりません。
延滞管理
延滞バケットと段階遷移
返済日にお金が入らなければ延滞が始まります。運用では延滞日数をバケットで区切って管理します。
延滞バケットの遷移 (日次バッチが毎日判定)
正常(Current) --未納発生--> 1~29日 (Bucket 1, 初期延滞)
^ |
| 全額正常化 v
+<----------- 30~59日 (Bucket 2)
| |
| v
+<----------- 60~89日 (Bucket 3)
| |
| v
+<-----?----- 90日以上 (デフォルト認識ゾーン)
|
v
期限の利益喪失 (EOD: Event of Default)
|
v
全額即時返済義務 / 回収強化 / NPLトラック
設計ポイントは次のとおりです。
- **延滞日数の単一定義**: 延滞日数の計算機はシステム全体に一つだけ存在すべきです。回収システムと引当金エンジンがそれぞれ日数を計算すれば、必ずずれます。
- **一部納付とバケット**: 3回分が滞った状態で1回分だけ納付されると、延滞の起算日は2回目の返済日に移動します。「最も古い未納回次基準」という起算ルールを明確に実装する必要があります。
- **バケット遷移の履歴**: バケットの現在値だけを更新せず、遷移履歴(どの日付にどのバケットへ)をappend-onlyで残します。ビンテージ分析(roll rate: バケット間の移動率)がリスク管理の核心的な入力だからです。
延滞利息の計算
延滞が発生すると、約定利息の代わりに(または加えて)延滞利息が付きます。韓国の実務で一般的な構造は「約定金利 + 延滞加算金利(上限規制あり)」で、延滞利率は法定上限金利を超えられません。
延滞利息の計算 (一般的な構造の例)
延滞利率 = MIN(約定金利 + 延滞加算金利, 法定上限)
(1) 期限の利益喪失前: 延滞した「当該回次の未納額」基準
延滞利息 = 未納約定返済額 x 延滞利率 x 延滞日数 / 365
(2) 期限の利益喪失後: 「元金残高の全体」基準
延滞利息 = 元金残高 x 延滞利率 x 経過日数 / 365
例: 未納返済額100万ウォン、約定金利5%、加算3% -> 延滞利率8%
延滞40日なら
延滞利息 = 1,000,000 x 0.08 x 40 / 365 = 8,767ウォン (切捨ルール適用)
期限の利益喪失の前後で**計算の母数自体が変わる**という点が、システム実装の核心です。遷移の時点が一日ずれると延滞利息が丸ごと変わるため、期限の利益喪失の処理日はバッチでの導出ではなく、明示的なイベントレコードとして固定すべきです。
期限の利益喪失
期限の利益喪失は、「残りの期間にわたって分割で返す権利(期限の利益)」を借主が失い、全額の即時返済義務が生じる法的イベントです。一般に、一定期間以上の延滞(約定上の通知要件を含む)、担保価値の著しい下落、借主の信用悪化事由などで発生し、発生前の顧客通知(予告通知、到来通知)の義務があります。
システム観点の処理は次のとおりです。
1. 対象抽出バッチ: 延滞日数・事由の条件を満たす口座を候補として抽出
2. 通知の発送と回答待ち: 通知履歴を法的証憑レベルで保管(発送日時、手段、返送の有無)
3. 期限の利益喪失の確定: イベントレコードの生成、口座状態の遷移、延滞利息の計算母数の切替
4. 後続連動: 信用情報集中機関への登録、保証機関への事故通知(保証付ローン)、回収強化トラックへの移行
期限の利益喪失の後、顧客が延滞金を全額正常化すると期限の利益が**復活**する場合がありますが、この復活処理(計算母数の復元、スケジュールの復旧)は喪失処理より実装難度が高く、バグも多い箇所です。復活可能な条件と回数制限をポリシーとして明確にしておくべきです。
資産健全性分類 — 5段階
監督規定上、金融会社は保有する与信を借主の返済能力と延滞状態に応じて5段階に分類します。いわゆる資産健全性分類であり、韓国の監督体系の伝統的な分類は次のとおりです。
| 段階 | 名称 | 通常の基準(概略) | 意味 |
| --- | --- | --- | --- |
| 1 | 正常 | 延滞なし、返済能力良好 | 回収確実 |
| 2 | 要注意 | 1か月以上3か月未満の延滞など | 潜在リスク |
| 3 | 固定 | 3か月以上の延滞、回収に疑問だが担保の範囲内 | 回収に相当なリスク |
| 4 | 回収疑問 | 固定のうち担保超過部分など | 回収不確実 |
| 5 | 推定損失 | 事実上回収不能 | 損失が確定的 |
二つの点に注意が必要です。
- **延滞日数は出発点にすぎない**: 分類は延滞日数だけで機械的に終わりません。FLC(Forward Looking Criteria)の観点から、借主の将来の返済能力(産業の見通し、財務状態)を反映して下方修正でき、同一借主の他の与信が不良化すれば一緒に下方修正される交差不良(cross-default的な借主単位の分類)のルールもあります。
- **担保による分割分類**: 同じ口座でも、有効担保価額の範囲内の部分は「固定」、超過部分は「回収疑問」に分けて分類するような金額の分割が起こります。分類テーブルは口座単位ではなく、口座-区分(金額断片)単位で設計すべきです。
分類結果は最低積立率ベースの監督目的の引当金につながり(正常は一定比率、要注意・固定・回収疑問・推定損失へ行くほど高い比率)、会計目的のIFRS 9予想信用損失とは**別の体系**として並行運用されます。システムは両方の体系を算出し、通常は二つのうち保守的な(大きい)方が財務に反映される構造をサポートしなければなりません。
引当金 — IFRS 9予想信用損失
3段階モデル
IFRS 9の予想信用損失(ECL、Expected Credit Loss)は、「損失が発生してから積み立てる」従来の発生損失モデルを、「将来の損失をあらかじめ見積もって積み立てる」モデルに変えました。核心はStageの区分です。
IFRS 9 ECL 3段階
Stage 1 Stage 2 Stage 3
(正常) (信用リスクの著しい増大) (信用減損)
12か月ECLを計上 全期間(Lifetime)ECL 全期間ECL
利息収益: 総帳簿価額 利息収益: 総帳簿価額 利息収益: 純帳簿価額
基準 基準 (帳簿価額 - 引当金) 基準
移行トリガー(例):
Stage 1 -> 2 : 30日以上の延滞(反証可能な推定),
信用格付の著しい低下、ウォッチリスト登載など (SICR)
Stage 2 -> 3 : 90日以上の延滞、期限の利益喪失,
債務調整(信用減損の認識)など
回復方向 : 治癒期間(probation)の経過後に上方移行
ECL計算の骨格
ECL = SUM over t [ PD(t) x LGD(t) x EAD(t) x 割引係数(t) ]
- Stage 1: t = 今後12か月
- Stage 2/3: t = 残存満期の全体 (Lifetime)
- マクロ経済シナリオ(楽観/基準/悲観)ごとに算出して確率加重
- PD/LGD/EADはCSS・IRB体系のパラメータを会計目的に変形
システム実装の観点
- **SICR(信用リスクの著しい増大)判定エンジン**: 30日延滞という量的基準のほかに、格付低下幅、ウォッチリスト、業種リスクのような質的基準をルールとして運用します。判定根拠(どのルールに該当したか)を口座-基準日単位で保存してこそ、監査対応が可能になります。
- **Stage移行の非対称性**: 下方移行(1から2、2から3)は即時、上方移行(治癒)は一定期間延滞なしで維持された後にのみ許容する非対称ルールが一般的です。移行履歴はやはりappend-onlyです。
- **シナリオ加重のインフラ**: マクロシナリオごとのパラメータセットを受け取ってECLを複数回計算し、確率加重する構造のため、引当金エンジンは「パラメータセット x 口座」の積で計算量が増えます。月次締めのウィンドウ内に収まるよう、パーティショニングと並列化を設計の初期から考慮すべきです。
- **監査証跡**: 引当金の数字一つについて、「どのモデルバージョン、どのシナリオ、どのパラメータ、どのStage判定」が使われたかをフルに追跡できなければなりません。会計監査が最も深く掘る箇所です。
督促・回収システム
コール配分と作業キュー
延滞が発生すると、督促・回収(コレクション)システムが回収活動を組織します。構造は本質的に「優先順位付きの作業キュー + 行為規制エンジン」です。
延滞口座の流入 (日次バッチ)
|
v
セグメンテーション
- 延滞バケット、回収スコア(Collection Score)、金額、商品
- 自社回収 / 委託回収 / 法的手続トラックの分離
|
v
キャンペーン/キュー配分
- 初期(1~29日): SMS/アプリ通知中心、低コストチャネル
- 中期(30~89日): オペレーターへのコール配分、約束管理
- 後期(90日~): 専担組織、法的手続の検討
|
v
オペレーターのワークリスト
- 通話結果コード、約束(PTP)の登録、次のアクションの日程
- **回収スコアによる差別化**: 自己治癒(self-cure)の確率が高い口座にコールを浪費しないよう、回収可能性スコアで接触強度を差別化します。CSSのインフラで扱った行動スコア・回収スコアがここで使われます。
- **約束管理(PTP、Promise to Pay)**: 相談で「何日までにいくら払う」という約束を構造化して登録し、約束日に収納を自動照合して履行/不履行を判定します。約束の履行率は、相談品質と戦略の核心指標です。
- **収納とのリアルタイム同期**: 顧客がたった今入金したのに督促コールが出ていくのが最悪のシナリオです。収納確定イベントが回収キューから当該口座を即時に除外するよう、イベント連動を設計します。
督促行為の規制遵守
債権の督促・回収は、債権の公正な回収に関する法律などで行為が強く規制される領域です。システムが規制をコードで強制してこそ、人のミスを防げます。
- **接触制限**: 夜間(通常午後9時から午前8時)の接触禁止、1日の接触回数制限などを、ダイヤラーと発送エンジンのレベルで遮断します。「かけるな」というガイドではなく「かけられない」ようにするのがポイントです。
- **第三者への告知禁止**: 家族・職場に債務の事実を知らせる行為は禁止されています。連絡先管理で、借主本人と確認できていない番号への自動発送を防がなければなりません。
- **債務調整・訴訟中の口座保護**: 信用回復委員会への債務調整申請、個人再生・破産手続が開始された口座は、督促行為が制限されます。外部機関連携で当該状態を受信したら、回収キューで即時凍結(hold)する自動化が必須です。
- **全履歴の保存**: すべての接触の試行と結果(録音を含む)を保存します。苦情・紛争において金融会社が立証責任を負う場合が多いからです。
債務調整のシステム反映
延滞した借主の再起を支援する債務調整は、外部制度(信用回復委員会の債務調整、裁判所の個人再生・破産)と、金融会社の自社プログラム(期限延長、金利減免、分割返済への転換など)に分かれます。システムの観点では、共通して次の処理が必要です。
1. **元の債権の凍結と調整条件での新スケジュール生成**: 減免された金利、延長された満期で新しい返済スケジュールを作りつつ、元の約定条件と調整履歴をすべて保存します。元のレコードを上書きしてはいけません。
2. **会計・引当金の連動**: 債務調整は通常、信用減損(Stage 3)の認識事由であり、条件変更による帳簿価額の調整(現在価値の再計算)が発生し得ます。調整タイプごとの会計処理ルールを引当金エンジンと共有すべきです。
3. **健全性分類と治癒期間**: 調整後に一定期間誠実に返済すれば分類を上方修正できますが、この治癒期間中の返済履行の追跡がシステム要件になります。
4. **回収凍結と信用情報の処理**: 調整確定時に回収を中断し、信用情報集中機関へ約定変更・延滞解除の情報を登録期限内に反映します。
NPLの償却と売却
回収の見込みが事実上ない債権は、二つの出口から出ていきます。
償却(Write-off)
償却は会計帳簿から債権を除去する処理です(通常は引当金と相殺)。重要なのは、**償却が債権の消滅ではない**という点です。法的な請求権は生きているため、償却後も「償却債権管理元帳」で残高・時効・回収活動を追跡し続けます。償却後に回収が発生すれば、収益(償却債権回収益)として認識する別の仕訳経路が必要です。消滅時効(通常、商事債権は5年)の管理と、時効中断事由(仮差押、訴訟、一部弁済など)の追跡もこの元帳の役割です。
売却(NPL Sale)
不良債権を束ねてNPL専門投資家や流動化ストラクチャーに売るのが売却です。
NPL売却パイプライン
プール(Pool)構成 実査(Due Diligence) 落札/譲渡実行
- 対象債権の抽出 - データテープの提供 - 債権譲渡契約
- 除外条件フィルタ (借主/担保/延滞履歴) - 譲渡通知 (対抗要件)
(調整中, 訴訟中, - 入札価格の算定 - 元帳の除却処理
保証付など) - Q&A対応 - 事後精算
(基準日以後の回収金)
システム要件は次のとおりです。
- **データテープの品質**: 買い手に提供する債権明細(元金・利息・延滞履歴・担保・法的進行状態)の正確性が、そのまま売却価格になります。情報系での一回限りの抽出で作らず、標準テープの生成機能をシステム化しておくと、反復する売却に有利です。
- **基準日精算**: 入札基準日と譲渡実行日の間に入った回収金は買い手の取り分です。この区間の収納を分離集計する精算ロジックが必要です。
- **譲渡後のイベント処理**: 譲渡された債権への入金が誤って入ってきたら買い手に引き渡さなければならず、顧客からの問い合わせは譲受人への案内にルーティングされます。口座に「譲渡済み」の状態と譲受人の情報を保存していてこそ可能なことです。
- **信用情報の登録**: 譲渡の事実の信用情報集中機関への反映も、期限内の処理対象です。
監督報告と情報系連携
事後管理データは、さまざまな監督報告の源泉です。
- **延滞率の報告**: 延滞率の分子・分母の定義(1か月以上延滞した元利金基準など)は、報告書ごとに異なり得ます。定義別の算出ロジックをコードで明細化し、元帳の締めデータとの整合性チェックを自動化します。
- **健全性分類・引当金の報告**: 業務報告書の分類別残高・引当金の積立内訳は、月次・四半期の締めスナップショットから算出します。締め後の遡及修正が生じると報告の再提出問題になるため、締めのカットオフと修正手続を厳格に管理します。
- **信用情報集中機関への登録**: 延滞の発生・解除、期限の利益喪失、債務調整、譲渡などのイベントには登録期限があります。イベント発生と登録電文の発送をつなぐキューに、未発送の監視アラームを設けます。
データモデル
核心エンティティをERDで要約すると次のとおりです。
+---------------+ +--------------------+ +-------------------+
| LOAN_ACCOUNT |1-----N| REPAY_SCHEDULE | | RATE_HISTORY |
|---------------| |--------------------| |-------------------|
| account_id PK | | account_id FK | | account_id FK |
| product_cd | | seq, due_date | | from_date, rate |
| principal | | principal_due | | reason_cd |
| open_date | | interest_due | +-------------------+
| maturity_date | | status (予定/完納/ |
| status | | 一部納/延滞) | +-------------------+
| repay_method | | version_no |1-----N| TXN_HISTORY |
+------+--------+ +--------------------+ |-------------------|
| | txn_id PK |
|1 | account_id FK |
| | txn_date, type |
N | amount, applied_to|
+---------------+ +--------------------+ | (費用/利息/元金) |
| DELINQ_EPISODE|1-----N| BUCKET_TRANSITION | +-------------------+
|---------------| |--------------------|
| episode_id PK | | episode_id FK | +-------------------+
| account_id FK | | trans_date | | CLASSIFICATION |
| start_date | | from_bucket | |-------------------|
| end_date | | to_bucket | | account_id FK |
| eod_flag | +--------------------+ | base_date |
| eod_date | | class_cd (5段階) |
+------+--------+ +--------------------+ | split_amount |
|1 | COLLECTION_ACTION | | reason_cd |
| |--------------------| +-------------------+
N | action_id PK |
+---------------+ | episode_id FK | +-------------------+
| PTP_PROMISE | | channel, result_cd | | ECL_RESULT |
|---------------| | action_ts, agent | |-------------------|
| promise_id PK | +--------------------+ | account_id FK |
| episode_id FK | | base_date, stage |
| promise_date | | ecl_amount |
| promise_amt | | model_ver |
| kept_yn | | scenario_set_id |
+---------------+ +-------------------+
モデリングの原則をいくつか付け加えます。
- **延滞はエピソード単位**: 一つの口座が延滞と正常化を繰り返すため、「延滞の開始から解消まで」を一つのエピソードエンティティにまとめてこそ、回収履歴・バケット遷移がきれいに帰属します。
- **スケジュールはバージョン管理**: 金利再設定・繰上返済・債務調整でスケジュールが再生成されるたびにversion_noを上げ、以前のバージョンを保存します。「その時点で有効だったスケジュール」を再現できなければなりません。
- **分類・ECLは基準日スナップショット**: 現在値の更新ではなく、基準日ごとの蓄積です。時系列がそのまま監査証跡であり、分析の源泉です。
バッチ設計 — 日次バッチと月次バッチ
事後管理はバッチの世界です。依存関係が生命線です。
日次バッチ (EOD) — 順序がそのまま整合性
01 収納確定処理 (自動引落の結果反映)
02 日次利息計上 (未収利息の積数)
03 延滞判定 / バケット遷移 <- 02の後 (当日収納の反映後)
04 延滞利息の計算 <- 03の後 (バケット/EOD状態の確定後)
05 期限の利益喪失の候補抽出/通知
06 回収キューへの積載/回収 <- 03, 05の後
07 信用情報登録の電文生成
08 元帳-会計の照合 (日次締め)
09 情報系への蓄積
月次バッチ (月次締め)
M1 優遇金利条件の再判定 <- 次の利息サイクルの前
M2 行動スコア/回収スコアの算出
M3 資産健全性分類 <- 延滞/担保データの確定後
M4 IFRS 9 Stage判定 / ECL算出 <- M2, M3の後
M5 引当金の会計仕訳 / 決算連動
M6 監督報告書の算出 <- M3, M4, M5の後
M7 ビンテージ/ロールレート分析マートへの蓄積
バッチ設計で繰り返し強調すべき点は三つです。
- **再起動可能性(restartability)**: 04番が失敗したときに01から回し直す設計では、締め時間を守れません。ジョブ単位のチェックポイントと部分再処理を最初から設計します。
- **基準日のパラメータ化**: すべてのジョブは「今日」ではなく明示的な基準日を入力として受け取るべきです。障害で翌日に再実行しても、前日基準で正確に回らなければならないからです。
- **休日カレンダーの単一ソース**: 返済日の繰延、延滞の起算、利息の日数はすべて営業日カレンダーに依存します。カレンダーマスターは一つでなければならず、年単位の登録時点に検証手続を設けます。
落とし穴 — 遡及再計算の誘惑
事後管理システムで最も危険なアンチパターンを集めました。
1. **遡及再計算**: 「金利の適用が間違っていたから、過去6か月の利息を再計算して上書きしよう」という要求は必ず来ます。絶対に過去のレコードを上書きしてはいけません。過去の取引はそのままにして、差額を別の精算取引(返金または追加請求)として起こす**調整取引パターン**を標準とすべきです。上書きした瞬間、会計の締め、報告書、信用情報の登録、顧客向け明細がすべてずれます。
2. **延滞日数計算機の重複**: 元帳、回収、引当金がそれぞれ延滞日数を計算して一日ずつずれる事故はよくあります。単一モジュールに強制し、派生システムは結果を購読するだけにします。
3. **期限の利益喪失状態の暗黙管理**: 「延滞90日を超えたら喪失とみなす」のような導出ロジックで処理すると、通知要件・復活処理と食い違います。明示的なイベントと状態で管理すべきです。
4. **収納確定前の金額の先行反映**: 自動引落の引落結果が来る前に収納とみなすと、引落失敗時に延滞判定・回収除外がすべてひっくり返ります。受付と確定の分離が答えです。
5. **バケット遷移の時系列の不保存**: 現在のバケットだけを更新すると、ロールレート分析が不可能になり、引当金モデルの入力データも消えます。
6. **締め後のデータ修正**: 月次締めのスナップショットが出た後に源泉を直すと、報告書と元帳が異なる数字を持つことになります。修正は次の期の調整として反映し、例外的な遡及は再提出手続とともに統制します。
7. **時効管理の漏れ**: 償却債権の消滅時効をシステムが追跡していないと、時効が完成した債権への督促で法的リスクが発生します。時効の起算日・中断事由をデータとして管理すべきです。
設計チェックリスト
- [ ] 返済スケジュール生成器が据置期間、日数コンベンション、端数調整、休日繰延をすべてパラメータで受け取るか
- [ ] 金額計算がdecimalベースで、切り捨て/四捨五入のルールが商品属性として明細化されているか
- [ ] 充当順序が外部化され、収納配分の結果が会計仕訳と1:1で対応しているか
- [ ] スケジュールの再生成が未来の回次だけに触れ、バージョン履歴を保存しているか
- [ ] 延滞日数の計算が単一モジュールで、一部納付時の起算ルールが明確か
- [ ] 延滞エピソード・バケット遷移がappend-onlyで保存されているか
- [ ] 期限の利益喪失が明示的なイベントとして管理され、通知履歴が証憑レベルで残るか
- [ ] 健全性分類が金額分割(担保の範囲)をサポートし、基準日スナップショットで蓄積されるか
- [ ] ECL算出のモデルバージョン・シナリオ・Stage判定の根拠がフルに追跡可能か
- [ ] 督促行為の規制(時間帯、回数、第三者告知の禁止)がシステムレベルで強制されているか
- [ ] 収納確定イベントが回収キューとリアルタイムに同期しているか
- [ ] 債務調整・再生手続開始の情報受信時に回収凍結が自動化されているか
- [ ] 償却債権の元帳が別に存在し、消滅時効を追跡しているか
- [ ] NPL売却のデータテープ生成と基準日精算のロジックがシステム化されているか
- [ ] 日次・月次バッチの依存順序が明細化され、ジョブ単位の再起動が可能か
- [ ] 遡及修正の代わりに調整取引パターンが標準として強制されているか
おわりに
事後管理システムは華やかではありません。新規加入者数のような指標もなく、うまく回るほど静かです。しかし、貸出というビジネスの損益は結局ここで決まります — 延滞をどれだけ速く正確に識別するか、引当金をどれだけ信頼性高く算出するか、回収をどれだけ規制の中で効率的に行うか。本稿の核心を一行に縮めるとこうなります。**時間を明示的に扱い(基準日、バージョン、エピソード)、過去を絶対に上書きせず(調整取引)、派生する数字は単一の源泉からのみ流れ出るようにせよ(元帳中心)。**
これで与信シリーズ — LOS(誕生)、CSS(審査)、事後管理(その後) — が一巡しました。改めて、本稿は技術アーキテクチャの解説であり、金融商品の勧誘や投資・法律・会計上の助言ではありません。
参考資料
- [IFRS Foundation — IFRS 9 Financial Instruments](https://www.ifrs.org/issued-standards/list-of-standards/ifrs-9-financial-instruments/)
- [BIS — Basel Framework (CRE: Credit Risk)](https://www.bis.org/basel_framework/)
- [BIS — Guidelines: Prudential treatment of problem assets (NPEの定義)](https://www.bis.org/bcbs/publ/d403.htm)
- [ECB — Guidance to banks on non-performing loans](https://www.bankingsupervision.europa.eu/)
- [金融監督院(韓国)](https://www.fss.or.kr/)
- [金融委員会(韓国)](https://www.fsc.go.kr/)
- [信用回復委員会(韓国)](https://www.ccrs.or.kr/)
- [韓国資産管理公社(KAMCO)](https://www.kamco.or.kr/)
- [韓国信用情報院](https://www.kcredit.or.kr/)
- [国家法令情報センター — 債権の公正な回収に関する法律などの検索](https://www.law.go.kr/)
- [韓国大法院 — 再生・破産の案内](https://www.scourt.go.kr/)
- [ISO 20022 — Universal Financial Industry Message Scheme](https://www.iso20022.org/)
현재 단락 (1/358)
これまでの記事でLOS(ローンの誕生)とCSS(審査の頭脳)を扱いました。しかし、与信システムの中でコードの行数が最も多く、バッチが最も複雑で、監査が最も頻繁に覗き込む場所は、実は実行以後の世界 — ...