Part 3 in the Financial Architecture series tacked the index concept, explaining the distinction between the definition of the value (the index concept) and the value itself. This post will further examine this topic, and explain how the index concept relates to complex payoffs.
Derivative contracts often oblige parties to make payments that depend on a collection of underlyings in complex ways. For example, a contract might instruct that a payment is made on some date 
whose amount is given by
- the greater of zero and the Total Capped Return as observed on date
, - where the Total Capped Return is the smaller of 20% and the Combined Capped Return,
- where the Combined Capped Return is the sum of the Capped Return for each of three stocks,
, 
, and 
, - where the Capped Return for stock
is defined as the smaller of 10% and the difference between the ratio of the value of stock 
on some date 
to that on date 
, and one.
This style is typically found in term sheets, but with more legal rigor, omitted here for clarity. Increasingly, often mathematical notation is used directly in term sheets, which results in a more compact expression of the information content, as follows
where
for some underlying 
. Our concern is the efficient encoding of this formation for use in derivative valuation platforms. The key observation is that, if 
is an Index that holds the definition of the value of shares in company 
, then 
also meets the requirements of being an Index. The introduction of mathematical or computational operations or functions (which are certainly well-defined and unambiguous) such as arithmetic, logic, or calculations such as max and min, results in the definition of a quantity that is just as well-defined and unambiguous as the formula’s inputs, and therefore is just as capable of being written into a financial derivative contract.
Although the expression above may seem complex, the number of distinct operations which are used to express payoffs is not large. There is a fundamental set which can accommodate virtually any payoff. This set includes the following constructs:
- Arithmetic operators +, -, * and /
- Boolean operators , >, =, >=, and, or and not()
- Conditionals; if(Condition,Left,Right), evaluates to Left if Condition is true, otherwise Right, where Condition is a Boolean-valued Index
- The min and max functions, together with other special functions such as logarithms.
These are all low-level constructs; they are fundamental operations from which others may be composed. For example, we could synthesize a new payoff called call via call
for some strike k and underlying X. This is of course just a European call option payoff.
Similarly, other higher-level Indices may be constructed, such as an Index whose value is the fraction of time that a condition is met during an interval of time (which would cover all range accrual payoffs) or an Index which indicates whether some underlying Index breached a barrier or set of barriers.
When encoding payoffs in a derivatives valuation platform, it is most convenient to construct a language in which payoffs may be expressed. Such a language should contain all of the above fundamental constructs, but there are two distinct advantages to including higher-level expressions also. The first is operational efficiency; high-level expression of intent is desirable in any programming language, because it enables a concise expression of the programmer’s instructions, which in turn results in code that is cheaper to maintain. The second is more subtle. By retaining the concept of “barrier” or “range accrual” or similar, instead of expressing the equivalent payoff calculation in terms of fundamental operations, it is far easier to optimize the calculation of such payoffs with bespoke algorithms or approximations. Without retaining such concepts, we would be forced into a challenging pattern recognition exercise within the calculation tree.
Together with the Product concept, in principle we now have all we need to express any derivative contract! It's all very low-level though, so in my next post I'll define some higher-level Product types, all still Products, but with some specific structural features that makes expressing common derivatives convenient.
