オペレーショナルリスク

1. オペレーショナルリスクとは何か

オペレーショナルリスクは、特定の商品だけに存在するリスクではない。預金、貸出、為替、証券、決済、デリバティブ、顧客管理、会計、報告等、 銀行の全商品・業務・プロセス・システムに内在する。損失額がまだ発生していなくても、統制の欠陥や重要業務の中断可能性があれば管理対象となる。

1-1. 「損失の集計」だけではない

過去損失は重要であるが、低頻度・高影響の事象、損失に至らなかったニアミス、統制不備、環境変化、新商品・システム変更等は、損失実績だけでは把握できない。 事象管理、自己評価、指標、シナリオ、統制検証、業務継続を組み合わせて、過去・現在・将来を捉える必要がある。

2. 原因・事象・影響と他リスクとの境界

分類の基本は、なぜ起きたかという原因、何が起きたかという事象、何に影響したかという結果を分けることである。 一つのコードへ押し込むと、原因分析、横断集計、再発防止、資本計測のいずれかが不正確になる。

3. 損失事象の分類

バーゼル枠組みは、損失事象を七つの大分類で整理する。これは発生原因の全てを一意に表す分類ではなく、 損失事象を共通の軸で比較・集計するための分類である。内部管理では、原因、業務、商品、法人、拠点、システム、影響等の別軸を併用する。

4. ガバナンスと三つの防衛線

三つの防衛線とは、第一線の業務部門、第二線の独立したリスク管理・コンプライアンス部門、第三線の内部監査等が、 異なる責任でリスク管理を支える考え方である。数字を集める部署を置くだけではなく、リスクを生む業務の責任、独立した牽制、独立保証を明確にする。

5. 管理サイクルとリスク選好

オペレーショナルリスク管理枠組み（ORMF：Operational Risk Management Framework）は、個別の事象対応だけでなく、 平時の特定・評価・監視・統制、重大事象時の対応・復旧、事後の学習を一つの循環として管理する。

1. 対象を特定する：商品、業務、プロセス、システム、法人、拠点、データ、サードパーティ、重要業務を棚卸しする。
2. リスクを評価する：固有リスク、発生可能性、影響、統制の設計・運用、有効性、残余リスクを評価する。
3. 監視する：損失事象、ニアミス、主要リスク指標、限度超過、監査・検査指摘、外部事象を継続監視する。
4. 統制・低減する：回避、削減、移転、受容を選び、予防・検知・対応・復旧統制を整備する。
5. 報告・意思決定する：重要性に応じて業務部門、第二線、経営陣、取締役会等へエスカレーションする。
6. 改善し学習する：根本原因、統制不備、改善期限、効果検証を管理し、分類・シナリオ・教育・計画へ反映する。

5-1. リスク選好・許容度・業務中断の耐性度

6. 損失事象・ニアミス・回収

イベント又はインシデントは「何が起きたか」の記録であり、損失レコードは「いつ、どの会計科目へ、いくら認識したか」の記録である。 一つの事象が複数期・複数科目の損失、引当、回収、顧客補償を生むため、事象と損失を一対一にしない。

6-1. 三つの日付を分ける

6-2. 総損失・回収・純損失

7. 原因分析と改善策管理

直接原因だけを「担当者のミス」として終えると、同じ構造の事象が再発する。根本原因分析では、なぜ誤りを防げず、なぜ検知できず、 なぜ影響を封じ込められず、なぜ復旧が遅れたかを、プロセス・人・技術・データ・組織・外部依存に分けて確認する。

7-1. 改善策は「完了」後に有効性を確認する

1. 暫定対応：被害拡大を止め、顧客・業務・法令・決済への影響を抑える。
2. 恒久対応：根本原因と統制不備を解消する設計・手順・システム・体制を実装する。
3. 独立確認：第一線以外が、実装証跡、テスト結果、残余リスク、例外を確認する。
4. 効果検証：一定期間の指標、再発状況、抜取テスト、訓練等で有効性を確認する。
5. 正式終了：承認者、終了日、未解決事項、受容した残余リスクを記録して閉じる。

8. リスクと統制の自己評価

リスクと統制の自己評価（RCSA：Risk and Control Self-Assessment）は、業務部門が自らの業務に内在するリスクと統制を体系的に評価し、 第二線が基準の一貫性や評価根拠を検証する手法である。損失が起きた後だけでなく、統制が効かなかった場合の潜在影響を前向きに捉える。

8-1. リスク・統制台帳の関係

