跳到主要內容

電信訊號 × AI 風險決策 API

為按下確認的那一秒而設計。

商家在換收款帳戶、大額轉帳、結帳之前呼叫 TrustLayer:參考電信訊號與平台行為,判斷這是不是本人、是不是正在被詐騙,回給 0–100 分、原因碼與建議動作。

現況

大額轉帳有人把關,小額詐騙每天都在發生。

2025 年全台詐騙
財損NT$893.26 億受理16.2 萬件
投資詐騙單月財損
2024/8 → 2025/1289 億 → 27.96 億
大魚攔下來了。
2025/12 網購詐騙,案件數第一
受理4,140 件平均每件損失約 7.6 萬
小魚愈來愈多:單筆不高、件數極大,多半不經過銀行的大額轉帳警示。

資料來源:內政部警政署 165 打詐儀錶板

  • 訊號落差

    電信只回單點事實。同樣是換過 SIM 卡,申辦新機時正常,半夜大額轉帳時就是紅旗。

  • 決策落差

    拿到訊號,還得自建模型、門檻與稽核;大型銀行做得起,中小平台做不起。

  • 通路落差

    機構對機構的客製串接,導入以月計;詐騙件數成長最快的中小平台反而接不上。

一通電話

陳阿姨的一通電話。

  1. 步驟 1 / 5

    晚上九點,陌生來電。

    TrustLayer 看得到

    • 正在通話電信網路 · Scam Signal
  2. 步驟 2 / 5

    對方要她打開來電轉接。

    TrustLayer 看得到

    • 來電轉接已開啟電信網路 · Call Forwarding
  3. 步驟 3 / 5

    換一支新手機,登入拾光購物。

    TrustLayer 看得到

    • 這個會員第一次用這台裝置商家提供
  4. 步驟 4 / 5

    結帳 NT$10,000 禮物卡,按下「確認付款」。

    TrustLayer 看得到

    • 金額是近 30 日平均的 12.1 倍商家提供
  5. 步驟 5 / 5

    這一秒,付款被攔下來。

    風險分數(示範回應)87

    攔截審核BLOCK_REVIEW

    原因碼

    • CALL_STATE_CONCURRENT+35交易當下門號正在通話中
    • CALL_FORWARDING_ACTIVE+30門號已開啟無條件來電轉接
    • CONTEXT_ANOMALY+22首次使用的裝置、金額為近 30 日平均的 12.1 倍

    建議:攔截並送人工審核。

    通話中不寄簡訊驗證碼:騙子會叫你念出來。

示範劇本;電信訊號依公開 CAMARA 規格模擬中華電信。

電信網路

這份安心,也該屬於中小企業。

中華電信已為企業推出 11 支通過 GSMA 認證的網路 API。TrustLayer 想延續這個想法:讓每天面對詐騙的中小商家,也用得到電信網路裡的訊號。

TrustLayer 目前沒有與中華電信合作。

電信訊號依公開 CAMARA 規格模擬中華電信。中華電信 2026/7/1 公告

信任層

訊號早就在電信網路裡,缺的是一層決策。

TrustLayer 把分散的電信訊號與平台行為,變成商家可以直接用的決策。

判斷方式

看訊號,給分數,建議下一步。

換卡、門號、通話、網路與裝置,各自由電信網路回答「是否異常」。

01 訊號進來

  1. SIM 卡與門號

    • 換 SIM 卡SIM Swap
    • 門號核實Number Verification
    • 門號開通時間KYC Tenure
  2. 通話與網路

    • 正在通話Scam Signal
    • 來電轉接Call Forwarding
    • 漫遊狀態Device Roaming Status
    • 位置驗證Location Verification
  3. 這支手機

    • 裝置識別Device ID

示意圖;手機為程式繪製的通用機型,畫面為模擬。

02 算出分數

一個 0–100 的分數,對應四種動作。

電信訊號與平台行為各自加分,加總後落在哪一段,就建議商家怎麼做。

  • 放行0–29
  • 提示30–59
  • 二次驗證60–84
  • 攔截審核85–100

