极点宏观｜Financial Cloud Cloud · AWS Re:cap
AWS Re:cap 02: 利用 AI 和 AWS 构建未来交易平台
视频： https://www.youtube.com/watch?v=aqDCPW9oBYA
利用 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 解决方案
● 分析顾问当前的业务账簿和账户持仓
● 为账户推荐模型，推动其转向模型化业务实践
● 旨在通过减少运营工作并增加与客户互动的时间来提高顾问效率