I have always believed that the most awesome aspect of Quintessence is its profoundly simple and yet powerful data model. It is the fundamental reason why Quintessence is the solution to the range of challenges that our clients face. This, together with our talented data engineers, allows us to deliver industrial-strength solutions to a range of problems, spanning the back, middle and front office. I will focus this article on describing the Quintessence Data Model by demonstrating its fit into many diverse business cases.
Whenever a software development problem is solved, an integral aspect of the solution is understanding the data and the consequent data model. Data models are abstract models of the data elements and how they relate to one another. Data Models are a prerequisite to defining the conceptual, physical and logical structures that result in a specified schema. Once a data model is designed, best practice specifies that the model is validated prior to building, deploying and using the said model. Developers then interact with the model via views that offer a decoupled representation of the data – with the possibility of multiple adaptable representations of the same underlying data.
Consider the real-life example of a fund management house needing a process to manage its portfolios’ dispersion. The fund managers maintain various house views – a Global Equity view, an EMEA view and an ESG view. These house views encapsulate the fund managers’ positions and stances. A house view comprises a universe of companies together with an index. Periodically, active bets (overweight and underweight relative to the index) are specified on the universe. These active bets add up to zero and can be thought of as a theoretical long-short portfolio.
A house view can be related to multiple mandates that are stipulated by institutional clients. Every mandate has an underlying benchmark. The House View and Mandate generate a model portfolio for the client under consideration.
In this example, the developers would create the said data model containing concepts such as ‘House Views’, ‘Mandates’, ‘Indices’ etc. The data model is a prerequisite to building the application that generates the model portfolio for each mandate.
In the real life example, the problem evolved to allowing mandates to have constraints and an associated risk profile. The risk profiles were specified as being either High, Medium or Low. Mandate constraints included statements of the form:
; 
In a standard development life-cycle, these new requirements would result in an underlying schema change. Software engineers would need to model the data (e.g. include the new concepts such as ‘Constraints’ and ‘Risk Profiles’) and thereafter validate the new data model version, as shown below. Changing the underlying data model would result in a new release. This is a necessarily lengthy process that involves black box, white box and user testing. The turn-around time to implement these additional features could be months.
Now consider a completely different use case. An Operational Data Store for an insurance company. The business solution required modelling both the asset and liability side of every transaction. In this use case, completely different business concepts arise relative to the previous example. Every ‘trade‘ is related to multiple ‘transactions‘. A ‘transaction’ can have an associated ‘policy’, ‘counter-party’, ‘liability product’ and ‘book’. Every ‘book’ is associated with a ‘desk’ and a ‘life license’. It is clear that a very different data model applies to this use case.
Now, what does Quintessence bring to the party? The Quintessence advantage is that we have decoupled the data schema, either persistently stored or cached, from the data model. Quintessence allows clients to create and add artefacts onto their data model as and when they need to. This layer of indirection between the data model and the underlying schema allows for rapid changes and enhancements to applications, as required in an agile development environment. It also is a prerequisite for data virtualisation.
The Quintessence Data Model is known as the Entity-Factor Model. It is best represented in the simple diagram below.
Firstly, basically everything is an entity: A currency, company, bond, future, option, fund manager, region, country, analyst … the list goes on. The key requirement is that entities have codes. Each entity can have multiple codes associated with them e.g. a Bloomberg, ISIN, SEDOL and RIC code. Entities can be related to other entities via a relationship. These two aspects allow us to incorporate symbology i.e. a company’s corporate or risk structure together with all the codes associated with each entity you encounter as you walk the tree representing the structure. Data can be associated with an entity e.g. Name, Close Price, Volatility Surface. Data can also be associated on a relationship between entities e.g. the ‘Weight‘ (Data) of the ‘Constituents’ (Relationship) of an ‘Index’ (Entity).
These simple constructs allow us to create any data model that is applicable and required in the financial markets. This, together with each model’s inherent malleability, provide Quintessence data engineers with the tools they need to develop flexible and robust industrial-strength solutions.
Feel free to contact me for more information and to learn about additional Quintessence features!
