Skip to content
Published on

信用評価システム(CSS)の設計 — スコアカードからML審査まで

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに

前回の記事でLOS(Loan Origination System)のパイプラインを扱った際、審査段階の核心はCSSだと述べました。CSS(Credit Scoring System)は「この借主にお金を貸したら返してくれるのか」という問いに確率で答えるシステムです。数十秒で完結する非対面ローンの即時審査も、法人与信の格付算定も、結局はこのシステムが出す数字の上で回っています。

CSSは興味深い位置にあるシステムです。統計学と機械学習というモデリングの世界、リアルタイムAPIとフィーチャーストアというエンジニアリングの世界、そしてバーゼル規制と金融消費者保護というコンプライアンスの世界が、一点で交わるからです。モデルをうまく作ってもサービングが遅ければ非対面チャネルは死に、サービングが速くても説明可能性がなければ規制を通過できません。

本稿ではCSSの役割区分(申込スコア/行動スコア)から、スコアカード開発の方法論(WoE/IV)、伝統的モデルとMLモデルの比較、サービングアーキテクチャ、意思決定エンジン、モニタリング(PSI)、そして法人与信の内部格付手法まで幅広く扱います。本稿はシステムと方法論に関する技術解説であり、特定の金融商品の勧誘や投資・法律上の助言ではありません。規制に関する内容は一般論ですので、実際の適用時にはコンプライアンス部門のレビューが必要です。

CSSの役割 — 申込スコアと行動スコア

CSSが算出するスコアは、用途によって大きく二つに分かれます。

区分申込スコア (Application Score)行動スコア (Behavior Score)
時点新規申込時点口座保有期間中に周期的(月次など)
入力CB情報、申込書情報、所得/在職自行取引履歴、返済パターン、枠の利用率
用途承認/否決、初期限度額/金利増枠/減枠、更新審査、早期警戒
データの深さ外部情報中心(自行履歴なし)内部の行動データが豊富
モデル更新周期比較的長い(1~2年)短い(四半期~年次の再検証)

申込スコアは「初めて見る顧客」を外部情報だけで判断しなければならないためCB(信用情報機関)データへの依存度が高く、行動スコアは自行の取引データが蓄積された既存顧客を扱うため判別力がはるかに優れています。システムの観点では、申込スコアがリアルタイムAPI呼び出し型、行動スコアが月次バッチ算出型という、ワークロードの違いが重要です。この二つを一つのサービング基盤に押し込むと、バッチ負荷がリアルタイム審査の遅延に波及する事故が起きやすくなります。

このほか、督促・回収の優先順位付けのための回収スコア(Collection Score)、不正利用検知のための不正スコア(Fraud Score)などが、同じ基盤の上で運用されることも多いです。

スコアカード開発の概要

開発パイプライン

伝統的なスコアカード開発は、おおむね次の段階で進みます。

母集団定義 -> サンプリング -> 不良(Bad)定義 -> 観察/成果期間の設定
   -> 特性(変数)候補の導出 -> ビニング(Binning) -> WoE変換
   -> IVベースの変数選定 -> ロジスティック回帰の適合
   -> スコアのスケーリング -> 検証(KS, AUC, Gini) -> 戦略策定 -> デプロイ

まず不良(Bad)の定義がすべての出発点です。通常は「成果期間内に90日以上の延滞が発生」を不良と定義しますが、商品特性によっては60日を使うこともあります。観察期間(特性を抽出する過去の区間)と成果期間(不良かどうかを見届ける未来の区間)の設定を誤ると、モデル全体が無意味になります。

もう一つ重要なのが**否決者推論(Reject Inference)**です。学習データは「承認されて実際の成果を観察できた顧客」に偏っています。否決された申込者がもし承認されていたらどんな成果になったかを推定して補正しなければ、モデルは既存の承認ポリシーをなぞる循環論理に陥ります。

ビニングとWoE/IV

連続変数(年収、負債比率など)はそのまま使わず、区間(bin)に分けたうえで、各区間をWoE(Weight of Evidence)値に変換します。数式は次のとおりです。

WoE(i) = ln( (Good_i / Good_total) / (Bad_i / Bad_total) )

  Good_i     : i番目の区間の優良(正常返済)件数
  Bad_i      : i番目の区間の不良件数
  Good_total : 全体の優良件数
  Bad_total  : 全体の不良件数

IV (Information Value)
  = SUM over i [ (Good_i/Good_total - Bad_i/Bad_total) * WoE(i) ]

