Can You Use Monthly Supply-Chain Data in a Daily Trading Model?
September 14, 2026
Altsets
Research by Altsets Research
Yes, but treat monthly relationships as slowly changing state variables rather than new daily observations, then combine them with genuinely fresh returns, volatility, news, or event data.
Data used:Altsets Supply Chain Intelligence: 90k+ entities, 400k+ relationships, 20+ years of history.
Key findings
- The supplied ASML-Micron relationship provides a slow-moving economic state that can condition daily market information without being treated as newly observed on every trading day.
- Mixed-frequency methods exist specifically because economic and market variables arrive at different sampling frequencies, and a valid backtest should preserve the actual update schedule of the relationship feature.
Yes, but a monthly supply-chain snapshot should be treated as a slowly changing state variable, not as a new independent observation every trading day. A daily trading model can combine the latest observable customer and supplier relationships with fast-moving returns, volatility, news, and event data, but the backtest has to preserve the actual update schedule of the graph.
Monthly relationships can remain valid between updates
The supplied Altsets data shows an economically large ASML-Micron relationship, including a 3B USD relationship size and 11.91% of Micron's cost base in the displayed view. If that relationship remains unchanged through a month, a daily model can reasonably use the latest observable state on every day during that month. The mistake is not forward-filling by itself. The mistake is pretending the feature became newly observed each day or treating twenty repeated values as twenty independent relationship observations.
A clean implementation should retain the feature timestamp and its age. The model can know that the latest relationship state is still 11.91% while separately knowing that the observation is one, five, or fifteen trading days old. That gives the researcher a way to test whether the usefulness of a relationship state decays as the snapshot ages instead of making freshness invisible inside a forward-filled column.
Slow network state can interact with fast market information
Mixed Data Sampling methods exist specifically because financial and economic variables are often observed at different frequencies. The broader lesson applies even if the final model is a tree ensemble or neural network rather than a formal MIDAS regression. Aggregating every daily variable to monthly frequency can throw away useful timing, while expanding every monthly variable to daily frequency without respecting its observation process can create pseudo replication.
A natural supply-chain design separates state variables from event variables. The customer and supplier network is the slower state. Daily customer returns, earnings surprises, analyst revisions, options changes, and news are the faster inputs. The daily model then asks whether today's fast information has a different implication for companies with different pre-existing relationships. The ASML-Micron relationship does not need to change because ASML moved today. The relationship tells the model why today's ASML information may matter to Micron.
The update schedule belongs inside the backtest
A historical model can accidentally make monthly data more responsive than the live system will be. If a month-end snapshot is attached to dates earlier in that month, the backtest receives relationship information before it would have been available. The feature should become usable only after its eligible historical observation time and remain fixed until the next eligible update.
Derived graph features need the same treatment. Centrality, peer groups, dependency clusters, and covariance priors should not be recomputed every day from a retrospectively perfect graph if the production system will refresh them monthly. The backtest should reproduce the intended feature-generation cadence. Otherwise the researcher can end up testing a high-frequency graph that the product never actually had.
Repeated state does not create repeated evidence
A daily panel can become enormous after monthly features are forward-filled. That row count can give a false sense of statistical power because the relationship state has not changed. The daily market outcome is new, but the network observation is not. Standard errors, train-test design, and feature-importance interpretation should recognize that repeated relationship values are clustered through time and often through the graph as well.
This is particularly important when the model is asked whether the relationship itself predicts returns. A stronger formulation can ask whether a fixed relationship state changes the response to new daily information. That gives the daily rows a clearer economic meaning because the variation comes from genuinely new market information interacting with a known dependency.
The conclusion is to model slow structure and fast information separately
Yes, monthly supply-chain data can belong in a daily strategy. Treat the graph as a slowly updating economic state, preserve the age and observation date of each snapshot, and let higher-frequency market or event variables provide the daily variation. That avoids both common errors: throwing away daily information by aggregating everything to monthly frequency and manufacturing fake evidence by pretending the same monthly relationship was rediscovered every trading day.
The market-knowledge timing guide explains why a historical feature should not become available before the market could have observed it. The effective-sample-size guide explains why repeated connected observations can overstate the amount of independent evidence.
For relationship definitions and evidence limits, read the Altsets methodology.