摘要：本篇是"银行业经营收益引擎"系列第 4 篇，讲大额资金异动监控与存款流失挽留。存款是银行的根基，大客户资金一动就是几千万上亿，可现在的发现方式还是靠柜面报告和客户经理人情，钱走了才知道，挽留靠运气。极昆仑iInsight 做四件事：①当天巡检大额异动（大额转出、活期转定期提前支取、质押解押），不用等月末报表；②当天归因——客户为什么走，线索里包括客服通话记录里"他行利率高 0.3%"、客户经理工作日志里客户提过他行产品这类非结构化信息；③生成一户一策挽留方案（利率优惠申请、专属产品、服务升级、高层拜访）派给客户经理；④要求 24 小时内首次触达，触达结果回填。收益按"年度大额流失资金 × 挽留率提升 × 净息差"算：示例按一年流失 30 亿、挽留率 15%→45%、净息差 1.6% 算，一年挽回约 1400 万（只是举例不是承诺）。兑现确定性标"中"——挽留率提升要靠客户经理执行力和产品资源，而且营销场景可以做 A/B 对照来验证（跟风控场景不同），但归因和触达的效率当天就能看。

大客户资金走了才知道，挽留靠运气

先破一个误区：很多人觉得大客户资金流失是"防不住"的——客户想走，你拦不住。真相是，大客户走之前是有信号的：他开始做小额试转、他行理财到期、他行客户经理来挖角、他最近对服务有投诉、他打听过利率——这些信号一直在，只是散在柜面、客服、客户经理的脑子里，没人聚起来看。

还原一次大客户流失的真实过程：

• 某对公大户在行里 8000 万活期，最近三个月流水越来越少，柜面经办发现他往他行转了几笔测试金额，没当回事，也没上报；

• 一个月后，8000 万一次性转走。客户经理得知时，钱已经到隔壁行账上了；

• 事后复盘才知道，他行给了上浮利率，客户已经在隔壁行开了户、办好了手续——整个决策过程有三个月，行里一次都没察觉。

这不是段子，是很多行的常态。原因有三个：

1. 发现靠人，滞后。 大额异动主要靠柜面经办碰巧看到、客户经理偶然得知。柜面没有系统性地把"大额转出"报给客户经理，月末季末冲存款时才发现钱没了——等报表出来，人已经走了。

2. 归因靠猜，不知道客户为什么走。 就算发现钱走了，也说不清原因：是利率？是服务？是他行挖角？还是客户经营变故？不知道原因就没法挽留——挽留不是"求他别走"，是"知道他为什么想走，给一个留下来的理由"。

3. 挽留靠运气，没有方案。 客户经理知道了，也是临时打电话问"您怎么把钱转走了"，没有一户一策的方案，拿不出利率优惠、专属产品、服务升级这些筹码，更不知道 24 小时内必须触达。挽留变成人情，成功靠运气。

一个脱敏细节（示例口径，非实测）：某城商行复盘一年大额流失客户，发现其中相当一部分在流失前 30 天内有可识别信号——大额试转、他行产品到期、客服投诉、理财提前支取——但这些信号没有一个被系统性收集过。如果流失前 30 天就能聚出信号、归因清楚、派人触达，挽留窗口是真实存在的。

顺带说一句：存款流失挽留和违约预警（场景 1）有个本质区别——营销场景可以做 A/B 对照（一部分客户用新方案挽留，一部分照旧，对比挽留率），风控场景不能。所以这个场景的挽留率提升，是可以被严格验证的，只要银行愿意配合跑对照。

传统方式 vs 极昆仑iInsight 对比表

关键差异：传统方式是"钱走了才知道，然后靠人情碰运气"；极昆仑iInsight 是"客户想走之前 30 天就看到信号、当天归因清楚、第二天就有一户一策方案在客户经理手里"。

挽留的核心不是客户走了以后补救，是在他犹豫的那 30 天里给一个留下来的理由。

自家试算：你拿自家存款流水就能算

以下所有数字为示例口径，只是举例不是承诺。请用自家数据套公式自算。

① 基础参数（3 个数）

② 极昆仑iInsight 带来的动作变化

