加密貨幣合規軟體回應的是義務，而非功能清單：這個類別的存在，是為了承擔加密貨幣業務原本就已肩負的篩查、監控及報告職責。進入市場的機構與平台，並不需要從零開始發明一套合規計畫；他們需要的是將鏈上義務轉譯成工具，而這正是此類軟體所銷售的內容。本指南所繪製的，正是這種映射關係本身：哪種能力對應哪項義務，以及哪些責任始終留在營運方身上。
從義務出發，而非從工具出發
購買討論通常從工具開始，但這其實本末倒置。加密貨幣業務在評估任何軟體之前，已背負三大義務群組。篩查職責：在導入客戶時及每個受規範的接觸點，了解與你交易的地址所帶來的風險。監控職責：持續觀察往來關係，因為風險在客戶導入之後仍會變化。報告與紀錄職責：及時上報可疑活動，並保存經得起檢視的證據。FinCEN 的資料說明了背後的反洗錢原理，而FATF 建議書則制定了國際框架。
機構所描述的進入市場問題，其實是一個轉譯問題：這些義務在傳統金融中並不陌生，陌生的是這片新領域。能與這些義務清楚對應的合規軟體，能將陌生的風險場景轉化為熟悉的計畫。
哪種工具能力回應哪項義務
義務與能力之間有清楚的對應關係：篩查職責需要標籤深度，監控職責需要事件觸發與低延遲，報告職責則需要可解釋的證據軌跡。
| 義務 | 回應此義務的能力 | 應要求的條件 |
|---|---|---|
| 篩查（導入及接觸點） | 標籤化地址情報 | 規模達數億級別、持續更新、多鏈覆蓋 |
| 監控（持續性） | 事件觸發式重新篩查 | 由制裁指定驅動的重新檢查、毫秒級回應、分層警示 |
| 報告（上報） | 證據彙整 | 機器生成的軌跡、可解釋的訊號、可匯出的格式 |
| 紀錄保存（供檢查用） | 稽核級日誌記錄 | 每次檢查均附有情報依據的時間戳記 |
供應商應能明確陳述的數字：Phalcon Compliance 對每筆受篩查的交易，會依據超過 200 項風險訊號進行評估，並運用涵蓋數億個地址、持續更新的標籤化資料庫。若數字沒有可查核的依據，理應受到質疑。
這種映射式的紀律勝過功能清單式的做法：依照義務來採購的團隊，最終會得到他們真正會使用的工具，而按清單採購的團隊，則會為那些永遠派不上用場的模組付費。若想更全面了解此類別，請參閱加密貨幣合規軟體指南；若想比較各主要選項，請參閱6 款最佳區塊鏈與加密貨幣合規軟體解決方案。
部署形式：API、平台，或兩者兼具
| 形式 | 內容說明 | 適用情境 |
|---|---|---|
| API 優先 | 將篩查呼叫嵌入你的產品流程中 | 支付、交易所、託管服務：風險決策於流程中即時執行 |
| 平台 | 供分析師審查與調查使用的工作空間 | 合規團隊處理案件佇列及定期審查 |
| 兩者兼具 | 在 API 與工作空間之下共用同一情報層 | 需要大量篩查、並針對例外情況進行調查的營運單位 |
多數營運團隊會在同一個情報層上同時運行這兩種形式。API 呼叫所產生的證據，正是調查人員之後所需的同一份證據，若需從兩套系統中重新拼湊，往往就是檢查過程變得痛苦的原因。
預約 Phalcon Compliance 的展示，看看這三大義務群組如何對應同一個標籤化情報層，並可透過 API、平台，或兩者兼具的方式部署。
常見問題：加密貨幣合規軟體
合規軟體能讓我們符合合規要求嗎？ 不能。Phalcon Compliance 產出的是訊號、證據與草案；決策與責任仍歸屬於你的機構。若有軟體承諾本身就能達成合規，那等於是在承諾監理機構不會接受的事。
這與 KYC 工具相同嗎？ 不同。身分驗證是一門獨立的學科，有其自身的類別。鏈上合規軟體涵蓋的是地址與交易層面，與身分驗證相互配合，而非取而代之。
收費方式為何？ 按次計費（用量制）與訂閱制兩種模式皆有；按次計費適合隨市場週期波動的用量，訂閱制則適合穩定的高用量需求。
購買前應確認哪些事項？ 依序為：標籤資料庫的規模與更新頻率、在你尖峰負載下的回應延遲、警示的可解釋性，以及鏈的覆蓋範圍。