一つのリスクに複数統制、一つの統制に複数リスクが対応し得るため、多対多で管理する。 統制には所有者、実行者、頻度、自動・手動、予防・検知・対応・復旧、重要統制区分、証跡、テスト方法、最終実施日、例外を持たせる。

9. 主要リスク指標・限度・報告

主要リスク指標（KRI：Key Risk Indicator）は、リスク又は統制環境の変化を早期に捉える指標である。 単なる実績件数ではなく、どのリスク・統制・業務と結び付き、どの閾値で誰が判断し、何を行うかを定義する。

9-1. 閾値は単色ではなく行動へ結び付ける

10. シナリオ分析とストレス

シナリオ分析は、発生頻度が低くても影響が大きい事象を含め、起こり得る事象の原因・波及・影響・対応を専門家が前向きに検討する手法である。 過去損失だけに依存せず、内部・外部事象、自己評価、指標、統制検証、根本原因、業務・システム構造を組み合わせる。

10-1. シナリオを物語だけで終わらせない

10-2. 主観性を統制する

• 対象、期間、前提、発生経路、影響軸、統制の成否を明示する。
• 業務、リスク管理、法務・コンプライアンス、人事、IT、サイバー、財務等の専門家を参加させる。
• 内部損失、外部事象、取引量、顧客数、復旧実績等の観測データで判断を補強する。
• 楽観・基準・厳しいケース、又は影響幅を用い、一点推計だけに固定しない。
• 第二線の検証、独立レビュー、承認、版管理を行う。
• 結果を資本、保険、限度、投資、業務継続、訓練、改善計画へ利用する。

11. 事務・不正・法務・コンダクト

オペレーショナルリスクはシステム障害だけではない。日常の事務、内部・外部不正、顧客対応、法令・契約、商品設計・販売、 労務・安全等を、個別専門領域と連携しながら共通枠組みで把握する。

11-1. 一つの事象を複数の専門部署で分断しない

顧客情報漏えいは、サイバー、個人情報保護、顧客対応、法務、広報、保険、会計損失、当局報告にまたがる。 各専門システムの詳細を一つに統合する必要はないが、共通の事象ID、重要度、時系列、責任者、影響、報告、改善策を関連付ける必要がある。

12. システム・サイバー・変更・データ

情報通信技術（ICT：Information and Communication Technology）リスクは、オペレーショナルリスク管理枠組みと整合させつつ、 可用性、完全性、機密性、変更、容量、老朽化、サイバー、復旧等を専門的に管理する。技術部門だけの問題ではなく、重要業務と顧客影響から優先順位を決める。

12-1. 変更は主要なリスク発生点である

1. 変更を起案する：新商品、新業務、法令対応、システム更新、設定変更、移行、廃止等を共通IDで登録する。
2. 影響を評価する：業務、顧客、データ、会計、決済、セキュリティ、委託先、復旧、規制報告への影響を確認する。
3. 独立した確認を行う：業務、IT、セキュリティ、リスク、法務、財務等が重要性に応じて審査する。
4. テスト・移行する：機能、性能、容量、セキュリティ、回帰、障害、切戻し、データ移行・照合を検証する。
5. 本番後に確認する：稼働、取引・会計・顧客影響、監視、未解決課題を確認し、事後レビューを行う。

金融庁の2025年のITレジリエンス分析は、システム統合・更改、日常運用・保守、サードパーティ、冗長構成、復旧手順、 プログラム更新・特殊作業等に起因する障害を整理している。設計書の判読性、作業手順、有識者レビュー、本番・検証環境の分離、復旧体制等が、技術だけでなく管理上の論点となる。

12-2. サイバーは「防御」だけで完結しない

13. 外部委託・サードパーティ

サードパーティとは、外部委託先だけでなく、調達先、クラウド、共同センター、サービス連携先等を含む広い外部依存先である。 再委託先等の供給網まで含め、重要業務の提供に必要な外部資源、集中、相互依存、代替可能性を把握する。

13-1. 委託しても責任は消えない

委託先で事象が発生しても、顧客、金融システム、当局に対する銀行の責任が自動的に委託先へ移るわけではない。 事象通知、影響評価、顧客対応、業務継続、会計損失、当局報告、改善確認を銀行側で行える情報・権限・体制が必要である。

14. 業務継続とオペレーショナル・レジリエンス

業務継続管理（BCM：Business Continuity Management）は、危機時に必要な業務を継続・復旧するための方針、計画、体制、訓練、改善を管理する。 業務継続計画（BCP：Business Continuity Plan）は、その具体的な計画である。

