Logo
OFFLINEPIXEL
Asset Management

Designing Multi-Asset Trading Platforms

A global asset manager consolidated 5 disparate trading systems into a unified multi-asset platform, reducing infrastructure costs & improving execution speed.

Executive Summary

A global asset manager with $500B AUM maintained 5 separate trading systems for different asset classes—each with different protocols, risk engines, and operational overhead. Senior quant engineers architected a unified multi-asset platform that reduced latency by 65%, cut infrastructure costs by 40%, and enabled cross-asset strategies previously impossible.

Key Outcomes

  • ▹ 5 systems → 1 unified platform
  • ▹ 65% reduction in execution latency
  • ▹ 40% infrastructure cost reduction
  • ▹ 3 new cross-asset strategies deployed

Client Situation

The firm's trading desk used separate systems for equities, FX, futures, options, and fixed income. Each had unique APIs, risk models, and operational workflows.

Key Challenges

  • ⚠ Inconsistent execution quality across asset classes
  • ⚠ No cross-asset risk aggregation in real-time
  • ⚠ 5x infrastructure and maintenance costs

Existing Architecture

Five independent systems: one per asset class, each developed by different teams over 15 years, using varying tech stacks.

  • Cross-asset strategies required manual coordination
  • No shared risk or position keeping
  • Engineer onboarding required learning 5 systems

Solution Design

Unified event-driven platform with asset-agnostic order management, real-time risk aggregation, and pluggable execution adapters.

Key Decisions

  • ✓ Kafka for event sourcing and audit trails
  • ✓ Unified risk model across all asset classes
  • ✓ Pluggable execution adapters for 25+ venues
C++RustKafkaRedisKubernetesgRPC

Implementation

Strangler pattern replacing one asset class at a time, starting with equities (highest volume), then FX, futures, options, fixed income.

  1. Phase 1: Phase 1: Core Platform

    Built shared order management and risk engine with asset-agnostic data models.

  2. Phase 2: Phase 2: Equities Migration

    Replaced equities system first, running parallel for 3 months.

  3. Phase 3: Phase 3: Remaining Assets

    Rolled out FX, futures, options, and fixed income over 12 months.

Technical Challenges

Normalizing different market data protocols

Impact: Each asset class had unique feed formats (ITCH, FIX, binary)

Resolution: Canonical data model with asset-specific adapters

Cross-asset risk aggregation latency

Impact: Real-time VaR calculation too slow for multi-asset orders

Resolution: Precomputed risk sensitivities with incremental updates (20ms → 500μs)

Results

Cross-asset execution latency
BeforeNot possible
After25ms
ImprovementNew capability
Infrastructure cost
Before$5M/year
After$3M/year
Improvement40% reduction
Time to onboard new venue
Before3 months
After2 weeks
Improvement87% reduction

Lessons Learned

  • 📘 Canonical data model was key investment (3 months) but paid off in all future integrations
  • 📘 Risk aggregation at scale required novel incremental computation
  • 📘 Event sourcing via Kafka provided perfect audit trail for compliance

What We Would Do Differently

  • 💡 Use Rust for more components (only used for adapters initially)
  • 💡 Implement circuit breakers earlier to isolate failing venues

Role Relevance

Senior quant engineers with multi-asset experience architected the canonical data model and unified risk system, enabling strategies impossible on fragmented platforms.

Critical Skills Demonstrated

Multi-asset tradingEvent-driven architectureCross-asset risk modelingSystem integration

Related Roles

Senior Quant Engineer Quant Engineer Quant Developer

Frequently Asked Questions

What was the hardest asset class to integrate?
Options—complex risk surface and volatility surfaces required custom modeling.
How did you ensure backward compatibility during migration?
API gateway routing to legacy or new system based on asset class with feature flags.