operational-risk

オペレーショナルリスク

基本概念

オペレーショナルリスクの枠組み

オペレーショナルリスクとは、内部プロセス、人員、システムの不備や障害、または外部事象に起因する損失のリスクです。バーゼル委員会が定める7つの事象タイプは、トレーディング業務では次のように分類されます。

バーゼルの事象タイプ	トレーディング業務の例
1. 内部不正	無許可取引、意図的なポジションの誤記、架空取引の計上、フロントランニング
2. 外部不正	アカウント乗っ取り、取引認証情報を狙ったフィッシング、決済指図における電信送金詐欺、取引相手による操作
3. 雇用慣行および職場の安全	オペレーション研修の不足、重要な業務の特定の担当者への依存、ミスを誘発する業務負荷
4. 顧客、商品および事業慣行	適合性の確認漏れ、不適切な執行、最良執行義務違反、顧客指図への不履行
5. 物的資産への損害	自然災害や社会的混乱によるデータセンターまたはトレーディングフロアの損害
6. 事業の中断およびシステム障害	OMSの停止、市場データフィードの障害、接続の喪失、取引所ゲートウェイや清算システムの停止
7. 執行、受渡しおよびプロセス管理	取引ミス、決済不履行、照合差異、コーポレートアクション処理の失敗、不正確な証拠金計算（通常、最も損失額が大きいカテゴリー）

リスクの特定では、プロセスマッピング、リスク・コントロール自己評価（RCSA）、損失事象分析、シナリオ分析、監査所見を通じて、すべてのオペレーショナルリスクエクスポージャーを洗い出します。リスク評価では、通常、5×5のヒートマップを用いて、各リスクの発生可能性と影響度を評価します。リスクモニタリングでは、KRI、損失事象、コントロールの有効性を追跡します。リスク軽減では、コントロール（予防的および発見的）、プロセスの再設計、テクノロジーソリューション、保険、事業継続計画を活用します。

取引エラー

取引エラーとは、人為的ミス、システム障害、または連絡の行き違いにより、取引が誤って実行されることです。一般的な取引エラーには、次の種類があります。

• 証券の取り違え。 誤った CUSIP、ISIN、またはティッカーが入力され、意図しない証券の購入または売却につながります。似たティッカーシンボル（例：「APLE」ではなく「AAPL」と入力する）の入力や、ドロップダウンから誤った項目を選択することが原因となる場合がよくあります。
• 数量の誤り。 株式、債券、または契約の数量が正しくありません。よくあるサブカテゴリとして、余分な桁を入力してしまう「ファットフィンガー」エラーがあります（例：1,000 株ではなく 10,000 株）。
• 売買方向の誤り。 買い注文が売り注文として入力される、またはその逆の誤りで、意図と反対のポジションになります。ネットエクスポージャーの誤差は、意図した取引規模の 2 倍になります。
• 口座の誤り。 取引が誤ったクライアント口座で実行される、またはクライアント口座ではなく会社の自己勘定口座で実行されます。これにより、適合性、配分、および潜在的な利益相反に関する問題が生じます。
• 注文の重複。 システムのタイムアウト後の再送信、ダブルクリック、または重複排除ロジックの不具合により、同じ注文が複数回送信されます。その結果、会社は意図したポジションの 2 倍を保有することになります。
• 価格タイプまたは指値の誤り。 指値注文ではなく成行注文が出される、または指値価格が誤って設定され、意図しない価格で約定します。
• 古い注文または取消済み注文の執行。 取消処理が間に合わなかった、または送信中に失われたため、取り消されるはずの注文が執行されます。

エラーの検出方法。 エラーは、リアルタイムのポジション監視（予期しないポジションの変化によりアラートが発生します）、取引前の検証ルール（数量制限、証券の制限、口座の適格性チェック）、取引後の照合（予想ポジションと実際のポジションの比較）、クライアントからの苦情、清算会社または取引相手からの拒否通知、および損益の帰属分析（説明のつかない損益はエラーの兆候であることがよくあります）によって検出されます。

エラーの修正手順。 エラーが検出されたら、速やかに修正する必要があります。

