A few words about LexiFi’s main technology

What is LexiFi’s main technical driver?

LexiFi has developed a unique formalism to describe financial contracts. In the same way algebraic symbols can be combined to describe all algebraic expressions, this formalism can be used to describe all structured products and derivatives, from the simplest to the most complex ones. Crucially, all descriptions are based on the same small number of combinators and operators instead of an ever growing list of ad-hoc elements that need to be introduced for each type of product. One could qualify this approach as “Lego™-like”, in that one can build ever more complex objects from the same set of elementary pieces.

Precise and exhaustive semantics (meaning, or “behavior”) of the contract payoff is therefore self documented, if one only knows and understands the about ten elementary combinators. Contract’s symbolic payoff meaning becomes therefore accessible to both a computer program and a human reader.

LexiFi is not selling this idea (which has been co-published by LexiFi in an academic paper), but rather a highly refined implementation of it. Used in many highly demanding production environments for more than 15 years in finance and financial software industries, LexiFi’s technology has been carefully crafted to scale even to large portfolios of the most intricate structured products or derivatives.

What markets/underlyings does this description language support?

LexiFi’s contract algebra has been designed to uniformly support any kind of underlying asset (such as equities, fx, commodities, inflation, interest rates, etc.). Using the same logic for all markets allows a unified approach, both in terms of business functionality and technical implementation. This consistency reduces costs in the long run and dramatically simplifies the API manipulating financial contracts. Crucially, this API is independent from any particular financial contract. LexiFi’s approach follows a strict separation of concerns (defining financial contracts on one hand, valuating, analysing and managing them on the other). By contrast, conventional approaches intertwine all these concerns, resulting in increased complexity and loss of generality at every level.

Wait a minute - isn’t this just another kind of pricing script?

No, it is not. Typical financial scripting languages available on the market or developed inside financial institutions are designed to be executed, usually for pricing purposes. These scripting languages have a serious “quant biais”: they can’t be used for anything else than pricing.

LexiFi’s contract algebra on the other hand is a symbolic specification of the rights and obligations attached to a contract. Crucially, such a specification can be considered independently from any valuation, management or analysis mechanism (i.e. it is a “value” in itself) and as such it can be stored, transmitted, rewritten, or transformed symbolically.

Every contract can be specified in this way using the same minimal set of combinators and operators. This specification language has been carefully designed to be exhaustive and precise. The meaning (semantics) of a contract is derived in a compositional way from that of the combinators and operators used in its description.

For example, LexiFi provides tools to parse and render this representation in a number of different formats, such as a simple textual form suitable for human consumption, XML format, or a number of different dataexchange formats, both textual and binary.

Similarly, specialised contract pricing code, management tools, and other transformations can be generically produced from and applied to such a symbolic representation.

Got it — but give me one interesting example of a contract analysis/transformation?

Our approach to life-cycle management is a perfect illustration.

This approach is based on the premise that life-cycle management should be implemented once, in a generic way across all contracts. In order to achieve this, each aspect of life-cycle management is implemented as an independent analysis performed on the symbolic representation of the financial contract under consideration. For example:

  • The event calendar (a precise annotated list of all future, certain or possible, events) is derived on demand from the symbolic contract description, by extracting dates of fixings, cash flows, barriers and other relevant features.

  • Applying a life-cycle step (observing a fixing, exercising an option, hitting a barrier, paying a coupon, etc.) comes down to transforming the symbolic representation into a simpler one, reflecting the partial resolution of contract uncertainty over time.

Life-cycle management is therefore similar to a state machine, the internal state being the symbolic representation of the “current” contract, and reacting to life-cycle events coming from the outside by iteratively simplifying this description until it becomes trivial (when the contract ends, i.e., it reduces to the “nothing” contract).

Other examples of this approach include qualitative cash flow projections, the automatic choice of suitable pricing models for a contract or interactive graphical simulation tools for the end-user.

Just as before, each of these examples is implemented as analysis and transformation passes working on arbitrary symbolic representations, and as such can be applied generically across all contracts, without the need for any ad-hoc logic. In other words, having access to the semantics of financial contracts provides numerous possibilities, not only as of today but also for future needs not foreseen today, therefore protecting vigorously our client’s investments.

