Hi Gang,

A general question; does any one have any thoughts on how to consider historical futures margins requirements in a backtest ? Obviously the margin on CL is not the same as it was X weeks/months/years ago.

Here are some thoughts:

- If I run a backtest on a portfolio, the symbol info manager can only take in 1 fixed $ value.

Question: Can the symbol info manager be populated with a variable like a dollarised 10 day ATR? (using the assuming that their is a correlation between margin requirements and ATR) - so tat the backtest will use the variable to calculate the margin required for the trade.


- There are some sources lurking around that provide the actual historical margins:
http://www.cmegroup.com/clearing/risk-management/historical-margins.html, for example.

Question: If one painfully collated this data, how could one use it in the WL environment ?


AK

Hi Adrien,

QUOTE:
Question: Can the symbol info manager be populated with a variable like a dollarised 10 day ATR?

No, the tool is not designed with variables in mind. Any programmatic change made to its preferences file (SymbolnfoManager.xml) won't even be reflected until WL is restarted.

Thanks Eugene,

I thought that was the case.
Is there perhaps another solution to better reflect historical margins in backtests ? Perhaps through code ?

A rawer cruder way to do it would be to use the "average margin requirement" over the period of the backtest, but this obviously lacks in accuracy.

Has this come up before ? Your thoughts are appreciated.

Well, there's Margin property in every Bars object > SymbolInfo group and in theory it looks like it allows itself to be altered on a bar by bar basis:

CODE:
Please log in to see this code.

Thanks Eugene, Will have a play with this

Question is, will Wealth-Lab adhere it or use the static value in the Symbol Info Mgr. Feel free to share your findings on the forum.

Hm... it looks like Wealth-Lab uses the static value provided in the Symbol Info Mgr, and ignores the si.Margin assignments from the editor.
The snippet of code you provided effectively shows different margin for every bar in the PrintDebug Window, but I think that's as far as it goes.
That information is not taken into any further consideration.

I ran a strategy twice on a portfolio mode, on the same data.
One without these si.Margin assignment, one with (I made some outlandish assignments that would ensure results would be obvious)
The results where identical across both backtests.

I also repeated the process making sure I removed the relevant symbol line from the Symbol Info Manager (thinking/hoping that if there was no data there, the si.Margin assignment would kick in), but once again the results where the same.

Any thoughts on any other workarounds here ?

QUOTE:
but once again the results where the same.

Sounds like Futures mode is disabled on your end. I just ran Moving Average Crossover with lines like "if( bar >= 100 ) si.Margin = 100;" thrown in and it eagerly reacted to changes to the code I was making. The performance report was changing.

Thanks Eugene,
My Futures mode is definitely enabled. Must have something to do with 'where in the code' these statements go.
I am entering these statements at the upper end of the code where variables are declared.
If you could post your MA crossover example that would be very much appreciated.

On a more interesting note for the forum, I am running some analysis to see whether this approach even makes sense at all, and the chart attached (CL) shows that there may be some value in assuming a good correlation between margins and ATR.
(the gap in the red line = i have no data for this period).

QUOTE:
I am entering these statements at the upper end of the code where variables are declared.

Variables are usually declared before the main (trading) loop where "bars" just do not exist yet. This doesn't make sense. These statements should be placed inside the main (trading) loop - for instance, right after its beginning. Please see post #4 for a complete example.

Indeed, i thought about this incorrectly, thanks for your help on this.

Hi akardar1,

A very interesting link for historical margins, thank you.

Just one word of advice from the zillion tests that I have created and ran in my life:
Don't get hang up on little details. As we all want our tests to be as close to reality as possible, sometimes we are over doing it. The time spend on details like that are spend better in other fields.

Hi VK,

Thank you for your sound advice.

My thought process was that a well thought strategy should know, in advance, how much of its capital (percentage) will be utilized for margin.
25% or perhaps 50 % ?

The answer will allow me to deduce how many positions I can have on at the same time, and therefore avoid the "insufficient funds" message, by which point you have probably already received a margin call. The only way to really tackle this is by having and near accurate representation of margins. CL has has seen a margin low of 3k ish and a margin high of 9kish in the last 10 years.

Once we got the si.Margin to work (i.e. to use a value driven by code, instead of the symbol info manager's static value), things looked promising. However, I have come to the conclusion that, despite the fact that is possible to pass a value si.Margin for every bar, its not possible for this to be dynamically called on for every trade as margin. Its as if, the code is only willing to update the margin "once" for the duration of the backtest.

*For those interested, here is a test summary example:
Run over 500 bars of data with around 10 trades on one product. Set Capital to 100,000

First run: Set the margin to $100,000 for bars 1 to 300 then $200 for bars 301 to 500.
Result: All trades were taken with size inline with margin of $200 for all trades.

Second run: Same code with $200 margin for bars 1 to 300 then $100,000 for bars 301 to 500
Result: No trades taken.

In both cases the si.Margin for each bar was printed and showed the margin to be set for each bar as described. While symbol info manager was updated in each scenario with the final bar margin value. So it seems although it does seem to be possible to dynamically vary the si.Margin the trade size calculations are not using this but instead reference the final margin value.

If anyone thinks otherwise, let me know : )