入金变更指南

本页说明

讲什么：PM 最常见的 10 种入金变更需求——每种告诉你改什么、在哪改、影响什么、找谁审批 适合谁：需要推动入金相关需求变更的产品经理 前置阅读：入金方式总览预计阅读：5 分钟 负责人：入金产品经理

核心要点：入金变更分为代码常量、配置文件、数据库、运营后台四类，不同类型的改动周期和影响链差异很大——改代码需发版，改配置可能即时生效。

怎么用这页

当你有一个入金相关的需求变更时：

在下面找到对应的变更场景
看"配置类型"判断改动难度和周期
看"影响链"评估风险
看"审批要求"确认找谁签字
看"验证方法"确认怎么验收

配置类型速查

类型	含义	生效方式	改动周期
代码常量	写死在 PHP/Go/Python 代码中	需走发布流程	1~3 天（含开发+测试+发布）
配置文件	`config/*.php` 或 `.env`	需走发布流程	1~2 天
数据库配置	存在 DB 配置表中	改完即时生效	当天
运营后台	OA/CRM 后台可调	运营自行操作	即时
Cron 配置	定时任务表达式	需运维部署	0.5~1 天
银行侧	需要银行配合	走商务+技术对接	数周~数月

变更审批流程

无论哪种变更场景，都应遵循以下通用流程：

Staging 验证通用指南

所有需要发布的变更（代码常量、配置文件类）都应在 Staging 环境验证后再上线。

分步指南：如何在 Staging 验证入金变更

前置条件：Staging 环境已部署最新代码（含变更）

Step 1 — 准备测试数据

在 Staging 创建测试用户（或使用现有测试账号）
确认 Staging 的银行 Mock 服务正常运行（Staging 不连真实银行，用 Mock 模拟流水）

Step 2 — 触发测试场景 3. 按变更类型准备不同的测试：

容差变更：构造差额恰好在新旧容差边界的流水，验证匹配行为变化
限额变更：构造金额恰好在新旧限额边界的申请，验证自动入账判定
超时变更：创建申请后快进时间（修改 DB 时间），验证通知和驳回触发
风控变更：加/移黑名单后触发入金，验证 DepositType 标记
新银行：端到端测试完整链路（Mock 流水 → 匹配 → 入账）

Step 3 — 验证结果 4. 检查 DB 状态（Apply/Flow/Task/Match 表）是否符合预期 5. 检查通知是否正确触发（Push/站内信） 6. 检查对账报告是否无异常

Step 4 — 记录 7. 截图/录屏验证结果 8. 在需求文档中标注"Staging 已验证"

场景一：调整某银行的匹配容差

例：把汇丰的自动入账容差从 HKD 65 调到 HKD 100

维度	说明
改什么	对应银行 Matcher 类中的容差常量
在哪改	`deposit/src/app/Business/Match/HsbcMatch.php`（汇丰）、`BocMatch.php`（中银）、`HangSengMatch.php`（恒生）、`IcbcNewMatch.php`（工银）、`DbsMatch.php`（星展）、`EwbMatch.php`（东亚）
配置类型	代码常量 — 需发布
影响链	容差放宽 → 更多流水进入自动匹配 → 误匹配风险上升（金额相近的不同申请可能被错配）→ 可能出现入错账。容差收紧 → 更多流水降级为辅助匹配 → 运营人工确认工作量增加
验证方法	发布前：拉 1 周该银行的历史流水，用新容差模拟回测匹配结果。发布后：观察该银行的「自动匹配率」和「辅助匹配量」变化
审批要求	产品确认 + 运营知晓（工作量可能变化）
回滚	1. 恢复原容差常量 → 重新发布（~1小时） 2. 已经被新容差错误匹配的入金需逐笔检查 3. 如发现误匹配 → 走冲正流程（冲正指引）

容差调整的核心风险

容差每放宽 1 元，理论上都会增加"金额相近的不同申请被错配"的概率。尤其当同一银行有多个用户同时申请相近金额时。必须先用历史数据回测再上线。

当前各银行容差 → 入金规则速查 § 匹配容差

场景二：调整自动入账限额

例：把 HKD 自动入账上限从 200 万调到 500 万

