銀行エンジニアリング 36：ストレスの比較・再現・対策案の決定

Level 1 基礎：ストレスは『もしも』の数字

ストレステストは、予測ではなく『もし、こうなったら』の試算です。基準（ストレスなし）と並べて、何がどれだけ悪化するかを見ます。

Level 2 銀行業務：比べるときの決まり

• 同じスナップショットから作った実行どうしだけを比べる（違うと RK003）
• 同じパラメータの版どうしだけを比べる（違うと RK004）
• PD・LGD などの版は、提案者とは別の管理責任者が承認する（自己承認は RK005）。承認すると、以後の実行が新しい版を使い、過去の実行は使った版のまま残る
• 対策案も同じ二者承認。承認は『決定の記録』で、取引・商品・上限は変わらない

Level 3 システム：MiniBankでの実装

• risk.run は (スナップショット, シナリオ, パラメータの版, モデルの版) が同じなら、前の実行をそのまま返す（冪等）。結果には式、仮定、警告が含まれ、結果のハッシュが保存される
• risk.recompute は、保存された入力とパラメータから結果を計算し直し、ハッシュが一致するかを返す。入力をこっそり書き換えると、一致しなくなる（入力ハッシュも合わなくなる）
• risk 関数は Posting を呼ばず、元帳・商品・契約の表に一切書かない。テストで、実行の前後に元帳の件数・試算表・口座残高が変わらないことと、移行のSQLに投稿する記述がないことを固定している
• 承認待ちのパラメータと対策案は、運用センターの承認キューに出る

異常時：ストレスの数字が急に変わった

Level 4 アーキテクチャ：計算と決定を分ける

リスクの計算は『見る』仕組み、対策の決定は『決める』仕組みです。見る仕組みが商品や取引を書き換えられないようにしておけば、モデルの誤りが顧客に波及しません。決める仕組みは、人の承認の記録として残します。

どこを確認すればよいか

• 管理画面『リスク管理』：比較表、パラメータの版、対策案
• Lab：ストレスを実行し、再計算で再現できること、自己承認が断られることを確かめる