Everyone who has run a research process knows about look-ahead bias in prices. Far fewer people apply the same suspicion to macro inputs, and macro inputs are where the problem is worse, because a price is a price forever and a money supply figure is an estimate that keeps being corrected for years afterward. A liquidity signal tested on today's version of history is being tested on a series that was not available to anyone at any point during the period being tested.
This matters specifically for anything built off the Global Liquidity Scorecard, whose named inputs are the aggregate central bank balance sheet, global M2 money supply, USD liquidity indicators and credit spreads across eight central banks. Two of those four families are revised routinely. If a signal derived from that composite has been validated against a downloaded history, the validation is not wrong so much as it is measuring a different question than the one you asked.
Two different look-aheads, only one of which is obvious
Separate them, because they need separate corrections and fixing one does nothing for the other.
The first is publication lag. A monthly series describing March does not exist in March. It appears weeks later. A backtest that stamps the March value at the end of March has let the strategy trade on information that had not been produced yet. This one is well understood and it is the easier of the two to fix.
The second is revision. The number published in late April for March is a first estimate. It gets revised. Then the seasonal adjustment factors are re-estimated on an annual cycle and the whole history is restated. Then benchmark revisions and definitional changes arrive on a longer cycle. The value sitting in your downloaded series today for a month five years ago is not the number anybody saw five years ago, and in many cases it is not the number anybody saw four years ago either.
Annual re-seasonalisation is the one that catches people, because it does not just correct recent observations. It restates the entire series. That means a downloaded macro history is not a record of what was known plus some errors near the end. It is a smooth, internally consistent object constructed with the benefit of everything learned since, and no participant ever saw it.
Which direction the bias runs
The instinct is that revisions are noise and should wash out. They do not, and the reason is structural rather than statistical.
Revision processes are designed to produce a better estimate, and better in this context largely means smoother and more internally coherent. Early estimates are noisy because they are built from incomplete source data. Later vintages incorporate more complete reporting and re-estimated adjustment factors. The net effect is that turning points look cleaner in the revised series than they did in the first prints.
Now consider what a liquidity signal usually does. It looks for turns. It tries to identify the moment an expansion becomes a contraction. Tested on revised data, it is looking for turns in a series where the turns have been tidied up after the fact. It will find them, it will find them earlier and more decisively than was possible in real time, and the resulting statistics will be better than anything achievable.
I am not going to attach a number to how much better, because I have not measured it on this composite and inventing one would be worse than saying nothing. What I will say with confidence is the direction, and that the direction is systematically favourable rather than random. A test that does not correct for this overstates. The only open question is by how much.
Rebuilding on release date vintages
The correct object is not a series. It is a triangle. Rows are the reference period being described. Columns are the vintage date on which that description was published. Each cell is what was believed about that reference period as of that vintage.
The procedure follows directly.
- For every decision date in the backtest, select the column of the triangle corresponding to the most recent vintage published on or before that date. Never a later one, and never the final column.
- Compute the composite, or your signal, from that column only. This is the part that requires the composite to be reconstructible from its inputs. If you cannot reconstruct it, you cannot vintage it, and that limitation should be stated in the research note rather than worked around.
- Stamp entries at the release timestamp, not at the end of the reference period. A signal that depends on a monthly figure released on the 25th cannot trade on the 1st.
- Where release timestamps are intraday, decide once whether you trade the same session or the next open, document the choice, and apply it uniformly. Same session fills on a release day are frequently unachievable in size and should be justified rather than assumed.
- Report both results side by side, the revised-data version and the vintage version. The gap between them is itself a finding, and it is the number a reviewer will care about most.
Archives of release date vintages exist for the major US series, and the archival counterpart to FRED maintained by the St. Louis Fed is the usual starting point for them. Coverage is much thinner outside the US, and for several of the eight central banks in this composite you may find that no usable vintage archive exists at all. That is a real constraint and the honest response is to restrict the tested universe, or to test the US portion properly and disclose that the remainder is uncorrected, rather than to quietly use revised data for the legs where vintages are inconvenient.
The composite itself has a vintage problem
One layer above the input data sits a subtler issue that applies to any vendor produced score, including this one.
A composite has a specification: which inputs, what weights, what normalisation, what scale. Specifications get improved. When they do, any historical series of the composite is typically recomputed under the new specification, which means the score you can download for a date three years ago is not the score the panel was displaying on that date. It is the current model's opinion about that date.
This is not a criticism of anyone. Nobody wants a discontinuous indicator. But it means a long history of a vendor composite is a backfilled object with the same in-sample flattery as a revised data series, layered on top of the revision problem in the inputs.
The only clean defence is a forward record. Capture the composite live on a fixed schedule with its recompute timestamp, store it, and never overwrite it. After a year you have something no download can give you, which is a genuine point in time series of the score as displayed. It is short, and a short honest record is a weaker basis for a decision than a long one. It is also the only history you have that nobody has been able to improve, and when a due diligence reviewer asks whether your macro overlay was validated on point in time data, it is the only answer that survives the follow up question.