Chain of Custody for Investment Performance Data — From Venue API to Published Figure

Performance data passes through several hands between the venue and the published number. A chain of custody documents each step. Why it matters, where it breaks, and how a verifiable registry maintains it.

The phrase 'chain of custody' comes from forensic evidence. It refers to the documented sequence of custodians a piece of evidence passes through between collection at the scene and presentation in court. Each handoff is logged. Each custodian is identifiable. Each transformation — copying, sealing, transporting — is recorded with a timestamp. The point is not bureaucratic completeness; the point is that any later challenge to the evidence's integrity can be answered with reference to a specific, attributable, auditable record. If the chain breaks anywhere, the evidence's value is compromised and the court knows why.

Investment performance data has the same problem and is usually handled with much less rigour. A trader's claimed return started life as a venue's settlement record; passed through the venue's API as a JSON response; was processed by some intermediate code into a daily NAV figure; was rolled up into a TWR calculation; and ended up as a number on a slide deck. Each of those handoffs is a custody handoff. Most published track records cannot tell you who ran each step, when, against what input, with what code version. That opacity is what makes most published track records hard to underwrite.

Why custody matters for performance data

Without a chain of custody, the only person who can vouch for a published figure is the publisher themselves. A reviewer who wants to challenge the figure has no record to point at — no specific moment where the data was different, no specific transformation that should be re-run, no specific actor who can answer questions. The figure stands or falls on the reviewer's overall trust in the publisher, which is exactly the trust that verification is supposed to obviate.

