Forecasting Dividends - Part 3

In part one and two of this series we covered the theory behind predicting dividends; this post is where the rubber hits the road.

~~

The maths for our previous wordy description is

F = S * e ^ [(r-c) * t]

where

F : future or forward price of the stock

S : spot price

r : interest rate

t : time to the forward's maturity

c: convenience yield

We haven't mentioned the convenience yield yet.  For equities the convenience yield is

c = q + l + E

where

q : dividend yield

l : stock lending yield (a big factor when a stock is being heavily shorted)

E : error term, or other miscellaneous factors

Solving the equation for q and assuming stock lending and the error term is minimal we find an equation we can use to predict dividends

q = r - ln(F/S) / t

~~

In order to test this equation I took an S&P 500 future maturing in December 2013 and tracked it through the wild ups and downs through its three years of life.  It was a pretty interesting time; the boom of 2013, not to mention Euro zone debt crises and Congress debt ceiling talks.

On the future's first day it predicted the dividend yield over the next 3 years would be 1.9%; the actual yield was 2.08%. Not bad.

The average deviation was about -0.2% over its life, i.e. it underestimated the dividend yield over its life time.

Still, in the volatile world of equities being about 10% off in longer range forecasts is unheard of.

The data I used to make these forecasts can be downloaded here (Open Office format).

The spread sheet can be improved upon - perhaps with more care the forecasts will be even more accurate.

Also, the realised dividend information used is actually from the SPY ETF - I couldn't find the dividend information for the S&P 500 index itself.

Lastly, the forecast is really for the future's convenience yield - there are quite a few factors which we assume to be small, that may have a large impact over certain periods of time.

~~

Next time, we will investigate making predictions for individual stocks rather than indicies.

Strength

Geraldine O'Hara describes her time in Africa treating Ebola in her audio diary.

One day she describes seeing a woman saying goodbye to her son for the last time while her son is being wheeled into another room for treatment.

Her son never comes back, but a young boy starts tagging along with her because he has no one else left.

O'Hara is amazed at the strength of the woman, who immediately after losing her son picks herself and starts caring for someone else's son.

Forecasting Dividends - Part 2

Imagine you woke up tomorrow morning, the calendar was open at tomorrow's date - but 10 years ago.

Time travel.

What could you do?  Earn a lot of money! (and save the world perhaps)

How could you earn that money?  Invest in the stock market?  Apple hasn't introduced the iPhone yet and Nokia hasn't jumped off a cliff.

Time travellers have an unfair advantage; but like many other travellers; they have new information which people will pay a handsome price for.

Earning money quickly is recompense for flagging to everyone what's valuable and what's not.

Sub-prime real estate is junk.

In contrast, a recently IPO-ed Google is gold.

~~

Now let's return to the conundrum we left last post.  Uncertainty makes forecasting dividends hard.  We have a bunch of unhelpful unknowns.

What do we know?

We know the current stock price; the cost of delayed or future cash payments (i.e. the interest rate).

What else can we get our hands on?

