[R-SIG-Finance] Using Margin in Blotter package

[Brian G. Peterson]

Margin depends on both the instrument and the position.  Most exchanges 
use SPAN, and certified SPAN engines are extremely expensive.  Beyond 
exchange margin, your broker often charges additional margin, and may or 
may not cross-margin using SPAN.

Ulrich is right that you could add a field to your instrument data (in 
the FinancialInstrument package) to describe minimum initial and 
maintenance margin: that's trivial as the instrument model is 
deliberately extensible, but it's also useless because it doesn't cover 
cross-margining, and the only accounts that don't get cross-margin are 
typically retail.

Even funds that use leverage in the futures space typically tell their 
investors that they will invest a certain *notional* amount from equity. 
  While they usually report margin/equity, this has nothing to do with 
most backtests, you backtest on notional exposure, and your reported 
leverage to your investor is usually based on notional as well.

While efficient use of margin is obviously very important, I don't 
really see this as having anything to do with blotter, since we're not 
going to license and write a SPAN engine.

Regards,

    - Brian

On 11/01/2012 06:19 PM, Ulrich Staudinger wrote:
> To make it really precise is an art, though. I don't know the internals of
> the blotter package, but as far as I understood, quantstrat has an
> instrument class (or was it blotter?), this instrument class would be the
> right place to add a function "cashUse" or something like that.
>
> A function could cater for the different characteristics of contracts. As
> an example, the actual margin use for FDAX futures depends on volatility
> and price - it's not a plain price dependency.
>
> 'my two cent.
>
>
>
> On Thu, Nov 1, 2012 at 11:45 PM, Peter Carl <peter at braverock.com> wrote:
>
>>> Is there a way to account for margin size in blotter?
>> No, although it isn't outside the realm of possibilities some day.
>> Finding an enthusiastic author of such code has been, well, difficult.
>>
>>> If not, can you think of a way to "cheat" that into the current system?
>> As a quick but perhaps impractical solution, you could export your
>> positions to an external span engine.  Barring that possibility, I'd say
>> that you can do some back of the envelope calculations based on positions
>> and transactions kept in blotter to estimate margin use if you need.
>>
>> Contributions would be welcome, of course.
>>
>> pcc
>> --
>> Peter Carl
>> http://www.braverock.com/peter
>>
>>>   I've run into an issue with the blotter package that may be significant.
>>>
>>> When buying and selling futures, the full contract value is NEVER paid.
>> It is normal practice to simply pay the margin.  For example, a single
>> contract of corn is for 5,000 bushels.  At $5.00 per bushel, that is a
>> $25,000 contract.  However, the amount actually paid to a broker is
>> around $2,000.
>>>
>>> This is an issue when designing and testing trading systems.  If I have
>> a fictional fund of $1,000,000 and want to buy 20 contracts of corn,
>> real life cash outflow would be around $40,000.  However, with blotter
>> it would be $500,000, which is 1/2 of my portfolio. That quickly kills a
>> lot of trading strategies and testing.
>>>
>>> Is there a way to account for margin size in blotter?
>>> If not, can you think of a way to "cheat" that into the current system?
>>>
>>>
>>> --
>>> Noah Silverman, M.S.
>>> UCLA Department of Statistics
>>> 8117 Math Sciences Building
>>> Los Angeles, CA 90095
>>>
>>> _______________________________________________
>>> R-SIG-Finance at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>>> -- Subscriber-posting only. If you want to post, subscribe first. --
>> Also note that this is not the r-help list where general R questions
>> should go.
>>>
>>
>> _______________________________________________
>> R-SIG-Finance at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>> -- Subscriber-posting only. If you want to post, subscribe first.
>> -- Also note that this is not the r-help list where general R questions
>> should go.
>>
>
>
>


-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock