一次 KYT API 接入，會在每一筆入金與出金上呼叫篩查端點、解析返回的風險評分，並在資金動之前給這筆交易分流。批次篩查與持續監控疊在它上面，負責歷史資料與地址漂移。這個 API 屬於交易流程裡面，而不是跑在它旁邊——因為即時檢查在結算之前抓到高風險活動，而批次任務與監控覆蓋兩者之間的一切。本文為一家數字貨幣交易所走完這三種模式。更寬的工作流見 Phalcon Compliance。本頁屬於數字貨幣反洗錢合規中心。
交易所為什麼需要 API 級的即時篩查
一家交易所選定的篩查節奏，同時也就是它接受下來的那個洗錢視窗。一個按周或按日跑的批處理任務，篩的是批處理執行那一刻的所有地址；但每一筆在兩次批處理之間到達的入金，都會毫無阻礙地進入錢包。資金可以在那道縫隙裡落地、轉移、提現出去。API 級的即時篩查把這道縫隙合上，因為每一筆入金與出金都在交易被放行之前被檢查過。
推動它的不只是運營考慮。FinCEN 要求貨幣服務企業（含數字貨幣交易所）維持一套反洗錢體系（31 CFR 1022.210）並報送可疑交易（31 CFR 1022.320），並結合其2019 年虛擬貨幣指引（FIN-2019-G001）一起讀。實操上，正是這個組合使持續監控成為必需，而不是設定了某個固定的即時閾值。FATF 面向虛擬資產服務提供商的風險為本方法收斂到同一個要求上——它要求 VASP 持續監控交易，而不是在開戶時做一次檢查。一家交易所滿足這兩者的方式，是在每一筆入金與出金上保持一道活著的控制措施——而這恰恰是下面講的即時 API 模式所提供的東西。一個只有批次節奏的做法，會在「監控義務」與「實際在跑的控制措施」之間留下一段可被察覺的距離，而檢查官會把這段距離讀成體系缺陷，而不是部署偏好。
這個問題的開發一側，本身是另一重約束。在那些現成的第三方工具真正拿到內部系統的訪問權限之前，任何組合都不會貼合一家交易所的使用場景——所以被低估的那場仗是接入，而不是功能數量。一個無法與入金流程、出金流程和告警分派路徑對話的篩查引擎，改變不了這家交易所能抓到什麼，它只改變了一個看板。正是接入這件工作，把一項篩查能力變成一個篩查體系。
接入前的準備：風險閾值、告警分派、系統訪問
在寫任何 API 呼叫之前，有三個決定必須先定下來。它們決定了這套接入上線之後實際做什麼；而在部署之後再改它們，意味著 API 客戶端與下游告警路徑都要返工。這三個決定坐在更大的數字貨幣交易所反洗錢合規體系裡面——那篇覆蓋風險評估、篩查、分流與可審計記錄。本頁聚焦的是那套體系裡的 API 接入層，而不是體系結構本身。
第一個決定是風險閾值規則集。KYT API 返回一個風險評分，但這個分值在交易所決定「哪些分值區間觸發哪個動作」之前什麼都不做。一個常見的形狀是三檔：低風險自動放行，中風險掛起交易待人工複核，高風險攔截交易並開出告警。這些閾值必須被定義成程式碼、而不是定義成政策，因為 API 客戶端會以程式方式按它們分流。
第二個決定是告警分派。當一個風險評分越過閾值時，這條告警必須到達一個人或一個佇列。分派設計要覆蓋：哪個渠道承載這條告警——是一個進 Slack 或 Telegram 頻道的 webhook、一個案件管理工具裡的工單，還是一個內部佇列裡的條目。平臺支援含 webhook 的多渠道通知，而分派路徑必須在接入上線之前就對映好，不是在第一條告警漏掉之後再補上去。
第三個決定是套餐門檻。API 訪問只在 Scale 檔（699 美元/月起）與 Enterprise 檔提供；免費檔、篩查包與 Essential 檔不含 API 訪問。一個想把篩查嵌進自家入金或出金流程的團隊，需要先到 Scale 檔。在接入開始之前確認這一點，能避免「程式碼是對著一個團隊實際用不了的檔位寫的」這種局面。至於多席位團隊協作——如果合規職能需要不止一個人同時在工具裡作業——只在 Enterprise 檔提供。這道門檻如何坐在更寬的數字貨幣反洗錢合規體系裡，在中心頁上有鋪陳。
接入 Phalcon Compliance 的 KYT 與 KYA API：三種模式
Phalcon Compliance 的 API 支援即時檢查、非同步 CSV 批次篩查、持續監控。即時檢查覆蓋入金與出金。批次篩查覆蓋歷史地址與積壓。Monitor 盯住此前已篩查過的地址、觀察其風險變化。交易所可以按「在哪裡、什麼時候需要篩查」把這三種模式組合起來。
一家交易所的入金與出金流程有三種篩查需求，而它們不會合併成一種。一筆活著的交易需要在被放行之前拿到答案，這意味著一次同步的、低延遲的呼叫。一批歷史地址需要在不阻塞即時流量的前提下批次篩查，這意味著一個非同步任務。而一個首次篩查時乾淨的地址，日後可能與一個高風險交易對手交易，這意味著對已篩查地址的持續觀察，而不是一次性的裁決。
Phalcon Compliance 以三種模式開放它的篩查 API，對應上述三種需求。即時單次檢查模式覆蓋入金與出金閘口。非同步 CSV 批次模式覆蓋積壓與歷史篩查。持續的 Monitor 模式按動態週期重新分析已篩查過的地址。三種模式共享同一個已認證的介面面，於是單個 API key 就管控對它們全部的訪問，而交易所是逐次呼叫地挑模式，不必維護幾套獨立的接入。
| 模式 | 觸發物件 | 延遲 | 額度與速率限制 | 使用場景 |
|---|---|---|---|---|
| 即時單次檢查 | 單個地址或交易 | 毫秒級 | 每個 API key 每分鐘 50 次呼叫 | 即時的入金與出金篩查 |
| 非同步 CSV 批次 | CSV 上傳 | 非同步 | 地址 CSV 每文件最多 100 條；交易 CSV 每批最多 400 條 | 積壓與歷史篩查 |
| Monitor | 持續 | 動態週期 | 不消耗篩查額度 | 風險變化時對已篩查地址重新分析 |
三種模式的接入順序是一樣的。客戶端用平臺簽發的 API key 完成認證；帶上地址或交易標識呼叫篩查端點；解析返回的風險評分，包括附著在分值上的風險指標與敞口數字；按接入前定下的閾值規則分流；並在閾值被越過時，通過已配置的 webhook 或通知渠道發出告警。篩查 API 按每個 API key 每分鐘 50 次呼叫限流，超限的呼叫會收到 HTTP 429，所以客戶端必須以退避方式處理 429，而不是遇錯就重試。
BlockSec 把即時單次檢查的延遲標註為毫秒級。把它當作一個需要拿團隊自己的流量去確認的數字：把接入建成能容忍延遲的形態，而不是假定某個具體的毫秒目標；交易所設定的任何內部 SLA，都要拿生產流量去量。
速率限制、額度與套餐門檻：工程要點
速率限制是接入最先撞上的那個工程約束。篩查 API 按每個 API key 每分鐘 50 次呼叫限流，超限的呼叫會收到 HTTP 429。對一條活著的入金流程，這很少構成實際約束，因為入金是一筆一筆到的，而一次即時檢查會在下一次呼叫之前跑完。但對一次批次操作它就是約束了，因為同步地篩幾千個積壓地址，幾分鐘就會把限額燒穿。CSV 批次模式的存在，正是為了把這份負載從同步路徑上移走。CSV 地址篩查每文件最多接受 100 個地址，CSV 交易篩查每批最多接受 400 筆交易。於是積壓是被非同步處理的，不會與即時閘口爭搶速率限額。
額度模型是第二個約束。篩查會扣減一個餘額，而扣減按一個既定順序發生：訂閱額度每個週期重置，然後消耗充值篩查額度，然後是推薦獎勵，然後是篩查包。接入本身不需要挑用哪個餘額；但掌管預算的合規團隊確實需要理解這個順序，因為它決定了哪個餘額先被耗盡、以及什麼時候必須充值。Monitor 模式是例外：它按動態週期執行，在已篩查地址的風險發生變化時重新篩查它們，而且不消耗篩查額度——所以把 Monitor 一直開著，不會佔用單次檢查的預算。
套餐門檻是第三個約束，而且不可協商。如上文所述，API 訪問需要 Scale 檔（699 美元/月起）或 Enterprise 檔；免費檔、篩查包與 Essential 檔不含 API 訪問。在這道門檻之外，還有兩項附加能力會影響範圍：webhook 訪問落在 Scale 或 Enterprise 檔；自定義風險引擎配置從篩查包檔位起可用（篩查包 3 個引擎、Essential 10 個、Scale 20 個、Enterprise 不限）；而工具內的多席位協作是 Enterprise 的功能。這些檔位背後的定價細節在專門那篇定價 spoke 裡講；本頁只覆蓋影響 API 接入規劃的那部分門檻。
閱讀 Phalcon Compliance 的 API 文件
一次 KYT API 接入，不是在第一個呼叫返回一個分值時就算完成了。它算完成，是當即時閘口、積壓路徑與 Monitor 觀察三者都被接進了這家交易所的入金與出金流程：閾值被定義成程式碼、告警分派到一個真實佇列、套餐門檻在第一個呼叫之前就已確認。閱讀 Phalcon Compliance 的 API 文件，查端點參考、webhook 契約與 Scale 檔的試用路徑。