Risk Operations KRI Dashboard
偵測系統可以產生警示，但真正的風險營運還要回答：今天該先看哪一案？誰快超過 SLA？哪條規則誤報最多？所有決定有沒有留下紀錄？
先用一句話理解這個專案
它是一個可重建的風險營運工作簿：把分散的 alerts、transactions、accounts 與 reviewer actions 組成有優先級、有 SLA、有 KRI、有稽核軌跡的人工審查流程。
Key Risk Indicator，關鍵風險指標。它不是只顯示「有幾筆警示」，而是監控高風險比例、誤報率、案件積壓、SLA breach 與處理時間是否正在惡化。
專案目的：把「很多警示」變成「可以被管理的工作」
異常偵測專案回答的是哪些事件值得看；這個 Dashboard 回答的是團隊要怎麼看、先看什麼、看完留下什麼，以及整個審查流程是否健康。
在實際營運裡，風險團隊每天面對的不是一張漂亮的圖，而是一個不斷變動的 queue。Critical 案件可能只有四小時 SLA；High 案件要在八小時內處理；同時新警示仍在進來。如果只按照建立時間排序，嚴重度、風險分數與截止時間就可能互相衝突。
所以這個專案把工作簿設計成一個可檢查的小型營運系統：Executive KRI 看整體狀態，Case Queue 決定優先順序，Account Profile 與 Transaction Detail 補充證據，Rule Definitions 提醒規則邏輯和常見誤報，Reviewer Audit Log 則保存每次決定。
要解決的問題：偵測之後，流程才真正開始
優先級不清楚
嚴重度、risk score、建立時間與 SLA deadline 同時存在，分析師需要一致的排序規則。
證據散落
帳戶背景、交易、登入、錢包、alert 與相關案件若散在不同 CSV，審查容易漏掉重要脈絡。
團隊狀態看不見
沒有 backlog、breach、false positive 與 handling time，就不知道規則和人力是否失衡。
另一個常被忽略的問題是「決定的歷史」。如果 reviewer 直接覆寫儲存格，今天看到的 Closed 可能無法回答昨天是誰把它從 Pending Review 改成 Escalated、理由是什麼。這也是為什麼專案加入 append-only audit log，而不是只保留最後狀態。
解法：用資料層、公式層與人工流程組成可追蹤系統
一致的資料契約
accounts、wallets、transactions、login events、alerts、cases、rules 與 audit log 都有穩定主鍵和 UTC 時間。
隱藏且可稽核的計算層
原始 Data_* sheets 與 Calc_Daily 保留資料來源，前台使用 bounded references 與命名範圍，不靠人工貼數字。
案件審查介面
Case Queue 以 severity、risk score 與 SLA 排序；Account Profile 和 Transaction Detail 提供 drill-down。
營運與治理指標
15 個 KRI、8 張原生圖表、Rule Definitions、False Positive 分析與 append-only reviewer log 一起呈現。
這樣設計的重點，是讓畫面上的每個數字都能沿著公式回到資料列。例如 SLA breach rate 可以追到哪些 case 超時；false positive rate 可以追到哪些 reviewer disposition；高風險 alert rate 也會和 alerts table 的 severity 對得起來。
分析師實際怎麼使用這份工作簿
工作流程不是從 Executive Dashboard 看完圖就結束，而是從隊列走到個案證據，再把決定寫回可稽核紀錄。
- 先看 Case Queue：篩選 Open / Escalated，從 Critical、High 以及最接近 SLA deadline 的案件開始。
- 打開 Account Profile：選擇 account_id，比較典型交易量、最近行為、登入國家、錢包與既有案件。
- 進入 Transaction Detail：用 account、wallet、transaction ID、asset、chain、date 與 risk band 篩選事件證據。
- 閱讀 Rule Definitions：確認觸發門檻、風險意義、已知 false-positive scenario 與建議 reviewer action。
- 寫下決定：選擇 status / disposition，加入具體而非空泛的 evidence-based notes。
- 追加 audit row：保存誰在什麼時間把什麼欄位從哪個值改成哪個值；不刪除舊紀錄。
工作簿不會自動封鎖帳戶。它的角色是整理證據、時間與工作量，讓 reviewer 做出更一致、可回溯的決定。
KRI 怎麼解讀：不能只看紅燈
KRI 的價值不是把儲存格變紅，而是把風險與營運負荷放在同一個決策框架。例如 High-Risk Alert Rate 上升，可能表示風險型態變化，也可能是規則版本改動；False Positive Rate 上升，可能是門檻太敏感，也可能是 reviewer 定義改變。
| KRI | 公式概念 | 它回答什麼 | 不能忽略的脈絡 |
|---|---|---|---|
| High-Risk Alert Rate | High + Critical / all alerts | 高優先訊號占比是否增加 | 規則版本、分母與資料量 |
| False Positive Rate | FP decisions / decided cases | 審查資源是否花在非風險個案 | 只看已決案件，需確認 disposition 一致 |
| SLA Breach Rate | breached cases / all cases | 團隊是否及時處理 queue | 案件嚴重度、班表與 backlog |
| Open Cases | Open + Escalated | 目前有效工作量 | 狀態紀律與 shift handoff |
每個 KRI 都附 business purpose、來源、更新頻率、warning / critical 門檻、限制與可能的 false-positive explanation。門檻不應因單一案件就調整；要一起衡量 confirmed-risk coverage、reviewer workload 與 SLA。
如何重建工作簿，而不是拿一個不可重現的成品
專案提供 deterministic generator 與 builder。這代表使用相同 seed，可以重新生成相同的 30 天資料、Excel 公式、圖表與驗證結果；如果替換成相容 CSV，也能重新建置而不需要逐格貼上。一般性的環境安裝保留在 README，這裡只留下會真正產生成品或驗證結果的指令。
python generate_sample_data.py
python build_dashboard.py
python validate_workbook.py
python -m unittest discover -s tests -v完成後打開 workbook/risk_operations_dashboard.xlsx。藍色儲存格是 analyst input，公式欄位受到無密碼保護，避免操作時誤改。要放到 Google Sheets，可以上傳 XLSX，或逐一匯入 UTF-8 CSV；Google Apps Script 版本可在 queue 編輯時追加 audit row 並更新 dashboard timestamp。
{"status": "PASS"}。檢查涵蓋 required sheets / headers、公式、唯一 case ID、severity-based SLA、risk score 範圍、必要欄位、圖表與 audit consistency；3 個測試均通過。
工作簿的實際操作畫面
以下九張都是專案程式實際產生並由工作簿渲染出的頁面，不是為文章另外手動畫出的圖表。它們依序呈現使用者會看到的 KRI、案件、證據、規則與稽核介面。
限制與治理：Dashboard 不會替資料品質背書
即使公式完全正確，來源資料若延遲、缺欄、重複或 reviewer 狀態填寫不一致，KRI 仍可能誤導。區塊鏈欄位也是合成證據提示：counterparty label 可能過期，chain finality 不同，USD 價值只是簡化估計，rapid outflow 或 bridge hopping 也可能有合理業務原因。
- 每個 rate 都要和分母一起看；樣本太小時不應過度解讀。
- 門檻變更需要記錄誰批准、何時生效、會影響多少案件。
- Reviewer Audit Log 應追加而非覆寫，才能保留決策鏈。
- 工作簿適合展示與受控營運，不等於具備權限、版本發布與資料保留政策的正式 case-management platform。
所有帳戶、錢包、交易、alert 與 decision 都是合成資料。警示只啟動人工複核，工作簿不會也不應自動把帳戶標記為犯罪或直接執行封鎖。