• 取消しと再計上。 誤った取引を取り消し、正しい取引を計上します。決済前にエラーが見つかった場合は、同じ取引日に取消しと再計上を行うことがあります。決済後に見つかった場合は、ポジションを遡及的に調整するために、過去日付取引を使用します。
• エラー口座。 ほとんどのブローカー・ディーラーは、解決まで誤った取引を移管するためのエラー口座（差額口座とも呼ばれます）を 1 つ以上設けています。エラー口座により、誤ったポジションがクライアント口座から分離され、発生した損益が記録されます。エラー口座の活動は監督上のレビューの対象となり、文書化する必要があります。
• エラー損益の配分。 取引エラーによる損失は会社が負担し、クライアントに転嫁してはなりません。取引エラーによる利益の扱いはより複雑で、規制当局のガイダンスと会社の方針に基づき、その利益をクライアント口座に戻すか、エラー口座に残すかが決まります。FINRA は、会社がクライアントの犠牲のもとで取引エラーから恒常的に利益を得るべきではないと述べています。
• 根本原因分析。 取引エラーが発生するたびに、プロセスの不備、技術的な問題、研修不足、または個人のミスが原因かどうかを特定するため、根本原因分析を行う必要があります。根本原因の分析結果は、オペレーショナルリスクのフレームワークにおけるリスクの特定と軽減のサイクルに活用されます。

取引差異と照合

同じ取引に関する2つの記録が一致しない場合、取引差異が発生します。取引ライフサイクルの複数の段階で差異が生じます。

• フロントオフィスとバックオフィス間の差異。 注文管理システム（OMS）の記録が約定管理システム（EMS）の約定内容と一致しない場合や、フロントオフィスシステムの取引記録がミドルオフィスの計上内容と一致しない場合です。部分約定が適切に集約されていないこと、手作業による計上ミス、システム連携の障害などが原因です。
• 自社と取引相手間の差異。 自社の取引記録が取引相手の記録と一致しない場合です。取引照合やコンファメーションのプロセス（例：DTCC CTM、Omgeo、SWIFT matching）で検出されます。数量の不一致、価格の差異（特に価格を交渉するOTC取引）、決済日の不一致、決済指図の詳細の誤り（SSIの不一致）がよくある原因です。
• 自社とカストディアン間の差異。 自社のポジション記録がカストディアンの記録と一致しない場合です。日次または日中のポジション照合で検出されます。未計上の取引、コーポレートアクションの処理の違い、一方のシステムに反映されていない決済不履行、取引日基準と決済日基準の会計処理のタイミングの違いなどが原因です。
• 現金差異。 自社の現金元帳が銀行またはカストディアンの現金明細と一致しない場合です。未計上の現金移動、記録されていない手数料の控除、利息計上の違い、外国為替換算の不一致などが原因です。

照合プロセス。 金融機関は主に次の3種類の照合を行います。

1. ポジション照合。 自社の有価証券ポジションを、カストディアン、清算機関、または保管振替機関の記録と比較します。活発に取引される口座については、毎日実施します。
2. 取引照合。 自社の記録と外部記録（取引相手からのコンファメーション、清算明細、カストディアンの明細）の間で、個々の取引を照合します。すべての取引が両方のシステムに記録されていることを確認します。
3. 現金照合。 自社の現金残高と現金移動を銀行およびカストディアンの明細と比較します。未記録の借方、貸方、手数料を特定します。

差異の解消ワークフロー。 一般的な差異解消プロセスには、次の手順が含まれます。（1）許容範囲内の差異（例：0.01ドル未満の価格差、丸め処理による数量差）を自動照合して解消する。（2）未解決の差異をオペレーション担当アナリストに割り当てる。（3）根本原因を特定するために調査する。（4）該当するシステムで誤った記録を訂正する。（5）差異が解消されたことを取引相手またはカストディアンに確認する。（6）解消内容と根本原因を文書化する。

経過期間とエスカレーション。 未解決の差異は経過期間別に追跡します。業界標準および規制上の要請により、経過期間のしきい値に基づくエスカレーションが求められます。

