Most trading systems do not fail because of the model. They fail because every component interprets market data differently.
When a feature has one value in a backtest and another in live trading, the problem is not intelligence. It is architecture.
The Real OHLCV Problem
OHLCV stands for open, high, low, close, and volume. It looks simple, yet it drives research, execution, risk controls, and operational monitoring.
The common mistake is treating OHLCV as a CSV file or an API response. In production, it is an operational data asset that must be versioned, reproducible, and auditable.
If a feature changes meaning between research and production, trust collapses. Backtest performance stops being evidence.
A scalable trading system stabilizes feature definitions before it trains another model.
What Is an OHLCV Feature Pipeline?
An OHLCV feature pipeline transforms raw market data into variables used for trading decisions. It should produce the same result in backtests, paper trading, and live execution.
Raw Market Inputs
Inputs often include OHLCV bars, corporate actions, contract metadata, market state, and sometimes alternative data. Each input needs a known event time, ingestion time, and quality status.
A five-minute candle close is not usable until that candle has actually closed. Using it earlier creates look-ahead bias.
Normalization Layer
This layer standardizes time zones, symbols, intervals, duplicates, and incomplete bars. It is not glamorous work, but it prevents expensive hidden failures.
BTC/USDT on two exchanges is not necessarily the same operational instrument. Liquidity, reported volume, and candle construction can differ.
Feature Computation Layer
This layer converts raw inputs into derived features. Log returns, ATR, VWAP, rolling volatility, volume imbalance, and regime labels are common examples.
Every feature needs a contract: inputs, calculation logic, window length, permitted latency, version, and owner.
What Is a Feature Registry?
A feature registry is an operational catalog for defining and governing features. It is more than a list of names. It is the data contract of the trading system.
Each registered feature should state what it calculates, which source data it uses, when it becomes valid, and which version is approved for production.
Minimum Feature Metadata
- Unique name: for example,
realized_volatility_20_v2 - Calculation definition: formula, window, and aggregation method
- Source data: venue, dataset, timeframe, and price type
- Time validity: event time, availability time, and latency
- Version: to prevent silent changes in results
- Owner: the person or team accountable for quality
- Tests: data validity, sensible ranges, and time-consistency checks
Feature Registry vs. Feature Store
A feature store primarily focuses on persisting and serving features. A feature registry focuses on definition, lineage, and governance.
For a small system, both may live in one repository. At operational scale, separating the concepts reduces future debugging cost.
| Dimension | Feature Registry | Feature Store or Cache |
|---|---|---|
| Primary role | Definition, versioning, and lineage | Fast access to computed values |
| Core question | What exactly is this feature? | Where is the latest valid value? |
| Main risk | Silent logic changes | Stale or inconsistent data |
| Typical ownership | Research and platform engineering | Trading infrastructure and runtime systems |
A Better Architecture
Good architecture does not remove complexity. It moves complexity into controlled layers.
Layer One: Immutable Raw Data
Do not overwrite raw market data after ingestion. Store corrections as new versions or explicit correction records.
This consumes more storage. It becomes invaluable when a live result must be traced weeks later.
Layer Two: Canonical Bars
A canonical bar defines one standard representation of symbol, timeframe, time zone, and trading session. Every downstream feature should use this contract.
If one module uses UTC while another uses venue-local time, even strong models will produce inconsistent outputs.
Layer Three: Deterministic Feature Jobs
Feature computation should be deterministic. Given identical inputs, versions, and timestamps, it should produce identical outputs.
Avoid hidden dependencies on system clocks, future data, or opaque state. Those dependencies destroy reproducibility.
Layer Four: Registry-Controlled Publication
No new feature should enter live trading directly. It should be registered, tested, and assigned a release state first.
A practical workflow is draft, validated, shadow, production, and deprecated. That modest structure makes silent changes much harder.
Layer Five: Online Cache
The cache is not the source of truth. It is the fast path for decisions.
Live trading should read validated feature values at low latency while retaining a traceable path back to raw inputs and feature lineage.
Designing the Trading Cache
A cache is not only about speed. It controls latency, reduces repeated computation, and protects runtime capacity.
A poorly designed cache can also make stale decisions look current.
Use Complete Cache Keys
A cache key should include the symbol, venue, timeframe, feature version, and event timestamp. A feature name and symbol alone are not enough.
For example, BTCUSDT:binance:5m:atr_14_v2:2026-07-29T10:25:00Z has a clear operational meaning. BTCUSDT:atr does not.
TTL Is Not Enough
A time-to-live setting prevents stale accumulation. It does not prove that a cached value matches the latest completed market bar.
Trading features also need a freshness watermark. The runtime must know the latest event time processed by the pipeline.
Use Event-Driven Invalidation
When a candle is corrected or historical data is replayed, invalidate cache entries through events. Global cache clearing is easier, but becomes costly at scale.
The trade-off is clear: precise invalidation is harder to build, while broad invalidation creates more recomputation.
Practical Example: 20-Period Realized Volatility
Assume a momentum strategy uses 20-period realized volatility. A vague definition can distort the result before the strategy even trades.
- Specify the source: Binance BTC/USDT five-minute closing prices
- Allow only completed candles into the calculation
- Calculate log returns from consecutive closes
- Calculate the rolling standard deviation of 20 returns
- Register the feature as
realized_volatility_20_v1 - Store the latest candle event time and calculation time with the output
- Publish to the cache only when the required freshness condition holds
If annualization logic changes later, create a new feature version. Do not overwrite the old definition.
What Most Teams Get Wrong
Shared Code Without Shared Contracts
Using one repository for research and production can help. Without data contracts and version control, it simply creates one shared place for failure.
Shared code is not shared architecture.
Treating a DataFrame as a System Boundary
A DataFrame is an analysis tool, not an operational contract. When features exist only inside temporary DataFrames, lineage and versioning become unclear.
Every feature job should emit a defined schema and explicit metadata.
Ignoring Market Data Corrections
Market data changes. Incomplete candles, websocket reconnects, and differences between snapshots and trade streams are operational facts.
A system without a correction strategy eventually produces research and production discrepancies nobody can explain.
Recomputing Everything on Every Request
This can work for a prototype. In live systems, it raises latency and infrastructure cost for no good reason.
The cache should eliminate repeated work, not hide data truth.
Operational Trade-Offs
A registry-and-cache architecture has real cost. You need schemas, tests, metadata, and a controlled release path.
The alternative is rarely cheap: hidden discrepancies, unreliable backtests, and decisions that cannot be reconstructed.
| Choice | Benefit | Cost | Best fit |
|---|---|---|---|
| Compute inside the strategy | Fast initial delivery | Repeated logic and high error risk | Short-lived prototypes |
| Simple feature pipeline | Better reuse and testing | Requires data contracts | First production release |
| Independent registry and cache | Scale, governance, and auditability | More operational complexity | Multiple strategies or teams |
A Founder Decision Framework
Ask one question before adding another model: if a strange trade appears tomorrow, can we reconstruct exactly which data and feature version produced that decision?
If the answer is no, repair the data path before expanding the model layer.
If You Have One Strategy
Start with canonical OHLCV, a few versioned features, and a limited cache. The registry can initially be a version-controlled file with a strict schema.
If You Have Multiple Strategies or Markets
Promote the feature registry into a distinct service or module. Formalize ownership, validation, and deprecation.
If You Operate a Trading SaaS
Tenant isolation, rate limits, data lineage, and audit trails are no longer implementation details. They become part of the product.
Implementation Guidance
- Define a canonical OHLCV schema with symbol, venue, timeframe, event time, ingestion time, and data-quality fields
- Register every feature using a searchable, versioned name and metadata contract
- Add look-ahead bias and determinism tests for every feature
- Key cache entries by event time and feature version
- Check freshness watermarks at runtime
- Run new features in shadow mode before live publication
- Keep a reproducible path from raw data to the final trading decision
Key Takeaways
- OHLCV is not simple input data; it is the foundation of trading decisions
- A feature registry defines feature meaning, version, and lineage
- A cache improves speed but never replaces source-of-truth data
- Event time matters more than ingestion time for trading validity
- Never overwrite a feature definition; publish a new version
- If a decision cannot be reproduced, the system is not ready to scale
FAQ
What does OHLCV mean?
OHLCV is a market-data format containing the open, high, low, close, and volume for a defined time period.
What does a feature registry do in a trading system?
A feature registry records each feature's definition, version, source data, calculation logic, validity time, and owner, making outputs reproducible and auditable.
What is the difference between a feature registry and a cache?
The registry defines what a feature is and how it is produced. The cache stores the latest valid result for fast access during runtime.
Why must trading features be versioned?
Versioning prevents silent changes to calculation logic. It also supports result comparison, rollback, and reconstruction of historical decisions.
Do small trading systems need a feature registry?
Yes, but it does not need to be a large platform on day one. A strict schema and a version-controlled feature definition file are a strong starting point.
A trading model is only as trustworthy as the data system behind it.
Good structure does not sacrifice speed. It makes speed reliable.
Sources
Comments (0)
You need to log in to post a comment.
Login / Sign up