銀行エンジニアリング 15：ケース調査・判断・二次確認・上申

Level 2 銀行業務：架空の3ケース

Level 3 システム：ケースの状態遷移

1. 01OPEN（未着手）
2. 02INVESTIGATING（調査中）
3. 03判断：FALSE_POSITIVE / CLEARED → CLOSED
4. 04判断：NEEDS_REVIEW → PENDING_REVIEW → 別担当者が判断
5. 05判断：ESCALATED → 管理責任者が完了 → CLOSED

• ケースは1つの口座についてだけ作れる（AL002）。すでにケースに入ったアラートは別のケースに入れられない（AL003）
• 判断には調査メモ（NOTE）か証拠（EVIDENCE）が少なくとも1件必要（AL007）
• NEEDS_REVIEW を付けた本人は最終判断できず、別の担当者が判断する（AL008）
• ESCALATED のケースを完了できるのは管理責任者だけ（AD004）
• 限界：上申した管理責任者本人が、そのケースを完了することもできる（別の人による確認は強制していない）。実際の銀行ではここにも二者確認が必要で、MiniBank はシミュレーターとして簡略にしている
• 限界：判断は担当者に限定されず、権限のある人なら誰でも判断できる（ケースの引き継ぎを簡易にするため）。誤検知（FALSE_POSITIVE）と問題なし（CLEARED）は、どちらも記録の分類が違うだけで処理は同じ
• 判断の選択肢に「不正確定」はない。上申は、より権限のある部署へ判断を引き継ぐことを意味する
• 調査の記録（aml.case_events）は追記のみで、後から書き換えられない

異常時：証拠なしで判断しようとした

Level 4 アーキテクチャ：判断をデータとして残す

AMLの判断は、後から監査や当局の確認を受ける前提で行われます。誰が・いつ・何を根拠に・どう判断したかを追記専用の記録として残し、職務の分離（二次確認・上申）をDBの関数で強制することで、画面の使い方に依存しない統制になります。

どこを確認すればよいか

• ケース詳細：判断・調査の記録・アラートの根拠
• 監査ログ：AML_CASE_CREATED / AML_CASE_DECIDED