入金排障
本頁說明
講什麼：入金過程中的常見異常——按「用戶/運營看到什麼症狀」組織，給出排查路徑和處理方式 適合誰：需要處理入金問題的運營人員，需要理解異常流程的產品經理 前置閱讀：匹配與自動入賬預計閱讀：7 分鐘 負責人：入金運營主管
核心要點：入金異常按症狀分類——流水未到、五維不匹配、超額攔截、無對應申請是最常見的四類原因，每種有對應的診斷路徑和處理方式。
快速跳轉 — 你可能想做的事：
症狀 → 場景速查
不確定該去哪個場景？用下面這張圖：
按錯誤碼快速定位
遇到具體錯誤碼時，直接在此表中查找：
| 錯誤碼 | 含義 | 跳轉 |
|---|---|---|
MFISAC01 | eDDA 帳戶號碼錯誤 | 場景七 |
MPP01006 | eDDA 手機號不一致 | 場景七 |
MPP01007 | eDDA 姓名不匹配 | 場景七 |
MPP01008 / MPP02013 | eDDA 銀行未綁手機 | 場景七 |
MPP04000~04004 | eDDA 驗證碼問題 | 場景七 |
MPP06001 | eDDA 帳戶狀態異常 | 場景七 |
ECH09001 | eDDA 通用授權失敗 | 場景七 |
BRC_8I1 | 恒生 eDDI 餘額不足 | 場景八 |
BRC_8RZ | 恒生 eDDI 帳戶異常 | 場景八 |
BRC_8RW+FP2414 | 恒生未查到授權 | 場景八 |
BRC_8RW+FP2415 | 恒生授權未生效 | 場景八 |
BRC_8RW+FP2417 | 恒生超授權限額 | 場景八 |
MPP02020/MPP02023 | 匯豐授權已取消/不存在 | 場景八 |
MPP02021 | 匯豐付款帳戶已關閉 | 場景八 |
MPP02022/MPP05000 | 匯豐超扣款上限 | 場景八 |
MPP02038/MPP02039 | 匯豐授權休眠/過期 | 場景八 |
| 駁回碼 1~15 | 入金駁回原因 | 駁回原因碼 |
| Apply.status=5 | 入金已沖正 | 場景五 |
| DepositType=5 | 風控高風險 | 場景九 |
完整錯誤碼 → 統一錯誤碼中心
快速診斷：用戶說「錢沒到」
收到用戶反饋「我已經轉賬了但錢沒到」時，按以下順序排查：
大部分「錢沒到」的原因是銀行流水還沒到達系統——不同銀行的流水到達時間差異很大，中銀可能延遲數小時，EWB 需要手工上傳。各銀行流水時效 → 入金規則速查 § 處理時效
場景頻率分布
| 頻率 | 場景 | 佔比估算 | 含義 |
|---|---|---|---|
| 高頻 | 場景一（匹配失敗）、場景二（無申請） | ~70% | 幾乎每天都會遇到，運營需最熟練 |
| 中頻 | 場景三（金額差異）、場景四（超時）、場景七（eDDA 授權）、場景八（eDDA 扣款） | ~25% | 每周數次，需熟悉排查路徑 |
| 低頻 | 場景五（沖正）、場景六（重複）、場景九（風控） | ~5% | 每月數次，但影響大，需嚴格按流程操作 |
建議：新入職運營先重點掌握場景一和場景二的處理流程，覆蓋 70% 的日常工單。
場景一：流水到了但沒匹配上 高頻
症狀：Flow 表有流水記錄（status = 0 待處理），Apply 表有申請（status = 0 待處理），但匹配引擎沒有配對。
可能原因及處理：
| 原因 | 排查方式 | 處理 |
|---|---|---|
| 金額差異超容差 | 對比 Flow.amount 和 Apply.amount | 運營確認差額原因後，在 OA 手動匹配 |
| 姓名不一致 | 對比 Flow.en_name 和用戶註冊名 | 可能是英文名格式問題，運營確認後手動匹配 |
| 幣種不一致 | 對比 Flow.currency 和 Apply.currency | 用戶可能選錯了幣種，需駁回重新申請 |
| 超出日期窗口 | 對比 Flow 到達日期和 Apply 創建日期 | 可能申請太早或太晚，運營可手動匹配 |
| 卡號不匹配 | 對比 Flow.customer_account 和 Apply.bank_card_number | 用戶可能從不同卡轉賬 |
運營操作：在 OA 後台的匹配列表中找到這條流水和申請，確認匹配關係後手動創建入金任務。
分步 Runbook：收到「匹配失敗」工單
第 1 分鐘 — 定位問題
- 在 OA 流水列表搜索用戶提供的轉賬金額和日期
- 在 OA 申請列表搜索用戶 UID
第 2~5 分鐘 — 逐維度對比 3. 對比金額：Flow.amount vs Apply.amount，差額是否在容差內？ 4. 對比姓名：Flow.en_name vs 用戶註冊英文名，注意姓名順序 5. 對比幣種：Flow.currency vs Apply.currency 6. 對比日期：流水到達日期是否在申請的匹配窗口內？
第 5~10 分鐘 — 執行處理 7. 如果找到匹配對但被系統跳過 → 在 OA 點擊「手動匹配」 8. 如果金額差異超容差 → 確認差額原因（手續費/轉錯），修改申請金額後重新匹配 9. 如果確實不匹配 → 標記流水為「待跟進」，聯繫用戶確認轉賬詳情
超過 15 分鐘未解決 → 升級到入金產品經理
場景二：用戶轉了錢但沒提交申請 高頻
症狀：銀行流水到達系統，但找不到任何對應的入金申請。
這是最常見的異常場景之一——用戶在銀行 App 轉了錢，但忘了或不知道要在 moomoo App 提交入金申請。
系統處理：AbnormalDepositJob 定時任務會自動檢測這類流水，通過銀行卡號和姓名嘗試識別用戶身份，然後創建異常入金記錄。
運營操作：
- 在 OA 異常入金列表中查看（權限：
ABNORMAL_DEPOSIT_VIEW） - 確認流水對應的用戶
- 選擇處理方式：
- 成功處理：代用戶創建申請並入賬
- 掛起：等待用戶自行提交申請
- 跟進：聯繫用戶確認
預防措施
從產品角度，減少這類異常的方式是在轉賬前引導用戶先在 App 提交申請——很多入金頁面會在轉賬前自動創建申請。
分步 Runbook：發現孤立流水（有流水無申請）
第 1 分鐘 — 確認流水資訊
- 在 OA 異常入金列表查看該筆流水
- 記錄：金額、幣種、匯款人姓名、銀行卡號
第 2~5 分鐘 — 識別用戶 3. 用銀行卡號在銀行卡系統搜索 → 找到對應用戶 UID 4. 如果卡號匹配不到 → 用匯款人姓名搜索 → 可能找到多個用戶 5. 如果姓名也匹配不到 → 標記為「無法識別」
第 5~15 分鐘 — 執行處理 6. 識別到唯一用戶 → 在 OA 選擇「成功處理」，代用戶創建申請並入賬 7. 識別到多個候選用戶 → 標記為「待跟進」，聯繫用戶確認 8. 無法識別 → 掛起，等待用戶主動聯繫或自行提交申請
超過 30 分鐘未解決 → 升級到入金產品經理
場景三：金額不一致 中頻
症狀：用戶說「我轉了 50,000」，但流水顯示 49,950。
銀行轉賬可能產生手續費，尤其是跨行和跨境轉賬。匹配引擎有容差機制處理合理範圍內的差額。
在容差範圍內：自動匹配，Apply.real_amount 記錄實際到賬金額（49,950），用戶看到「入金成功 HKD 49,950」。
超出容差範圍：匹配引擎返回輔助匹配或不匹配。運營需要確認差額原因：
- 銀行手續費 → 確認匹配，按實際到賬金額入賬
- 用戶轉錯金額 → 與用戶確認後處理
- 運營也可以在 OA 修改申請金額後重新匹配
各幣種、各銀行的容差規則 → 入金規則速查 § 匹配容差
場景四：超時未到賬 中頻
症狀：用戶提交了申請，但很長時間銀行流水沒到。
系統會自動處理超時申請，分兩個階段：
階段一：自動通知。 申請超過一定天數後，系統發消息提醒用戶上傳轉賬憑證，幫助運營確認轉賬是否已完成。
階段二：自動駁回。 通知發出後又過了一定天數仍未收到流水或憑證，系統自動駁回申請，通知用戶「由於長時間未收到資金，無法辦理入賬，請與銀行確認是否退款」。
超時天數因銀行和入金方式而異——FPS 通常 1 天就會通知（因為 FPS 本應秒級到賬），而海外匯款可能等 10 天。具體配置 → 入金規則速查 § 超時配置
特殊情況：需要補充憑證。 ATM/櫃台轉賬等方式可能要求用戶上傳憑證。如果憑證模糊或資訊不全，運營會要求補充。超過 20 個交易日未補充 → 自動駁回。
超時天數按交易日計算
所有超時計算基於 HKEX 交易日曆，排除週末和香港公眾假期。
場景五：需要沖正（已入賬資金撤回） 低頻
症狀：入金已完成（狀態=已完成），但需要把資金退回。
沖正是低頻但影響重大的操作，可能的觸發原因：
| 原因 | 說明 |
|---|---|
| 銀行退款（chargeback） | 銀行方面要求退回資金 |
| 錯誤入賬 | 發現入賬處理錯誤，如配錯了用戶 |
| 風控攔截 | 入賬後風控系統發現異常 |
| BST 銀行退款 | 天星銀行主動退回（REFUNDED 狀態） |
沖正排障決策樹
分步 Runbook：沖正失敗排查
第 1 分鐘 — 確認當前狀態
- 在 OA 找到目標入金申請，確認
Apply.status：- 如果 = 2（已完成）→ 可以沖正
- 如果 = 1（處理中）→ 不允許沖正，等處理完成
- 如果 = 5（已沖正）→ 已經沖正過，無需重複操作
- 確認操作人有
CASH_IN_TASK_REVERSE權限
第 2~5 分鐘 — 排查失敗原因 3. 查 SBA 日誌，確認 CashDepositReverse Procedure 的執行狀態：
PROCEDURE_STATUS_END_OK→ SBA 認為成功，檢查 Apply 狀態是否已更新- 餘額不足錯誤 → 查用戶證券帳戶可用餘額和持倉
- 服務超時/連接失敗 → SBA 服務可能宕機
- 如果是餘額不足：
- 查用戶當前持倉佔用金額
- 查是否有在途出金任務
- 計算可用餘額 vs 沖正金額的差額
第 5~10 分鐘 — 恢復操作 5. 餘額不足：凍結帳戶 → 通知用戶釋放資金 → 餘額到位後重新發起沖正 6. SBA 異常：確認服務已恢復 → 重新發起沖正 7. 狀態異常：聯繫入金開發團隊核實原入金的 SBA 記錄，必要時走手工補償
超過 10 分鐘未恢復 → 升級到入金技術負責人
沖正流程：
- 運營在 OA 發起沖正（權限：
CASH_IN_TASK_REVERSE） - 系統檢查狀態——正在處理中的不允許沖正
- 執行沖正：SBA 執行
CashDepositReverse反向 Procedure - 更新申請和任務狀態為「已沖正」（Apply.status = 5）
- 如果是通過綁卡入金的，同步解綁銀行卡
- 通知用戶入金已撤回
沖正後，申請狀態變為 5（已沖正），資金從證券帳戶扣除。
流水退款（不同於任務沖正）：如果銀行流水尚未匹配入賬（Flow.status = 0），可以直接標記流水退款（Flow.result = 3），不涉及證券帳戶資金變動。
三種退款機制的完整對比 → 退款與沖正 運營操作步驟 → 沖正/退款指引
場景六：重複入金 低頻
症狀：同一用戶同一天提交了多筆相同金額的申請，或同一筆銀行流水被處理了兩次。
系統防重機制：
| 層面 | 機制 | 說明 |
|---|---|---|
| 申請層 | 重複檢測標記 | 同一用戶同日同金額的多筆申請會被標記 |
| 流水層 | 唯一索引 | 銀行交易 ID + 銀行類型組成唯一索引，防止同一筆流水重複導入 |
| 對賬層 | 重複掃描 | 定期對賬任務掃描相同金額/姓名/帳號/日期的流水，生成疑似重複報告 |
運營收到重複預警後，審核確認哪筆是真實的、哪筆是重複的，然後駁回重複的申請（駁回原因碼 8：重複申請）。
場景七：eDDA 授權失敗 中頻
症狀：用戶在 App 提交 eDDA 授權後，長時間未生效或直接失敗。
排查路徑：
常見錯誤碼及處理：
| 錯誤碼 | 含義 | 處理建議 |
|---|---|---|
MFISAC01 | 銀行帳戶號碼錯誤 | 引導用戶核對銀行帳號，重新提交 |
MPP01006 | 手機號與銀行綁定不一致 | 引導用戶在銀行 App 確認綁定手機號 |
MPP01007 | 姓名與銀行帳戶不匹配 | 核對註冊姓名與銀行開戶姓名是否一致 |
MPP01008 / MPP02013 | 銀行未綁定手機號 | 引導用戶聯繫銀行綁定手機 |
MPP04000 / MPP04003 / MPP04004 | 驗證碼問題 | 引導用戶重新獲取驗證碼 |
MPP06001 | 銀行帳戶狀態異常 | 引導用戶聯繫銀行處理帳戶狀態 |
ECH09001 | 通用授權失敗 | 確認資訊正確後重新授權 |
運營操作：在 OA 後台查看 setup_eddis 表，確認 edda_status 和 error_code。如果是可修正錯誤（如姓名不匹配），聯繫用戶修正後重新發起授權。
完整錯誤碼表 → eDDA 代扣入金 § 授權失敗錯誤碼
場景八：eDDA 扣款被拒 中頻
症狀：eDDA 授權已生效，但發起扣款時銀行拒絕。Apply 狀態變為已駁回。
排查路徑：
- 確認
setup_eddis.edda_status = 2（授權已生效） - 查
hsbc_eddis或hs_eddis表的reject_code/reject_message - 對照下表處理
恒生常見拒絕碼：
| 錯誤碼 | 含義 | 處理建議 |
|---|---|---|
BRC_8I1 | 餘額不足 | 提醒用戶充值後重試。注意：銀行可能收取手續費且取消授權 |
BRC_8RZ | 銀行帳戶異常 | 引導用戶聯繫恒生銀行 |
BRC_8RW + FP2414 | 未查詢到授權 | 授權可能已被取消，引導用戶重新授權 |
BRC_8RW + FP2415 | 授權未生效 | 引導用戶到恒生銀行激活 eDDA |
BRC_8RW + FP2417 | 超過授權限額 | 引導用戶減少金額或聯繫銀行調整限額 |
匯豐常見拒絕碼：
| 錯誤碼 | 含義 | 處理建議 |
|---|---|---|
MPP02020 / MPP02023 | 授權已取消/不存在 | 引導用戶重新授權 |
MPP02021 | 付款帳戶已關閉 | 引導用戶聯繫匯豐銀行 |
MPP02022 / MPP05000 | 超過扣款上限 | 引導用戶聯繫銀行調整限額 |
MPP02038 / MPP02039 | 授權已休眠/過期 | 引導用戶重新授權 |
特殊注意：恒生餘額不足（BRC_8I1）時銀行可能自動取消 eDDA 授權。處理完餘額問題後，用戶可能還需要重新完成授權才能再次入金。
完整錯誤碼 → eDDA 代扣入金 § 恒生/匯豐扣款被拒錯誤碼
場景九：風控攔截 低頻
症狀：匹配成功但未自動入賬，DepositType 被標記為 HIGH_RISK(5)。
可能原因：
| 攔截類型 | 檢查服務 | 觸發條件 | 處理方式 |
|---|---|---|---|
| 黑名單命中 | hk-deposit-blacklist-go | 用戶/銀行卡/關聯資訊在黑名單中 | 聯合風控團隊審核後決定是否放行 |
| 高風險國家 | SWIFT 代碼檢查 | 匯款來源國在高風險名單中 | AML 合規審核 |
| 線上開戶區域限制 | 白名單服務 | 線上開戶 + 非 FPS + 無港區銀行卡 | 確認用戶身份後決定是否放行 |
運營操作：
- 在 OA 入金任務列表篩選
deposit_type = 5 - 查看關聯的風控檢查結果
- 與風控團隊協商處理：放行入賬或退回資金
- 黑名單支持設置過期時間——臨時風控觀察的用戶到期後自動解除
風控攔截 ≠ 入金失敗
HIGH_RISK 標記只是將自動入賬降級為人工審核。審核通過後仍可正常入賬。
分步 Runbook：收到風控攔截入金
第 1 分鐘 — 確認攔截資訊
- 在 OA 入金任務列表篩選
deposit_type = 5（HIGH_RISK） - 記錄：用戶 UID、入金金額、幣種、銀行、攔截原因
第 2~5 分鐘 — 分類處理 3. 黑名單命中 → 查 hk-deposit-blacklist-go 的命中記錄
- 是臨時黑名單（有過期時間）？→ 等到期自動解除
- 是永久黑名單？→ 轉交風控團隊決定
- 高風險國家命中 → 查 SWIFT 代碼，確認匯款來源國
- 聯繫合規團隊進行 AML（反洗錢）審核
- 線上開戶區域限制 → 確認用戶開戶方式和綁卡情況
- 如果用戶有合規的港區銀行卡 → 可能是系統判斷有誤，聯繫開發確認
- 如果確實不符合條件 → 告知用戶需綁定港區銀行卡
第 5~15 分鐘 — 執行決策 6. 風控/合規團隊決定放行 → 在 OA 手動通過入金，系統自動入賬 7. 風控/合規團隊決定退回 → 走退款流程 8. 風控/合規團隊需要更多時間 → 入金保持 HIGH_RISK 狀態，告知用戶「審核中」
記錄：所有風控攔截的處理結果都需記錄在 OA，形成審計軌跡
超過 4 小時未有決策 → 升級到風控團隊負責人
場景十：工銀流水疑似重複 低頻
症狀：同一筆入金出現兩次匹配記錄，或用戶反饋被重複入賬。
根因：工銀沒有唯一交易 ID，流水去重依賴組合字段（金額+日期+卡號+備註）。當工銀出現 T-1 遲到流水（交易日次日才到達系統）時，可能與當日已到達的流水形成重複。
排查路徑：
分步 Runbook：工銀流水重複排查
第 1 分鐘 — 確認是否真的重複
- 在
flows表按金額+日期+卡號搜索：是否有兩條幾乎相同的流水？ - 對比兩條流水的
created_at：是否一條是當日到達、一條是 T-1 遲到？ - 對比
remarks字段：是否完全相同？
第 2~5 分鐘 — 判斷影響 4. 檢查兩條流水是否都已匹配成功（查 matches 表） 5. 如果只有一條匹配 → 另一條是孤立流水，問題不大 6. 如果兩條都匹配且入賬到同一用戶 → 用戶被重複入賬
第 5~10 分鐘 — 處理 7. 一條匹配、一條未匹配：對未匹配的重複流水執行流水退款標記（Flow.result=3） 8. 兩條都已入賬：對多餘的入金走任務沖正流程 9. 記錄事件，通知用戶（如已重複入賬需先沖正再通知）
超過 15 分鐘未解決 → 升級到入金技術負責人
預防：工銀流水的去重邏輯如有調整，需同步回歸測試 T-1 場景
工銀特殊性
工銀是入金量第二大來源（~12.3%），但系統限制最多。詳見工銀已知系統限制。
駁回原因碼
當申請被駁回時，系統記錄駁回原因碼。常見原因：
| 代碼 | 含義 | 典型場景 |
|---|---|---|
| 1 | 資訊不清楚 | 用戶提交的資訊無法辨認 |
| 4 | 銀行帳戶資訊缺失 | 缺少必要的銀行資訊 |
| 5 | 證券帳戶異常 | 用戶帳戶狀態異常 |
| 7 | 申請被合併 | 多筆申請合併處理 |
| 8 | 重複申請 | 檢測到重複入金 |
| 9 | 超時 | 長時間未收到資金 |
| 14 | 帳戶不一致 | 轉賬人與申請人不一致 |
完整的 15 個原因碼 → 入金規則速查 § 駁回原因碼
運營工具清單
| 工具 | 用途 | 所需權限 |
|---|---|---|
| 申請列表 | 查看/篩選所有入金申請 | CASH_IN_APPLY_VIEW |
| 流水列表 | 查看/篩選銀行流水 | CASH_IN_FLOW_VIEW |
| 任務審批 | 確認匹配、通過/駁回入金 | CASH_IN_TASK_APPROVAL |
| 異常入金 | 處理無申請/資訊錯誤的流水 | ABNORMAL_DEPOSIT_MODIFY |
| 沖正 | 撤回已完成的入金 | CASH_IN_TASK_REVERSE |
| 修改申請 | 修正申請資訊後重新匹配 | CASH_IN_APPLY_MODIFY |
監控與告警
系統通過以下定時任務監控入金異常：
| 任務名 | 頻率 | 監控內容 | 告警條件 |
|---|---|---|---|
monitor:flow-monitor | 每 30 分鐘（07:00~23:00） | 待處理流水堆積 | 待處理流水數超過閾值 |
abnormal-deposit:search | 每 30 分鐘 | 無匹配的孤立流水 | 發現無申請對應的流水 |
abnormal-deposit:update-status | 每 3 分鐘 | 異常入金狀態 | 狀態流轉異常 |
monitor:job | 持續 | Job 佇列健康 | Job 執行失敗/堆積 |
monitor:large-amount | 每小時 | 大額入金 | 超過預設金額閾值的入金 |
monitor:frozen-task | 每小時 | 凍結中入金任務 | 任務長時間處於凍結狀態 |
配置位置
所有監控任務定義：deposit/doc/crontab.sh
收到告警後的處理優先級：
- 流水堆積告警：最緊急——可能是某家銀行的流水採集服務故障，影響所有該銀行的入金。先檢查對應的採集服務是否正常運行。
- Job 執行失敗：檢查失敗 Job 的錯誤日誌，通常是銀行介面超時或返回異常。
- 大額入金告警：通知風控團隊評估，非緊急但需及時處理。
分步 Runbook：收到流水堆積告警
第 1 分鐘 — 定位影響範圍
- 查看告警內容：是哪家銀行的流水堆積？堆積了多少條？
- 檢查該銀行最近一條流水的到達時間 → 判斷是「新流水不進來」還是「進來了但沒處理」
第 2~5 分鐘 — 診斷原因 3. 如果是「新流水不進來」 → 檢查對應銀行的採集服務狀態（hsbc_bank_flow_service、bochk_flow_go 等） 4. 如果是「進來了但沒處理」 → 檢查 match:{bank} Cron 任務是否正常執行 5. 查看服務日誌是否有報錯（銀行介面超時、鑑權失敗等）
第 5~10 分鐘 — 嘗試恢復 6. 採集服務異常 → 重啟服務，觀察流水是否開始進入 7. 匹配任務異常 → 檢查 DB 連接、手動觸發一次匹配任務 8. 銀行介面異常 → 記錄錯誤資訊，通知銀行關係團隊
超過 15 分鐘未恢復 → 升級到技術運維值班人員
如果需求變更：修改異常入金檢測規則
代碼位置：deposit/src/app/Business/AbnormalDeposit.php + deposit/src/app/Jobs/AbnormalDepositJob.php
異常入金檢測邏輯：AbnormalDepositJob 定時任務（每 30 分鐘）掃描 flows 表中 status=0（待處理）且超過一定時間仍未被匹配的流水，嘗試通過銀行卡號和姓名識別用戶。
常見變更場景：
- 調整孤立流水的檢測時間閾值 → 修改
AbnormalDepositJob中的時間窗口參數（當前：流水到達後 X 分鐘未匹配即標記） - 修改用戶識別規則 → 修改
AbnormalDeposit.php中的卡號/姓名匹配邏輯 - 調整異常入金狀態更新頻率 → 修改
deposit/doc/crontab.sh中abnormal-deposit:update-status的 cron 表達式（當前：每 3 分鐘） - 修改流水堆積告警閾值 → 修改
monitor:flow-monitor任務中的閾值參數 - 新增監控維度（如按銀行分別告警） → 在
monitor:flow-monitor或新增獨立監控任務
注意：
- 異常入金記錄需要
ABNORMAL_DEPOSIT_MODIFY權限才能在 OA 處理 - 修改檢測時間閾值過短會增加誤報（流水尚在正常匹配窗口內就被標記為異常）
- 修改過長則孤立流水被發現的時間延遲，影響用戶體驗
分步 Runbook：Job 執行失敗
第 1 分鐘 — 確認失敗 Job
- 查看告警內容：哪個 Job 失敗了？失敗了多少次？
- 檢查 Job 佇列狀態：是單個 Job 失敗還是佇列整體異常？
第 2~5 分鐘 — 分類診斷 3. 匹配相關 Job（match:*）→ 檢查 DB 連接和查詢性能
- 如果 DB 慢查詢 → 可能是表數據量大或索引失效
- 如果 DB 連接超時 → 檢查網路和 DB 實例狀態
- eDDA 相關 Job（
EddiResultJob/EddiCreateJob）→ 檢查 SBA 服務狀態- SBA 超時 → 通常是臨時問題，Job 框架會自動重試
- SBA 返回錯誤 → 查具體錯誤碼
- 監控相關 Job（
monitor:*）→ 非緊急，但需修復避免告警丟失- 檢查監控目標服務是否存活
第 5~10 分鐘 — 恢復 6. 單個 Job 失敗 → 通常 Job 框架會自動重試（最多 3 次） 7. 佇列異常 → 重啟 Job Worker 進程 8. DB 問題 → 聯繫 DBA 檢查實例狀態
超過 15 分鐘未恢復 → 升級到技術運維值班人員
升級決策樹
當你不確定該升級給誰時，用這張圖：
回應要求與升級路徑
| 場景 | 回應時效 | 一線處理 | 升級對象（一線處理不了時） |
|---|---|---|---|
| 流水堆積告警 | 15 分鐘內 | 檢查對應銀行的採集服務是否存活 | → 技術運維（服務重啟/排查） |
| 匹配失敗（單筆） | 工作時間 1 小時內 | OA 後台核對流水和申請資訊，嘗試手動匹配 | → 入金產品經理（規則問題） |
| eDDA 授權失敗 | 工作時間 2 小時內 | 查 error_code，按錯誤碼表引導用戶 | → 銀行關係團隊（銀行側問題） |
| eDDA 扣款被拒 | 工作時間 2 小時內 | 查 reject_code，按錯誤碼表引導用戶 | → 銀行關係團隊（銀行側問題） |
| 風控攔截 | 工作時間 4 小時內 | 查看風控檢查結果 | → 風控團隊（決定放行或退回） |
| 大額入金告警 | 工作時間 4 小時內 | 通知風控團隊評估 | → 風控團隊 + 合規團隊 |
| 用戶投訴「錢沒到」 | 工作時間 30 分鐘內 | 按快速診斷流程圖排查 | → 入金產品經理（系統問題）或銀行關係團隊（銀行問題） |
| 沖正請求 | 工作時間 2 小時內 | 確認沖正原因，執行沖正操作 | → 入金產品經理 + 清算團隊 |
| Job 執行失敗 | 30 分鐘內 | 檢查失敗 Job 的錯誤日誌 | → 技術運維（基礎設施問題）或對應銀行服務開發者 |
時效說明：工作時間指 HKT 09:00~18:00 週一至週五。非工作時間的告警在下一個工作日開始時處理，但流水堆積告警和 Job 失敗需 24×7 回應。
常見誤解
| 誤解 | 事實 |
|---|---|
| 「用戶說錢沒到就是系統故障」 | 70% 的情況是銀行流水還沒到系統，或用戶忘了提交申請。先按診斷流程圖排查 |
| 「告警就要馬上處理所有問題」 | 按優先級：流水堆積 > Job 失敗 > 匹配失敗。不是所有告警都緊急 |
| 「駁回就是入金失敗」 | 駁回只是當次申請被關閉。用戶可以重新提交申請 |
| 「沖正後用戶會自動收到退款」 | 沖正只是從證券帳戶扣回資金。銀行退款是另一個流程，需要單獨操作 |
| 「HIGH_RISK 的入金一定有問題」 | 不一定。可能只是臨時風控觀察、或地區限制。審核後大部分都會放行 |
讀完之後
| 我想... | 去看 |
|---|---|
| 銀行卡綁定/授權導致入金異常 | 銀行卡綁定與入金授權 |
| 理解匹配機制（才能排查失敗原因） | 匹配與自動入賬 |
| 查容差、超時、原因碼的數字 | 入金規則速查 |
| 看 eDDA 授權/扣款的錯誤碼 | eDDA 代扣入金 |
| 看運營側 eDDA 排障操作指引 | eDDA 排障指引 |
| 看各銀行流水到達時效 | 銀行流水採集 |
| 查運營日常操作指南 | 人工匹配指引 |
| 查所有錯誤碼和狀態碼 | 統一錯誤碼中心 |
| 了解退款和沖正完整機制 | 退款與沖正 |