経過期間	状態	対応
T+0～T+1	通常	通常の手順で調査して解消する
T+2～T+3	要注意	上級オペレーション担当者にエスカレーションし、優先度を上げる
T+4～T+5	警告	オペレーション管理者にエスカレーションし、取引相手に直接連絡する
T+5+	重大	オペレーション責任者とコンプライアンス部門にエスカレーションし、財務上のエクスポージャーを評価する

許容しきい値。 金融機関は、差異を自動解消するための許容水準を設定します。一般的なしきい値は、取引所で取引される有価証券の価格許容差が1単位あたり+/- 0.01ドル、丸め処理による数量許容差が+/- 1単位、軽微な丸め処理に対する現金許容差が+/- 1.00ドルです。許容水準は定期的に見直し、実際の誤りが見過ごされるほど広く設定しないようにする必要があります。

損失事象の管理

損失事象とは、オペレーショナルリスクのインシデントによって実際に生じた損失です。効果的な損失事象管理には、以下が必要です。

損失事象の特定。 発生源には、取引エラーによる損益、決済不履行の手数料（バイインコスト、当座貸越利息）、規制当局による罰金や制裁金、訴訟の和解金、システム停止によるコスト（取引機会の逸失、手作業による処理コスト）、サービス障害に対する顧客への補償金などがあります。

損失事象の分類。 各損失事象は、以下の基準で分類されます。

• バーゼルの事象タイプ（上記の7つのカテゴリーのいずれか）
• 業務部門（トレーディングデスク、オペレーション、テクノロジー、コンプライアンス）
• 原因カテゴリー（人、プロセス、システム、外部要因）
• 重大度（軽微、中程度、重大、大規模、深刻 — 企業が設定した金額基準に基づく）

損失事象の記録。 各事象の記録には、発生日、発見日、解決日、事象の説明、根本原因、バーゼルカテゴリー、業務部門、総損失額、回収額（保険、取引相手からの払い戻し）、純損失額、実施した是正措置、担当マネージャーを含める必要があります。

ニアミスの追跡。 損失につながる可能性があったものの、迅速な検出や有利な市場変動によって損失に至らなかった事象は、ニアミスとして追跡します。ニアミスは統制の弱点を示す先行指標であり、実際の損失とあわせて分析します。例：誤った数量を入力したものの、執行前に事前取引数量制限によって検出された場合は、ニアミスに該当します。

損失事象データベース。 企業は、組織全体の損失事象を集約する内部損失事象データベース（多くの場合、GRC — ガバナンス、リスク、コンプライアンス — プラットフォームの一部）を維持します。このデータベースにより、傾向分析、根本原因のパターン特定、上級管理職や取締役会への報告が可能になります。

しきい値に基づく報告。 企業は報告基準を設定します。

しきい値	対応
> $10,000	24時間以内に部門長へ報告
> $50,000	24時間以内に最高リスク責任者へ報告
> $100,000	上級管理職およびリスク委員会へ報告
> $500,000	取締役会へ通知し、規制当局への報告義務を評価

これらのしきい値は例示です。各企業は、規模、複雑さ、リスク許容度に応じて調整します。

規制当局への通知。 特定の損失事象は、規制当局への報告義務を発生させます。FINRA Rule 4530は、重大なオペレーショナルインシデントを含む、指定された事象について会員企業に報告を義務付けています。SEC Rule 17a-11は、特定の財務状況および業務状況について、ブローカー・ディーラーにSECへの通知を義務付けています。企業は、損失事象の種類およびしきい値と、適用される規制当局への通知要件を対応付けた一覧を維持する必要があります。

主要リスク指標（KRI）

KRIは、オペレーショナルリスクへのエクスポージャーの増大を早期に警告する指標です。KRIは、パフォーマンスの測定ではなくリスクの兆候を示すことを目的として特別に設計されている点で、主要業績評価指標（KPI）とは異なります。ただし、両方の目的に使われる指標もあります。

先行指標と遅行指標。 先行指標は将来のリスク事象を予測します（例：システムのレイテンシの増大は、障害を予測する可能性があります）。遅行指標はすでに発生した事象を測定します（例：先月の取引エラー件数）。効果的なKRIプログラムには、両方の種類が含まれます。

