Days to weeks
Trend following
Diversified futures books across asset classes, tested on decades of daily history with a cost charged on every trade.
Platform case studySystematic tradingMinutes to days
A complete platform for running a systematic mid-frequency trading system.
Market data, data quality, research, execution, risk and operations on one stack, built and run by one engineer directing a fleet of AI agents. For a firm onboarding a systematic strategy that holds positions for minutes to days, Nexus is the whole path from vendor feed to broker order. It runs every day on a production host, with execution on a broker demo account.
Read on 2026-10-01 between 18:27 and 18:40 UTC from GitHub, the work board, the deploy ledger and TimescaleDB catalog estimates (≈ marks an estimate).
A systematic trading system needs six things to work together. Nexus has all six in production, sharing one data store, one sizing library and one way of shipping change.
Ten sources and nine asset classes, from daily futures history back to 1969 to live broker capture at one second.
≈1.10B bars · 11,137 tickersRaw data is never edited. Every bar is checked, every fix is a logged and reversible operation, and bad series are quarantined.
37 check types · 6,631 logged fixesTrend, mean reversion and relative value on six simulation engines, a strategy builder over two of them, and controls that stop a backtest from flattering itself.
6 engines · 2 in the builderThe backtest and the live book size positions with the same library. Staged pre-trade limits, a halt and a kill switch sit in front of the broker.
1 sizing library · broker reconciliationThirty agent seats from three vendors build and maintain the platform. Every change is leased, reviewed by a different agent, tested and logged.
30 seats · 3,911 merged PRsCheckers on timers open a work item for anything red, every first-party system service has a failure alert wired, and backups are restore-tested.
41 checkers · failure alerts wired on 116 of 116 system unitsFourteen repositories make up the platform. The core is a data path: vendor feeds and live broker ticks land in a time-series store, a data API serves them, a research service tests strategies against them, and a trader executes the book that research promotes.
A mid-frequency system needs long daily history to test across many market regimes, and dense intraday bars to measure entries, exits and costs. Nexus holds both in one store: about 1.1 billion price bars across 11,137 tickers from ten sources.
Each bar runs from a source's earliest stored bar to its latest, as recorded in the store's coverage cache on 1 October 2026. A source's span is set by its longest series; many of its tickers start later. Hover or focus a row for the detail.
Two further public sources each supply one index series. Futures history includes individual contracts as well as continuous series.
| Source | Coverage | From | Latest stored | Resolution |
|---|---|---|---|---|
| Pinnacle Data CLC | 39 futures markets | Jan 1969 | 17 Jul 2026 | daily |
| Yahoo Finance | 6,479 tickers | Jan 1999 | 1 Oct 2026 | daily; hourly from Apr 2024; 5- and 15-minute from Feb 2026 |
| FRED | 42 series | Jan 2000 | 1 Oct 2026 | mainly daily |
| Dukascopy | 36 instruments | May 2003 | 24 Sep 2026 | 1-minute |
| Cboe | 274 volatility series | Jan 2004 | 30 Sep 2026 | daily |
| Databento | 40 continuous, 3,982 contracts | Jun 2010 | 1 Oct 2026 | daily and hourly; 1-minute for 5 markets to Aug 2023 |
| CCXT | 526 crypto assets | Aug 2017 | 1 Oct 2026 | daily and hourly; 5- and 15-minute |
| IG | 52 markets | Jul 2026 | live (bars to 24 Sep) | 1-second live capture; bars |
Catalog estimates of raw bars held, in millions.
Compressed 7 to 13 times on disk, depending on resolution.
Tickers with stored bars, each counted once, by the asset class in the instrument reference.
For your firmFutures, FX, equity, index, volatility and crypto history is already loaded. A new vendor is onboarded the same way as the ten here: registered as a source, checked by the same validators, and served through the same API.
A backtest is only as good as the bars under it. Nexus never edits raw data. It checks every dataset, logs each correction as a reversible operation, and serves a clean view that can be rebuilt from raw at any time.
Every vendor bar is kept as delivered, in append-only tables.
37 check types run against each dataset and record what they flag.
Each fix is one logged, reversible operation with before and after statistics.
A dataset is marked clean only when its checks pass.
Research and trading read canonical series through the data API.
QuarantineA dataset that fails is held back, with its reason on record, until it is fixed or retired. 45 are held today.
A selection of the 37 check types.
For your firmWhen a result looks too good, you can trace every bar behind it back to the vendor's delivery and every change made to it.
Nexus is not built around one strategy. Six simulation engines cover daily portfolio backtests, statistical arbitrage, minute-level and intraday simulation, and overlays. A strategy builder covers two of them today, trend books and target-position panels, and opens a saved strategy as its components and results. Every style runs under the same controls.
Diversified futures books across asset classes, tested on decades of daily history with a cost charged on every trade.
Intraday and daily books on minute and hourly bars, with costs charged before a trade is admitted.
Spread and basket books across related instruments, simulated leg by leg with each leg's costs.
A new strategy is integrated through the builder's extension points, then follows the same governance path: register, authorise, test, decide.
Every campaign writes its accept rule before any result exists, and closes on that rule.
No registered test runs without a one-shot, root-owned authorisation that binds the spec hash, the code SHA, the data IDs and the operator's sentence. No agent can write it.
An append-only register is checked before any market-data read. A run larger than its reservation is refused, and retrospective bookings still count.
A read spends a look only if it produces a return, a fit or a selection. A sealed slice is spent once, with no refund after a crash.
A trade is admitted only if the forecast clears its uncertainty and a measured cost reserve. An unmeasured instrument never gets a default cost.
Tests check that no future data reaches a signal; 38 test files address look-ahead, from signal checks to the CI and deploy gates that run them. Walk-forward scoring uses deflated out-of-sample statistics.
For your firmYour strategy is tested the way a sceptical reviewer would want: trials counted, hold-out sealed, costs measured, and the verdict rule written down first.
For a quant with a model, the expensive part is everything around it: clean history, a bar clock, sizing, turnover limits, risk caps, costs, honest statistics and a path to a broker. In Nexus a strategy is a document of named slots, and a model fills the forecast slot. Bringing a model in is integration work: it is registered as a forecast component through the builder's extension points and runs on an engine that already exists. It does not need a new backtester.
strategy
sleeve
universe instruments, series
clock 5-min, hourly, daily
forecasts <- your model
blend how forecasts combine
sizing forecast to position
turnover no-trade band, trades
risk caps and limits
cost charged per trade
book
allocation across sleeves
book risk book-level limits
band weight band
Stored trend books hold several sleeves each. Composing changes a stored strategy's settings within bounded menus; it does not add or choose sleeves.
Your model emits a signed forecast per market per bar and joins the trend engine as a new forecast. The engine sizes positions from the forecasts, applies the turnover band and risk caps, and charges costs per trade, on a daily clock.
Your model scores a panel of markets on a five-minute or hourly clock. The target-position engine turns the scores into position targets, clips them to limits, holds small changes inside a no-trade band, trades the rest, and charges a measured cost on each trade and financing on each bar.
The model reads the same clean series as research and trading. Every logged look records the deployed commit it ran on, and a saved strategy records its code version, so a result can be traced to the code that made it.
The stages each path exposes, so you can see where a result was made or lost. Panel strategies show all of these; trend books show forecasts, positions, trades, costs and P&L, without the target stages.
The same sections whichever path ran, each in that path's own units.
Score the strategy on the declared window for its clock. Warm-up history is loaded but never scored, and every look is logged.
Change a stored strategy's settings within bounded menus. Panel strategies can be saved today, under a name that is never reused; saving composed trend books is built and awaiting release.
Submit the document. The trial is booked in the register first, then the job queues with a runtime estimate and runs to a descriptive report, not a research verdict.
For a quantBring the model and keep it in one component. You get governed backtests on clean data, costs on every trade, statistics that state their own uncertainty, and a record of the code behind every look. Trading a new kind of model is a separate step: the trader runs trend books today, and another model type needs its trader integration built first.
The same platform that tests a strategy runs it: a per-market scheduler, pre-trade controls and reconciliation on the trading side, and checks, alerts and tested backups on the operations side.
For your firmPre-trade controls in the spirit of MiFID II RTS 6 and SEC 15c3-5, and reconciliation that finds breaks early.
For your firmOperational resilience you can evidence: checks that report, alerts that fire, and a maturity score with the gaps listed.
Thirty agent seats from three AI vendors build and maintain Nexus. The controls are the point: every change is a leased work item, made in its own worktree, reviewed by a different agent at the exact commit, tested on scoped CI and shipped through a deploy ledger.
One Postgres lease board. Taking a work item is an atomic compare-and-swap, so one instruction can go to every idle seat and exactly one wins. Usage is metered per vendor, and work is not dispatched to a vendor that is short of quota.
Work is an item on the board, not a chat message.
A seat takes the item for a fixed term and gets its own worktree. Leases expire on read, so no sweeper is needed.
The agent works in its worktree and pushes a branch. Shared clones are never edited.
A different seat, often from another vendor, approves the exact head SHA. An approval of any other SHA does not count.
The diff is classified into test lanes on self-hosted runners. An unchanged tree reuses its green run.
Merge lanes serialise main. The research repository accepts merges only as tested batches.
deploy-now ships the tested tree, runs the service's gate and a health check, and logs the result. It refuses dirty trees, stale clones and rollbacks.
Checkers turn anything red into a new item, and the loop starts again.
For your firmAdopting AI coding agents with the controls a regulated team needs: leases, isolation, independent review, a cost meter and a deploy ledger you can query.
Each step below uses a part of Nexus that runs today. A firm can take the whole path, or only the parts it is missing.
Agree the markets, horizons and data. Each instrument gets its source, calendar, roll rule and a trading-cost estimate.
History is loaded raw, validated, cleaned with logged operations and promoted only when its checks pass.
The strategy or model is registered with its accept rule, authorised, and run on the simulation engines against a sealed hold-out.
The book runs through the trader on a broker demo account, sized by the same library as the backtest and reconciled against the broker. The trader runs trend books today; another model type gets its trader integration first.
Pre-trade limits, the halt and the kill switch stay on. Checkers and alerts watch data, jobs and positions.
See it appliedThe systematic trend programme is an example running on Nexus today. It was researched and tested on the platform, and it has run every day in forward incubation on a broker demo account since 12 August 2026. It has no live track record yet, and its case study says what that means for the results. Read the trend programme case study →
Each of these happened in production, and each left a rule or a tool behind.
A rollback deploys an older commit, and that commit passes its own tests. The gate goes green on the way down while the service moves backwards past fixes. The deploy tool now refuses it, and fixes go forward.
Release safety · fix-forward practice
Three agent sessions exhausted memory. With unbounded swap, no OOM kill fired: the host ground for about 100 minutes and was unreachable for about ten. The fix was per-slice memory caps, a guaranteed floor for Postgres and CI, and a per-job ceiling.
Linux resource isolation · incident forensics
Two shells reported the same agent id, and one released the other's live claim with no audit trail. The lease tool now refuses a second claim under a shared id and flags the collision.
Concurrency control · fail-closed design
Every first-party system unit now has a failure alert wired. A green check proves the wiring exists, not that anyone is paged, so the checker prints that limit in its own output.
Testing safety controls · honest monitoring
Sources, read 2026-10-01 between 18:27 and 18:40 UTC: GitHub for merged pull requests, runners and workflows across the 14 platform repositories; git on each repository's main branch for test files and functions, routers, pages, checkers and seats; the work board and its claim ledger; the deploy ledger, excluding test-fixture rows; TimescaleDB catalog estimates, compression statistics and the coverage cache for bars, tickers, sources and history; the instrument reference for asset classes; the validation, cleaning and dataset tables for data quality; the trader's account and order tables; the unit-alert coverage checker; and the dated review and incident records.
How the AI fleet works day to day: the seat roster, the Postgres work board, the lease a seat takes before it edits anything, the dispatcher's eleven gates, review by a different agent, and the lessons each control came from.
53 technologies, each with where it lives in the code, what that code does and the detail that matters.
How an alert gets from any service to Slack without blocking the caller: a 202, a transactional outbox and a delivery loop.
Lightstreamer, WebSockets and Server-Sent Events compared, and where each one runs in Nexus.
No Celery, no Airflow, no crontab: every service and job is a systemd unit, and Postgres does the queueing.
How accounts, cgroups and scheduling keep the database and trading running whatever else the server is doing.
How each change pays only for the tests it needs, on self-hosted runners, with one writer to main.
I can set up this framework, or the parts you are missing, around your strategy or your model: the data platform, the research controls, execution and risk, and the agent fleet that maintains it.