Architecture Design: Backtesting Engine with Historical Data Integration

[shial4]

Architecture Design: Backtesting Engine with Historical Data Integration

I wanted to start conversation and create initial idea how we can implement backtesting engine on top of historical data from IB.
This is initial draft. Comment, extend, edit, change, update, add or remove. Literally anything. Think of it as a design document. As it is always the best to scope out before implementing. :)

Cheers!

Overview

This document provides a detailed design for a Backtesting Engine capable of simulating market movements based on historical data fetched via IBKit. The engine will allow users to specify the start and end dates for the simulation, adjust playback speed, and configure market data granularity, such as bar intervals or tick data.

The below setup ensures that the DataManager, MarketSimulator, handle data asynchronously, reacting to the data availability in real-time or as fast as the simulation parameters allow. This integration pattern is crucial for ensuring the backtesting engine can handle the data dynamics similar to live trading scenarios, making for a more robust and realistic testing environment.

Key Features

1. Historical Data Fetching: Utilize IBKit to retrieve historical market data.
2. Simulation Control: Users can set start and end dates, playback speed, and data resolution.
3. Market Simulation: Simulate market conditions from historical data to evaluate trading strategies.
4. User Configurability: Users can configure the backtest with flexible parameters.

Components

DataManager
Responsible for fetching and storing historical market data from IBKit.
Responsibilities: Fetches historical data based on the BacktestConfig.
Methods: fetchHistoricalData(config): Retrieves data from IBKit based on specified dates and resolution.

BacktestConfig
Stores user-defined settings such as start/end dates, playback speed, and data resolution.
Attributes:
startDate: When the backtest should start.
endDate: Optional end date; defaults to the current date if not specified.
playbackSpeed: Multiplier for the speed at which the backtest runs (1x, 2x, etc.).
resolution: Granularity of the data (e.g., tick, 1-minute bars, daily bars).

MarketSimulator
Simulates the market by replaying historical data at a user-defined speed and interval.
Methods:
simulateMarket(data): Simulates market conditions by replaying data at the speed and resolution defined in BacktestConfig.

+-------------------------------------+
|         DataManager                 |
|-------------------------------------|
| + fetchHistoricalData(config)       |
+-------------------------------------+

+-------------------------------------+
|         BacktestConfig              |
|-------------------------------------|
| + startDate: Date                   |
| + endDate: Date?                    |
| + playbackSpeed: Double             |
| + resolution: DataResolution        |
+-------------------------------------+

+-------------------------------------+
|         MarketSimulator             |
|-------------------------------------|
| + simulateMarket(data)              |
+-------------------------------------+

BacktestConfig.swift

// BacktestConfig.swift
struct BacktestConfig {
    var startDate: Date
    var endDate: Date?
    var playbackSpeed: Double
    var resolution: DataResolution
}

DataManager.swift

import Combine
import Foundation

class DataManager {
    var dataPublisher: AnyPublisher<[MarketData], Never> {
        fetchHistoricalData(config).eraseToAnyPublisher()
    }

    private func fetchHistoricalData(_ config: BacktestConfig) -> AnyPublisher<[MarketData], Never> {
        // Simulated data fetching from IBKit
        Just([MarketData]()) // Example, replace with actual IBKit call
            .delay(for: .seconds(1), scheduler: RunLoop.main)
            .eraseToAnyPublisher()
    }
}

MarketSimulator.swift

import Combine
import Foundation

class MarketSimulator {
    private var cancellables: Set<AnyCancellable> = []

    func simulateMarket(dataPublisher: AnyPublisher<[MarketData], Never>) -> AnyPublisher<SimulatedData, Never> {
        dataPublisher
            .flatMap { marketData -> AnyPublisher<SimulatedData, Never> in
                // Process each market data to simulate market conditions
                Just(SimulatedData(data: marketData)) // Example transformation
                    .delay(for: .milliseconds(200), scheduler: RunLoop.main)
                    .eraseToAnyPublisher()
            }
            .eraseToAnyPublisher()
    }
}