IV解釈の慣例:
  0.02未満       : 予測力なし (変数除外)
  0.02 ~ 0.1     : 弱い予測力
  0.1  ~ 0.3     : 中程度の予測力
  0.3  ~ 0.5     : 強い予測力
  0.5超          : 過度に強い -> ターゲットリーク(leakage)を疑う

WoE変換の実務上の利点は明確です。欠損値と外れ値を専用の区間に吸収でき、変数とデフォルト率の非線形関係を単調(monotonic)な区間に整理でき、回帰係数の解釈が直感的になります。ビニングでは、各区間のサンプル数が十分か(通常は全体の5%以上)、区間ごとの不良率が単調に動くかを確認します。不良率がギザギザに動くビニングは過学習のシグナルです。

IVが異常に高い変数は喜ぶべきものではなく、疑うべきものです。たとえば「現在延滞中かどうか」のような変数は事実上ターゲットの同義反復なので、申込時点で知り得た情報なのか(time-of-decision availability)を必ず検証する必要があります。

スコアのスケーリング

ロジスティック回帰の出力(対数オッズ)を、人が扱いやすいスコアに変換します。

Score = Offset + Factor * ln(odds)

  Factor = PDO / ln(2)
  Offset = BaseScore - Factor * ln(BaseOdds)

例: PDO(Points to Double Odds) = 40,
    基準点600点でオッズ50:1の場合
  Factor = 40 / ln(2) = 57.7
  Offset = 600 - 57.7 * ln(50) = 374.3

  -> スコアが40点上がるごとに優良:不良のオッズが2倍

このスケーリングパラメータ(PDO、基準点、基準オッズ)はモデルバージョンと共に構成管理しなければなりません。スコア分布が変わるモデル交換の際、戦略テーブルのカットオフを併せて調整しないと、承認率が急変する事故が起きます。

伝統的ロジスティック vs MLモデル

比較

観点ロジスティック + WoEスコアカードML (XGBoost, LightGBMなど)
判別力 (AUC/KS)ベースライン通常数ポイント優位 (データが豊富なほど差が拡大)
説明可能性配点表で完全に透明SHAPなど事後説明手法が必要
否決理由の算出配点減点の上位項目から直接導出SHAP寄与度ベースで導出 (検証が必要)
単調性制約ビニング段階で自然に反映単調制約オプションで強制可能
運用/再学習変更影響分析が容易ドリフトに敏感、再学習ガバナンスが必要
規制検査方法論が定着し説明負担が低いモデルリスク管理体制の立証負担

規制の観点 — 説明可能性と否決理由

信用評価は、その結果が個人の金融アクセスを左右する意思決定であるため、規制は「なぜその決定になったのか」の説明を要求します。韓国の信用情報法体系では、個人信用評価結果に対する説明要求・異議申立の権利が制度化されており、自動化された評価に対する説明義務も強化される傾向にあります。否決時に具体的な理由(adverse action reasons)の通知を義務付ける米国のECOA/Reg Bのような法制も同じ方向です。

実務的にこれが意味するところは明確です。モデルが何であれ、申込案件単位で「スコアを下げた上位要因」を一貫して算出するパイプラインが、モデルサービングの一部でなければならないということです。スコアカードなら配点表から直接得られ、MLモデルならSHAP値の上位の負の寄与フィーチャーを理由コードにマッピングするレイヤーを設けます。このとき、理由コードのマッピングテーブル自体もバージョン管理の対象です。

ML導入時のよくある折衷案はハイブリッドです。承認/否決の境界の意思決定には単調制約をかけた解釈可能なモデルを使い、MLモデルは限度額・金利の細分化やチャレンジャー(候補モデル)として運用しながら信頼を積み上げる方式です。米連邦準備制度のSR 11-7に代表されるモデルリスク管理フレームワーク — 開発・検証・利用の分離、独立検証、文書化 — は、どのモデルを使うにせよ適用されると考えるのが安全です。

モデルサービングのアーキテクチャ