示意,不是實測。

03 給出動作

每個分數都附原因碼與建議動作。

  • 拿不到訊號就是 UNKNOWN,不當安全,也不當詐騙。

  • AI 模型只能把分數調高,不能壓低。

  • 換卡、通話中、來電轉接時,不寄簡訊驗證碼。

13 個原因碼(13)

計畫書 7 個

  • SIM_RECENT_CHANGE門號近期更換過 SIM 卡
  • DEVICE_ROAMING_MISMATCH門號正在漫遊,所在地與操作來源不一致
  • NUMBER_BINDING_WEAK帳號與門號的綁定關係薄弱(綁定時間短,或門號與目前裝置的 SIM 不符)
  • CALL_STATE_CONCURRENT交易當下門號正在通話中
  • CONTEXT_ANOMALY這次操作的情境異常(例如新裝置、多次登入失敗、剛變更收款帳戶或金額偏高)
  • COUNTERPARTY_RISK交易對象有風險跡象(帳號很新或曾被檢舉)
  • TELECOM_SIGNAL_UNAVAILABLE電信訊號暫時無法取得,未視為安全,改以平台行為判斷

平台版新增 6 個

  • NUMBER_TENURE_SHORT門號為近期才開通的新門號
  • DEVICE_RECENT_CHANGE門號近期移到另一支手機使用
  • LOCATION_MISMATCH門號所在位置與商家提供的位置不符
  • DEVICE_UNREACHABLE門號目前未連上行動網路
  • CALL_FORWARDING_ACTIVE門號已開啟無條件來電轉接
  • DEVICE_UNRECOGNIZED這次使用的手機不是此門號常用的手機

產業情境

每個產業,都有自己的那一秒。

