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.

```mermaid
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.

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

```json
{
  "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](https://api.quantverse.com/scalar) 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.

| Package | Coverage | Status |
|---|---|---|
| CIK, CUSIP, FIGI mappings, point-in-time | 1996 onward | available |
| US equities, daily OHLCV, regular market | 2004 onward | available |
| Splits and dividends, each with its event date and a computed knowledge date | 2004 onward | available |
| Mergers and acquisitions | 1996 onward | coming soon |
| Listings, delistings, halts | 1996 onward | coming soon |
| US equities, 1-minute bars | 2003 onward | coming soon |
| Premarket and postmarket prices | 2010 onward | coming soon |
| Dollar bars and volume bars | 2008 onward | coming soon |
| Technical features, 142 columns, point-in-time | 2003 onward | coming soon |
| Labels: forward returns, triple-barrier, meta | 2003 onward | coming soon |
| Point-in-time screener API | 2003 onward | coming soon |
| Earnings transcripts with embeddings | 2010 onward | coming soon |
| Daily equity co-movement clusters | 2005 onward | coming 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](/data).

## 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](/agents).

## 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](/pricing).

If you want to be in the beta, subscribe to the newsletter on the
[home page](/) or write to [info@quantverse.com](mailto:info@quantverse.com).
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.