リアルタイム審査APIとフィーチャーストア

                     +---------------------------+
 LOS審査リクエスト ->|  スコアリングAPIゲートウェイ|
 (顧客ID, 申込情報)  +------+--------------------+
                            |
              +-------------+--------------+
              v                            v
     +----------------+          +------------------+
     | フィーチャー    |          |  モデルサービング |
     | アセンブラ      |--特徴--->|  - モデルレジストリ|
     | - オンラインストア| ベクトル|  - バージョンルーティング|
     |   参照 (ms)     |          |  - チャンピオン/  |
     | - リアルタイムCB変換|       |    チャレンジャー |
     +-------+--------+          +---------+--------+
             |                             |
             v                             v
     +----------------+          +------------------+
     | オンライン      |          | 意思決定エンジン  |
     | フィーチャーストア(KV)|    | - 戦略テーブル    |
     +-------+--------+          | - カットオフ/オーバーライド|
             ^                   +---------+--------+
             | 同期                        |
     +-------+--------+                    v
     | オフラインストア |          承認/条件付/否決 + 理由コード
     | (ウェアハウス)  |          + スコア/フィーチャーのスナップショット保存
     +----------------+

核心となる設計ポイントは次のとおりです。

  • オンライン/オフラインのフィーチャー一貫性: 学習はウェアハウス(オフライン)から、サービングはKVストア(オンライン)からフィーチャーを読みます。同じフィーチャーが二つの経路で異なって計算される学習-サービングの歪み(training-serving skew)は、CSSの品質事故の常連の原因です。フィーチャー定義をコードに一元化し、二つのストアを同じ定義から実体化(materialize)する必要があります。
  • 時点整合性(Point-in-time correctness): 学習データを作る際は「その申込時点で知り得た値」だけを使わなければなりません。フィーチャーストアが時点参照をサポートしていなければ、未来情報のリークが発生します。
  • レイテンシ予算: 非対面審査の全体予算が数秒なら、CB照会が大半を占めるため、フィーチャー参照と推論に許される時間は数百ミリ秒程度です。フィーチャーの組み立ては並列化し、モデルは推論遅延を基準に選択します。
  • スコアのスナップショット: 算出したスコアだけでなく、入力フィーチャーベクトル全体、モデルバージョン、戦略バージョンを申込案件に帰属させて保存します。再現可能性は、LOSと同様にCSSでも第一原則です。

意思決定エンジン

戦略テーブル

スコアは確率にすぎず、決定は戦略です。意思決定エンジンはスコアとポリシー変数(DSR、既存負債、所得形態など)を組み合わせて、承認/条件付/否決と限度額・金利を決定します。

戦略テーブルの例 (概念):

  セグメント: 給与所得者 / 信用ローン

  スコア区間   DSR 40%以下        DSR 40~50%        DSR 50%超
  ---------  ----------------   ---------------   -------------
  720以上     承認, 限度額1.0x   承認, 限度額0.7x   条件付(書類)
  650~719     承認, 限度額0.8x   条件付(書類)       否決
  600~649     条件付(保証付)     否決               否決
  600未満     否決               否決               否決

  * 限度額倍率は所得ベースで算出した基準限度額への乗数
  * すべてのセルに理由コードと戦略バージョンが結合される

戦略テーブルはルールエンジンに外部化し、施行日のバージョン管理、変更前のシミュレーション(過去申込の再処理)、決裁権者の承認を経てデプロイします。実運用では、モデルを交換せずに戦略だけを変えて承認率を調整するケースの方が多いのです。

チャンピオン/チャレンジャー

新しいモデルや新しい戦略を、いきなり全トラフィックに載せることはしません。

  • シャドーモード: チャレンジャーはスコアを算出して記録するだけで、決定には関与しません。数か月後に実際の成果と比較して判別力を検証します。
  • トラフィック分割: 検証が終われば、ランダムな一部(例: 10%)にチャレンジャー戦略を適用し、承認率・デフォルト率・収益性をチャンピオンと比較します。金融の意思決定のA/Bテストは、一般のサービスと違い、消費者保護の観点での公平性レビューが先行しなければなりません。
  • 昇格とロールバック: チャレンジャーの昇格時には戦略バージョンが交換され、問題が発生すれば即座に以前のバージョンへルーティングを戻せなければなりません。モデル/戦略のバージョンルーティングテーブルがこれを可能にします。

モデルモニタリング

PSI — 母集団の安定性

モデルはデプロイされた瞬間から老い始めます。入力分布が開発当時と変わっていくのを追跡する代表的な指標がPSI(Population Stability Index)です。

import numpy as np

def psi(expected: np.ndarray, actual: np.ndarray,
        breakpoints: np.ndarray) -> float:
    """PSI = SUM (actual_pct - expected_pct) * ln(actual_pct / expected_pct)

    expected   : 開発(基準)時点のスコアサンプル
    actual     : 直近の運用時点のスコアサンプル
    breakpoints: 基準サンプルの十分位などで作った区間境界
    """
    eps = 1e-6
    exp_pct = np.histogram(expected, bins=breakpoints)[0] / len(expected)
    act_pct = np.histogram(actual, bins=breakpoints)[0] / len(actual)
    exp_pct = np.clip(exp_pct, eps, None)
    act_pct = np.clip(act_pct, eps, None)
    return float(np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct)))

