[R-SIG-Finance] R-SIG-Finance Digest, Vol 79, Issue 23

[Anass Mouhsine]

Thank you Brian for your insights.

I understand a little bit more the philosophy behind the spread 
definition with Financial Instruments.
I totally agree with you on the necessity to test a spread as a 
univariate time series without entering in the constitution of the 
portfolio synthetizing it.
The modus operandi that I understand now is to construct whatever spread 
I want (varying or not) using my own calculations functions in R and 
then declaring it in FI in order to be handled by quantstrat.

Thank you again and merry christmas ;-)

On 23/12/2010 12:00, r-sig-finance-request at r-project.org wrote:
> Message: 4
> Date: Wed, 22 Dec 2010 08:56:43 -0600
> From: "Brian G. Peterson"<brian at braverock.com>
> To:r-sig-finance at r-project.org
> Subject: Re: [R-SIG-Finance] [quantstrat] Trading a synthetic asset
> Message-ID:<4D1211AB.3070005 at braverock.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 12/22/2010 08:24 AM, Anass Mouhsine wrote:
>> >  Hi all,
>> >
>> >  While using the demos in package quantstrat ( btw a very nice and useful
>> >  package), I wondered about the application on a synthetic asset.
>> >  I've seen the possibilities offered by the FinancialInstrument package
>> >  on the subject. This package enables us to define a synthetic asset e.g.
>> >  a spread between two stocks.
> Yes.  I use it in this way.
>
>> >  My question is about the way of using this synthetic asset in a
>> >  quantstrat strategy.
>> >  How is it constructed? How is it handled by the getSymbols function used.
> There are two answers to this question, the 'simple' answer, and the
> more complex one.  I'll describe the 'simple' answer in some depth, and
> the more complex one more briefly.
>
>> >  My problem can be seen in two ways:
>> >
>> >  1- I have a constructed a synthetic spread (of two stocks) as an xts
>> >  object with a varying ratios through time.
>> >  How can use it in a quantstrategy as an asset itself? Specifically,
>> >  since quantstrat uses mainly the getSymbols function, how the data
>> >  loading is done?
> This is the 'simple' approach, and the one I recommend.
>
> You construct the spread time series as an xts object, and tell
> FinancialInstrument (FI) about your spread() instrument.
>
> You can then either use quantmod's setSymbolLookup or FI's
> setSymbolLookup.FI to tell it where you're storing the files or objects,
> or you can just name your xts series for the primary_id of the 'spread'
> instrument, keep it in your .GlobalEnv, and get() and getSymbols() will
> 'just find it'.
>
>> >  2-Suppose now I have the original symbols series and a time series of
>> >  weights defining the spread ratio.
>> >  I can use the getSymbols function to load original data. How can I
>> >  construct my time-varying spread using the package FinancialInstrument
>> >  and use it in a quantstrat framework?
> This gets to be a little more complicated, but still quite feasible.
> There is a simple buildSpread() function in FI that uses OHLC data.
> We're sanitizing and cleaning up a version of this function with more
> functionality that works on tick TBBO data. If you're using the
> getSymbols function on free OHLC data, the existing buildSpread function
> may meet your needs.  Please let us know.
>
>> >  I would like to know a little bit more about the logic intended when
>> >  facing this kind of use of the quantstrat framework.
> I hope this helps answer your direct questions.
>
> I find when building/testing strategies that using a univariate spread
> series is much easier than modeling transactions on the underlying
> instruments. There are several reasons for this, including that most
> modern trading execution platforms have spread execution engines, and
> think of the spread as a single product with multiple execution legs.
> This means that logically, the spread is one product, not all of its
> legs.  Also, the complexity of modeling the orders (in quantstrat or any
> other package) for all the individual legs doesn't seem to add a lot of
> accuracy to your tests, and introduces significant additional
> complexity.  I've done it, but don't tend to do this level of modeling
> anymore, as it detracts from the time I could be spending creating and
> refining strategies by miring me down in execution details.  If that's
> part of your 'edge', then maybe that would be warranted, but it's not
> for me (right now).
>
> Regards,
>
>     - Brian
>
> -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: 
> bgpbraverock