入金方式總覽 Push 模式 Pull 模式
本頁說明
講什麼：10 種入金方式的分類、體驗差異和選擇建議，以及一筆入金從申請到到賬的完整生命週期 適合誰：需要了解入金渠道全貌、幫助用戶選擇最優方式的產品經理 前置閱讀：新人導讀預計閱讀：7 分鐘 負責人：入金產品經理
核心要點：入金有 10 種方式，按自動化程度分為 Push（用戶主動轉入，最常見）、Pull（eDDA 代扣）、BST（銀證互轉）三大類。一筆入金從申請到到賬經歷"申請→流水採集→匹配→入賬→對賬"五步。
入金系統全景圖
下面這張圖展示了入金系統的完整拓撲——從用戶操作到資金到賬，每個節點標註了對應的文檔頁面。建議新 PM 先花 2 分鐘看懂這張圖，再逐頁深入。
圖中各節點對應的文檔：
| 節點 | 對應頁面 | 關鍵內容 |
|---|---|---|
| Apply 申請表 | 入金規則速查 | 申請狀態碼、分表策略、核心字段 |
| 流水採集服務 | 銀行流水採集 | 12 家銀行的採集方式、協議、時效 |
| 匹配引擎 | 匹配與自動入賬 | 五維匹配、銀行專屬規則、容差設計 |
| 自動入賬判定 | 匹配與自動入賬 | 限額、2412 規則、風控檢查 |
| 運營 OA 審核 | 人工匹配指引 | 運營操作流程、審批權限 |
| eDDI 扣款 | eDDA 代扣入金 | 授權生命週期、扣款鏈路、錯誤碼 |
| BST 指令 | BST 銀證轉賬 | 招行/民生/天星的銀證協議 |
| SBA 入賬 | SBA 資金編排 | Procedure 執行模式 |
| 異常處理 | 入金排障 | 9 個場景 + Runbook |
| 變更指導 | 入金變更指南 | 10 種變更場景的操作指南 |
| 沖正/退款 | 退款與沖正 | 三種退款機制、決策樹、失敗恢復 |
三種入金模式
用戶把錢從銀行轉到證券帳戶，有三種截然不同的"發起方"：
Push（用戶推）：用戶在銀行 App 操作轉賬，錢到公司帳戶後，系統需要通過匹配引擎識別"這筆錢是誰的"。好處是無需預授權，任何銀行都能用；代價是需要匹配，到賬不夠即時。
Pull（系統拉）：用戶在 moomoo App 一鍵操作，系統直接從用戶銀行帳戶扣款。系統自己發起的扣款天然知道資金歸屬，完全跳過匹配引擎。體驗最好，但需要用戶提前完成銀行授權（eDDA），且僅匯豐和恒生支持。
Direct（銀證直連）：銀行與證券公司的專線通道，系統通過銀證協議發起扣款。與 Pull 類似，不需要匹配引擎，但走的是不同的技術協議（SM2 加密的銀證專線）。僅招行、民生、天星支持。
10 種入金方式一覽
| 代碼 | 方式 | 模式 | 支持銀行 | 用戶操作 | 到賬時效 |
|---|---|---|---|---|---|
| 3 | FPS 轉數快 | Push | 渣打、廣發、中銀、恒生、工銀 | 銀行 App 轉賬 | 3~5 分鐘 |
| 9 | eDDA 匯豐 | Pull | 匯豐 | App 內一鍵 | 數分鐘 |
| 8 | eDDA 恒生 | Pull | 恒生 | App 內一鍵 | 數分鐘 |
| 1 | BST 銀證 | Direct | 招行、民生 | App 內一鍵 | ~10 分鐘 |
| 10 | 天星銀證 | Direct | 天星 | App 內一鍵 | ~10 分鐘 |
| 5 | 網銀轉賬 | Push | 幾乎所有銀行 | 網上銀行轉賬 | 2 小時~3 天 |
| 2 | ATM/櫃台 | Push | 大部分銀行 | 去 ATM/櫃台 | 2 小時~次日 |
| 4 | 繳付賬單 | Push | 支持 BP 的銀行 | 銀行繳費功能 | 2 小時~次日 |
| 6 | 支票 | Push | 可開支票的銀行 | 開支票 | 2~3 天 |
| 7 | 海外匯款 | Push | EWB、眾安、新加坡工銀子賬戶 | 跨境匯款 | 3~5 天 |
表格按用戶體驗排序——越上面的方式體驗越好、到賬越快。所有方式都支持 HKD 和 USD；FPS、網銀、ATM 等 Push 方式額外支持 CNH。
入金量分佈（產品優先級參考）
下面這張餅圖展示各通道的入金量佔比，幫助判斷優先級：
關鍵結論：
- 匯豐 eDDA 是絕對主力（72%）——任何影響 eDDA 的變更都應優先保障，回歸測試必須覆蓋匯豐通道
- Pull 模式（eDDA）合計近 80%——驗證了"用戶偏好一鍵入金"的產品判斷
- 工銀是第二大來源（12.3%），但系統限制最多——涉及工銀的變更需額外注意
- BST 銀證（招行+民生+天星）合計約 4%，但對特定用戶群體是唯一選項
數據說明
入金量佔比基於近期業務統計，不同時段可能有波動。僅作為產品優先級參考，不代表精確即時數據。
每種方式的處理管線
三種入金模式在系統內部走完全不同的處理鏈路。下面分別展開。
Push 管線（FPS / 網銀 / ATM / BP / 支票 / 海外匯款）
關鍵系統：
- 流水存儲：
flows_{trans_type}_{month}分表，按銀行和月份分片 - 匹配調度：
match:{bank}定時任務，每 3 分鐘一輪 - 匹配結果常量定義在
MatchResult.php，流水處置結果定義在BankFlow.php
Pull 管線（eDDA 匯豐 / 恒生）
特點：系統自己發起扣款，天然知道資金歸屬，跳過匹配引擎。
關鍵數據表：
- 入金申請：
applys_{shard}（按用戶 ID 分片） - 匯豐 eDDI：
hsbc_eddis；恒生 eDDI：hs_eddis - 授權管理：
setup_eddis
詳見 eDDA 代扣入金。
Direct 管線（BST 招行 / 民生 / 天星）
特點：走銀證專線協議（SM2 加密），同樣跳過匹配引擎。招行/民生走 Socket 長連接，天星走 REST API。
詳見 BST 銀證轉賬。
Pull 模式：eDDA 入金
eDDA（Electronic Direct Debit Authorization）是體驗最好的入金方式——用戶在 moomoo App 內填金額、點確認，不需要切換到銀行 App。對於綁定了匯豐或恒生的用戶，eDDA 是轉化率最高的入金方式。
前提：一次性授權。用戶首次使用前，需完成 eDDA 授權，允許系統從其銀行帳戶扣款。授權通過後長期有效，後續入金無需重複授權。
為什麼 eDDA 跳過匹配引擎？ 因為這筆扣款是系統自己發起的——系統在發起扣款請求時就知道這筆錢屬於哪個用戶、對應哪筆申請。不存在"這筆錢是誰的"的問題。
匯豐和恒生的 eDDA 在協議和授權規則上有顯著差異，詳見 eDDA 代扣入金。
為什麼 eDDA 只有匯豐和恒生？
eDDA 是 HKMA（香港金管局）FPS 體系的一部分，技術標準統一，但每家銀行的 API 實現、審核流程、商務條件各不相同。當前只有匯豐和恒生完成了全部對接（商務簽約 + 技術聯調 + 生產驗證）。其他銀行是否支持 eDDA、何時可接入，取決於銀行側的技術就緒度和商務合作意願。想評估新增 eDDA 銀行的可行性 → 入金變更指南 § 新增 eDDA
Push 模式：FPS、網銀及其他
Push 模式的共同特點：用戶在銀行側操作轉賬 → 資金到達公司銀行帳戶 → 系統通過匹配引擎識別歸屬 → 入賬。
FPS 轉數快
FPS 是 Push 模式中體驗最好的——轉賬即時到賬，流水即時推送到系統，匹配引擎 3 分鐘一輪，通常 3~5 分鐘全自動完成。
為什麼 FPS 這麼快？兩個原因：一是 FPS 網絡本身即時結算（不像跨行轉賬要 T+1 清算）；二是渣打和廣發通過 API 即時推送 FPS 流水，不需要等批量文件。
網銀轉賬
覆蓋範圍最廣的入金方式，幾乎所有銀行都支持。但到賬時效差異大：
- 同行轉賬（發送銀行 = 收款銀行）：~2 小時
- 跨行轉賬（HKD）：2~3 個交易日
- 跨行轉賬（外幣）：3~4 個交易日
為什麼同行和跨行差這麼多？同行轉賬在銀行內部結算，當天處理。跨行需要通過銀行間清算系統（CHATS），走批量清算週期。
其他 Push 方式
| 方式 | 適合誰 | 特殊之處 |
|---|---|---|
| ATM/櫃台 | 偏好線下操作的用戶 | 需上傳轉賬憑證，憑證不清楚會要求補充 |
| 繳付賬單（BP） | 熟悉銀行繳費功能的用戶 | 匹配時額外校驗 BP 編號，精度更高 |
| 支票 | 偏好傳統方式的用戶 | 清算週期 2~3 天 |
| 海外匯款 | 境外銀行帳戶的用戶 | 通過子帳戶號匹配（非銀行卡號），容差較大因中轉行扣費不可控 |
Direct 模式：BST 銀證轉賬
BST（Bank-Securities Transfer）是銀行和證券公司之間的專線通道。與 eDDA 類似都是系統側發起扣款，區別在於 BST 走銀證專線協議，使用國密算法加密通信。
| 銀行 | 入金方式 Key | 特點 |
|---|---|---|
| 招行 | bst | 通過銀證雙向鏈路，事件驅動 |
| 民生 | bst | 同招行 |
| 天星 | bstAsb | 虛擬銀行，API 對接 |
前提：用戶需完成銀證帳戶綁定。綁定後可在 moomoo App 內一鍵入金。
處理時段：週一 08:00 ~ 週五 16:00。非營業時段的入金順延到下一交易日自動處理。
為什麼 BST 只有招行、民生、天星？
BST（銀證轉賬）是中國特色的銀證直連協議，通過 SM2 國密加密專線通信。只有在香港設有分支的大陸銀行才具備銀證轉賬能力。招商銀行和民生銀行是最早在港開通銀證的兩家，天星銀行（虛擬銀行）通過 API 適配了類似協議。其他外資銀行（匯豐、恒生、渣打等）不使用銀證協議，走各自的入金通道。
從申請到到賬：完整生命週期
無論哪種入金方式，一筆入金都會經歷以下生命週期：
| 狀態 | 含義 | 典型觸發 |
|---|---|---|
| 待處理（0） | 用戶已提交，等待資金確認 | 用戶在 App 提交入金申請 |
| 處理中（1） | 資金已確認，正在入賬 | Push: 匹配成功；Pull/Direct: 銀行扣款回調成功 |
| 已完成（2） | 入金成功，資金到賬 | SBA Procedure 執行完畢 |
| 已駁回（3） | 申請被拒絕 | 超時未到賬自動駁回 / 運營主動駁回 |
| 已撤回（4） | 用戶取消 | 用戶在 App 主動取消 |
| 已沖正（5） | 已到賬資金被撤回 | 銀行退款、錯誤入賬糾正 |
三種模式的關鍵差異在"待處理→處理中"這一步：
- Push：需要等銀行流水到達 + 匹配引擎匹配成功，可能幾分鐘到幾天
- Pull（eDDA）：系統發起扣款 → 銀行回調成功，通常幾分鐘
- Direct（BST）：系統發起扣款 → 銀行回調成功，通常幾分鐘
詳細的狀態碼和枚舉值 → 入金規則速查
入金類型與流程模板
每筆入金在創建時會被賦予一個 DepositType，決定這筆入金走哪個流程模板（即需要哪些審批步驟）。
| 代碼 | 類型 | 觸發場景 | 是否需人工 | 流程模板 |
|---|---|---|---|---|
| 1 | NORMAL | 流水匹配 + 自動入賬 | 否 | FLOW_NO_CONFIRM |
| 2 | PRE_APPROVAL | 線上開戶首次入金 | 看情況 | FLOW_PRE_CONFIRM |
| 3 | ABNORMAL | 運營手工創建 | 是 | FLOW_PRE_CONFIRM_ABNORMAL |
| 4 | TRANS_AUTO | 前端精確匹配 | 否 | FLOW_NO_CONFIRM |
| 5 | HIGH_RISK | 命中風控（黑名單/高風險國家） | 是 | FLOW_CONFIRM |
| 11 | NORMAL_HOLD | eDDI + 基金定投凍結 | 否 | FLOW_NO_CONFIRM |
| 21 | STOCK_HOLD | eDDI + 股票定投凍結 | 否 | FLOW_NO_CONFIRM |
| 31 | FUND_PURCHASE_HOLD | eDDI + 基金申購凍結 | 否 | FLOW_NO_CONFIRM |
5 種流程模板詳解
每種流程模板定義了入金從"待處理"到"已完成"需要經過的步驟：
| 模板 | 步驟 | 場景 |
|---|---|---|
| FLOW_CONFIRM | [SBAConfirm] | 需運營確認後 SBA 入賬，用於高風險入金 |
| FLOW_NO_CONFIRM | [BankPending] | 全自動，等 SBA 完成即可，最常見的模板 |
| FLOW_PRE_CONFIRM | [Confirm, AccountPending] | 線上開戶用戶，需運營確認 + 等待帳戶就緒 |
| FLOW_PRE_NO_CONFIRM | [AccountPending] | 線上開戶用戶，自動入賬 + 等待帳戶就緒 |
| FLOW_PRE_CONFIRM_ABNORMAL | [Confirm, AccountPending, SBAConfirm] | 異常場景全流程，三重關卡 |
- Confirm：運營在後台確認入金合規性
- AccountPending：等待用戶證券帳戶開通完畢（線上開戶場景）
- SBAConfirm：調用 SBA Procedure 完成資金入賬
- BankPending：等銀行側處理完成，無需人工介入
代碼來源：deposit/src/app/Business/Deposit.php:55-230、deposit/src/app/Business/Tasks/Deposit.php:68-80
如何選擇入金方式
作為產品經理，推薦入金方式的優先級：
核心原則：Pull/Direct > Push。能避免匹配引擎的方式，體驗和確定性都更好。
| 場景 | 推薦方式 | 原因 |
|---|---|---|
| 新用戶首次入金 | FPS（如果支持）或 網銀 | 無需預授權，門檻最低 |
| 高頻入金用戶 | eDDA 或 BST | 一鍵體驗，無需反覆操作 |
| 大額入金（超自動限額） | 任意方式 | 超限後需人工確認，方式不影響 |
| 境外用戶 | 海外匯款 | 唯一選擇，通過子帳戶匹配 |
入金方式可用性判斷
系統根據以下因素決定用戶能看到哪些入金方式：
| 因素 | 影響 | 配置來源 |
|---|---|---|
| 已綁定的銀行卡 | 決定可用的銀行通道 | bankcard_service 資料庫，用戶綁卡時寫入 |
| eDDA 授權狀態 | 未授權則不顯示 eDDA | setup_eddis 表，授權成功後寫入 |
| BST 綁定狀態 | 未綁定則不顯示 BST | bst_bindcards 表，銀證簽約後寫入 |
| 用戶所在地 | 香港/大陸/海外看到的方式不同 | 用戶註冊資訊 + deposit 配置文件中的地區規則 |
| 選擇的幣種 | JPY、SGD 僅部分方式支持 | deposit/config/trans_type.php 幣種-方式映射 |
| 開戶方式 | 線上/線下開戶可用方式有差異 | 用戶帳戶表 account_type 字段 |
各方式處理時段與暫停窗口
不是所有入金方式 7×24 運行。以下是每種方式的精確處理時段：
| 方式 | 處理時段 | 暫停窗口 | 非工作時段行為 |
|---|---|---|---|
| eDDA 匯豐/恒生 | 週一 07:00 ~ 週六 10:00 | 08:55~09:00, 16:05~16:10 | 排隊等下一交易日 |
| BST 招行/民生 | 交易日 07:00 ~ 次日 04:00 | 08:55~09:00, 16:05~16:10 | 排隊等下一交易日 |
| BST 天星 | 交易日 08:00 ~ 22:00 | — | 排隊等下一交易日 |
| FPS | 與 BST 類似 | 08:55~09:00, 16:05~16:10 | 自動入賬暫停，輔助匹配繼續 |
| 匹配引擎 | 7×24（每 3 分鐘） | 08:55~09:00, 16:05~16:10 | 匹配照跑，但自動入賬受時段限制 |
| 網銀/ATM/支票 | — | — | 流水到系統後等待匹配，不受時段限制 |
16:00~16:10 暫停原因：收盤後系統對證券帳戶餘額進行對賬（2412 規則），此窗口內任何自動入金都會暫停，避免資金變動干擾對賬。
如果需求變更：新增一種入金方式
代碼位置：
- 入金方式定義：
deposit/proto/server/cash_deposit.proto— 添加新的入金方式枚舉值 - 方式配置：
deposit/src/app/Common/DepositMethodConfig.php（如存在）或deposit/config/目錄 - 前端展示：需同步更新 App 端的入金方式列表
步驟：
- 定義新方式的 Key 和 代碼編號（確保不與現有 1~10 衝突）
- 確定模式：Push/Pull/Direct — 決定是否需要匹配引擎
- 如果是 Push 模式 → 需要新增 Match 類（參考
BocMatch.php） - 如果是 Pull/Direct → 需要新增 SBA 編排服務（參考
sba_hase_eddi） - 配置處理時段、容差規則、超時駁回天數
- 在可用性判斷邏輯中添加新方式的展示條件
如果需求變更：修改入金方式的可用性規則
代碼位置：deposit/src/app/Business/ 目錄中的可用性判斷邏輯
常見變更場景：
- 某銀行新增 FPS 支持 → 在 FPS 可用銀行列表中添加該銀行的 TransType
- 取消某種入金方式 → 在可用性判斷中將該方式的條件設為 false
- 修改線上開戶限制 → 調整
account_type相關的判斷分支 - 修改地區限制 → 調整
area相關的判斷分支
如果需求變更：調整入金處理時段
代碼位置：deposit/src/app/Business/DepositConfigNew.php
關鍵配置項：
- 營業時段開始/結束：約第 34-50 行，定義週一~週五的處理窗口
- 週六特殊處理：到 09:55 關閉（約第 498 行）
- 暫停窗口（2412 規則）：16:05~16:10（約第 603-641 行）
- USD 特殊開始時間：09:01（約第 440 行）
注意：修改處理時段會影響所有依賴該時段的入金方式（eDDA、BST、匹配引擎的自動入賬判定），需全面評估影響。
角色閱讀路徑
不同角色關注的重點不同，建議按以下路徑閱讀：
新入職 PM（第一週）
| 順序 | 頁面 | 目標 | 預計時間 |
|---|---|---|---|
| 1 | 本頁（入金方式總覽） | 理解 3 種模式 + 10 種方式 | 7 分鐘 |
| 2 | 新人導讀 | 跟著 3 個場景走查一遍 | 15 分鐘 |
| 3 | 匹配與自動入賬 | 理解匹配引擎核心邏輯 | 7 分鐘 |
| 4 | 入金排障 § 場景一和二 | 掌握 70% 的日常問題 | 5 分鐘 |
| 5 | 入金規則速查 | 知道數字在哪裡查 | 瀏覽 2 分鐘 |
需要推動變更的 PM
| 順序 | 頁面 | 目標 |
|---|---|---|
| 1 | 入金變更指南 | 找到對應場景，看影響鏈和審批要求 |
| 2 | 入金規則速查 | 確認當前參數值 |
| 3 | 對應的專題頁 | 理解變更涉及的具體模組 |
運營人員
| 順序 | 頁面 | 目標 |
|---|---|---|
| 1 | 入金排障 | 掌握 9 個場景的排查路徑 |
| 2 | 人工匹配指引 | 掌握日常匹配操作 |
| 3 | 本頁 § 入金方式一覽 | 了解各方式時效 |
| 4 | 銀行流水採集 | 理解流水到達機制 |
常見誤解
| 誤解 | 事實 |
|---|---|
| "入金只有一種方式" | 有 10 種，分為 Push/Pull/Direct 三種模式，體驗和時效差異極大 |
| "eDDA 和出金有關" | eDDA/eDDI 僅用於入金代扣。出金走企業網銀轉賬 |
| "所有入金都需要匹配引擎" | 只有 Push 模式需要。Pull（eDDA）和 Direct（BST）跳過匹配引擎 |
| "入金到賬時間取決於我們系統" | 大部分等待時間是銀行流水到達的延遲，不是我們系統處理慢 |
| "BST 銀證和 eDDA 代扣是同一種技術" | 完全不同。BST 走銀證專線（SM2加密Socket），eDDA 走 FPS 體系（HTTPS/SM2 HTTP） |
| "自動入賬 = 秒到" | 自動入賬也需要等匹配引擎的 3 分鐘週期 + SBA 入賬時間。最快也要 3~5 分鐘 |
讀完之後
| 我想... | 去看 |
|---|---|
| 了解綁卡與授權如何開啟入金通道 | 銀行卡綁定與入金授權 |
| 了解匹配引擎怎麼工作 | 匹配與自動入賬 |
| 了解 eDDA 代扣完整流程 | eDDA 代扣入金 |
| 看各銀行流水怎麼進系統 | 銀行流水採集 |
| 入金出問題了怎麼辦 | 入金排障 |
| 查限額、容差、超時的數字 | 入金規則速查 |
| 推動入金變更需求 | 入金變更指南 |
| 了解退款和沖正機制 | 退款與沖正 |