取引業務で一般的なKRI：

KRI	定義	先行／遅行
NIGO率	Not-In-Good-Order率：情報が不足または不正確な取引指図の受領率	先行
取引ブレーク率	不一致取引の件数が総取引件数に占める割合	遅行
決済失敗率	決済失敗件数が総決済件数に占める割合	遅行
取引エラー率	約定した取引1,000件あたりの取引エラー件数	遅行
エラー口座残高	エラー口座にあるポジションの総額	遅行
STP率	Straight-Through Processing率：手動介入なしで処理された取引の割合	先行
システム可用性	重要な取引システムおよび業務システムの稼働率	先行
マージンコール件数・金額	発行または受領したマージンコールの件数と金額	先行
長期未解決ブレーク件数	エスカレーション基準を超えて未解決の取引ブレーク件数	先行
取消・訂正率	取引取消件数および訂正件数が総取引件数に占める割合	遅行
照合完了率	目標期限までに完了した日次照合の割合	先行
未解決インシデント件数	未解決のオペレーショナルインシデント件数	先行

KRIのしきい値。 各KRIには、信号機モデルを用いてしきい値レベルを設定します。

• 緑。 通常の運用範囲内です。定期的なモニタリング以外の対応は不要です。
• 黄。 リスク許容度に近づいています。モニタリングの強化と調査が必要となり、経営陣の注意を要する場合があります。根本原因分析を開始します。
• 赤。 リスク許容度を超えています。経営陣による即時の対応、上級管理職またはリスク委員会へのエスカレーション、および目標日を記載した是正計画の文書化が必要です。

取引ブレーク率のしきい値設定例：

レベル	しきい値	対応
緑	1日あたりの取引量の < 2%	定期的なモニタリング
黄	1日あたりの取引量の 2% - 5%	根本原因を調査し、照合頻度を増やす
赤	1日あたりの取引量の > 5%	オペレーション責任者にエスカレーションし、必要に応じて新規業務を停止する

KRIの推移と報告。 KRIは、傾向を把握するために継続的に追跡します。緑の範囲内にとどまっていても、黄に向けて上昇傾向にあるKRIは、ある時点での数値よりも多くの情報をもたらします。経営陣向けの月次KRIレポートには、現在値、しきい値の状況、傾向の方向、および黄または赤の指標に関する説明を含めます。

インシデント管理

取引業務におけるオペレーショナルインシデントは、小規模なシステム障害から、市場への参加に影響を及ぼす大規模な停止まで多岐にわたります。体系化されたインシデント管理プロセスにより、一貫性のある対応と解決が実現します。

インシデントの分類（重大度レベル）：

重大度	定義	例	対応時間
SEV-1（重大）	取引機能が完全に失われた、または重大な財務エクスポージャーが発生している状態	注文管理システムの停止、いずれの取引所にも注文をルーティングできない、決済を妨げる清算システムの障害	即時。全員で対応
SEV-2（大）	取引機能が大幅に低下している、または重大な財務リスクがある状態	主要取引所のマーケットデータフィードの障害、特定の注文タイプを処理できない、一部の接続が失われている	15 分以内
SEV-3（中）	取引業務への影響が限定的で、回避策がある状態	システムパフォーマンスの低下、重要度の低いレポート機能の障害、単一の取引相手との接続問題	1 時間以内
SEV-4（軽微）	業務への影響が最小限で、財務エクスポージャーがない状態	UI の見た目に関する問題、緊急性のないレポートの遅延、取引に影響しない軽微なデータ品質の問題	4 時間以内

インシデント対応手順。 標準的なインシデント対応ライフサイクルは次のとおりです。

