リスクを測り、複数の銀行を一緒に読む
v18は同じ入力で不確実さを比較し、v19は法人ごとの帳簿を守りながら集約する。計算と責任の境界を学ぶ。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- リスクの数字は、凍結した入力・式・架空の仮定の組み合わせ
- グループ内でも法人別の権限と帳簿は消えない
- 連結の消去は報告上の計算であり、元の仕訳を削除しない
この記事の目次
1. v18：比較の前に、同じ時点の材料をそろえる
銀行のリスクを一つの赤いランプで表すと、原因も対策も見えません。MiniBankのv18は、信用、市場の金利、流動性、業務上の障害という四つを別々に計算し、基準条件と厳しい条件を比べます。実際の与信判断や規制上の評価を行うものではなく、式と仮定を追える教育用の測定です。
比較の材料は、融資残高と延滞区分、Treasuryの資金状況、預金商品の価格、インシデントの時間などです。実行のたびに最新値を読み直すと、金利ショックの影響なのか、その間に返済が入った影響なのか分かりません。そこで一時点の入力をスナップショットとして凍結します。同じスナップショットを使い、シナリオだけを変えれば、変えた前提の影響を比較しやすくなります。
凍結するのは数字だけではありません。取得時刻、論理営業日、復旧状態、入力元が利用可能か、警告なども残します。融資の未収利息の計上が営業日に追いついていなければ、品質の注意を付けます。「材料が古い」という情報自体が、結果を読むための材料になるのです。
2. v18：信用リスクの期待損失を分解する
信用リスクは、貸したお金を約束どおり回収できない可能性です。模型では、回収の危険にさらされる金額をEAD、返せなくなる確率の仮定をPD、その場合に失う割合をLGDと呼びます。専門用語を覚えるより、「いくらを」「どの確率で」「どの程度失うと置くか」の三つに分けることが先です。
架空の正常な貸出が、元金と未収利息を合わせて100万円あるとします。初期の仮定であるPD 1%、LGD 45%なら、期待損失は100万円×1%×45%＝4,500円です。信用ストレスでPDを2倍、LGDを10パーセントポイント上げると、100万円×2%×55%＝1万1,000円になります。実際に4,500円や1万1,000円の損失が必ず起こるという意味ではありません。
v18は正常、延滞、デフォルト候補、デフォルト確定という区分別に計算します。区分が変われば同じ残高でも結果が変わります。初期のPDやLGDはすべて架空で、統計から推定した値ではありません。パラメータの変更には提案と別の管理責任者の承認があり、実行には最後に承認された版をひも付けます。大きな版番号というだけで採用するわけではありません。
3. v18：四つを円で並べても、同じ種類の数字ではない
金利リスクでは、金利変化によって1年間の資金利益がどう変わるかを見ます。流動性では、預金流出後の資金と必要な余裕資金の差、調達費用を計算します。オペレーショナルリスクは、障害の時間に仮の時間単価と重大度の重みを掛けます。継続中の障害は取得時刻までの時間で仮に数え、解決済みとは扱いません。
たとえば2時間のSEV2障害なら、初期の架空の単価5万円／時と重み2で20万円です。この数字は支払った請求書ではなく、比較のために置く想定損失です。信用の期待損失、資金利益の減少、調達費用、障害の想定損失を円で横に並べると比較しやすくなりますが、単純な合計には相関や分散効果がありません。調達費用と利益減少が経済的に重なることにも、読む側は注意が必要です。
入力不足を0で埋めると、「危険が測れない」が「危険はない」に見えてしまいます。ALMの材料がなければ依存する指標を欠測として返し、預金価格を市場の仮定で代替した場合は警告を残します。融資契約が本当に0件という正常なゼロとは区別します。対策案の承認も決定を記録するだけで、商品金利や上限を自動変更しません。
4. v19：グループでも、財布と責任は分ける
ここから問いが変わります。一つの銀行のリスクではなく、複数の法人を持つグループをどう記録するかです。entityとは、独立して帳簿と責任を持つ事業体の単位です。MiniBankでは、基準のMINIBANK、追加のWEST、TRUSTという架空の三つから始まります。
単純に既存のすべての金融表へentity_idを足す方法も考えられます。しかし、古い集計処理がその列を見なければ、別法人の数字を黙って足してしまいます。v19は既存の基準銀行の元帳を維持し、追加entityにはbankgroup内の独立した元帳を持たせました。基準銀行は既存のPosting Engineを使い、読み取り用の接続口を介してグループへ参加します。
この選択は既存の数字を守りやすい反面、二種類の元帳の読み取り結果を合わせる責任が増えます。接続口の試算表が元の総勘定元帳と一致するかを独立に照合します。また担当者は自分のentityの役割がなければ扱えず、受取りは受け手側の責任者が行います。グループ全体の管理責任者に広い権限があることと、すべての担当者が全法人を扱えることは違います。
5. v19：片側だけ確定した移動を、成功にしない
説明用に、MINIBANKからWESTへ100万円を貸すとします。送り手では現金が減り、WESTに対するグループ内債権が増えます。受け手では現金が増え、MINIBANKに対するグループ内債務が増えます。両者は同じ移動IDで結びつきますが、二つの法人をまたぐ一枚の仕訳にまとめるのではありません。
送信後に受取りが止まると、送り手だけ記帳済みになります。ここを全体成功と表示したり、送り手の記録をなかったことにしたりすると、事実が失われます。残った送信は照合待ちとして扱い、管理責任者が理由付きで受取りを再試行するか、送り手を逆仕訳で取り消します。訂正の経緯を残しながら終わらせる必要があります。
相互勘定の照合では、移動中だから説明できる差と、説明のつかない差を分けます。どちらも差額はありますが、次に必要な行動が違います。単に合計がゼロかを見るより、一件の移動の状態と結びつける方が運用に役立ちます。
6. v19：連結は、内部の貸し借りを報告上で消す
先ほどの100万円について、両方の法人をただ合算すると、グループ内債権100万円とグループ内債務100万円が残ります。グループ全体を一つと見る報告では、この内部の貸し借りは外部に対する資産・負債ではありません。そこで対応する双方を差し引く処理を「消去」と呼びます。
v19は同じ営業日の全entityの確定スナップショットを集め、科目ごとに合算してから、相手ごとに一致する小さい方の金額を消去します。Aの債権100万円に対してBの債務が80万円しかなければ、80万円を消して20万円を残します。差を消して見栄えを整えるのではなく、移動中か説明のつかない差かを明記します。
消去するのは報告の数字です。MINIBANKとWESTの正式な元帳から元の100万円の仕訳を削除しません。法人ごとの責任は残るからです。スナップショットが欠けていれば連結できず、確定後に元帳が動いていれば、そのことも示します。「一枚のきれいな合計」より、「いつの、どの法人の数字か」を守る設計です。
7. 測定と集約が増えても、元の責任は消えない
v18とv19に共通する学びは、数字をまとめる前に境界を固定することです。v18は入力時点とパラメータの版を固定し、v19は法人と営業日を固定します。前提の違う値を一緒にすると、計算自体が正しくても意味が崩れます。再計算できること、何を合算したかを説明できることが、画面の華やかさより重要になります。
限界も異なります。v18は規制上の自己資本比率、LCR・NSFR、実データ由来の確率、担保、相関などを扱いません。v19の追加entityは集計レベルの元帳であり、各法人に顧客口座や融資契約が丸ごと複製されるわけではありません。為替換算、のれん、少数株主持分などの実際の連結会計も対象外です。v18のリスク測定が、追加entityへ自動的に広がるわけでもありません。
復旧については、現行のdigest版3でgroupの役割とentityの状態も検出対象になっています。以前の資料の「役割は対象外」を現在の説明へそのまま移さないことが大切です。ただし外に控えた比較基準自体が古ければ、その後の変更の巻き戻りを見抜けない限界は残ります。数字の集約にも、安全の確認にも、基準の鮮度が必要なのです。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- v18 リスク測定の契約 ↗（非公開GitHub・要権限）
入力凍結、四つのリスクの式、パラメータ承認、欠測、対策案 - v19 グループ・複数法人の契約 ↗（非公開GitHub・要権限）
独立元帳、権限、二段階移動、相互勘定、連結、復旧の最新補強
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。