It is important to automate “middle-office” processing to keep operational costs and risks under control.
Such automation brings many challenges. Some are directly related to the industry’s structure such as the direct influence of index sponsors and market data providers on derivatives and structured products’ automation capabilities. While other challenges are related to the complexity and diversity of payoffs.
Also, some market players ambition to “run” structured products and process their lifecycle events on blockchain-based ledgers, using smart contract technology. A prerequisite to doing so is understanding how to achieve full automation locally first, in a non-distributed setting.
This post might thus be of interest to people involved in such projects as well as everyone in the business of automating (some aspects of) structured product life-cycle processing. Let us outline the five main challenges we have identified.
Challenge 1: agreeing on the scope of “life-cycle” processing
The term “life-cycle” can have different meanings depending on the context. The first thing is to agree exactly on the scope of what we want to automate.
We make a clear distinction between two big families of events: contractual events (fixings, options, barriers, credit events, cash flows) and trade-level life cycle events (settlement layers, payment systems). Both are important but largely independent and each comes with its challenges. In this post, we will consider only contractual events.
While computer systems in charge of processing structured products should avoid conflating these two life cycle event families, it is not always the case. For instance, in the processing of contractual events, one can consider “abstract” long/short parties, although concrete identification of parties with all administrative details can be left to the trade-level layer. More precisely, we are looking to automate the “nominal” behavior of the product. The impact of some exceptional events, such as market disruption, monetary events, termination of indices, and legislative evolution are not fully specified and thus cannot be completely automated.
Challenge 2: capturing the payoff
The nature of the structured product market makes it that terminologies used for contract payoff descriptions are not uniform across markets and sometimes issuers. Payoffs are usually described in term sheets or other kinds of (semi)-contractual documents. Many of these documents contain informal language, some typos and, bogus descriptions. When analyzing term sheets for similar products, the same payoff feature can be described in multiple ways.
There sometimes remain unspecified behaviors and ambiguities. This is often the case with “concurrent” events such as a potential early redemption event on dates where a continuous barrier also exists, with different outcomes for the barrier and early redemption events. Such cases need to be fully specified when translating the payoff into a mechanical description. Even more frequently, term sheets contain actual mistakes.
In practice, capturing a payoff from informal documents is a tedious and error-prone manual process. Some partial solutions involve:
- Semi-automated capturing of payoff terms from contractual documents using document processing and AI-based solutions.
- Relying on common exchange format at the level of the mechanical description (which is a prerequisite for “structured products” as “smart contracts on blockchains” project).
- Or, more pragmatically, relying on a common exchange format at the level of “product parameters” such as a list of supported product families, their parameters, and the intended payoff behavior.
Challenge 3: naming and accessing market data and external stuff
To automate lifecycle management, reference to “external concepts” (stocks, indices, including proprietary ones, credit events, business calendars, etc.) need to be done through well-established naming conventions. However, identification schemes are often subject to specific licensing and legal constraints. This hinders the ability to use common naming conventions in exchange formats and inside internal software systems.
Industry and regulation efforts have led to the creation of the Legal Entity Identifier framework, and we believe that the industry would benefit from similar efforts applied to other things that need to be properly identified in term sheets.
Once effective naming conventions are set, processing fixings and barriers or monitoring credit events is based on observing market data. This can only be automated with proper “automated” feeds for such data. The main challenges are the availability of data (e.g., proprietary indices), the cost for acquiring market data, the licensing constraints on usage and redistribution, and the quality of data. Official historical close prices for stocks are available to the public for free on the web but acquiring the same data for business use is tricky!
Using the right technology can help overcome the long-standing data cost problem. LexiFi Apropos for instance helps users make the most out of their data usage by controlling both direct and indirect costs related to regulatory reporting.
Challenge 4: handling exceptional events
Some exceptional events cannot be fully captured in automated life-cycle systems. For instance, we are not aware of any system that would support out-of-the-box the case of a currency being discontinued or the transition to the post-LIBOR era. Such transition necessarily involves some unplanned intervention on product descriptions.
The better control we have over payoff representation of the payoff, the bigger our chances to cover a wide range of cases in a semi-automated way. For instance, with LexiFi’s DSL for describing products, substituting LIBOR with fallback indices or replacements can be automated for a wide range of products.
Corporate events, such as stock split, rights issues, mergers, spinoffs, etc. are special kinds of exceptional events requiring a specific treatment. These typically require adjustments in the terms of structured products. A wide range of corporate events can be supported in a “mechanical way”, using one of the two common adjustment methods (Ratio or Basket method), even if this sometimes requires manual treatment.
In those cases, the adjustments required on the payoff description can be automated. As is the case for market data, a core difficulty is having access to a robust automated feed. Such feed should describe the corporate events and the choice of adjustment to be applied —which is usually left to the discretion of the issuer or calculation agent.
Challenge 5: the need for a “mechanical” description of the payoff
For a computer system to automate life cycle event management, it first needs to figure out product payoff semantics. Specifically, the rights and obligations of parties involved in the contract, how each product “behaves” which cash flows it produces _for any possible set of “inputs” such as market observation or option decisions, etc. We thus need to describe this “payoff function” using some representation that can faithfully capture the terms of a given financial contract and can be processed by a computer system.
In many systems, structured products are only described by a set of “parameters” which varies depending on the product family. The actual semantics of the product is “hidden” in the application. It then needs to be replicated to process the same product for different purposes such as life cycle, hedging, valuation, reporting, etc. Extending such systems with support for new product families or types often requires a significant engineering effort: a given version of the system will only handle a fixed family of products.
There have been some efforts to standardize such parametric descriptions independently of a specific computer system. Examples include FpML or IBT. These tend to be complex to implement and restricted in scope. Plus, they fail to bring a formal enough specification of all possible combinations of features to ensure that all parties involved in a trade agree on the precise meaning of the product.
We argue that a much better approach is to organize the system around a generic language that describes arbitrary payoffs for products of interest. Instead of maintaining a list of support product families, the idea is to rely on a programming language powerful enough to capture the actual payoff semantics. The core system does not know anything a priori about specific product families: all operations such as life cycle processing operate at the level of the generic language. The “program” that describes a given product is itself considered as the input of such operations.
Using a domain-specific language (DSL) rather than a general-purpose one makes it much more tractable to organize the system. It allows to avoid security issues and facilitates the mechanical treatment of product definitions such as static analyses, or compilation to efficient code for quantitative analysis. Also, the DSL can be more easily exposed to financial end users, who are not expert programmers but might still find it useful to see a complete but readable description of products in their books.
LexiFi’s approach
LexiFi has established a domain-specific computer language that allows generically describing financial products. For a historical perspective, you may read the academic paper co-written by LexiFi’s founder and CEO Jean-Marc Eber. Thanks to our uniform description of derivatives and structured products, LexiFi’s lifecycle management tool is ready to process any product regardless of its complexity and asset class. LexiFi’s technology has been used by various financial institutions and software companies for over 20 years.
We are aware of other systems that follow a generic approach and manipulate “scripts” that represent structured products. In most cases, those representations are by-products of pricing layers, and it is not uncommon to see lifecycle being somehow derived mechanically from “pricing scripts.” These scripts were sometimes initially used for hedging and valuation purposes such as driving Monte Carlo pricing engines. One problem here is that pricing scripts sometimes require approximations over the actual payoff and might not convey “administrative” details that matter for the lifecycle. We can cite the distinction between an automatic call option and a call option with explicit exercise as an example.
LexiFi’s approach automatically generates such pricing scripts from the higher-level representation of products in our DSL (with some logic to insert required approximation and forget useless details, etc.). A single product can be mapped to different pricing scripts depending on the target pricing model.
Regulatory initiatives
Market data
Regulators are mobilizing to achieve data harmonization and establish industry standards that are essential to lifecycle management automation. Regarding market data availability, licensing, and data redistribution challenges, ESMA recently launched a consultation paper on guidelines on the MiFID II/MiFIR obligations on market data. It provides guidance on publishing market data, as well as costs and availability requirements. This shows that market data are under regulatory radars; however, it will take time until we see actual results.
Reporting
When it comes to post-trade reporting, financial market participants often rely on manual outdated technological processes. This gives rise to errors and regulatory reporting divergences. In February 2020, the US Commodity Futures Trading Commission (CFTC) issued a plan to require reporting parties to use industry-recommended critical data elements (CDE) when submitting their OTC derivatives trade information. Legacy back-office capital markets solutions are not sufficient to answer regulatory requirements. This urges the need for a technology built around a uniform standard. Technologies such as LexiFi’s can provide a common standard for participants—buy-side, sell-side, regulators. It can also help software vendors to bring a common solution to the market that significantly extends their reach.
Conclusion
The complex nature of derivatives and OTC instruments results in unique challenges as the essence of these products is their customization, which makes it difficult to standardize their manipulation. The adoption of common data and rigorous standards along with the use of robust technologies will improve risk management and reduce costs. Accurate lifecycle management and high-quality post-trade services are clients’ priorities. Increased automation will reduce complexity and allow for superior client services. Considering the industry challenges, the smartest way is to go for a specialized vendor with a demonstrated track record of product lifecycle management automation.
We walk the talk
LexiFi’s system relies on an internal generic description of payoff semantics using a domain-specific language. Of course, in practice, the end-users of our applications do not usually write scripts by hand. Instead, we provide various ways to generate such scripts from external descriptions: user-interface screens with various degrees of flexibility (including ones that allow for semi-graphical programming); import from external representations such as IBT. Some issuers have also created direct feeds to transmit product descriptions directly to their buy-side counterparts who use LexiFi software.
Recently, we have developed a powerful new approach: a term sheet reader. This tool scans PDF documents (term sheets or similar documents) and recognizes the definition of a given product using a combination of layout and keywords analysis. Many control mechanisms are put in place to minimize operational risk and send alerts in case of anomalies in the contract definition. The tool supports many issuers, document layouts and, product families. It works mostly for term sheets in English (but also in French for a smaller number of issuers), and already covers most products managed by our customers. We expand coverage regularly, to follow market trends and adapt to new commonly found product variations.
Our uniform approach for describing financial contracts places the capital markets industry in a better position to manage financial products' diversity.