# 慣例的な解釈:
#   0.1未満    : 安定
#   0.1 ~ 0.25 : 注意 (原因分析)
#   0.25超     : 不安定 (再開発の検討)

PSIは最終スコアだけでなく主要フィーチャーごとにも算出してこそ、原因を追跡できます。スコアのPSIが跳ねたとき、特定のフィーチャー(例: 新しい流入チャネルの所得分布)のPSIも一緒に跳ねていれば、母集団変化の震源地をすぐに特定できます。

性能モニタリングと早期指標

デフォルトはゆっくり現れるため(成果期間12か月など)、AUC/KSのような判別力指標は遅行します。運用では次を組み合わせます。

  • 早期延滞率(early delinquency): 実行後3~6か月以内の30日延滞率をビンテージ(実行月)単位で追跡。モデル劣化の最速のシグナルです。
  • 格付別デフォルト率の単調性: 格付が悪いほどデフォルト率が高くなければなりません。逆転が生じたら格付体系が崩れています。
  • オーバーライド率: 審査担当者がモデルの決定を覆す比率が高まれば、モデルへの信頼が壊れたという運用上のシグナルです。オーバーライドの理由はコード化してモデル改善に還流します。

法人与信と内部格付手法 — PD/LGD/EAD

リテールのCSSがスコアを出すとすれば、法人与信と規制資本の世界は三つのリスクパラメータで語ります。

期待損失 EL = PD x LGD x EAD

  PD  (Probability of Default)   : 1年以内のデフォルト確率 (格付別)
  LGD (Loss Given Default)       : デフォルト時の損失率 (回収率の補数)
  EAD (Exposure At Default)      : デフォルト時点のエクスポージャー
                                   (未使用枠 x CCF を含む)

規制資本(バーゼル内部格付手法)は、これらのパラメータを
監督上の算式に代入してリスクアセット(RWA)を算出
  - FIRB(基礎的内部格付手法): PDのみ自行推計、LGD/EADは監督値
  - AIRB(先進的内部格付手法): PD/LGD/EADすべて自行推計

システムの観点から内部格付手法(IRB)が意味するところは次のとおりです。

  • 格付システムとパラメータ推計システムの分離: 債務者格付(デフォルトリスク)と案件格付(回収構造)を分離して管理し、各格付に長期平均ベースのPD/LGDをキャリブレーションします。
  • デフォルト定義の一元化: バーゼルのデフォルト定義(90日延滞、または返済の見込みなしの判断)が、内部システムの延滞・期限の利益喪失コードと正確にマッピングされなければなりません。このマッピングがずれると、推計値全体が揺らぎます。
  • データ履歴の要件: パラメータ推計には複数年(PDは5年以上など)のデフォルト・回収履歴が必要なため、データの保存と履歴の完全性がモデルと同じくらい重要です。
  • CSSとの関係: リテールIRBではプール(pool)単位でパラメータを推計しますが、プール割当の入力として行動スコアが使われるなど、CSSと規制資本の体系がつながっています。さらにIFRS 9の予想信用損失の計算も同じパラメータ体系の変形(12か月/全期間、マクロ経済見通しの反映)を使うため、パラメータマートは多目的での利用を前提に設計すべきです。

公平性と規制遵守

信用評価システムの設計において、コンプライアンスは機能要件です。

  • 禁止変数: 性別、出身地域のような差別の恐れがある属性はモデル入力から除外するのが原則であり、より厄介な問題は**代理変数(proxy)**です。居住地域コードが特定の集団の代理変数として機能していないか、相関分析と公平性指標(集団別の承認率・誤分類率の差)で点検します。
  • 金融消費者保護の観点: 金融消費者保護法体系の適合性・適正性の原則と説明義務は販売プロセス上の義務ですが、審査結果の告知(否決理由、金利算定根拠)と絡み合い、CSS出力の説明品質に直接的な要求を生み出します。
  • 信用情報の管理: 信用情報法上の収集・利用同意、保有期間、破棄義務は、データパイプラインの設計制約です。特に、モデル学習データセットに入った個人信用情報の保存期限管理は、頻繁に漏れるポイントです。
  • モデルガバナンス: モデルインベントリ、開発文書、独立検証報告書、変更履歴、定期再検証スケジュール — SR 11-7流の体系を備えれば、国内外のどんな検査にも基本となります。