维度	说明
改什么	`DepositConfigNew` 中的币种限额常量
在哪改	`deposit/src/app/Business/DepositConfigNew.php`
配置类型	代码常量 — 需发布
影响链	限额调高 → 更多大额入金走自动通道 → 减少运营工作量，但大额异常入金也可能自动放行。限额调低 → 更多入金需人工确认 → 运营工作量增加，但安全性更高
验证方法	发布后观察「需人工确认的入金占比」变化
审批要求	风控团队签字（必须）+ 产品确认 + 运营知晓
回滚	1. 恢复原限额常量 → 重新发布（~1小时） 2. 检查变更期间是否有超原限额的入金被自动处理 3. 如有异常大额 → 联合风控团队逐笔审核

当前限额

HKD 2,000,000 / USD 300,000 / CNH 2,000,000 / JPY 40,000,000 / SGD 350,000。完整表 → 入金规则速查 § 币种限额

场景三：修改超时天数

例：把 FPS 的通知天数从 1 天改为 2 天

维度	说明
改什么	超时配置（通知天数、驳回天数）
在哪改	`deposit/src/app/Business/DepositConfigNew.php` — 超时配置区
配置类型	代码常量 — 需发布
影响链	通知天数延长 → 用户等待更久才收到提醒 → 可能导致更多"钱没到"投诉。通知天数缩短 → 正常但较慢的银行转账可能被过早通知 → 用户困惑
特殊注意	天数按 HKEX 交易日计算（排除周末和公众假期）。修改只影响新申请，不影响已有申请的超时计算
验证方法	发布后创建测试申请，等待超时通知触发
审批要求	产品确认
回滚	恢复原天数，重新发布

当前超时配置 → 入金规则速查 § 超时配置

场景四：调整 2412 暂停窗口

例：把 16:05~16:10 的暂停窗口改为 16:00~16:15

维度	说明
改什么	2412 暂停窗口的起止时间
在哪改	`deposit/src/app/Business/DepositConfigNew.php:603-641`
配置类型	代码常量 — 需发布
影响链	窗口扩大 → 更多入金在暂停期间降级为辅助匹配 → 运营工作量增加，但对账安全性更高。窗口缩小 → 对账期间可能有自动入金在执行 → 可能导致账户余额不一致
为什么不能随便改	2412 窗口是为了确保港股开盘/收盘时的账户对账不被资金变动干扰。窗口起止时间与交易所的开盘前结算和收盘后结算时间对齐。如果缩短窗口，可能出现"对账瞬间账户余额被入金改变"的情况，导致账务不平
验证方法	联合清算团队验证对账报告无差异
审批要求	清算团队签字（必须）+ 产品确认
回滚	恢复原窗口，重新发布

场景五：修改风控规则

例：把某用户加入/移出黑名单

维度	说明
改什么	黑名单/白名单数据
在哪改	`hk-deposit-blacklist-go` / `hk-deposit-whitelist-go` 服务的管理接口
配置类型	数据库配置 — 改完即时生效
影响链	加入黑名单 → 该用户所有后续入金自动标记为 HIGH_RISK(5) → 需人工审核才能入账。移出黑名单 → 该用户恢复正常自动入账。黑名单支持设置过期时间（临时观察）
特殊注意	黑名单影响入金环节。如果用户已有申请正在匹配中，黑名单在下一个匹配周期（3 分钟内）生效。已经完成入账的不受影响
验证方法	加入后触发一笔测试入金，确认 `deposit_type` 被标记为 5
审批要求	风控团队签字（必须）
回滚	从黑名单移除，即时生效

场景六：调整匹配引擎频率

例：把匹配引擎从每 3 分钟改为每 1 分钟

维度	说明
改什么	匹配 Cron 任务的执行频率
在哪改	`deposit/doc/crontab.sh` 中各 `match:*` 任务的 cron 表达式
配置类型	Cron 配置 — 需运维部署
影响链	频率提高 → 用户感知的入金速度更快。但数据库查询频率成比例增加 → 可能影响 DB 性能，尤其是流水量大的银行（中银、汇丰）
为什么当前是 3 分钟	在当前日均流水量下，3 分钟是"用户体验"和"数据库负载"的平衡点。匹配引擎每次运行需扫描 `flows` 和 `applys` 表中所有待处理记录（`status=0`），频率越高扫描越频繁。如果某银行日均只有几十条流水，提频意义不大；如果日均数千条，提频会带来显著的 DB 压力
验证方法	先在压测环境验证 DB 负载变化；灰度期间监控 DB 慢查询告警
审批要求	技术负责人确认（DB 负载评估）+ 产品确认
回滚	恢复原 cron 表达式，重新部署

