Forwards vs. Futures

I’ve covered Forwards and Futures in previous posts, and now that I’ve covered the basics of Stochastic Interest Rates as well, we can have a look at the difference between Forwards and Futures Contracts from a financial perspective.

As discussed before, the price of a Forward Contract is enforceable by arbitrage if the underlying is available and freely storable and there are Zero Coupon Bonds available to the Forward Contract delivery time. In this case, the forward price is

F(t,T) = S(t) \cdot {1 \over {\rm ZCB}(t,T)}

In this post I’m going to assume a general interest rate model, which in particular may well be stochastic. In such cases, the price of a ZCB at the present time is given by

{\rm ZCB}(t,T) = {\mathbb E}\Big[ \exp{\Big\{\int_t^T r(t') dt'\Big\} } \Big]

Futures Contracts are a bit more complicated, and we need to extend our earlier description in the case that there are interest rates. The basic description was given before, but additionally in the presence of interest rates, any deposit that is in either party’s account is delivered to the OTHER party at the end of each time period. So, taking the example from the previous post, on day 4 we had $4 on account with the exchange – if rates on that day were 10% p.a., over that day the $4 balance would accrue about 10c interest, which would be paid to the other party.

Let’s say we’re at time s, and want to calculate the Futures price to time T. Our replication strategy is now as follows, following the classic proof due to Cox, Ingersall and Ross but in continuous time. Futures Contracts are free to enter into and break out of due to the margin in each account, so entering X Futures Contracts at time t and closing them at time t+dt will lead to a net receipt (or payment if negative) of \inline {\rm X}\cdot\big[ H(t+dt,T) - H(t,T)\big]. From t+dt to T, we invest (borrow) this amount at the short rate and thus recieve (need to pay)

{\rm X}\cdot\big[ H(t+\tau,T) - H(t,T)\big]\cdot\prod_t^T \big( 1 + r(t)\tau \big)

and now moving to continuous time

{\rm X}\cdot\big[ H(t+dt,T) - H(t,T)\big]\cdot\int_t^T e^{ r(t)}\ dt

We follow this strategy in continuous time, constantly opening contracts and closing them in the following time period [I’m glossing over discrete vs. continuous time here – as long as the short rate corresponds to the discrete time step involved this shouldn’t be a problem], and investing our profits and financing our losses both at the corresponding short rate. We choose a different X for each period [t,t+td] so that \inline {\rm X}(t) = \int_s^t \exp{\{r(t')\}}dt'. We also invest an amount H(s,T) at time s at the short rate, and continually roll this over so that it is worth \inline H(s,T)\cdot \int_s^T \exp{\{r(t)\}}dt at time T

Only the final step of this strategy costs money to enter, so the net price of the portfolio and trading strategy is H(s,T). The net payoff at expiry is

H(s,T)\cdot \int_s^T e^{r(t)}dt + \sum_s^T {\rm X}\cdot[H(t+dt,T)-H(t,T))]\cdot\int_t^T e^{r(t)}dt

= H(s,T)\cdot \int_s^T e^{r(t)}dt + \sum_s^T \int_s^t e^{r(t)}dt\cdot[H(t+dt,T)-H(t,T))]\cdot\int_t^T e^{r(t)}dt

= H(s,T)\cdot \int_s^T e^{r(t)}dt + \int_s^T e^{r(t)}dt \cdot \sum_s^T [H(t+dt,T)-H(t,T))]

= H(s,T)\cdot \int_s^T e^{r(t)}dt + \int_s^T e^{r(t)}dt \cdot [H(T,T)-H(s,T))]= H(T,T) \cdot \int_s^T e^{r(t)}dt

And H(T,T) is S(T), so the net payoff of a portfolio costing H(s,T) is

= S(T) \cdot \int_s^T e^{r(t)}dt

