出金變更指南
本頁說明
講什麼：PM 最常見的 10 種出金變更需求——每種告訴你改什麼、在哪改、影響什麼、找誰審批 適合誰：需要推動出金相關需求變更的產品經理 前置閱讀：出金方式總覽預計閱讀：8 分鐘 負責人：出金產品經理
核心要點：出金變更按類型分為代碼改動（需發版 1-3 天）和數據庫配置（改完即時生效），每種變更都標註了改動位置、影響範圍和審批要求。
怎麼用這頁
當你有一個出金相關的需求變更時：
- 在下面找到對應的變更場景
- 看"配置類型"判斷改動難度和週期
- 看"影響鏈"評估風險
- 看"審批要求"確認找誰簽字
- 看"驗證方法"確認怎麼驗收
配置類型速查
| 類型 | 含義 | 生效方式 | 改動週期 |
|---|---|---|---|
| 代碼常量 | 寫死在 PHP/Go/Python 代碼中 | 需走發布流程 | 1~3 天（含開發+測試+發布） |
| 配置文件 | config/*.php 或 .env | 需走發布流程 | 1~2 天 |
| 數據庫配置 | 存在 DB 配置表中 | 改完即時生效 | 當天 |
| 運營後台 | OA/CRM 後台可調 | 運營自行操作 | 即時 |
| Cron 配置 | 定時任務表達式 | 需運維部署 | 0.5~1 天 |
| 銀行側 | 需要銀行配合 | 走商務+技術對接 | 數週~數月 |
場景一：調整自動出金限額
例：把天星 HKD 單筆上限從 300 萬調到 500 萬
| 維度 | 說明 |
|---|---|
| 改什麼 | auto_settings 表中對應銀行+幣種的 max_amount 欄位 |
| 在哪改 | 數據庫 auto_settings 表，按 id（銀行：招行=2、民生=1、天星=3）定位行，修改 {prefix}max_amount |
| 配置類型 | 數據庫配置 — 改完即時生效 |
| 影響鏈 | 限額調高 → 更多大額出金走自動通道 → 運營工作量減少，但大額異常可能自動放行。限額調低 → 更多出金降級為人工 → 運營工作量增加，安全性更高 |
| 驗證方法 | 發一筆略超舊限額但低於新限額的測試出金，確認走了自動路徑 |
| 審批要求 | 風控團隊簽字（必須）+ 產品確認 + 運營知曉 |
| 回滾 | 恢復原值，即時生效 |
三層限額聯動
修改 max_amount（單筆上限）時，需同步評估 alarm_amount（報警閾值）和 stop_amount（熔斷閾值）是否也需要調整。單筆上限調高但熔斷不調，可能導致幾筆大額出金就觸發熔斷。
當前三層限額值 → 出金規則手冊 § 三層限額體系
場景二：修改高風險判定規則
例：讓大陸地區（CN）不再觸發高風險 Audit
| 維度 | 說明 |
|---|---|
| 改什麼 | HIGH_RISK_AREA 因子的判定邏輯 |
| 在哪改 | withdraw/src/app/Business/HighRisk/HighRiskBiz.php → 各 checkHighRisk*() 方法 |
| 配置類型 | 代碼常量 — 需發布 |
| 影響鏈 | 移除 CN → 大陸銀行卡出金不再觸發 Audit → Audit 審核量下降，但可能遺漏大陸方向的異常出金。新增國家 → 對應國家的出金全部多一步 Audit → 運營審核量上升 |
| 特殊注意 | 高風險國家列表每 5 分鐘從 API 更新一次，但 CN 和 PR 是硬編碼在 HighRiskBiz.php 的 checkHighRiskArea() 中的（不在 API 列表中）。移除 CN 需改代碼而非調 API |
| 驗證方法 | 用大陸銀行卡發一筆測試出金，確認 high_risk 位掩碼中 AREA(2) 不再被設置 |
| 審批要求 | 風控團隊簽字（必須）+ 合規確認 |
| 回滾 | 恢復原代碼，重新發布 |
常見變更場景
- 讓 FREQUENCY 也觸發 Audit → 在
HighRiskCheck.php→needAudit()中添加 bit 判斷 - 修改"≥10 筆"的頻率閾值 → 修改
HighRiskBiz.php中的 FREQUENCY 判斷邏輯 - 新增一個風險因子 → 新增 bit 常量 + 計算邏輯 + needAudit 判斷
當前 6 因子詳解 → 出金規則手冊 § 高風險判定
場景三：修改審批模板
例：新增 VIP 用戶免 Confirm 的快速出金模板
| 維度 | 說明 |
|---|---|
| 改什麼 | $stepTemplates 數組，新增模板或修改現有模板的步驟 |
| 在哪改 | withdraw/src/app/Business/Task.php → $stepTemplates 數組 |
| 配置類型 | 代碼常量 — 需發布 |
| 影響鏈 | 減少步驟 → 出金審批更快，但安全檢查減少。增加步驟 → 出金變慢，安全性提高但運營工作量增加。新增模板 → 需同步在 CreatorBase.php 中添加模板選擇邏輯 |
| 驗證方法 | 用目標用戶類型發一筆測試出金，檢查 template 欄位和實際審批步驟數 |
| 審批要求 | 產品確認 + 風控確認 + 運營知曉（流程變化） |
| 回滾 | 恢復原模板，重新發布 |
新增步驟需實現 Step 類
每個審批步驟是一個 PHP 類，實現 IFStep 接口。新增步驟不只是加數組元素——需要編寫步驟的檢查邏輯、CRM 交互邏輯和權限控制。
當前 6 種模板 → 出金規則手冊 § 審批模板
場景四：調整自動出金餘額管理
例：天星 HKD 的報警閾值從 4000 萬調到 6000 萬
| 維度 | 說明 |
|---|---|
| 改什麼 | auto_settings 表中的 alarm_amount 和/或 stop_amount |
| 在哪改 | 數據庫 auto_settings 表 |
| 配置類型 | 數據庫配置 — 改完即時生效 |
| 影響鏈 | alarm 閾值調高 → 更早收到告警 → 運營有更多反應時間。alarm 閾值調低 → 告警延遲 → 餘額可能在不知不覺中接近熔斷線。stop 閾值調高 → 更早觸發熔斷關閉自動出金 → 安全但運營需更頻繁"充值"。stop 閾值調低 → 更晚熔斷 → 自動出金持續時間更長 |
| 驗證方法 | 調整後觀察下一次告警/熔斷觸發時的餘額值是否符合新閾值 |
| 審批要求 | 運營主管確認 |
| 回滾 | 恢復原值，即時生效 |
"充值"操作
當餘額低於 stop_amount 觸發熔斷後，運營需要：1. 更新 {prefix}amount 增加金額（"充值"）；2. 將 {prefix}status 設為 1（重新開啟）。兩步缺一不可。
auto_settings 完整欄位 → 出金規則手冊 § 自動出金配置
場景五：恢復出金手續費
例：恢復對跨境出金收取 HKD 105 / USD 15
| 維度 | 說明 |
|---|---|
| 改什麼 | getFee() 末尾的 $fee = 0 強制免費行 |
| 在哪改 | withdraw/src/app/Business/CreatorBase.php → getFee() 方法 |
| 配置類型 | 代碼常量 — 需發布 |
| 影響鏈 | 恢復收費 → 用戶出金成本增加 → 可能影響出金頻率和用戶滿意度。費用會在用戶提交前展示確認 → 前端顯示邏輯無需修改（已有） |
| 特殊注意 | 代碼中已定義了完整的費率表（HKD 105 / USD 15 / CNH 105），只需刪除末尾的 $fee = 0 即可恢復。無需重寫費率邏輯 |
| 驗證方法 | 用跨境銀行卡發一筆測試出金，確認 App 端展示的費用和 Task 的 fee 欄位正確 |
| 審批要求 | 產品負責人 + 運營知曉 + 客服準備話術 |
| 回滾 | 加回 $fee = 0，重新發布 |
當前費率表 → 出金規則手冊 § 費用規則
場景六：新增 BST 銀行
例：接入一家新的銀證轉賬銀行
這是最複雜的出金變更場景，涉及多個服務。
開發清單
| 步驟 | 工作內容 | 涉及服務/文件 |
|---|---|---|
| 1 | 銀行側簽約 + 技術協議確認 | 商務團隊 |
| 2 | 開發銀證對接服務 | 新建 Python/Go 服務（參考 cmb_stock_trans） |
| 3 | 開發 SBA 出金編排適配 | sba_cash_withdraw_system 新增銀行分支 |
| 4 | 在 auto_settings 表新增銀行配置 | 數據庫 + AutoSetting.php 新增 bank_id 映射 |
| 5 | 在 Method.php 添加通道路由 | calcMethod() 新增 BST 判斷分支 |
| 6 | 新建 xxx_list 表 | 銀行端發起出金的流水存儲 |
| 7 | 新建隊列事件 | SyncXxxWithdraw + XxxWithdrawCreate |
| 8 | Mandate/簽約管理 | 銀行卡服務 + BankCardXxxBst 擴展表 |
| 9 | 前端通道展示 | App 出入金頁面適配 |
| 10 | 聯調測試 | 端到端：簽約 → 入金 → 出金 → 回調 |
協議選擇
| 協議 | 參考 | 到賬時效 | 複雜度 |
|---|---|---|---|
| Socket 雙向鏈路（SM2） | 招行 cmb_stock_trans | 秒級（實時推送） | 高 |
| REST API + 輪詢 | 天星 airstar_service | 秒~分鐘級 | 中 |
審批要求
商務團隊（銀行合作）+ 技術負責人 + 風控確認 + 產品確認
參考工期
| 對接方式 | 參考工期 | 參考服務 |
|---|---|---|
| Socket 雙向鏈路 | 6~8 週 | cmb_stock_trans（招行） |
| REST API | 4~6 週 | airstar_service（天星） |
場景七：新增 FPS 出金通道
例：接入渣打銀行的 FPS 出金 API（從手動變半自動）
| 維度 | 說明 |
|---|---|
| 改什麼 | 將手動通道升級為有 API 對接的半自動通道 |
| 在哪改 | 多處——見開發清單 |
| 配置類型 | 代碼開發 — 需完整開發週期 |
開發清單
| 步驟 | 工作內容 | 涉及文件 |
|---|---|---|
| 1 | 創建 Go 服務對接銀行 FPS API | 新建 xxx_fps_service（參考 cgb_fps_service） |
| 2 | 在 PHP 新建業務類 | withdraw/src/app/Business/Withdraw/XxxFpsBiz.php（參考 CgbFpsBiz.php） |
| 3 | 新建輪詢事件 | SyncXxxFpsResult（參考 SyncCgbFpsResult） |
| 4 | 在 Method.php 添加通道常量 | 新增 xxx_fps_api 常量和分組歸屬 |
| 5 | 新建狀態跟蹤表 | task_xxx_fps（參考 task_cgb_fps） |
| 6 | 調整 CRM 展示 | 通道列表、操作按鈕 |
審批要求：技術負責人 + 產品確認
參考工期：3~4 週（含聯調）
通道執行細節 → 通道執行手冊 § FPS 通道
場景八：修改處理時段
例：把天星的處理時段從 08:00~22:00 擴展到 07:00~23:00
| 維度 | 說明 |
|---|---|
| 改什麼 | BST 通道的自動處理時間窗口 |
| 在哪改 | 出金定時任務腳本 + SBA 編排中的時段判斷 |
| 配置類型 | Cron 配置 + 代碼常量 — 需運維部署 + 代碼發布 |
| 影響鏈 | 窗口擴大 → 更多時段的出金可自動處理 → 用戶體驗更好。但需確認銀行側該時段是否接受指令——如果銀行不處理，指令會在銀行側排隊 |
| 為什麼不能隨便改 | 處理時段與銀行的營業時間對齊。如果系統在銀行非營業時間發送指令，銀行可能返回超時或拒絕 |
| 驗證方法 | 在新增時段內發一筆測試出金，確認銀行正常處理 |
| 審批要求 | 產品確認 + 運維部署 + 需先與銀行確認支持的時段 |
| 回滾 | 恢復原時段配置 |
當前各通道處理時段 → 出金規則手冊 § 處理時段
場景九：新增出金幣種
例：新增 JPY（日元）出金
| 步驟 | 工作內容 | 涉及文件 |
|---|---|---|
| 1 | 在 auto_settings 表添加 JPY 列 | jp_status、jp_amount、jp_max_amount 等 6 個欄位 |
| 2 | 在 AutoSetting.php 添加前綴映射 | 新增 jp_ 前綴處理 |
| 3 | 在 getFee() 添加 JPY 費率 | CreatorBase.php 的 switch 語句 |
| 4 | 在通道路由中支持 JPY | 確認各通道是否支持 JPY 出金 |
| 5 | 前端幣種選擇器 | App 出金頁面添加 JPY 選項 |
| 6 | SBA 配置 | SBA 系統支持 JPY 賬戶餘額操作 |
前置條件：確認哪些出金通道支持 JPY。BST 通道需銀行確認是否支持日元銀證轉賬。
審批要求：產品確認 + 清算團隊確認 + 技術負責人
參考工期：2~3 週
場景十：修改出金通知邏輯
例：出金成功後的推送通知改為包含到賬銀行信息
| 維度 | 說明 |
|---|---|
| 改什麼 | 通知文案和觸發邏輯 |
| 在哪改 | 通知服務配置（非 withdraw 服務管轄——withdraw 只負責發通知事件） |
| 配置類型 | 取決於通知服務的實現 |
| 影響鏈 | 文案修改僅影響用戶端展示；觸發邏輯修改可能影響通知時機和頻率 |
| 特殊注意 | 出金系統通過 SBA 的回調觸發通知，Task 狀態更新為 DONE 時發送。修改通知內容不需要改出金服務，只需改通知服務的模板 |
| 驗證方法 | 測試環境完成一筆出金，確認通知內容和渠道 |
| 審批要求 | 產品確認 |
變更風險矩陣
| 變更 | 技術風險 | 業務風險 | 改動週期 | 建議灰度方式 |
|---|---|---|---|---|
| 調整限額 | 低 | 高（大額異常） | 即時 | 按銀行×幣種逐步調整 |
| 修改風控規則 | 低 | 高（遺漏風險） | 1~3 天 | 先移除單一因子，觀察 1 週 |
| 修改審批模板 | 中 | 高（審批缺失） | 1~3 天 | 先對特定用戶群灰度 |
| 調整餘額管理 | 低 | 中 | 即時 | 先調一個幣種觀察 |
| 恢復手續費 | 低 | 高（用戶體驗） | 1~3 天 | 不建議灰度，需全量同步前端展示 |
| 新增 BST 銀行 | 高 | 中 | 6~8 週 | 新銀行獨立上線 |
| 新增 FPS 通道 | 中 | 低 | 3~4 週 | 新通道獨立上線 |
| 修改處理時段 | 低 | 中 | 0.5~1 天 | 先延長 30 分鐘觀察 |
| 新增幣種 | 中 | 低 | 2~3 週 | 按幣種逐步開放 |
| 修改通知 | 低 | 低 | 1~2 天 | 灰度推送 |
讀完之後
| 我想... | 去看 |
|---|---|
| 理解出金的完整流程 | 出金生命週期 |
| 看每條規則的詳細解釋 | 出金規則手冊 |
| 查某個狀態碼是什麼意思 | 出金數據字典 |
| 看入金側有什麼變更場景 | 入金變更指南 |
| 瞭解某家銀行的對接細節 | 銀行能力矩陣 |