Compositional description and valuation of financial contracts

0 comments

file time: 2008-02-16

filetype:ppt

Click Here To Download...

>  
 
 
 
 

Composing contracts 
An adventure in financial engineering 

Simon Peyton Jones and Julian Seward,

Microsoft Research

and

Jean Marc Eber, LexiFi Technologies

 
 
 
 
 

The big picture 

Financial engineering 

Programming language design and implementation 

Jean Marc 

Simon

and

Julian

 
 
 
 
 

The big picture 

Financial engineering 

Programming language design and implementation 

Jean Marc 

Simon

and

Julian 

Swaps, caps, options, european, bermudan, straddle, floors, swaptions, swallows, spreads, futures

 
 
 
 
 

Combinatorlibrary 

Denotational semantics 

Operational semantics

 
 
 
 
 

What we want to do 

Precise description of a contract 

Scheduling for back office 

Valuation and hedging 

Legal and documentation 

etc00  
 
 
 
 

What we want to do 

Precise description of a pudding 

Compute sugar content 

Estimate time to make 

Instructions to make it 

etc00  
 
 
 
 

What we want to do 

Precise description of a pudding 

Compute sugar content 

Estimate time to make 

Instructions to make it 

Bad approach

List all puddings (trifle, lemon upside down pudding, Dutch apple cake, Christmas pudding) For each pudding, write down sugar content, time to make, instructions etc  
 
 
 
 

What we want to do 

Precise description of a pudding 

Compute sugar content 

Estimate time to make 

Instructions to make it 

Good approach

Define a small set of 00b>pudding combinators00/font> Define all puddings in terms of these combinators Calculate sugar content from these combinators too  
 
 
 
 

Creamy fruit salad 

On top of 

Take 

Whipped 

1 pint 

Cream 

Mixture 

Take 

Chopped 

3 

Apples 

Take 

6 

Oranges 

Optional 

Combinators combine small puddings into bigger puddings

 
 
 
 
 

Trees can be written as text 

On top of 

Take 

Whipped 

1 pint 

Cream 

Mixture 

Take 

Chopped 

3 

Apples 

Take 

6 

Oranges 

Optional 

salad  = onTopOf topping main_part

topping  = whipped (take pint cream)

main_part  = mixture apple_part orange_part

apple_part  = chopped (take 3 apple)

orange_part = optional (take 6 oranges) 

Notation:

parent child1 child2 function arg1 arg2  

Slogan: a domain-specific language for describing puddings

 
 
 
 
 

Building a simple contract 

c1 :: Contract

