DEV Community: Christian Pichichero

Allowlists Are Not Spending Caps: Two Different Security Properties, Often Confused

Christian Pichichero — Thu, 03 Sep 2026 18:05:38 +0000

If you've ever configured a delegated signer, a session key, or a bot's wallet permissions, you've probably reached for two knobs: an allowlist of assets it's allowed to touch, and a cap on how much value it can move. It's tempting to treat these as two settings on the same dial — both feel like "limits." They're not. They prevent different failure modes, and conflating them is how permission systems end up weaker than their configuration screen suggests.

What a spending cap actually prevents

A spending cap bounds magnitude. If a delegated key can move at most 500 USDC per day, then no matter what it does with that authority — swap, stake, send to an arbitrary address — the maximum damage from a compromised or misbehaving key is 500 USDC. It says nothing about what the money touches. A cap enforced correctly stops a runaway loop or a fully compromised signer from draining a wallet in one shot. It does not stop that signer from moving the capped amount into something worthless.

What an allowlist actually prevents

An allowlist bounds scope. If a signer can only interact with three named token contracts, then even with no spending cap at all, it categorically cannot send funds to an arbitrary address or interact with an unknown contract. This is a different property: it's not about how much moves, it's about which counterparties are even reachable.

The two compose well in theory — cap the blast radius, and separately narrow the attack surface — but each has failure modes the other doesn't cover, and "we have both" is not the same claim as "we're safe."

Failure mode 1: the allowlisted token isn't the code you allowlisted

An allowlist entry is usually just an address. But an address is not fixed behavior. If the token contract sits behind a proxy — which a large fraction of tokens do, for legitimate upgrade reasons — the logic executed when your signer calls transfer or approve can change after you added the address to your list. You audited version 1. The proxy now points at version 2. Your allowlist still matches, because the allowlist only ever checked the address, and the address never moved. This isn't a hypothetical: it's the entire reason "audit the contract, then allowlist the address" is a weaker guarantee than people assume — the audit has a timestamp, the allowlist doesn't.

Failure mode 2: the router that accepts arbitrary calldata

A lot of "swap-only" permission schemes are enforced by pointing the signer at a router contract instead of individual token contracts, on the theory that a router only does swaps. But look at what the router's function signature actually accepts. Plenty of router and aggregator interfaces expose something shaped like:

function execute(address target, bytes calldata data) external;

That's not a swap function. That's a generic call forwarder that happens to usually be used for swaps. If your policy allowlists the router's address and stops there, you've allowlisted "anything the router is willing to forward," which — depending on the router's own internal checks — can include calls into arbitrary target contracts with arbitrary calldata. The allowlist has to be checked against the target and selector inside the calldata, not just the outermost contract address, or it isn't restricting anything meaningful.

Failure mode 3: "it can only swap" is a claim about a function signature you haven't read

This is the general version of failure mode 2. "Swap-only" is not a security property until you know exactly what parameters the swap function takes. A swap function that hard-codes the output token and the pool is a narrow, auditable action. A swap function that takes a path: address[] or a router: address parameter chosen by the caller is, functionally, "call arbitrary code with a legitimate-looking wrapper around it." The English sentence "it can only swap" is doing no work — the actual boundary is whatever the function's parameter types and the policy engine's validation of those parameters allow. Read the signature, not the label.

A practical checklist

When someone tells you an authorization is scoped, four questions separate a real boundary from a documentation claim:

Allowlisted at what granularity — contract address, function selector, or full calldata shape?
Capped on what — per-transaction, cumulative, or notional value at execution time (which can be gamed by slippage)?
Enforced where — checked by a policy engine before signing, checked by the contract itself on-chain, or just described in a UI with no enforcement at all?
What happens when a check fails — does the transaction revert, or does the check silently pass because the policy engine and the contract disagree about what "the same asset" means?

None of this makes allowlists useless. It makes them one layer, with a specific and narrow claim, that has to be paired with selector-level restriction and cap enforcement at the layer that actually executes the call — and it means the honest description of any "restricted signer" is a list of exactly what's checked and where, not the word "scoped" on its own.

Disclosure: I build Tradevo, which runs delegated strategy execution through a scoped session signer with a token allowlist, per-subscription allocation cap, and slippage limits — enforced by the signing provider's policy and by our own executor, not by the chain, which is exactly why I spent this piece on where enforcement actually lives instead of what the label says.

The Fill Model Is Where Backtests Quietly Cheat

Christian Pichichero — Thu, 03 Sep 2026 12:54:19 +0000

Every backtest has to answer a boring question: when the strategy says "buy," what price does it actually get? Most backtesting frameworks answer this question badly by default, and the badness is almost always in the strategy's favor.

Here are the four assumptions that do the most damage, roughly in order of how often they show up.

Mid-price fills

If your backtest fills orders at the midpoint of the bid-ask spread, you are assuming you trade for free. You don't. A market order pays at least half the spread to cross it; a marketable limit order pays something close to that too, once you're honest about how often it actually gets hit versus sitting unfilled while the market moves away. Mid-price fills are the single most common way a backtest manufactures edge that doesn't exist, because the effect compounds with trade frequency — a strategy that trades often looks great on mid-price fills and mediocre-to-negative once it pays the spread on every round trip.

Zero slippage

Slippage is the gap between the price your signal fired at and the price your order actually executed at, and it's not just a queuing artifact — it's partly information. If your strategy is buying because something changed, other participants are reacting to the same thing, and the price you wanted is often gone by the time your order reaches the book. A backtest with zero slippage is quietly assuming the market waits for you.

Unlimited size at the touch

Backtests routinely assume you can execute your full position size at the best bid or ask, no matter how large the order is relative to the visible size there. In practice, a large order walks the book, and the average fill price is worse than the touch price by an amount that depends on how thin the book is. This one is invisible until you try to size up, which is exactly when a strategy that looked fine in testing starts bleeding.

Commissions omitted or averaged

Commissions and fees are usually small per trade and therefore easy to skip or fold into a rough average. But a strategy with thin per-trade edge and high turnover can have its entire expectancy eaten by costs that were treated as a rounding error.

A worked example

Take a mean-reversion strategy trading a $30 stock with a 2-cent spread: average win 18¢, average loss 14¢, win rate 55%.

expectancy (per share, before costs)
= 0.55 × 18¢ − 0.45 × 14¢
= 9.9¢ − 6.3¢
= 3.6¢

That 3.6¢ looks like a real edge. But if the backtest filled at the mid, it never paid the spread it would pay in live trading. A more honest fill — buying near the ask, selling near the bid — costs roughly the full spread on the round trip, here about 2¢. Subtract that:

3.6¢ − 2¢ = 1.6¢

The edge didn't disappear, but it lost more than half its value to an assumption that never showed up as a line item anywhere in the report. Add a per-share commission and a little realistic slippage on top, and it's easy to see how a strategy with a "good" backtest turns out to be trading the spread, not an actual signal.

What you can actually check from a trade list

If all you have is a CSV of closed trades — entry, exit, size, timestamps — there's a limit to how much of this you can diagnose. You can check sensitivity: rerun expectancy with a range of assumed slippage and spread costs and see how much of the edge survives. You can check whether wins are concentrated in trades with unusually favorable prices relative to the surrounding bars, which is a proxy for lookahead or mid-price fills. You can check whether performance depends on a handful of trades — if removing the best 5% of trades erases the edge, that's worth knowing regardless of the fill model.

What you generally can't check from a trade list alone is anything that requires order book state: actual queue position, actual available size at the touch at the moment of the signal, actual latency between signal and order arrival. Those require tick-level or order-book data and a simulator that models the exchange mechanics, not just entry and exit prices. If someone tells you they can fully validate execution realism from a CSV of closed trades, they're skipping something — the honest version of this check is partial, and it should say so.

The practical test

The cheap version of all this: take your reported average win and average loss, subtract a full spread crossing on both entry and exit, and see if the strategy still has positive expectancy. If it doesn't survive that adjustment, the edge was largely the spread it never paid, and no amount of additional testing further downstream is going to rescue it. If it does survive, you've at least confirmed the edge isn't purely a fill-model artifact — which is a different question from whether it will hold up in other ways, but it's the first one worth asking.

