利用 AI 和 AWS 构建未来交易平台

场次笔记

利用 AI 和 AWS 构建未来交易平台

（LPL Financial 参与分享）（由 Cognizant 赞助）

会议介绍

• 对交易平台进行现代化改造并构建下一代交易平台
• 速度、规模、韧性和智能在财富管理中的重要性
• 会议议程概述
• 财富管理行业概述：
• 财富管理的定义与核心目的
• 行业规模：管理资产达 144 万亿美元，拥有 30 万名财务顾问和 6,800 万名客户
• 代际财富转移：将有 100 万亿美元资产从婴儿潮一代转移到精通技术的新一代

LPL Financial 简介

• LPL 是《财富》500 强企业，也是美国领先的经纪交易商
• LPL 的商业模式和当前交易平台
• 独立经纪交易商释义：
• 一家允许财务顾问独立经营自己的业务，同时提供必要支持（技术、运营、合规等）的公司
• LPL Financial 的市场地位：
• 32,000 名财务顾问
• 管理资产达 2.3 万亿美元
• LPL 以客户为中心的方法：
• 使命：帮助客户在每一步取得成功
• 愿景：成为最优秀的财富管理公司
• 实现 LPL 愿景所需的技术：
• 自适应、前沿且面向未来的技术
• LPL 对交易的定义：
• 连接财务顾问与市场的纽带
• 幕后交易流程：
• 数百个高性能系统协同工作
• 2,000 多项检查在亚毫秒内完成
• 依赖多个合作伙伴（市场中心、金融科技机构）
• 用户对交易的期望：
• 安全交易
• 系统始终在线
• 即时、近实时的响应
• 经济高效的交易
• 实现业务目标的技术目标：
• 零安全事件
• 100% 合规
• 具备快速恢复能力、始终在线且韧性极强的系统
• 针对峰值交易量设计的交易系统
• 云之旅：
• 采用迭代渐进的过程，而非一次性大规模迁移
• 类比：建造摩天大楼（地基、核心结构、供电、管道、自动化）
• 截至 2024 年：将流程从本地数据中心迁移至云端，在 EKS 中运行关键系统，并采用 AI 和机器学习算法
• 2024 年重点：通过自动扩展和平台解耦提升可扩展性
• 未来计划：增强平台韧性，从多可用区过渡到多区域、多可用区，并减少对本地环境的依赖

当前状态架构

• 本地数据中心和云端多可用区
• 工作流设计为在本地环境与云端之间进行握手
• 当前状态架构中的 AWS 组件：
• 用于表现层和内容渲染的 S3 存储桶
• 用于无服务器设计及自动扩展/自我修复架构的 EKS Kubernetes
• 用于满足关系型需求和高事务吞吐量的 Postgres SQL
• 用于文档数据库（主要是读取用例）的 Dynamo DB
• 用于低延迟、高算力内存处理的 Memory DB
• 使用 Kafka 作为消息代理，以减少级联依赖和故障
• 用于机器学习算法和 AI 用例的 SageMaker
• 用于检测和端到端可观测性的 CloudWatch
• 下一代架构目标：
• 消除一级关键应用程序对本地环境的依赖
• 充分利用云的全部能力，实现端到端韧性和更简单的故障转移
• 过渡到主动-主动多区域环境
• 挑战：确保跨区域数据一致性，并以主动-主动方式编排多个区域之间的请求
• 潜在解决方案：使用 Aurora DB 的原生多区域支持
• 下一代架构采用方案：
• 将 Bedrock 与 SageMaker 结合，更好地把 Gen AI 和 LLM 集成到核心工作流
• Bedrock 的学习曲线更平缓

用例：Klein Works Rebalancer

• LPL 的旗舰自研交易平台
• 基于模型化交易原则
• 顾问根据客户不同的投资需求、目标和风险状况创建投资组合
• 市场始终在变化，导致投资组合偏离预期策略
• 模型化交易可自动调整投资组合，使其符合客户目标
• 模型与账户之间是一对多关系
• 交易基于模型进行，而非基于单个账户
• Client rebalancer 并行执行数百万次偏离度检查、自动执行交易，并完全符合合规要求
• 类比：Client rebalancer 如同根据交通状况重新规划路线的 GPS
• 目前 LPL Financial 的 32,000 名顾问中有 14,000 名正在使用
• 在过去 5 年中逐步推出
• 平台已执行超过 7,000 万笔交易
• 每天执行 100 万次偏离度检查

用例：Klein Works Rebalancer

