用戶把錢存入 FinTech 平台後，因為各種原因導致帳號被盜用，我們稱呼這樣的現象為 帳戶接管攻擊 (Account Takeover Attack, ATO)，除了密碼外洩的管道很多種，除了常見的密碼外洩外，可以在 https://haveibeenpwned.com/ 這個網站查查看你的信箱密碼是不是已經被外洩了，即使你今天密碼沒有外洩，駭客也很容易透過你的 Email 和可以搜尋到的個人資料來嘗試重設你的密碼，來竊取你帳戶的資料，這在現今網銀充斥的時代，有了你個人的帳號密碼就很容易把你的資產轉走，更不用說監管極少的加密貨幣或是數位創新產業了，因此 ATO 監測格外重要

如果我們用一個機器學習的觀點來看這問題，可以簡化成一個二元分類問題 (Binary Classification)，有資料科學背景的工程師立刻就會想到如何開始做一個 EDA 來設計特徵，接著用 XGB Model 訓練產生一個二元分類模型，最後把模型變成一個 API Endpoint 來給其他服務調用，然而這樣一股腦兒的栽進去，往往會變成模型做出來，報告也證明各項 Metrics 表現還可以，但是要把模型推到線上的服務卻很難推動

比資料跟建模更重要的是什麼？Agrawal 提出一個 AI Canvas 的理論和後來的 Louis Dorard 提出了 ML Canvas ，這兩個理論提供了一個表格讓你可以在開始專案時就去評估一個 AI/ ML Solution 所需要考量的各個面向，但我相信大多的 Data Driven 專案，特別是一個想要快速 POC，快速實作 Solution 的專案並沒有時間和資源去研究這裡面的每一項資訊，對於這樣的情境，我的經驗是：

請先放棄使用 ML 而是用一系列的 If-else 來解決你的問題，如果更系統化的說法，請先搭建一個決策引擎

舉例我們提到的 ATO 案例， 如果我要用一個邏輯來判定我要怎麼做？最簡單的做法，我如果發現用戶用的 IP 是一個他從來沒使用的 IP 登入，輕且嘗試提款，我就要阻止他提款。上面這一段描述就需要以下的系統元件

1. 我需要一個資料庫記得用戶過去使用過的 IP ，這就是一個特徵引擎
2. 需要每次用戶提款的時候，就去得到用戶使用的 IP，這是一個實時的特徵計算
3. 計算提款使用到的 IP 和過去使用的 IP 是否重複，這是一個判斷邏輯
4. 如果發現異常，我們要阻止用戶提款，阻止的方法可以是延遲，或是寄信請用戶確認是否有這筆提款，或是直接拒絕讓請求失敗，這是一個業務流程的設計

這整套流程可以抽象成 Event -> Rule -> Action和一個資料層以及計算層

• Event：用戶發生提款的觸發點
• Rule：一系列判斷邏輯
• Action：如果 Rule 判定有問題後續如何處理
• 資料層：保存用戶資訊與特徵
• 計算層：計算用戶資訊與特徵

當然這個邏輯會產生很多的 False Positive，用戶很有可能會因為在家裡以外的地方登入然後發現無法提款，就會氣炸的打客速電話，然後給在 Apple Store 上臭罵你。你可以試著去把 IP 改成 IP 所在的國家，也可以用用戶設備的名稱等等，設計更多的 Rule 來層層把關

好的金庫要層層方戶，而不是使用一個完全不可能攻破的鎖