Currency Conversion Choices for Portfolio Backtests

# How to most optimally perform currency conversions when backtesting on portfolio level?


# How to most optimally perform currency conversions when backtesting on portfolio level?












I am currently expanding my own strategy profiling and testing platform which partly consists of a portfolio backtesting module. The backtest engine processes tick based data (quotes for currencies, order book changes and trades for other asset classes) and I am currently looking to enhance the risk management and portfolio capabilities. As I test portfolios of concurrent assets of different base currencies I need to implement a currency conversion algorithm for margin calculation purpose, base currency pnl, and capital utilization purposes.

There is no issue with my EMS and OMS in real time as each subscribed asset will pass its base currency into a scheduler which frequently updates those fx pairs that aid in converting the asset base currency to overall account base currency. However, as I deal with many hundreds of millions of ticks in backtests I cannot afford to update such fx pairs on each tick, at least it would be computationally prohibitively expensive. obviously we are talking historical data but I have all historical tick based data for any and all currencies pairs.

Can you offer solutions or ideas how to handle such issue? One idea is to update the batch of conversion fx pairs once per day (just one tick data point per day). Fx rates do not fluctuate too much on any given day to make a too significant impact on order sizing, margin calculations, and notional exposure. But any alternative views or recommendations are highly welcomed.

Thanks

## Answer by chrisaycock (score 2, accepted)

https://quant.stackexchange.com/a/8573

From a practical standpoint, the conversion rate can be kept constant during the day. It won't be precise, but it'll be fast. Stat arb backtesters have plenty of precedent where the entry price is the day's close plus a slippage factor. So if your goal is adversarial research (where there question is "would this strategy work?"), then you could add a negative fudge factor to the conversion rate that always makes your results look slightly worse.

## Answer by RaveTheTadpole (score 2)

https://quant.stackexchange.com/a/8568

There are two factors here, which might or might not be conflicting.

1) You want to mimic what will happen in production. If your production system sweeps currencies once a day, then backtest that way. If your clearing broker only calculates margin at the end of the day, then do the same in backtests. If you will only resize your portfolio once a month, then do it that way in backtests. Anything else will add to the discrepancy between backtesting and actual performance.

2) You want to match the time intervals that you will use to evaluate the backtest's performance. If you will be calculating performance on daily outcomes, you need/want to convert currencies once a day for pnl purposes. If you are going to be looking at minute-by-minute portfolio results when calculating Sharpe,etc then you'll have to be converting currencies that often just so that you have a common currency for your calculation.

On the technology side, I don't see why it would be hard to update the currency prices at the increments that the two factors above suggest. If the volume of currency ticks is slowing down the backtest, you could preprocess the currency data to extract the last tick before each desired time increment. So if it's once a day, you only save one tick per pair. If you don't know in advance what times you want, you could at least make a smaller database that had at most one tick per second per pair.

## Answer by Yugmorf (score 0)

https://quant.stackexchange.com/a/8559

If you use the same time each day then on days when the currency market moves a lot, your risk measurement error will be larger than on other days. Why not monitor the intraday FX movements and update your risk calculations whenever a certain divergence is observed. The result will be more frequent updating in volatile periods and less frequent updating at other periods, with the additional benefit of being able to control the size of your error tolerance.