Multi-Venue Algo Trading Architecture
A venue-agnostic algo trading operating layer connecting adapter contracts, research, backtesting, paper and controlled live execution, risk, and observability, with UMX as the current first implementation.
What this project proves
AI agents support code exploration, implementation, testing, and documentation; I own the system boundaries, risk rules, operating workflow, and release judgement.
A sanitised architecture and diagnosable paper-to-live design currently validated through the UMX adapter; other venue adapters are an explicitly labelled roadmap.
Evidence trail
Last reviewed2026-08-24See what is live, bounded, and still next.
The public case exposes only sanitised system boundaries and control semantics. Accounts, strategies, positions, P&L, and internal endpoints stay excluded, while multi-venue compatibility is not claimed early.
Sanitised target architecture
The public diagram preserves generic boundaries across venue adapters, research, execution, risk, and observability without internal identifiers.
First venue-adapter implementation
UMX is the current implemented venue boundary. The portfolio documents its adapter contract and operating responsibilities without SDK secrets or account data.
Strategies, accounts, and live outcomes
Strategy parameters, positions, P&L, clients, and real outcomes are not public evidence; synthetic scenarios explain control semantics only.
Binance, OKX, and Coinbase adapters
The multi-venue contract is explicit direction, but the three additional adapters are not claimed as complete or live.
2Crypto and securities API domains
4Research, backtest, paper, and live gates
3Rate, reconnect, and confirmed-state defences
Problem
Strategies coupled directly to one exchange API quickly become difficult to port across market data, order rules, and state handling. The core problem is a stable adapter contract with consistent semantics across research, backtest, paper, and live execution.
Build
Used the UMX SDK as the current first venue adapter, then designed a venue-agnostic algo operating platform with independently evolvable layers for market data, strategies, execution, accounts, risk, research records, and monitoring.
Outcome
An evolving multi-venue foundation: the current UMX adapter supports the full strategy lifecycle, while Binance, OKX, and Coinbase adapters can be added next without rewriting the strategy and risk core.
From venue adapters to a controlled strategy lifecycle
A shared contract wraps market, account, order, and event flows. UMX is the current implementation, keeping rate limits, retry, reconnect, and venue-specific rules inside the boundary.
Research, parameterised backtests, and fee simulation share signal semantics to reduce drift between experimentation and execution.
Paper validates behaviour first; live execution checks quantity, minimum notional, account, and risk conditions, advancing state only after confirmed success.
Risk rules, system events, connection health, strategy diagnostics, and research records create an operational trail instead of leaving failures buried in logs.
Interactive control path
One intent, three different state decisions
Switch the venue response to see how the same strategy intent moves through risk, the adapter, and evidence-based state control. This is a synthetic control scenario, not a real order or trading result.
Sanitised scenarioNo order or account data
Strategy intent
Pure calculation proposes direction and quantity without changing strategy state.
Risk gate
Validate permission, quantity, minimum notional, limits, and data freshness.
Venue adapter
Isolate authentication, precision, rate limits, retry, and venue-specific semantics.
Venue evidence
Normalise acceptance, rejection, timeout, and subsequent events into explicit evidence.
Strategy state
Commit, hold, or enter reconciliation only from confirmed evidence.
State decisionCOMMIT
Confirmed acceptance allows state to advance
The adapter receives identifiable, correlated acceptance evidence. Only after the execution layer persists it may the strategy mark the intent as processed.
- 01Intent created; strategy state unchanged
- 02Pre-trade checks passed
- 03Adapter normalised the venue request
- 04Acceptance evidence confirmed and persisted
- 05Strategy state advanced safely
State decisionHOLD
Explicit rejection is evidence of non-execution
The rejection reason is normalised and retained for diagnosis. State does not advance; a corrected condition may create a new intent instead of treating the original request as successful.
- 01Intent created; strategy state unchanged
- 02Pre-trade checks passed
- 03Venue explicitly rejected the request
- 04Adapter preserved the normalised reason
- 05State held pending correction or a new intent
State decisionRECONCILE
A timeout is neither failure nor success
Without sufficient evidence, blind retry is blocked to avoid duplicate side effects. State freezes until queries, event streams, or operator action complete reconciliation.
- 01Intent created; strategy state unchanged
- 02Request sent but confirmation timed out
- 03Outcome marked uncertain
- 04Automatic duplicate submission blocked
- 05Entered the reconciliation queue
Public boundary: Only control semantics and failure handling are shown. API keys, accounts, strategy parameters, positions, P&L, internal endpoints, and real trading outcomes are excluded.
The core rule: state must follow evidence
Strategy logic emits intent; pre-trade risk rejects invalid requests and the venue adapter isolates exchange-specific behaviour. Only confirmed outcomes advance strategy state, while rejection, timeout, and uncertain outcomes remain diagnosable and safely retryable.
My scope: first venue adapter and venue-agnostic platform architecture
This case uses the UMX Python SDK as the first concrete exchange boundary, but the platform above it is organised around a venue-adapter contract. I designed the algo operating layer across research, backtesting, paper and live engines, execution, risk, monitoring, and operator views. The dashboard and additional adapters are still evolving; the architecture is evidence, not a claim that every venue is already connected.
Paper success is not live safety
A paper engine can make every order look successful. Live execution must survive insufficient quantity, exchange rejection, latency, stale data, and partial infrastructure failure. The core state rule is therefore explicit: a signal is not marked as executed until the execution layer returns a confirmed success. Failed orders remain retryable and visible instead of silently contaminating strategy state.
Risk is part of execution, not a report after the fact
Account credentials are encrypted at rest, position and drawdown rules are checked before an order, and monitoring records both system events and strategy health. The longer-term design separates pure signal calculation, side-effecting execution, and confirmed state transitions, making failure injection, approval workflows, and hierarchical limits possible without rewriting the strategy layer.
Multi-venue compatibility is the next system boundary
The current implementation executes through UMX. The target architecture adds Binance, OKX, and Coinbase behind the same market, account, order, and event contracts while isolating venue-specific authentication, rate limits, precision, and rejection semantics. SimpleTerminal can remain the observation layer above those venues. This is a compatibility roadmap, not a claim that multi-venue live execution is already complete.