When Forward and Futures Prices Are Approximately Equal
Summary
The note asks whether a forward price equals a futures price when the contracts share a maturity and the market has no dividends, constant interest rates, and no arbitrage. The answer derives the standard cost-of-carry relationship: the delivery price is related to spot value grown at the risk-free rate, adjusted for net storage costs. It argues that the same no-arbitrage logic links forward and futures prices under simplified textbook assumptions.
The equality is presented as approximate in practice. Customized over-the-counter forwards may be illiquid and expose parties to counterparty risk, while futures are standardized. These frictions can affect pricing and make the theoretical equivalence imperfect. The brief answer does not quantify those effects or develop a formal model for how they change the price difference, so it is best read as an intuition for the idealized relationship rather than a complete pricing treatment.
Key ideas
- No-arbitrage connects delivery contracts to the cost of buying and holding the underlying asset.
- The cost-of-carry expression includes financing and net storage costs.
- Forward and futures prices can be treated as approximately equal under simplifying assumptions.
- Illiquidity and counterparty risk can weaken the practical equivalence.
Tags
Full text
# Is the forward price equal to the future price?
# Is the forward price equal to the future price?
If $f^{T_1}(t)$ is the price of a forward and $F^{T_1}(t)$ is the price of a future on some stock, both maturing at date $T_1$ and with the assumptions:
- no dividend
- constant interest rates
- no arbitrage
My notes say that the "constant interest rate" assumption implies the following:
$$ f^{T_1}(t) = F^{T_1}(t) $$
I have 2 questions:
- Isn't the above equality wrong due to counterparty risk? That is, we need a "no credit risk" assumption for the above equality to hold.
- Even with "no credit risk" assumption, would the above equality hold?
## Answer by Hamish Gibson (score 1, accepted)
https://quant.stackexchange.com/a/54642
I'll answer your two questions with two answers.
$1.)$ Yes, you are right. The equation you mention in your question would only hold when you make certain assumptions. These come in the form of Illiquidity Risk and Counterparty risk. Because a forward contract is so customised, it can be hard to get out of at a fair price as they are traded OTC. Additionally, it could be cheaper for the counterparty to 'see you in court' rather than actually fulfill the obligation of that contract.
$2.)$ This where the No-arbitrage requirement comes in to play, I'll outline why this is relevant.
There are two ways to procure an asset for date $T$ delivery.
- Buy a future or forward contract with $T$ years to delivery.
- Buy the underlying assset and store for $T$ years.
In order for the no arbitrage requirement to hold, these two methods must equal each other. I'm sure the equation is described in your textbook (if it needs explaining let me know and I'll edit my answer). But the equation has the following symbols
- $S_{0}$: Spot price at time $T_{0}$
- $F_{0}$: Forward price agreed on at time $T_{0}$
- $H_{0}$: Futures price agreed on at time $T_{0}$
- $r$: Risk free rate
- $FV$: Net storage costs
As we could use either a futures or forward contract to fulfilll the requirement, this derives the equation $H_{0} \simeq F_{0} = S_{0}e^{rT} + FV$
Now that I've outlined the equation above and the importance of the no-arbitrage requirement, the emphasis is particularly on the $\simeq$ symbol. The $\simeq$ symbol implies the assumptions made regarding Counterparty risk and Illiquidity risk and hence, they are not properly encapsulated and can only be approximated. For the sake of textbook purposes, it makes these assumptions and does not take this into account. I hope this helps.Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.