Cross-Asset Market Data

The problem

The project turns heterogeneous daily market CSVs into a shared SQLite schema and builds return, trend, and volatility features for each asset.

How can heterogeneous market histories be cleaned, stored, and made comparable before testing cross-asset predictive signals?

Digital assets trade continuously while equity indices use market-hours calendars, making a consistent cross-asset dataset a non-trivial preparation problem.

How it works

1. 01

   Daily market CSVs

2. 02

   Column / date normalization

3. 03

   asset_prices SQLite table

4. 04

   Per-asset feature builder

5. 05

   asset_features + inspection queries

From input to output

1. 01Normalize raw columns and date formats across daily asset histories.
2. 02Load cleaned series into SQLite tables for asset prices and engineered features.
3. 03Generate one-day returns, log returns, moving averages, and seven-day volatility for each asset.
4. 04Use the structured dataset as a documented foundation for cross-asset modeling rather than claiming a final trading signal.

Data sources

• Local five-year CSV histories for ETH, SOL, S&P 500, Nasdaq, crude oil, and gold
• Source report documenting Yahoo Finance historical-data collection
• SQLite market-data database

Technical approach

• Schema normalization
• Date and numeric cleaning
• SQLite persistence
• Return, moving-average, and volatility feature engineering

What you can inspect

• The pipeline creates a common daily schema across assets with different source column conventions.
• Feature generation is reproducible and separated from raw-data loading.

The strongest deliverable is a reusable cross-asset research foundation; prediction performance is not asserted without a documented final model evaluation.

Where this is useful

• A shared, auditable data layer makes subsequent correlation, lag, and forecasting work more reliable.
• Normalization is especially important when combining 24/7 crypto series with market-hours assets.

Checks & engineering decisions

Verification evidence

• check_db.py groups rows by asset and frequency and prints samples from prices and features.
• These inspection checks establish dataset visibility, not forecast accuracy or full data-quality coverage.

Key decisions

• Separate ingestion from feature construction.
• Store price and feature tables separately for repeatable analysis.
• Trading-calendar alignment remains a downstream modeling concern.

df["return_1d"] = df["close"].pct_change()
df["log_return"] = np.log(df["close"] / df["close"].shift(1))
df["ma_5"] = df["close"].rolling(5).mean()
df["ma_10"] = df["close"].rolling(10).mean()
df["volatility_7d"] = df["return_1d"].rolling(7).std()

Role & status

Supporting project material.

Limitations

• A common schema does not by itself establish predictive power.
• Different trading calendars and missing values require careful alignment in downstream models.
• No public live demo is claimed.

Explore the evidence

The showcase is based on local scripts, CSV inventory, SQLite schema, and report documentation; raw market data is not published.