1. 検知と報告。 インシデントは、監視アラート、ユーザーからの報告、取引相手からの通知、自動ヘルスチェックを通じて検知されます。
2. トリアージと分類。 インシデントの重大度、範囲、潜在的な財務影響を評価し、重大度レベルを割り当てます。
3. コミュニケーション。 コミュニケーションプロトコルに従って、関係者に通知します。SEV-1 と SEV-2 の場合、取引デスク責任者、オペレーション管理部門、テクノロジー部門のリーダー、コンプライアンス部門、経営幹部への通知が含まれます。指定されたインシデントコマンダーが対応を調整します。
4. 封じ込め。 インシデントの拡大を防ぐため、直ちに措置を講じます。自動取引の停止、手動での注文入力への切り替え、バックアップシステムの起動、取引所や取引相手への通知などが含まれる場合があります。
5. 解決。 技術チームが通常業務の復旧に取り組みます。システム停止の場合は、バックアップシステムへのフェイルオーバー、サービスの再起動、緊急パッチの適用を行います。
6. 復旧。 根本原因に対処した後、通常業務を再開します。未処理の注文、取引、ポジションを照合します。停止中に成立しなかった取引について、クライアントへの影響を評価します。
7. インシデント後のレビュー。 根本原因、タイムライン、影響、対応の有効性、是正措置を記録するため、正式なレビューを実施します。

エスカレーションマトリクス。 エスカレーション経路は重大度レベルごとに定義されています。

• SEV-1：インシデントコマンダー、CTO/COO、取引責任者、最高リスク管理責任者、市場全体に影響する場合は CEO
• SEV-2：インシデントコマンダー、テクノロジー担当 VP、取引オペレーション責任者、最高リスク管理責任者
• SEV-3：テクノロジーチームリーダー、オペレーションマネージャー
• SEV-4：担当者、スーパーバイザー

根本原因分析の手法。 広く利用されている手法は 2 つあります。

• 5 Whys。 根本原因が特定されるまで、「なぜ」を繰り返し問いかけます。例：なぜ取引エラーが発生したのか？間違った口座が選択されたため。なぜか？口座のドロップダウンに似た名前が表示されていたため。なぜか？UI に口座名とともに口座番号が表示されないため。なぜか？新しいクライアントを買収した後も、口座の表示形式が更新されなかったため。根本原因：不十分な UI 設計に、買収後のシステム統合の不備が重なったこと。
• フィッシュボーン（石川）図。 潜在的な原因を「人」「プロセス」「テクノロジー」「データ」「環境」「外部」の 6 つの分岐に分類します。各分岐を調べ、要因となった事柄を特定します。

是正措置の追跡。 根本原因分析ごとに是正措置を作成します。各措置には担当者、完了目標日、ステータス（未着手、進行中、完了、検証済み）を割り当てます。是正措置登録簿を維持し、定期的なオペレーショナルリスク会議で確認します。是正措置は、有効性が独立して検証されるまで完了とは見なされません。

事業継続と災害復旧

取引業務では、業務を妨げる事象が発生した場合でも重要な機能を継続できる体制を維持する必要があります。規制要件（FINRA Rule 4370 を含む）により、ブローカー・ディーラーには事業継続計画の策定が義務付けられています。

FINRA Rule 4370（事業継続計画および緊急連絡先情報）。 FINRA の各会員は、少なくとも次の項目に対応する事業継続計画（BCP）を書面で策定し、維持する必要があります。データのバックアップと復旧、すべてのミッションクリティカルなシステム、財務および業務の評価、顧客および規制当局との代替連絡手段、代替の物理的拠点、重要な事業関係者への影響、規制報告、規制当局との連絡です。会社の業務、組織構造、事業または所在地に重大な変更があった場合は、計画を更新する必要があります。

目標復旧時間（RTO）。 システムの停止による業務への影響が許容できなくなるまでの、許容可能な最大時間です。取引業務では、RTO は通常、分から時間単位で設定されます。

システム	一般的な RTO
注文管理システム	< 30 分
市場データフィード	< 15 分
取引所接続	< 15 分
リスク管理システム	< 1 時間
決済／清算インターフェース	< 2 時間
顧客向けレポートシステム	< 4 時間

目標復旧時点（RPO）。 時間で測定する、許容可能な最大データ損失量です。RPO が 5 分の場合、会社が許容できる取引データの損失は最大 5 分間です。取引システムでは、注文データや約定データの RPO は通常ほぼゼロ（同期レプリケーション）で、重要度の低いデータでは数分です。

