銀行卡與出金授權
本頁說明
講什麼：銀行卡狀態和認證如何影響出金、account_type 如何決定可用出金通道、BST 授權對出金的前提要求、首次出金認證流程、通道路由與銀行卡的關係、出金相關的銀行卡異常排查 適合誰：需要理解"用戶為什麼無法出金"的產品經理和運營 前置閱讀：出金方式總覽預計閱讀：5 分鐘 負責人：出金產品經理
核心要點：用戶能用哪種方式出金，取決於銀行卡的三個維度——status（卡是否生效）、verify（是否已認證）、account_type（是否有 BST 位）。BST 出金還額外要求 Mandate 狀態為 OPEN。理解這三道門檻，是排查"用戶無法出金"的關鍵。
快速跳轉 — 你可能想做的事：
- 用戶看不到 BST 出金選項？→ 出金通道與卡類型的關係
- 用戶首次出金被攔截？→ 卡認證與首次出金
- BST 出金不可用？→ BST 授權與出金
- 系統是怎麼選出金通道的？→ 通道路由與銀行卡
- 出金相關的銀行卡問題？→ 出金相關的銀行卡異常
出金的三道門檻
用戶發起出金前，系統依次檢查銀行卡的三個維度。任一不通過，出金都無法繼續：
| 門檻 | 檢查欄位 | 通過條件 | 不通過表現 |
|---|---|---|---|
| 1. 卡狀態 | status | = 1（已生效） | "銀行卡不存在"或無法選擇該卡 |
| 2. 卡認證 | verify | = 2（已認證）或非首次出金 | "銀行賬戶還未通過認證"，要求上傳憑證 |
| 3. 通道授權 | account_type + Mandate | BST 通道需含 BST 位 + OPEN | 不顯示 BST 選項，或 Confirm 步驟攔截 |
入金 vs 出金的銀行卡要求差異
入金對銀行卡要求較寬鬆——未認證的卡（verify=0）可以正常入金。 出金要求更嚴——首次出金到未認證卡時會被攔截，必須先完成認證。這是因為出金涉及資金流出，反洗錢合規要求確認收款賬戶屬於本人。
出金通道與卡類型的關係
銀行卡的 account_type 直接決定用戶可用的出金通道：
| account_type | 含義 | 可用出金方式 | 說明 |
|---|---|---|---|
| 1 | Regular（僅普通） | 網銀、FPS、CHATS、電匯等 | 綁卡默認狀態，不含 BST |
| 3 | Regular + BST | 上述 + 銀證出金 | 完成銀證簽約後獲得 |
| 5 | Regular + eDDA | 網銀、FPS、CHATS、電匯等 | eDDA 位對出金無影響（eDDA 僅用於入金） |
| 7 | 全能力 | 與 account_type=3 相同 | eDDA 位不增加出金能力 |
關鍵區別：對入金來說，account_type 的每一位都有意義（Regular / BST / eDDA 各自開啟不同入金通道）。但對出金來說，只有 BST 位（bit 1）有實質影響——eDDA 是代扣通道，只用於入金，出金走的是企業網銀通道（hase / hsbc），與 eDDA 授權無關。
出金通道的銀行卡要求
| 通道 | account_type 要求 | 額外要求 | 備註 |
|---|---|---|---|
auto_bs（銀證） | 含 BST 位（2/3/6/7） | Mandate = OPEN | 唯一的全自動通道 |
hsbc（匯豐網銀） | Regular 即可 | 無 | 運營操作企業網銀轉賬 |
hase（恒生網銀） | Regular 即可 | 無 | 運營操作企業網銀轉賬 |
boc_fps（中銀 FPS） | Regular 即可 | 無 | 半自動 |
cgb_fps_api（廣發 FPS） | Regular 即可 | 無 | 半自動 |
sc（渣打） | Regular 即可 | 無 | 半自動 |
tele_transfer（跨境電匯） | Regular 即可 | bank_swift 必填 | 非港銀行自動選此通道 |
chats_rtgs | Regular 即可 | 無 | 港內大額（≥100 萬） |
boc（中銀同行） | Regular 即可 | 無 | 人工操作 |
manual（工銀手工） | Regular 即可 | 無 | 人工操作 |
運營排查要點
用戶反饋"看不到 BST 出金選項"時，排查路徑：
- 查
bank_card.account_type——含 BST 位的值：2、3、6、7 - 查 Mandate 狀態——必須為 OPEN(2)
- 如果
account_type不含 BST 位 → 銀證簽約未完成，引導用戶完成簽約 - 如果 Mandate 不是 OPEN → 參考 BST 授權與出金
BST 授權與出金
BST（銀證轉賬）是出金中唯一的全自動通道。使用 BST 出金的前提是銀證授權狀態為 OPEN。
Mandate 狀態對出金的影響
| Mandate 狀態 | 含義 | 能否 BST 出金 | 運營關注點 |
|---|---|---|---|
| 0 CLOSE | 未授權 | 否 | 用戶需發起授權 |
| 1 PROCESSING | 授權中 | 否 | 等待銀行確認 |
| 2 OPEN | 已授權 | 是 | 正常狀態 |
| 3 WAITING | 等待首筆入金 | 否 | 線上開戶專用，入金成功後自動轉 OPEN |
| 4 FAIL | 授權失敗 | 否 | 檢查 reject_code |
| 5 CANCEL | 已取消 | 否 | 用戶可重新發起 |
只有 OPEN(2) 才能使用 BST 出金——這是排查"BST 出金不可用"的第一步。
三家 BST 銀行的出金差異
| 維度 | 招行 / 民生 | 天星 |
|---|---|---|
| 出金指令 | Socket 雙向鏈路實時推送 | REST API + 兩階段輪詢 |
| 到賬時效 | 秒級 | 快速輪詢 ~50 秒 + 兜底同步最長 2 小時 |
| CNH 出金 | 不走 BST（協議未覆蓋，留給運營手工選） | 支持（無限制） |
| 銀行發起出金 | 支持（用戶在銀行 App 操作轉出） | 支持 |
| 市場粒度 | 每個市場單獨簽約 | 一次授權自動綁定 3 市場 |
CNH 限制：招行/民生不走 BST
這是一個重要的邊界條件：招行/民生 + 離岸人民幣 CNH = 不走 BST。
原因：招行和民生的銀證接口協議層面未覆蓋 CNH 幣種的自動轉賬。系統在通道路由時檢測到這個組合後，會將 method 設為 null，留給運營手動選擇其他通道（通常是網銀或 FPS）。
天星不受此限制——天星的銀證接口支持 CNH。
Confirm 步驟的授權校驗
出金審批的 Confirm 步驟會強制校驗 BST 授權狀態：
Confirm 步驟邏輯：
if method == auto_bs:
檢查 Mandate 狀態
if status ≠ OPEN → 拒絕推進，提示"銀證授權狀態異常"
if status == OPEN → 通過，推進到 Remittance如果 Confirm 卡住且提示授權異常 → 排查 Mandate 狀態，詳見 出金排障 § 銀證授權異常。
完整 BST 授權技術細節 → 銀行卡與授權 § BST 銀證授權 BST 通道執行細節 → 通道執行手冊 § BST
卡認證與首次出金
銀行卡認證（verify）是出金獨有的門檻——入金不檢查認證狀態，但首次出金到未認證卡時會被攔截。
認證狀態
| verify 值 | 含義 | 對出金的影響 |
|---|---|---|
| 0 | 未認證 | 首次出金被攔截，要求上傳憑證 |
| 1 | 認證中 | 出金等待認證完成 |
| 2 | 已認證 | 無限制 |
自動認證（不需要用戶操作）
以下場景會自動將卡標記為已認證（verify=2），用戶無需額外操作：
| 場景 | 來源代碼 | 原理 |
|---|---|---|
| BST 銀證簽約成功 | bst | 銀行側已驗證身份 |
| eDDA 授權成功 | edda | 銀行側已驗證身份 |
| 香港線上開戶入金成功 | hk_online | 入金流水已驗證卡號歸屬 |
實際意義：如果用戶先通過 BST 或 eDDA 入金，卡已自動認證，出金時不會被攔截。只有用戶通過網銀/FPS/ATM 等方式入金後、首次向該卡出金時，才會觸發手動認證。
首次出金認證流程
為什麼要認證
反洗錢合規要求確認收款賬戶屬於用戶本人。出金意味著資金從受監管的證券帳戶流出，所以合規門檻比入金更高。
通道路由與銀行卡
系統通過 calcMethod() 根據銀行卡屬性自動選擇出金通道：
路由決策使用了銀行卡的以下欄位：
| 欄位 | 路由中的作用 |
|---|---|
account_type | 判斷是否含 BST 位 → 決定能否走銀證通道 |
bank_code | 判斷是招行/民生/天星中的哪家 → 決定 CNH 限制 |
area | 判斷銀行是否在香港 → 非港銀行走跨境電匯 |
bank_swift | 跨境電匯必填，缺失會導致出金失敗 |
currency_type | 卡必須支持出金幣種，否則拒絕 |
method = null 時運營怎麼選
當系統無法自動確定通道時，運營在 Confirm 步驟手動選擇，優先級：同行轉賬 > FPS > CHATS/RTGS > 支票。詳見 出金方式總覽 § method = null 時的 fall-through 邏輯。
其他銀行卡限制
除了上述三道門檻，出金還有一些銀行卡相關的限制條件：
| 限制 | 檢查欄位 | 表現 | 說明 |
|---|---|---|---|
| 大陸銀行卡 | area = cn | "不支持提取到中國大陸銀行賬戶" | 系統直接攔截 |
| A 股通 CNH | 幣種 + 銀行地區 | "CNH 僅支持提取到香港銀行" | 僅 CNH + 非港銀行 |
| Payoneer 賬戶 | 銀行類型 | "Payoneer 賬戶不支持出金" | 業務限制 |
| 第三方卡 | third_party_flag = 1 | 出金受額外限制 | 非本人卡需額外審核 |
| 幣種不匹配 | currency_type 位圖 | "銀行賬戶幣種與出金幣種不一致" | 如 currency_type=1 的卡不支持 USD 出金 |
| SWIFT 缺失 | bank_swift 為空 | 跨境電匯失敗 | 歷史數據問題，運營補充 |
| 在線開戶未入金 | status = 0 | "綁卡須轉賬 ≥ 10,000 港元" | 待審核卡不可出金 |
出金相關的銀行卡異常
以下是與出金直接相關的銀行卡異常場景——完整的銀行卡異常列表參見 銀行卡與授權 § 異常場景。
| # | 場景 | 表現 | 排查步驟 | 運營處理 |
|---|---|---|---|---|
| 1 | BST 出金不可用 | 用戶看不到銀證出金選項 | ① 查 account_type 是否含 BST 位（2/3/6/7）② 查 Mandate 狀態是否為 OPEN(2) | account_type 缺位 → 簽約未完成；Mandate 非 OPEN → 引導重新授權 |
| 2 | 首次出金被攔截 | 提示"銀行賬戶還未通過認證" | ① 查 verify 欄位 ② 查是否有待審核憑證 | 引導用戶上傳銀行對賬單；或運營 ManualVerify |
| 3 | 待審核卡無法出金 | 在線開戶卡不可用 | ① 查 status 是否為 0 ② 查首筆入金是否成功 ③ 查 TakeEffect 是否執行 | 入金已成功但卡未生效 → 手動 BatchTakeEffect |
| 4 | Confirm 卡住 | BST 出金停在 Confirm 步驟 | 查 Mandate 狀態——不是 OPEN 則 Confirm 無法推進 | 引導用戶重新完成銀證授權 |
| 5 | 幣種不支持 | 出金時提示幣種不匹配 | 查 currency_type 位圖（HKD=1, USD=2, CNH=4） | 引導用戶綁定支持該幣種的銀行卡 |
| 6 | SWIFT 缺失 | 跨境電匯出金失敗 | 查 bank_swift 是否為空 | 運營 UpdateBankCard 補充 SWIFT |
| 7 | 第三方卡限制 | third_party_flag=1 出金受限 | 查 third_party_flag 是否誤標記 | 誤標記 → UpdateThirdPartyFlag 修正 |
常見誤解
| 誤解 | 事實 |
|---|---|
| "eDDA 授權了就能用 eDDA 出金" | eDDA/eDDI 只用於入金（從用戶銀行扣款）。出金走的是企業網銀通道（hase / hsbc），與 eDDA 授權無關。account_type 的 eDDA 位不增加任何出金能力 |
| "綁卡就能出金" | 綁卡只是第一步。首次出金到該卡還需要通過認證（verify=2）；走 BST 通道還需要銀證授權為 OPEN。三道門檻缺一不可 |
| "BST 簽約了就一定走 BST" | 不一定。招行/民生 + CNH 出金即使有 BST 簽約也不走 BST（協議未覆蓋），系統會將 method 設為 null 由運營手動選通道 |
| "卡認證失敗 = 出金被拒" | 不是同一件事。認證是針對銀行卡本身（"這張卡是不是你的"），只在首次出金到該卡時檢查。出金被拒可能有很多其他原因（餘額不足、風控攔截等） |
讀完之後
| 我想... | 去看 |
|---|---|
| 瞭解出金的完整生命週期 | 出金生命週期 |
| 看 BST 通道的執行細節 | 通道執行手冊 § BST |
| 瞭解入金側的綁卡與授權 | 銀行卡綁定與入金授權 |
| 看銀行卡的完整數據模型 | 銀行卡與授權 |
| 用戶無法出金怎麼排查 | 出金排障 § 用戶無法發起出金 |
| BST 授權出了問題 | 出金排障 § 銀證授權異常 |