FAQ

LexiFi brings most value to structured product professionals who

• are serious about automating the management of complex derivatives;
• realize that the development of software for structuring, pricing, and processing complex financial products is a very difficult challenge for which no simple solution exists; and
• recognize the need to overcome the limitations of stand-alone spreadsheets and inadequate representations of complex financial products in traditional trading and risk management systems.

The LexiFi Platform is a complete set of tools for the rapid development of financial applications.

The LexiFi Platform comprises

• a portable, pricing-independent financial product description standard that precisely reflects the evolution of a contract over time
• an open pricing architecture that supports multiple integration scenarios with in-house valuation algorithms and calculation platforms
• automated event processing capabilities
• a simple and readable IT model that shields applications from the diversity or complexity of financial products
• tools for the rapid development of Microsoft .NET applications
• a software development kit with pre-built functionality for defining and processing financial products, including a finance library and a collection of industry-standard model implementations, both delivered with source code
• comprehensive integration tools

The Modeling Language for Finance (MLFi) is the defining technology behind the LexiFi Platform.

MLFi is a general-purpose programming language that comprises a domain-specific sub-language for describing financial products. The MLFi contract sub-language is a precise formalism that exhaustively describes financial contracts with a limited set of core constructs.

The main technical feature that sets LexiFi apart is the compositional logic that MLFi provides for defining financial products.

For more information, see below "Technology - What do you mean by compositional?".

MLFi is a building block for developing a variety of high value-added transaction processing, decision support, and business integration solutions for complex derivatives. 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 pricing libraries, forms the foundation layer of an integrated and extensible transaction processing and decision support infrastructure.

Yes. LexiFi Platform users can get started immediately with a collection of Monte Carlo, PDE, and closed form implementations of industry-standard interest rate, equity, and hybrid models, all delivered with source code.

Yes. MLFi's operational model is a crucial feature for many valuation-related processes.

MLFi guarantees that pricing code always mirrors the state of each contract. The combination of a formal operational model and pricing capabilities provides a unified framework for valuing complex products as they evolve in their life cycle, for simulating the value of a contract over a set of future dates, and for calculating value at risk and potential credit exposures on a portfolio of exotic products.

The fact that MLFi correctly reflects the evolving structure of financial contracts has two additional benefits:

• Optimal Pricing.   MLFi updates pricing code as contracts transition from state to state. This provides an opportunity to use the most efficient pricing algorithm, including closed-form solutions when they exist, in each contract state. For example, MLFi generates pricing code that accurately reflects the decreasing dimension of exotic basket-based equity options in which underlying assets are progressively removed from the reference basket.
• Correct Handling of Time-Related Events   The impact of time-related events such as coupon payments on the behavior of a contract must be carefully reflected in traditional pricing algorithms. MLFi eliminates this important source of programming errors by generating valuation code that exactly mirrors the state of each residual contract.

MLFi is a general-purpose programming language that comprises a domain-specific sub-language for describing financial products.

MLFi is implemented as an extension of OCaml, a functional programming language that was developed over the past twenty years by INRIA, The French National Institute for Research in Computer Science and Control. MLFi's implementation is therefore a full-fledged programming language that includes financial contract description features. The fact that MLFi is written in itself proves that MLFi is a full-fledged programming language.

MLFi's contract sub-language accurately describes sophisticated capital market, credit, and investment products with a limited set of core constructs. Domain-specific languages exist in other industries such as electronics (e.g., for circuit and chip design) and aerospace.

MLFi runs under virtually any PC or Unix platform.

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 behavioral 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 specialized 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.

MLFi has proven theoretical properties such as strong typing. The contract sub-language has the added properties of being strongly normalizing—i.e., the execution of a contract is guaranteed to terminate in a finite time—and purely functional—i.e., free of side effects. This theoretical simplicity opens the way for powerful analyses and optimizations, including partial evaluation and abstract interpretation, in the treatment of contracts within a well-understood compiler technology framework.

