quantverse.
2026-09-04 · Quantverse Team

Introducing Quantverse: point-in-time data, research agents, and a strategy lab

Quantverse is point-in-time US equities data, an MCP server of research skills, and a strategy lab. This is what we are building, what works today, and why every query carries an as-of date.

On 9 June 2022 the ticker FB stopped trading and META took its place. Nothing about the company changed that morning. Its CIK, its CUSIP, its share count and its price history were all the same. Only the label moved. A backtest that joins prices to a universe by ticker string sees something different: one company that vanishes and another that appears from nowhere with no history. Depending on how the join is written, the strategy either sells a position it never had a reason to sell, or it never held Meta at all.

That is one bug. A research pipeline built on ordinary vendor data has more like it, and they all point in the same direction: the backtest knows things the trader did not. Quantverse exists to remove that class of error at the data layer, so it cannot be reintroduced by the code above it.

Three ways historical data lies

Every one of these is a data problem before it is a modelling problem.

Restated values. Most price feeds apply split and dividend adjustments retroactively, then overwrite the series. The row for March 2014 gets rewritten in June 2014 when a 7-for-1 split lands. A model trained on the rewritten row has seen the split before it was announced.

Drifting identifiers. Tickers get renamed, reused and reassigned. A symbol that meant one company in 2015 can mean an unrelated shell company in 2019. Fundamentals are keyed by CIK, prices by ticker, index membership by CUSIP, and the mapping between them changes without any of the three sources noticing.

Survivorship. A universe built from today's listings contains only the companies that made it. The ones that were delisted, acquired or went bankrupt are exactly the names a long-only strategy would have bought, and they are gone from the sample.

None of these can be fixed downstream. Once the data has been restated, the original value is no longer there to recover. The fix has to happen at ingestion, by storing every fact with the interval during which it was true and never overwriting it.

What point-in-time means here

In Quantverse, a fact is a value plus a validity range. A company's ticker is not a column; it is a row that says AAPL was this company's listing from 1980-12-12 until further notice. A name change, a CUSIP reassignment or a delisting closes one range and opens another. Nothing is deleted, so the store can answer any question of the form "what was true on date D".

The reference layer is built from several sources that disagree with each other, which is the point. SEC EDGAR is the authority for CIK, name and SIC codes. Two independent vendor universes supply CUSIP, ISIN, FIGI, listing and delisting calendars, and each corroborates the other. A separate archive of actual daily bars is used as a confirmation oracle: it never asserts who a ticker was, but it can say whether that ticker traded on a given day. Every raw observation from every source is kept, and a reconciliation pass turns them into the canonical point-in-time tables. Because that pass is a pure function of the raw observations, it can be re-run from scratch whenever a rule changes, and the result is the same every time.

graph LR
    E[SEC EDGAR] --> R[Raw observations]
    V1[Vendor universe A] --> R
    V2[Vendor universe B] --> R
    F[OpenFIGI] --> R
    B[Daily bars archive] --> T[Trading-day confirmation]
    R --> C[Reconciliation]
    T --> C
    C --> P[Point-in-time tables]
    P --> API[REST API]
    P --> MCP[MCP skills]
    P --> LAB[Strategy lab]

Every consumer sits on the right of that diagram. The REST API, the MCP skills and the strategy lab all read the same tables, and none of them has a way to see a row before its range starts.

The first endpoint

What is live today is security resolution: give the API a ticker and a date, and it returns the company that ticker mapped to on that date.

GET https://api.quantverse.com/v1/securities/AAPL?as_of=2020-01-01
X-Api-Key: <your key>

{
  "ticker": "AAPL",
  "as_of": "2020-01-01",
  "matches": [
    {
      "public_id": "…",
      "entity_type": "COMPANY",
      "name": "Apple Inc.",
      "equity_holding": "PUBLIC",
      "country": "US",
      "identifiers": {
        "CIK": "320193",
        "CUSIP": "037833100",
        "ISIN": "US0378331005",
        "FIGI": "BBG000B9XRY4"
      },
      "listing": {
        "value": "AAPL",
        "range_start": "1980-12-12"
      }
    }
  ]
}

