How to backfill FX rates without look-ahead bias
When you backtest a strategy that traded EUR/USD in March, you need the rate that was knowable in March — not a revised ECB series published months later. Here's the pattern.
Point-in-time data returns the value that was actually published as of a given timestamp, with no later revisions folded in. It is the difference between a backtest you can trust and one quietly contaminated by information the market did not yet have.
What "point-in-time" means
Most data providers serve you the current best estimate of a historical value. When a figure is revised — a GDP print restated, a settlement corrected — the old number silently disappears. Query last March today and you get March as it is understood now, not as it was understood in March.
A point-in-time store keeps every vintage. Ask for the value as_of=2026-03-14 and you receive exactly what a subscriber would have seen on that date, revisions excluded.
Why look-ahead bias ruins backtests
If your historical series contains values that were only knowable later, your strategy is implicitly trading on the future. Returns look spectacular in simulation and collapse in production. The bias is subtle precisely because the numbers are real — just not real yet.
How Console stamps every value
Every observation we store carries the timestamp it became public. Add an as_of parameter and the API replays the series as it stood on that date — no special endpoint, same envelope.
Naive vs point-in-time
“If you cannot reproduce the number you traded on, you do not have a backtest — you have a story.”
Putting it together
Point-in-time is the default on every Console series — fx, metals, and power alike. You do not opt in; you opt out by omitting as_of to get the latest. Either way, every value names the feed and timestamp it came from, so the number is auditable end to end.