A process is a task that transforms an MLFi contract definition into a specified output such as modified MLFi code (i.e., another MLFi contract), source code in another programming language, or a text file. Examples of processes include pricing, event management, and cash flow forecasting. Processes are described by how they manipulate MLFi's twenty basic combinators.

The business benefits are reduced time to market, costs, and operational risk.

The technical benefits are that processes (e.g., pricing, event management) do not need to be re-written each time a new instrument is introduced and, conversely, new processes do not have to be adapted for each instrument, one by one.

Decoupling contract definitions and processes can be achieved by creating a compositional contract algebra (see below "What do you mean by compositional?") that: (i) defines a shared standard for describing financial products, and (ii) defines processes independently from products.

What this means is that 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.

Data models and object models aiming to encapsulate the definitions and behavior of financial instruments were developed by banks and vendors in recent years in order to support a variety of departmental and firm-wide processes.

LexiFi believes that many of these initiatives did not meet expectations in terms of functionality, budget, or implementation time because the tools were not adapted:

• Data Models.   Data models are not compositional (see "What do you mean by compositional?") and are therefore inherently ill-suited to represent complex financial contracts.

• Object Models   Even though major object-oriented languages are not compositional, they are potentially able to mimic the features of the contract sub-language included in MLFi. The problem with object-oriented languages lies in the implementation of pattern matching, a powerful mechanism that increases programmer productivity and program safety and performance:
  • Programmer Productivity and Program Safety.   Pattern matching, as implemented in MLFi, performs complex semantics verifications on the user's code. The MLFi compiler detects useless cases and, more importantly, cases that were overlooked by the programmer. This feature catches many non trivial programming errors and proves statically that cases are exhaustively covered.
  • Program Performance.   LexiFi has demonstrated that the representation of financial contracts in the form of abstract syntax trees helps to solve some of the most difficult problems related to the management of complex products. The manipulation of financial contracts, for example for pricing or event management purposes, entails the exploration of such trees. Pattern matching is the tool of choice to find the relevant structure in a program, to retrieve the aligning parts, and to substitute the matching part with something else. Structured products can result in large and complex trees—trees comprising thousands of nodes are not uncommon. The MLFi compiler handles such cases very efficiently: a tree node occupies only few bytes in memory. In an object-oriented language, memory requirements are potentially an order of magnitude larger. The likely consequences are reduced performance and the possibility of exceeding the memory capacity of existing machines.
  In addition, financial product data models and object models add a significant management burden on IT teams as they impose the maintenance of dozens of tables or UML diagrams.

Semantics

