接受數字貨幣錢包之前如何進行篩查

第 1 步：在准入前核查地址

從一個地址、一次核查開始。在 BlockSec 網站註冊，用每月 3 次免費核查中的一次來核查該地址，然後檢視幾秒內返回的五級風險評級：無、低、中、高或極高。接下來，由你們成文的策略、而不是一時的感覺，來決定這個等級對該客戶意味著什麼。

掃描是容易的那一半，真正考驗紀律的是決策規則：在開始之前，就寫明團隊在每個等級下該怎麼做。一種常見的做法是：無和低風險直接接受，中風險進入審核，高和極高風險拒絕或上報。但合適的做法取決於你們的風險偏好和監管機構的要求。工具給出評級，策略給出判斷。

這個順序之所以重要，是因為第一次篩查是你在這段業務關係中能做的成本最低的一次篩查。在資金流動之前、在使用者與你產生任何往來記錄之前、在一次錯誤的接受演變成糾紛之前，你能幹淨地看一眼這個地址做過什麼。金融行動特別工作組（FATF）將此表述為風險為本的方法：核查的深度應當與你面對的風險相匹配。

這項核查與身份核驗並列進行，而不是排在其後。KYC 回答的是這個人聲稱自己是誰；地址篩查回答的是他的錢包一直在做什麼。只做前者而跳過後者，平臺就會出現這樣的局面：客戶身份完全核實，充值卻來自與盜竊相關的錢包。兩項核查在同一道門口進行，依據的是不同的證據。

第 2 步：用 API 擴大核查規模

當每日核查量超出一個人能做好的範圍時，就把核查移入你的業務流程。批次篩查介面可以接收整份地址列表，API 金鑰對呼叫進行認證，同樣的五級風險評級以結構化結果返回，你的系統可以直接據此處理，無需任何人複製貼上。

進入這一步的觸發條件不是某個神奇的數字，而是第一次因為沒時間而跳過核查。那一天，人工篩查就不再是一種控制手段，而只是一種僥倖。API 路徑還能讓輸出標準化，這對最後的記錄步驟很重要。

動手開發之前，有三個問題決定了方案設計。我們每天實際要做多少次核查，按峰值而不是平均值算？結果落在哪裡，是客戶檔案、工單，還是單獨的日誌？當流程把一筆充值標記為待審核時，由誰負責處理這個例外？在第一週回答這些問題，可以避免兩種典型的失敗形態：沒人看的篩查任務，和沒人負責的審核佇列。

從介面到速率限制的整合細節，詳見自動化地址篩查：API、Webhook 與告警渠道。有一個規劃層面的事實值得在這裡重申：API 接入僅在 Scale 與 Enterprise 套餐中提供，所以在你的開發依賴它之前請先確認。

第 3 步：批准後配置監控

大多數團隊在批准後就止步了，而這恰恰是監控應當開始的地方。一個今天篩查結果乾淨的錢包，今晚就可能收到被盜或受制裁的資金。你接受的地址會進入監控名單，風險等級變化會把告警推送到團隊真正會看的渠道。

開啟你工作流的風險為本方法，同樣要求它持續進行：OFAC 近期動態按自己的節奏更新，一個地址可能在接入你的平臺很久之後才被列入名單。真正重要的事件，是已批准地址的風險等級發生變化，並附帶變化前後的等級以及事件經過的時間線。

乾淨的錢包為何會變得有風險，包括標籤更新與新活動的機制，是一個獨立的主題：數字貨幣錢包在乾淨之後還會變得有風險嗎？。本手冊要講的是習慣：每個被接受的地址都要持續監控，每條告警都要有一個決定，哪怕這個決定只是繼續觀察。

讓渠道適配團隊，而不是反過來。常駐群聊的合規團隊，就應該在群聊裡收到告警；實行輪值的團隊，就應該讓告警落到輪值人員盯著的工具裡。機制上最重要的是，變化前後的等級要與時間線一起送達，這樣做決定的人就不必再去還原等級為什麼變動。

第 4 步：保留經得起審計的記錄

每一次核查、每一次批准、每一次告警響應都會留下記錄：地址、日期、輸入、評級以及決策理由。把這些記錄放在一起，監管問詢就從重建變成了檢索，你的合規專案也能不斷改進，因為你終於能看清它一直以來在做什麼。

要達到的標準說起來很簡單。當檢查人員問你為什麼在六個月前允許了一筆充值時，團隊裡有人能在幾分鐘內給出答案，並附上當時有效的證據。風險時間線和告警歷史承擔了大部分整理工作，因為它們記錄了篩檢視到了什麼，以及何時看到的。

一個有用的演練是：每季度隨機挑一個已接受的錢包，把檢查人員的問題大聲問出來。我們為什麼接受了這筆充值？如果憑現有記錄幾分鐘就能回答，說明這套機制行之有效。如果需要花一個下午去重建，那麼這個缺口就在修復成本還低的時候暴露了出來。

記錄也為可疑案件畫上閉環。當活動從有風險越界到需要報告時，你一直保留的檔案就成為可疑活動報告（SAR）的骨架。這類報告的標準由 FATF 框架確立，它把你的工作流與報告層銜接起來，相關內容見如何撰寫數字貨幣 SAR 或 STR。

完整的四步框架（一頁即可看完，無需滾動）在錢包篩查中心中有全景呈現，同時還介紹了面向上個月業務量剛剛激增的團隊的自動化路徑。