Chain of custody is the structural answer. It converts a single act of trust ('do you believe the publisher?') into a chain of small, auditable claims ('the venue's API returned this exact response at this timestamp; this hash captured it; this transformation was applied; this output rolled up'). Each link can be verified independently. A reviewer who wants to spot-check picks any link and confirms it; the rest of the chain is implied by the construction. This is exactly the property a serious verification surface delivers.

The standard custody chain for performance data

The chain has six positions in the typical setup. Position one is execution — an order is matched on the venue's order book and a fill is recorded. Position two is settlement — the venue's clearing layer updates the trader's account ledger to reflect the fill. Position three is the venue's API surface — the trader (or a connected service) queries an endpoint and receives a response containing the post-settlement state. Position four is intermediate processing — a snapshot service or a portfolio aggregator transforms the response into a derived form (NAV, equity curve, position summary). Position five is calculation — a TWR or other performance algorithm runs over the derived form. Position six is publication — the resulting figure is presented to the reviewer.

Most performance-data failures localise to one of these six positions. Knowing the chain explicitly is what makes the localisation possible. A reviewer who challenges a figure and is told 'the data has been verified' has nowhere to go; a reviewer who challenges the same figure and gets back 'here are the API responses captured at positions 3, 4, 5' can do something with it.

How custody normally breaks

Chain of custody breaks in mundane ways. The most common is silent re-pulling: a snapshot service that loses its database and re-pulls historical data from the venue, replacing the original responses with whatever the venue returns at the time of the re-pull. The new responses look authoritative because they came from the venue, but they are not the responses captured at the original timestamps. Any restatement, correction, or change the venue made between the original capture and the re-pull is now silently absorbed without any record that it happened. The chain has effectively been edited.

A second common break is intermediate-processing format drift. A snapshot service ingests a venue response and stores a derived NAV; later, the service is updated to handle a new venue field; old historical NAVs need to be recomputed; the service silently regenerates them from cached responses. If the cached responses are not byte-identical to the original wire form (whitespace, key ordering), the regenerated figures may differ subtly from the originals. Without a hash captured at the time of original processing, there is no record of the difference.

A third break is publication-layer cherry-picking. The first five positions are clean; the sixth is curated. The publication chooses which months to show, what window to use, which benchmark to compare against. The data is honest at every prior step; the framing at the publication step is not. The methodology guide on why a screenshot of P&L is not evidence covers the structural problem at the publication layer; chain of custody does not solve it on its own — it only ensures that whatever is being framed is genuinely from primary records.

What a chain-preserving registry does

A registry that preserves chain of custody intervenes at three points. At capture (position 3), the raw API response is stored alongside its canonicalised form and an SHA-256 content hash. The hash is the witness: any later question about whether the response has been altered can be answered by recomputing the hash on the canonical form and comparing. At intermediate processing (position 4), all transformations are deterministic functions of the canonical form; running the transformation again on the stored canonical input produces an identical output. At calculation (position 5), the methodology is documented and re-runnable; given the same NAV series, any reviewer's implementation produces the same TWR.

On NakedPnL, this is exactly what the snapshot, hash, and chain machinery does. The daily cron at 23:55 UTC pulls the venue API, canonicalises the response, hashes the canonical form, and stores both the response and the hash as a NavSnapshot row. The chain header is SHA-256(previous chain header + current content hash); editing any historical row changes its content hash, which changes every chain header from that point forward, which is immediately detectable on integrity check. The daily Merkle root of all chain heads is committed to Bitcoin via OpenTimestamps so the publication-time state of the chain is also unforgeable. The methodology guide on how to verify a track record yourself covers how a reviewer runs each check.

What custody does not solve

Custody preserves the chain from venue to publication; it does not warrant the venue itself. If the venue's matching engine produces erroneous fills, the chain captures those errors faithfully. If the venue's settlement layer mis-prices an asset, the chain inherits the mis-pricing. The verification surface answers 'does the published figure match the primary records?' — it does not answer 'are the primary records themselves honest?'. The latter question is partially addressed by venue regulation, audit, and reputation, all of which sit outside the registry's perimeter.

Custody also does not solve coverage. A trader can connect three accounts and not connect a fourth where they have lost money. The custody chain is intact for the three connected accounts; the fourth simply does not exist on the registry. A reviewer relying on chain of custody alone might mistake the absence of evidence for evidence of absence — the chain says nothing about accounts that were never connected. The methodology guide on survivorship bias in trader rankings covers this structural blind spot.

Custody and the four properties of a verified track record

The verified-track-record glossary entry defines four properties that distinguish a verified record from a claimed one: independent primary data, deterministic computation, append-only history, and published methodology. Chain of custody is what makes the first three durable. Independence at the data source is one moment; preserving that independence as the data moves through the system requires capture and hashing. Determinism in computation is one property; preserving it across multiple re-derivations by different reviewers requires the input data to be byte-identical, which is the canonicalisation discipline. Append-only history is one promise; enforcing it requires a hash chain that detects any retroactive edit.

Without chain-of-custody discipline, all four properties degrade over time. The data drifts; the computation diverges across implementations; the history quietly absorbs corrections. A reviewer arriving a year later cannot reconstruct what the registry knew at the original publication date. With chain-of-custody discipline, the registry's state at any past date is recoverable: the chain bundle plus the OTS proof for that date together specify exactly what the registry believed about every connected account at that point in time.

Practical custody questions to ask any registry

1. What primary record is captured at snapshot time? The raw venue response, a derived form, or only a final NAV figure? (Raw response is the gold standard.)
2. Is the primary record canonicalised before hashing? What canonicalisation rule? (Sorted keys, no whitespace is the typical rule.)
3. Is the canonical form hashed and stored? With what hash function? (SHA-256 is the standard.)
4. Are historical rows mutable? If so, is the mutation logged with a corrective entry visible alongside the original? (Append-only is the gold standard.)
5. Is the chain head externally anchored — to a public ledger, a notary, or a third-party timestamping service? (Bitcoin via OpenTimestamps is one good option.)
6. Is the methodology between capture and publication documented and re-runnable from the stored canonical form? (If not, position 4-5 of the custody chain is not verifiable.)
7. What happens if the venue restates? Is the restatement logged as a corrective entry or silently absorbed? (Logging is the only correct answer.)

A registry that answers all seven questions clearly has thought about chain of custody. A registry that gives vague or evasive answers has not, and its outputs should be treated as opaque. The questions do not require any specialist expertise to ask, and they cut to the structural integrity of the verification surface in a way that surface-level marketing claims do not.

How NakedPnL answers the seven questions

• Primary record captured: the full raw venue API response at snapshot time, stored alongside the canonical form.
• Canonicalisation: sorted keys, no whitespace, applied via the procedure documented in the canonical-data-pipeline guide.
• Hash: SHA-256 of the canonical form, stored as the content hash of every NavSnapshot row.
• Mutability: the snapshot table is append-only by code path. Corrective entries are added with both old and new visible; original rows are never edited.
• External anchor: the daily Merkle root of all chain heads is committed to the Bitcoin blockchain via OpenTimestamps. Crons at 00:05 and 00:30 UTC handle the anchoring and the Bitcoin block-height upgrade.
• Methodology: documented at /docs/verification with reference Python and JavaScript snippets. The TWR engine in lib/calculation/twr-engine.ts is the canonical implementation.
• Restatement handling: a venue restatement is recorded as a new entry referencing the original; the original NavSnapshot row is preserved unchanged. Any reviewer can see both.

The combination of these answers is what gives a NakedPnL chain its verification value. None of them is exotic; each is a known engineering pattern. What is unusual is the combination — most performance-data systems answer one or two of the seven questions clearly and the rest opaquely. A complete custody chain requires explicit answers to all seven, and the cost of providing them is small relative to the credibility benefit.