Real Tick Data

Arconomy backtests your strategies against real tick-level market data — the actual sequence of every price change as it happened in the market. This eliminates the guesswork inherent in bar-based backtesting and produces results that more closely reflect real-world trading conditions.

What Is Tick Data?

Tick data is the most granular form of market data available. Each tick represents a single price update — a change in the bid price, ask price, or last traded price for an instrument. Unlike OHLC bars, which compress an entire period's price action into four values (Open, High, Low, Close), tick data preserves the exact chronological sequence of every price movement.

A single one-minute OHLC bar might represent hundreds or thousands of individual ticks. When you backtest on bar data, you lose the information about what happened between those four price points. With tick data, every price update is available to the engine.

What a Tick Looks Like

Each tick in Arconomy's data store contains the following fields:

{
  "timestamp": "2025-03-15T14:30:00.123Z",
  "symbol": "EURUSD",
  "bid": 1.08423,
  "ask": 1.08425,
  "bid_volume": 1500000,
  "ask_volume": 2000000
}

The timestamp is recorded to the millisecond, providing precise ordering of price events. Bid and ask prices are stored separately, allowing the engine to calculate the exact spread at the moment of each simulated fill.

Where the Data Comes From

Arconomy sources its tick data from institutional-grade data providers that aggregate price feeds from multiple liquidity providers. The data goes through a multi-stage quality pipeline before it reaches the backtesting engine:

1. Ingestion — Raw tick data is collected from liquidity provider feeds in real time and stored in Arconomy's time-series database.
2. Deduplication — Duplicate ticks (same timestamp, same price) are removed to prevent artificial inflation of tick counts.
3. Outlier filtering — Ticks that deviate significantly from the surrounding price context are flagged and reviewed. Erroneous spikes caused by data feed glitches are removed.
4. Gap detection — Periods where no ticks were received (outside of normal market closures) are identified and documented so you can account for them in your analysis.
5. Storage — Cleaned tick data is compressed and indexed for fast retrieval during backtesting.

How Tick Data Improves Accuracy

Using tick data for backtesting produces more realistic results in several important ways:

Accurate Fill Simulation

When the engine simulates an order fill, it uses the exact bid and ask prices at the moment the order would have been triggered. This means the spread applied to each trade reflects the actual market conditions at that point in time, rather than an average or assumed value.

Precise Stop and Limit Execution

Stop-loss and take-profit orders are triggered based on the actual sequence of price movements. With bar data, a stop and a limit within the same bar create an ambiguity — which one was hit first? Tick data resolves this definitively because the exact order of price changes is known.

Realistic Entry Timing

Strategies that depend on precise entry timing — such as breakout strategies or mean-reversion entries — benefit significantly from tick data. The engine can determine the exact moment a price level was breached and simulate the fill accordingly, rather than assuming the fill occurred at a bar's open or close.

Spread Variability

In live markets, spreads widen during periods of low liquidity or high volatility. Tick data captures this variability because each tick records the actual bid and ask prices. Strategies that are sensitive to spread costs will produce more accurate results when backtested on tick data.

Available Coverage

Arconomy's tick data coverage spans a growing range of instruments and historical periods. The following table summarises current availability:

Asset Class	Instruments	History Available
Forex Majors	EUR/USD, GBP/USD, USD/JPY, AUD/USD, USD/CHF, USD/CAD, NZD/USD	2015 onwards
Forex Crosses	EUR/GBP, EUR/JPY, GBP/JPY, AUD/JPY, and 20+ more	2017 onwards
Indices	US30, US500, NAS100, GER40, UK100, AUS200	2018 onwards
Commodities	XAUUSD, XAGUSD, USOIL, UKOIL	2018 onwards
Crypto	BTC/USD, ETH/USD, and selected majors	2020 onwards

Data Source Frequency Options

When configuring a backtest, you can choose the data source frequency that best suits your strategy and performance requirements:

• Every tick — The engine processes every single tick in the dataset. This provides maximum accuracy but takes the longest to run. Best for scalping strategies and short-timeframe entries.
• Every nth tick — The engine samples every nth tick (e.g., every 5th or 10th tick). This reduces processing time while still capturing intra-bar price dynamics. Suitable for strategies operating on 5-minute to 1-hour timeframes.
• 1-minute OHLC — The engine constructs one-minute bars from the tick data and processes each bar as a single unit. Faster than tick-level processing, and sufficient for strategies that operate on 15-minute or longer timeframes.
• Custom bar period — You can specify any bar period (5-minute, 15-minute, 1-hour, 4-hour, daily) for even faster processing. The engine constructs bars from the underlying tick data, so the OHLC values are still derived from real prices.

Regardless of which frequency you choose, the underlying data is always real tick data. Even when you select a bar-based frequency, the bars are constructed from actual ticks rather than pre-aggregated OHLC values from a third party.

Tick Data and Backtest Performance

Processing every tick in a multi-year dataset can be computationally intensive. A single year of EUR/USD tick data can contain over 100 million individual ticks. Here are some guidelines for managing backtest performance:

• Start with a shorter date range to validate your strategy logic, then expand to the full period once you are satisfied with the results.
• Use a lower frequency during the iterative development phase, then switch to every-tick mode for your final validation run.
• Focus on the instruments you intend to trade rather than running broad multi-instrument backtests during initial development.

Backtest processing time also depends on your plan tier. Higher-tier plans have access to more compute resources, resulting in faster execution times for tick-level backtests.