The Quantitative lifecycle

The same data from backtest to production.

algoseek built its Mercury, co-location, and data pipelines for trading first before it ever sold a dataset. One handler writes the historical archive and the live feed.

Exchange feeds

CTA/UTP

OPRA

CME

NYSE

IEX

 

 

Mercury ticker plant

One handler · one schema · one source

ACTIVE

 

 

 

 

Historical archive

From 2007

Real-time feed

NY4 · NY2 · NY5

 

 

 

 

Same schema · same ASID · same bar logic

 

Same data, every stage

01

Research

Historical

02

Out‑of‑sample

Historical

03

Paper

Real‑time

04

Live

Real‑time

The cost of two vendors

Six months of research, broken on day one of production.

The logic was sound; the data underneath changed between backtest and deploy. By the time you find out, capital is at risk.

One vendor, one pipeline

We built the infrastructure first. Then the data came from it.

The ticker plant and delivery layer were built as production infrastructure first. The archive and the live feed come out of the same handler; nothing to diverge.

Two-pipeline setup

Typical vendor

Exchange feeds Historical vendor Pipeline A Live feed vendor Pipeline B ≠ Different schema, identifiers, bar logic

Bar boundaries differ. Historical at 09:31:00.000, live at 09:31:00.014. Late prints land in different bars.

Identifiers disagree. Ticker change breaks the position at the symbology layer.

Adjustments applied differently. Historical end-of-day, live raw. Sign of P&L flips.

Security masters conflict. Two vendors, two files, two truths.

algoseek single pipeline

One handler

Exchange feeds Mercury One handler · One schema Historical archive Real-time feed

Bar boundaries identical. Same condition codes, same jitter handling, same close logic.

ASID stays constant through ticker changes, mergers, and delistings.

Adjustment factors on the same schedule across all four stages.

Security master built and quality-controlled in-house. One file for everything.

What stays constant

The four things that never change between your backtest and your live feed.

If any of these differ between research and production, your strategy runs on data it was never tested against.

01

02

03

04

Identifier

ASID (persistent)

Survives ticker changes, mergers, delistings, and corporate restructuring. Cross-references FIGI and ISIN.

Schema

Up to 90 fields per bar

Tick, second, minute, and daily bars in one field format. The columns of Stage 01 are the columns of Stage 04.

Reference

In-house security master

Security master, adjustment factors, and corporate events built in-house. No third party between you and the data.

Source

Mercury ticker plant

One handler writes both sides. C++ and Assembly, zero external dependencies. Third generation, fifteen years of runtime.

The four stages

Research, validation, paper, live. Same data at every step.

Every vendor covers one of these well. The question is what happens when you need the next one.

 

Stage 01

Historical research

 

Historical

20+ years of tick data, up to 90 fields per bar, queryable from day one. The schema here is the schema in production.

What you will NOT do here

Spend a quarter on data engineering. Discover your test relied on fields that do not exist live.

Query sample

# AAPL minute bars, full 2024

bars = client.get_bars(

‘AAPL’, ‘1m’, ‘2024’)

✓ 97,500 rows · 90 fields · 0.8s

 

Stage 02

Out-of-sample testing

 

Historical

Point-in-time masters and versioned adjustment factors keep walk-forward clean.

What you will NOT do here

Reverse-engineer a vendor’s retroactive adjustments. Find tomorrow’s information in today’s security master.

Walk-forward check

In-sample

2018-01 to 2022-12

Holdout

2023-01 to 2023-12

Schema

Identical

Sec. master

Point-in-time

 

Stage 03

Paper trading

 

Real-time

Mercury wrote your history and delivers your live feed: every open matches your backtest. A difference here is your model, not the data.

What you will NOT do here

Write a translation layer between historical bars and live ticks. Lose paper-trading days to pipeline issues.

Mercury feed status

Feed

● Live multicast

Location

NY4 primary

Schema

Same as Stage 01

Capital

Paper only

 

Stage 04

Live trading

 

Real-time

Real capital. The same ticker plant algoseek runs for funds, banks, and two US regulators: fifteen years, zero streaming downtime.

What you will NOT do here

Wait three days on a support ticket while your model trades blind.

Uptime since 2015

 

 

 

 

 

 

 

 

 

 

 

2015

2025

Zero streaming downtime across COVID, meme-stock OPRA, 0DTE surge, election weeks

Who uses which stages

Not every team runs all four, but the pipeline covers whichever subset you need.

Different segments enter and exit at different points; the data is the same across all of them.

Quant trading

Funds, prop firms, independents

The full lifecycle, from first backtest to co-located live trading. Divergence between backtest and production costs real money.

Typical path

01 Research

02 Walk-forward

03 Paper

04 Live

Banks / Institutional

Risk, TCA, compliance, surveillance

Enter at Stage 04 for surveillance or TCA; the archive lookback matches what the live system recorded.

Typical path

01 Lookback

+

04 Surveillance

Fintechs

API feeds, redistribution, product builds

Prototype on the archive, deploy delayed or real-time feeds into the product. An expiring instrument cannot break the end-user experience.

Typical path

01 Prototype

02 Validate

Delayed + Real-time

Academic

Research universities, PhD programs

Stages 01 and 02, with the field depth and security master institutional clients get.

Typical path

01 Research

02 Validation

Test the pipeline before you commit to it.

Up to a year of historical data across all asset classes. Jupyter, SQL, Excel. No credit card, no sales call required.