金融機関向けの期中モニタリング
Tideline Monitor
決算期を待たずに、
取引先の信用リスクを把握する。
金融機関がお持ちの月次の取引データと決算情報から、優先して確認すべき取引先とその理由をお届けします。既存の格付や延滞管理は置き換えず、決算と決算の間の変化を見る仕組みを加えます。
Why
取引先の変化を、月次のデータから捉えます
延滞に至るまでのよくある順番（模式図。間隔は取引先によって異なります）
取引先の事業の変化
- 売上が落ちる 粗利率が下がる
- 資金繰りが 苦しくなる
- 税・社会保険の 支払いが遅れる
- 延滞
決算書で減益が分かるのは、決算月によっては資金繰りが苦しくなったあとです。毎月の数字を見ていれば、それより早い段階で気づける可能性があります。
決算書は年に1回
決算書で変化が分かるころには、資金繰りの相談や条件の見直しに使える時間が短くなっています。
確認が手作業
試算表や資金繰り表を読むのに時間がかかり、担当先が多いとすべての取引先には目が届きません。
経緯が引き継がれにくい
担当者が異動すると、その取引先でこれまで何があったかが伝わりにくくなります。
How
既存の信用リスク管理を補完する月次モニタリング
既存の管理（一般的な例）
Tideline Monitorで追加する機能
主に使う情報
今：決算書、格付、延滞の情報
加わる：月次の取引データや、取得できる試算表を、決算書と組み合わせて使う
確認のタイミング
今：決算期や定期的な見直し
加わる：毎月
確認する取引先の選び方
今：担当者の判断や、既存のルール
加わる：リスクスコアと、前月からの変化の大きさで順番を付ける
担当者に届くもの
今：格付の結果や延滞のアラート
加わる：理由の文と、取引先に確認したいこと
効果の確かめ方
今：—
加わる：既存の管理との比較により、検知時期と捕捉件数の差を検証する
使うデータは、金融機関が保有する月次の取引データと決算情報が中心です。利用できる項目と更新の頻度は、検証の前に確かめます。当社は、そのデータで精度を確かめ、現場で使える形に仕上げるところまでを担います。用意したモデルをそのまま売るのではなく、金融機関ごとの過去データで検証し、取引先の構成や運用に合わせて作り込みます。
Screens
担当者と本部が、毎月の確認に使う画面
合成データで動かしているデモ画面です。社名・数値はすべて架空です。
01
要確認先の一覧
リスクスコア（0〜100）が要確認の基準を超えた取引先を、高い順に並べます。前月から大きく上がった先も分かり、営業店や業種などで担当分だけに絞り込めます。
02
リスクスコアの要因分析
各指標がリスクスコアにどう影響したかを図で示し、影響の大きい指標を短い文で説明します。理由に合わせて、取引先に確認したいことの下書きも出します。
03
過去データで、どれだけ早く検知できたか
延滞や債務者区分の引き下げが起きた取引先を選び、表示する月を戻すと、その時点のリスクスコアと理由が分かります。合成データによるこの例では、引き下げの8か月前に要確認先に入っていました。
Effects
取引先の変化を早めに捉え、確認対象を絞り込めます
- 早期の相談・対応につなげる
- 決算書が出る前に変化に気づければ、資金繰りや計画の見直しを取引先と早めに相談できます。
- 確認する先を絞り込める
- 全取引先をリスクスコアの順に並べ、深く確認する先を絞り込めます。手間がどれだけ減るかは、試行で確かめます。
- 本部でも取引先の変化を一覧できる
- 営業店別・取引先別のスコア変化を、共通の基準で確認できます。
- 融資条件の見直しに早く着手できる
- 事業の価値が大きく下がる前に、融資条件の見直しや保全を検討できます。
確認の進め方の例（担当50社の場合）
全50社
リスクスコアの変化を毎月確かめる
上位の数社
理由を見て、深く確認する（例：3〜5社）
Validation
過去データで検証し、結果を確認してから導入を判断できます
使い始める前に、仮名化した過去データで、既存の管理と比べてどれだけ早く気づけたかを確かめます。検証では、各月の時点で実際に手元にあったデータだけを使います。後から分かった情報を混ぜると、精度が実際より高く見えるためです。
検知の先行期間
悪化した取引先が、悪化の何か月前から要確認先に入っていたか（中央値）。
捕捉率
悪化した取引先のうち、事前に要確認先に入っていた割合。見逃さなかった割合です。
的中率
要確認先にした取引先のうち、実際に悪化した割合。空振りしなかった割合です。
確認にかかる時間
毎月の要確認先の数と、担当者が確認にかける時間。
- 01
準備
金融機関の手続きによる
対象とする取引先、使うデータ項目、何を「悪化」とするかを決め、委託契約とデータ抽出の手配を進めます。
- 02
過去データでの検証
目安6〜8週間
仮名化した過去データで、悪化した取引先に何か月前から気づけたかと、捕捉率・的中率を既存の管理と比べて報告します。結果をご覧いただいてから、次に進むかを決めていただけます。
- 03
試行
目安3か月
一部の営業店や取引の種類で、担当者に実際に使っていただき、使いやすさと対応につながった件数を確かめます。
- 04
本番運用
継続
対象を広げ、精度を見ながら定期的に再学習します。精度は四半期ごとに報告します。
Governance
金融機関の規程に合わせて、データとモデルの管理を設計します
データとモデルの置き場所
-
国内のパブリッククラウド
国内リージョンに置く当社の専用環境で運用します。
-
閉域網での接続
インターネットを通らない専用回線で接続します。
-
金融機関の環境内
モデルを金融機関の環境に置き、データは外に出しません。検証も同じ環境で行えます。
安全管理とモデルの管理
- 安全対策
- FISC安全対策基準に沿って設計します。
- 外部委託
- 外部委託先として、立入監査や報告のご要望に対応します。
- モデルの文書
- 作り方と検証の結果を文書でお渡しし、モデル・リスク管理に合わせます。
- 精度の確認
- 定期的に報告し、精度が落ちたときは原因を調べて再学習します。
- 最終判断
- 金融機関の担当者が行います。リスクスコアは判断材料で、自己査定や格付の代わりにはなりません。
FAQ
導入前のご質問
- 自機関のデータでは、どの程度の精度が出ますか？
- 精度はデータと取引先の構成によって変わります。それを確かめるのが過去データでの検証です。
- 既存の格付モデルとは、どのような関係ですか？
- 格付モデルは主に決算書を使います。このサービスは毎月のデータで決算と決算の間の変化を捉え、格付を補います。
- すべての取引先を同じ精度で確認できますか？
- 見えるデータが少ない取引先や、試算表が取れない取引先では、変化に気づける度合いが下がります。検証では、データの取得状況ごとに取引先を分けて精度をお示しします。
- 誤検知によって現場の負担が増えませんか？
- 要確認先の数は、担当者が毎月確認できる件数に合わせます。捕捉率と的中率のどちらを優先するかも、金融機関と決めます。
期中の業況把握と予兆検知の設計について、技術ブログで公開しています。
期中モニタリングの課題や検証についてご相談ください
対象先や利用可能なデータを確認し、検証範囲とデータの受け渡し方法をご相談します。通常3営業日以内に返信します。
-
01
対象とデータの確認
対象にする取引先と、お持ちのデータの項目を伺います。
-
02
検証計画の合意
何を「悪化」とするか、使うデータ、日程を検証計画書にまとめます。
-
03
検証レポート
何か月前に気づけたか、捕捉率、的中率を既存の管理と比べてお渡しします。結果を見て、次に進むかを決めていただけます。