4
$\begingroup$

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

Improve this question
$\endgroup$
8
  • $\begingroup$ How are you storing the historical ticks? It it were just an array in memory, then running a calculation on 100 million elements should be really fast. $\endgroup$
    – chrisaycock
    Commented Jul 19, 2013 at 16:35
  • $\begingroup$ This question appears to be off-topic because it is about software development, which belongs to another site in the Stack Exchange network. $\endgroup$
    – madilyn
    Commented Jul 19, 2013 at 22:14
  • $\begingroup$ @chrisaycock, I store tick data in binary flat files but wrote a very versatile query engine to access tick data by start and end time stamp extremely quickly regardless of file size. But the issue I stated in my question is not so much about how the historical data is store but rather whether or not to have to update fx conversion factors as frequently as with each incoming data point. When I load batches of tick data into the engine, it loads batches of the same time snap shots across whatever assets the engine is subscribed to. I could do the same with the fx pairs. $\endgroup$
    – Matt Wolf
    Commented Jul 20, 2013 at 1:12
  • 1
    $\begingroup$ @kristine, I see your concern but this is closely related to currency fluctuations and their impact on computations such as pnl, capital utilization, notional exposure,... and hence I decided to pose the question here rather than in a forum of users without much expertise on the finance/trading side. Care to add your take to this problem? I am curious to learn how you would handle it. Thanks $\endgroup$
    – Matt Wolf
    Commented Jul 20, 2013 at 1:16
  • 1
    $\begingroup$ Oh, I see what you're saying now. Yeah, we cheat as well and just update the conversion rate once a day during research. Sorry I can't offer anything more sophisticated than that. $\endgroup$
    – chrisaycock
    Commented Jul 20, 2013 at 1:52

3 Answers 3

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for the comments. I would be more careful if I had to deal with inaccurate pricing data of the instrument itself or estimates thereof (I do take exact pricing into account, so no issue there). However, this question only deals with currency conversions to trade/profile non base currency denominated assets. So, after thinking of it I am pretty sure your advice is sufficient, thanks. $\endgroup$
    – Matt Wolf
    Commented Jul 26, 2013 at 12:10
2
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks for your input. I also update currency conversions in live trading once a day thus I think I will run the strategy profiling on historical tick data on daily fx rate conversion updates as well. Technology wise it is not hard to implement tick based updates, in fact that would be the easiest solution to implement. The issue is with performance degradation in terms of tick throughput/second. Any rate update on 10-20 cross currencies would cost several tens-hundreds of microseconds/tick which explodes when running hundreds of millions of data points. $\endgroup$
    – Matt Wolf
    Commented Jul 26, 2013 at 4:51
  • $\begingroup$ @MattWolf Assuming that you are going to be running this thing over and over on the same data as some part of research/optimization, I would definitely take your full fx tick database and pull out a smaller number of ticks. One per second, one per minute, one per day, whatever. Store that in a new database, and only read that thin database when running your analysis. I agree that having every tick in your fx pairs is a performance problem. $\endgroup$
    – RaveTheTadpole
    Commented Jul 29, 2013 at 21:06
  • $\begingroup$ yes that is how I have done it in the end. Run-time wise it would probably have been the cleanest way because I could have read such time series just in an identical way as the other assets' time series. However, in order to realize a bit more of some sort of "separation of concerns" I stored all dollar crosses (assuming USD is base currency) in a separate in-memory database. (very small footprint as I only use 1 update per day). $\endgroup$
    – Matt Wolf
    Commented Jul 30, 2013 at 0:27
0
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for your idea and suggestion, it is much appreciated. However, I was purely talking in regards to historical testing and my point was that I try to avoid having to check all fx conversion factors to a certain base currency because it would unnecessarily slow down the profiling process. I think what chrisaycock suggested comes closest to what I will implement because it only "cheats" on unrealized pnl until the conversion rate is updated again a day later or when the pnl is realized, whichever comes first. $\endgroup$
    – Matt Wolf
    Commented Jul 24, 2013 at 12:58
  • $\begingroup$ For order sizing purposes even a variation of 5% or so has an almost immaterial effect (for example, it makes almost no difference whether I trade 1,000,000 EUR notional based on an outdated conversion factor or 1,050,000 EUR, that would have been correct because the current conversion factor changed by 5% since the update in the system). $\endgroup$
    – Matt Wolf
    Commented Jul 24, 2013 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.