The main technical difference between FpML, pricing-orientated 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 behavior 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 (see "What do you mean by 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 behavior 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 analyze 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 summarize, a contract described with MLFi is an expression (a value) that can be analyzed and manipulated in many ways to convey different meanings: MLFi has potentially multiple, compositional semantics.

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

	FpML	Payoff Languages	MLFi
Contract Description	Structured list of parameters.	Program.	Expression.
Number of constructors	Potentially infinite, as new constructors are needed to define new products.	Finite or potentially infinite, depending on the implementation.	Finite list of primitives.
Data separated from processes	Yes. Describes what contracts "are" independently from what they "do." What contracts "do" cannot be easily derived from what they "are."	No. Describe what contracts "do" in a pricing context. Contract description is a program that can only be executed.	Yes. Describes what contracts "are" independently from what they "do." Contract description is a value that can be analyzed and manipulated in many ways. What contracts "do" is automatically derived from what they "are."
Semantics	No semantics.	Single valuation (denotational) semantics.	Many possible denotational semantics (e.g., valuation, future cash flows) and operational semantics (e.g., event processing). Programs that manipulate contract definitions are compositional.
Analogy with algebra*	Meaning cannot be determined independently by simply looking at a parametric definition of the algebraic expression.	Find the value of X and Y, using a model, to calculate the value of the expression.	Denotational semantics: Find the value of X and Y, using a model, to calculate the value of the expression. Calculate the number of symbols, the sum of even numbers, etc. Operational semantics: If we know that the value of X is 5 (in the world of financial contracts this could represent the value of a fixing), record the fixing information as part of the expression and apply simplification rules. The expression becomes "6 x (3 + Y)".
(*) This line describes the possible meaning(s) that may be given to algebraic expression      "(1 + X) x (3 + Y)" under the different approaches.

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.

MLFi is implemented as an extension of OCaml, a strongly typed functional programming language, available in open source, and developed over the past twenty years by INRIA, the French National Institute for Research in Computer Science and Control.

Yes. As a member of the Caml Consortium, LexiFi benefits from a license that allows our firm to offer commercial products based on OCaml (for more information, see the Caml License for Consortium Members). In addition to LexiFi, members of the Caml Consortium include Dassault Aviation, Dassault Systèmes, and Microsoft.

LexiFi found that a functional programming language was the most effective tool for developing compositional contract and scenario algebras.

LexiFi users derive important benefits from a functional programming approach, including:

• Lists.   Functional programming languages offer powerful support for useful pre-defined types such as lists. Lists play a central role in finance where they are used extensively to define schedules. For example, a swap schedule or a Bermuda option exercise schedule may be defined recursively using a list.
• Specification.   The declarative formalism of functional programming languages is well suited for specifying complex data structures and algorithms, and the interactions between complex data structures and algorithms. In contrast, imperative programming languages tend to reflect the actual behavior of computers: complex types may be extremely difficult to design and maintain. Object-oriented languages are better candidates than imperative languages for implementing a contract algebra. However, they suffer from certain limitations, especially with respect to pattern matching (see " What are the limitations of data-oriented and object-oriented approaches for modeling financial instruments?").

  There is nothing dogmatic in LexiFi's choice. LexiFi simply selected the best tool for each task:

  • a functional language, MLFi, to represent financial contracts;
  • an object-oriented language, C#, to build graphical applications; and
  • an imperative language, C or the imperative layer of C++, to implement pricing algorithms—the object layer of C++ is not required here because the proposed approach enables quantitative analysts to focus on the mathematical aspects of a pricing model's implementation. The logic of the contract and all market conventions are resolved in the MLFi contract definition. The pricing code derived from the MLFi specification defines the sequence of calls to a limited set of pricing primitives implemented by quantitative analysts.
• Functions.   Functions are "first-class citizens" in functional programming languages: they can be used as arguments of other functions. For example, a "sliding contract" used in a LexiFi simulation is a function that takes a date and a scenario argument and returns a contract. A list of sliding contracts—i.e., a list of functions—is passed to LexiFi's simulator function to run a simulation.

More generally, quoting Don Syme of Microsoft Research:

"Mixed functional/imperative programming is a fantastic paradigm for many programming tasks. Languages such as OCaml and Standard ML provide excellent general purpose programming languages suited to medium-advanced programmers who want simple yet highly expressive tools that boost their productivity, primarily by reducing the error rate, increasing their productivity through type inference, and basically letting them focus on the difficult parts of their applications. ...

Purely functional languages like Haskell are excellent within certain niches, but while laziness and Haskell's very strict control of effects do offer substantial benefits they also pose real problems for interoperability between lazy and strict languages. Purely imperative programming languages like C or Pascal do not provide satisfying mechanisms for abstraction or data manipulation. Purely object oriented languages like Smalltalk are excellent for some dynamic applications but do not provide static guarantees. Typed class-based languages like C# and Java contain a very large number of constructs, and it can sometimes be difficult for programmers to choose how to model their problem, and sometimes result in very large amounts of code just to solve quite simple problems. In contrast, the core constructs of the ML family of languages provide a smaller number of simple, orthogonal constructs which work together to allow for succinct yet efficient solutions to programming problems, and in particular permit common patterns of coding to be abstracted very easily." For more information, see Caml and Functional Programming Resources

INRIA stands for "Institut National de Recherche en Informatique et en Automatique" or "National Institute for Research in Computer Science and Control." INRIA is France's leading computer science research institution.

Please contact Philippe Lecocq at LexiFi (Direct line: +33 1 47 95 20 40, E-mail: philippe.lecocq@lexifi.com) if you wish to take a closer look at our products.