The Multi-Currency Cash Ledger in Simulation

A single-currency backtest can get away with one running number: cash. A backtest trading across multiple markets — a US equity book alongside a European bond book, say — needs a cash ledger per currency, because a position and its cash proceeds don't automatically live in the same currency as the strategy's reporting currency. Selling a EUR-denominated bond produces EUR cash, not USD cash, and that EUR balance sits there earning or losing value against USD every day the position is held before it's converted or hedged. A simulator that quietly nets everything into one dollar number is silently converting at some assumed rate, and that assumption is itself a source of unrealistic P&L.

Why single-currency cash accounting breaks

Three effects compound if currency isn't tracked separately: unconverted balances accrue translation gains or losses purely from FX moves, independent of any trading decision; converting cash between currencies incurs its own bid-ask spread cost, which a simulator has to charge explicitly or it's granting free conversion; and holding foreign cash (or being short it) accrues interest at that currency's own rate, not the reporting currency's rate, which matters over any holding period longer than a day or two. A simulator that ignores all three effectively assumes frictionless, interest-free currency conversion happening automatically and invisibly — a assumption no real trading desk gets to make.

What a correct implementation tracks

Per currency: a running cash balance, the day's spot rate to the reporting currency (for mark-to-market translation only, not an actual conversion), an explicit conversion event with its own bid-ask cost whenever cash is actually moved between currencies, and an interest accrual on each balance at that currency's own short rate. The strategy's total P&L in the reporting currency is then the sum of each currency ledger's local P&L, translated at each day's spot rate, plus the running total of realized FX gains or losses from actual conversions — not a single blended number computed once at the end.

Worked example: an unhedged EUR bond position

A strategy buys a EUR 1,000,000 bond. At entry, EUR/USD = 1.10, so the position is worth $1,100,000. Over the holding period the bond's local price is flat — zero bond P&L in EUR terms — but EUR/USD moves to 1.08. Translated to USD, the position is now worth $1,080,000, a $20,000 loss purely from currency translation, with the bond's own performance contributing nothing. A simulator that only tracks a single USD cash number, converting the initial purchase to USD once and never revisiting the rate, would miss this $20,000 entirely — it would report the strategy as flat, when in reporting-currency terms it lost money. Only a ledger that re-marks the EUR balance to the current spot rate each day captures this correctly.

What this means in practice

Any backtest touching more than one currency needs to answer, explicitly, whether it's hedging currency exposure or leaving it open — and either way, the P&L attribution needs to separate local-market return from currency translation return so a strategy's real skill isn't confused with an FX bet nobody intended to take. Skipping a real multi-currency ledger is one of the more common ways backtests overstate genuinely uncorrelated-looking returns that are actually just riding FX volatility.