オペレーショナル・レジリエンスは、事故や障害を完全に防げないことを前提に、重要な業務を最低限維持すべき水準で提供し続ける能力である。 業務継続計画を含むが、顧客目線の重要業務、耐性度、業務を支える社内外資源のマッピング、極端だが起こり得るシナリオによる検証を重視する。

14-1. 重要業務から依存関係を逆引きする

1. 重要業務を特定する：中断が金融システム又は顧客の日常生活へ著しい悪影響を及ぼし得るサービスを顧客目線で選ぶ。
2. 耐性度を定める：復旧時間だけでなく、停止範囲、影響取引数・金額・顧客数、データ完全性等を設定する。
3. 資源をマッピングする：人、プロセス、施設、システム、データ、通信、サードパーティ、再委託先、決済インフラ等を関連付ける。
4. 厳しいシナリオで検証する：複数拠点、サイバー、要員、委託先、通信等の複合障害を含め、耐性度内で提供できるかを試す。
5. 弱点を改善する：単一障害点、集中、復旧順序、代替手段、連絡、データ整合、顧客周知、意思決定を見直す。

15. インシデント対応・復旧・学習

重大事象では、正確な最終原因を待ってから動くのではなく、限られた情報で影響を抑えながら、判断を更新する。 初動、技術・業務対応、顧客・当局等への連絡、会計・損失、復旧、事後分析を共通時系列で管理する。

1. 検知・受付：監視、職員、顧客、委託先、相手方、外部機関等からの情報を受け、事象を起票する。
2. 初期評価：重要業務、顧客、取引、金額、法令、データ、安全、決済、拠点、波及の可能性を評価する。
3. 指揮・エスカレーション：重大度に応じた責任者・会議体を起動し、事実、未確認事項、判断、次回更新を明確にする。
4. 封じ込め・代替：被害拡大を止め、代替手段、手作業、処理制限、迂回、顧客周知等を実施する。
5. 復旧・整合確認：技術復旧後、取引、残高、会計、データ、顧客状態、未処理・重複を照合して業務を再開する。
6. 報告・補償：顧客、当局、法執行機関、決済・市場インフラ、保険者等へ必要な報告・連絡を行う。
7. 事後分析：根本原因、統制不備、対応・復旧の課題、損失・回収、改善策、教訓を確定する。

15-1. 共通時系列に持たせる情報

16. 自己資本比率規制上の計測

オペレーショナルリスク管理と規制資本計測は関係するが、目的は同一ではない。 管理枠組みはリスクの発生頻度・影響を減らし、重要業務を継続するためのものである。 標準的計測手法は、財務指標と一定の内部損失経験を用いて、自己資本比率の分母に反映するリスク量を算出する仕組みである。 事業規模指標（BI：Business Indicator）から事業規模要素（BIC：Business Indicator Component）を求め、 内部損失乗数（ILM：Internal Loss Multiplier）を反映してオペレーショナルリスク所要資本（ORC：Operational Risk Capital Requirements）を算出し、 リスク・アセット（RWA：Risk-Weighted Assets）へ換算する。

16-1. BICの段階係数

国内Q&Aでは、BIが1,000億円までの部分へ12％、1,000億円超3兆円までの部分へ15％、3兆円超の部分へ18％を段階的に適用する例が示されている。 全BIへ一つの率を掛けるのではなく、各帯の増分へ係数を適用する。

16-2. 内部損失データを管理目的と規制目的で分ける

19. 段階導入・再処理・よくある論点

19-1. 段階的な実装順序

1. 範囲と用語を統一する：定義、七事象区分、原因・影響、重大度、事象・損失・ニアミス、境界、機密性を定める。
2. 共通IDと最小データを整える：組織、業務、システム、事象、損失、改善、委託先のIDと主要属性を統一する。
3. 重大事象と会計損失をつなぐ：発生・発見・計上日、総損失・回収、会計伝票、当局報告、改善策を追跡可能にする。
4. 自己評価と統制を整える：業務・リスク・統制の台帳、固有・残余評価、テスト、例外、改善を関連付ける。
5. 指標・シナリオ・レジリエンスへ広げる：主要リスク指標、耐性度、依存関係、訓練、外部事象を同じ基盤へ接続する。
6. 規制計測を分離・接続する：内部管理データから適格損失を判定し、BI・BIC・ILM・ORC・RWAと報告・開示へつなげる。
7. 品質・再現性を高度化する：システム間データ連携、照合、版、再処理、差異ブリッジ、経営報告を自動化する。