フェイルオーバー手順。 重要なシステムには、セカンダリ環境への自動または半自動のフェイルオーバーを備える必要があります。これには、スタンバイ側を自動で昇格させるアクティブ／パッシブのデータベースレプリケーション、取引所および清算会社への冗長ネットワーク経路、地理的に分離されたデータセンター、事前設定済みの災害復旧用取引環境が含まれます。

リモート取引機能。 会社は、トレーダーおよび業務担当者が代替拠点から業務を行えるようにする必要があります。これには、取引システムへの VPN アクセス、事前配備済みのリモート取引用ワークステーション、リモート拠点からの音声通信（取引タレット、録音電話回線）のテスト、リモート取引の開始手順の文書化が含まれます。

コミュニケーション計画。 業務の中断時には、会社は次の相手に連絡する必要があります。顧客（注文状況、口座へのアクセス、代替連絡手段について）、規制当局（FINRA、SEC、取引所）、取引相手および清算会社、従業員、重要なベンダーです。連絡網と連絡用テンプレートを事前に整備し、テストしておく必要があります。

テスト要件。 FINRA Rule 4370 では、BCP を少なくとも年 1 回、見直してテストすることが義務付けられています。業界のベストプラクティスには、机上演習（シナリオの確認）、バックアップシステムとフェイルオーバーの機能テスト、大規模なシミュレーション演習、取引所および清算会社との第三者テストが含まれます。テスト結果を文書化し、不備には是正措置を講じる必要があります。

テクノロジーリスク

テクノロジーリスクはオペレーショナルリスクの一部であり、注文のルーティング、執行、リスク管理、決済処理を自動化システムに依存しているため、取引業務では特に深刻です。

システムの信頼性。 取引システムには高い可用性基準が求められます。ミッションクリティカルなシステムでは、一般的な目標稼働率は99.95%（年間の許容ダウンタイムは約4.4時間）です。冗長化されたアーキテクチャ、自動監視、キャパシティプランニング、定期的なパフォーマンステストによって信頼性を確保します。

変更管理。 取引システムのソフトウェアや設定の変更は、オペレーショナルインシデントの主な原因の一つです。規律ある変更管理プロセスには、変更依頼の文書化、影響評価、本番以外の環境でのテスト、計画的なデプロイ時間帯（高リスクの変更では市場取引時間を避ける）、ロールバック手順、デプロイ後の検証が含まれます。市場取引時間中の緊急変更には、リスクへの意識を高めたうえでの迅速な承認が必要です。

ベンダーリスク管理。 取引業務は、市場データ、注文ルーティング、清算、決済、テクノロジーインフラを提供する多数のサードパーティベンダーに依存しています。ベンダーリスク管理には、導入前のデューデリジェンス、測定可能なパフォーマンス基準を定めたサービスレベル契約（SLA）、ベンダーのパフォーマンスと財務健全性の継続的な監視、ベンダー障害時の緊急対応計画、集中リスク評価（重要な機能を単一のベンダーに過度に依存しないこと）が含まれます。

取引システムにおけるサイバーセキュリティ。 取引システムは、サイバー攻撃の標的として価値が高いものです。主なサイバーセキュリティ対策には、取引システムを分離するネットワークセグメンテーション、システムへのアクセスに対する多要素認証、転送中および保存中のデータの暗号化、侵入検知・防止システム、定期的なペネトレーションテスト、サイバー事象に特化したインシデント対応計画が含まれます。

市場データシステムの障害。 市場データ（価格、気配値、参照データ）が失われると、正確な注文価格の設定、リスク計算、コンプライアンスチェックができなくなる可能性があります。企業は、複数のベンダーからの冗長な市場データフィード、代替価格設定の仕組み（最後に確認された価格、管理策を伴う手動での価格入力）、データの古さや欠落を知らせるアラートを整備する必要があります。注文のルーティングや執行品質に影響する市場データ障害は、オペレーショナルインシデントとして分類し、管理する必要があります。

注文ルーティングシステムの障害。 取引所やマーケットセンターに注文をルーティングできないことは、取引業務におけるSEV-1インシデントです。対策には、各執行会場への冗長なFIX接続、代替の注文ルーティング経路、最終手段としての取引所端末での手動注文入力機能、執行遅延をクライアントに通知するための事前に定めた手順が含まれます。