场景七：新增银行入金通道

例：接入一家新银行（如大新银行）的 Push 模式入金

这是最复杂的变更场景，涉及多个服务和配置。

开发清单

步骤	工作内容	涉及服务/文件
1	分配 TransType 代码	`deposit/proto/server/cash_deposit.proto` — 在枚举中加新值
2	开发流水采集服务	新建 Go/Python 服务（参考 `dbs_service` 或 `icbc_be_relay`）
3	实现 Matcher 类	`deposit/src/app/Business/Match/` 下新建 `XxxMatch.php`，继承 `MatchBase`
4	配置匹配 Cron 任务	`deposit/doc/crontab.sh` 加 `match:xxx` 每 3 分钟
5	配置容差和时间窗口	在 Matcher 类中定义（参考同类银行）
6	配置超时天数	`DepositConfigNew.php` 按入金方式设置
7	前端入金方式展示	App 入金页面配置新方式可见性
8	对账配置	`bank_reconciliation` 任务中加新银行
9	联调测试	端到端测试：流水采集 → 匹配 → 入账 → 对账

前置条件

条件	说明	负责方
银行技术对接协议	确定流水获取方式（API/文件/Webhook）	商务 + 技术
公司收款账户	在该银行开设企业收款账户	财务
银行卡识别规则	BIN 号段识别，用于前端展示和匹配	`bankcard_service`

审批要求

商务团队（银行合作）+ 技术负责人 + 产品确认

参考工期

流水接入方式	参考工期	参考
API 实时推送	3~4 周	参考渣打 `scb_service`
API 定时拉取	2~3 周	参考工银 `icbc_be_relay`
文件批量拉取	4~6 周	参考中银 `bochk_flow_go`（最复杂）

任务依赖与并行度

新银行接入的 9 个步骤并非全部串行。以下是依赖关系和可并行的工作：

可并行的工作（绿色标注）：

步骤 2（流水采集）、3（Matcher）、6（超时配置）、7（前端展示）可以同时进行
步骤 4（Cron）和 5（容差/窗口）依赖 2 和 3，但可以在 2/3 完成后并行
步骤 9（联调）是最终汇合点，依赖所有其他步骤

关键路径：前置条件 → TransType → 流水采集服务 → 联调测试。流水采集服务的开发通常是耗时最长的环节。

回滚策略

新银行上线后如需回滚：

关闭前端展示（用户看不到该银行入金方式）→ 立即生效
停止 match:{bank} Cron 任务 → 新流水不再匹配
停止流水采集服务 → 不再接收新流水
已经入金的不受影响，无需冲正

场景八：新增 eDDA 支持银行

例：想让星展银行也支持 eDDA 入金

结论：短期不可行，需评估银行侧支持情况。

前置条件	说明	可控性
银行支持 eDDA 协议	银行需在 HKMA 的 FPS 体系中实现 eDDA 功能	完全取决于银行
商务合作签约	银行同意为 moomoo 开通 eDDA 代扣权限	需商务谈判
技术对接	对接银行的 eDDA/eDDI API（每家实现不同）	预计 4~8 周
SBA 编排服务	新建 `sba_xxx_eddi` 编排服务	参考 `sba_hsbc_eddi`
deposit 服务适配	Eddi.php 中加新银行分支	1~2 周

为什么当前只有汇丰和恒生？ eDDA 是 HKMA（香港金管局）FPS 体系的一部分。虽然技术标准是统一的，但每家银行的 API 实现、审核流程、商务条件各不相同。当前只有汇丰和恒生完成了全部对接（商务签约 + 技术联调 + 生产上线）。

如果真的要推进：第一步是联系银行关系团队，确认目标银行是否支持 eDDA 协议，再评估商务和技术工作量。

场景九：新增币种支持

例：新增 GBP（英镑）入金

步骤	工作内容	涉及文件
1	Proto 定义	`deposit/proto/server/cash_deposit.proto` — 加 Currency 枚举
2	容差配置	各 Matcher 类中加 GBP 容差（参考与 HKD 的汇率折算）
3	限额配置	`DepositConfigNew.php` — 加 GBP 自动入账限额
4	超时配置	`DepositConfigNew.php` — 加 GBP 超时天数
5	前端展示	入金页面币种选择器加 GBP
6	SBA 配置	SBA 系统支持 GBP 余额账户
7	对账	新增 GBP 对账任务

