Contract description language

MLFi: the Modeling Language for Finance

LexiFi has created the world's only formal description of financial contracts* to enable the industry to manage financial product diversity. LexiFi's uniform and platform-independent contract representation approach radically simplifies the development of sales support, trading, risk management and processing applications for cash and derivative products.

Unlike other financial contract modeling approaches, LexiFi's award-winning formalism supports both pricing and operational management. LexiFi's ingenious pricing framework is designed to link contract definitions with in-house, third-party, and LexiFi valuation engines; to facilitate the development of risk analyses; and to reuse calculation platforms while benefiting from a unique contract description. LexiFi's robust operational management framework enables the systematic detection and processing of contract events.

(*) A formal description of financial contracts enables the creation of product definitions that can be read by a human being and processed by a computer, and that satisfy at least six goals: (i) describe the rights and obligations of the parties both precisely and exhaustively; (ii) support any type or combination of underlying asset(s); (iii) be "portable" so that stakeholders can exchange them; (iv) lend themselves to manipulations of all sorts, for example, for the purpose of pricing a contract, estimating its market and credit risks, or managing its clauses; (v) adapt automatically in response to life cycle events; and (vi) do not depend on a technical environment - e.g., a programming language or paradigm.

Theoretical foundation

The theoretical foundation for MLFi results from a joint effort over many years between LexiFi and leading researchers in computer science. This award-winning work draws insights from the study of programming language theory to provide a clear and homogeneous framework for representing financial instruments.

The main results include:

• A set of about twenty basic combinators or "primitives" that capture the essence of financial contracts in order to both describe and process such contracts. The contract description is independent of any contract manipulation or valuation method.
• An operational semantics designed to describe precisely how a contract evolves in its life cycle. A behavioural equivalence relationship enables the manipulation, transformation, and simplification of contracts as they evolve over time.
• A valuation semantics that, for each contract, enables the creation of a program that associates a contract description and a model specification in order to automatically generate specialised pricing code. The semantics is compositional: this crucial property means that the value of a compound contract is given by the values of its components.

The MLFi technology has been described in academic papers and in a book. You can find more information about it in our white papers and presentations.

With MLFi, it suffices to understand a small set of core constructs in order to design complex contracts. Analogously, in algebra, the expression "(1 + 2) x (3 + 4)" is easy to understand because we know what a number is, and we understand the meaning of algebraic operators. MLFi does exactly the same thing with financial contracts, with elementary MLFi contracts replacing numbers and MLFi combinators replacing algebraic operators. Expressions that contain elementary contracts and combinators are also contracts, which may in turn be further combined with other contracts to create increasingly higher-level building blocks for designing financial products.

A key benefit of compositional semantics is that one can explore and manipulate "passive" data. For example, MLFi's contract definitions—the data—lend themselves to automated processing of various sorts, including pricing and event management. A single program may manipulate all data elements, without exception. This property has a parallel in algebra: in the same way one can apply a process to any algebraic expression—e.g., calculate the value, count the number of symbols—MLFi can apply a process to any contract.

In summary, MLFi's crucial property is that sophisticated contracts are assembled from a small set of simple, orthogonal constructs that processes know how to manipulate, regardless of the contract's complexity. The consequence is that processes do not need to be reprogrammed as new financial instruments are added.

The same principles are applied to define market scenarios, which may be derived from one or more other scenarios using a limited set of scenario composition operators.

What is the difference between FpML, pricing-orientated payoff languages, and MLFi?

Semantics

The main technical difference between FpML, pricing-oriented payoff languages, and MLFi lies in their semantics—or lack thereof.

FpML

While FpML brings structure in descriptions of financial contracts, as opposed to a "flat" collection of (name, value) pairs, FpML lacks semantics: the "meaning(s)" of a contract cannot be determined by simply looking at an FpML product definition. One needs an associated text such as ISDA definitions to fully understand an FpML contract specification and to be able to specify its behaviour in the context of valuation or operational management.

Object-oriented models that implement FpML attempt to bridge the semantics gap but have two inherent limitations: they are very difficult to design and, most importantly, the resulting model is not compositional.

FpML describes contract types and lists the parameters needed to describe each contract category. FpML therefore obeys a standards logic that relies on a menu of contracts. While the menu attempts to be exhaustive, it ultimately cannot be.

Because it is not compositional, FpML focuses on interbank contracts and does not support complex, client-driven transactions.

Payoff Languages

Payoff languages define a product's meaning in the context of pricing. For example, in a Monte Carlo pricing context, a product is a program—a "machine"—that takes a simulated market scenario as input and returns the list of cash flows induced by the scenario, on the correct dates. Products are mapped from inception into the world of valuation algorithms: cash flows, options, and other potential events are expressed in a way that is understandable by the stochastic machinery used to value financial contracts. This mapping implies a loss of information: for example, a payoff language will not distinguish between a cash-settled option and a physically-settled option, or between an option that is exercised automatically if it expires in-the-money and one that is exercised only at the discretion of one party.

A contract described with a payoff language is a program that can only do one thing—be executed—in order to describe the contract's behavior in the single context of pricing.

MLFi

MLFi describes what contracts "are" independently from what they "do," and the resulting specification is used to derive pricing, simulation, back office management, and other processing capabilities, with the guarantee that the behaviour across these environments is consistent.

MLFi precisely and exhaustively describes financial products, independently from the processes that may be applied to them: contract definitions represent "data" that numerous programs can analyse and translate into equivalent definitions. The original product representation is preserved and remains independent from process-specific translations.

The "data" is specified with about twenty basic combinators or "primitives" and processes are described by their action on each primitive. Consequently, programs that manipulate data are relatively easy to write and adapt mechanically to any contract. MLFi's semantics is compositional: it suffices to understand a small set of core constructs in order to design and process sophisticated products.

To summarise, a contract described with MLFi is an expression (a value) that can be analysed and manipulated in many ways to convey different meanings: MLFi has potentially multiple, compositional semantics.

The table below summarises the characteristics of the three approaches for representing financial contracts.

Business considerations

FpML's reliance on network effects may delay its adoption

MLFi delivers intrinsic value whereas FpML relies on network effects to create value. MLFi may be used by individual business units or product areas as a stand-alone tool to design, price, and process products. In contrast, FpML is primarily a communication standard and brings relatively limited value to a single group: users derive value from FpML when different groups within a single bank or, preferably, when several banks use the standard to communicate with each other. FpML's reliance on network externalities to deliver value may delay its adoption.

Payoff languages create operational risk

In the past decade, many derivatives desks have developed payoff languages to price new products, sometimes with little consideration for the downstream impact of executing complex transactions. As a result, complex contracts are invariably redefined in several systems and/or processed manually. Multiple contract representations are an important source of operational risk.

MLFi offers a technical solution to apply sound practices in the structured product business. MLFi contract descriptions lend themselves to many uses and can be shared among applications: MLFi preserves the freedom to innovate and provides control over the entire structured product value chain.

What is MLFi used for?

MLFi is a building block for developing a variety of high value-added transaction processing, decision support and business integration solutions for derivatives and structured products. Potential application areas of MLFi include:

• structuring and sales support
• trading
• risk management
• operational management
• documentation processing
• product repository
• enterprise application integration
• data warehousing

MLFi, combined with the customer's or LexiFi's own pricing libraries, forms the foundation layer of an integrated and extensible transaction processing and decision support infrastructure.

Resources