How about the forward price?  Last time we saw that the next dividend payment could be calculated by comparing the current stock price (the value of all future dividends) minus the forward price (the value of future dividend payments excluding the ones paid between now and the future's expiry date).

It's not common to find forward prices for individual stocks, but we can find them for stock indicies in the form of index future prices.

~~

Future prices don't come to us from speculative time travellers; rather on the back of the trillions of dollars traded in them every day.  Each trader earning money from the valuable snippets of information they bring to market every day.

The current price is the best available knowledge we have about the future right now.

~~

In our idealised world from the previous post; the next period's dividend is 1 dollar.  The difference between the current price of 100 dollars and the 99 dollar forward price.

Let's hypothesis that the next dividend of the S&P 500 is the difference between the current value and the the next future contract's price.

We need to adjust a little for the mismatch between how we value future payments less than current ones (i.e. the interest rate); but other than that we should have the best possible prediction of the next dividends paid by S&P 500 companies.

~~

We will take a look at how well we can predict dividends in our next post!

Forecasting Dividends - Part 1

Forecasting is difficult, nigh on impossible in fact, however in order to have a basis for deciding what to do right now - we need to have some grasp on what may happen in the future.

Stocks are valued by the market's expectations of future dividend payouts.

As a mind experiment let's assume determinism and forget about uncertainty for a while.

~~

We have Acme Co.  The market knows that the company will stick around for the next 100 years; that it will pay out a dollar dividend per year for the duration of its life.

Let's also assume that the market values receiving a dollar now the same as a dollar receive at any point in the future.

How much will a stock in Acme Co. be valued by the market?  $100, of course.

Assuming everything stays the same, how much will Acme Co. be valued at next year? (i.e. the 'one year forward' price)

$99!

The difference between the forward price and the current price is the dividend paid over the next year: $1.

This is the value we would like to predict in the real world.

~~

Now lets add back in all the complexity which we assumed away.

Of course we never know how long a company will survive; a company could kick the bucket next year or in a hundred years.

We can only guess at what dividends will be paid out in the future.

And, importantly, everyone is impatient, of course I'd rather dollars sooner rather than later!

Last, but not least, nothing stays the same.  Shit happens, as the saying goes.

~~

It seems we have hit a road block.

~~

We had a mind experiment that makes sense.  We add in a bunch of uncertainty and now we are back to square one.

It's like we have a 'mental equation'; to which we just added a slew of unknowns and all of a sudden it's all unsolvable.

~~

Tune in next week for more!

~~

iDivs.org

Learning QuantLib with Python - Implied Volatility

[Previous post]

However much finance would like to disown its father discipline; it very much belongs to the economics world which in turn boils down to sociology for nerds.

Economics is about understanding people and how they make decisions and financial models are fairytales about how people operate in the land of markets.  They are not very accurate.

What happens when people do something unexpected or 'irrational'?  A financial engineer will calibrate her financial model to reality.

There are two financial 'laws' which hold pretty consistently (apart from death and taxes) but a apart from those everything else is a metaphor and a search for intuition rather than steadfast knowledge about how the financial world operates.

Implied volatility is a fudge factor which we add to option pricing models as the rubber hits the road (volatility is a useful fudge because it's not directly measurable; no one can readily refute it!).

Incidentally there is another unknown.  Future dividend yield which you can find estimated at iDivs.org.

QuantLib makes finding the implied volatility of an option very easy.

Continuing from where we left off with our previous option example.  Add a line to solve for implied volatility using its market value like so

implied_volatility_rate = option.impliedVolatility(market_value, process)

and simply set our volatility to the rate we just found (OO for the win!)

volatility_rate.setValue(implied_volatility_rate)

Runnable code can be downloaded here.

Assuming the model is correct (big assumption) we now have a nicely capsulated way to understand our American option and understand how we will be impacted by all manner of possible bumps in the road ahead.

Financial models are inaccurate.  In this case it is obvious by how they inconsistently report implied volatilities on the same stock for the same expiry (i.e. the implied volatility smile).

In contrast to the constant nature of laws, financial models are capricious friends.

Nevertheless approximate intuition is far better than nothing.

[Next post in series]

Python and QuantLib - Bonds

[Previous post in this series]

A hundred years ago equities were the modern derivatives of mass destruction du jour, only traded by financial whizz kids.

Today the global debt market still dwarfs the equity market; but equity has a larger mind share amongst the public, perhaps because fixed income is harder to understand.

In finance, as with the wider world, simplicity and complexity are often two sides of the same coin.

On the face of it, bonds look more complicated than equities.  When you choose to buy a bond there are many terms and conditions which describe when you receive money and how much you'll be paid.  The specificity removes room for surprises.

QuantLib gives us the Schedule function which helps us set out the time table for coupon and principal payment.

bondSchedule = Schedule(issue_date, maturity_date, Period(payment_frequency), calendar, Unadjusted, Unadjusted, DateGeneration.Backward, False)

The FixedRateBond method creates our bond object and sets the rest of the details needed to value the bond.

bond = FixedRateBond(0, face, bondSchedule, [coupon], bondDiscountingTermStructure.dayCounter(), payment_convention, 100, issue_date)

Each payment can be costed out and we can put a price on each cash flow dependent on time.  In the previous option example we set the interest rate to a constant over time.  Now we will create a term structure which increases the cost over time.

We will create a dictionary for zero coupon bond yields by time.

zcQuotes = [ (0.0003, Period(1,Months)), (0.0004, Period(3,Months)) ... (0.0333, Period(25,Years)),(0.0348, Period(30,Years)) ]

and retrieve a term structure object from QuantLib

# Create deposit rate helpers
zcHelpers = [ DepositRateHelper(QuoteHandle(SimpleQuote(r)), tenor, fixing_days, calendar, payment_convention, True, day_counter) for (r,tenor) in zcQuotes ]

# Term structure to be used in discounting bond cash flows
ts = PiecewiseFlatForward(valuation_date, zcHelpers, day_counter)

This laborious setup code hints at the pedantic nature of bonds.

However, remember, stockholders aren't given any specific promises by the issuing company.  A stock holder is told he may or may not be given dividend payments at some time in future.  That's it.

How would you go about modelling that effectively? (Rhetorical question!)

A bond's fine grained detail gives you a much richer set of analytical tools than in the equity world and far better accuracy to boot.

The analytical depth available is result of the superficial complexity and underlying simplicity.

The upshot is precious nuggets of actionable insight; which you can derive handily enough from QuantLib.

Download a working example of the code here.

QuantLib and Python - iPython Notebook Screencast

Really nice screencast by Luigi Ballabio.

QuantLib 1.4 Packages on Debian Stable

Freshly baked last night.  Download here.

Python and QuantLib - American Equity Options

[The previous post in this series is here]

American options are exactly the same as European options in every respect, except of course, the holder of an American option can exercise his right to buy or sell stock earlier than the expiry date.

On the face of it, this extra freedom in the contract sounds like a big benefit.  Extra choice is always good.

In practice however, the dollar value of the benefit is minimal.

American bankers (North or South?) are great sales people.  They sell some fancy financial products which sound much better value than it really is.  Where have I heard that before?  Ingenious.

The benefit might be near worthless but after the tweak there is no analytical solution to the problem.  I.e. no best 'answer' in all situations.

If the expiry date is finite, the problem is associated with a 2-dimensional free-boundary problem with no known closed-form solution.

Luckily QuantLib provides a couple of dozen pricing engines that numerically approximate solutions; which means if you really care about accuracy you have a lot of ammunition to nail down decent numbers.

On the other hand, if you really don't care too much, I hear you!

It takes two lines of code to change our previous European option into an American option.

First we need to change the exercise rules to allow for early expiry.

Our exercise variable in the European option example

exercise = EuropeanExercise(expiry_date)  

becomes

exercise = AmericanExercise(valuation_date, expiry_date)

Now we have to look into which pricing engine to use.

Cox, Ross and Rubinstein is the bog standard method that everyone uses and understands well but unfortunately is also terribly inefficient.

I have found that the finite difference engine generally achieves far better accuracy within a similar time period.

We switch out the European analytical engine

engine = AnalyticEuropeanEngine(process)

with our brand spanking new one

time_steps = 100
grid_points = 100
engine = FDAmericanEngine(process, time_steps, grid_points)

Once we have everything good to go and see results we will notice far fewer analytics available.  We have left the analytical world and almost every sensitivity calculation no longer comes for free.  I.e. now we will have to recalculate by shocking inputs a little in order to see each Greek.

The full source code for the example is here.  Note that I have started to organise the code into methods.

So there you have it.  Bank salesmen in America threw a nice sweetener into the option deal causing headaches for practitioners (and grant money for mathematicians) for decades to come.

Now we will just have to wait for African (?) equity option salesmen to popularise American options that never expire to make our lives easier again.

[Next post]

Python and QuantLib - Equity Option Example Source Code

[Read the previous part of this series here]


The command line entries have been rejiggered into one Python file which you can download.

I added some new results also, which give you an idea of the analytical results available out of the box.


[Read the next part here!]

Quantlib and Python - Putting Fingers to Keyboard

[Read the previous part in this series here]

You want to be an ueber powerful super hero capable of all sorts of impossible feats; then again don't you want to lead a simple life away from all the complexities of having rubbery hands and being able to become invisible?

No wonder super heroes resort to having those Clarke Kent and Bruce Wayne alter egos.

[As an aside, that reminds me of the age old question - would you rather be able to fly or turn invisible?]

Every designer has to ask himself this.  Not whether he wants to fly or not but do we want to do a few things well or be a super duper Swiss Army knife?

Quantlib (most of the time) comes down on the Swiss Army side of the argument; which means it's hard to learn; but also, once mastered, you will have those financial super powers at the touch of your finger tips. That's the hope!

Dates are a good starting point.  Almost everything non trivial in finance involves specific future payoffs.  Actually when I say non trivial I mean in some way tractable; the really hard stuff doesn't have specific future payments is left untouched.

In any case let's drop into Python's interactive interpreter

python

and create a few date objects

>>> from QuantLib import *

>>> valuationDate = Date(13,1,2014) 

>>> expiryDate = Date(13,1,2015)

Now tell the system what the valuation date is

>>> Settings.instance().evaluationDate = 
valuationDate

Finance is obsessed by time.  And of course money.  The cost of money over time is naturally represented by discount factors and on a day to day basis these prices are quoted as interest rates.

The following code sets an interest rate of 1% and tells the system that the price of money is constant over time.  The actual actual day count convention makes sure every calendar is accounted for when accruing payment IOUs (i.e. no short cut conventions are made in assuming 30 days in a month and 360 days a year).

>>> interestRate = 0.01

>>> riskFreeRate = FlatForward(valuationDate, interestRate, ActualActual() )

We can do the same for dividends.

>>> dividendRate = 0.02

>>> dividendYield = FlatForward(valuationDate, dividendRate, ActualActual() )

By the way if you want decent dividend predictions, check out iDivs.org.

Any financial asset with non-linear payoffs (it turns out almost everything) needs to account for volatility.  We will setup our volatility data in a very similar manner.

>>> calendar = UnitedStates()

>>> volRate = 0.03 

>>> volatility = BlackConstantVol(valuationDate, calendar, volRate, ActualActual())

As an aside, QuantLib's calendars are very useful (at the risk of being monotonous - finance is obsessed by time! : )).

I am unsure why volatility requires calendar information whereas flat forwards does not.  Let me know in the comments if you can enlighten me.

The last piece of data to setup is an underlying equity price of 123

>>> underlying = SimpleQuote(123)

As you can see, pretty much everything needed to be an object in QuantLib.  Every.  Single.  Thing.

Hardcore abstraction may well give you super powers, but also means there's a high barrier to entry.

No prizes for what we are going to model next.  We need to specify the payoff conditions for our European equity call option with a strike of 100

>>> exercise = EuropeanExercise(expiryDate)  

>>> strikePrice = 100

>>> payoff = PlainVanillaPayoff(Option.Call, strikePrice)

and roll those terms together into an option object

>>> option = VanillaOption(payoff,  exercise)

Now bundle the market data together

>>> u = QuoteHandle(underlying) 

>>> d = YieldTermStructureHandle(dividendYield)

>>> r = YieldTermStructureHandle(riskFreeRate)

>>> v = BlackVolTermStructureHandle(volatility)  

>>> process = BlackScholesMertonProcess( u,d,r,v)

Things are getting a little convoluted now with the handle objects, eh?

Finally we set the pricing engine.

>>> engine = AnalyticEuropeanEngine(process)

>>> option.setPricingEngine(engine)

Let's price and see a result

>>> option.NPV()

Now we start to tangibly benefit from the object oriented-ness.  We can swap pricing engines in and out to our heart's content.  For example, why stick with bog standard Black Scholes when we could use something which sounds much fancier?

In any case, we will wrap up by calculating some Greeks

>>> option.delta() 

>>> option.gamma()

>>> option.vega()

>>> option.theta() 

>>> option.rho()

If you missed it, QuantLib is a pretty verbose convoluted affair.

Rest assured as with intelligent design or creationism everything is done for a reason and after overcoming all of these obstacles you will become a finance quant prophet amongst men.

[Next part is here]

Quantlib and Python - Getting Started

[See part 1 of this series here]

When it comes to open source software Linux is the only way to go.

Why would you use anything other than Photoshop on a Mac or a cutting edge game on Windows? - using Linux is just easier for Python development and all the quant lib packages come ready made for your machine (no messy compiling required!).

In order to install Quantlib for Python on Debian (sure to work on Ubuntu and Mint also) Linux system run:

apt-get install quantlib-python quantlib-swig

which will install everything you need.

Now give your setup a quick test:

cd /usr/share/doc/quantlib-python/examples/

python bonds.py

With any luck you will see a bunch of analytical results in your console.

This collection of examples are one of two resources I have found about using Python for Quantlib, which hopefully I can add to a little with these blog posts.

The other reference which you can use are the test units also included in the same folder.

ls /usr/share/doc/quantlib-python/examples/test/

These tests are used as a check by the library developers to ensure everything is good to go and no bugs have been introduced.  With such meagre references the tests are valuable reference for code written in Python.

One of the other places to go to with is the Quantlib C++ library reference itself.  As I said before, C++ is not my forte and in this day and age more of an academic pursuit in finance than anything else.  Nevertheless, example Python code is in short supply - and the python code that you do write is pretty close to what you see written in C++.

The upshot is on the one hand your Python code doesn't feel super Pythonic because you are tied so close to the C++ libraries.  On the other hand the C++ idioms start making more and more sense after days and weeks of banging your head of the wall! (no pain no gain?)

The places to ask questions are Wilmott, Quant Stack Exchange and the mailing list.  None are high traffic when it comes to Quantlib (scared off yet?) so your mileage may vary.

[Continued here]

Quantlib and Python - An Introduction

I am learning how to write Quantlib code with Python in order to create a project of mine called Vol Kills.  What better way to learn than writing down what I have figured out?  And perhaps I can help others out along the way.

First question, why Quantlib? why Python?

Firstly Python is easier to learn than C++ (I admit I never tried, always sounded too daunting).  You can code quick with no need to worry about the cruft that comes with Java and C.

Secondly, we're really just using Python to send messages to Quantlib which is written in C++ compiled down to super fast 1s and 0s.

Best of both worlds!

Third Python does a lot.  You get the stats libraries; web frameworks; heavy lifting"extract transform load" libraries and more right there in the one place (their motto is "batteries included" after all).  No need to mess around with multiple languages and run times.

A quick word about QuantLib.  It's a collection of code which helps people like me model financial investments; understand how investor's portfolios tick and perhaps point out some opportunities and pitfalls ahead.

Quantlib has been developed for over a decade.  It is widely used and battle hardened.  Best of all it is free and open source, which means you can use it without worrying about licensing fees and nasty bugs (the more eyeballs on the code the less chance of errors).

[Continued here]

Quantlib 1.3 Debian Packages for Debian Stable

Debian is the old reliable Linux distribution.

It comes in several flavours.  "Unstable" which is really just the latest and greatest open source apps all collected together.

On the other end of the scale the "stable" release includes battle hardened software that has been tested for years.

Unstable is used on desktops stable is all about servers.

I ran into a problem last week however, as I needed some features from Quantlib 1.3 which weren't available in 1.2 (bundled with Stable).

Last time I did any serious compilation work was college.  Turned out not to be too tricky.

As of this weekend Quantlib 1.3 itself is out of date but I'll make do without 1.4 for the time being.

Without further ado download the deb packages here (including Ruby and Python bindings).