19-2. 訂正・再処理を上書きにしない

1. 訂正理由を分類する：新事実、会計訂正、分類・境界、回収、組織・業務、データ連携、ルール、プログラム、手修正等を識別する。
2. 影響範囲を確定する：事象報告、KRI、RCSA、改善、会計、ILM、資本、開示、当局報告、経営報告への影響を特定する。
3. 旧版を固定する：修正前データ、分類・ルール版、計算ラン、報告・承認を保存する。
4. 新規版又は新規ランを作る：修正後結果を再計算し、取引・事象・年度・報告セル別の差を算出する。
5. 承認・再配信する：重要性、再提出、顧客・当局連絡、関連報告差替え、原因・再発防止を決定する。

19-3. よくある論点

Q1. システム障害だけがオペレーショナルリスクか

違う。業務プロセス、人、システム、外部事象を原因とする広いリスクであり、事務誤り、内部・外部不正、法務・顧客対応、災害、委託先等を含む。

Q2. 損失が発生していないニアミスは登録不要か

不要ではない。偶然又は統制で重大影響を回避した事象は、潜在影響、統制の有効性、再発可能性を理解する重要な材料である。 規制損失データと内部管理事象を分けて保存する。

Q3. 一つの事象を一つの分類コードへまとめればよいか

不十分である。主たる損失事象区分に加え、原因、影響、業務、商品、法人、拠点、システム、サードパーティ、法務・サイバー等の関連属性を持つ。

Q4. 原因を「担当者のミス」とすれば再発防止になるか

ならない場合が多い。手順・権限・要員・教育・設計・監視・レビュー・文化・委託等、誤りを防げず、検知・封じ込め・復旧できなかった構造要因を分析する。

Q5. RCSAの点数が低ければ管理は十分か

十分とは限らない。点数の根拠、統制設計・運用、事象・指標・監査との整合、外部環境、評価者の偏り、前回からの変更を確認する。

Q6. BCPとオペレーショナル・レジリエンスは同じか

同一ではない。BCPは特定の危機へ対応する具体的計画である。レジリエンスは原因を問わず中断が起きる前提で、顧客目線の重要業務を耐性度内で提供する能力を、依存関係とシナリオで検証する。

Q7. 外部委託すれば、その事象は銀行のオペレーショナルリスクではないか

そうではない。委託先・再委託先の障害や不正が銀行の顧客、業務、会計、法令へ影響すれば、銀行側の管理対象となる。 契約前評価、継続監視、事象通知、集中、代替、終了を管理する。

Q8. サイバーインシデントはサイバー部門だけで完結するか

完結しない。業務継続、顧客、法務・個人情報、広報、会計、当局・法執行機関、委託先等へまたがる。 専門詳細は権限制御しつつ、共通事象ID・重大度・時系列・影響・改善を共有する。

Q9. 改善策をリリースすれば課題を終了できるか

原則として有効性確認が必要である。設計・実装、独立確認、一定期間の監視又は再テストを経て、残余リスクと未解決事項を承認して終了する。

Q10. 規制資本の損失データと内部事象データは一致すべきか

範囲は一致しない。内部管理ではニアミス、潜在影響、会計外影響、外部事象等も扱い得る。 規制計測では、告示・Q&Aに基づく損失定義、閾値、回収、観測期間、境界、除外を適用する。両者の差を説明できることが重要である。

Q11. 最終的な損失総額とRWAだけを保存すればよいか

不足する。事象、損失・回収明細、会計伝票、分類、境界、BI構成、BIC、ILM、適用ルール、除外、計算中間値、承認、報告セル、計算ランを保存する。

Q12. システム間データ連携で同じ事象が複数到着したら、古いものを削除すればよいか

単純削除してはならない。重複なのか、同一原因による関連事象なのか、同じ事象の別部門報告なのかを判定する。 統合又は親子関係の理由、元ID、変更履歴、承認を残す。

Q13. 前日値や推計値で報告を継続してよいか

目的、重要性、変動性、期限、法令・内部規程に応じた判断が必要である。 代替値を使う場合は対象、算出根拠、保守性、承認、有効期限を明示し、正式データ到着後に新規ランで再計算する。

Q14. 高度なシステムを導入すれば管理は成熟するか

システムだけでは成熟しない。共通定義、責任、リスク文化、報告のしやすさ、独立した牽制、データ品質、改善実行、経営利用が必要である。 まず重大事象・損失・改善・重要業務を確実につなぎ、その後に自動化・分析を広げる。