実例

エンドツーエンドのシナリオを確認できる実例がreferences/examples.mdに3つあります。（1）ブローカー・ディーラーのトレーディングデスク向けオペレーショナルリスクフレームワークの構築、（2）標準化された取引エラーの処理・訂正プロセスの設計、（3）取引業務管理のためのKRIダッシュボードの実装です。

よくある落とし穴

• オペレーショナルリスク管理を、事業管理の規律ではなくコンプライアンス上の手続きとして扱うこと。書類は完成していても、リスクが積極的に管理・軽減されていません。
• 実際の損失とともにニアミスを追跡しないこと。その結果、統制の劣化を示す早期警告シグナルを見逃します。
• データではなく理想に基づいてKRIのしきい値を設定すること。常に赤信号となるしきい値は信頼性を失い、経営陣に無視されます。
• ドキュメントを残さずに取引エラーの修正を許可すること。これにより、見えないリスクエクスポージャーが生じ、根本原因分析が妨げられます。
• 照合作業への投資が不十分であること。長期間未解消の差異は、オペレーショナル上の障害や潜在的な金銭的損失を示す先行指標ですが、新規取引処理に比べて差異の解消が後回しにされることがよくあります。
• 日中のポジション監視を行えば数時間早くエラーを検出して損益への影響を抑えられるにもかかわらず、日次の照合だけに頼ること。
• 現実的なシナリオを用いず、チェック項目を埋めるだけの事業継続計画テストを実施すること。その結果、実際の復旧上の課題を特定できません。
• テクノロジー変更管理をオペレーショナルリスクの発生源として見落とすこと。重大インシデントのかなりの割合は、ソフトウェアのデプロイや設定変更に起因します。
• 明確なエスカレーションマトリクスを整備しないこと。その結果、担当者によって対応が異なる場当たり的なインシデント対応につながります。
• バーゼル分類を使用せず、すべてのオペレーショナルリスク事象を単一のカテゴリに分類すること。これにより、有意義な傾向分析やベンチマーキングができなくなります。
• ベンダー集中リスクを見落とすこと。市場データ、注文ルーティング、または清算に影響する単一ベンダーの障害は、全社的なオペレーショナルリスク事象になり得ます。
• 是正措置のフォローアップを完了しないこと。根本原因分析から改善案が出されても、追跡と検証がなければ、同じ障害が繰り返されます。

相互参照

• order-lifecycle（trading-operations プラグイン）：注文の入力から約定までの注文ライフサイクルでは、多くのオペレーショナルリスク事象が発生します。各段階にエラーの検出と防止が組み込まれています。
• settlement-clearing（trading-operations プラグイン）：決済不履行や清算上の差異は、オペレーショナルリスクの主要カテゴリです。決済不履行の管理プロセスは、オペレーショナルリスクの枠組みと密接に関連しています。
• counterparty-risk（trading-operations プラグイン）：取引相手の不履行（証券の引き渡しや現金の支払いの不履行）は、信用リスク管理にも関わる外部オペレーショナルリスクです。
• trade-execution（trading-operations プラグイン）：執行品質の問題、ルーティングエラー、最良執行義務違反は、規制上の影響を伴うオペレーショナルリスク事象です。
• pre-trade-compliance（trading-operations プラグイン）：取引前チェックは、取引エラー、無許可取引、口座制限違反を防ぐ予防的統制として機能します。
• post-trade-compliance（trading-operations プラグイン）：取引後の監視では、取引前の統制をすり抜けたエラーや異常を検出します。
• books-and-records（compliance プラグイン）：損失事象のドキュメント、インシデント記録、エラー口座の活動記録は、保存要件の対象となる規制上の帳簿・記録です。
• examination-readiness（compliance プラグイン）：オペレーショナルリスクの枠組み、インシデントログ、BCPのドキュメントは、FINRAおよびSECの検査官がよく確認する項目です。
• privacy-data-security（compliance プラグイン）：取引システムに影響するサイバーセキュリティインシデントは、データ保護義務や侵害通知義務も発生させるオペレーショナルリスク事象です。