Disclosure: I build Tradevo Verify, which takes a closed-trade export and runs it through this kind of stress-testing, among other checks, and produces a versioned evidence record rather than a verdict on whether the strategy is good.

What 'Revocable' Actually Means at the Contract Level

Christian Pichichero — Tue, 01 Sep 2026 11:05:03 +0000

If you've ever called approve() on an ERC-20 token and then moved on with your life, you've already brushed up against the thing this post is about: an approval is not a setting inside some app, it's a row in a smart contract's storage, and every system built on top of it is only as honest as its last read of that row.

Most token approvals work the same way. A user signs a transaction granting a spender contract permission to move up to some amount of a token from their wallet. The ERC-20 standard stores this as allowance[owner][spender]. Any contract that wants to move the user's tokens checks that number before doing so, and the check happens inside the same transaction that tries to move funds — so the contract-level enforcement is real. The token contract itself will not let a transfer through if the allowance is insufficient.

Revocation is just another write to that same slot, usually setting it to zero. It's a normal transaction. It has to be signed, broadcast, and mined like any other. That's the part people gloss over: revoking is not a UI toggle, it's a transaction with all the same properties as the transaction that created the approval in the first place — it sits in a mempool, it can be delayed by network congestion, and it isn't final until it's in a confirmed block.

Where the gap shows up

Say you're building a service that executes on a user's behalf using a stored approval — a trading bot, a subscription payment puller, anything with an off-chain component that decides when to spend and an on-chain component that actually moves the funds. The natural design is to keep a local record: "user X has approved up to Y, active." That record is convenient. It's also just an opinion your own server holds about the world, and it can be wrong in both directions.

It can be wrong stale-permissive: the user revokes, your service hasn't seen it yet, and if the on-chain check before spending is missing or weak, you build and sign a transaction anyway. Depending on how you structured the check, this either fails harmlessly at the token contract (wasted gas, a failed tx, an alert) or, if you did something sloppier — like checking your database instead of the chain — you send a transaction that the chain itself will still reject, because the allowance really is zero now. The token contract is the backstop here, which is good, but you don't want your system's normal path to depend on that backstop catching your own mistake.

It can also be wrong stale-restrictive: your database says revoked, but the revoke transaction is still sitting unconfirmed, and the user expects it to be in effect immediately because that's what the button said. This one is more of a UX problem than a safety problem, but it's the same root cause — a record and the chain disagreeing about what's true right now.

Why the check has to happen at the moment of execution

The fix sounds almost too obvious to write down: before doing anything that spends a user's tokens, read the allowance from the chain, right then, not from whatever your database cached the last time you looked.

function attemptExecution(user, requiredAmount) {
 onChainAllowance = readAllowance(user); // the ground truth, right now
 if (onChainAllowance < requiredAmount) {
 skipAndLog(user, "allowance insufficient at execution time");
 } else {
 sendExecutionTx(user, requiredAmount);
 }
}

This has real costs. Every execution now needs an RPC round-trip before it can act, which adds latency and adds load on whatever node provider you're using. If you're executing for many users on a schedule, that's a lot of extra reads for what is, most of the time, a value that hasn't changed since the last check. There's also a subtler question buried in "read from the chain": read at what block? RPC providers don't all agree on the very latest block during a reorg, and a read that lands on a block that later gets replaced is its own small version of the same trust problem, one layer down. Treating the freshest confirmed state as authoritative, and re-checking rather than caching, is the mechanism — it doesn't make the read instantaneous or immune to provider disagreement, it just means you're asking the right question at the right time instead of trusting an answer that might be minutes or days old.

What breaks mid-cycle

The uncomfortable case is a multi-step action — say a swap that routes through two pools, or a strategy that does three on-chain calls in sequence to complete one logical action. If a user revokes between step one and step two, step one already happened. You can't undo it. The system has to be built so a partial completion is a safe, loggable state rather than an unrecoverable one — which mostly means designing each step so it's fine to stop after it, not chaining steps that only make sense together and hoping revocation never lands in the middle. That's a design constraint, not something the revoke mechanism itself solves for you.

None of this makes revocation less real. The user genuinely can remove the authorization, and once that transaction confirms, the contract genuinely will not let the spender move their tokens anymore — that part is enforced by the token contract itself, not by anyone's goodwill. What it means is narrower and more mechanical than "revocable" sounds: it's a state change on a specific chain, subject to that chain's confirmation times, and any executor sitting on top of it is only trustworthy if it treats its own records as a guess and the chain as the check.

Disclosure: I build Tradevo, which runs automated strategies on Base from wallets whose keys the user holds. More at app.tradevo.co. The trade-offs above are ones I have had to think through rather than ones I am claiming to have solved.

Scoped Permissions vs Custody: Letting Software Act On-Chain Without Holding Your Keys

Christian Pichichero — Tue, 01 Sep 2026 02:19:59 +0000

If you've ever set up a recurring on-chain action — a DCA buy, a rebalance, a claim-and-restake — you've run into the same fork in the road: either you hand a private key to something (a bot, a script, a service), or you sign every transaction yourself and the automation stops being automatic. Custody is the easy way out of that problem, and it's also the thing that goes wrong most often in this industry. So it's worth being precise about what "non-custodial automation" actually means mechanically, because the phrase gets used loosely.

There are two structurally different ways to let a piece of software act from your wallet without giving it your funds.

Delegated session signers. You generate a separate keypair, authorize it (usually via a signed message or an on-chain transaction) to act on your account, and hand the private half to a service. The service's backend now holds a key that can sign transactions on your behalf. Non-custodial in the narrow sense that your main wallet's key never leaves your device — but the scope of what that session key can do is enforced by the vendor's own logic, before it ever reaches the chain. Something like this:

// backend, off-chain, before it decides to sign
const isCallInScope = (call, policy) =>
 call.target === policy.allowedTarget &&
 policy.spent + call.value <= policy.cap;

That's a real check, and a careful team writes it correctly. But notice where it lives: in a server you don't control, checked against a policy object that server maintains. If the backend has a bug, gets compromised, or is simply told by an operator to ignore the cap for one call, nothing on-chain stops it. The chain sees a validly signed transaction from an authorized key and executes it. The account itself has no opinion about whether the call was "in scope" — it trusted the key, full stop.

Account-enforced permissions (ERC-7715 style). The newer approach, built for smart accounts under ERC-4337 and formalized in proposals like ERC-7715, moves the scope check into the account's own validation logic via caveat enforcers. When you grant a permission, you're not just handing over a key — you're installing a rule inside your account that every action from that permission has to pass, checked by the account contract itself at execution time:

// runs in the account's validation path, on-chain
function enforceCaveat(bytes calldata call, Caveat calldata c) external view {
 require(call.target == c.allowedTarget, "target not allowlisted");
 require(c.spent + call.value <= c.cap, "exceeds cap");
}

The difference sounds small but it isn't. In the 7715 model, even if the delegate's key is fully compromised, the account contract rejects any call that violates the caveat — the enforcement is data the account carries, not trust the account extends. Revocation is also a first-class on-chain action against your own account state, not a request you send to someone else's server and hope gets honored before the next scheduled run.

The honest trade-off: 7715 requires your wallet to be a smart account that supports the standard, and tooling for it is still young — wallet support is uneven, and the caveat-enforcer ecosystem (which enforcers exist, which are audited, which compose safely with each other) is not mature. The session-signer approach works today with wallets that have none of that infrastructure, and for a lot of use cases it is a reasonable, shippable answer. It's just that when you use it, the meaning of "scoped" is a promise made by a company's backend code, not a rule your account carries. That's a real distinction, not a pedantic one, and it's worth asking any "non-custodial automation" product which side of it they're on.

