AWS Re:cap 02: Building the Future Trading Platform Leveraging AI and AWS

Video: https://www.youtube.com/watch?v=aqDCPW9oBYA

Building the future trading platform leveraging AI and AWS

(featuring LPL Financial) (sponsored by Cognizant)

Session Introduction

● Modernizing and building the next generation trading platform

● Importance of speed, scale, resiliency, and intelligence in wealth management

● Overview of the session's agenda Overview of the wealth management industry:

● Definition and core purpose of wealth management

● Industry size: $144 trillion assets under management, 300,000 financial advisors, 68 million clients

● Generational wealth transfer: $100 trillion assets transitioning from baby boomers to tech-savvy next generations

Introduction to LPL Financial

● LPL's position as a Fortune 500 company and the leading broker-dealer in the country

● LPL's business model and current trading platforms Explanation of an independent broker-dealer:

● A firm that allows financial advisors to operate their own businesses while providing necessary support (technology, operations, compliance, etc.) LPL Financial's position:

● 32,000 financial advisors

● $2.3 trillion assets under management LPL's customer-centric approach:

● Mission: To help clients succeed at every step

● Vision: To be the best wealth management firm Technology requirements to achieve LPL's vision:

● Adaptive, cutting-edge, future-ready technology Definition of trading at LPL:

● Connective tissue for financial advisors to the market Behind-the-scenes trading process:

● Hundreds of high-performance systems working in unison

● 2,000+ checks running in sub-milliseconds

● Reliance on multiple partners (market centers, fintech organizations) User expectations for trading:

● Secure trades

● Always-on systems

● Instant, near real-time responses

● Cost-effective trading Technology goals to achieve business objectives:

● Zero security incidents

● 100% compliance

● Ultra-resilient, always-on systems with fast recovery

● Trading systems designed for peak volumes Cloud journey:

● Iterative and incremental process, not a big bang migration

● Analogy: Building a skyscraper (foundation, core, electricity, plumbing, automations)

● Up until 2024: Migrating processes from on-prem data centers to the cloud, running critical systems in EKS, adopting AI and machine learning algorithms

● 2024 focus: Auto scaling and decoupling platforms for better scalability

● Future plans: Enhancing platform resiliency, transitioning from multi-availability zone to multi-region, multi-availability zone, reducing on-prem dependencies

Current state architecture

● On-prem data center and multi-availability zone in the cloud

● Workflows designed to handshake between on-prem and the cloud Current state architecture components from AWS:

● S3 bucket for presentation layer and content rendering

● EKS Kubernetes for serverless design and auto-scaling/self-healing architecture

● Postgres SQL for relational needs and high transaction throughput

● Dynamo DB for document databases (mostly read use cases)

● Memory DB for low latency, high computing in-memory processes

● Kafka as a message broker to reduce cascading dependencies and failures

● SageMaker for machine learning algorithms and AI use cases

● CloudWatch for instrumentation and end-to-end observability Next-gen architecture goals:

● Remove on-prem dependency for tier one critical applications

● Harness the full power of the cloud for end-to-end resiliency and simpler failovers

● Transition to an active, active multi-region environment

● Challenges: Ensuring data consistency across regions and orchestrating requests between multiple regions in an active, active way

● Potential solution: Using Aurora DB for native multi-region support Next-gen architecture adoption:

● Bedrock along with SageMaker for better integration of Gen AI and LLM into core workflows

● Easier learning curve with Bedrock

Use case: Klein Works Rebalancer

● LPL's flagship homegrown trading platform

● Based on models-based trading principle

● Advisors create portfolios for clients with different investment needs, goals, and risk profiles

● Markets are always changing, causing portfolios to deviate from their intended strategy

● Models-based trading automates the process of adjusting portfolios to meet client goals

● One-to-many relationship from model to accounts

● Trading happens on models, not individual accounts

● Client rebalancer performs millions of drift checks in parallel, executes trades automatically, and is fully compliant

● Analogy: Client rebalancer is like a GPS that recalibrates based on traffic patterns

● Currently used by 14,000 advisors out of 32,000

● at LPL Financial

● Incremental rollout over the last 5 years

● More than 70 million trades executed on the platform

● One million drift checks performed daily

Use case: Klein Works Rebalancer

● powered by AWS for hyperscaling

● Each trade on the platform performs 50+ checks (account details, market price, licensing, compliance rules, etc.)

● Thousands of trades across hundreds of accounts and advisers result in hundreds of thousands of trade volume per minute Platform design:

