Describing, manipulating and pricing financial contracts: The MLFi language

Transcription

1 Describing, manipulating and pricing financial contracts: The MLFi language Centre for Financial Research, Judge Institute of Management Cambridge, 14 March 2003 (revised January 2005) Jean-Marc Eber LexiFi, Paris

2 Agenda The problem Goals An algebra of contracts and observables (simplified) Reasoning about contracts Managing contracts Fixings, exercise decisions Pricing contracts Stochastic process algebra Model capabilities, model implementations

3 The problem: Front-office vs back-office statements What is a Euribor 3M contract? Front-office, Quant answer: This is a forward contract. By simple arguments, it can be shown that this depends only on the price of two ZC bonds P (t, T 1 ) and P (t, T 2 ). It is therefore an (adapted) stochastic process, function of these two former processes... The maths are beautiful... For the institutional details, ask the back-office guys... Back-office answer: This is a number that is officially published on each trading day at... pm, and is available on.... Many contracts are written on it and we must track these fixings... For the maths, ask the front-office guys...

4 Some remarks about these two answers The question was: what is a... contract? The quant s answer: how to calculate its price Contract = definition of the price process as a function of simpler elements (the ZC Bonds) The back-office s answer: where to find its quote Contract = time series of daily quotes Nobody answered the question properly: give the correct definition of this forward contract! The MLFi technology aims at reconciliating these two diverging approaches...

5 Goals Allow for an exhaustive and sufficiently precise definition of (bilateral) financial contracts Financial contract specification language Systematically derive pricing and operational management from the contract s definition This derivation should itself be mathematically rigorous In particular, contract definitions should be independent from the pricing mechanism Implies the existence of a valuation model that does not depend on the contract s definition Reasoning about contracts. Is it possible, for instance, to simplify them?

6 Part I: The MLFi specification language in 20 minutes Peculiarities of the finance domain Contract and observable combinators (simplified) A compositional contract algebra: contract definitions as values Algebraic contract transformations, normal form, sharing Time-related contract analysis and simplifications From a few combinators to a whole language Market conventions, industry-specific contract libraries

7 The importance of time Time plays a crucial role: All financial contracts are strongly time-related There is a natural total order on time # let t1 = T16:00 (* ISO 8601 notation *) ;; val t1 : date = T16:00:00 # let t2 = t1 +days 20 ;; val t2 : date = T16:00:00 # t1 < t2 (* t2 is clearly later than t1 *);; - : bool = true Time (values of type date) is a built-in feature of MLFi and largely exploited for checking time consistency of contract definitions (more about that later)

8 Important facts about contract definitions A contract is defined, but......the economic consequences for its holder depend on when the contract was acquired (acquisition date): think just about a bond bought years after its issue date All elementary definition blocks will therefore be parametrised by the acquisition date Most of the time, observables are values that are unknown when the contract is being defined and are observed (fixed) later by means of an agreed-upon procedure Contracts are written on such observables Observables may have different types (float for an index, bool for a default event)

9 We present a minimalistic set of contract combinators: In real life, there will be more of them, but the principles can be explained in a limited amount of time with a subset of them!

10 Precise contract combinators val zero : contract (** [zero] is a contract that, when acquired, carries no right or obligation. *) val one : currency -> contract (** Unitary currency payout. [one k] is a contract that, when acquired, pays immediately the holder one unit of the currency [k]. *) val ( and ) : contract -> contract -> contract (** Simultaneous immediate acquisition of two contracts. To acquire [c1 and c2] is the same as acquiring [c1] and [c2]. You acquire the rights and obligations of both contracts. *)

11 val either : (string * contract) list -> contract (** Choice among many contracts. To acquire [either [(s1,c1); (s2,c2);... (si,ci);... (sn,cn)]] means having the obligation to acquire exactly one of the [ci]s immediately. The necessarily different [si]s are used for managing the contract. They provide a unique identifier for each possible choice. *) val ( or ) : (string * contract) -> (string * contract) -> contract (** Binary short notation for the [either] operator: [(s1, c1) or (s2, c2)] is equivalent to [either[(s1, c1); (s2, c2)]]. *) val scale : float observable -> contract -> contract (** Scaling a contract by an observable. If you acquire [scale o c], then you acquire [c] at the same moment, except that all of [c] s payments are multiplied by the value of the observable [o] at the moment of acquisition. *)

