NAV Discrepancy Tolerance Gates: How Much NAV Variance Is Acceptable?
There is no single acceptable NAV variance — a flat tolerance conflates timing differences with real errors. A defensible reconciliation uses four separate gates: position completeness (binary, 100%), ledger accuracy under normalised pricing (5 basis points of gross asset value), per-investor allocation (5bps or $1, whichever is greater), and a documented — not scored — pricing-methodology delta.
A tolerance gate is a threshold that decides whether a variance between two independently produced NAVs counts as agreement or as a break requiring investigation. In a shadow NAV and continuous reconciliation setup, the two NAVs are the fund administrator's official number and a second, independently computed number run alongside it.
The mistake most funds make is picking one number — "within 5 basis points" — and applying it to the headline NAV. That single figure is directionally reasonable and technically naive: two competent systems will differ for reasons that have nothing to do with either one being wrong.
Why does a flat NAV tolerance fail?
Two independently built NAV engines will disagree on a crypto fund even when both are correct, because of eight recurring sources of divergence: pricing source and mark timestamp, management fee accrual convention (daily versus monthly), performance fee crystallisation timing, trade-date versus settlement-date treatment, staking and reward recognition point, tax lot method (FIFO versus specific identification), in-flight transfers between venues at the cut, and rounding or dust.
Some of those are genuine errors. Most are legitimate methodology choices. A single tolerance band either fails a fund unfairly for a timing convention, or lets a real ledger error pass because it happened to net out against an unrelated timing difference. Separating the gates is what makes a pass or fail defensible to both sides.
The four-gate structure
| Gate | What it tests | Tolerance | Pass condition |
|---|---|---|---|
| Gate 1 — Completeness | Every position matches the administrator's holdings report on asset, venue and quantity; every transfer is matched on both legs | None — binary | 100%, no unexplained balances |
| Gate 2 — Ledger accuracy | The general ledger, accruals, fee logic and cash treatment, using the administrator's own price marks rather than the shadow book's marks | 5 basis points of gross asset value | Total NAV within tolerance |
| Gate 3 — Per-investor allocation | Each capital account, series/class high-water mark, accrued performance fee and equalisation entry | 5bps or $1, whichever is greater, per investor | Every investor line within tolerance |
| Gate 4 — Pricing methodology delta | Every difference between the two sets of price marks, with source and timestamp | Not scored | Documented and explained, not adjudicated |
This is the methodology behind Nyx Fund's parallel-run pilot, not an accounting or regulatory standard — see the callout below.
Why test Gate 1 before anything else?
Completeness is the gate that catches what actually breaks in practice: data ingestion. Across a fund running positions on dozens of exchanges and blockchains, the most common failure mode is not a pricing disagreement — it is a quiet API failure, a wallet that stopped syncing, or a transfer that landed on one venue's ledger and not the other's. A ledger that agrees on NAV to the cent while missing a position is not reconciled; it is coincidentally close.
This is also the gate an operations lead cares about first, because it tests the thing their existing administrator most often gets wrong across a large number of venues — not the arithmetic, the coverage.
Why separate Gate 2 from Gate 3?
Gate 2 re-runs the shadow NAV using the administrator's own price marks instead of the shadow book's independent marks. That isolates the general ledger, the accrual logic and the cash treatment from any disagreement about what an asset is worth — it is the honest test of whether the accounting engine itself is correct.
Gate 3 then tests something Gate 2 cannot see: per-investor allocation. Two funds can tie on aggregate NAV while every individual capital account is wrong, because per-series [[high-water-mark|high-water marks]] with mid-period subscriptions and redemptions are genuinely difficult to get right. Administrators reconciling crypto funds get this wrong more often than the headline NAV, which is why Gate 3 is the harder gate to pass and the one worth citing to a prospective investor.
There is no regulator or accounting body that mandates a four-gate NAV reconciliation structure. This is the pass condition Nyx Fund uses in its paid, refundable parallel-run pilot — three consecutive month-end closes reconciled against an existing fund administrator, with two of three months required to pass Gates 1 through 3 and the third allowed to fail no more than one gate before conversion. It is published here because a specific, falsifiable methodology is more useful to an operations lead evaluating reconciliation software than a vague claim of accuracy.
How is a gated reconciliation adjudicated month to month?
- Deliver the reconciliation pack
A full reconciliation report — gate by gate, position-level breaks, a NAV bridge attributing every difference to a named cause, per-investor comparison, and the pricing delta — is produced within five business days of receiving the administrator's month-end pack.
- Countersign pass or fail per gate
The fund's operations lead reviews and countersigns each gate independently. A fail must name the specific gate and the specific failing line — a vague "it didn't match" is not an adjudication.
- Score across the full period
Two of three month-ends must pass Gates 1 through 3 for the overall run to pass, with the third permitted to fail no more than one gate, remediated before any conversion decision.
- Treat Gate 4 as a deliverable, not a score
The pricing-methodology delta is read and discussed, not adjudicated — it is frequently the page that surfaces something neither side had noticed, such as an administrator marking a thin-liquidity position off a single venue.
Key takeaways
A single flat NAV tolerance either penalises legitimate timing differences or lets a real error slip through — use separate gates for completeness, ledger accuracy, per-investor allocation and pricing methodology.
Completeness (Gate 1) should be binary and tested first — it catches data ingestion failures, which are the most common real-world break across a multi-venue crypto book, and is not a pricing question at all.
Re-running your own NAV under the counterparty's price marks (Gate 2) isolates ledger correctness from valuation disagreement — a critical separation when two systems price the same asset differently.
Per-investor allocation (Gate 3) is the hardest gate to pass and the most valuable one to have passed, because per-series high-water marks with mid-period flows are where crypto fund administration most often goes wrong.
A documented, unscored pricing-methodology delta (Gate 4) surfaces real operational findings — for example, an administrator marking illiquid assets from a single venue — that a pass/fail number alone would hide.
Tools like a NAV validator can apply a version of Gate 2 on demand — recomputing NAV under an alternate price source and flagging the delta — before a formal reconciliation cycle even starts.
Questions, answered
What is an acceptable NAV discrepancy for a crypto fund?
There is no single acceptable number. A defensible reconciliation separates position completeness (which should be 100%, no exceptions) from ledger accuracy under matched pricing (typically tolerated to 5 basis points of gross asset value) and per-investor allocation (5 basis points or $1, whichever is greater). Treating NAV variance as one number hides which of these is actually failing.
Why would two correct NAV calculations disagree at all?
Because "correct" allows for legitimate methodology choices: which price source and timestamp was used, whether management fees accrue daily or monthly, when performance fees crystallise, trade-date versus settlement-date treatment, staking income recognition timing, and tax lot method. None of these is an error on its own, but they all move the number.
What does gate 2 (ledger accuracy) actually test?
Gate 2 re-runs a NAV calculation using the counterparty's own price marks rather than your own, then compares the result. Because both sides are now pricing from the identical source, any remaining variance is attributable to the general ledger, accrual logic, or cash treatment — not to a disagreement about asset value.
Why is the per-investor gate harder to pass than the headline NAV gate?
Aggregate NAV can tie perfectly while individual capital accounts are still wrong, particularly where a fund runs multiple share classes or series with independent high-water marks and mid-period subscriptions or redemptions. Getting every investor's accrued performance fee and equalisation correct requires the allocation logic itself to be right, not just the top-line total.
What is the point of a pricing-methodology delta that is not scored?
It documents, line by line, where and why two sets of price marks diverge — source, timestamp, and rationale — without forcing a pass/fail verdict. It is often the most useful page in a reconciliation pack because it can surface a real operational issue, such as an administrator marking a thin-liquidity asset from a single exchange, that a binary tolerance test would never reveal.