Moreover, we can provide component that will help facilitate user their own strategies. But not necessary as every consumer of SDK should be able to do it on their own. Maybe just an example in playground

StrategyExecutor.swift

import Combine
import Foundation

class StrategyExecutor {
    private var cancellables: Set<AnyCancellable> = []

    func executeStrategy(dataPublisher: AnyPublisher<SimulatedData, Never>) -> AnyPublisher<[Trade], Never> {
        dataPublisher
            .map { simulatedData -> [Trade] in
                // Execute strategy logic based on simulated data
                [Trade()] // Example transformation
            }
            .eraseToAnyPublisher()
    }
}

[stensoosaar]

A long time has passed since this discussion started, but the idea has stuck with me ever since. So let me draft a few thoughts:

Obtaining high-resolution market data for a large number of instruments is a known bottleneck, which highlights the need for a local cache—especially for storing historical data. This will significantly improve performance and reduce dependency on IB's rate-limited historic data API.

Additionally, while IB provides portfolio accounting for paper and live trading, backtesting portfolio accounting needs to be simulated.

---

1. Store Module

Purpose: Manages entities, handles local cache, and synchronizes data between IB, a local master database, and a session-level cache.

Key Components:

• Entity Model: Defines contracts, accounts, positions, and quote summary. Some things. to address:
• Simulated Account and Broker to handle portfolio accounting, commissions and user defined order filling strategy for backtesting purposes
• Data Syncing: Ensures updates between local and external sources like IB. In case of larger trading universe, the question remains, where to draw the line between strategy feeding local cache and securities master database. Probably protocol based datasource with default implementation, where user can override methods to request data from local masterdata instead of IB?
• Ingestion Layer:
  • Live Data: Handles data subscriptions for most
  • Background Updates: Fetches incremental updates for the remaining universe asynchronously to keep the cache fresh.
    IB allows 100 simultaneous subscriptions, but users can purchase booster packs to increase the limit). (in case user has a local masterdata, these results should be allowed to cached as files for later usage of updating masterdata?)

---

2. Session Module

Purpose: Facilitates running or testing strategies in both live and simulated environments.

Key Components:

• Data Subscription: Interfaces with the store module to provide on-demand data streams or snapshots for the current trading session. It supports both live and background data updates by:
  • Allowing users to define a watchlist to narrow live data selections. Watchlists can be:
    • Static: Manually selected instruments.
    • Dynamic: Interval-triggered queries against the store, resulting in new contract selection.
  • Reserving a small number of subscriptions for background data fetches (depending on session configuration)
• State Generation: Creates a state object for each instrument in the trading universe to maintain context, such as historical prices, indicators, and other relevant metrics.
• Signal Generation: Uses state data to produce actionable trading signals based on predefined logic or ML models.
• Portfolio & Risk Management:
  • Converts signals into portfolio-level allocations.
  • Evaluates pending and outstanding positions with user provided risk metrics (eg stop losses, max drawdowns etc)
• Order Execution:
  • Managed delta between model allocations and user portfolio positions and generating orders
  • Handles execution logic, eg order splitting, routing strategies to optimize fills.
  • Tracks the lifecycle of orders (submitted, filled, partially filled, rejected, etc.

---

3. UI Module

Purpose: Provides analytics and monitoring capabilities for live and simulated trading sessions.

Key Features:

• Session Analytics: Visualize signal generation, portfolio metrics, and risk exposure in real-time.
• Remote Monitoring: Allows sessions to run on a server while offering access from other devices (e.g., desktop, mobile).
• Separation of Execution and Monitoring: Enables running the strategy on one machine while monitoring it from another.
• Kill Switch: Ensures manual override capability for halting live trading or backtesting processes in emergencies.

---

[shial4]

This grew into something more than just back testing engine. Feels like this is a draft for whole trading infrastructure

[stensoosaar]

Live trading and backtesting engine should be as similar as possible to ensure that your strategy will always behave in a similar way. Sometimes small additional effort ensures much less work in future...