銀行卡與授權
本頁說明
講什麼：銀行卡生命週期（狀態與認證）、數據模型核心字段、幣種與帳戶類型位圖、卡-通道能力矩陣、綁卡/解綁規則與系統流程、BST 銀證授權模型（招行/民生 vs 天星 Mandate）、eDDA 授權流程與擴展字段、線上開戶三合一流程、銀行卡 API 概覽，以及常見異常場景與排查指南 適合誰：需要了解銀行卡管理業務規則的產品經理和運營人員 前置閱讀：新人導讀預計閱讀：12 分鐘 負責人：入金產品經理
銀行卡生命週期
卡狀態
| 狀態碼 | 名稱 | 含義 | 典型場景 | 運營關注點 |
|---|---|---|---|---|
| 0 | 待審核 | 卡已添加但尚未生效，不可用於出入金 | 線上開戶添加卡，等待首筆入金驗證 | 若長時間停留（>24 小時），檢查用戶是否完成首筆入金 |
| 1 | 已生效 | 卡正常可用 | 普通綁卡成功；或在線開戶完成首筆入金後生效 | 正常狀態，可用於所有出入金操作 |
| 2 | 已刪除 | 卡已停用/刪除，不可恢復 | 用戶解綁或運營刪除 | 終態。用戶需重新綁卡，BST/eDDA 授權同時作廢 |
卡認證
認證是對銀行卡持有人身份的驗證——與「狀態」獨立，一張已生效的卡可以是未認證的。
| 認證碼 | 含義 | 觸發場景 | 對出入金的影響 |
|---|---|---|---|
| 0 | 未認證 | 預設狀態 | 入金不受影響；首次出金到該卡會被攔截 |
| 1 | 認證中 | 已提交憑證，等待審核 | 入金不受影響；出金等待認證完成 |
| 2 | 已認證 | 已通過認證 | 無限制 |
認證來源與觸發條件：
| 來源 | 代碼 | 觸發場景 | 認證方式 | 需用戶操作？ |
|---|---|---|---|---|
| 香港在線開戶入金 | hk_online | 用戶通過線上開戶入金 | 入金成功自動認證 | 否（自動） |
| 首次出金 | withdraw | 用戶首次向該卡出金 | 需上傳銀行對帳單/轉帳截圖 | 是 |
| 綁定銀證 | bst | 完成 BST 簽約/Mandate 授權 | 銀行側已驗證身份，自動認證 | 否（自動） |
| 綁定 eDDA | edda | 完成 eDDA 授權 | 銀行側已驗證身份，自動認證 | 否（自動） |
| 人工驗證 | manual | 運營在 CRM 手動通過 | 運營審核憑證後標記 | 否（運營操作） |
認證流程（首次出金場景）
首次出金到未認證卡是最常見的認證觸發場景：
生命週期流轉
在線開戶的「待審核」卡：通過 CheckSave 接口創建（operation=1 開戶中 / operation=0 入金中）。只有完成首筆入金後，系統調用 TakeEffect 將卡從待審核→已生效。
存儲位置與數據表
銀行卡數據存儲在 web_account 數據庫，由 bankcard_service/（PHP，端口 20005）管理。
| 表名 | 存什麼 | 關鍵字段 | 說明 |
|---|---|---|---|
bank_card | 銀行卡主記錄 | id, uid, number, status, verify, account_type | 一行 = 一張銀行卡 |
bank_card_operation_log | 操作日誌 | card_id, operation, operator, created_at | 每次綁卡/解綁/狀態變更都有記錄，不可刪除 |
bank_card_certificate | 認證憑證 | card_id, file_url, status | 用戶上傳的銀行對帳單/轉帳截圖 |
bank_info | 預置銀行資訊 | id, bank_name, bank_code, swift_code | 銀行名稱/代碼/SWIFT/Logo 等（唯讀） |
bank_card_asb_bst | 天星銀證擴展 | card_id, mandate_id, status | 天星 Mandate 授權資訊 |
bank_card_edda | eDDA 擴展（恒生） | card_id, limit_amount, status | 恒生 eDDA 授權資訊 |
bank_card_hsbc_edda | eDDA 擴展（匯豐） | card_id, mandate_identification, status | 匯豐 eDDA 授權資訊 |
運營排查技巧：出入金問題排查時，先在 bank_card 表確認卡狀態（status）和認證（verify），再根據通道類型查對應擴展表。
銀行卡數據模型
核心字段
| 字段 | 業務含義 | 示例 | 運營常用場景 |
|---|---|---|---|
id | 卡唯一 ID | 12345 | CRM 查詢銀行卡的主鍵 |
uid | 用戶 ID（牛牛號） | 800001234 | 關聯到用戶 |
number | 銀行帳號 | 012-345-678-901 | 匹配銀行流水、核對卡號 |
bank_id | 預置銀行 ID（0=自定義銀行） | 23 | bank_id > 0 使用預置資訊；= 0 需手動填寫 |
bank_code | 銀行內部代碼 | CMBHK | 系統內部路由出入金通道 |
bank_swift | SWIFT 代碼（HK 卡必填） | CMBCHKHH | 國際匯款必需 |
area | 卡所屬地區 | hk / cn / us / other | 不同地區有不同的必填字段要求 |
currency_type | 幣種位圖（見下） | 7 | 決定該卡支持哪些幣種的出入金 |
account_type | 帳戶類型位圖（見下） | 2 | 決定該卡支持哪些出入金通道 |
status | 卡狀態：0/1/2 | 1 | 0=待審核、1=已生效、2=已刪除 |
verify | 認證狀態：0/1/2 | 2 | 0=未認證、1=認證中、2=已認證 |
third_party_flag | 第三方卡標記 | 0 | 0=本人卡、1=第三方卡（出金有額外限制） |
address_status | 地址狀態 | 0 | 0=正常、1=異常（可能影響出金） |
不同地區卡的必填字段
| 地區 | area 值 | 必填字段 | 可選字段 | 典型銀行 |
|---|---|---|---|---|
| 香港 | hk | bank_swift, bank_name | bank_address | 匯豐、恒生、中銀、招行(HK)、民生 |
| 大陸 | cn | opening_address（開戶行地址） | bank_province, bank_city | 招商、工商、建設 |
| 美國 | us | routing_number | bank_address | Bank of America, Chase |
| 其他 | other | bank_name | bank_swift, bank_address | 新加坡、英國等海外銀行 |
幣種位圖（currency_type）
系統用位圖表示一張卡支持哪些幣種——每個 bit 代表一種貨幣：
| Bit | 值 | 幣種 | 說明 |
|---|---|---|---|
| 0 | 1 | HKD（港幣） | 港股交易、港幣出入金 |
| 1 | 2 | USD（美元） | 美股交易、美元出入金 |
| 2 | 4 | CNH（離岸人民幣） | A 股通交易、人民幣出入金 |
組合示例：
| currency_type | 二進制 | 支持幣種 | 常見於 |
|---|---|---|---|
| 1 | 001 | 僅 HKD | 港幣單幣種卡 |
| 3 | 011 | HKD + USD | 雙幣種卡 |
| 7 | 111 | HKD + USD + CNH | 最常見——大部分香港銀行卡 |
運營技巧：如果用戶反饋「某個幣種無法入金/出金」，先檢查銀行卡的 currency_type 是否包含對應幣種位。例如 currency_type = 3 不支持 CNH 出入金。
帳戶類型位圖（account_type）
同樣用位圖表示卡支持哪些轉帳能力：
| Bit | 值 | 類型 | 含義 | 如何獲得 |
|---|---|---|---|---|
| 0 | 1 | Regular | 普通銀行卡，支持網銀/FPS 等手動轉帳方式 | 綁卡時自動賦予 |
| 1 | 2 | BST | 已綁定銀證通道（招行/民生/天星） | 完成銀證簽約後系統自動加上 |
| 2 | 4 | eDDA | 已授權 eDDA 代扣（恒生/匯豐） | 完成 eDDA 授權後系統自動加上 |
組合示例：
| account_type | 二進制 | 含義 | 可用通道 |
|---|---|---|---|
| 1 | 001 | 僅普通 | 網銀入金、網銀/FPS 出金 |
| 3 | 011 | 普通 + BST | 上述 + BST 入金/出金 |
| 5 | 101 | 普通 + eDDA | 上述 + eDDA 代扣入金 |
| 7 | 111 | 全能力 | 所有出入金通道 |
帳戶類型是自動設置的
account_type 不是用戶選擇的——它由綁卡/授權流程自動設置。用戶完成銀證簽約後，卡的 account_type 自動加上 BST 位（|= 2）；完成 eDDA 授權後自動加上 eDDA 位（|= 4）。解綁時相應位會被清除（&= ~2 或 &= ~4）。
運營快速判斷（不需要做位運算）：
- 含 BST 位的值：2、3、6、7 → 可使用銀證通道
- 含 eDDA 位的值：4、5、6、7 → 可使用 eDDA 代扣
- 僅 Regular（無 BST）：1、5 → 沒有銀證通道
- 僅 Regular（無 eDDA）：1、2、3 → 沒有 eDDA 代扣
運營排查：用戶反饋「看不到 BST/eDDA 入金選項」時，檢查 account_type 的值是否在上述列表中。
轉帳方式（methods）
每張卡攜帶一個轉帳方式列表，標明可用的出入金渠道：
| method 值 | 類型 | 含義 | 對應銀行 | 對應 account_type 位 |
|---|---|---|---|---|
normal | 普通 | 普通轉帳（網銀/FPS/ATM 等） | 所有銀行 | bit 0 (Regular) |
bst_cmbhk | BST | 招行銀證 | 招商銀行（香港） | bit 1 (BST) |
bst_cmbchk | BST | 民生銀證 | 民生銀行 | bit 1 (BST) |
bst_asb | BST | 天星銀證 | 天星銀行 | bit 1 (BST) |
edda_hase | eDDA | 恒生 eDDA 代扣 | 恒生銀行 | bit 2 (eDDA) |
edda_hsbc | eDDA | 匯豐 eDDA 代扣 | 匯豐銀行 | bit 2 (eDDA) |
卡-通道能力矩陣
銀行卡的 account_type 決定了哪些出入金通道可用：
| 帳戶類型 | 網銀入金 | BST 入金 | eDDA 入金 | BST 出金 | 網銀出金 | FPS 出金 |
|---|---|---|---|---|---|---|
| Regular (1) | ✓ | — | — | — | ✓ | ✓ |
| BST (2) | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| eDDA (4) | ✓ | — | ✓ | — | ✓ | ✓ |
| BST + eDDA (6) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
通道過濾邏輯
用戶可以綁定多張不同類型的卡。發起出入金時，系統根據選中卡的 account_type 和 methods 列表過濾可用的入金方式或出金通道。
App 端顯示規則：
- 用戶選了一張 Regular 卡 → App 只顯示「網銀入金」，不顯示 BST/eDDA 選項
- 用戶選了一張 BST 卡 → App 顯示「網銀入金」和「銀證入金」兩個選項
- 用戶選了一張 eDDA 卡 → App 顯示「網銀入金」和「eDDA 代扣入金」兩個選項
出金端顯示規則同理：根據卡的 account_type 決定顯示哪些出金通道按鈕。
綁卡 / 解綁規則
綁卡規則
| 規則 | 說明 | 違反時表現 |
|---|---|---|
| HK 卡必須有 SWIFT | 香港銀行卡綁卡時 bank_swift 為必填（「其他銀行」除外） | 綁卡接口返回參數校驗錯誤 |
| 大陸卡必須有開戶地址 | area = cn 時 opening_address 為必填 | 同上 |
| 美國卡必須有 routing number | area = us 時 routing_number 為必填 | 同上 |
| 卡號唯一性 | 同一 uid + number 組合不可重複綁定 | 提示「該卡已綁定」 |
| 預置銀行優先 | bank_id > 0 時使用預置銀行資訊（名稱/代碼/SWIFT）；bank_id = 0 需手動填寫 | 自定義銀行需用戶自行確認資訊準確性 |
| 在線開戶卡 | 通過 CheckSave 創建，status = 0（待審核），首筆入金成功後 → status = 1 | 待審核期間不可用於出入金 |
| 已刪除卡可重新綁定 | 同一 uid + number，若舊卡 status=2，可創建新的綁卡記錄 | 新卡是全新記錄（新 id），舊卡的 BST/eDDA 授權不會繼承 |
綁卡系統流程
解綁規則
| 場景 | 操作步驟 | 前置條件 | 運營注意 |
|---|---|---|---|
| 普通卡解綁 | 設 status = 2 | 無進行中的出入金 | 確認無待處理的 Procedure |
| BST 卡解綁 | ① 取消銀證簽約（CancelBst）→ ② account_type &= ~2 → ③ 設 status = 2 | 招行/民生需銀行端解除簽約；天星需取消 Mandate | BST 簽約作廢後，銀證通道不可用。需先完成未結出金 |
| eDDA 卡解綁 | ① 取消 eDDA 授權 → ② account_type &= ~4 → ③ 設 status = 2 | 恒生/匯豐 eDDA 授權需先失效 | eDDA 代扣通道不可用 |
| BST + eDDA 卡解綁 | 按以上兩步分別取消，再刪卡 | 兩種授權都需先失效 | 全部通道授權作廢 |
解綁不可逆
status = 2 是終態——被刪除的卡無法恢復，用戶需要重新綁卡。BST/eDDA 解綁意味著對應的銀證簽約或代扣授權也同時作廢。
用戶常見問題：「我不小心解綁了銀行卡怎麼辦？」——只能重新綁卡。如果是 BST 卡，還需要重新走銀證簽約流程。如果是 eDDA 卡，需要重新完成 eDDA 授權。
運營注意：解綁前必須檢查該卡是否有進行中的出入金 Procedure。有進行中的出金（特別是 pending(transfer_manual) 狀態）時不要解綁——等出金完成後再處理。
BST 銀證授權與銀行卡
在 BST 銀證通道中，銀行卡管理和銀證授權（Mandate）緊密綁定——用戶不能只綁卡不授權，也不能只授權不綁卡。
授權模型差異
| 維度 | 招行 / 民生 | 天星 |
|---|---|---|
| 核心標識 | 銀行卡號 | mandate_id |
| 綁定流程 | 銀行端完成銀證簽約 → 通知 moomoo | moomoo 端發起 Mandate 授權 → 銀行確認 |
| 簽約發起方 | 只能銀行端發起 | moomoo 可主動發起 |
| 解綁影響 | 解除簽約 = 不可使用 BST | 取消 Mandate = 不可使用 BST |
| 多市場 | 每個市場需單獨簽約 | 一次授權自動映射 3 個市場（HK/US/HKCC） |
| 通信方式 | SM2 Socket 雙向鏈路（實時推送） | REST API（需輪詢結果） |
| 授權狀態 | 2 種（開通/未開通） | 6 種（含 WAITING、FAIL、CANCEL） |
| 自動認證 | 簽約成功 → 卡自動認證（verify=2） | 授權成功 → 卡自動認證（verify=2） |
招行/民生銀證簽約流程
招行和民生的銀證簽約由銀行端發起，moomoo 被動接收：
招行 vs 民生的差異：
| 維度 | 招行 | 民生 |
|---|---|---|
| 服務名 | cmb_stock_trans | ms_stock_bank_transaction |
| 市場粒度 | 每個市場單獨簽約（HK/US/HKCC 分別操作） | 每個市場單獨簽約 |
| 出金收款人 | 中文名 | 英文名（payee_name 必須英文） |
| 流水號字段 | bank_tx_seq | OrgRefNo |
| 異常恢復 | sync_bst_data_helper 補償 | 自動重連 + 重拉 |
天星 Mandate 詳解
天星以 mandate_id 而非銀行卡號作為銀證關係的核心標識。意味著：
- 入金：通過 mandate_id 關聯到對應的銀行卡和用戶
- 出金：通過 mandate_id 確認授權有效後才能發送出金指令
- 查詢：所有銀證相關的狀態查詢都以 mandate_id 為主鍵
3 市場自動映射：用戶完成一次 Mandate 授權後，系統自動為 HK（港股）、US（美股）、HKCC（港股通）三個市場創建銀證綁定。用戶在 moomoo 做港股、美股、A 股交易時，入金出金都走同一個銀證通道。
天星授權流程（用戶視角）
| 步驟 | 用戶操作 | 用戶感知 | 預計耗時 |
|---|---|---|---|
| 1 | 在 moomoo 選擇天星銀行入金 | 顯示天星銀證入金選項 | — |
| 2 | 點擊「授權簽約」 | 跳轉到天星銀行授權頁面 | — |
| 3 | 在天星頁面確認授權 | 輸入銀行密碼/驗證碼 | 1-2 分鐘 |
| 4 | 授權完成，返回 moomoo | 顯示「授權成功」 | 秒級 |
| 5 | 可以開始入金/出金 | BST 通道可用 | — |
天星授權流程（系統視角）
天星銀證卡擴展字段（BankCardAsbBst）
| 字段 | 含義 | 運營場景 |
|---|---|---|
account_name | 客戶姓名 | 核對持卡人身份 |
account_number | 客戶銀行帳號 | 核對銀行帳號 |
mandate_id | 銀證授權 ID | 核心標識——查詢銀證狀態、排查問題的主鍵 |
status | 授權狀態（見下表） | 判斷 BST 通道是否可用 |
reject_code | 授權失敗拒絕碼 | 排查授權失敗原因 |
created_at | 授權創建時間 | 確認授權時間線 |
updated_at | 最後更新時間 | 確認狀態變更時間 |
Mandate 狀態碼：
| 狀態碼 | 含義 | 能否出入金 | 運營關注點 |
|---|---|---|---|
| 0 | 未授權（CLOSE） | 否 | 初始狀態或已取消。用戶需重新發起授權 |
| 1 | 授權中（PROCESSING） | 否 | 等待銀行確認，通常秒級~分鐘級完成。若超過 5 分鐘仍在 PROCESSING → 檢查 airstar_service 日誌 |
| 2 | 已授權（OPEN） | 是 | 正常狀態，BST 通道可用 |
| 3 | 等待中（WAITING） | 否 | 在線開戶專用——等待首筆入金。入金成功後自動 → OPEN(2) |
| 4 | 授權失敗（FAIL） | 否 | 檢查 reject_code 了解失敗原因。常見：銀行側風控攔截、用戶資訊不匹配 |
| 5 | 授權取消（CANCEL） | 否 | 用戶或運營主動取消。用戶可重新發起授權 |
只有 status=2（OPEN）才可出入金——這是運營排查「BST 無法使用」的第一步。
詳細的 Mandate 狀態機 → 內銀系 BST 總覽 § 銀證授權
eDDA 授權與銀行卡
入金視角的 eDDA 授權說明（授權如何開啟代扣入金通道）→ 銀行卡綁定與入金授權 § eDDA
eDDA 授權流程
恒生和匯豐的 eDDA 授權流程類似但有細微差異：
eDDA 卡擴展字段
恒生和匯豐的 eDDA 授權資訊綁定在銀行卡上：
| 字段 | 含義 | 恒生 | 匯豐 | 運營場景 |
|---|---|---|---|---|
limit_amount | 單筆/週期額度上限 | 有 | 有 | 用戶反饋「代扣失敗」時檢查是否超限 |
limit_periodicity | 額度週期 | 有 | 有 | Y=年 / H=半年 / Q=季度 / M=月 / P=每筆 |
expiry_date | 有效期 | 有 | 有 | 9999999=長期有效；檢查是否過期 |
status | 啟用狀態 | 0=失效 / 2=啟用 | 0=失效 / 1=授權中 / 2=啟用 | status=2 才可代扣 |
mandate_identification | 銀行側唯一標識 | 無 | 有 | 與匯豐核對時使用 |
恒生 vs 匯豐 eDDA 差異：
| 維度 | 恒生 | 匯豐 |
|---|---|---|
| 服務名 | sba_hase_eddi | sba_hsbc_eddi |
| 授權確認 | 同步返回（秒級） | 異步 SFTP 報表（T+0~T+1） |
| 狀態值 | 0/2 兩種 | 0/1/2 三種（多一個「授權中」） |
| 報表下載 | 不需要 | 需 hsbc_edda_report 服務定時拉取 |
| 額度修改 | 需重新授權 | 需重新授權 |
eDDA 只用於入金
eDDA/eDDI 是代扣通道，只能用於入金（從用戶銀行帳戶扣款到證券帳戶）。出金不走 eDDA——恒生/匯豐的出金走企業網銀通道（hase / hsbc），由運營在銀行網銀完成人工轉帳。
銀行卡 API 概覽
銀行卡服務對外暴露的核心接口——對應 CRM 和 App 中的操作：
面向 App 的接口
| 接口 | 觸發場景 | 效果 | 說明 |
|---|---|---|---|
AddBankCard | 用戶在 App 添加銀行卡 | 創建 bank_card 記錄，status=1 | 含參數校驗（SWIFT/地址/唯一性） |
GetBankCardList | 用戶查看銀行卡列表 | 返回 status≠2 的所有卡 | 含 methods 列表，供前端顯示可用通道 |
DeleteBankCard | 用戶解綁銀行卡 | status → 2（已刪除） | 會先檢查無進行中的出入金 |
CheckSave | 在線開戶流程添加卡 | 創建 bank_card 記錄，status=0（待審核） | operation=1 開戶中 / operation=0 入金中 |
TakeEffect | 在線開戶首筆入金成功 | status 0→1（待審核→已生效） | 由入金服務自動調用 |
面向 CRM 的接口
| 接口 | 運營操作 | 效果 | 使用場景 |
|---|---|---|---|
GetBankCardInfo | 查看銀行卡詳情 | 返回卡全部字段 + 擴展資訊 | 排查時獲取完整卡資訊 |
UpdateBankCard | 修改銀行卡資訊 | 更新指定字段 | 修正錯誤的 SWIFT/地址等 |
ManualVerify | 手動通過認證 | verify → 2 | 運營審核憑證後標記認證 |
UpdateThirdPartyFlag | 修改第三方卡標記 | third_party_flag 更新 | 誤標記時修正 |
BatchTakeEffect | 批量生效待審核卡 | 多張卡 status 0→1 | 在線開戶批量處理 |
銀行卡異常場景
| # | 場景 | 表現 | 可能原因 | 排查步驟 | 運營處理 |
|---|---|---|---|---|---|
| 1 | BST 無法使用 | 用戶反饋銀證入金/出金不可用 | Mandate 不是 OPEN 狀態 | ① 查 bank_card_asb_bst.status 是否為 2(OPEN) ② 查 account_type 是否為 2/3/6/7（含 BST 位） | 不是 OPEN → 引導重新授權 |
| 2 | eDDA 代扣失敗 | 入金時提示代扣失敗 | eDDA 未啟用或額度超限 | ① 查 eDDA status 是否為 2 ② 查 limit_amount 是否超限 ③ 查 expiry_date 是否過期 | 未啟用 → 重新授權；超限 → 等待額度重置或提高額度 |
| 3 | 綁卡後通道未出現 | 用戶綁卡後 App 不顯示 BST/eDDA 選項 | account_type 未正確設置 | ① 查 account_type 值：BST 需為 2/3/6/7，eDDA 需為 4/5/6/7 ② 查 methods 列表 | account_type 缺失 → 檢查授權流程是否完成 |
| 4 | 在線開戶卡無法使用 | 待審核卡不可出入金 | 首筆入金未完成 | ① 查 status 是否為 0 ② 查首筆入金是否成功 ③ 查 TakeEffect 是否執行 | 入金已成功但卡未生效 → 手動 BatchTakeEffect |
| 5 | 認證失敗影響出金 | 首次出金到未認證卡被攔截 | 卡未認證（verify=0） | ① 查 verify 字段 ② 查是否有待審核的憑證 | 引導用戶上傳銀行對帳單；或運營 ManualVerify |
| 6 | 第三方卡限制 | third_party_flag=1 的卡出金受限 | 系統判定為非本人卡 | ① 查 third_party_flag ② 確認是否確實是第三方卡 | 誤標記 → UpdateThirdPartyFlag 修正 |
| 7 | SWIFT 缺失導致出金失敗 | 出金時銀行報錯 | HK 卡綁卡時未填 SWIFT（歷史數據） | ① 查 bank_swift 是否為空 | 運營 UpdateBankCard 補充 SWIFT |
| 8 | 幣種不支持 | 用戶選擇的幣種無法入金/出金 | currency_type 不含對應幣種 | ① 查 currency_type 位圖 | 引導用戶綁定支持該幣種的銀行卡 |
線上開戶
線上開戶的入金視角（含用戶旅程和異常處理）→ 銀行卡綁定與入金授權 § 天星線上開戶三合一
天星三合一流程
天星銀行支持線上開戶——新客戶可以在 moomoo App 內一站式完成從零到可交易的全流程：
| 步驟 | 動作 | 說明 | 涉及系統操作 | 數據變更 |
|---|---|---|---|---|
| 1 | 開立證券帳戶 | 完成 KYC 身份驗證 | 帳戶系統創建交易帳戶 | — |
| 2 | Mandate 授權 | 授權天星進行銀證轉帳 | CreateAuth → 銀行確認 | BankCardAsbBst.status = 3（WAITING） bank_card.status = 0（待審核） |
| 3 | 首筆入金 | 完成首筆入金到證券帳戶 | 入金成功 → TakeEffect | bank_card.status 0→1（已生效） BankCardAsbBst.status 3→2（OPEN） |
價值：傳統流程需要用戶在多個系統間切換（moomoo 開戶 → 去銀行櫃台或網銀簽約 → 回 moomoo 入金），三合一流程把這三步壓縮到一個連貫的 App 內流程中，大幅降低新客流失率。
線上開戶 vs 常規開通
| 維度 | 線上開戶（新用戶） | 常規開通（已有天星帳戶） |
|---|---|---|
| 前提條件 | 無需天星銀行帳戶 | 必須已有天星銀行帳戶 |
| 操作位置 | 全程在 moomoo App 內 | moomoo App 發起，可能需銀行端確認 |
| 流程 | 開戶 → 簽約 → 首次入金，三步合一 | 簽約 → 入金，兩步 |
| 銀行卡初始狀態 | status = 0（待審核） | status = 1（已生效） |
| Mandate 初始狀態 | status = 3（WAITING） | status = 2（OPEN） |
| 最低入金 | 有要求（見下表） | 無最低限制 |
| 獲客價值 | 高——降低新客入門門檻 | 中——僅對已有天星客戶 |
首筆入金限制
線上開戶的首筆入金有最低金額要求，高於普通入金：
| 幣種 | 線上開戶最低入金 | 普通入金最低 | 不滿足時表現 |
|---|---|---|---|
| HKD | 10,000 | 無限制 | App 提示「首次入金需 ≥ 10,000 HKD」 |
| USD | 1,500 | 無限制 | App 提示「首次入金需 ≥ 1,500 USD」 |
| CNH | 10,000 | 無限制 | App 提示「首次入金需 ≥ 10,000 CNH」 |
目的是確保新客戶有足夠資金進行交易，避免「只開戶不交易」的無效轉化。
線上開戶用戶旅程
線上開戶異常處理
| # | 異常場景 | 卡在哪一步 | 數據狀態 | 運營處理 |
|---|---|---|---|---|
| 1 | 開戶成功但授權失敗 | Mandate 授權 | bank_card.status=0, BankCardAsbBst.status=4(FAIL) | 引導用戶重新發起授權（不需要重新開戶） |
| 2 | 授權成功但入金失敗 | 首筆入金 | bank_card.status=0, BankCardAsbBst.status=3(WAITING) | 引導用戶重新發起入金（滿足最低金額） |
| 3 | 入金成功但卡未生效 | TakeEffect | bank_card.status=0（應為 1） | 手動 BatchTakeEffect 或檢查 TakeEffect 接口 |
| 4 | 長時間停在待審核 | 用戶未完成入金 | bank_card.status=0, BankCardAsbBst.status=3 | 聯繫用戶提醒完成首筆入金 |
僅天星支持
招行和民生不支持線上開戶三合一流程——銀證簽約需要用戶在銀行端完成。線上開戶是天星 BST 獨有的獲客功能，特別適合配合營銷活動推廣（如「入金送免佣」）。
完整限額 → 出金規則手冊 § 三層限額體系
讀完之後
| 我想... | 去看 |
|---|---|
| 了解入金視角的綁卡與授權 | 銀行卡綁定與入金授權 |
| 了解 BST Mandate 狀態機 | 內銀系 BST 總覽 |
| 了解 SBA 編排模型 | SBA 資金編排 |
| 看整體架構和數據流 | 系統架構與數據流 |
| 查銀行卡相關錯誤碼 | 統一錯誤碼中心 |