This is what the as_of parameter is for. Asked about FB on 2021-06-01, the store answers with the company under the name it carried that day and a listing range that ends where META begins. Asked about 2023-06-01, it answers 404, because no listed security carried that ticker on that date. The identifiers map only contains the keys that were active on the as-of date, so a CUSIP assigned later is absent, not back-filled.

The public_id is the handle to keep. It is minted once per entity and never reassigned, so it survives every rename and relisting, and it is safe to store in your own tables as the join key. Internal vendor identifiers never appear in a response.

The endpoint is small on purpose. It is the join key for everything that follows, and we wanted it correct and boring before building on it. The OpenAPI specification is generated from the handler code, so the API reference cannot drift from what the server does.

The catalog

The identifier, splits, dividends and daily price packages are available now. The rest of the catalog is being built on the same store and will open through the beta.

PackageCoverageStatus
CIK, CUSIP, FIGI mappings, point-in-time1996 onwardavailable
US equities, daily OHLCV, regular market2004 onwardavailable
Splits and dividends, each with its event date and a computed knowledge date2004 onwardavailable
Mergers and acquisitions1996 onwardcoming soon
Listings, delistings, halts1996 onwardcoming soon
US equities, 1-minute bars2003 onwardcoming soon
Premarket and postmarket prices2010 onwardcoming soon
Dollar bars and volume bars2008 onwardcoming soon
Technical features, 142 columns, point-in-time2003 onwardcoming soon
Labels: forward returns, triple-barrier, meta2003 onwardcoming soon
Point-in-time screener API2003 onwardcoming soon
Earnings transcripts with embeddings2010 onwardcoming soon
Daily equity co-movement clusters2005 onwardcoming soon

Two details in that table matter more than the rest. Corporate actions carry both an event date and a computed knowledge date (for history backfilled before go-live, approximated from the event's own dates), so a backtest can keep a split out of view until that knowledge date. Once a split is dated no later than the backtest date, it adjusts the bars earlier than its execution date, and the execution-day bar stays as traded, on the new basis. The screener replays any historical date against the universe as it stood then, so a filter such as "Russell 2000 members with 60-day realized volatility below 20%" returns the names a trader could have found that morning, including the ones that no longer exist.

The full list with row counts and tiers is on the data page.

Agents

The second half of the platform is an MCP server that exposes quantitative research as skills any agent runtime can call: Claude, Cursor, a loop you wrote yourself, or the Quantverse studio. There are 48 skills; 29 are open and 19 are premium. They cover universe construction, feature engineering from bars, fundamentals and transcripts, walk-forward backtesting with purging and embargo, regime tagging, drawdown attribution, position sizing, hedging and report generation.

An agent given a prompt like "research mean reversion in the Russell 2000 over the last three years, market-neutral" builds a point-in-time universe for the start date, computes features under the same as-of discipline, runs walk-forward folds and writes up the result with charts. The interesting part is what it cannot do.

  • Every query the agent makes resolves through the point-in-time engine. There is no raw table access, so lookahead is not a matter of prompt discipline.
  • Compute is bounded per run, per day and per organisation, with a hard cutoff rather than a warning.
  • Walk-forward fold counts, universe size and feature width have caps, so an agent cannot mine its way to a good Sharpe by widening the search.
  • Anything that touches an order management system, a brokerage or order flow requires a human to sign off. Agents propose and people approve.
  • Each skill call is signed and hashed, so a result can be reproduced from its record later.

The skill list, configuration snippet and guardrails are on the agents page.

Where this is going

Quantverse will enter open beta soon with a small group of funds and independent researchers. The identifier API is live now; the price and corporate action packages and the MCP server open through the beta. Pricing is three tiers with no per-seat charge; the details are on the pricing page.

If you want to be in the beta, subscribe to the newsletter on the home page or write to [email protected]. Tell us which of the three lies in this post has cost you the most. We have a guess, but we would rather hear it.

← back to blog