A few other things are true regardless of which model you pick. Gas sponsorship (someone else pays gas so the user doesn't need a native-token balance sitting around) is orthogonal to custody — you can sponsor gas under either architecture. An allowlist of target contracts and an allocation cap reduce blast radius but don't eliminate it: a bug in an allowlisted contract, or a cap set too high, still lets real money move. And revocability is only as good as how quickly it takes effect — an on-chain revocation is final the moment it's mined; an off-chain "we'll stop signing now" is final whenever the backend process notices.

Disclosure: I build Tradevo (app.tradevo.co), which runs algorithmic strategies from a wallet whose keys the user holds. More at app.tradevo.co. I'm not claiming it's the account-enforced version described above; it's worth being clear about which one you're actually getting, from us or anyone else, before you sign anything.

What Shuffling Your Trade History Actually Tells You (And What It Doesn't)

Christian Pichichero — Mon, 31 Aug 2026 17:50:01 +0000

You ran a backtest. The equity curve is smooth, the drawdown is small, the Sharpe ratio looks respectable. Here's the thing nobody tells you early enough: that curve is one path. It's the result of your trades happening in exactly the order they happened. If trade #14 (a big loser) had landed right after trade #3 (another big loser) instead of scattered safely between winners, your drawdown number would be a different number, from the same trades, with the same win rate, same average win, same average loss.

That's the whole motivation for Monte Carlo trade resampling. You take the list of closed trades — just the P&L values, stripped of their original sequence — and you reshuffle them, thousands of times, rebuilding an equity curve for each shuffle. Two common flavors:

Permutation (resampling without replacement): every shuffle uses the exact same set of trades, just in a different order. Total return is fixed across all shuffles; only the path changes — which is precisely the point, since path determines drawdown and time-underwater.
Bootstrap (resampling with replacement): each shuffle draws trades at random, allowing repeats and omissions. This also perturbs the total return, not just the order, giving you a sense of variance from sample size, not just sequence.

Here's a minimal version of the permutation approach:

import numpy as np

def max_drawdown(equity):
 peak = np.maximum.accumulate(equity)
 dd = (equity - peak) / peak
 return dd.min()

def resample_paths(trade_returns, n_sims=5000):
 trades = np.array(trade_returns)
 results = []
 for _ in range(n_sims):
 shuffled = np.random.permutation(trades)
 equity = np.cumprod(1 + shuffled)
 results.append(max_drawdown(equity))
 return np.array(results)

Run this on 80 closed trades and you don't get one drawdown number, you get a distribution of 5,000 drawdown numbers. That distribution is the actual output worth looking at. Somewhere in there is a 5th percentile case — a drawdown notably worse than the one your backtest happened to show you, built from the exact same trades. If your original backtest's drawdown sits near the friendly end of that distribution, your single equity curve got lucky on ordering, and you didn't know it because you only ever looked at the one path that occurred.

The median-path trap

Here's where people go wrong once they've done the resampling correctly: they look at the median drawdown, or the median final equity, and treat it as "the expected outcome going forward." This is a mistake for a specific mathematical reason, not just a vague warning. Max drawdown is a nonlinear, path-dependent statistic — it's the result of a maximum and a minimum operating over the whole sequence. When you average or take the median of thousands of nonlinear statistics, that summary number doesn't correspond to any real path anyone actually experiences. There is no shuffle in your simulation set whose drawdown equals the median drawdown by construction — it's a statistic about the population of outcomes, not a description of a plausible one.

Worse, the distribution of drawdowns is almost always right-skewed (bounded at zero, long tail toward catastrophic). The median underrepresents the tail. If you're using this number to size positions or set risk limits, you want the 90th or 95th percentile of drawdown, not the middle of the pack — the middle is the case where nothing went particularly wrong, which is not the case you're trying to survive.

The assumption everyone skips: independence

Both permutation and bootstrap resampling rest on one assumption: that each trade's outcome is independent of the trades around it — that shuffling the order doesn't destroy any real information, because there wasn't any sequential structure to begin with. For a lot of systematic strategies this is roughly fine. For momentum strategies, it's false, and it's false in a way that matters.

Momentum strategies, by construction, tend to produce autocorrelated trade outcomes: winning trades cluster during trending regimes, losing trades cluster during chop or reversals, because the underlying edge itself is regime-dependent. When you randomly permute those trades, you break up the clusters. This can cut both ways — sometimes it makes the resampled drawdowns look worse than reality, because it creates unlucky strings of losses that would never actually co-occur (a losing streak needs a choppy regime, and regimes don't get randomly interleaved trade-by-trade in real markets). Other times it hides the real risk, because the actual worst case is "strategy stops working when the regime changes for three months straight," and no reshuffling of historical trade P&L will manufacture a scenario the strategy never lived through.

Block bootstrapping — resampling contiguous chunks of trades instead of individual ones — partially addresses this by preserving some local correlation structure. It's a real improvement, not a full fix. It still can't invent a regime your strategy never traded through, and it still assumes the blocks are exchangeable, which is a weaker but still real assumption.

So what resampling actually tells you: how much of your backtest's apparent smoothness depended on the specific order the trades happened to arrive in, and how much of that ordering is even ordering you can trust reshuffling to explore honestly. It's a stress test on a fixed sample, not a forecast, and treating the tidy version — the median path, or a permutation test on a momentum book — as the expected future is the fast way to be surprised by a drawdown your simulation told you was rare.

Disclosure: I build Tradevo Verify, which runs this kind of resampling (among other checks) against closed-trade exports and reports the resulting distribution rather than a single pass/fail number — because the distribution is the honest answer and a single number usually isn't.

What a Clean Equity Curve Doesn't Prove

Christian Pichichero — Mon, 31 Aug 2026 17:27:25 +0000

You've seen the shape before: equity curve going up and to the right, Sharpe ratio north of 2, max drawdown that looks survivable. It's convincing. It's also, on its own, close to worthless as evidence that the strategy will do anything useful going forward.

This isn't a claim that backtesting is pointless. It's that a single backtest, however clean, can hide four specific failure modes that don't show up in the summary stats you're staring at. You have to go looking for them in the trade list itself.

1. Return concentration

Open your closed-trade export and sort by PnL, descending. Sum the top 3 trades. Sum everything else. If the top 3 account for most of your total return, your backtest isn't describing a strategy — it's describing a small number of events that happened to occur in your sample window.

trade_id, pnl
1, 120
2, -40
3, 3800   <- one trade
4, -60
5, 90
...
47, -30

A strategy with 47 trades where one trade is 90% of total profit isn't a systematic edge, it's a lottery ticket that paid off once during backtesting. The Sharpe ratio doesn't tell you this. The equity curve doesn't tell you this, because one big trade still draws a smooth-looking line. You have to look at the distribution of individual trade PnL, not the cumulative sum.

The fix isn't to throw away the trade — maybe it was real. The fix is to know it's there before you size a live position based on "the strategy averages X% per trade."

2. Regime dependence

A strategy backtested from 2019 to 2023 has lived through exactly one dominant regime: a multi-year bull market interrupted by one sharp, fast-recovering crash. If your entries are long-biased and your backtest window doesn't include a prolonged sideways or bear regime, you haven't tested a strategy — you've tested a strategy's performance during one macro condition, and gotten a result that will not generalize.

The way this hides itself: date range selection feels neutral. "I used all the data I had" sounds responsible. But if all the data you had happens to be one regime, your Sharpe ratio is really a Sharpe ratio conditioned on that regime, and nothing in the report tells you that conditioning exists. You find it by segmenting trades by market condition (trend vs. chop, high vol vs. low vol) and checking whether performance holds up in each segment separately, not just in aggregate.

3. Execution assumptions doing the work

Every backtest makes assumptions about fills: what price you get, how much slippage, whether you can actually get filled at all at the size you're testing. These assumptions are usually buried in a config file or a default in your backtesting library, and they are frequently the entire source of the edge.

A mean-reversion strategy that assumes fills at the exact touch price on a thinly traded instrument is not describing a strategy — it's describing what happens if you had a magic wand for that one variable. Move the assumption from "fill at touch" to "fill at touch plus one tick" and watch a lot of "profitable" systematic strategies go flat or negative. This is worth doing as a deliberate stress test: take your existing trade list, degrade the fill assumption by a fixed amount, and recompute. If the strategy's profitability doesn't survive a small, realistic degradation, the edge was execution assumption, not signal.

4. Path luck

Even a strategy with real, non-concentrated, regime-robust edge produced one specific sequence of trades, in one specific order, during one specific slice of history. That sequence is a single sample from a distribution of possible sequences. Some of those alternate sequences look much worse — deeper drawdowns, longer flat periods, sequences where the losing trades cluster early and you'd have quit before the edge showed up.

The standard way to check this is to shuffle: take your trade returns, resample them (with replacement, or reorder them, depending on what you're testing for), and generate a distribution of possible equity curves instead of the one you happened to get. If your actual curve sits near the median of that distribution, the drawdown you experienced is typical. If your actual curve is near the best-case tail, you got lucky with path, and a live version of this strategy is more likely to look like the median case — which might include a drawdown you didn't plan for.

What this adds up to

None of these four checks are exotic. Concentration is a sort and a sum. Regime dependence is a segmentation. Execution sensitivity is a parameter sweep. Path luck is a resample. You can build all of this yourself in an afternoon with pandas and numpy, and if you're serious about running a systematic strategy with real money, you should — at minimum look at your trade list sorted by PnL and ask if 3 trades are secretly the whole story.

The uncomfortable conclusion is that a clean equity curve is weak evidence by default. It's evidence of what happened in one sample, once, under one set of fill assumptions. Turning it into evidence you can actually lean on means trying to break it, not admiring it.

Disclosure: I build Tradevo Verify, which runs a version of these checks (execution stress, path/Monte Carlo, concentration, regime tests) against a closed-trade CSV and returns a report on how much weight the evidence can carry — not a verdict that the strategy is good. It's a $99 one-time check, and it's built to return a fragile result whenever the trade list earns one.

Point-in-Time Fundamentals for Numerai Signals: Killing Lookahead in Your Feature Join

Christian Pichichero — Wed, 19 Aug 2026 16:00:35 +0000

If you build features for Numerai Signals from fundamentals, the single most common way to silently overstate your live performance is joining on the wrong date. A table keyed by fiscal period end, or by a single "report date" that is overwritten on every revision, cannot tell you when a number was actually knowable. Our rows are keyed by first_filed — the date the value first appeared on EDGAR — with the first-reported value stored separately from the current one. Numerai's tournament resolves against real future returns, so any leakage in your feature construction shows up as a validation metric that decays the moment you go live. (This is not investment advice, and nothing here is a performance promise.)

This article covers three things: why lookahead leaks into fundamentals-based signals even when you think you've handled it, how a first_filed-keyed join fixes the mechanics, and where a small, honest, US-annual-only dataset like ours fits — and where it doesn't.

Why fundamentals leak into signals more than price data does

Price and volume are point-in-time by construction — the close on Tuesday was known Tuesday night. Fundamentals are not. A 10-K covering fiscal year 2022 might be filed in March 2023, restated in an amendment in August 2023, and then sit in a vendor's database keyed only by "period end 2022-12-31." If your pipeline joins on period end and pulls whatever value is in the database today, you're feeding your model information that didn't exist yet, and sometimes a corrected number that didn't exist until months later.

This is a bigger problem for fundamentals than most people expect, because:

Filing lag varies a lot by company size and quality. Some filers report a few weeks after period end (rare), most take one to three months, and small caps can lag further.
Restatements are common and not always flagged. If a value changes across amendments and you don't know which version was live on a given day, backtests can pick up the revised number, which can correlate with future returns simply because it was derived with hindsight.
Numerai's eras compound the problem. Signals are scored weekly across thousands of tickers; a systematic few-week lookahead bias across the whole universe doesn't average out — it can inflate validation metrics uniformly, which is worth checking for if a validation curve looks unusually strong.

We wrote a longer, more technical breakdown of this mechanism in Lookahead Bias in Fundamental Backtests if you want the failure modes in more detail.

The correct join: `first_filed`, not period end

The fix is mechanical once you have the right column. Every fundamentals row needs a first_filed timestamp — the date the value became public via SEC EDGAR — separate from the fiscal period it describes. For a given Numerai submission date as_of, the query is:

SELECT * FROM fundamentals
WHERE ticker = ?
  AND first_filed <= as_of   -- same-day inclusive
ORDER BY first_filed DESC
LIMIT 1

That is the filing-date half of the leakage fix: the filter is first_filed <= as_of, applied per row, instead of a uniform "lag by 90 days" heuristic across every filer (which both under- and over-corrects depending on the company). You also want two values per row, not one:

original_value — the first-reported figure, safe for point-in-time backtests.
latest_value — the current, revision-including figure, useful only if you're deliberately studying restatement effects.

We key our dataset this way: first_filed, original_value, latest_value, a restated flag (set when a same-tag revision exceeds 0.5%, including amendments), and qa_status. Across our current build, 18,723 rows carry that restated flag out of 312,751 total — restatements are common enough that ignoring them isn't a rounding error.

What our dataset is (and explicitly is not)

Tradevo Data (tradevodata.com) is a point-in-time US equity fundamentals dataset sourced entirely from SEC EDGAR (public domain data, not redistributed from a paid vendor). Currently: 5,189 US companies, 312,751 point-in-time rows, 7 core concepts (Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares), up to 12 fiscal years of history, annual only — 10-K and 10-K/A filings. Quarterly is on the roadmap, not shipped. If your Numerai signal design needs quarterly fundamentals or non-US tickers, this dataset will not cover you today — say so up front rather than let you find out after checkout.

Access is one JSON endpoint, /v1/fundamentals?ticker&as_of[&concept], server-side first_filed <= as_of filtering built in, plus the full dataset via /v1/download and whole-universe cross-sections via /v1/snapshot?as_of — all included in the $49/mo plan, 5,000 requests/day and 2,500 distinct tickers/day (use /v1/snapshot or /v1/download for cross-sections). No quarterly, no non-US, no Parquet yet (CSV/gzip only; Parquet is roadmap).

On lag: on the reliable-filing rows of our 40-company free sample, the gap between fiscal period end and first_filed was mean 43.4 days / max 61 days. That figure is scoped to the sample. Across the full 5,189-company universe the reliable-row gap is wider — mean 66 days, median 60, p90 90 — because large caps are the fastest filers, so don't extrapolate the sample figure to the whole universe.

Fair comparison

	Tradevo Data	Sharadar (Nasdaq Data Link)	Tiingo	QuantConnect	Build it yourself from EDGAR
Point-in-time fields	Yes (`first_filed`, original + latest)	Yes, per their docs	Fundamentals PIT coverage varies, check their docs	Yes, via their data infra	Yes, if you build it correctly
Frequency	Annual only	Annual + quarterly, per their docs	Varies by plan	Varies by plan	Whatever you extract
Coverage	US only	US, check their docs for depth/history	US-focused	Multi-asset via platform	Whatever you scope
Price	$49/mo flat	See their pricing page	See their pricing page	See their pricing page	Your engineering time
Restatement flags	Yes, explicit	Check their docs	Check their docs	Check their docs	You build the logic

We don't know competitors' current prices and won't guess — check their pricing pages directly, they change.

When another option is genuinely better

If you need quarterly fundamentals for Numerai Signals features (which many quality/growth factors want), Sharadar or a comparable vendor with quarterly PIT coverage is the right call today — we don't have it. If you need international equities, none of what's here helps; we're US-only. If you're already inside QuantConnect's ecosystem and want fundamentals integrated with their backtester and live trading, their bundled data may save you more integration time than a standalone API, even before comparing price.

When to build it yourself

EDGAR's data is public and free. If you only need a handful of concepts for a handful of tickers, and you're comfortable parsing XBRL and handling amendment logic yourself, you can build a first_filed-keyed table in a weekend. The tradeoffs: you own restatement detection, filer-level edge cases (fiscal year changes, non-calendar year ends, multiple amendments to the same period), and ongoing maintenance as EDGAR's XBRL taxonomy shifts. For a few tickers, doable. For thousands of tickers across multiple years, it becomes a real data-engineering project — which is the gap we built this to fill.

Try before you subscribe

The free sample — 40 companies, 3,280 rows, full methodology, no signup — is on GitHub. Run your own join logic against it before paying for anything. If it fits your Signals pipeline, the full dataset is $49/mo, instant key after Stripe checkout, cancel anytime. More on the mechanics of PIT fundamentals generally: Point-in-Time Fundamentals Data, Explained.

Not investment advice; verify any competitor pricing yourself on their current pricing pages.

Why the Same Fundamental Lives Under Different XBRL Tags in SEC EDGAR

Christian Pichichero — Wed, 12 Aug 2026 16:31:22 +0000

If you've tried to pull "revenue" for a US company directly out of SEC EDGAR's XBRL data, you've probably noticed something annoying: the same line item on the income statement doesn't always show up under the same tag. One year it's Revenues. Another year, for the same company, it's SalesRevenueNet. After 2018 it might switch again to RevenueFromContractWithCustomerExcludingAssessedTax. Nothing about the business changed — the taxonomy did.

This is one of the least-discussed but most consequential problems in building point-in-time fundamentals from EDGAR, and it's the reason a lot of DIY XBRL scrapers quietly produce broken time series without anyone noticing until a backtest looks weird.

Why the tags change at all

The SEC requires filers to tag financial statement line items using the US GAAP XBRL taxonomy, which the FASB updates annually. A few things drive tag churn:

Taxonomy revisions. New tags get added, old ones get deprecated, and companies (or their filing agents) migrate to the current tag in a later filing — sometimes mid-history, sometimes not at all.
Accounting standard changes. The rollout of ASC 606 (revenue recognition) around 2018 is the clearest example: many filers moved from Revenues or SalesRevenueNet to RevenueFromContractWithCustomerExcludingAssessedTax or the "IncludingAssessedTax" variant, sometimes in the same fiscal year they adopted the standard.
Filer inconsistency. Two companies in the same industry, filing in the same quarter, can choose different (both technically valid) tags for what an analyst would call the same concept. Smaller filers and their outside preparers are especially inconsistent year over year.
Custom/extension tags. Filers can create company-specific extension tags instead of using a standard one, which is valid XBRL but invisible to anyone matching on a fixed tag list.

None of this is a data error. It's just how the taxonomy and filer behavior evolve. But if your pipeline hardcodes "revenue = tag X," you will silently lose or corrupt history the moment a company switches tags.

How this breaks naive datasets

The common failure mode looks like this: a script pulls Revenues for every 10-K, going back as far as the filer used that tag. The moment the company switches to RevenueFromContractWithCustomerExcludingAssessedTax, the naive pull sees a gap — the concept looks like it disappeared. Depending on how the downstream code handles missing values, you get one of three quiet failures:

A false gap in the time series (treated as no revenue reported).
A forward-fill of the last known value, understating growth or flatlining a metric that actually changed.
A join against the wrong tag entirely, if a fallback rule grabs a different line item that happens to exist (e.g., falling back to SalesRevenueGoodsNet and picking up only product revenue, not total revenue).

All three are worse than an explicit "no data," because they don't look like errors — they look like real numbers. That's the trap: tag drift doesn't crash your pipeline, it silently biases it.

How synonym-tag resolution actually works

The fix is conceptually simple but tedious to do correctly: instead of mapping one concept to one tag, you maintain a synonym set of tags per concept and resolve among the candidates present in each filing, rather than baking in a single tag at ingest time.

In practice, for Tradevo Data that means:

Each of our seven tracked concepts (Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares) maps to a list of known US GAAP tags that filers have used for that concept, not a single tag.
When a filing is parsed, the synonym tags present in that same filing are compared rather than ranked. Every candidate on the list is intended to be a consolidated total, so when two of them disagree materially the larger is the total and the smaller is a component of it, and the larger wins. The tag that actually resolved is recorded on the row, so the mapping is auditable rather than a black box. We used to apply a fixed priority order, and it shipped a 10× error on General Mills — the post-mortem explains why no fixed ordering gets MetLife and General Mills right at the same time.
We track first_filed (when the value became public) separately from latest_value (the current, possibly amended figure), and flag rows as restated when a same-tag revision moves the value by more than 0.5%, including amendments. That's how the dataset ends up with 18,723 labeled restatements — those are tag-consistent revisions, not tag-switch artifacts.
qa_status on each row exists specifically so a switch that looks suspicious (e.g., a jump coinciding with a tag change) is visible to whoever is using the data, rather than silently smoothed over.

The full mapping logic and the reasoning behind it — including which tags we treat as synonyms for each concept and why — is public in the methodology alongside the free sample, not hidden behind the paid API. If you want to see exactly how a specific company's revenue tag changed over time, that's the place to check it yourself: github.com/christianpichichero-max/pit-fundamentals (3,280 rows across 40 companies, full methodology, no signup).

For the point-in-time angle specifically — why first_filed matters independently of tag resolution — see /blog/point-in-time-fundamentals-data and /blog/lookahead-bias-fundamental-backtests.

A fair comparison of your options

Approach	Handles tag drift?	Point-in-time (`first_filed`)?	Frequency	Cost
Raw SEC EDGAR + your own scraper	Only if you build synonym mapping yourself	Only if you build it (EDGAR gives you filing dates, not a PIT API)	Whatever you implement	Free (your engineering time)
Tradevo Data	Yes, synonym sets per concept, documented in the free methodology	Yes, `first_filed` + `original_value` on every row	Annual only (10-K / 10-K/A); quarterly is on the roadmap, not available today	$49/mo
Sharadar / Tiingo / QuantConnect fundamentals	Not independently verified by us — these are established, mature vendors, so check their docs for specifics	Varies by product; check each vendor's docs	Varies by product; check each vendor's docs	See their pricing pages: Sharadar via Nasdaq Data Link, Tiingo, QuantConnect

This isn't an attempt to declare a winner. We haven't audited Sharadar's, Tiingo's, or QuantConnect's internal tag-resolution logic, so we're not claiming to know how they handle it — only that they're credible, established sources worth comparing against. If price or feature fit matters to your decision, their pricing pages will tell you what's on offer; we're not going to guess a number for you.

When the established players are the better choice

Be honest with yourself about what you actually need before defaulting to the cheaper option:

If you need quarterly fundamentals, Tradevo Data doesn't have them yet (roadmap only) — an established vendor that already offers quarterly data is the right call today.
If you need non-US markets, more historical depth than 12 fiscal years, or a broader concept set beyond our seven, a larger vendor's coverage is likely to fit better.
If you need a track record — a data provider that's been used in production research for years, with support SLAs and a sales team you can talk to — that's a real advantage of established players over a $49/mo budget tool run by a small team.
If Parquet or other formats matter to your pipeline today (not roadmap, today), check whether an established vendor already ships it.

We'd rather point you to the right tool than pretend we're the right tool for every use case.

When you should build it yourself

Building your own EDGAR XBRL parser is a legitimate choice, not just a fallback for people who can't afford data. It's the right call if:

You need concepts or tags outside the seven we track (segment data, non-GAAP reconciliations, footnote disclosures).
You need international filers or non-EDGAR sources.
You have engineering time to spend and want full control over the synonym-resolution rules rather than trusting someone else's judgment calls.
Your research only needs a handful of companies and a few concepts — at that scale, hand-checking tag switches against the actual 10-K filings is faster than integrating a new data source.

Where a vendor (any vendor, not just us) earns its cost is in the tedious part: tracking taxonomy changes across thousands of filers over many years, catching restatements, and doing it consistently so you're not re-solving the same tag-drift problem every time the FASB updates the taxonomy.

Try it before you pay for it

The free sample has the same tag-resolution logic as the paid dataset, just scoped to 40 companies and 3,280 rows — enough to inspect a real tag switch yourself and decide if the approach holds up: github.com/christianpichichero-max/pit-fundamentals.

If it does and you need the full 5,189-company, 312,751-row universe with a server-side as_of query, the API and bulk download (/v1/download, /v1/snapshot?as_of) are $49/mo, cancel anytime: tradevodata.com/?ref=blog.

Not investment advice. This dataset describes what was publicly filed and when — it makes no claims about future performance. Verify competitor pricing and feature claims yourself on their websites before deciding.

SEC 10-K Filing Deadline Data: The Structural Reason Fundamentals Lag Weeks Behind

Christian Pichichero — Wed, 12 Aug 2026 16:30:51 +0000

If you've ever wondered why a company's "Q4 numbers" aren't publicly known the day the fiscal year ends, the answer isn't vendor laziness or data-pipeline delay. It's the SEC's own filing calendar. The deadlines are public, stable, and have been in place for years — and they're the single biggest structural reason any honest fundamentals dataset has a gap between period-end and public availability.

This matters for anyone backtesting on fundamentals: if your data model assumes a number was known the moment the quarter closed, you're not modeling reality. You're modeling a fantasy calendar that doesn't exist.

The SEC's 10-K Deadlines Are Public and Fixed by Filer Class

Under SEC rules (Exchange Act Rule 12b-2 and related Regulation S-K guidance), the deadline to file an annual report (Form 10-K) after fiscal year-end depends on the company's filer category, which is based on public float:

Filer Category	Public Float Threshold	10-K Deadline After Fiscal Year-End
Large Accelerated Filer	$700M or more	60 days
Accelerated Filer	$75M to $700M	75 days
Non-Accelerated Filer	Under $75M	90 days

These thresholds and deadlines are public record, not proprietary knowledge. Any company can and does file earlier than its deadline — but a meaningful share file close to it, because compiling audited financials, running the audit committee process, and drafting MD&A takes real time. The deadline is a ceiling companies work toward, not a floor they clear early by default.

Why the Deadline Creates a Point-in-Time Gap

Here's the mechanical consequence: a fiscal year that ends December 31 might not have its 10-K publicly filed until late February (large accelerated), mid-March (accelerated), or the end of March (non-accelerated). That's a 60-to-90-day window baked into the regulatory structure, before you even account for filers who use extensions (Form 12b-25) or file 10-K/A amendments later.

So when you see a "FY2023 Revenue" figure, the honest question is: known to the public when? Not "as of fiscal year-end" — as of the date the 10-K (or amendment) actually hit EDGAR. Any dataset that timestamps fundamentals by fiscal period end instead of filing date is implicitly assuming zero-day disclosure, which the SEC's own deadlines show doesn't happen.

From Filing Date to "First Known" Value

This is why point-in-time (PIT) datasets track more than just the number. Tradevo Data's schema, sourced directly from SEC EDGAR (public domain), records for each row:

first_filed — the date the value first became public
original_value — the first-reported figure (the point-in-time-safe one)
latest_value — the current, possibly-restated figure
restated flag — set when a later filing changes the same tag by more than 0.5%, including amendments
qa_status

Across the dataset, 18,723 restatements carry the restated flag — a reminder that "the number" for a given fiscal year isn't fixed at first filing; it can move, and a PIT-correct backtest needs to use what was known on a given date, not what we know now with hindsight.

What We Actually Measured (Scoped Honestly)

On the free 40-company sample's reliable-filing rows, the measured lookahead — the gap between fiscal period end and first_filed — averaged 43.4 days, with a maximum of 61 days. That number is specific to the 40-company sample and should not be quoted as a property of the full 5,189-company, 312,751-row dataset, where the same gap is wider — mean 66 days, median 60, p90 90 on reliable-filing rows — because large caps are the fastest filers. We're not going to blur that line for a cleaner headline.

When a Bigger or Quarterly-Aware Vendor Is the Better Choice

In the interest of not overselling: if your strategy needs quarterly (10-Q) fundamentals, non-US equities, Parquet delivery, or a vendor with a longer operating track record and broader SLA guarantees, providers like Sharadar, Tiingo, or QuantConnect are worth evaluating — see their pricing pages directly, since we won't quote competitor prices here. QuantConnect in particular is worth a look if you want fundamentals data pre-integrated into a backtesting engine rather than delivered as a standalone feed. Tradevo Data is annual-only (10-K plus 10-K/A) for now, US-only, and delivered as JSON/CSV — quarterly and Parquet are roadmap items, not shipped features.

When to Build It Yourself from EDGAR

EDGAR's raw filings and XBRL data are free and public. If you only need a handful of tickers, have engineering time to spare, and want full control over parsing logic, building your own extractor is a legitimate option. The tradeoffs to budget for: XBRL taxonomy changes across years, handling 10-K/A amendments correctly so you don't silently overwrite original_value with latest_value, and building the first_filed logic so your backtest can't see a number before it existed. None of this is exotic, but it's also not a weekend project if you want it PIT-correct rather than just "mostly right."

Where Tradevo Data Fits

Tradevo Data exists for the middle case: you want SEC-sourced, point-in-time-correct annual fundamentals — Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares, up to 12 fiscal years — across 5,189 US companies (312,751 rows), without building the EDGAR pipeline yourself or paying for a full institutional-grade platform. The $49/mo plan includes the full bulk /v1/download, the whole-universe /v1/snapshot?as_of cross-section, and the /v1/fundamentals?ticker&as_of JSON endpoint — 5,000 requests/day and 2,500 distinct tickers/day; use /v1/snapshot or /v1/download for cross-sections — with a Stripe checkout that issues a key instantly. Cancel anytime. Docs are at /docs.

This is a budget tier of research-grade PIT data — not a claim to be the only cheap option, and not a promise about what it will do for your returns.

Try Before You Subscribe

The free sample — 40 companies, 3,280 rows, full methodology, no signup — is on GitHub: github.com/christianpichichero-max/pit-fundamentals. It's the same schema, same first_filed/original_value/restated logic, just smaller. If the filing-deadline mechanics above are new to you, the deeper walkthroughs are at /blog/lookahead-bias-fundamental-backtests and /blog/point-in-time-fundamentals-data.

If the schema fits your backtests, the full dataset is at tradevodata.com/?ref=blog. If you're still comparing PIT vendors, our comparison index lays out the options side by side.

Not investment advice; verify competitor pricing yourself.

We Shipped a 10x Error on General Mills. Here's the Bug, and the Check That Would Have Caught It.

Christian Pichichero — Tue, 04 Aug 2026 19:38:46 +0000

On 2026-08-03 our API was serving General Mills' FY2024 revenue as $2.038 billion. The real figure is $19.857 billion. We were wrong by an order of magnitude on an S&P 500 company, for weeks, and every automated check we had said the data was fine.

This is the post-mortem. It is worth reading if you build anything on SEC XBRL, because the root cause is not exotic — it is the most natural way to write the code, and it is wrong.

What the filing actually says

General Mills tags two different numbers in the same 10-K for the same period:

XBRL element	FY2024 value
`Revenues`	$2,037,800,000
`RevenueFromContractWithCustomerExcludingAssessedTax`	$19,857,000,000

Both come from SEC's own companyconcept API. Neither is a mistake by the filer. Revenues here is a component; the consolidated top line lives under the ASC-606 element.

We picked Revenues.

Why we picked the wrong one, and why it was defensible

Our tag resolution used a static priority list, with Revenues ranked first. That ordering was itself a fix. Earlier, we had ASC-606 contract revenue ranked above Revenues, and it produced this:

MetLife FY2024 — served at $2.2B against a true $71.0B
Capital One — 85% low
AvalonBay — 99.8% low, for eight consecutive years

For insurers, REITs and card issuers, contract revenue is a small slice and Revenues is the real total. So we promoted Revenues, verified MetLife came out right, and shipped.

That fix was correct for MetLife and catastrophically wrong for General Mills — because there is no single XBRL element that is the consolidated top line for every filer. Revenues is the total for an insurer and a minor component for a consumer-goods company. Any fixed ordering serves one and betrays the other.

We had traded one class of error for another, and we could not see it, because we validated the fix against the company that motivated it.

Why nothing caught it

This is the part worth generalising. We had four automated gates:

a claims check comparing published site copy to the database
a minimum-row-count guard against truncated builds
endpoint smoke tests
an invariant scan for internal consistency

Every one of them asks "is this data consistent with itself?" None asks "is this number correct?"

$2.038 billion is internally consistent. It is correctly dated, plausibly sized for a public company, sourced from a real XBRL element in a real filing, and it passes every range check. It looks exactly like money. There is no internal signal that separates it from the right answer.

We even had a flag firing. The row carried qa_status = FLAG:ambiguous_tag, which our engine sets when another element in the same filing reports materially more. The system detected the ambiguity and published the smaller number anyway. Detecting is not deciding.

The second bug, which was worse

While fixing the first, we found that our bank-revenue path had been silently broken for months.

Banks frequently tag no single total-revenue element, so we synthesise one: net interest income plus noninterest income, the standard definition. That code computed Fifth Third's FY2023 revenue correctly at $8.708B. Then it stamped the value with the wrong filing date — 2026-02-24 instead of 2024-02-27 — because of this:

nii = {p["end"]: p for p in annual_points_for_tag(...)}

A dict comprehension keeps the last entry per key. SEC reports the same period across many filings, so the last one is the most recent re-filing. The synthetic bank total therefore always looked like it was filed years late.

Our selection logic picks the earliest-filed candidate, on purpose — that is the point-in-time discipline. So the correct bank total always arrived "late" and lost to the fee-income tag it existed to replace. The fix computed the right answer and threw it away, every single time. Fifth Third kept publishing $0.577B against a true $8.708B.

One line, and it silently reversed the outcome of a fix everyone believed had shipped.

The check that would have caught both

The missing piece was not more tests. It was one test of a different kind: compare the data to something outside itself.

node scripts/verify-against-sec.mjs

For a sample of served values, it asks SEC's companyconcept API for every candidate revenue element the filer reported for that exact period, and asserts that what we serve is the consolidated total rather than a component of it. It deliberately does not reuse our tag-selection logic — otherwise it would reimplement the bug and agree with itself.

Run against the broken data, it printed:

WRONG GIS FY2024: serving $2.038B vs SEC $19.857B — 10.3% of the total
WRONG GIS FY2023: serving $1.957B vs SEC $20.094B —  9.7% of the total
WRONG PG  FY2014: serving $29.400B vs SEC $83.062B — 35.4% of the total

It now runs on every data refresh and fails the build. A gate that cannot catch its own motivating case is decoration, so we proved it fired before shipping it.

The actual fix

We stopped ranking elements and started comparing them. Every tag in our candidate list is intended to be a consolidated total — the gross-overstating ones are explicitly excluded — so when two candidates in the same filing disagree materially, the larger is the total and the smaller is a component of it. That rule gets MetLife and General Mills right simultaneously, which no fixed ordering can.

The regression test keeps them in the same file, deliberately, because they pull in opposite directions.

What this cost, and what changed

Wrong values reached the paid API and the free sample. P&G FY2014 shipped at $29.4B against a true $83.1B in the public CC0 file — the one our own pricing page tells prospects to verify against.

All of it is corrected now: General Mills at $19.857B, P&G at $83.062B, Fifth Third at $8.708B, M&T at $9.279B, MetLife still right at $70.986B. Roughly 320 values across all seven concepts have since been checked against SEC's API with zero mismatches.

Three things we would tell anyone building on XBRL:

There is no universal top-line element. Any static tag priority is wrong for some filer. Compare magnitudes within the filing instead of trusting an order.
Detecting an ambiguity is not resolving it. We flagged the row and published it anyway. If your system knows something is uncertain, decide what to do about it.
Self-consistency is not correctness. Every gate we had compared the data to itself. Wrong numbers pass those effortlessly, because wrong numbers are usually well-formed. Something in your pipeline has to compare against the outside world.

We would rather publish this than have you find it. The free sample is 40 large caps, 3,280 point-in-time rows, CC0, no signup — github.com/christianpichichero-max/pit-fundamentals — and the methodology is public specifically so it can be attacked.

Not investment advice.

As-Reported vs Restated Financial Data: Why the Difference Matters for Backtesting

Christian Pichichero — Wed, 29 Jul 2026 16:54:14 +0000

Every financial statement exists in at least two versions: the number a company first told the market, and whatever number ends up in today's database after amendments, reclassifications, and restatements. If you're building a fundamental backtest, confusing the two is one of the quieter ways to inflate a strategy's historical returns — quieter than survivorship bias, but just as real.

This article works through what "as-reported" and "restated" actually mean, why a backtest that uses the wrong one is training on information that didn't exist yet, and how a point-in-time (PIT) dataset like Tradevo Data represents both so you can choose deliberately instead of by accident.

As-reported: what the market actually saw

As-reported (also called original or first-filed) is the value disclosed in the filing that made it public — for us, a 10-K (or 10-K/A). It's stamped with a date: the moment that number entered the public record via SEC EDGAR. Before that date, no market participant could have known it. That's the entire premise of point-in-time data: every fact carries a timestamp for when it became knowable, not just what the fact eventually became.

Restated: what the number is today

Restated (or latest) is the current, revised figure after any subsequent 10-K/A amendments or comparative restatements in later filings. Companies restate for real reasons — accounting errors, standard changes, reclassifications, M&A-driven reallocations. The restated number is often more accurate as a historical record of what actually happened. It is not, however, what a trader or analyst could have known on the date the original filing hit the tape.

Why this becomes lookahead bias in a backtest

A backtest that joins today's restated fundamentals to historical prices is implicitly assuming the market had access to information it didn't have yet. If a company later restates revenue upward and your backtest uses the restated figure as of the original filing date, any strategy conditioned on that revenue print will look smarter in hindsight than it could have been in real time. The effect is usually small per company, but restatements aren't rare — our dataset flags 18,723 restatements across 312,751 point-in-time rows, which suggests this is a systematic feature of financial data, not an edge case you can ignore.

The fix is mechanical, not statistical: for any date you're backtesting against, use only the values that had a first_filed date on or before that date, and use the value as it was first reported — not as it later became.

A concrete example

Suppose a company files its original 10-K reporting revenue for fiscal year N. Some quarters later, it files a 10-K/A that revises that same fiscal year's revenue — the change exceeds the 0.5% same-tag threshold we use to flag a meaningful restatement (not just a rounding or presentation tweak).

In Tradevo Data's schema, that single revenue fact for fiscal year N produces:

first_filed: the date the original 10-K became public
original_value: the revenue as first reported — this is what you join against historical dates for a PIT-safe backtest
latest_value: the revenue as currently stated, after the 10-K/A
restated: true, because the revision exceeded the 0.5% same-tag threshold
qa_status: our internal check on whether the row parsed and reconciled cleanly

If your backtest logic is "as of date X, what did we know about this company's revenue," you filter to rows where first_filed <= X and read original_value. If your logic is "what actually happened to this company's revenue, full stop," you read latest_value. Same row, two different questions, two different answers — and picking the wrong one for the wrong question is exactly the bug PIT data exists to prevent.

As-reported vs restated at a glance

	As-reported (`original_value`)	Restated (`latest_value`)
Answers the question	What did the market know on this date?	What is the corrected historical fact?
Correct use	Backtesting, PIT research, signal generation	Fundamental analysis of "true" historical performance, post-mortems
Risk if misused	None if used correctly for its purpose	Lookahead bias if fed into a historical backtest
Changes over time	No — frozen at first filing	Yes — updated as amendments are filed
Where it lives in our schema	`original_value` + `first_filed`	`latest_value` + `restated` flag

When restated data is genuinely the better choice

This isn't a case for always preferring as-reported. If you're doing retrospective fundamental analysis — "how did this company's margins actually trend over a decade" — the restated figure is usually the more honest answer, since it reflects corrected accounting rather than a since-fixed error. Restated data is also the right call for training long-horizon valuation models where you're not simulating point-in-time decisions, or for auditing how much a company's numbers have moved since first disclosure. The mistake isn't using restated data; it's using it inside a backtest that pretends to be historical.

When to build it yourself — or use someone else's dataset

Building a PIT pipeline from raw EDGAR filings is entirely doable, and for some teams it's the right call: you get full control over parsing logic, tag mapping, and restatement detection thresholds, and you're not dependent on anyone's refresh schedule. The tradeoffs are real, though — reconciling XBRL tags across amendments, tracking every 10-K/A, and validating first-filed dates against actual EDGAR timestamps is unglamorous, ongoing work, and it's easy to introduce silent bugs (like accidentally picking up a restated value) that only surface when your backtest results look suspiciously good.

If you need quarterly data, non-US markets, or Parquet natively today, other providers are worth evaluating — Sharadar, Tiingo, and QuantConnect all offer credible fundamentals products; see their pricing pages directly, since we won't quote competitor prices here and terms change. Tradevo Data is annual-only (10-K/10-K/A), US-only, and CSV-first (Parquet is on the roadmap), so if your use case needs more than that today, one of those may be the better fit right now.

Where Tradevo Data fits

What we do offer: 5,189 US companies, 312,751 point-in-time rows across 7 core concepts, up to 12 years of history, with every value carrying first_filed, original_value, latest_value, and a restated flag so you never have to guess which one you're looking at. On our 40-company free sample, the gap between fiscal period end and first_filed averaged 43.4 days (max 61 days) on reliable-filing rows. Across the full universe the same gap is wider — mean 66 days, median 60, p90 90 on reliable-filing rows — because large caps are the fastest filers. The sample figure is the friendly end, not a property of the whole dataset.

The full methodology and 3,280 sample rows are free, no signup: github.com/christianpichichero-max/pit-fundamentals. If it fits your workflow, the full dataset and API are $49/mo at tradevodata.com — bulk download and whole-universe snapshots included, cancel anytime. For more on how lookahead bias creeps into backtests, see /blog/lookahead-bias-fundamental-backtests and /blog/point-in-time-fundamentals-data.

Not investment advice; verify competitor pricing yourself on their respective sites.

How to Detect Lookahead Bias in a Backtest: A Practical Checklist

Christian Pichichero — Wed, 08 Jul 2026 17:03:29 +0000

Lookahead bias in a fundamentals backtest almost never announces itself. It shows up as a backtest that looks unusually good, and then a live strategy that quietly stops working. The mechanism is boring: your join used a date the data wasn't actually public yet. This article is a checklist for finding that, not a pitch for a particular dataset — though we'll use our own free sample to show working code, because it's the one we can show you column-by-column without asking anything of you.

This is not investment advice. Nothing here promises a better-performing backtest — only a more honest one, with fewer joins that leak future information into the past.

Symptom 1: Your signal times earnings suspiciously well

If a fundamentals-driven signal enters positions right before earnings-driven price moves with better-than-random timing, check what date you used to decide the fundamental was "known." A common bug: joining on fiscal period end date (e.g., Q4 2019 = 2019-12-31) instead of the date the 10-K was actually filed and made public. Every company reports its fiscal year end weeks to months before the filing exists. If your backtest thinks Q4 data is available on the period end date, it's trading on the future.

Symptom 2: Live performance decays right after paper trading ends

This is the classic tell. A strategy backtests clean, goes live (or into a genuinely walk-forward paper test), and the edge shrinks or disappears. If the strategy relies on fundamentals and nothing else changed — no regime shift, no capacity issue — lookahead bias in the historical joins is the first thing to rule out, because live trading is the one environment where lookahead is structurally impossible.

Symptom 3: Performance is fragile to a few outlier dates

Run your equity curve breakdown by trade. If a disproportionate share of PnL comes from trades placed in a narrow window around known reporting seasons, and those specific trades have unusually strong hit rates, look at whether the fundamental value used in the join was restated later and your backtest is silently using the restated number instead of what was originally reported.

The Join-Date Audit

The fastest way to check: pull your actual join logic and ask, for every fundamental value, "what date did my code think this became true?" Then compare that to the date it was actually filed. Two dates get confused constantly:

Fiscal period end — when the reporting period closed (always in the past relative to filing)
First filed date — when the 10-K (or 10-K/A) hit EDGAR and became public

If your pipeline uses the former where it should use the latter, you have a lookahead bug baked into every single row, sized to the actual filing lag for that company and quarter.

A pandas check using first_filed

Our free PIT sample (40 companies, 3,280 rows, no signup) includes a first_filed column specifically so you can run this check yourself. Example:

import pandas as pd

df = pd.read_csv("sample.csv", parse_dates=["first_filed", "fiscal_period_end"])

def check_leakage(df, as_of_date, join_col="fiscal_period_end"):
    as_of = pd.Timestamp(as_of_date)
    naive_join = df[df[join_col] <= as_of]        # what a naive backtest would include
    correct_join = df[df["first_filed"] <= as_of]  # what was actually public by as_of
    leaked = naive_join[~naive_join.index.isin(correct_join.index)]
    return leaked

leaked_rows = check_leakage(df, "2020-03-31")
print(f"{len(leaked_rows)} of {len(df)} rows would be lookahead-leaked "
      f"if you joined on fiscal_period_end instead of first_filed")

If leaked_rows is non-empty for a realistic as_of date, your naive join is including fundamentals before they existed publicly. Swap the join key to first_filed (or whatever your data vendor's equivalent "became public" field is called) and rerun.

The Lag-Shift Test

A second, independent check that doesn't require inspecting your join code line by line: shift your as_of date backward by a fixed number of days across your entire backtest — say 30, 60, 90 days — and rerun. If performance is fairly stable under small shifts, that's a decent sign your logic isn't sitting right on a knife's edge of leaked information. If performance craters the moment you shift even slightly earlier, your original result was likely dependent on data being available earlier than it should have been. This is a blunt instrument, not proof, but it's cheap to run and catches a lot of accidental lookahead.

For deeper background on why this matters mechanically, see lookahead bias in fundamental backtests and our overview of point-in-time fundamentals.

Comparing Your Options for Fixing It

Approach	Effort	Coverage	Cost	Best for
Scrape EDGAR yourself, track filing dates	High	Whatever you build	Your time	Teams needing full control, custom concepts, or non-US data
Research-grade PIT vendors (e.g. Sharadar, Tiingo, QuantConnect)	Low	Broad, often quarterly + more concepts	See their pricing pages	Funds/teams needing quarterly data, longer history, or bulk delivery — this is genuinely where they win over us
Tradevo Data	Low	5,189 US companies, 7 concepts, annual only, up to 12 fiscal years	$49/mo	Individual quants who need PIT-safe annual US fundamentals cheaply, via API
Free PIT sample (GitHub)	Low	40 companies, 3,280 rows	Free	Prototyping the join logic and running the checks in this article before paying for anything

We're not the only affordable option, and we're not claiming to be — the vendors above are credible and some cover more ground (quarterly data, longer history, bulk delivery). See their pricing pages directly since we won't quote numbers we don't control.

When to Build It Yourself (or Use Someone Else)

Being honest about where Tradevo Data isn't the right tool — and where the vendors above genuinely win:

You need quarterly fundamentals. We're annual-only (10-K + 10-K/A). Quarterly PIT logic is a roadmap item, not shipped. A vendor with quarterly coverage wins here.
You need non-US equities. We're US-only, sourced from SEC EDGAR. A vendor with international coverage wins here.
You need more than 7 concepts, or line items beyond Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, and DilutedShares.
You need Parquet files specifically — bulk is included (a one-call gzipped-CSV download of the full dataset via /v1/download, plus a whole-universe /v1/snapshot), but the delivery format is CSV/JSON today; Parquet is on the roadmap.
You're already comfortable parsing EDGAR filings directly and tracking first_filed yourself — that's a legitimate, free path if you have the engineering time, and it's exactly what our free sample's methodology documents.

If none of those apply and you just want a point-in-time-safe first_filed/original_value pair for US annual fundamentals without building the EDGAR pipeline yourself, that's the actual use case we built for.

Try It Before You Pay for Anything

Start with the free sample — 40 companies, full methodology, no signup — and run the join-date audit and lag-shift test above on your own logic. If it holds up and you want the full 5,189-company, 312,751-row dataset with first_filed, original_value, latest_value, and restatement flags via API, it's $49/mo at Tradevo Data, instant key after checkout, cancel anytime, docs at /docs.

If you're actively comparing PIT data providers, our comparison index lays out where we fit and where we don't.

Not investment advice; verify competitor pricing yourself on their own pricing pages.