Data modelling of Financial Instruments. Best Practices.
Deconstructed recipes, like the valiant efforts of contestants MasterChef, have shown to provide a delicious and viable alternative to the norm.
Conceptual, semantic, logical, and physical data models, on the whole, have been based around historical trading desks. Over time these have been shown not to be too appropriate and unworkable, especially if the model was originally based on a single securitised domain, then extended to include others. We all have worked on projects that started with Equities, then Debt, then exchange-traded derivatives then more complex capital market products. Having developed applications based around XML and industry standards, I, like many others, have fallen foul of this over the years.
Financial products take many forms, nonetheless, they all have something in common. That being the flow of cash between the owner/issuer, seller, and purchaser. A classic example is that of a debt instrument. If one purchases a bond, an investor provides the issuer with the capital in return for regular interest payments and the subsequent return of the capital invested at maturity, back to the investor.
Constructing a model around cash flows eliminates the pitfalls associated with attempting to categorise financial products under simplistic hierarchical classifications. However, when adopting such as approach, one needs to ensure that it is possible to provide traceability back to the original product. There are scenarios where risk management has been adequately supported by having all financial products represented as cash flow transactions. Nonetheless, on maturity or expiry, it has been difficult to reconstruct the original product as the more complex the agreement, the greater likelihood that the product has morphed into something completely different from its original.
Is there a solution that enables the business to support risk and regulatory reporting?
There are various classification schemes that organisations are expected to categorise financial instruments by, including ISO 10962 to support MiFID, ESA 95/2010 for the ECB statistical analysis and other accountancy classifications such as IFRS 7/9 used to measure business entity risk.
This does raise the question of whether it is possible to construct a hybrid model of financial products that supports both risk and regulatory reporting requirements. The latter requires financial products to be pigeon-holed into differing hierarchical taxonomies.
Inevitably, we are all aware of the deficiencies of building a data model around a taxonomy that uses only a simple set of key attributes. This can be seen if one uses a food analogy and attempts to classify cupcakes and muffins. Both contain similar quantities of calories, fats and carbohydrates. Thus, based on these properties, they are one of the same. Any financial data model will need to be able to effectively categorise financial products into multiple classification schemes.
Another dilemma is the identification of instruments, parties, and their associated accounts. In the case of instruments, the identification requirement differs as it progresses through the various stages of the trading lifecycle. This includes the exchange ticker at the trade inception through to an appropriate settlement identifier upon deal completion. The ability to understand whether the trade is still live or open is another concern, as financial institutions are exposed until it is considered closed.
A building-block approach that is product type agnostic, using common data structures to support both securitised and derivative products, will provide the framework for maintaining the complex requirements of an organisation’s needs. The main ingredients of which should include cash flow, instrument, pricing, party information, and party role components.
Let us be inspired by the results of deconstructed recipes, rather than suffer from piling more onto decomposing legacy financial data repositories and data models.
Could this be the panacea one requires?
Martin Sexton is a Senior Business Analyst at Finworks
The Finworks Data Platform
Finworks’ Data has developed a golden copy database model, deployed at a high-profile European Bank handling the pricing, valuations, and reference data of over eight million active financial products, that is complemented by our data quality management framework.
Contact us via Email: firstname.lastname@example.org or at: https://www.finworks.com/