● Rebalance requests from advisors are received by an orchestrator

● Orchestrator breaks down large rebalance requests into smaller mini-batches

● Mini-batches are sent to Kafka, which guarantees delivery

● Rebalance algorithm runs on an EKS cluster designed for auto-scaling

● Algorithm is independent and scales based on CPU, memory utilization, and Kafka queue depth Pre-trade validation:

● Over 200 checks are performed to determine if a trade can be executed

● In-process caching is used for instantaneous millisecond feedback on trade validity

● Invalid trades are kicked back to the queue and not processed further

● Parallelization and CQRS:

● 60+ code microservices and database calls are grouped by dependency map and run in parallel

● Command Query Responsibility Segregation (CQRS) paradigm is applied

● Writes are optimized for one server, batched, and buffered to reduce database hits

● Reads are optimized for read instances due to higher read volume and cached in-memory using AWS Memory DB Adaptive scaling on read instances:

● Due to the system's heavy read nature, adaptive scaling is applied to read instances

● EKS automatically scales, and reads are designed to scale automatically as well End-to-end observability with CloudWatch:

● Each trade is assigned a correlation ID for full traceability

● CloudWatch is used for monitoring and logging

● System is designed to self-alert and self-heal Synthetics:

● Synthetic transactions are created to mimic advisor actions

● These transactions are run iteratively on the system to detect potential issues before users are affected

● The system handles thousands of transactions per second and has seen almost a million transactions during peak volume AI use cases at LPL:

● Human-in-the-loop approach is preferred, with advisors controlling AI-suggested outcomes and smart recommendations Use case: Market center outage detection

● Market centers can experience slowness, challenges, or outages, leading to operational issues and duplicate orders

● Goal: To detect market center outages ahead of time

● Workflow created to feed real-time trades and executions to an algorithm

● Algorithm used: Random Cut Forest, a time series anomaly detection algorithm

● When anomalies are detected, the operational team is alerted and takes action Second use case: ETF classification

● ETFs have different holdings and must be classified into categories (e.g., crypto, commodities, foreign funds) based on their metadata

● Regulatory implications require licensing checks, compliance rules, and training for advisors

● Traditionally done manually, but automated using a trained model running nightly

● Model used: Artificial Neural Network (ANN), an unsupervised model with high accuracy

● Operational staff reviews and accepts the model's suggestions

AI model architecture

● Data storage: Historical data for both use cases is stored in RDS Aurora PostgreSQL database

● Lambda function: Picks up curated, updated data daily, processes it, and dumps it into an S3 bucket for learning

● SageMaker: Trains and hosts models; trained models are published as endpoints for downstream consumption Workflow for real-time anomaly detection:

● Stream of real-time trade data is picked up by a Lambda function

● Data is run through the trained model endpoint (e.g., Random Cut Forest algorithm)

● Anomalies are detected and alert the staff

● Data is fed back to RDS for future learning based on model decisions Workflow for ETF classification:

● New ETF data is sent to a Lambda function

● Data is run through the trained model endpoint

● Outcome is provided to the operator

● Data is stored in the RDS instance

Trading Back Office Automation

Business Context

● Goal of investing: Grow money

● Portfolio growth leads to higher capital gains taxes

● Larger accounts, especially for ultra-high net worth clients, face significant tax consequences

● Existence of tax thresholds for accounts

● Rebalancer Complexity

● Rebalancer process is complicated

● Adding tax awareness and optimization increases complexity

● Algorithm considers over 50 variables with high interdependencies and sensitivity

● Multi-Agentic AI Framework

● Exploration of using agentic AI to solve the problem

● Agents are models with specific roles and actions

● Rebalancer Agent

● Trained with 22 data sets

● Data sets include the algorithm with 50+ parameters and historical runs of tax trade rebalancers

● Handles hundreds of requests per day

● Outcomes are sent back for further processing

● Validation Agent

● Checks for cascading dependencies and impacts on the account ecosystem

● Approves favorable outcomes to proceed to the trading agent

● Sends feedback for reprocessing if validation fails

● Trading Agent

● Executes trades with market makers and market centers

● Part of the agentic loop that has shown a 10x scale in throughput

● Industry Trend

● Shift towards model-based trading

● Some accounts not yet transitioned due to historical reasons and operational intensity

● AI Solution

● Analyzes advisor’s current book and account holdings

● Suggests models for accounts to transition towards model-based practice

● Aims to increase efficiency for advisors by reducing operational work and increasing client interaction time