前置条件：公司在收款银行需有 GBP 账户。并非所有银行都支持所有币种——需先确认哪些银行可收 GBP。

审批要求：产品确认 + 清算团队确认 + 技术负责人

场景十：修改入金通知逻辑

例：入金成功后的推送通知文案要改

维度	说明
改什么	通知文案和触发逻辑
在哪改	通知服务配置（非 deposit 服务管辖，deposit 只负责发通知事件）
配置类型	取决于通知服务的实现——通常是配置文件或数据库
影响链	文案修改仅影响用户端展示；触发逻辑修改可能影响通知时机和频率
特殊注意	入金系统定义了 4 种通知类型码（普通入金=1、线上开户绑卡=2、绑卡后入金=3、大陆预开户=4），通知的具体文案和渠道（Push/SMS/站内信）由通知服务控制
验证方法	测试环境触发一笔入金，确认通知内容和渠道
审批要求	产品确认

场景十一：修改冲正流程

例：冲正前增加二次审批 / 冲正后不自动解绑银行卡

维度	说明
改什么	入金冲正的执行逻辑、前置校验、后置操作
在哪改	`deposit/src/app/Business/Deposit.php:877-935`（入金冲正 `reverse()` 方法）
配置类型	代码常量 — 需发布
影响链	冲正流程修改直接影响已完成入金的资金撤回能力。修改前置校验可能导致应冲的冲不了；修改后置操作可能遗漏解绑/通知步骤
验证方法	Staging 环境创建测试入金 → 完成入账 → 执行冲正 → 验证 Apply.status=5、SBA Procedure 成功、银行卡解绑状态、通知触发
审批要求	风控团队签字（必须）+ 产品确认 + 运营知晓
回滚	恢复原代码 → 重新发布。已被新逻辑处理的冲正不受影响（冲正不可撤销）

常见变更场景：

变更	改动位置	注意事项
冲正前增加审批步骤	`reverse()` 方法入口处添加审批检查	当前冲正是直接执行、无二次审批。增加审批会延长冲正时效
冲正后不自动解绑银行卡	`reverse()` 中的解绑逻辑	不解绑可能导致下次入金仍然走绑卡通道
增加冲正金额上限	`reverse()` 前置校验	超限的冲正需升级审批（如大额走主管审批）
修改冲正通知模板	通知服务消息模板配置	不在 deposit 服务管辖内
批量冲正限制	`/deposit/batch` 接口	当前无批量数量限制，可加上防误操作

变更风险矩阵

变更	技术风险	业务风险	改动周期	建议灰度方式
调整容差	低	高（误匹配）	1~3 天	先用历史数据回测
调整限额	低	高（大额异常）	1~3 天	按银行分批调整
修改超时	低	中	1~3 天	按银行分批调整
调整 2412	低	高（对账异常）	1~3 天	不建议灰度，必须全量验证
风控规则	低	中	即时	按用户粒度操作
匹配频率	中（DB 负载）	低	0.5~1 天	按银行逐步提频
新增银行	高	中	3~6 周	新银行独立上线
新增 eDDA	高	低	数月	新银行独立上线
新增币种	中	低	2~3 周	按币种逐步开放
修改通知	低	低	1~2 天	灰度推送
修改冲正流程	中	高（资金安全）	1~3 天	必须全量验证

读完之后

我想...	去看
理解 10 种入金方式的全景	入金方式总览
看匹配容差和限额的详细规则	匹配与自动入账
查某个参数的具体数值	入金规则速查
了解 eDDA 协议和错误码	eDDA 代扣入金
看出金侧有什么变更场景	出金变更指南
了解退款和冲正机制	退款与冲正

这个页面有帮助吗？

入金变更指南 ​

怎么用这页 ​

配置类型速查 ​

变更审批流程 ​

Staging 验证通用指南 ​

场景一：调整某银行的匹配容差 ​

场景二：调整自动入账限额 ​

场景三：修改超时天数 ​

场景四：调整 2412 暂停窗口 ​

场景五：修改风控规则 ​

场景六：调整匹配引擎频率 ​

场景七：新增银行入金通道 ​

开发清单 ​

前置条件 ​

审批要求 ​

参考工期 ​

任务依赖与并行度 ​

回滚策略 ​

场景八：新增 eDDA 支持银行 ​

场景九：新增币种支持 ​

场景十：修改入金通知逻辑 ​

场景十一：修改冲正流程 ​

变更风险矩阵 ​

读完之后 ​