One security, two symbols: how Quantverse stitches price history across a ticker rename

On 16 June 2023 the company now called World Kinect moved its ticker from INT to WKC. Look up WKC directly in the Quantverse price warehouse, the table of daily bars (a bar is one day's prices and volume for one symbol), and the rows begin on that day. Everything earlier sits under INT, which the warehouse's 2026 rows show taken up by a different issuer (observed 19 September 2026). A literal lookup returns three years of WKC history, and an INT history that stops in 2023 and resumes as something else.

Neither answer is wrong about the table. Both are wrong about the company. Rather than rewrite the warehouse, the prices endpoint reassembles the series at query time from a symbol lineage: the ordered, non-overlapping eras of the symbols one security traded under. This post follows one request, GET /v1/securities/WKC/prices, through four decisions: identity, rename evidence, stitching across the seam, and what the response lets you check.

Why the bars are not re-keyed

When measured on 19 September 2026 the warehouse held 48.6 million daily bars for about 36,000 US tickers back to January 2004, each keyed to the symbol in force that day. One corporate-actions feed was backfilled with history re-keyed to the current symbol, so World Kinect's dividends were stored back to 2004 under WKC, while the old symbol kept receiving the same events. On 16 September 2026, 59 of INT's 90 dividends also existed under WKC with matching ex-date, sequence and amount; a naive union would apply them twice. Re-keying also cannot serve a reused symbol, where one row key would belong to two unrelated holders. So the bars stay where they traded, and identity is resolved per request.

Decision one: which security does the ticker name?

Every ticker-scoped request takes an as_of date, defaulting to today, and its first job is identity: which security did this symbol name then? The strongest evidence is the SEC's EDGAR ticker records, each a stint: an observed interval during which one entity held one symbol. When exactly one in-scope entity's stint covers as_of, that entity is preferred. WKC today resolves to World Kinect; INT as of 2020 to the same entity. META as of 8 June 2022 resolves to the Roundhill fund that held the symbol; one day later, to Meta Platforms, which had traded as FB until then.

When the stints name no holder, or several, the resolver falls back to the platform's own listing records, most recently listed first, and takes the first; among listings starting on the same day that order is undefined. BNC had three such tied holders on 8 October 2026, and the pick decides whether the request succeeds or fails. Identity is a ranking, not a refusal.

Decision two: what counts as evidence of a rename

Two sources describe renames; neither is complete alone.

Explicit ticker-change events from a commercial vendor record old → new on a date. Authoritative where present, their coverage starts in June 2023, so the 2022 FB → META rename has no event.

EDGAR stints reach much further back, but a stint's end is often the date a crawl last saw the symbol, not the date it stopped trading. World Kinect's INT stint runs to 8 March 2026, overlapping WKC by nearly three years.

Each catches what the other misses. Meta's stints hand over cleanly, FB ending on 8 June 2022 and META starting the next day, so the builder infers that rename from succession. World Kinect's stints overlap, so the explicit event supplies the boundary, and its date wins: the INT era ends on 15 June 2023.

Decision three: what the builder refuses to guess

The hard part is not linking symbols. It is declining to. An EDGAR entity is not a trading line: a fund trust is one entity holding hundreds of funds under their own symbols. The iShares Trust had 1,631 stints across 601 symbols (regression fixture, 8 October 2026).

An earlier builder inferred a rename from any two stints of one entity that abutted within seven days, and inside a trust unrelated siblings abut by accident. The documented failure mode: IVV was served AGT → AOA → ACWF → IVV history, bars and dividends included. The code correction was committed on 8 October 2026.

A stint succession is inferred only when all of the following hold:

• the entity's complete EDGAR history never shows two symbols trading at once (a shared boundary day is a handover) and none of its stints is malformed;
• one symbol's tenure ends and another's begins within seven days;
• each is the other's only candidate;
• no explicit event already leaves the one or enters the other.

An explicit event is always eligible, and eras are keyed by tenure rather than symbol, so Fiserv's recorded FISV → FI → FISV is three eras, not a cycle.

When the queried lineage's evidence contradicts itself, the builder does not repair it. Two successors, a cycle, boundaries out of order, an ambiguous succession, a rename no tenure could have held, or more than 32 eras make that lineage invalid, and the request is served as 503 ERR_UNAVAILABLE on the splits, dividends and prices routes. A partial chain would merely look right. Nine symbols were in that state on 8 October 2026; the count is not stable.

Decision four: stitching across the seam

For WKC today the lineage is two eras: INT from its first recorded stint in 2004 through 15 June 2023, then WKC from 16 June 2023, open-ended. A page is served with one warehouse query per era, cut to the era's dates and the requested window, in order until the page fills. Every bar carries the symbol in force on its date, so 15 June 2023 is labelled INT and the next bar WKC.

Corporate events are gathered the same way, era by era, which disarms the duplicates. A 2010 distribution keyed to WKC never qualifies, since in 2010 the security traded as INT. Where two copies of one event both qualify, a fixed preference keeps one: more reporting sources, then the era covering the date, then the latest observation. Each World Kinect dividend enters the multiplicative adjustment once.

Adjustment is opt-in.

• none, the default, serves the warehouse values unchanged.
• splits divides prices and multiplies share volume by every split ratio for splits executing strictly after the bar's date; the bar on the execution date already trades on the new basis.
• splits_dividends also multiplies every bar strictly before an ex-date by 1 − D / previous close, where D is the sum of that ex-date's USD distributions (one factor per ex-date and currency) and the previous close is the unadjusted close of the last bar before the ex-date anywhere in the lineage. If that bar belongs to the INT era, as for a hypothetical ex-date on the first WKC trading day, the factor anchors on an INT close.

Figures are illustrative: a bar closes at 100, the next day is the ex-date of a 2.00 dividend, so the factor is 0.98, and an earlier bar that closed at 90 is served as 88.20. Only events dated on or before as_of apply, so a request as of 2020 is never reshaped by a 2023 event.

A separate known_as_of pin filters events by a knowledge date: the first observation for events seen since the platform's knowledge epoch of 12 September 2026, and an approximation for earlier backfilled history (declaration date, else ex-date, for dividends; execution date for splits). The pin governs visibility, not values: a dividend first observed in 2027 stays out of a series pinned at 2026, but an already visible event is served with its current, possibly restated, figures.

What you can check from the response

The response returns neither the factor schedule, the reference closes nor the evidence behind each era.

• security carries the resolved entity's stable public id and name; for a fund, that is the issuing trust. lineage lists the eras queried. Both are null when no entity resolved and the literal symbol was served.
• splits_applied, dividends_applied and dividends_skipped are counts, one per split and one per dividend factor; a factor is skipped when it is not in USD, has no bar before its ex-date, or would be zero or negative. If an adjusted series has quietly become splits-only, the counts say so; rebuilding the factors takes the corporate-action rows and the unadjusted closes, each served by its own endpoint.
• Each corporate-action row carries its symbol, its known_since date, first and last observation times, how many reporting sources carried it, and whether they disagree. That count is corroboration, not provenance: it does not show the sources were independent.
• The factor schedule depends only on the lineage, as_of, known_as_of and the adjustment, never on the page, so a paginated walk over unchanged data returns what a single request would; the pin is a filter, not a snapshot.

What it does not do

The lineage is served as currently known: stints and rename events carry no usable knowledge time, so known_as_of cannot un-know a rename. Bars and corporate actions are current-state, served with their corrected values whatever the pin says. The market-wide sweeps take no as_of and no lineage, and still contain the cross-symbol duplicates the ticker routes remove.

The evidence for a rename is never complete, and identity is ranked before a lineage is validated. The rule is to say so, rather than serve a series that merely looks continuous.