简介恒生财富管理系统的完整方案文档面向银行理财业务产品经理、系统设计人员及财富管理相关从业者重点应对客户资产配置难度大、理财产品同质化等业务痛点。压缩包共1个文件为docx格式文档大小约594KB适合直接阅读、检索与二次整理。内容系统梳理了客户管理、营销管理、产品管理、理财规划、投资规划及跟踪、金融资讯、支持系统七大功能模块并展开系统特点与农总行、大连银行、杭州银行等典型案例同时补充私人银行专户理财系统、客户经理绩效考核系统两类扩展方案。文档结构完整、描述详尽既可作为银行财富管理系统建设或方案选型时的参考蓝本也可用于产品需求梳理与业务知识学习。已有161人学习下载。1. 财富管理系统不是客户关系管理的升级版而是资管数字化的主战场我见过太多机构把财富管理系统理解为“给客户建档案、记几笔交易”的内部工具结果上线三个月后理财师依旧开着三个系统一个查客户资产一个录产品认购还有一个用 Excel 手工算客户收益。某公司曾找我复盘一套已交付的“恒辰财富管理系统”项目他们当时最大的痛不是功能不够而是客户、产品、交易三个域的数据口径互相打架日终对账差异能到几百笔。这里要聊的财富管理系统本质是把客户、资产、产品、交易这四类主数据统一建模再通过文档固化成可评审、可排期、可落地的实施方案。适合谁看正在选型或自研财富管理系统的技术负责人、业务分析师、方案架构师——你想知道这东西要不要做、怎么做、坑在哪读完就能照着推演一遍。2. 拆解一套可落地的财富管理系统核心域与数据模型2.1 财富管理系统为什么要分四个核心域而不是按菜单分很多方案文档会把系统画成“客户管理、产品销售、交易查询、报表中心”四个模块这种按菜单拆的方式开发起来很顺手但一碰到跨模块的数据问题就乱了。比如“客户总资产”这个指标到底是从产品持仓算还是从账户资金加总如果按菜单分客户模块算一遍报表中心又算一遍两边口径不一业务一开票就炸。我一般建议按领域拆分而不是按页面拆。财富管理系统最稳定的骨架是四个核心域客户域、资产域、产品域、交易域。客户域管“人是谁、能不能买、风险等级是什么”资产域管“客户名下的钱和份额在哪里”产品域管“货架上有什么、净值多少、风险多高”交易域管“买卖动作怎么发生、怎么确认、怎么清算”。四个域之间通过客户ID、账户号、产品代码关联任何页面上的功能都能映射到这四条链路。下面这张表是四域的关键对象和关系写进方案文档时可以原样复用。核心域关键对象典型字段对外服务客户域客户主数据、KYC信息、风险测评cust_id, risk_level, id_type客户视图、适当性检查资产域资金账户、持仓、产品份额acct_no, shares, cost, nav总资产查询、收益试算产品域产品目录、净值、费率prod_id, nav, fee_rate产品筛选、收益预估交易域认申购、赎回、撤单、确认order_no, order_status下单、撤单、对账划分边界带来的直接收益是资产域和产品域解耦。产品净值的变动不会引起持仓表的频繁更新资产域只需要在每日日终根据产品域的快照刷新估值。否则行情一波动整个交易链路都会被拖慢。2.2 用一张 SQL 看客户统一视图怎么落库客户统一视图是财富管理系统最基础但又最容易做错的一张表。很多项目一开始只想着“我要一个客户总资产”结果直接做了一个汇总字段放在客户表里每次更新需要跑全量任务。正确做法是拆成客户、账户、持仓、产品四张表通过外键关联查询时再聚合。-- 客户主表 CREATE TABLE customer ( cust_id VARCHAR(32) PRIMARY KEY, cust_name VARCHAR(64), id_type VARCHAR(8), id_no_hashed VARCHAR(128), risk_level TINYINT, created_at DATETIME ); -- 资金账户表 CREATE TABLE account ( acct_no VARCHAR(32) PRIMARY KEY, cust_id VARCHAR(32), acct_type VARCHAR(16), open_date DATE, status TINYINT ); -- 产品表 CREATE TABLE product ( prod_id VARCHAR(32) PRIMARY KEY, prod_name VARCHAR(128), risk_level TINYINT, nav DECIMAL(18,4), nav_date DATE, fee_rate DECIMAL(10,6) ); -- 持仓表 CREATE TABLE position ( pos_id BIGINT AUTO_INCREMENT PRIMARY KEY, acct_no VARCHAR(32), prod_id VARCHAR(32), shares DECIMAL(18,2), cost DECIMAL(18,2), update_time DATETIME );字段说明id_no_hashed不是证件号原文而是哈希后的值。这么做是合规要求也是降低泄露风险的常见手段业务查询可以用哈希值做等值匹配但不做反向解密。risk_level用 TINYINT 而不是 varchar是为了让适当性匹配能直接做数值比较比如客户风险等级不能低于产品风险等级。nav用 DECIMAL(18,4) 是给净值保留四位小数避免浮点数误差。查询某个客户总资产时不直接查 customer 表而是SELECT SUM(shares * nav) FROM position JOIN product ... WHERE acct_no IN (...)。这个查询如果每次实时跑客户账户多的时候会很慢所以在生产环境要做资产聚合并写入快照表。2.3 收益试算的三种口径与“一把尺子”问题收益试算是财富管理系统里被吐槽最多的功能。原因不是算法多难而是业务方在不同地方提到的“收益”根本不是同一个东西。我参与过的某模拟项目 X 里产品经理要求“展示客户持有产品的累计收益”研发按持仓市值减本金算结果债券类产品用的是摊余成本法日终估值出来的数值和客户自己手机银行看到的差了一大截。三种常见口径是持仓成本法、摊余成本法、市值法。持仓成本法适合股票型和混合型产品公式是(当前单位净值 - 持仓成本单价) * 持仓份额摊余成本法适合货币基金和短期理财用买入成本加应计利息净值波动小市值法适合净值型产品直接用最新净值乘份额减累计投入本金。一个系统里必须预置valuation_method字段产品表里每个产品标明口径所有收益试算服务统一读这个字段而不是给上层页面各算各的。口径适用产品计算公式波动特征持仓成本法股票型、混合型(最新净值 - 成本单价) * 份额随净值波动敏感摊余成本法货币基金、短期理财成本 应计利息日常几乎不波动市值法净值型、FOF最新净值 * 份额 - 累计本金跟随市场波动这个“一把尺子”问题不解决后面做客户资产汇总、绩效归因全部会翻车。所以在方案文档的数据模型章节务必把估值口径设计成枚举值并且在接口参数里强制传递。3. 从客户到资产业务主流程与产品接入设计3.1 KYC、风险测评与适当性匹配的完整链路财富管理系统不是一个只做记录的台账它要承载完整的销售适当性流程。我把它拆成七步每一步都对应明确的系统功能和数据落点。第一步客户建档写入客户主表第二步做风险测评问卷打分后得出风险等级第三步是产品池过滤把产品风险等级、起购金额、投资期限和客户测评结果做匹配第四步给出资产配置建议这一步可以不做得太复杂用一个简单的风险预算模型就能跑第五步产品下单第六步交易确认第七步投后监控与再平衡。这套链路里最容易偷懒的是第四步。很多团队觉得配置建议需要量化模型于是拖延不做只在系统里放一个“产品推荐位”。但财富管理系统的价值恰恰在于把适当性匹配和配置建议串起来。哪怕第一版只做“根据客户风险等级给出预设比例”也比没有强。预设比例可以写成一张配置表例如保守型客户固收类70%、权益类20%、现金类10%。步骤执行时要注意风险测评不是一次性的。客户资产规模变动超过一定阈值或者测评过期超过一年系统要强制重新测评。这个规则属于非功能需求但会直接影响业务合规必须在文档里写明否则开发会默认“做过一次就行”。3.2 产品接入为什么要先定义统一接口而不是接一个算一个产品接入是财富管理系统实施时最耗人力的一环。常见的机构会同时代销保险、公募基金、私募、信托、银行理财每种产品的接口报文格式都不一样。如果每个产品方对接一套开发团队会陷入无休止的字段映射中。我一般会先定义一个统一产品接入参数模型要求所有产品在经过中间件适配层后都转成同一套标准字段。下面是一份最小参数表也是产品接入接口的核心参数。参数名类型必填说明product_codeString是产品唯一编码product_nameString是产品展示名称product_typeString是基金/理财/保险/信托risk_levelInteger是1-5数字越大风险越高min_purchase_amountDecimal是起购金额navDecimal条件必填最新净值nav_dateDate条件必填净值日期fee_typeString是前端/后端/无fee_rateDecimal是费率百分比存小数statusInteger是0未上架1在架2下架参数写好后新接入一个产品方只需在适配层做一次格式映射核心系统不需要改动。这个设计的附加好处是监管要求查看“全量产品清单”时直接从产品标准表导出即可不用去每个接口拼数据。3.3 交易异步确认与对账时序财富管理系统的交易链路和普通电商不一样。用户下单那一刻系统不能立刻确认成交因为产品端要做份额确认和资金清算。常见做法是异步确认用户发起认申购后系统先锁定资金生成订单状态为“待确认”然后发送给下游 TA基金注册登记系统TA 在 T1 日返回确认成交份额系统再更新持仓。这个异步流程是天然的坑点。如果方案文档里没有写清时序研发容易做成同步等待导致页面超时。正确时序是下单→冻结资金→提交TA→TA日终确认→回写份额→解冻剩余资金。每一步都要记录流水号便于追踪。对账是最后一道防线我建议日终跑一个持仓与资金快照比对看看系统记录和 TA 确认的数据是否一致。对账差异超过阈值一定要告警而不是静默修复否则账目会越差越多。4. 把方案写成一份能执行的 docx从目录到评审4.1 docx 文档的目录结构让研发和业务都能看财富管理系统的标题本身就带着一个 .docx 文件这说明方案文档是项目交付的第一载体。可很多方案文档写出来只是“应付立项”目录只有背景、目标、功能清单、实施计划业务看着觉得全研发一看没有字段定义无从下手。我经手的文档会固定一个九章结构让业务能看懂业务边界研发能对着写代码。这份结构是1 项目背景与目标2 术语与口径3 业务架构4 功能需求5 数据模型6 接口清单7 非功能需求8 实施计划9 风险与问题。其中第 2 章是我特别想强调的。如果不在文档开头定义“总资产”“持仓收益”“日终估值”这些术语的含义后续开会就陷入无休止的口径争论。术语表可以用一张简单表格术语、定义、参考口径、备注。第 5 章数据模型不是给 DBA 看的而是要写清楚每个字段的长度、类型、约束、示例。第 6 章接口清单至少包含接口名、入参、出参、错误码。有了这两章研发估算工作量才靠谱。很多团队把文档画成架构图加流程图画完就交差结果到开发阶段才发现字段对不上返工成本极高。4.2 用表格写需求而不是大段文字需求描述最忌讳用一段段散文。我见过有人写“系统要支持客户查询资产并展示收益信息”这个需求没法验收。正确做法是把需求拆成可测试的条目用表格维护。每个需求条目有编号、模块、需求描述、优先级、验收标准。验收标准必须量化比如“客户选择任一产品后系统展示最新净值、持仓份额、持仓成本、浮动盈亏接口响应时间 P95 小于 1.5 秒”。用表格式需求还有一层好处开发排期可以按需求条目拆分测试用例直接引用需求编号评审时逐条过不会漏。下面是一个示例片段。编号模块需求描述优先级验收标准R001客户视图按客户查询名下所有账户及持仓P0展示时间小于 2 秒含冻结份额R002适当性产品风险等级高于客户风险等级时禁止提交认购P0前端提示并拦截后端再次校验R003收益试算支持按持仓成本法、市值法两种口径试算P1试算结果与日终估值差异小于 0.01 元注意写着“P0”的需求不要超过需求总量的三分之一。如果全是 P0等于没有优先级评审时大家会先吵最难的而不是先做最核心的。4.3 模板字段与版本管理docx 也可以持续集成docx 是 Word 格式最大的痛点是没法像代码一样 diff。两个版本之间改了哪句话靠人工比对很容易漏。我的做法是方案文档的主源用 Markdown 或 AsciiDoc 维护通过脚本转换成 docx 交付给业务方评审。评审意见回收到文档源码里下个版本再转一次。这样既能享受纯文本的版本管理又能拿到 Word 的展示效果。具体操作时在文档里使用固定的样式名称来控制标题层级不要手动改字体和缩进。模板字段也是有价值的比如用 Word 的文档属性域自动填充版本号和修改日期避免每次提交前手改文件头。还有一个细节文档里的接口定义和字段表尽量和代码仓库里的 YAML 配置同源。我一般会在文档中插入“此段由 config/product_schema.yaml 生成”的注释这样接口改版时文档重跑一遍脚本就能同步不会出现代码和文档各说各话的情况。5. 财富管理系统实施中的避坑清单5.1 客户总资产和持仓明细加起来对不上现象客户在资产总览页看到总资产 100 万但点进持仓明细逐条加总只有 98 万。原因总览页的数据来自资产快照表明细页实时查询持仓表快照生成时间和明细查询时间不在同一时刻或者两处用了不同的估值净值。解决统一日终快照的估值时点所有页面展示都读快照表不实时聚合快照表要记录snapshot_date和nav_date一旦发现对不上先查这两个时间戳是否一致。这个坑在方案设计阶段就能避免。我在项目里要求资产聚合任务必须是一个独立批处理跑完后生成一张对账结果表差异金额大于 1 元就要告警。没有这个机制线上发现问题时已经是一周后了数据回溯成本非常高。5.2 收益试算结果在不同页面不一致现象客户经理在客户端看到客户持有某产品收益 5000 元客户在手机银行看到收益 4820 元。原因两个页面分别由不同团队开发一个用持仓成本法另一个用市值法而且产品没有预置估值口径字段。解决在产品表增加valuation_method字段所有收益计算服务必须读取该字段封装统一收益试算服务页面只传产品代码和数量不允许自定义公式。这个措施还能降低后续维护成本新业务接入时不需要理解底层算法。5.3 产品接入排期总是被拖着现象每个新产品的接入都要 2-3 周产品经理说技术不配合研发说对方报文不规范。原因没有统一接入标准每次都是定向开发适配层代码越堆越多排期自然长。解决先做中间件适配层把外部报文转成标准 JSON核心系统只认标准报文同时制定一个产品接入清单表缺少哪个字段直接反馈给产品方而不是默默匹配默认值。经验是第一个产品接入花两周第二个接入缩短到三天后面就稳定在一天。5.4 方案文档写得像 PPT开发不知道字段长度现象评审完设计方案开发人员发现“证件号”字段不知道存 15 位还是 18 位金额字段用 int 还是 decimal。原因文档里只有业务流程图和系统架构图没有数据字典。解决交付文档必须附带字段级明细表至少包含字段名、物理类型、长度、精度、必填、默认值、备注。我一般要求每个表结构都做成 docx 里的三线表让研发可以直接建表。5.5 客户查询性能随着账户数量增长急剧下降现象刚开始用户量小客户视图查询很快运行半年后一个客户名下挂了五六十个账户查询总资产要等十几秒。原因查询时实时 join 持仓和产品表并逐条计算市值没有做读模型。解决建立客户资产宽表按客户维度每日汇总查询走宽表如果对实时性有要求可以在客户修改持仓后异步刷新宽表而不是查询时计算。这个方案能支撑千万级客户核心逻辑就是“读时拆分、写时聚合”。6. 用三个指标验证这套系统值不值得继续投入系统上线以后不要只看“功能都做了没”要看它是否真的给业务带来了确定性的改善。我会用三个指标来判断财富管理系统是否值得继续投入。第一个是对账差异率日终系统资产与 TA 确认数据的差异笔数除以总交易笔数目标要低于 0.1%如果长期高于这个值说明数据模型或异步流程有问题优先修而不是加功能。第二个是客户视图覆盖率能在一个页面看到完整资产持仓的客户数占总客户的比例目标是 100%低于这个数说明还有客户的账户没串起来。第三个是资产配置建议采纳率理财师按照系统自动生成的建议方案和客户成交订单数除以总建议数这个指标能直接衡量系统是否帮业务赚到了钱。还有一个值得做的进阶技巧把方案文档里的需求编号作为全链路唯一溯源标识。开发分支名、提交信息、测试用例、线上验收报告全部带上需求编号例如feat/R001-customer-asset-view。这样做之后每次业务方来问“这个需求做了没有”只要在代码仓库搜一个编号就能回答不需要再去翻各种群聊记录。这是我自己的一个工作习惯最初是为了应付审计后来发现它能让文档从“交差”变成真正的驱动工具。回看我自己经手的财富管理系统项目最后悔的不是技术选型而是没有在方案阶段把术语口径和字段级设计写透。如果开需求评审会时业务和研发能对着一张数据字典逐条确认后面至少能少一半的扯皮和返工。希望这个思路能帮到你从一份够细的 docx 开始把财富管理系统做成业务真正用得起来的底盘。本文还有配套的精品资源点击获取