用於交易前篩查的即時 KYT API

即時 KYT API 只在唯一還能改變結果的那一刻回答一個問題：這筆交易放行之前。鏈上轉帳是不可逆的，所以一筆入金或出金一旦廣播出去，剩下的選項只有調查與報送。交易前篩查把這個決策往前挪，挪進那個仍然可以攔下或掛起高風險交易對手的窗口裡。本文只談這個交易前視窗——它為什麼要緊、延遲要求是多少、API 如何返回一個決策、攔截/掛起/放行這套處置、即時與批次與監控三種模式各自的適用場景，以及一份交易前接入清單。KYT 的完整能力面見 Phalcon Compliance。本頁屬於 KYT 資源中心。

交易前篩查為什麼要緊

鏈上轉帳的不可逆性，是交易前篩查存在的結構性原因。一筆法幣電匯可以通過代理行體系撤銷、追回或凍結，一筆鏈上轉帳不能。它一旦被確認，資金就歸收款方所有，剩下的救濟手段只有事後調查、執法請求，或者提交一份 STR——而到那時資金往往已經又動過了。一道只在交易結算之後才跑的控制措施，實際上就是一道在損害發生之後才跑的控制措施。

交易後監控替代不了交易前檢查。FATF 面向虛擬資產服務提供商的風險為本方法要求 VASP 對交易進行持續的、對風險敏感的監控，而不是在開戶時做一次檢查。FinCEN 在其面向貨幣服務企業的反洗錢體系規則（31 CFR 1022.210）下對持續反洗錢監控義務的界定，對數字貨幣交易所及其他美國貨幣服務企業指向的是同一個方向。兩個框架都沒有規定一個硬性的延遲數字，但都期望這道控制措施真的跑在它所管轄的那筆交易上。一個只在資金動完之後才發現風險的體系，留下的缺口會被檢查官讀作體系薄弱，而不是部署偏好。

經濟帳也偏向更早的那個決策。在閘口攔下一筆高風險入金，成本是一次 API 呼叫；追同一筆入金穿過三跳混幣服務，成本是一個分析師好幾天，而且追回來的機率很低。交易前篩查，正是「一道能預防的控制措施」與「一道只能報告的控制措施」之間的差別。

一次篩查呼叫必須多快返回

交易前篩查的邊界是使用者體驗，不是廠商能力。一筆出金因為要跑篩查而卡兩秒，用起來就像壞了；一筆入金因為分析師要複核而被掛十秒，用起來就像被凍結了。所以交易前決策的延遲預算很緊，是以數百毫秒計的，不是以秒計。一個常見的可用上限是端到端大約 500 毫秒——從交易抵達閘口，到放行、掛起或攔截的決策返回。在這個上限之下，篩查對使用者是不可見的；超過它，篩查就開始顯得像摩擦，而摩擦會驅使使用者繞開這道控制措施。

理想目標要更低。API 自身做到 100 毫秒以內的響應，才給閘口剩下的部分留出餘地：網路往返、內部路由、日誌、閾值判斷，都要在原始 API 呼叫之上再吃掉一部分預算。如果 API 一家就吃掉 300 毫秒，棧裡剩下的部分就沒得用了。延遲不是規格表上的一個功能項，它是「一道與交易同步執行的控制措施」和「一道與交易賽跑的控制措施」之間的差別。

BlockSec 為其即時篩查 API 標註的是毫秒級延遲。把它當作一個需要在生產流量上確認的目標，而不是一個可以據以設定內部 SLA 的既定事實。一道假設 50 毫秒、實際看到 400 毫秒的閘口，會在第一條告警觸發之前就先垮掉。閘口必須去量那個真實數字，並在沒達到時優雅降級。

即時 KYT 篩查 API 是怎麼運作的

即時 KYT 篩查 API 坐在交易的決策路徑上，而不是它旁邊。整個流程有四步，而且必須在延遲預算內跑完。客戶端完成認證並提交地址或交易標識；API 拿這個地址去比對它的風險資料，返回一個風險評分以及背後的證據；隨後客戶端的閘口用以程式碼定義的閾值把分值對映成一個處置動作——攔截、掛起或放行——並據此放行或截住這筆交易。這個呼叫是同步的、單地址的，因為決策必須在交易放行之前回來。

Phalcon Compliance 的即時篩查 API 就是這個形狀。訪問由單個 API key 管控。呼叫返回一個風險評分、支撐它的敞口數字，以及驅動這個分值的那些風險指標。風險資料建立在超過 6 億個帶標籤地址與 17 個以上風險指標類別之上，覆蓋行為模式、對已知非法服務的敞口，以及交易對手風險。分值是閘口據以分流的東西；而指標與敞口數字，是交易被掛起複核時分析師會讀的東西——也正是它們讓這個決策可審計而不是不透明。

有兩個約束條件決定了這個 API 怎麼用。第一，訪問門檻在 Scale 檔（699 美元/月起）與 Enterprise 檔。免費檔、篩查包與 Essential 檔是給通過平臺介面做互動式篩查用的，不是給嵌進交易閘口用的。一個要搭交易前篩查的團隊，在寫第一個呼叫之前就必須已經在 Scale 或 Enterprise 上。第二，那個延遲數字——即時 API 的毫秒級響應——決定了這個 API 能不能服務一道交易前閘口，還是隻能退回去做交易後監控。在團隊自己的負載下確認這個真實數字，是上線的一部分，不是上線之後的形式手續。