12 val acquire : bool observable -> contract -> contract (** Forced acquisition at entry in a region. [acquire r c] means that you must acquire [c] as soon as region [r] becomes [true]. Note the particular case [acquire {[t]} c], where [t] is a date: Because [{[t]}] denotes the trivial region that is [true] at date [t] and [false] everywhere else, acquiring [acquire {[t]} c] means acquiring [c] at [t]. *) We will only use the simplest form: acquire {[t]} c, meaning that you acquire contract c at date t.

13 Precise observable combinators Observables may be constant. ~ is a convenient notation for constant observables: # let cst obs = 150.~ ;; val cst obs : float observable = 150.~ Functions of observables are again observables:... val ( +.~ ) : float observable -> float observable -> float observable val ( -.~ ) : float observable -> float observable -> float observable val ( *.~ ) : float observable -> float observable -> float observable val ( /.~ ) : float observable -> float observable -> float observable... # let another obs = cst obs +.~ 12.~ ;; val another obs : float observable = 162.~

14 Time is observable: val time : date observable (** Time observable. [time] is the [date] observable having, at each date {t}, value {t}. *) Observables may be annotated with a market (management) identifier val market : string -> c observable -> c observable (** Named Market Observable. Observables may be used both in contact management and in pricing. A label ([id]) is given to the observable to enable contract management. The [id] label is used in all contract management operations, for example, to record fixings. The label is ignored in {pricing}: [market id o] is the same as observable [o], which serves as the pricing model s underlying variable. *)

15 A contract algebra: contract definitions as values We are used to manipulating, say, numbers and strings: # let r1 = # let r2 = "Happy" ^ " " ^ "in Cambridge" # let r3 = r1 + String.length r2 ;; val r1 : int = 17 val r2 : string = "Happy in Cambridge" val r3 : int = 35 But we can do the same kind of manipulation with contract definitions: # let c1 = one EUR # let c2 = one GBP # let c3 = c1 and c2 ;; val c1 : contract = one EUR val c2 : contract = one GBP val c3 : contract = (one EUR) and (one GBP)

16 Simple contract definition We want to specify the following contract: One has the right, on , to choose between receiving USD on , or receiving GBP on (kind of European FX-option). That s easy...

17 # let usd payment = acquire {[ ]} (scale ~ (one USD)) ;; val usd payment : contract = simple flow USD ~ # let gbp payment = acquire {[ ]} (scale ~ (one GBP)) ;; val gbp payment : contract = simple flow GBP ~ # let choice = ("first", usd payment) or ("second", gbp payment) ;; val choice : contract = ("first", simple flow USD ~) or ("second", simple flow GBP ~)

18 # let option = acquire {[ ]} choice ;; val option : contract = acquire {[ ]} (("first", simple flow USD ~) or ("second", simple flow GBP ~)) From understanding only precisely what the basic combinators (acquire, one, or,...) mean, you derive the meaning of this contract That s the idea of algebraic expressions (like (x + y)) and MLFi is doing the same for contracts! It s important to understand carefully how the acquire primitive is organizing the time-related decision and payment structure of our example contract

19 Time-related structure verification The MLFi compiler checks the coherence of a contract s time-related structure Let s return to our previous example and change it so that the option s maturity falls after the underlying payment dates: # choice;; - : contract = ("first", simple flow USD ~) or ("second", simple flow GBP ~) # let option = acquire {[ ]} choice ;; Exception: Mlfi contract.acquire incompatible horizons ( , ).

