What data is needed to assess pair correlation
Pair correlation (usually implemented as the correlation coefficient between two return series) compares how two assets move together over a chosen time window and sampling frequency. To assess it accurately and independently, you need reliable time-series data plus clear choices for how “returns” are built and how the statistics are computed.
Data inputs and what they mean
- Two aligned price series: You need historical prices for both instruments you want to compare (for example, two currency pairs). The key is that the timestamps match or can be resampled to a common grid.
- A pricing source with documented provenance: Use a source you can describe (exchange feed, broker feed, data vendor) and confirm it is the same for both series. Different feeds can disagree even when they refer to similar underlying markets.
- A return definition: Correlation depends on what you treat as the series. Common choices are log returns or percentage returns computed from consecutive prices. You must state which one you use.
- A sampling frequency: Correlation changes with time granularity (minute, hourly, daily). You need to specify the frequency and whether you use raw observations or aggregated bars.
- A rolling-window or full-sample rule: Decide whether you compute one correlation for the whole history or a rolling estimate. A rolling approach needs a window length and step.
Mechanics: how the checks fit together
To compute pair correlation, you typically:
- Convert each price series into a return series using the same formula and the same time grid.
- Handle missing values consistently (for example, remove periods where either series is missing, or resample—without mixing inconsistent rules).
- Compute the correlation statistic on the overlapping return observations.
To make the result verifiable, record the full “recipe”:
- exact time range (start/end dates)
- frequency (e.g., daily closes)
- return formula (log vs percentage)
- window length and whether it rolls
- missing-data rule and timezone handling
Evidence or example setup (assumptions you must state)
A minimal, self-checkable setup could be:
- Collect two price series from the same overall source category.
- Resample both to the same frequency (e.g., end-of-period prices on the same calendar convention).
- Compute log returns from t-1 to t for each series.
- Estimate correlation over a fixed window (for example, using a single window for the whole range you choose).
Assumptions matter: if one series is effectively delayed, rounded, or has different trading hours, the alignment may be off by a few periods. That can noticeably affect the computed correlation even when both series look similar on a chart.
Limitations and failure modes
- Non-stationarity (changing relationships): Correlation is not a permanent property. It can vary by market regime, volatility conditions, and structural changes.
- Sample dependence and overfitting: A correlation estimated on historical data may not persist. Different window lengths can produce different answers.
- Alignment and timezone errors: If timestamps are not converted consistently (or if one series uses different session cutoffs), the return pairs are mismatched.
- Sensitivity to preprocessing: Correlation can change with outlier handling, missing-data treatment, or using prices vs midpoints vs closes.
- Costs and execution are not captured: Correlation is a statistical relationship in data; it does not include transaction costs, spreads, slippage, or execution timing.
Verification and next question to ask
A practical way to verify your assessment is to run the same computation under controlled variations:
- repeat with a different window length and check whether the conclusion changes drastically
- repeat using an alternative but well-documented pricing field (e.g., if the source provides multiple fields) to see how robust the result is
- test out-of-sample by computing correlation on one period and comparing its stability in a later period
Next question to refine your evaluation: What exact return definition and timestamp alignment procedure are you using, and how would you reproduce the same dataset and calculation steps from your recorded recipe?