攔截、掛起還是放行：在資金動之前決定

一次即時篩查只有在閘口知道拿這個答案做什麼時才有用。適配交易前篩查的框架是一套三檔分層處置，而不是「放行還是標記」的二元判斷。各檔由風險評分劃定，每一檔都帶一個閘口無需等人就會執行的具體動作。

第一檔是放行。低風險地址在延遲預算內自動、同步地放行，而這一檔必須佔絕大多數流量。第二檔是掛起。中風險地址既不放行也不攔截：交易被暫停，一條告警被送進複核佇列，分析師在面前擺著風險指標與敞口數字的情況下決定處置。掛起接住的是那些分值本身模糊、值得為人工判斷付出延遲代價的情形。第三檔是攔截。高風險地址在放行前被截住，交易不被廣播，同時開出一條帶完整證據鏈的告警。攔截這一檔乾的，正是交易後監控幹不了的那份預防工作。

這套框架的分量在審計鏈上，而不只在那個決策上。每一個處置結論都必須可復現：返回的是哪個分值、它落進哪一檔、由哪些指標驅動、閘口採取了哪個動作。一次攔截必須能作為「基於證據的決策」被論證，而不是一條拍腦袋的經驗規則。一次掛起必須可審計為「一次確實被複核並結掉的暫停」，而不是一筆被悄悄丟掉的交易。風險指標與敞口數字，正是讓這條鏈完整的東西。沒有它們，處置就只是一個裁決；有了它們，它是一個檢查官或審計人員讀得懂的、有據可查的決策。

即時、批次、監控——什麼時候用哪個

交易前篩查不是唯一的篩查模式，而把這幾種模式搞混是一個常見的失敗模式。即時 KYT API 有三種執行模式，各自回答一個不同的問題。即時單次檢查回答「這筆交易現在放行安不安全」。批次篩查回答「這批積壓的風險畫像是什麼樣」。監控回答「一個我們已經篩過的地址，自上次看過之後風險變了沒有」。三者不會合併成一個，用錯了要麼白燒額度，要麼漏掉風險。

即時單次檢查是交易前那個模式：同步、低延遲，在閘口上每筆交易跑一次。批次篩查是非同步的，跑在 CSV 上傳的歷史積壓上，不跑在交易路徑裡。監控是持續的：它按動態週期重新分析已篩查過的地址，並在一個此前乾淨的地址風險發生變化時觸發——比如某個交易對手後來被列入制裁名單。

實際分工是：即時管現場閘口，批次管歷史積壓，監控管風險漂移。只跑即時的體系，對第一次篩查之後才浮現的風險是盲的；只跑監控的體系，沒有交易前決策；只跑批次的體系，兩樣都沒有。穩妥的配置是三種都用，各守其道。特別值得一提的是，監控模式不消耗篩查額度，所以把它一直開著，不會佔用即時與批次所依賴的那份單次檢查預算。本頁只談即時這條道；把三者一起接進一個交易所流程，是另一個接入話題。

交易前篩查的接入清單

一道交易前篩查閘口算做完，是當它對任意一筆交易都能回答：採取了什麼處置、為什麼、以及這個決策花了多久。下面這份清單是即時視角，聚焦閘口本身。

1. 確認 API 檔位。 即時 API 訪問需要 Scale 檔（699 美元/月起）或 Enterprise 檔。寫第一個呼叫之前先確認。

2. 把延遲預算寫進程式碼。 為整條篩查路徑定一個上限（常見約 500 毫秒），並在生產流量上量真實往返時間。把官方公佈的毫秒級響應當作一個待確認的目標，而不是一個假設。

3. 把閾值分檔定義成程式碼。 攔截、掛起、放行必須是程式化的，按返回的風險評分分流。只活在文件裡、不活在閘口裡的政策，不會跑在交易上。

4. 上線前先接通告警路徑。 掛起與攔截必須真的落進一個佇列——webhook、工單或內部頻道。等第一條告警漏掉之後再補分流，那已經是一次失敗了。

5. 每個處置結論都要落存證據。 分值、閾值檔位、風險指標、敞口數字，都必須與交易記錄一起存下來。這個處置在幾個月後必須仍然可復現。

6. 建好降級路徑。 如果 API 超出延遲預算或報錯，閘口必須朝一個既定方向失敗——掛起待複核，或者放行但打上交易後監控標記——而不是把交易悄悄丟掉。

7. 處理速率限制。 篩查 API 按 key 限流，超限的呼叫返回 HTTP 429。客戶端必須做退避，而不是遇錯就重試。

8. 為風險漂移開啟監控。 交易前篩查抓的是閘口那一刻的風險，監控抓的是之後才浮現的風險。監控不消耗篩查額度，所以可以一直開著而不佔用即時的預算。

一道過了這份清單的閘口，會把交易前決策跑在交易路徑裡：閾值會觸發、告警會到人手上、證據會留存、降級路徑會安全失敗。這就是即時交易前篩查在實踐中的樣子。閱讀 Phalcon Compliance 的 KYT API 文件，查端點參考、Scale 檔的接入路徑，以及完整的風險指標 schema。