20 Algebraic contract simplifications The MLFi compiler tries to simplify contract descriptions, and to share commonalities between contract sub-parts: # let c1 = (scale 1.~ (one EUR)) and zero ;; val c1 : contract = one EUR # let c2 = ("first", (scale 3.~ ((one EUR) and (one GBP)))) or # ("second", (scale 5.~ ((one GBP) and (one EUR)))) ;; val c2 : contract = (let c3 = (one EUR) and (one GBP) in ("first", scale 3.~ c3) or ("second", scale 5.~ c3)) The system tries to represent contracts in a normalized way......but, for now, the MLFi compiler only performs simplifications that are compatible with the back-office

21 Time-related contract simplifications Time-related structure simplifications are less trivial, as they analyse a contract definition along its potential evolution through time # let c1 = gbp payment ;; val c1 : contract = simple flow GBP ~ # let c2 = acquire {[ ]} c1 ;; val c2 : contract = acquire {[ ]} (simple flow GBP ~) # normalize c2 ;; - : contract = simple flow GBP ~ The normalize function is unable to make an initial assumption about the acquisition date of its contract argument. It can only assume that the contract is acquired on an admissible date. Realistic contracts generally begin with an acquire {[...]} construct anyway, which precisely defines the beginning of the contract

22 Important to remind: some simplifications apply to contracts, others to acquired contracts!

23 From contract combinators to a contract description language We typically write functions that manipulate numbers: # let f x y z = x * (y + z) ;; val f : int -> int -> int -> int = <fun> And we can then use this function: # let r = f ;; val r : int = 16 We can do the same for contracts:

24 # let scale and o con1 con2 = scale o (con1 and con2) ;; val scale and : float observable -> contract -> contract -> contract = <fun> And use this function: # let r = scale and ~ c1 c2 ;; val r : contract = scale ~ ((one EUR) and (let c5 = (one EUR) and (one GBP) in ("first", scale 3.~ c5) or ("second", scale 5.~ c5))) There is nothing new here: all this machinery is just an easy way of easily combining contracts from simpler ones (or elementary ones)

25 Let s write a function taking as input a list of (date, float) pairs and returning the contract paying all of these amounts (in, say, GBP): # let rec gbp pays = function # [] -> zero # (t, amount) :: rest -> # (gbp pays rest) and # (acquire {[t]} # (scale (obs of float amount) (one GBP))) ;; val gbp pays : (date * float) list -> contract = <fun> and use it: # let r = gbp pays # [( , 120.); ( , 110.); ( , 150.)] ;; val r : contract = ((simple flow GBP 150.~) and (simple flow GBP 110.~)) and (simple flow GBP 120.~)