同一個 API,可以用在銀行、購物平台、售票、外送與政府線上服務。

  1. 驗證碼和帳戶都流向詐團,林小姐的手機什麼都沒收到

    01 銀行

    變更綁定門號

    晴空銀行

    林小姐的 SIM 卡被詐團冒名補辦;詐團收到驗證碼後登入,再把綁定改成自己的門號。

    用到的訊號

    • 換 SIM 卡SIM Swap
    • 來電轉接Call Forwarding
    • 新門號開通時間KYC Tenure
    • 新門號核實Number Verification

    結果

    • 82分二次驗證詐團先補辦 SIM,再改綁門號

    改綁的那一刻多查兩支門號,詐團就不容易把帳號整個拿走。

    變更綁定門號・說明影片

  2. 詐團拿著新手機走過三塊踏腳石:重設密碼、改收款帳戶、提領

    02 購物平台

    帳號盜用(連續操作)

    拾光購物

    密碼被假網站騙走;詐團用新手機重設密碼、改收款帳戶,再提領。

    事件順序是選用功能,預設關閉,商家可以開啟。

    用到的訊號

    • 換 SIM 卡SIM Swap
    • 事件順序

    結果

    • 62分二次驗證加上事件順序(提領)
    • 22分放行只看提領這一筆

    單看一筆都不嚴重;把每一步串起來看,提領前就要求確認本人。

  3. 插著小陳 SIM 卡的手機放在國外機房的長桌上,被害人的錢一筆筆流進帳戶

    03 收款銀行

    門號轉帳/人頭帳戶

    綠野銀行(收款)・晴空銀行(付款)

    小陳的帳戶連門號一起賣掉;SIM 卡後來出現在國外機房,被害人的錢不斷轉進來。

    用到的訊號

    • 換 SIM 卡SIM Swap
    • 漫遊狀態Device Roaming Status
    • 門號開通時間KYC Tenure
    • 裝置識別Device ID

    結果

    • 50分提示SIM 卡被帶到國外機房

    入帳時多看一眼,人頭帳戶就不容易把錢轉走。

    門號轉帳/人頭帳戶・說明影片

  4. 黃牛坐在電腦前,旁邊插滿 SIM 卡的貓池不斷吐出新帳號

    04 售票平台

    搶票黃牛

    星光售票

    一批剛開通的預付卡插在貓池裡收驗證碼,黃牛在電腦上一個接一個註冊,準備抽籤囤票。

    用到的訊號

    • 門號開通時間KYC Tenure
    • 門號核實Number Verification
    • 換 SIM 卡SIM Swap

    結果

    • 53分提示黃牛用人頭卡大量開帳號

    在註冊和付款時把關,把人頭帳號擋在門外。

    搶票黃牛・說明影片

  5. 小美把驗證碼轉傳出去,笑臉好友其實是詐團拿著的面具

    05 購物平台

    「請給我驗證碼」

    拾光購物

    「好友」傳訊息說換了新手機,要小美幫忙轉傳一封簡訊;那是小美自己帳號的登入驗證碼。

    用到的訊號

    • 門號核實Number Verification
    • 換 SIM 卡SIM Swap

    結果

    • 32分提示改用門號核實:核實不符,擋下登入
    • 12分放行只用簡訊驗證碼:詐團登入成功

    沒有驗證碼可以轉傳,這種騙法就沒有著力點。

    「請給我驗證碼」・說明影片

  6. 刷卡機顯示紅色叉叉,林先生焦急地打電話給銀行

    06 發卡銀行

    出國刷卡被誤擋

    晴空銀行

    林先生人在日本,門號在日本漫遊;他在澀谷逛街刷卡,金額比平常高。

    不會誤擋本人:門號在日本漫遊、就在店家附近,跟刷卡的地點一致,照常授權。

    用到的訊號

    • 漫遊狀態Device Roaming Status
    • 位置驗證Location Verification

    結果

    • 0分放行林先生在東京逛街刷卡

    好人少被擋,盜刷多一道確認。

    出國刷卡被誤擋・說明影片

  7. 阿傑把帳號交給穿橘色上衣的朋友,朋友背起外送箱騎上機車

    07 外送平台

    帳號出租

    快送夥伴

    沒通過審核的朋友用自己的手機登入阿傑的帳號;阿傑的 SIM 卡還在阿傑手上。

    用到的訊號

    • 門號核實Number Verification
    • 裝置識別Device ID

    結果

    • 32分提示帳號借給朋友跑單

    每次上線多查一次門號,帳號出租就藏不住。

    帳號出租・說明影片

  8. 戴帽兜的人拿著外洩的資料和身分證影本搶先登記,補助飛向他的金融卡

    08 政府線上服務

    政府服務冒領

    補助申請・發票小幫手

    張奶奶的 SIM 卡被冒名補辦;對方用她的門號收簡訊驗證碼,搶先完成登記。

    用到的訊號

    • 門號開通時間KYC Tenure
    • 門號核實Number Verification
    • 換 SIM 卡SIM Swap
    • 來電轉接Call Forwarding

    結果

    • 55分提示補助:冒名補辦 SIM 卡收驗證碼
    • 85分攔截審核發票獎金:領獎帳戶換成人頭帳戶

    送出申請時多看一眼,冒名登記就多一道關卡。

    補助被冒名登記・說明影片

    發票獎金被改匯・說明影片

一套 API,八個產業場景。

品牌、人物與門號皆為虛構;分數是各情境劇本的引擎實測值(電信訊號依公開 CAMARA 規格模擬),不是防詐成效。

情資與簡訊

  • 情資測試

    詐騙情資是一份跟詐騙有關的帳號、門號、錢包、LINE ID 與網域清單(165 公開資料、平台自己上傳、外部情資來源、商家與用戶回報)。情資單獨命中最多到二次驗證,不會直接攔截,因為人頭帳戶的主人也可能是受害者。除了公開來源的網域,識別資料進來就雜湊,不存明碼。

    其中的 165 涉詐網站公開資料來自政府資料開放平臺(data.gov.tw 176455)。

  • 簡訊查詢

    POST /v1/messages/check

    把用戶收到的簡訊貼上來:抽出網址、電話、帳號與 LINE ID 查詐騙情資,再加上假冒品牌、假冒政府、短網址、催促語氣幾條規則。簡訊全文不存。

    沒發現已知詐騙特徵,不代表一定安全;不確定請撥 165。

