财富管理客户开户为何需要的不只是 AI
Wealth Management Client Onboarding Needs More Than AI
Databricks 提出"受治理的案件上下文"(governed case context),把 CRM、KYC、筛查、托管和工作流系统中的证据、案件状态、已完成控制项与决策历史整合为带版本、可溯源的统一视图。
即便每个系统都完成了各自的工作,财富管理客户开户仍可能停滞不前。文件已收集,筛查结果已返回,工作流任务已完成。然而案件仍在等待,因为必须有人判断发生了什么变化、哪些证据是当前有效的,以及由谁负责处理该例外情况。
对客户而言,这些边界是看不见的。他们经历的是一段旅程,并期望自己的信息和进度随之推进。然而在公司内部,这段旅程横跨客户关系管理(CRM)、文档、了解你的客户(KYC)、筛查、托管和工作流系统,每个系统都掌握着案件的不同部分。
各公司已投入资源让这些单独步骤更快,而 AI 正在进一步加速它们。但如果下一个团队仍必须重建案件、核对证据,并重新打开看似已完成的工作,那么更快的提取、筛查摘要或路由决策就收效甚微。
开户流程仍在这些交接环节损失时间。现代平台必须跨系统连接案件,在条件变化时协调工作,并保留流程所依赖的控制措施和人工判断。若做不到,成本就会在系统之间累积。
为什么财富管理客户开户耗时如此之长?
第一项成本是客户感受最直接的:时间。
在新加坡,开设私人银行账户大约需要 6 周,复杂案件耗时更长。2026 年 5 月,新加坡金融管理局(MAS)表示,由 MAS 与业界共同领导的开户工作组的举措预计将把该中位时间缩短至一个月以内。
在公司内部,这体现为员工时间。凯捷《2026 年世界财富报告》发现,144 位财富管理高管中有 60% 缺乏统一的客户视图。同一报告发现,来自 16 个市场的 1,317 位关系经理表示,运营工作占用了他们 41% 的时间。该数字涵盖广义的财富运营,而非仅开户,但它显示了日常协调可能吸收多少产能。
开户旅程本身涉及许多团队。2024 年安永对十余家全球资产管理公司的报告发现,超过半数在开户中涉及至少 10 个团队。然而只有 15% 报告与其 CRM 系统实现了强集成。
“超过半数的全球资产管理公司在开户中涉及至少 10 个团队,然而只有 15% 报告实现了强 CRM 集成。”
2024 年毕马威与私人财富管理协会对 35 家香港私人财富机构的研究指出,开户需求是成本上升和客户体验恶化的一个因素。
这些发现横跨不同市场、人群和监管制度,每一项都需结合背景解读。纵观这些发现,模式是一致的——客户信息碎片化,众多团队拼凑起整段旅程。
公司通过员工工时、反复查找证据、人工核对、例外处理和控制历史准备来吸收这种协调成本。集成、维护和变更测试则增加更多成本,而开户和资金到位仍在等待。
更快的任务并不总能带来更快的开户旅程。系统可以按时完成其工作,却仍让案件在下一个交接环节停滞。
AI 可以进一步加速每项任务,但它不会自动消除系统之间的摩擦。
为什么任务级 AI 无法加速开户旅程?
AI 已经进入财富与资产管理领域。在 2025 年 安永对 100 位决策者的调查中,财富管理与资产管理公司各占一半,95% 的公司表示已在多个用例中规模化应用生成式 AI,同时 78% 的公司正在探索代理式 AI。然而,将这一势头转化为可衡量的业务价值仍是一项挑战,仅有 27% 的高管表示 GenAI 带来了实质性的业务影响。
审视工作本身就能解释这一差距。AI 可以提取文档字段、总结筛选结果,或推荐下一步工作流操作。每项能力或许能改进单个应用内的某项任务,但交接仍依赖当前证据和对变更内容的清晰记录。团队还需要知道先前的工作是否必须重新审视。
AI 代理使这种依赖关系更加重要,因为在专业代理和已批准工具之间路由工作需要共享的案件状态。该状态必须显示哪些已完成、哪些已过时,以及哪个异常阻碍了下一步。没有它,更快的编排可能重现它本应减少的同样碎片化问题。
客户入驻中的受治理案件上下文是什么?
受治理案件上下文是对每个客户入驻案件的当前、带版本、可溯源视图。它汇集了证据、案件状态、已完成的控制项、未决异常、代理活动和决策历史。由于上下文带有版本,团队可以看到发生了什么变化、变化影响了什么,以及先前的工作是否需要重新审视。
入驻的不同环节可以存在于不同位置。核心客户和托管记录可能保留在其指定系统中,而证据处理、控制项、模型和案件工作流可以在 Databricks Data + AI Platform 上运行。受治理案件上下文在一个受治理视图中连接这些工作,如下图所示,同时保留记录所有权和决策权限。在 Databricks 上,Unity Catalog 集中管理该上下文的访问控制、血缘和可审计性,而 Delta Lake 和 Apache Iceberg 等开放表格式支持可靠的数据管理和跨系统互操作性。
受治理案件上下文只有在帮助下一个代理或审核员理解并推进案件时才有用。一个实用的测试是,他们能否在不重建历史的情况下回答四个问题:
- 哪些证据是当前的,由哪个来源和版本支持?
- 哪些工作已完成,发生了什么变化,哪些结果现在可能已过时?
- 哪些仍未解决,下一个允许的操作是什么?
- 哪些工作可以由代理或已批准工具执行,哪些必须由授权审核员决定?
将这些答案集中在一处,受治理的监督代理就可以从当前案件状态恢复工作。它可以将独立任务分配给专业代理,调用已批准工具,并在需要判断时引入审核员。它还可以标记相互冲突的证据并组装完整的审核包,同时该包背后的证据、变更和操作仍附属于案件。
价值来自在整个旅程中运用这一上下文。现代平台必须保持其时效性,围绕它协调代理和人员,并从第一份证据到最终决策全程保持可见性和治理。
一个为智能体就绪的入驻平台需要什么?
要让受治理的案例上下文发挥作用,需要四项平台能力。它们共同解决了前文指出的摩擦:在每次交接时重建案例、手动协调工作、治理对敏感数据的访问,以及在不了解完整旅程的情况下衡量任务。
- 维护案例的当前视图:
随着证据到达、控制措施运行并做出决策,平台应更新受治理的上下文,并保留其与底层来源的链接。被指派处理特定记录的系统可以保持权威性,而智能体和团队则基于同一版本化上下文开展工作。在 Databricks 上,Lakeflow Connect 将受支持源系统中的变更引入平台,Databricks AI Functions 提取并分类新证据,Lakebase 维护入驻应用所使用的实时事务状态。
- 协调智能体工作,同时让人保留权威:
受治理的监督智能体应基于当前案例状态选择下一个被允许的操作,将定义好的任务发送给专业智能体或经批准的工具,并在需要判断时引入合格的审核者。人仍然对例外、覆盖和入驻审批负责。在 Databricks 上,Supervisor Agents 可以在受治理的企业数据上协调专业智能体和经批准的工具,包括 Unity Catalog 函数、MCP 服务和 Genie Agents(原 Spaces)。
- 治理数据、工具和操作:
入驻涉及个人可识别信息(PII)和其他敏感记录。每个智能体应只能访问其任务所需的数据和工具,并在适当情况下对敏感字段进行掩码或不予提供。智能体活动应保持可追踪和可审查。在 Databricks 上,Unity Catalog 在受治理的数据和 AI 资产上提供细粒度访问控制、掩码、血缘和可审计性,而 Unity Gateway 通过控制每个智能体可以调用哪些模型和 MCP 工具、应用护栏、跨模型路由请求、执行预算和速率限制,并记录每个请求,将这种治理扩展到智能体运行时。
- 端到端衡量:
团队应监控智能体质量、延迟、可靠性和升级情况,以及周期时间、手动接触、返工、例外和从审批到放款的时间。运营视图还应包括集成变更、重复的数据移动以及准备控制证据所需的工作量。Databricks Apps 可以在队列和案例工作区内嵌入 Databricks AI/BI 仪表板,让运营和合规负责人能够将旅程绩效与活跃案例一起综合查看。
这些能力共同将受治理的案例上下文转变为一种运营模式。下图展示了上下文、受监督的智能体和人工审核在实践中如何协同工作。
受监督的 AI 智能体如何协调客户入驻?
该架构将四项能力围绕每个案件置于一个循环运行的运营闭环中。信息可从源系统传入,而证据处理、控制、风险模型和入职工作流则在平台上运行。每个结果都会返回受治理的案件上下文,并附带其来源引用和历史记录,为下一个智能体或审核人员提供案件的当前状态。
受治理的监督智能体读取该上下文并选择下一个被允许的操作。根据案件情况,它可以调用经批准的工具、将工作分配给专业智能体,或让审核人员参与。当新证据使先前结果过时时,它可以重新打开受影响的工作,而不是重新启动整个案件。它还会监控完成情况和新鲜度,在案件推进之前标记缺失或冲突的控制结果。
一个简单的例子展示了该循环如何运作。 假设有一个案件正在等待一份必需的文件。监督智能体可以识别出这一缺口,准备一封客户外联邮件以供审核,并暂停任何依赖缺失证据的工作。一旦审核人员批准外联,且文件通过指定渠道送达,案件上下文就会更新。随后,监督智能体可以触发文件处理,仅重新运行受影响的检查,并将案件路由到下一个被允许的步骤。
在此示例性设计中,每个专业智能体都有明确的职责:
- 文档智能体读取提交的文件,提取所需信息,并标记缺失的证据。
- KYC 与筛查智能体汇总来自身份、KYC 和筛查控制的结果。
- 风险分析智能体根据既定规则和控制结果评估已核实的案件事实。
- 案件摘要智能体准备一份评估草稿以供审核。
每个结果都会返回受治理的案件上下文,并附带其支持证据和来源引用。监督智能体利用该更新后的状态来确定是否应由另一个智能体采取行动、是否需要人工审核,或案件是否可以继续推进。
人员保留决策权。 在受控工作区中,审核人员可以检查证据、请求补充信息、解决异常、记录带有理由的覆盖决定,或在其权限范围内做出决定。他们的操作会成为案件历史的一部分,并可能触发另一个智能体任务或有针对性的重新运行。案件建议仍为评估草稿。警报处置、风险接受和入职批准仍由被授予该权限的系统和审核人员负责。
治理贯穿整个闭环,与工作流程相伴而行。细粒度访问控制将每个智能体限制在其工作所需的数据和工具范围内。智能体追踪记录每个智能体做了什么、耗时多久以及预估的模型成本。团队可以利用这些历史记录评估质量、发现性能退化并调查故障。这些追踪记录支持 AI 与模型风险监督,而经授权的决策仍保留在业务记录中。追踪记录与决策记录相结合,为合规和审计团队提供了每个案例可重建的完整说明:审查了哪些证据、运行了哪些控制、每个智能体产出了什么,以及谁批准、推翻或升级了结果及其原因。该记录支持 AML/KYC 记录保存和检查准备,因为企业可以展示每个决策是如何达成的,而不是事后拼凑历史。
审查员工作区记录人工操作,而应用程序维护工作流所需的实时案例状态。在做出授权决策后,受控集成会将批准的结果记录到指定负责该结果的系统中。在 Databricks 上,审查员工作区可以作为 Databricks App 运行,由 Lakebase 维护实时案例状态。
这种运营模式的价值必须贯穿整个旅程来衡量,从收集第一份证据到账户入金。否则,更快的智能体或控制可能只是将延迟转移到下一个交接环节。
企业应如何衡量智能体辅助的开户流程?
当架构改善整个开户旅程时,它才创造价值。更快的智能体响应固然重要,但真正的考验在于案例是否更早推进、团队协调工作的时间是否减少,以及控制是否仍然有效。
从一条高摩擦路径开始。选择一个交接、返工和延迟已经显而易见的开户旅程。在试点开始前,协调财富运营、合规、数据和技术负责人。就需要哪些证据、谁拥有每条记录和决策、哪些环节必须由人工判断,以及主管可以触发哪些操作达成一致。
在改变工作流之前建立基线。从三个方面衡量当前旅程:
- 成本与产能:每完成一次开户的成本,以及每个案例上花费的顾问、运营和合规工时。
- 旅程表现:中位数和第 90 百分位周期时间、批准到入金时间、人工接触次数、访问的系统数量、文档返工、异常、未完成案例和放弃率。
- 技术与控制:运行和变更集成的成本、重复的数据移动,以及汇集控制、血缘和审计证据所需的工作量。
这些指标共同揭示了往往消失在团队队列和系统交接中的工作。它们还表明,受治理的案例上下文是减少了重复的对账和证据查找,还是仅仅将工作转移到了别处。
在试点开始前设定成功阈值。评估速度、员工工作量、智能体质量、追踪完整性和控制有效性。主管和专家智能体应减少可避免的交接,并为审查准备更完整的案例。它们的追踪记录应使工作更易于评估和调查。
例外、覆盖和重新开启案件的发生率仍需进行根因分析和质量审查。发生率上升可能表明存在控制问题,也可能意味着新流程正在发现此前被遗漏的问题。
从整个旅程审视结果:
- 如果中位周期时间改善而第90百分位没有改善,说明复杂案件仍然卡住。
- 如果坐席处理速度加快而审批到资金到账的时间保持不变,说明瓶颈已经转移。
- 如果人工介入次数下降而控制证据准备时间持平,说明最终审查材料仍需改进。
当收益从首次收集证据一直保持到账户资金到账,且控制有效性依然完好时,再扩大规模。现代开户的标准很明确:更快推进案件,让每个坐席操作都可审查,并在任何需要判断的地方保留人类权威。
常见问题
为什么仅靠 AI 不足以解决财富管理客户开户问题?
更快的文档处理、筛查或路由并不能解决证据碎片化、案件状态和决策历史的问题。当团队必须确定发生了什么变化、哪些工作仍然有效以及应由谁采取行动时,开户仍可能在下一个交接环节停滞。
什么是受治理的案件上下文?
受治理的案件上下文是对开户案件当前状态、来源可追溯且带版本信息的视图。它连接证据、案件状态、控制结果、例外、坐席活动和决策历史,使坐席和审查人员能够基于同一上下文开展工作。
在保持人员控制的前提下,受监督的 AI 坐席如何帮助完成 KYC 和客户开户?
受治理的监督坐席可以将工作路由到负责文档智能、KYC 筛查和风险分析的专家坐席以及经批准的工具,并在需要判断时引入审查人员。细粒度访问控制和追踪使坐席活动可审查,而人员保留对例外、覆盖和开户审批的权威。
受治理的案件上下文是否要求公司替换现有系统?
不需要。核心记录可以保留在 CRM、托管或其他指定系统中,而证据处理、控制、模型和工作流在 Databricks Data + AI 平台上运行,由 Unity Catalog 治理数据、模型和坐席工具。受治理的案件上下文连接各项工作,同时保留记录所有权和决策权威。
公司应如何衡量坐席辅助开户的价值?
公司应衡量整个开户旅程的结果,而不是仅依赖坐席速度。有用的指标包括周期时间、审批到资金到账时间、人工介入次数、返工、员工投入、集成成本和控制有效性。当改进在端到端范围内持续保持且坐席操作仍可审查时,公司应扩大规模。
从一个高摩擦的开户旅程开始,衡量从首次证据到账户资金到账的影响。了解 Databricks 如何帮助金融服务公司构建受治理、可追踪且人员保持控制的坐席式工作流。
来源:Databricks Blog · databricks.com