26 Product libraries, market conventions All this machinery is the basis for building realistic and complete libraries of schedule manipulations, market conventions and contract definitions: type is_business_day = date -> bool (** Returns [true] if the argument is a business day, [false] otherwise instrument cashflow : amount * date -> contract (** Acquire [amount] at date [date]. *)... val callput : callput -> contract -> amount -> period -> contract (** [callput callputflag c strike (dbegin, dend)] is the right to buy ([callputflag = Call]) or sell ([callputflag = Put]) contract [c] against payment of [strike] in time interval ([dbegin], [dend])... *)...

27 val bermudacallput : callput -> contract -> (date * amount) list -> contract (** [bermudacallput callputflag c rule]: right to buy [callputflag=call] or sell [callputflag=put] contract [c] at dates and prices specified by schedule [rule] consisting of (date, strike) pairs with increasing dates. *)... val adj_raw_schedule : raw_schedule -> is_business_day -> business_day_convention -> raw_schedule (** Returns an adjusted schedule from a given schedule by imposing the application of the business day and business day convention arguments. *)

28 Part II: Managing contracts With a good understanding of our contract combinators, we want to manage a contract over time. For exercise decisions for instance, we generalise the intuitive idea that a contract of the form (l1, c1) or (l2, c2) should reduce to c1 if: I acquired this contract, and I choose the c1 branch (by specifying label l1) Fixings are treated similarly, by replacing the unknown observable identifier by its value in the contract s definition It is fundamental to understand that such a transition returns a modified contract that represents the new rights and obligations of the holder!

29 Contract management theory: operational semantics Φ < t, acquire t c > < t, S[c] > (SimplAcquire) o konst(x) Φ < t, scale o c > < t, S[scale konst(obs t (o)) c] > (ScaleF reeze) [.,ls,t R q k] Φ < t, c > < t, c > [.,ls,t R x q k] Φ < t, scale konst(x) c > < t, S[scale konst(x) c ] > (ScaleQuant) Φ < t, c1 > e1 < t1, c1 > Φ < t, c2 > e2 < t2, c2 > Φ < t, c1 and c2 > e1 < t1, S[c1 and c2] > t1 t2 (AndLef t) Φ < t, c1 or c2 > [.,Long,XL] < t, S[c1] > (OrLef t)

30 Manage the contract For simplicity, we assume the existence of the function: val manage : contract -> manage step -> contract * managed step = <fun> manage step can represent fixings, exercise decisions, time related events, barrier crossings Remember our FX option: # option ;; - : contract = acquire {[ ]} (("first", simple flow USD ~) or ("second", simple flow GBP ~))

31 Now let s manage this contract. We first indicate an exercise decision (here the left choice available): # let after choice, step = # manage option (Mgt event( , ("", Ev exer "first"))) ;; val after choice : contract = simple flow USD ~ val step : managed step = Step event ( , ("", Ev exer "first")) Note that attempting to apply a wrong event (we are specifying an exercise date that is incompatible with the contract) results in an error: # let after choice, step = # manage option (Mgt event( , ("", Ev exer "first"))) ;; Exception: Mlfi contract.irrelevant event ( , ("", Ev exer "first")).

32 We now move the clock forward so that any due payment can be processed: # let (after pay, step) = # manage after choice (Mgt exec( )) ;; val after pay : contract = zero val step : managed step = Step exec ( , [({t acquired = ; t q = ; t treenode = ""; t given = false}, Transfer (USD, "", {flow class = Fc simple; aggregation class = 0}))]) We may also ask the system to list pending events. Let s query our initial FX option:

33 # let option calendar = calendar max int option ;; val option calendar : calendar = {pendings = [({acquired = {[ ]}; hyps = []; q = 1.~; treenode = ""; given = false}, Pending exer ["first"; "second"])]; actions = [({acquired = {[ ]}; hyps = [Hyp exer ("second", {acquired = {[ ]}; hyps = []; q = 1.~; treenode = ""; given = false})]; q = ~; treenode = ""; given = false}, Transfer (GBP, "", {flow class = Fc simple; aggregation class = 0})); ({acquired = {[ ]}; hyps = [Hyp exer ("first", {acquired = {[ ]}; hyps = []; q = 1.~; treenode = "";

34 given = false})]; q = ~; treenode = ""; given = false}, Transfer (USD, "", {flow class = Fc simple; aggregation class = 0}))]}

35 The former result shows that the argument contract has an embedded option (Pending exer in the pendings list), giving all necessary information (especially the option s maturity, here ) Forthcoming payments are identified in the actions part and clearly identified as hypothetical (their existence depends on the previous exercise decision) because their hypotheses sets (hyps) are not empty and describe precisely the decision that must be taken for the payment to occur This feature provides a powerful way of checking properties for any contract described in MLFi. For instance: A firm contract is simply defined as having no Pending exer in his pendings list Similarly, one can easily check that a given contract consists only of simple cash flows by checking that the actions part contains only Transfers with empty hyps sets

36 Part III: Pricing Pricer = f (contract, model) We define the notion of a model capabilities: What currency(ies) and underlyings (observables) does the model support? What closed forms does the model support? Closed form definitions are part of the model, not the contract! Information about the model s geometry: PDE, Monte Carlo, etc. We generate a process expression, an abstract representation of the price (stochastic) process corresponding to the contract Potential closed forms are resolved at this stage More simplifications are applied on this expression The process expression is then used to generate source code that will be linked with low level model primitives