c1 = zcb (date 00 Jan 201000 100 Pounds 

zcb :: Date -> Float -> Currency -> Contract

-- Zero coupon bond 

00eceive 拢100 on 1 Jan 201000/font> 

Combinators will appear in blue boxes

 
 
 
 
 

Combing contracts 

c1,c2,c3 :: Contract

c1 = zcb (date 00 Jan 201000 100 Pounds

c2 = zcb (date 00 Jan 201100 100 Pounds 

c3 = and c1 c2 

and :: Contract -> Contract -> Contract

-- Both c1 and c2 

and 

zcb t1 100 Pounds 

zcb t2 100 Pounds 

c1 

c2 

c3

 
 
 
 
 

Inverting a contract 

and 

zcb t1 100 Pounds 

zcb t2 100 Pounds 

give :: Contract -> Contract

-- Invert role of parties 

c4 = c1 `and` give c2 

give 

c2 

c4 

c1 

and is like addition give is like negation  

Backquotes for infix notation

 
 
 
 
 

New combinators from old 

andGive :: Contract -> Contract -> Contract

andGive u1 u2 = u1 `and` give u2 

andGive is a new combinator, defined in terms of simpler combinators To the 00ser00 andGive is no different to a primitive, built-in combinator This is the key to extensibility: users can write their own libraries of combinators to extend the built-in ones  
 
 
 
 

Defining zcb 

Indeed, zcb is not primitive: 

zcb :: Date -> Float -> Currency -> Contract

zcb t f k = at t (scaleK f (one k)) 

one :: Currency -> Contract

-- Receive one unit of currency immediately 

scaleK :: Float -> Contract -> Contract

-- Acquire specified number of contracts 

at :: Date -> Contract -> Contract

-- Acquire the contract at specified date

 
 
 
 
 

Acquisition dates 

one :: Currency -> Contract

-- Receive one unit of currency immediately 

at :: Date -> Contract -> Contract

-- Acquire the underlying contract at specified date 

If you acquire the contract (one k), you receive one unit of currency k immediately If you acquire the contract (at t u) at time s<t, then you acquire the contract u at the (later) time t. You cannot acquire (at t u) after t. The latest acquisition date of a contract is its horizon.  
 
 
 
 

Choice 

An option gives the flexibility to

Choose which contract to acquire (or, as a special case, whether to acquire a contract) Choose when to acquire a contract 
(exercising the option = acquiring the underlying contract)  
 
 
 
 

Choose which 

or :: Contract -> Contract -> Contract

-- Acquire either c1 or c2 immediately 

zero :: Contract

-- A worthless contract 

european :: Date -> Contract -> Contract

european t u = at t (u `or` zero) 

European option: at a particular date you may choose to acquire an 00nderlying00contract, or to decline  
 
 
 
 

Reminder00/font> 

Remember that the underlying contract is arbitrary 

c5 :: Contract

c5 = european t1 (european t2 c1) 

This is already beyond what current systems can handle

 
 
 
 
 

Choose when: American options 

anytime :: Contract -> Contract

-- Acquire the underlying contract at

-- any time before it expires (but

-- you must acquire it) 

The option to acquire 10 Microsoft shares, for $100, anytime between t1 and t2 years from now  

golden_handcuff = anytime shares 

shares = zero `or` (scaleK -100 (one Dollar) `and`

             scaleK 10 (one MSShare)) 

anytime: Choose when 

MS shares are a 00urrency00/font> 

or: Choose whether

 
 
 
 
 

Setting the window 

golden_handcuff = at t1 (anytime (truncate t2 shares)) 

truncate :: Date -> Contract -> Contract

-- Truncate the horizon of a contract 

at :: Date -> Contract -> Contract

-- Acquire the underlying contract at specified date 

Can00 acquire shares after t2 

Acquire the anytime rights at t1

 
 
 
 
 

Observables 

Pay me $1000 * (the number of inches of snow - 10) on 1 Jan 2002 

c :: Contract

c = at 00 Jan 200200(scale scale_factor (one Dollar)) 

scale_factor :: Observable

scale_factor = 1000 * (snow - 10) 

scale :: Observable -> Contract -> Contract

-- Scale the contract by the value of the observable

-- at the moment of acquisition 

snow :: Observable

(*), (-) :: Observable -> Observable -> Observable

 
 
 
 
 

Summary so far 

Only 10 combinators (after many, many design iterations) Each combinator does one thing Can be combined to describe a rich variety of contracts Surprisingly elegant  
 
 
 
 

But what does it all mean? 

We need an absolutely precise specification of what the combinators mean: their semantics And we would like to do something useful with our (now precisely described) contracts One very useful thing is to compute a contract00 value  
 
 
 
 

Processing puddings 

Wanted: S(P), the sugar content of pudding P  

S(onTopOf p1 p2)  = S(p1) + S(p2)

S(whipped p)  = S(p)

S(take q i) = q * S(i)

00tc00/font> 

When we define a new recipe, we can calculate its sugar content with no further work Only if we add new combinators or new ingredients do we need to enhance S  
 
 
 
 

Processing puddings 

Wanted: S(P), the sugar content of pudding P  

S(onTopOf p1 p2)  = S(p1) + S(p2)

S(whipped p)  = S(p)

S(take q i) = q * S(i)

00tc00/font> 

S is compositional

To compute S for a compound pudding,

Compute S for the sub-puddings Combine the results in some combinator-dependent way  
 
 
 
 

What is the denotation of a contract? 

The denotation of a program is a mathematical value that embodies what the program 00eans00/font> Two programs are equivalent if they have the same denotation A denotational semantics should be compositional: the denotation of (P1 + P2) is gotten by combining somehow the denotations of P1 and P2  
 
 
 
 

What is the denotation of a contract? 

Main idea: the denotation of a contract is a random process that models the value of acquiring the contract at that moment. 

00/b> : Contract -> RandomProcess

RandomProcess = Time -> RandomVariable 

Uncertainty increases with time 

Time

 
 
 
 
 

Compositional valuation 

00/b>(c1 `and` c2)  = 00/b> (c1) + 00/b> (c2)

00/b>(c1 `or` c2) = max(00/b>(c1), 00/b>(c2) )

00/b>(give c) = - 00/b> (c)

00/b>(anytime c) = snell( 00/b>(c) )

00/b>(at t c) = discount( 00/b>(c)[t] )

00tc00/font> 

This is a major payoff!  Deal with the 10-ish combinators, and we are done with valuation!  

Add random processes point-wise

 
 
 
 
 

Valuation 

There are many numerical methods to compute discrete approximations to random processes (tons and tons and tons and tons and tons and tons and tons and tons and tons and tons of existing work)  

Contract 

Model of world  
(e.g. interest rates) 

Valuation engine

 
 
 
 
 

One possible evaluation model: BDT 

contract C 

5% 

6% 

4% 

zcb 3 100 Pounds 

interest rate model M 

100 

100 

95 

Value tree 00/b>(C) 

Valuation engine 

100 

100 

0 

1 

2 

3

 
 
 
 
 

Space and time 

Obvious implementation computes the value tree for each sub-contract But these value trees can get BIG And often, parts of them are not needed  

at t 

t 

simple discounting

 
 
 
 
 

Haskell to the rescue 

00azy evaluation00means that

data structures are computed incrementally, as they are needed (so the trees never exist in memory all at once) parts that are never needed are never computed  

Slogan

We think of the tree as a first class value 00ll at once00/font>

but it is only materialised 00iecemeal00/font>

 
 
 
 
 

An operational semantics 

As time goes on, a contract evolves

e.g. zcb t1 n k `and` zcb t2 n k

Want to value your current contract 00ook00/font> So we want to say formally how a contract, or group of contract evolves with time, and how it interacts with its environment (e.g. emit cash, make choice) Work on the operational semantics of programming languages is directly relevant (e.g. bisimulation)  
 
 
 
 

Reasoning about equivalence 

Using this semantics we can prove (for example) that  
 anytime (anytime c) = anytime c  
Depends on algebra of random processes (snell, discount, etc). Bring on the mathematicians!  
 
 
 
 

A compiler for contracts 

Contract 

Take semantics 

Random process 

Transform using algebraic laws 

Code generation 

Valuation program

 
 
 
 
 

A compiler for contracts 

Contract 

Take semantics 

Random process 

Code generation 

Valuation program 

Evolve using operational semantics

 
 
 
 
 

Summary 

A small set of built-in combinators: named and tamed A user-extensible library defines the zoo of contracts Compositional denotational semantics, leads directly to modular valuation algorithms Risk Magazine Software Product of the Year Prize Jean-Marc has started a company, LexiFi, to commercialise the ideas  

Routine for us, radical stuff for financial engineers

 
 
 
 
 

Summary 

A small set of built-in combinators: named and tamed A user-extensible library defines the zoo of contracts Compositional denotational semantics, leads directly to modular valuation algorithms Risk Magazine Software Product of the Year Prize Jean-Marc has started a company, LexiFi, to commercialise the ideas Beats higher order logic hands down for party conversation  

Routine for us, radical stuff for financial engineers

   download Compositional description and valuation of financial contracts