• 当天巡检：核心系统大额异动实时接入，大额转出、活期转定期提前支取、质押解押、批量转出，当天出预警，不等报表；

• 当天归因：Agent 拆解流失原因——利率（他行竞品动态、客服通话记录里"他行利率高 0.3%"）、服务（投诉记录、客户经理变动）、产品（他行理财到期、我行产品到期未续）、经营变故（流水异常），归因到"这个客户到底为什么想走"；

• 一户一策方案生成：按归因结果给方案——利率敏感给利率优惠申请单（走审批）、产品敏感给专属产品匹配、服务敏感给服务升级 + 高层拜访预案，附证据链（为什么判断他是这个原因）；

• 24 小时触达派单：方案派客户经理企微，要求 24 小时内首次触达，触达结果（客户反应、是否接受方案）回填，A/B 对照分组标记。

动作变化量化：发现时点从"流失后（月末/季末才发现）"提前到"流失前 30 天（异动当天）"；归因从"不知道原因"到"当天归因到利率/服务/产品/经营四类"；挽留率从 15% 提到 45%（推演值）。

③ 经营结果（公式 + 举个例 + 因果链）

公式：

年化挽回收入 ≈ L × ΔP × NIM

其中：

• L = 年度大额流失资金

• ΔP = 挽留率提升幅度（挽留率：本要流失、实际被挽留下的比例）

• NIM = 净息差（资金留下来一年的利差收入）

举个例（5000 亿资产城商行口径）：

L = 30 亿，ΔP = 30pp（15%→45%），NIM = 1.6%

30 亿 × 30% × 1.6% ≈ 1440 万 ≈ 1400 万

这个 1400 万是增量收入口径（示例口径）：挽留住的资金（30 亿 × 30% = 9 亿）留在行里一年产生的利差收入。它是"资金留一年"的持续收入，不是一次性收益。别理解成"多赚了 1400 万现金"，是"本来要走的 9 亿存款留下了一年"。

你家用自家数代：L 是 10 亿还是 80 亿，ΔP 是 10pp 还是 40pp，NIM 是 1.4% 还是 2.0%，自己算。L=10 亿、ΔP=10pp、NIM=1.4% 算出来约 140 万；L=80 亿、ΔP=40pp、NIM=2.0% 算出来约 6400 万——值不值立项，你比我清楚。

诚实边界（务必看）：①挽留率提升不是 AI 单方面能保证的——它取决于客户经理执行触达、产品资源跟不跟得上（利率优惠要审批，批不下来挽留就是空话）、管理层推不推动；②挽留率提升要跑 A/B 对照才能证明（营销场景可以做对照组，这是它和风控场景 1 的本质区别），不是上线就自动 45%；③这是增量收入口径，兑现确定性标"中"——归因和触达效率当天可验，但挽留率要等对照期。

因果链（为什么这个数能成立）：

经营场景：大额资金异动监控与存款流失挽留

    ↓ 第一层（技术能力）

    · 智能问数 + 确定性编译（异动巡检、归因计算 100% 正确可追溯）

    · 非结构化融合（客服通话"他行利率高 0.3%"、客户经理日志、投诉记录）

    · 行动方案生成（一户一策挽留方案 + 证据链，不是"建议关注"）

    · 工作流对接（企微派单 + 24 小时触达 SLA + 触达结果回填）

    ↓ 第二层（经营动作变化）

    ① 发现时点从"月末季末冲存款时发现（人已走）"→"流失前 30 天异动当天巡检"

    ② 归因深度从"为什么走说不清"→"当天归因到利率/服务/产品/经营四类"

    ③ 挽留方案从"临时打电话"→"一户一策（利率优惠/专属产品/服务升级/高层拜访）+ 证据链"

    ④ 触达时效从"看客户经理自觉"→"企微派单，24 小时内首次触达，结果回填"

    ⑤ 效果验证从"挽没挽住说不清"→"A/B 对照验证挽留率"

    ↓ 第三层（经营结果，自家数据自算）

    年化挽回收入 ≈ L × ΔP × NIM

效果参考口径（示例值，非客户实际回款）：

• 年度大额流失资金 30 亿（大额支取 + 流失判定口径）；

