Multi-Asset Simulation Architecture

A backtester that only ever traded one instrument type can get away with a lot of hardcoded assumptions: one trading calendar, one settlement convention, one way of computing a position's P&L. The moment a strategy trades across asset classes — say, an equity book hedged with index futures, or a cross-asset relative-value trade spanning bonds and FX — those hardcoded assumptions break, because equities, futures, FX, and options don't share a single set of mechanics. A multi-asset simulator has to be architected from the start to treat those differences as first-class, not bolted on later.

What differs across asset classes

Several things vary enough to break a single-asset-class simulator if left implicit: trading calendars and hours (a US equity and a EUR/USD pair don't share a session), contract multipliers and tick sizes (futures P&L scales by a contract multiplier that equities don't have), settlement and margin mechanics (futures are marked-to-market daily with variation margin; equities settle T+1 or T+2 in cash), and corporate actions that only apply to some asset classes (splits and dividends hit equities, not FX or futures). A simulator that computes P&L with one universal formula — price change times shares — will silently get futures P&L wrong by the contract multiplier, and will silently ignore that an FX position's "price" is itself a ratio of two currencies, not a single number.

The architectural fix: instrument abstraction

The standard solution is to define a common instrument interface — every tradable thing exposes methods like mark_to_market(), contract_value(), settlement_date(), and applicable_calendar() — and let each asset class implement those methods according to its own mechanics underneath. The simulation engine then never needs asset-specific logic itself; it just calls the interface and lets each instrument type answer correctly. This is the same pattern used in production trading systems, and skipping it in a backtester is exactly how "works for equities, silently wrong for futures" bugs get introduced.

Worked example: one strategy, two instruments, one P&L bug

A pairs strategy holds long 100 shares of an equity ETF and short 2 contracts of an equity index future as a hedge. The equity leg moves +$0.50, so P&L is $100 \times 0.50 = 50$, i.e. $50. The future's quoted price also moves, say, +0.25 index points, but the future has a contract multiplier of $50 per point, and the position is short 2 contracts, so P&L is $-2 \times 50 \times 0.25 = -25$, i.e. −$25. A simulator that naively applied "price change × quantity" to both legs with no multiplier awareness would compute the futures leg's P&L as $-2 \times 0.25 = -0.50$, i.e. only −$0.50 — a hundred-fold understatement of the hedge's actual effect, which would make the backtest believe the pair is far less hedged than it really is.

What this means in practice

Building or choosing a simulator for any multi-asset or cross-asset-hedged strategy means checking, concretely, whether contract multipliers, calendars, and settlement mechanics are handled per-instrument or assumed globally. A backtest that gets the hedge ratio's P&L wrong by a large factor because of a missing multiplier isn't a minor rounding issue — it can flip a strategy from appearing well-hedged to badly mis-hedged, or vice versa, purely as a simulator architecture defect rather than a strategy flaw.