最小揭露

我們只問:是不是異常。

一個門號、一則簡訊,經過 TrustLayer 之後留下的東西

門號

0900-000-007

加鹽雜湊

POST /v1/score

回應

telecom_evidence.signals

sim_swap
"value": false
scam_signal
"value": true
call_forwarding
"value": true

true=異常false=正常

簡訊

【物流通知】您的包裹因地址不全無法配送,請於今日內至 https://parcel-redeliver.test/tw 更新資料,逾期退回。

POST /v1/messages/check

回應

verdict
"SUSPICIOUS"可疑
signals
URL_IN_INTELURGENCY_PATTERN

沒發現已知詐騙特徵,不代表一定安全;不確定請撥 165。

  1. 01

    只存加鹽雜湊,不存明碼門號。

  2. 02

    簡訊全文不存。

  3. 03

    回應不含換卡日期、電信業者、所在國家。

  4. 04

    只查商家自己會員的門號,不能任意查號。

接入方式

一個 API,或一行 script。

接法有 REST API、一行 script 的瀏覽器 SDK、WooCommerce 外掛與 Webhook。

REST

在換收款帳戶、大額轉帳、結帳之前,從你的伺服器呼叫 POST /v1/score,金鑰放在 X-API-Key 標頭,門號用國際格式。回應是 0–100 分、原因碼與建議動作。

cURL

export TRUSTLAYER_SECRET_KEY=sk_test_your_key   # secret 金鑰,只放伺服器端

curl -s https://trustlayer-platform-rho.vercel.app/v1/score \
  -H "X-API-Key: $TRUSTLAYER_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type": "TRANSACTION",
    "user": { "user_ref": "member-0007", "phone_number": "+886900000007" },
    "context": { "amount": 10000, "avg_amount_30d": 823.33, "is_new_device": true }
  }'

Node

const res = await fetch("https://trustlayer-platform-rho.vercel.app/v1/score", {
  method: "POST",
  headers: {
    "X-API-Key": process.env.TRUSTLAYER_SECRET_KEY, // sk_test_your_key,只放伺服器端
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    event_type: "TRANSACTION",
    user: { user_ref: "member-0007", phone_number: "+886900000007" },
    context: { amount: 10000, avg_amount_30d: 823.33, is_new_device: true },
  }),
});
const decision = await res.json();
console.log(decision.risk_score, decision.action); // 87 "BLOCK_REVIEW"

Python

import os

import httpx

r = httpx.post(
    "https://trustlayer-platform-rho.vercel.app/v1/score",
    headers={"X-API-Key": os.environ["TRUSTLAYER_SECRET_KEY"]},  # sk_test_your_key,只放伺服器端
    json={
        "event_type": "TRANSACTION",
        "user": {"user_ref": "member-0007", "phone_number": "+886900000007"},
        "context": {"amount": 10000, "avg_amount_30d": 823.33, "is_new_device": True},
    },
)
r.raise_for_status()
decision = r.json()
print(decision["risk_score"], decision["action"])  # 87 BLOCK_REVIEW

瀏覽器 SDK

一行 script,用可以公開的 publishable 金鑰(pk_)。瀏覽器只拿到建議動作與給用戶的訊息;分數與原因碼留在商家後台。

HTML

<script src="https://trustlayer-platform-rho.vercel.app/sdk/trustlayer.js" data-key="pk_test_your_key"></script>
<script>
  TrustLayer.check({ event: "LOGIN", phone: "0900000001" })
    .then((d) => console.log(d.action, d.message));
</script>

<!-- 或標在表單上:送出前先查,ALLOW、WARN 才送出 -->
<form data-trustlayer-event="LOGIN">
  <input name="phone" />
</form>

WooCommerce 外掛

付款前把訂單送去評分,再依建議處理;傳統結帳與區塊結帳都可以。安裝後填 API 網址與 secret 金鑰。

WooCommerce → 設定 → 整合 → TrustLayer

