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