深色模式
出金变更指南
本页说明
讲什么：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 天 | 灰度推送 |
读完之后
| 我想... | 去看 |
|---|---|
| 理解出金的完整流程 | 出金生命周期 |
| 看每条规则的详细解释 | 出金规则手册 |
| 查某个状态码是什么意思 | 出金数据字典 |
| 看入金侧有什么变更场景 | 入金变更指南 |
| 了解某家银行的对接细节 | 银行能力矩阵 |
这个页面有帮助吗？