API 網址
https://trustlayer-platform-rho.vercel.app
API 金鑰
sk_test_your_key
模式

依建議處理,或只記錄

查詢門檻金額

低於門檻的訂單標「未查詢」,不當成安全

無法連線時

放行並註記「未評分」,或暫停出貨

外掛怎麼處理

放行ALLOW

正常結帳

提示WARN

正常結帳,訂單註記提醒

二次驗證STEP_UP

訂單改為「保留」,暫停出貨等人工確認(不用簡訊驗證碼)

攔截審核BLOCK_REVIEW

付款前攔下;顧客只看到一般訊息,不揭露原因

下載外掛(.zip)

Webhook

決策是 BLOCK_REVIEW(85–100 分)時,TrustLayer 送一則 decision.block_review 到你的 https 網址。先驗 X-TrustLayer-Signature 的 HMAC-SHA256 簽章,再相信內容。

通知內容

POST https://your-shop.example/webhooks/trustlayer
Content-Type: application/json
X-TrustLayer-Event: decision.block_review
X-TrustLayer-Signature: t=1793019912,v1=<HMAC-SHA256 hex>

{
  "type": "decision.block_review",
  "created_at": "2026-10-26T13:05:12.481920+00:00",
  "data": {
    "decision_id": "…",
    "risk_score": 87,
    "action": "BLOCK_REVIEW",
    "reasons": [ … ]
  }
}

Node 收件端

import { createHmac, timingSafeEqual } from "node:crypto";

// X-TrustLayer-Signature: t=<秒>,v1=<HMAC-SHA256(secret, "t.body")>
export async function POST(request) {
  const body = await request.text(); // 用原始內容驗簽,驗過才 JSON.parse
  const header = request.headers.get("x-trustlayer-signature") ?? "";
  const sig = Object.fromEntries(
    header.split(",").map((p) => [p.slice(0, p.indexOf("=")), p.slice(p.indexOf("=") + 1)]),
  );
  const t = Number(sig.t);
  if (!t || Math.abs(Date.now() / 1000 - t) > 300) {
    return new Response("stale timestamp", { status: 401 });
  }
  const expected = createHmac("sha256", process.env.TRUSTLAYER_WEBHOOK_SECRET) // whsec_your_secret
    .update(`${t}.${body}`)
    .digest();
  const given = Buffer.from(sig.v1 ?? "", "hex");
  if (given.length !== expected.length || !timingSafeEqual(given, expected)) {
    return new Response("bad signature", { status: 401 });
  }
  const event = JSON.parse(body); // event.type === "decision.block_review"
  // event.data:那次 /v1/score 的回應
  return Response.json({ received: true });
}
POST/v1/score示範主控台

請求

X-API-Key: sk_test_your_key

{"event_type": "TRANSACTION","user": { "user_ref": "member-0007", "phone_number": "+886900000007" },"context": { "amount": 10000, "avg_amount_30d": 823.33, "is_new_device": true }}

300 ms端到端 P95 目標(是目標,不是實測)

回應

200 OK87BLOCK_REVIEW
{"risk_score": 87,"action": "BLOCK_REVIEW","reasons": [{ "code": "CALL_STATE_CONCURRENT", "source": "TELECOM", "points": 35, "message": "交易當下門號正在通話中" },{ "code": "CALL_FORWARDING_ACTIVE", "source": "TELECOM", "points": 30, "message": "門號已開啟無條件來電轉接" },{ "code": "CONTEXT_ANOMALY", "source": "PLATFORM", "points": 22, "message": "首次使用的裝置、金額為近 30 日平均的 12.1 倍" }],"explanation": "風險分數 87(CRITICAL):交易當下門號正在通話中;門號已開啟無條件來電轉接;首次使用的裝置、金額為近 30 日平均的 12.1 倍。建議:攔截並送人工審核。","customer_message": "這次操作已暫停,將由客服人工審核,結果會另行通知您。","step_up_methods": [],"telecom_evidence": { "source": "CHT_SIMULATED", "is_simulated": true, "status": "COMPLETE" }}