• 由 AWS 提供支持，实现超大规模扩展
• 平台上的每笔交易都会执行 50 多项检查（账户详情、市场价格、许可、合规规则等）
• 数百个账户和顾问的数千笔交易，使每分钟交易量达到数十万
• 平台设计：
• 编排器接收顾问发出的再平衡请求
• 编排器将大型再平衡请求拆分成较小的微批次
• 微批次发送至保证交付的 Kafka
• 再平衡算法运行在专为自动扩展而设计的 EKS 集群上
• 算法独立运行，并根据 CPU、内存利用率和 Kafka 队列深度进行扩展
• 交易前验证：
• 执行 200 多项检查，以确定交易能否执行
• 使用进程内缓存，对交易有效性提供即时的毫秒级反馈
• 无效交易会被退回队列，不再继续处理
• 并行化与 CQRS：
• 60 多个代码微服务和数据库调用根据依赖关系图分组并并行运行
• 应用命令查询职责分离（CQRS）范式
• 写入针对一台服务器进行优化，并通过批处理和缓冲减少数据库访问
• 由于读取量更高，读取针对读取实例进行优化，并使用 AWS Memory DB 缓存在内存中
• 读取实例的自适应扩展：
• 由于系统以读取为主，对读取实例应用自适应扩展
• EKS 自动扩展，读取也设计为自动扩展
• 使用 CloudWatch 实现端到端可观测性：
• 为每笔交易分配一个关联 ID，以实现完整可追溯性
• 使用 CloudWatch 进行监控和日志记录
• 系统设计为可自行告警和自我修复
• 合成监控：
• 创建模拟交易以模仿顾问操作
• 在系统上迭代运行这些交易，以便在用户受到影响前发现潜在问题
• 系统每秒处理数千笔交易，并曾在峰值交易量期间处理近 100 万笔交易
• LPL 的 AI 用例：
• 首选人在回路方法，由顾问控制 AI 建议的结果和智能推荐
• 用例：市场中心中断检测
• 市场中心可能出现响应缓慢、问题或中断，从而导致运营问题和重复订单
• 目标：提前检测市场中心中断
• 创建工作流，将实时交易和执行数据馈送给算法
• 使用的算法：Random Cut Forest，一种时间序列异常检测算法
• 检测到异常时，运营团队会收到警报并采取行动
• 第二个用例：ETF 分类
• ETF 的持仓各不相同，必须根据元数据划分为不同类别（例如加密货币、大宗商品、外国基金）
• 监管影响要求进行许可检查、应用合规规则并培训顾问
• 传统上由人工完成，但现已使用每晚运行的训练模型实现自动化
• 使用的模型：人工神经网络（ANN），一种准确率很高的无监督模型
• 运营人员审核并接受模型的建议

AI 模型架构

• 数据存储：两个用例的历史数据都存储在 RDS Aurora PostgreSQL 数据库中
• Lambda 函数：每天获取经过整理和更新的数据，进行处理，并将其转储到 S3 存储桶中用于学习
• SageMaker：训练并托管模型；训练后的模型以端点形式发布，供下游使用
• 实时异常检测工作流：
• Lambda 函数获取实时交易数据流
• 数据通过训练后的模型端点运行（例如 Random Cut Forest 算法）
• 检测异常并向工作人员发出警报
• 根据模型决策将数据反馈到 RDS，以供未来学习
• ETF 分类工作流：
• 新 ETF 数据发送至 Lambda 函数
• 数据通过训练后的模型端点运行
• 将结果提供给操作人员
• 数据存储在 RDS 实例中

交易后台自动化

业务背景

• 投资目标：实现资金增长
• 投资组合增长会导致更高的资本利得税
• 规模较大的账户，尤其是超高净值客户的账户，将面临显著的税务后果
• 账户存在税务阈值
• 再平衡器的复杂性
• 再平衡器流程很复杂
• 增加税务感知和优化会进一步提高复杂性
• 算法需要考虑 50 多个高度相互依赖且敏感的变量
• 多智能体 AI 框架
• 探索使用智能体 AI 解决该问题
• 智能体是具有特定角色和操作的模型
• 再平衡器智能体
• 使用 22 个数据集进行训练
• 数据集包括含 50 多个参数的算法，以及税务交易再平衡器的历史运行数据
• 每天处理数百个请求
• 将结果发回以便进一步处理
• 验证智能体
• 检查级联依赖关系及其对账户生态系统的影响
• 批准有利结果，使其进入交易智能体
• 如果验证失败，则发送反馈以重新处理
• 交易智能体
• 与做市商和市场中心执行交易
• 作为智能体循环的一部分，其吞吐量已提高 10 倍
• 行业趋势
• 转向基于模型的交易
• 由于历史原因和运营工作量较大，一些账户尚未完成过渡
• AI 解决方案
• 分析顾问当前的业务账簿和账户持仓
• 为账户推荐模型，推动其转向模型化业务实践
• 旨在通过减少运营工作并增加与客户互动的时间来提高顾问效率