Pricing-orientated payoff computer languages form the vast majority of existing financial product language implementations, but they face serious limitations for valuing structured products on past, present, and future dates. A new class of context-neutral contract computer languages offers key properties to overcome the challenges of time travel.
Consider the following situations:
* A salesman simulates the value of a proposed transaction,
six months from today, to verify that the customer's
investment guidelines are satisfied.
* A trader calculates the month-to-date P&L on a portfolio
of structured products.
* A risk manager calculates six-month value at risk on the
same portfolio of structured products.
The Challenges Of Time Travel
1. The salesman may first attempt to move the valuation date forward and ignore intermediate paths followed by the contract's underlying variables between today's date and the future valuation date, as illustrated in the new contract example below. There are many instances, however, in which intermediate paths cannot be ignored:
* The contract may be undefined on the future date, and
therefore impossible to value, without prior knowledge of
all intermediate fixings.
* In addition, certain metrics require the knowledge of
intermediate fixings. If the investor's constraint is related to
a potential loss on the proposed transaction, the salesman
must calculate the contract's fair value at inception and in
six months, and the value of all intermediate cash flows
reinvested (or funded) until the future date, according to a
predefined financing policy.
In such cases, the analyst needs to simulate all intermediate paths--as illustrated opposite, in the existing contract example, in the segment located to the right of the current date and value the contract on the future date for each simulated path.
Contract Valuation On Past, Present & Future Dates
The need to simulate intermediate paths raises additional issues. The salesman must monitor potential barrier crossings continuously. The handling of options with automatic exercise potentially necessitates full pricing capabilities along the path. Options with discretionary exercise require additional assumptions about the option holder's behavior.
2. Contrary to the salesman, the trader only looks back in time. Traders need to (i) describe the contract at the end of the previous month and on the current date, taking into account realized events in both cases, (ii) record intermediate cash flows between the past and the current date, and (iii) define a financing strategy to calculate the portfolio's funding costs since the end of the previous month.
3. The risk manager needs to represent the contract in its current state and deal with the difficulties of calculating the change in value in the future.
To summarize, a time-travel machine for structured products must include the following features:
* Contract representation. Accurately specify the most
complicated contracts.
* Scenarios. Define forward-looking market scenarios.
* Pricing. Value contracts at any point in their life cycle.
* Contract execution. Define rules that describe how contracts
evolve along realized or simulated scenarios and correctly
represent contracts in each past, current, and future state.
* Trading strategies. Define a financing policy and calculate
corresponding costs.
Payoff Language Vs. Contract Language
Programming languages provide the flexibility needed to describe the great diversity of terms and conditions that characterize structured products. In the past decade, many derivatives desks have developed payoff languages that define a product's meaning in the context of pricing.
Contract languages describe what contracts are, as opposed to merely what they do, and the resulting specification may serve as the basis for pricing, simulation, back-office management, and other processes, with the guarantee that the behavior across these environments will be consistent. In a contract language, the essence of financial products is described independently from the processes that may be applied to them: contract definitions represent data that numerous external programs may analyze and translate into equivalent definitions, adapted to users' processing needs. The original product representation is preserved and remains independent from process-specific translations. A contract definition may be translated into a payoff description, but the opposite is not true.
We believe that payoff languages are well suited for the limited task of valuing a new transaction today, while contract languages greatly simplify the task of analyzing both new and existing transactions on past, present, and future dates, where applicable.
The greatest challenge faced by payoff language implementers is to represent the evolving structure of a contract. Payoff language developers have two options:
* Maintain an external historical scenario. The information
about realized fixings is not stored with the payoff's definition
but maintained externally in a historical scenario. The approach
presents two potential problems. First, it is not likely to satisfy
the requirements of the back office because fixing information is
specific to a contract and sometimes
differs from the official rates. Second,
discretionary events, such as the early
exercise of Bermudan and American
options, cannot be inferred from the
historical scenario. As a result, payoffs
are redefined manually after each
discretionary exercise decision.
* Annotate the contract with its event
history. The other option is to annotate payoff definitions.
Annotations include information about past fixings, exercise
decisions, barrier crossings, etc. With structured products,
such annotations can become complicated.
A contract language operates differently: a precise, process-independent contract definition is first written to describe the contract's essence and then translated, for example, to meet the user's valuation needs. As new event information becomes available, a new, simplified contract is created and translated again to produce processing code that mirrors the contract's new state.
Payoff languages present several limitations for time travel:
* Inefficient pricing. Whether historical fixing information is
stored externally or as an annotation of the payoff's definition,
the contract's history must be replayed for each Monte-Carlo
path until the valuation date is reached. 100,000 Monte-Carlo
simulations imply 100,000 runs with the same historical
scenario. In addition, a payoff language is unlikely to reflect a
decrease in the number of underlyings as the contract ages, a
common feature in structured equity derivatives. In contrast, a
contract language generates pricing code dynamically as
contracts transition from state to state and eliminates
redundant Monte-Carlo trajectories for both historical
scenarios and irrelevant underlyings.
* Limited flexibility to change models, numerical methods
and contract execution rules. Payoff languages do not
decouple contract definitions and processes and therefore
offer limited flexibility to accommodate changes in models,
numerical implementations and contract execution rules. In
contrast, contract languages introduce information about
custom pricing algorithms in model definitions instead of
contract definitions: they facilitate the concurrent
deployment of simple models, typically used for risk
management and more sophisticated models, used for
pricing. Contract languages also enable the simulation of
multiple contract execution rules--for example, methods
for handling Bermudan and American options in a
simulation--without any change to the original contract
definition, whereas payoff languages would require a
separate definition for each contract execution rule.
* Market conventions in pricing code.
Payoff languages mix product
definitions and pricing specifications.
With a contract language, all market
conventions are resolved in the
contract's definition. Model
implementers can focus exclusively
on the mathematics of valuation.
* No back office reconciliation. Payoffs
are defined from inception to generate a series of numerical
calculation steps: they do not distinguish physically-settled and
cash-settled options or automatic and discretionary option
exercises. In addition, payoff languages often do not explicitly
describe multi-currency products: users specify an amount and
an exchange rate instead of a foreign currency amount. The loss
of information resulting from the use of pricing-orientated
payoff languages precludes any reconciliation with a
corresponding product representation in the back office. A
context-neutral representation is required for this task.
* Cumbersome event planning. Future contract life cycle
events are easier to detect with a contract language than
with a payoff language. A payoff definition contains
pricing-orientated code as opposed to data. Payoff code does
not lend itself to introspection: a comprehensive list of
future events can be difficult, if not impossible, to extract.
* Risk of double counting. Payoff language programmers
must be careful to exclude cash flows that hit the cash
balance from pricing. Contract languages eliminate this
important source of programming errors by generating
valuation code that exactly mirrors the state of each contract.
Derivatives users should favor contract languages over payoff languages for safe and efficient time travel.
This week's Learning Curve was written by Jean-Marc Eber, ceo of LexiFi in Paris. An expanded version of this article is available from the author at jeanmarc.eber@lexifi.com.
