设计一个用户友好的资产聚合的技术方案

设计资产聚合功能是APP的技术核心与难点，目标是安全、准确、低摩擦地整合用户分散的金融资产，形成统一视图。这不仅是技术问题，更是涉及用户体验、安全和合规的系统工程。

以下是一个兼顾可用性、安全性与扩展性的技术方案选型与设计。

一、核心理念：分层解耦与渐进聚合

• 分层设计：将复杂的聚合过程解耦为 “连接 -> 获取 -> 解析 -> 展示” 四层，每层独立迭代。
• 渐进聚合：不追求一步到位。优先支持覆盖率高、API稳定的机构（如主流银行、支付宝、微信支付、头部券商基金），对支持有限的机构提供优雅的手动/半自动补充方案。

二、整体技术架构

资产聚合是一个典型的数据管道（Data Pipeline）问题，其核心流程与组件选型如下图所示：

flowchart LR
    subgraph A[数据获取层]
        direction LR
        A1[API直连聚合器]
        A2[安全前端采集器<br>（H5/SDK）]
        A3[手动录入模块]
    end

    subgraph B[数据处理与安全层]
        B1[加密传输<br>TLS/SSL]
        B2[敏感信息脱敏与加密存储<br>AES-256 + 盐]
        B3[数据解析与标准化引擎]
    end

    subgraph C[数据应用层]
        C1[统一资产数据集市]
        C2[账户健康度诊断引擎]
        C3[资产配置分析引擎]
    end

    A -- 原始加密数据 --> B
    B -- 标准化、脱敏数据 --> C

三、各层技术方案详述

第一层：数据获取层 - “如何拿到数据”

这是技术选型的核心，需根据金融机构的支持程度采用 “混合模式” 。

1. 模式一：API直连（最优，但壁垒高）场景：与有开放能力的银行、券商、基金公司合作，获取其官方Open API。技术选型：使用 OAuth 2.0 协议进行授权。用户跳转至金融机构页面授权后，获取access_token，用于调用资产查询API。优点：数据实时、准确、合法合规。挑战：谈判周期长，接口标准不一，开发维护成本高。
2. 模式二：安全前端采集（权宜，但用户体验佳）场景：对于不支持Open API但提供网上银行或App的机构。技术选型：方案A（H5爬虫）：在APP内嵌一个安全的浏览器容器（如腾讯X5内核）。用户在其中登录网银，通过前端注入的JS代码，在用户本地解析页面结构，提取数据后立即加密上传，不存储密码。需极度明确告知用户并获得授权。方案B（合作SDK）：与Plaid模式的国内合规服务商（如“AllBridge”、“BBAE”）合作，集成其SDK。它们已与众多金融机构建立了连接。优点：覆盖广，开发相对快。风险与合规：处于灰色地带，必须做到：仅前端解析、不存密码、用户主动触发、清晰授权。优先选择方案B。
3. 模式三：手动/文件导入（补充与兜底）场景：无法自动获取的资产（如私募、非标、实物黄金）、或用户不信任自动连接时。技术选型：手动录入：提供极简的表单和常用资产模板。文件导入：支持上传银行账单CSV、Excel，或支付宝/微信的账单导出文件。后端用Pandas进行解析和映射。优点：无合规风险，用户感知安全。缺点：体验差，数据滞后。

第二层：数据处理与安全层 - “如何安全地处理数据”

这是技术的生命线，必须投入顶级资源。

1. 传输安全：全程使用 TLS 1.3。
2. 数据脱敏与加密存储：密钥管理：使用云厂商的KMS（密钥管理服务）或自建HSM（硬件安全模块）管理根密钥。字段级加密：用户密码（如有）、交易明细等敏感数据，使用 AES-256-GCM 算法，结合随机生成的盐（Salt）进行加密后存储。即使数据库泄露，数据也无法被解密。存储分离：将用户身份信息、加密后的凭证、资产数据分表甚至分库存储。
3. 数据解析与标准化引擎：技术栈：Python + Pandas。为每家机构编写一个适配器，将千差万别的原始数据字段（如 “余额”/“current_balance”/“YE”）映射为内部统一的数据模型（如 {“asset_type”: “cash”, “amount”: 10000, “currency”: “CNY”}）。资产分类：建立内部资产分类树（如：现金及等价物、固定收益、权益、另类投资等），通过规则（关键词匹配、产品代码识别）和机器学习模型自动分类。

第三层：数据应用层 - “如何用好数据”

1. 统一资产数据集市：技术选型：使用时序数据库（如 InfluxDB 或 TDengine）存储每日资产快照。便于高效计算历史收益率、波动率等指标。
2. 账户健康度诊断引擎：实时计算：基于最新资产数据，实时计算并展示关键指标仪表盘，如：资产负债率、紧急备用金月数、投资资产占比、资产收益率。
3. 资产配置分析引擎：核心功能：对比用户当前持仓与目标配置（来自风险测评），计算偏离度，生成调仓建议。

四、关键工作流程示例（以模式二/H5采集为例）

1. 用户在APP内选择“添加某银行账户”。
2. APP启动安全浏览器容器，导航至该银行登录页。
3. 用户在容器内输入用户名密码（密码对APP不可见），登录。
4. 注入的JS脚本（在用户本地）等待页面加载完成，定位并提取余额、产品名称等元素数据。
5. 脚本将提取的纯文本数据立即通过加密通道发送至APP后端，并清空所有本地缓存。
6. 后端收到数据，通过该银行的“适配器”进行解析、标准化，存入加密数据库。
7. 前端更新资产总览视图。

五、技术选型清单

六、实施路径与合规建议

1. Phase 1：MVP（手动+核心直连）支持手动录入和1-2家最合作意愿的金融机构API直连。目标是跑通全流程，验证数据模型和展示逻辑。
2. Phase 2：扩展覆盖（合作SDK + 主流H5）接入1-2家聚合数据服务商的SDK，快速覆盖上百家机构。对支付宝、微信支付进行专门的H5采集优化（用户覆盖率高）。此时必须引入法律顾问，审核用户协议、隐私政策，确保采集方式合法。
3. Phase 3：深化与智能（全面直连 + 分析）积极寻求与大型金融机构的商务合作，用官方API替换非官方采集。基于完整的资产数据，开发高级分析功能（如收益率归因、费用分析）。

最重要的合规提醒：

• 绝对红线：不得存储用户的金融机构明文密码。
• 用户授权：必须在用户协议中清晰、单独地告知数据聚合的方式、范围、用途，并获得用户的主动勾选同意。
• 数据所有权：明确用户拥有其数据的所有权，并提供一键断开连接、清除所有数据的功能。

总结：资产聚合的技术选型，本质是在数据覆盖度、用户体验、开发成本、法律风险之间寻找最佳平衡点。一个务实的策略是：以官方API为长期目标，以合规的聚合SDK为中期支柱，以优雅的手动方案为兜底，并始终将安全和用户知情权置于首位。