Building the Future Trading Platform Leveraging AI and AWS

Session Notes

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