データパイプライン

ソース                   収集/蓄積               加工/サービング
------                   ---------               -------------
CB照会レスポンス ------> 原本保存 (不変)   ----> フィーチャー定義コード
申込書/審査結果 -------> 標準化レイヤー    ----> オフラインストア (学習)
勘定系元帳(返済履歴) --> 日次バッチETL     ----> オンラインストア (サービング)
行動データ(チャネルログ)-> ストリーミング収集 -> スコア/成果マート
                                               (ビンテージ分析, モニタリング)

原則をいくつか挙げます。

  1. 原本の不変保存: CBレスポンスの原文は、パース結果とは別に不変で保存します。パースロジックのバグが見つかったとき、原文がなければ復旧は不可能です。
  2. 成果ラベルのパイプライン: モデル学習のラベル(不良かどうか)は元帳の延滞履歴から来ます。延滞コード体系の変更、債務調整案件の扱い方がラベル品質を左右するため、ラベル生成ロジック自体をバージョン管理します。
  3. 保存と破棄: 法定保存期限と破棄義務をデータセット単位のメタデータとして管理し、学習スナップショットにも破棄ポリシーを伝播させます。

運用事例シナリオ

仮想の事例二つで運用感覚を整理します。

事例1 — スコア分布の突然の右方シフト。 月次モニタリングで申込スコアのPSIが0.31に急騰しました。フィーチャー別のPSIを見ると、「直近3か月のCB照会件数」の分布が大きく変わっていました。原因は、ローン比較プラットフォームとの提携拡大で流入する母集団自体が変わったことでした。モデル自体の欠陥ではありませんが、新しい母集団でのカットオフの妥当性を再検討し、ビンテージの早期延滞率を強化観察の対象に指定しました。教訓: PSIの急騰は「モデルの故障」ではなく「母集団の変化」のシグナルであることが多く、対応は戦略レベルになり得ます。

事例2 — チャレンジャーMLモデルの罠。 XGBoostのチャレンジャーがシャドーモードでチャンピオン比KS 6ポイントの優位を見せ、昇格を検討しました。ところが、否決理由算出の検証で、SHAPの上位の負の寄与フィーチャーが「申込の時間帯」のような説明不可能な変数になる案件が多数見つかりました。当該フィーチャーを除去し、単調制約を追加して再学習すると、KSの優位は4ポイントに縮みましたが、理由コードの品質が確保されたため昇格しました。教訓: 判別力数ポイントと説明可能性の交換は、CSSでは日常的な意思決定です。

設計チェックリスト

  • 不良の定義、観察/成果期間が文書化され、ラベル生成コードと一致しているか
  • 否決者推論を適用したか、適用していないならバイアスの限界を文書化したか
  • すべてのフィーチャーに時点整合性(申込時点での利用可能性)の検証があるか
  • オンライン/オフラインのフィーチャーが単一の定義から実体化されているか
  • 申込案件単位でフィーチャーベクトル・モデルバージョン・戦略バージョンのスナップショットが保存されているか
  • 否決理由コードがモデルタイプと無関係に一貫して算出されているか
  • スコア/フィーチャーのPSI、ビンテージ早期延滞率、オーバーライド率のモニタリングが自動化されているか
  • チャンピオン/チャレンジャーのトラフィック分割と即時ロールバック経路があるか
  • 戦略テーブルが施行日バージョン管理とデプロイ前シミュレーションを経ているか
  • 禁止変数と代理変数の点検、集団別の公平性指標の算出が手続き化されているか
  • モデルインベントリと独立検証の体制があるか
  • 学習データの保存期限・破棄ポリシーが執行されているか

おわりに

CSSは「良いモデル」だけでは完成しません。時点整合的なフィーチャーパイプライン、再現可能なスナップショット、説明可能な理由の算出、安定性モニタリング、そして戦略とガバナンスが一体となって動いてこそ、審査という意思決定が信頼を得ます。判別力指標の数ポイントよりも、1年後の監査の前で「この申込がなぜ否決されたのか」を30秒以内に再現できる体制こそが、CSSの実力です。

次回は、ローン実行以後の世界 — 返済スケジュール、延滞管理、資産健全性分類と引当金、NPL — を扱う事後管理システムを見ていきます。本稿は技術解説であり、金融商品の勧誘や投資・法律上の助言ではないことを改めて明記します。

参考資料

Discuss on Twitter • View on GitHub