示範:不會真的送出,重播 03 段陳阿姨的回應(節錄);電信訊號依公開 CAMARA 規格模擬中華電信。

引擎本機壓測 P95 約 7 ms(Mock 電信、不含電信往返)

三步上手

開始使用
  1. 1用 Google 登入用 Google 帳號登入商家後台。
  2. 2建立測試金鑰在後台的 API 金鑰頁建立;測試模式的決策跟正式資料分開。
  3. 3在電信模擬器試打一次替門號選一個電信情境(例如換過 SIM),再送一次,看分數與原因碼怎麼變。

商家後台

每一筆決策,都看得到原因。

每次評分都攤開在後台。上線前,先用測試金鑰和電信模擬器試一輪。

  • 儀表板
    商家後台的儀表板:評分次數、四種建議動作各幾次、原因碼分布、各電信訊號查了幾次,與最近的決策。
  • 決策紀錄
    決策紀錄:每筆評分的事件、分數與建議動作,右側展開一筆攔截待審的決策,列出原因碼、加分與電信證據。
  • 電信模擬器
    電信模擬器:用測試金鑰對一個示範門號試打一次評分,左邊是分數與原因,右邊是 API 的請求與回應。

左右滑動,看三個畫面

畫面為測試模式,資料來自情境測試;門號與會員代號都是虛構的。

  • 決策紀錄與原因

    每筆評分的分數、原因碼與電信證據都查得到;可以篩選、搜尋,也能回報事後結果。

  • 電信模擬器

    替測試門號切換換 SIM 卡、漫遊、來電轉接等情境,用測試金鑰試打一次就看到結果。

  • 情資測試

    評分時帶上交易對象的帳號、門號或網域,比對詐騙情資;情資單獨命中不會直接攔截。

  • 簡訊查詢

    貼上用戶收到的簡訊,查網址、電話與帳號,再看有沒有冒名、催促等特徵;全文不存。

    沒發現已知詐騙特徵,不代表一定安全;不確定請撥 165。

  • Webhook

    攔截待審的決策會送到你的系統,附 HMAC 簽章,收到就能驗證來源。

  • API 金鑰

    測試與正式金鑰分開,商家通過審核後,才能建立正式金鑰;撤銷後,用它的整合立刻失效。

開始使用

先用測試金鑰試一次。

  1. 01

    我是商家

    用 Google 登入,建立測試金鑰,在電信模擬器試打一次。

  2. 02

    我是開發者

    REST API、瀏覽器 SDK、WooCommerce 外掛與 Webhook 的範例都在接入方式;登入後可看接入指南。

  3. 03

    我想先看看

    八支情境說明影片。

常見問題

接之前,先看這幾題。

會不會擋到本人?

TrustLayer 回的是分數與建議動作,由商家決定怎麼處理:0–29 放行、30–59 提示、60–84 請本人再驗證一次、85–100 才建議攔截審核。拿不到的電信訊號記為 UNKNOWN,不會因此被當成詐騙。

拿不到電信訊號會怎樣?

記為 UNKNOWN:不當安全,也不當詐騙。

你們會存我的門號或簡訊嗎?

不存明碼門號,只存加鹽的雜湊;簡訊全文不存。回應只留訊號「是否異常」,不含換卡日期、電信業者、所在國家。而且只查商家自己會員的門號,不能任意查號。

分數怎麼算?AI 會不會亂扣分?

依電信訊號與平台行為算出 0–100 分,對照四個級距給建議動作,並附原因碼。AI 模型只能把分數調高,不能壓低;AI 只改寫說明文字,不影響分數。

電信訊號從哪裡來?

目前依公開 CAMARA 規格模擬中華電信,示範資料皆為虛構。TrustLayer 目前沒有與中華電信合作。拿不到的訊號一律記為 UNKNOWN,不當安全,也不當詐騙。

怎麼接?

REST API、一行 script 的瀏覽器 SDK、WooCommerce 外掛與 Webhook 都可以。先用 Google 登入、建立測試金鑰,在電信模擬器試打一次。