How does this differ from a portfolio costing the Forward price? Remembering that in Risk-Neutral Valuation, the present value of an asset is equal to the expectation of its future value discounted by a numeraire. In the risk-neutral measure, this numeraire is a unit of cash B continually re-invested at the short rate, which is worth \inline B(t,T) = e^{\int_t^T r(t')dt' }, so we see that the Futures Price is a martingale in the risk-neutral measure (sometimes called the ‘cash measure’ because of its numeraire). So the current value of a Futures Contract on some underlying should be

H(t,T) = {\mathbb E}^{\rm RN}\big[ S(T) | {\cal F}_t \big]

ie. the undiscounted expectation of the future spot in the risk-neutral measure. The Forward Price is instead the expected price in the T-forward measure whose numeraire is a ZCB expiring at time T

F(t,T) = {\mathbb E}^{\rm T}\big[ S(T) | {\cal F}_t \big]

We can express these in terms of each other remembering F(T,T) = S(T) = H(T,T) and using a change of numeraire (post on this soon!). I also use the expression for two correlated lognormal, which I derived at the bottom of this post

\begin{align*} F(t,T) &= {\mathbb E}^{T}\big[ F(T,T) | {\cal F}_t \big] \\ &= {\mathbb E}^{T}\big[ S(T) | {\cal F}_t \big] \\ &= {\mathbb E}^{T}\big[ H(T,T) | {\cal F}_t \big] \\ &= {\mathbb E}^{RN}\big[ H(T,T) {B(t)\over B(T)} {{\rm ZCB}(t,T)\over {\rm ZCB(T,T)}}| {\cal F}_t \big] \\ &= {\rm ZCB}(t,T){\mathbb E}^{RN}\big[ H(T,T) {1\over B(T)}| {\cal F}_t \big] \\ &= {\rm ZCB}(t,T){\mathbb E}^{RN}\big[ H(T,T)\big] {\mathbb E}^{RN}\big[ e^{-\int_t^T r(t')dt'} \big] e^{\sigma_H \sigma_B \rho} \\ &= H(t,T) \cdot e^{\sigma_H \sigma_B \rho} \\ \end{align*}

where \inline \sigma_H is the volatility of the Futures price, and \inline \sigma_B is the volatility of a ZCB – in general the algebra will be rather messy!

As a concrete example, let’s consider the following model for asset prices, with S driven by a geometric brownian motion and rates driven by the Vasicek model discussed before

{dS \over S} = r(t) dt + \sigma_S dW_t

dr = a \big[ \theta - r(t)\big] dt + \sigma_r \widetilde{dW_t}

And (critically) assuming that the two brownian processes are correlated according to rho

dW_t \cdot \widetilde{dW_t} = \rho dt

In this case, the volatility \inline \sigma_B is the volatility of \inline {\mathbb E}\big[ e^{-\int_t^T r(t')dt'}\big], and as I discussed in the post on stochastic rates, this is tractable and lognormally distributed in this model.

We can see that in the case of correlated stochastic rates, these two prices are not the same – which means that Futures and Forward Contracts are fundamentally different financial products.

 

For two standard normal variates x and y with correlation rho, we have:

\begin{align*} {\mathbb E}\big[ e^ {\sigma_1 x} \big]& = e^ {{1\over 2}\sigma_1^2 } \end{align*}

and

\begin{align*} {\mathbb E}\big[ e^ {\sigma_1 x + \sigma_2 y} \big]& = {\mathbb E}\big[ e^ {\sigma_1 x + \sigma_2 \rho x + \sigma_2 \sqrt{1-\rho^2}z} \big]\\ & = {\mathbb E}\big[ e^ {(\sigma_1 + \sigma_2 \rho) x + \sigma_2 \sqrt{1-\rho^2}z} \big]\\ & = \big[ e^ {{1\over 2}(\sigma_1 + \sigma_2 \rho)^2 + {1\over 2}(\sigma_2 \sqrt{1-\rho^2})^2} \big]\\ & = \big[ e^ {{1\over 2}\sigma_1^2 + {1\over 2}\sigma_2^2 + \sigma_1 \sigma_2 \rho} \big]\\ & = {\mathbb E}\big[ e^ {\sigma_1 x }\big] {\mathbb E} \big[ e^{\sigma_2 y}\big] e^{ \sigma_1 \sigma_2 \rho} \end{align*}

Factoryised C++

In two of my most recent posts I’ve talked about Forward Contracts and an implementation of the Normal Quantile function. One strategic reason for this will become apparent from today’s post!

I’m going to be talking here about one of the design patterns used in the Monte Carlo code presented on my blog and discussed recently. It isn’t really my goal for this blog to dwell heavily on programming topics as there are many, many more competent people than me sharing their knowledge on the subject across the web. However, there are some topics that are quite interesting to discuss and make ideal blog topics, and a grounding in Object-Oriented programming (particularly in C++) is vital for the modern Quant.

As I stated before, the goal of the code presented to date in ‘Simple Option Pricer 1.0’ is to choose a fairly simple option payoff, choose a method for generating uniform random numbers, and then choose a method for generating gaussian variates from these (and of course to enter the relevant market parameters like discount factor and volatility). The first thing to do is to download all of the code presented on that page, compile it, and run it a few times to make sure you can get all of it to work. Check the answers correspond to the results you get from the analytical pricers for the same parameters, although don’t forget that there will be some Monte Carlo error on the answers coming for C++, and observe that answers get better (though time taken increases!) as the number of paths is increased.

A very straight-forward way of achieving selectivity would be to use a switch statement:

int option;
SimpleOption* theOptionPointer;

cout << "Select a Contract Type: Call [1], Put [2]";
cin >> option;

switch ( option ) {
 case 1 :
  theOptionPointer = new CallOption( ... );
  break;
 case 2 :
  theOptionPointer = new PutOption( ... );
  break;
 default :
  throw("You must enter [1] or [2]!");
}

where I’ve assumed that we’ve defined some suitable option classes elsewhere that all inherit from an abstract base class SimpleOption (if there is demand for it I might go over inheritance another time, but there are many sources on the web. This IS important for quants, but it’s rather dry to go over!).

The switch statement looks at the user-entered value and assigns the pointer to an option of the relevant type. This is a basic example of polymorphism – we’ve declared theOptionPointer to be a pointer to the abstract base class SimpleOption, but then given it the address of a specific implementation of the base class via a derived class, either CallOption or PutOption. If we were to call any functions of this pointer, they would have to be those functions defined in the base class itself (although they could be abstract and potentially over-loaded in the derived classes) – if, for example, CallOption had a method called getStrike(), there would need to be a [potentially abstract] prototype for this in the base class SimpleOption if we want to have access to it via the SimpleOption pointer..

However, the code isn’t that great as it stands. We’re going to need a switch statement for each of the choices we’re giving the user (currently Option type, RNG type and Gaussian converter type), which will lead to a bloated main(){} function. More annoyingly, every time we want to include a new option in any of these selections, as well as coding up the relevant classes for the new choice we’re going to need to go into the main function and alter the choices and control structures given by the switch statements. As well as being a bother, this will mean the whole project will need to be re-compiled, and for large projects this can be a significant time constraint. You can see roughly how much time this takes by comparing the speed of Build/Compiling your project (which checks to see if changes have been made, and then only rebuilds the files that are affected) with the time taken to Re-Build/Re-Compile your project (which throws away previously compiled files and starts again from the beginning). Give this a try!

I’ve got around this in ‘Simple Option Pricer 1.0’ by coding up a basic Factory for each of the three selections, based on the Factory presented in Chapter 10 of Joshi’s text, C++ Design Patterns and Derivatives Pricing (this is one of my favourite textbooks on the subject – I’ll do some book reviews of other gems in the future). You can see how this works by downloading the following four files:

Drop these into the same folder as the rest of the files in ‘Simple Option Pricer 1.0’, and then right-click on the Project in your development environment and add them to the project one-by-one [Nb. if you’re using Visual Studio, you may need to add

#include "stdafx.h"

to the two .cpp files before this will work – and make sure they’re in the same folder as the rest, this can cause problems!!].

Now, Build/Compile your project. If you’ve done everything correctly, it should happen very swiftly – only the forward.cpp and the gaussianCdfInverter.cpp will need to compile, and the linker will need to run, but the other files won’t need to be recompiled (this is the real strength of the method, by the way!). Now, re-run the programme and you should discover two new options available to you for the option pricer! How have we achieved this sorcery?!

In the files optionFactory.cpp and optionFactory.h (and the corresponding files for the RNG and gaussian converters), we’ve defined the factories for the different types of classes we want to use. I’ve used the Singleton Pattern (for brevity I’m not going to discuss it here, but do have a look at wikipedia) to create and access a single instance of each factory. The important point is that there will be a single instance of each factory, and we can get their addresses in memory using the following method at any point in the code

optionFactory::factoryAddress()

The factories themselves store a two column table (implemented with a map) which links a string (the option name) in the first column with a function that constructs an option of that type and returns a pointer to it in the second column (this will be a base class pointer, using polymorphism as discussed above).

The functions that will create these pointers are implemented using another type of polymorphism – templatisation. In the optionFactoryHelper.h header, I’ve defined a new class which is constructed by calling it with a string. It also has a method which builds a new instance of the <class T>, and returns a pointer to it – which is exactly what we said the factory table needs.

template <class T>
simpleOption* simpleOptionHelper<T>::buildOption(double strike) {
 return new T(strike);
}

The constructer for the helper function registers this method in the factory’s table, along with the string.

template <class T>
simpleOptionHelper<T>::simpleOptionHelper(std::string optionType){
 optionFactory& theFactoryAddress = optionFactory::factoryAddress();
 theFactoryAddress.registerOption(optionType, simpleOptionHelper<T>::buildOption);
}

Options are registered in their .cpp files, the simple code to register the forward is at the top of forward.cpp, creating a new instance of the helper class templatised on the specific instance of the option that we are registering through it. This will call the helper class constructor, which as we just saw contains code to register the corresponding option type with the factory

namespace {
 simpleOptionHelper<forward> registerForward("forward");
}

Since these are done in namespaces, they happen before main(){} starts running – and once registered, we can call the factory at any time in our code using a string and giving it the required parameters and it will create a new instance of the derived class with that name

simpleOption* thisOptionPointer = optionFactory::factoryAddress().createOption( optionType, strike );

I’ll use this pattern again and again in future as more and more options are added to the code. At some point in the future, I’ll look at a way of combining ALL of the factories into a single, templatised factory process using more polymorphism, but the complication will be that since different processes need different arguments for their constructors, I’ll need to build a generic container class first that could contain many different sorts of arguments inside it. The next thing I want to do, however, is look at easier ways of data input and output, as the current console application is very clunky and wouldn’t be suitable for a large amount of data input. I’ll discuss ways of dealing with this in future posts.

Forwards

I’ve mentioned Forwards many times in the blog so far, but haven’t yet given any description of what they are, and it’s about time for a summary! Forwards were probably the first ‘financial derivative’ to be traded, and they still occupy a central role in the field today.

At the most basic level, a Forward Contract is a delayed sale between two parties. The contract is signed now and the sale and the price agreed to, but the transaction only happens at a later date. We can immediately see why these contracts would be popular, as they insulate the people who have signed the contract from risk due to price variations. For example, an airline can foresee fairly accurately its fuel requirements over the next year, so might wish to enter into a Forward Contract with an oil company for a certain amount of fuel to be delivered next year, in order not to be exposed to the risk of price rises. Meanwhile, the oil company knows its costs of production, and might well also decide that as long as the contract price is profitable it is locking in business for the future and avoiding the risk of price falls harming its operations.

The first thing to note is that, unlike options, the contract is binding – both parties are obliged to enter into the transaction at the given date, there is no optionality in this contract. The agreed price has different names, but for consistency with other products quants tend to call it the Strike Price, K.

Forward Contracts are the most simple form of derivative. A derivative is a financial instrument that derives it’s price from some other (‘underlying’) instrument. In the example above, the underlying was the cost of oil, but it could equally well have been foreign exchange rates, stock prices or interest rates – indeed, all of these are different sorts of risks that companies will in general want to hedge out. What is the price of a Forward Contract and how does it depend on the underlying? If the price of oil rises after the contract above had been signed, the airline company would breath a sign of relief – it has locked in the forward price for its oil via the Forward Contract so the contract is clearly a valuable asset for it. By contrast, the oil company will be miffed, as it could have sold the oil on the market for a better price. If prices fall, situations will be reversed. How can we express this mathematically?

As a simple example, I will consider a Forward Contract for me to buy a stock from a bank in a year’s time for $100. We can calculate the price of this contract using a technique called ‘replication’. What we need to do is construct a portfolio that exactly matches the payments implicit in the Forward Contract, and according to the ‘Law of One Price’, the price of these two matching portfolios must be the same. Call now t=0 and the expiry of the contract t=T.

Portfolio 1: 1 Forward Contract on S at strike price $100 and at time T. Transactions are: at time T, I pay $100, and receive one unit of stock. This will be worth S(T), the price of the underlying at that time. There are no net payments at time t=0.

How can we match this? Well, we will need to ensure the receipt of an amount of cash S(T) at time T, and an ideal way of ensuring this is by buying a unit of the stock at t=0 and holding it, since this is guaranteed to be worth S(T) at t=T. We also need to match the payment of the strike price, $100, at t=T. An ideal product to use for this is a Zero Coupon Bond maturing at t=T (this is equivalent to borrowing money and you can see it either way. We’re making all of the usual assumptions about being able to go long and short equally easily etc.). Recall that Zero Coupon Bonds are worth $1 at time t=T, and worth

    \[{\rm ZCB}(0,T) = {\mathbb E} \Bigr[ e^{-\int_0^T r(t')dt'} \Bigl] = e^{-rT}\]

at t=0, with the last equality holding only in the case of constant interest rates. So, we can short 100 ZCBs at t=0, these will mature at t=T when we will have to pay the holder $100. The holder will pay us the present value at t=0, which is 100 \cdot ZCB(0,T). We’ve constructed a portfolio that matches all of the payments of portfolio 1 at t=T:

Portfolio 2: Long 1 underlying stock S, short 100 ZCBs; close all positions at t=T.

How much does it cost to enter into portfolio 2? As we’ve said, this will identically be the price of portfolio 1. The cost is

    \[{\rm Fwd}(0,T) = S(0) - K \cdot {\rm ZCB}(0,T)\]

    \[= {\rm ZCB}(0,T) \cdot \Bigl({S(0) \over {\rm ZCB}(0,T)} - K \Bigr)\]

We can see that this price is a linear function of K – being long a Forward Contract is better if the strike is lower! We see that its price doesn’t depend on any assumptions about the underlying growth rate (the only assumption was that we can readily trade it on the market at the two times t=0 and t=T), and depends instead on the risk-free interest rate r(t). For this reason the contract is described as ‘Model Independent’ – its price doesn’t depend on any assumptions we make about the world, we can enforce it by no arbitrage using prices of things that are available to buy right now. Compare that to the hedging strategy for a vanilla option discussed here, which relied on continuous re-hedging in the future, and is hence open to risk if our model of future volatility and interest rate isn’t perfect (and it won’t be!).

The ‘Forward Price’ is defined as the strike which makes this contract valueless for both parties – the ‘fair price’ – looking at the equation above we can see that this must be

    \[{S(0)\over {\rm ZCB}(0,T)} = S(0)\cdot{\mathbb E}\Bigl[ e^{\int^T_0 r(t') dt'}\Bigr] = S(0)\cdot e^{rT}\]

with the second equality again only valid for constant rates. The Forward Price is exactly the expectation of the underlying stock S in the risk-neutral measure, it appears across quantitative finance and often simplifies algebra, consider for example the following two ways of expressing the BS equation for vanilla option prices:

    \[C_{\rm call}(K,T,\sigma,r,\delta) = S(0)\cdot \Phi(d_1) - \delta(0,T) K \cdot \Phi(d_2)\]

    \[C_{\rm call}(K,T,\sigma,r,\delta) = \delta(0,T) \Bigl( {\rm Fwd}(0,T)\cdot \Phi(d_1) - K \cdot \Phi(d_2) \Bigr)\]

with the various terms as defined in previous posts (nb. the discount factor here from t=0 to t=T is exactly the same as a ZCB expiring at T). I certainly prefer the second form – it is expressed in terms of quantities depending on the same time T, and all of the discounting is handled outside the brackets, so it is much more easily modularised when coding it up.

Compare the payoff of a forward at expiry with that of a call and a put option. How are they related? It turns out that

    \[C_{\rm call}(K,T,\sigma,r,\delta) - C_{\rm put}(K,T,\sigma,r,\delta) = \delta(0,T)\Big({\rm Fwd}(K,T,r,\delta) - K\Big)\]

This result is called put-call parity. It comes about because if we’re long a call and short a put, we will exercise the call only if the price goes up and the counterparty will exercise the put only if the price falls – we’ve effectively locked in a sale at the strike price K at time T – such a strategy is called a synthetic forward. Note this is actually quite a deep result – although the price of both a call and a put option will depend on the model that we assume for the underlying, the difference in the two prices is model-independent and enforceable by arbitrage! If we assume an increased level of volatility over the option lifetimes, it will increase both prices by the same amount.

Payoffs at expiry for a Forward Contract compared to vanilla calls and puts.
Payoffs at expiry for a Forward Contract compared to vanilla calls and puts. Since a Forward Contract obliges to enter a transaction at expiry at strike K, the payoff can now be negative. If strike is $100 as shown above, but spot has fallen to $70, then the contract is worth -$30, as we could have bought the underlying from the market at $70 but are instead obliged to pay $100 to honour our Forward Contract. Similarly, if the price rises, our contract payoff will be positive. By comparing to the vanilla payoffs at expiry, we can see that a long call and a short put will have the same payoff as a Forward Contract, a result called put-call parity.

Up to this point, I’ve made the implicit assumptions that the underlying asset doesn’t pay any income, it’s free to hold it, and we’re able to go long or short with equal ease. Of course, in general, none of these are true. If the asset pays income like dividends, or if there are costs of storage, it is fairly easy to adjust our replication argument above to find a new price for the Forward Contract that takes into account the extra cash flows associated with holding the underlying over the period 0 \textless t \textless T. However, we can’t always go short the underlying asset – a particular case of this will be commodities, where the asset in question may not exist at the current time (ie. if you haven’t dug it out of the ground or transported it to the delivery point at t=0!), in which case there is no reason that the forward price should be related to the spot price in the deterministic way described above – this is because we have violated our assumption about being able to trade the underlying at the two times t=0 and t=T, which was implicitly vital! However, the price of the Forward Price will still converge towards the expected future spot price as we approach t=T even in this case, since a Forward Contract for transaction at the current time is simply a spot transaction!

One final word about Forward Contracts – they are ‘Over The Counter’, which means they are signed between two counterparties directly and thus carry Credit Risk – there is a chance that your counterparty might go bankrupt before the contract expiry, in which case the transaction won’t be completed. If your contract was out-of-the-money, you will still be expected to settle your position with them, while if it was in-the-money they may well not be able to pay you your full dues, so credit risk will decrease the actual value of the contract. There are advanced ways of accounting for this that I deal with in a later post (CVA – Credit Valuation Adjustment); alternatively there is a similar product called the Futures Contract, which I will deal with very soon in another post, which is superficially similar to the Forward Contract (leading to MUCH confusion in the industry!) but also attempts to deal with this credit risk.