決済ドメイン知識
決済リスク
決済システム開発で考慮すべきリスクと過去の重大インシデント
決済リスク
決済システムの障害は、金融システム全体に波及する可能性があります。過去のインシデントから学び、開発に活かしましょう。
1. 決済リスクの分類
| リスク種別 | 内容 | 開発での対策 |
|---|---|---|
| 信用リスク | 取引相手が債務を履行できないリスク | 与信枠チェック、リアルタイム残高確認 |
| 流動性リスク | 資金が一時的に不足するリスク | キューイング、優先順位制御 |
| オペレーショナルリスク | システム障害・人的ミスによるリスク | 冗長化、自動フェイルオーバー、監視 |
| リーガルリスク | 法律・規制の変更によるリスク | 規制変更への柔軟な対応設計 |
| システミックリスク | 一機関の障害が連鎖的に波及するリスク | サーキットブレーカー、隔離設計 |
2. 過去の重大インシデントと教訓
ヘルシュタット銀行事件（1974年）
- ドイツの銀行が破綻し、外為取引で一方の通貨だけ支払われ、反対通貨が受け取れなかった
- 教訓: 時差リスク（タイムゾーンの違いによる決済タイミングのずれ）→ CLS銀行の設立（PVP: Payment versus Payment）
開発への示唆: 国際取引では「同時決済」の原則が重要。片方だけ処理が完了する中間状態を極力排除する設計が必要。
BONYシステム大停電（1985年）
- Bank of New York のシステム障害により、米国債市場の決済が停止
- FRBからの緊急融資で対応
開発への示唆: 単一障害点（SPOF）の排除。決済システムのバックアップ・DR設計の重要性。
ベアリングス事件（1995年）
- 不正取引の隠蔽がシステムの制御不備で発生
- 233年の歴史ある銀行が破綻
開発への示唆: 取引限度額の厳格なチェック、リアルタイムのポジション管理、監査ログの完全性。
SWIFTハッキング事件（2016年）
- バングラデシュ中央銀行からSWIFT経由で不正送金（被害約81百万ドル）
- 内部端末の侵害からSWIFT電文の偽造
開発への示唆: 多層防御、二重承認の仕組み、SWIFT電文の真正性検証、異常取引検知。
みずほ銀行システム障害（2021年）
- 定期預金の大量処理がトリガーとなりATM障害が連鎖
- 年間で複数回の障害が発生
開発への示唆: バッチ処理の負荷設計、キャパシティプランニング、障害の連鎖を防ぐ隔離設計。
3. 不正利用とセキュリティ
主な不正利用パターン
| パターン | 手法 | システム的対策 |
|---|---|---|
| スキミング | 磁気データの不正コピー | EMV（ICチップ）化 |
| フィッシング | 偽サイトでカード情報を窃取 | 3Dセキュア、行動分析 |
| なりすまし | 盗んだカード情報でのEC利用 | 3Dセキュア2.0、デバイス認証 |
| 番号盗用 | 情報漏洩からのカード番号悪用 | トークナイゼーション |
| マネーロンダリング | 不正資金の洗浄 | 取引モニタリング、KYC |
不正検知システム
開発者が意識すべき点: 不正検知は「誤検知（正常な取引を拒否）」と「見逃し（不正を通過させる）」のバランスが重要です。閾値の調整可能な設計にしましょう。
4. 犯罪とコンプライアンス
AML/CFT（マネーロンダリング対策 / テロ資金供与対策）
- KYC（Know Your Customer）: 顧客の本人確認
- 取引モニタリング: 疑わしい取引の検知・報告
- 制裁リストスクリーニング: OFAC等の制裁対象者との取引チェック
開発で実装すべき機能
- 取引金額・頻度の閾値監視
- 疑わしい取引の自動フラグ付け
- 規制当局への報告データ生成（疑わしい取引の届出 = STR）
- 制裁リストとのリアルタイム照合