利用 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 解決方案
• 分析顧問當前的業務賬簿和帳戶持倉
• 為帳戶推薦模型，推動其轉向模型化業務實踐
• 旨在透過減少運營工作并增加與客戶互動的時間來提高顧問效率