Traadence's Auto Trader Bot is a production Python system that turns existing quantitative signals into simulated or live orders without splitting research, execution, and monitoring across unrelated tools. It ingests streaming and historical market data, applies configurable risk checks, routes orders through venue adapters, reconciles fills, and stores each state change for replay. The result is one auditable operating path from market event to position update.
One event model for research, risk, execution, and replay.
What the Execution Engine Actually Does
The system connects four jobs that commonly drift apart: data ingestion, strategy evaluation, order management, and post-trade analysis. A normalized event schema lets the same strategy consume historical bars, recorded ticks, or live quotes. Before any order leaves the process, the risk layer checks exposure, order size, session status, price freshness, and configured loss limits. Accepted orders receive idempotent client identifiers, while fills and rejections update the same position ledger used by simulation.
That design matters when an algorithm moves from research into production. Instead of rewriting execution logic after a promising backtest, the researcher promotes a versioned strategy profile into paper trading, compares event-by-event behavior, and then enables a live adapter. Quantitative analysis remains reproducible because parameters, feature versions, data ranges, and execution assumptions are stored with every run.
Core Features
| Feature | Description |
|---|---|
| Unified market-data pipeline | Fragmented feeds create mismatched timestamps and symbols. The pipeline normalizes streaming quotes, trades, bars, and historical files into ordered events with source timestamps, receive timestamps, and gap flags. |
| Deterministic strategy runtime | Research results become unreliable when live code follows different rules. One strategy interface handles replay, paper, and live modes with versioned parameters and explicit feature dependencies. |
| Adapter-based order routing | Venue changes should not force strategy rewrites. A broker-neutral adapter contract maps submit, cancel, replace, fill, rejection, and account events into a common order state machine. |
| Pre-trade risk gate | Runaway orders and stale prices can turn a software fault into market exposure. The gate blocks orders that breach position, notional, loss, session, price-age, or rate limits. |
| Order lifecycle reconciliation | Dropped connections can leave local state out of sync. Reconciliation compares open orders, executions, and positions after reconnects, then flags discrepancies before automation resumes. |
| Event-driven backtesting | Vectorized tests can hide sequencing and fill assumptions. The simulator replays ordered events through the production strategy and risk interfaces with configurable fees, latency, spread, and slippage. |
| Feature research workspace | Untracked feature changes make experiments difficult to reproduce. The research layer versions transformations, labels, data windows, and evaluation outputs alongside each strategy run. |
| Live monitoring and audit trail | Silent degradation is harder to fix than a visible failure. Health checks watch feed freshness, heartbeat age, rejection bursts, queue depth, exposure, and process status while persisting structured audit events. |
Data, Research, and Live Execution Architecture
The event core uses Python for its mature numerical and systems ecosystem, with asyncio separating market-data, order, and monitoring tasks without blocking the strategy loop. Streaming connectors follow the RFC 6455 WebSocket standard, including heartbeat checks, reconnect backoff, sequence validation, and gap recovery. Durable order, fill, position, and run metadata live in PostgreSQL so incident review does not depend on transient logs.
Historical loads and scheduled research jobs can run through Apache Airflow when orchestration is required. Large research datasets can be staged in Snowflake while operational order state remains in the lower-latency transactional store. These components are optional modules, not hard dependencies for a single-machine deployment.
| Layer | Implementation | Why it is used |
|---|---|---|
| Event domain | Typed market, signal, risk, order, fill, and position events | Keeps simulation and live execution on the same contracts. |
| Execution control | Async task supervisor and idempotent order state machine | Contains connector failures and prevents duplicate submissions. |
| Storage | Transactional ledger plus partitioned research datasets | Separates authoritative trading state from analytical scans. |
| Observability | Structured logs, metrics, heartbeats, and alert hooks | Makes stale feeds, rejection bursts, and recovery attempts visible. |
| Configuration | Versioned YAML profiles with environment secrets | Makes strategy and risk changes reviewable without embedding credentials. |
Risk Controls Built Around Failure Modes
Risk handling is implemented as executable checks, not a dashboard warning after the order is sent. The control model follows the practical themes in the FIA automated trading risk-control guidance: pre-trade limits, kill controls, post-trade review, conformance testing, and documented recovery procedures. It also records execution context because the BIS report on FX execution algorithms highlights the operational and market-functioning risks created by increasingly automated, fragmented execution.
- A stale-data circuit breaker pauses new orders when market timestamps exceed the configured age, while cancellations and reconciliation remain available.
- A session kill switch rejects new exposure, cancels eligible working orders, and records the operator, reason, and strategy versions affected.
- Rate and duplicate guards evaluate client order IDs, recent intents, and venue acknowledgements before retrying an uncertain submission.
- Position and loss checks run before submission and again after fills so partial executions cannot bypass account-level limits.
Validation Targets and Failure Tests
The included acceptance harness measures the internal path rather than promising venue-dependent speed. On a reference local replay, the target profile processes 5,000 market events per second with p95 strategy-and-risk evaluation below 50 milliseconds. Order decision-to-adapter handoff targets p95 below 250 milliseconds, excluding network and venue latency.
| Test | Acceptance target | Method |
|---|---|---|
| Reconnect recovery | Feed heartbeat restored and gap check started within 5 seconds | Terminate the stream, retain sequence state, reconnect, and compare missing ranges. |
| Duplicate-order defense | Zero repeated client order IDs across 100,000 replayed intents | Inject timeouts before acknowledgement and retry through the order state machine. |
| Backtest/live parity | Matching signal and risk decisions for an identical recorded event stream | Run the same strategy profile in replay and paper modes, then compare event hashes. |
| Risk rejection | 100% of deliberately invalid orders blocked before adapter submission | Generate boundary cases for size, exposure, stale price, session, and loss limits. |
| Restart reconciliation | Open orders and positions converge before strategy resumption | Restart with simulated working orders and require an account snapshot comparison. |
Targets are deployment acceptance criteria, not exchange guarantees. Actual throughput and latency depend on hardware, venue protocols, data volume, strategy complexity, and network distance.
Use Cases
- Move a statistical-arbitrage model from notebook research into paper execution without replacing its signal interface or feature definitions.
- Run market-making logic with explicit quote-age, inventory, order-rate, and kill-switch controls while retaining every replace and cancellation event.
- Test prediction-market or sports-market strategies against recorded order-book events, then connect a venue adapter when the market API is approved.
- Operate several quantitative strategies from one dashboard while isolating positions, limits, parameters, and audit trails by strategy profile.
- Investigate a live incident by replaying the exact market, signal, risk, order, and fill sequence that preceded the discrepancy.
Project Directory
The download is organized as a complete operating project rather than a collection of research scripts. Strategy logic, venue adapters, risk checks, data jobs, migrations, replay tools, and tests are separated so a change can be reviewed without touching unrelated execution paths. Traadence also provides trading system integration and ongoing trading system maintenance for teams connecting additional venues, controls, or monitoring endpoints.
quant-execution-engine/
├── README.md
├── pyproject.toml
├── .env.example
├── Makefile
├── config/
│ ├── strategies.yml
│ ├── risk_limits.yml
│ ├── venues.yml
│ └── logging.yml
├── src/
│ └── quant_engine/
│ ├── app.py
│ ├── domain/
│ │ ├── events.py
│ │ ├── models.py
│ │ └── clock.py
│ ├── market_data/
│ │ ├── stream_client.py
│ │ ├── history_loader.py
│ │ ├── normalizer.py
│ │ └── gap_detector.py
│ ├── execution/
│ │ ├── router.py
│ │ ├── order_state.py
│ │ └── reconciler.py
│ ├── adapters/
│ │ ├── base.py
│ │ ├── paper.py
│ │ └── venue_template.py
│ ├── risk/
│ │ ├── pretrade.py
│ │ ├── exposure.py
│ │ └── kill_switch.py
│ ├── strategies/
│ │ ├── base.py
│ │ ├── registry.py
│ │ └── profiles.py
│ ├── research/
│ │ ├── features.py
│ │ ├── simulator.py
│ │ └── evaluation.py
│ ├── storage/
│ │ ├── postgres.py
│ │ ├── repositories.py
│ │ └── migrations.py
│ └── monitoring/
│ ├── health.py
│ ├── metrics.py
│ └── alerts.py
├── dags/
│ ├── historical_ingestion.py
│ └── research_refresh.py
├── sql/
│ ├── schema.sql
│ └── analytics_views.sql
├── scripts/
│ ├── bootstrap.sh
│ ├── run_replay.py
│ └── reconcile_account.py
└── tests/
├── unit/
│ ├── test_risk_limits.py
│ └── test_order_state.py
├── integration/
│ ├── test_stream_recovery.py
│ └── test_paper_session.py
└── replay/
├── test_live_parity.py
└── test_duplicate_guard.py
make bootstrap
make migrate
make test
make run-paper
How to Operate Live Execution Using Traadence's Auto Trader Bot
Download & Set Up the Project
Download, set up, and install Traadence's Auto Trader Bot to get the project running. If you hit any difficulty, contact us here.
Open the Operations Dashboard
Open the dashboard, choose Paper or Live, confirm the active venue adapter, and verify that market-data and account streams are healthy.
Load Strategy and Risk Settings
Select a strategy profile, then set symbols, order size, maximum position, daily loss limit, stale-data threshold, and the permitted trading session.
Start and Review the Session
Press Start Session. The engine validates risk, routes eligible orders, and returns fills, rejections, exposure, latency, and audit logs to the dashboard and database.
Questions
How does the system prevent duplicate or stale orders?
It checks price age, session state, recent order intents, client order IDs, and venue acknowledgements before submission or retry. If a response is uncertain, the reconciler queries open orders and executions before allowing another attempt, reducing the chance of duplicate exposure after a timeout or reconnect.
Can the execution layer switch between paper and live trading?
Yes. Paper and live modes implement the same adapter contract, so strategy, risk, event, and position interfaces remain unchanged. The operator selects the mode and venue profile at session start, while credentials and live permissions stay isolated in environment configuration.
How are backtests kept consistent with live execution rules?
The simulator feeds recorded events through the same strategy and pre-trade risk interfaces used in paper and live sessions. Each run stores parameter versions, feature versions, fees, latency, spread, slippage, and data ranges, making differences traceable instead of hidden inside a separate research-only engine.