These analyses and transformations are executed behind the scene nearly instantaneously, when needed. Optional smart cache approaches may further optimize the approach in case of frequent repetitive tasks.

Note: typical business users of LexiFi’s end-user software (LexiFi Apropos) aren’t exposed to this machinery but only to resulting features and simplicity of use.

So a typical user needs to describe all relevant contracts by hand, using this algebra?

No. The approach described previously is the one used internally in LexiFi’s technology stack. Most of our end-user clients (typically financial institutions) never deal with the symbolic contract representation directly. Common complex financial structures or structured products are provided by LexiFi in the form of “instruments”, which are mappings from a set of parameters (such as denomination, maturity, barrier level(s), etc.) to a contract description. New products or deals can therefore be specified (or imported in other ways) simply from their name (autocall, reverse convertible, etc.) and associated parameters.

Power users may add their own instruments, even if the set of instruments delivered with LexiFi Apropos covers typically all needs of our client’s institutions. Note that some instruments are themselves very generic, allowing for an Excel like definition of even the most intricate contracts.

Supporting a new structure in the system means adding a new instrument; life-cycle management, pricing, simulation tools, etc. are immediately available without further coding, parametrization or costs.

Reasonable. Can you say more about pricing and risk calculations?

LexiFi provides state-of-the-art analytics. All quantitative developments are done at LexiFi; we don’t rely on any third-party expertise. We implement a huge number of different models and variations. The usual numerical approaches - Monte Carlo and numerical Partial Differential Equation solvers - are supported for all models where this makes sense. Numerical routines are highly optimized and use, when available, multiple CPU cores or advanced processor instruction sets. We definitively know about finance. About computer architectures. About data structures and algorithms. About number crunching and high performance computing. And when one needs fast, reliable and precise results, all this matters.

LexiFi embraces not only the usual Risk Neutral approach, but proposes also pricing models based on historical observations or statistical estimations. Priips calculations and similar regulatory obligations are of course available too. Continuously enhanced and updated, our quantitative routines incorporate market evolutions, regulatory changes and customer feedback.

But combination of LexiFi’s symbolic approach with best-of-class analytic skills allows to go further than competing approaches. Automatic ranking of applicable models, automated additive decomposition of contracts for pricing speedups, optimal market data query generation,… are only a few of the many features that LexiFi makes available to its clients with its outstanding technology.

No free lunch — doesn’t this flexibility imply lower pricing speed compared to hand written/optimised code?

No. Even if the contract description is a symbolic representation, it is never directly executed for pricing purposes. It contains all information for doing the job, but it isn’t well suited for doing the job quickly. So we transform the contract description into a form adapted for doing pricing only, but for doing it fast!

LexiFi uses advanced compilation techniques to generate highly-optimised pricing code from the contract description. LexiFi has been honing its expertise in this domain and refining this compilation step for nearly 20 years. In a typical multiple pricing scenarios situation (think about a VaR calculation, for example), a given Monte Carlo “payoff code” is executed million of times. Even the smallest enhancement of this code may produce immediately sensible execution accelerations.

LexiFi integrates deep domain specific finance knowledge and expertise into it’s code generation technology. Generated code may depend on properties of the chosen pricing model, or include machinery for early exercise regression in a Monte Carlo context. Similarly, we can automatically treat control variates in a Monte Carlo framework and other optimisation methods in a partial differential equation approach, such as automatic insertion of “path-dependent” dimensions.

The generated code may also be instrumented to calculate probabilities of uncertain cash flows or barriers being hit, when such extended results are wanted. On the other hand, if really only the price result matters, minimalistic code can be generated, that allows for fastest possible execution on the computer.

Want to compare? We strongly encourage our clients or prospects to benchmark our pricing engine against competing pricing libraries or software. Because LexiFi shares with its customer and prospects one crucial point: pricing is never fast enough. Never.

Furthermore, since the pricing code is typically generated from the representation of the “current” contract, it automatically benefits from any contract simplification when approaching maturity.

I understand you offer end-user software. But what about enriching existing or forthcoming software with these advanced functionalities?

Yes, LexiFi offers essentially two product lines:

  • LexiFi Apropos is an application for business end-users, and

  • LexiFi Instrument Box for commercial software editors or internal developers to include LexiFi’s functionality into their own project.