• 极昆仑iInsight 巡检 + 归因 + 一户一策 + 24 小时触达，挽留率从 15% 提到 45%（推演值，需 A/B 验证）；

• 挽留资金约 9 亿，按净息差 1.6% 算，一年挽回约 1400 万（示例口径）。

以上 30 亿、15%、45%、1400 万均为示例值，不是承诺。你家实际数取决于大额流失体量、客户经理执行力、产品资源（利率优惠审批能不能批下来）。这个场景兑现确定性"中"，因为挽留率要等 A/B 对照期验证，但归因和触达效率当天可验。

为什么不是市面上 ChatBI 类、智能问数类产品能做

这是本场景最关键的差异化。通用 ChatBI 和智能问数产品在存款挽留场景里能做的，和 极昆仑iInsight 做的，差"归因 + 方案 + 触达"三层。

壁垒拆解：

壁垒 1：归因要非结构化信息，ChatBI 只看得见流水 "客户为什么走"这个问题的答案，一半在流水里（转出金额、频次、去向），另一半在非结构化信息里——客服通话记录里客户那句"隔壁行利率比你们高 0.3%"、客户经理工作日志里"客户最近提了好几次他行理财收益"、投诉工单里客户抱怨服务。通用 ChatBI 查不出这些，因为它只查结构化表。没有这些信息，归因就只能猜"他可能就是走了"，挽留方案也就无从谈起。

壁垒 2：要的是"方案"，不是"名单" 通用 ChatBI 给你一张流失预警名单，到此为止。剩下"这个客户该给利率优惠还是专属产品、优惠申请单怎么走审批、高层拜访谁去"——还得人干。极昆仑iInsight 的终点是一户一策挽留方案包：归因结论 + 对应方案 + 证据链 + 审批单 + 派单对象，客户经理拿到就能执行。这个"从名单到方案"的跃迁，ChatBI 跨不过去。

壁垒 3：24 小时触达是工作流，不是报表 方案生成只是开始，24 小时内触达、触达结果回填、A/B 对照分组——这是完整的执行闭环。通用 ChatBI 没有工作流能力，派不下去、收不回来，挽留率提不上去。极昆仑iInsight 的 work_order 表承载派单 → 触达 → 回填 → 对照全链路，是挽留率可验证的基础。

一句话：通用 ChatBI 解决"查得到流水、拉得出名单"，极昆仑iInsight 解决"非结构化信号融得进、归因归得到原因、一户一策方案生成、24 小时触达闭环"——而存款挽留要的是归因 + 方案 + 触达，不是一张表。

怎么试

这个场景的归因和触达效率当天就能验，挽留率提升需要一段 A/B 对照期（这恰好是它的优势——营销场景可以做对照组，结果可严格验证）。

如果你家也遇到"大客户资金走了才知道、柜面看到异动不当回事、客户经理挽留靠人情"这个情况，可预约一次 30 分钟需求对齐（不带销售，只看场景适配度——你家客服通话记录/客户经理工作日志有没有留文本、大额异动数据能不能实时接入核心系统）。

需要的话可以进一步做 概念验证：拿你家历史大额流失客户（已经流失的）跑一遍"异动识别 + 归因 + 挽留方案生成"，对比三件事：①能不能提前发现——流失前 30 天，异动信号能不能被巡检到；②归因准不准——AI 判断的流失原因，跟实际原因对不对得上（可以找客户经理逐个核对）；③方案合理性——生成的一户一策方案，客户经理觉得能不能用。

验证什么、不验证什么，先说清楚：

1. 概念验证验证的是异动巡检覆盖率、归因准确性、方案可用性——这三样用历史流失客户复盘，当天能核；

2. 概念验证不承诺挽留率从 15% 到 45%——挽留率提升要跑 A/B 对照（一批客户用新方案挽留、一批照旧），还要客户经理执行到位、产品资源批得下来，这是正式立项后要做的事，不是 POC 能证的；

3. 涉及客户信息的 POC 走数据授权路径，POC 阶段可先用脱敏/样例数据演示全流程。

想试？拿你家一年内流失的大客户名单，我们跑一遍"当时该不该发现、该归因到什么原因、该给什么方案"的复盘给你看。信号能不能提前看到、归因准不准、方案客户经理认不认，当场判断。