LexiFi Apropos is a complete application, built of course on top of… LexiFi Instrument Box. It is an example of a (big) application that leverages LexiFi Instrument Box provided functionalities. LexiFi Apropos wraps these functionalities into a system with graphical user interfaces, a centralized database, reporting capacities, workflows etc. making it a full application.

LexiFi Instrument Box on the other hand is a library to be embedded by programmers or developers into their own code. In order to maximise genericity, orthogonality and exhaustively, LexiFi has endeavored to define very precisely all contract manipulations and related concepts. All these different aspects are exposed as a library with a minimalist but powerful API, accessible by any third-party application. Depending on the needs and wishes of LexiFi’s clients, it may or may not include LexiFi’s analytic capabilities, but typically includes all life-cycle management functionalities. It may be configured with different programming language interfaces, as a static or dynamic library, as a server, etc., but the features and conceptual API always remain the same.

As an example, Bloomberg decided to replace an existing derivatives library in favor of LexiFi’s Instrument Box for building their new DLIB service, mainly in order to profit from this kind of automatic life-cycle management.

Sounds great — but how long does it take for a developer to master the certainly highly complex API of Instrument Box?

First, the API isn’t complex at all. Genericity, minimality, powered by LexiFi’s abstractions and deep finance domain specific knowledge ensure for an intuitive and easy to assimilate set of API entry points. Some of our Instrument Box customers work with no more than 10 or 15 entry points!

Through a knowledge transfer program, developers learn from LexiFi experts the concepts needed to use this stateless API. Note that programming with Instrument Box does not require any specific knowledge of the particular instruments supported (the list of which typically evolving through the evolution of a project). Same is true about particular pricing models supported.

Moreover, LexiFi provides an extended, specific “LexiFi Apropos for Instrument Box developers” to Instrument Box clients. It provides exports directly in Instrument Box compatible formats, and gives access to specific pages for discovering interactively Instrument Box’s features.

Fair enough. But I have to adapt my database schema to be able to store these changing algebraic contract descriptions?

No, this isn’t necessary. This algebraic description is only used internally. As mentioned earlier, an (initial) contract description can be derived from an instrument and its parameters. It can then be transformed by successively applying life-cycle management steps. This implies therefore that a (current) contract specification can always be derived from its instrument parameters plus the list of already applied life-cycle management steps. LexiFi uses a clever implementation making this process really fast! So one simply needs to store or have access to the instrument parameters and this list of past life-cycle management steps. Most of Instrument Box integration projects of LexiFi’s clients are indeed using this approach.

I understand the benefits of LexiFi’s approach. Am I forced to use LexiFi’s pricing models if I use Instrument Box?

No, you aren’t. First, contract management and life-cycle execution is independent of pricing. But even on the quantitative part, LexiFi distinguishes clearly the pricing framework (pricing code compilation technology, market data query generation,…) from actual implementation of pricing models. The later can be done by LexiFi’s client who want to “keep their model implementations”. Only minor modifications of these model implementations are typically necessary for making them compatible with LexiFi’s generated pricing code.

Some of our Instrument Box customers have succesfully chosen this path.

Can you give me other arguments in favor of LexiFi and the technology it provides to the market?

For nearly 20 years, LexiFi has combined advanced software technologies with its financial field-proven expertise to create software for manipulating complex derivatives and structured products. By combining fundamental ideas ranging from the theory of programming languages to the engineering of compilation technologies with the expertise of our internal quant team, LexiFi is able to push further the possibilities of financial software.

LexiFi is applying its combined expertise to many other finance-related features. If you are interested for instance in

  • carrying advanced symbolic or quantitative analyses of financial contracts

  • generating automatically entry screens for instruments and model parameters

  • adding powerful interactive simulation features to an existing web site

  • reading, analysing and importing automatically structured product term sheets in pdf format

  • generating documents containing complex quantitative analysis results, up to date with latest market data

  • defining reusable and compositional risk scenarios

  • minimising portfolio risk with structured products

  • reducing all kind of operational risk related to structured products

  • ensuring reliable and predictable pricing of complex derivatives

  • implementing a website dedicated to derivatives or structured products

you should definitively contact LexiFi. Now.

LexiFi • 892 rue Yves Kermen • F-92100 Boulogne-Billancourt • France