© ObjectCentric Solutions, Inc., 1999
Data Model. Background and Business
Niche Analysis
“Large-cap” clients – Open Finance
Laboratory benefits
“Medium-cap” clients – Open Finance
Laboratory benefits
“Small-cap” clients – Open Finance
Laboratory benefits
Narrative
Data Model has been designed to meet requirements of financial applications like trading, risk and portfolio management, and fixed-income research.
Compact Data Model is constructed as a small core system to simplify inevitable client customization procedures. Design intention was to use Data Model as boot-able expandable set of database objects.
“Big” company at some point decided to use “blue-chip” decision-support system (DSS) vendor, let’s say it happened to be Reuters or IQ Financial Systems. Normally, Big has diversified businesses and has to use different DSS for better tailoring to its business lines. Later, upper management issued requirement to consolidate all Big positions to have integrated view of all Big portfolios. Big would also need advanced reporting tool to analyze data cross different factors. What-if Big faces the situation to customize vendor repository to utilize Big’s proprietary financial models? What-if Big needs to combine within a single application some DSS with the best analytical package for the specific business line, let’s say FX or Money Market? What-if Big must conduct their own development based upon the newest information technology and financial industry standards? What would Big need to come up with the most effective and less costly solution?
(i) To consolidate positions from multiple DSS Big would need additional repository. The repository would contain the most essential for integration purposes financial data, leaving details for DSS;
(ii) Big would need the generalized reporting tool based on dynamic multi-factor analysis; this will allow to view the same financial data under multiple angles;
(iii) The system must be true flexible; there should be simple paradigms to plug-in or construct new financial models, factors or add extra attributes to existing data objects;
(iv) The system framework for data base objects managing should be a collection of small, “one-function-served”, modules;
(v) The system should allow integration with financial analytical and data acquisition packages, and financial exchange protocols based upon open standards;
(vi) The system should be inexpensive, easy to customize, to use and not to make customer as a “system” dependent.
Solution: the Big would need light-weighted system to simplify data integration, open standards support, flexibility in using multiple financial engineering models and tools.
“Medium” has just a couple lines of businesses. It ca not afford to pay multi-million license fees for DSS. It also employs proprietary business/financial models. I any case, Medium relies on its own systems. Medium now realizes that it can use more sophisticated analytical models for exotic options evaluation. Medium would like to use combination of both proprietary and “third-party” financial engineering analytical tools. Medium can smoothly integrate new tools with existing application if the new tools were based upon open standards. Also Medium is planning to move to Data Warehouse architecture and, therefore, redesign its existing data repository. This will allow Medium to “deepen” data analysis and to use multi-factor data consolidation reporting tools. What would constitute the Medium “wish list”?
(i) To start development of new data repository not from scratch, but rather from pre-defined data objects;
(ii) To use “atomic” operations on pre-defined objects; this is true-reuse approach because it allows to utilize fully-functional code base to derive customized, application-driven extensions;
(iii) To use standardized components for financial instruments computation and to have this components integrated with Data Warehouse; this will eventually allow to replace “aged’ analytical tool by the modern one in hopefully the less painful way;
(iv) The system should be inexpensive, truly flexible, “rubber band-kind-of”.
Solution: the Medium would need light-weighted system to support modern Data Warehouse philosophy, data base objects re-usability and customization. Medium looks for minimum dependency from the vendor.
This group of clients can include research departments of universities and financial institutions, small development teams, trading desks, etc. Most of them would face the same set of problems: to have simple, inexpensive back-office system to support dynamically modifiable financial and/or computational models. This group of clients would rather follow open standards and forums than vendor-dictated solutions. The “small” clients normally develop pilot (experimental) systems for further utilization of advanced business intelligence methods/methodologies in commercial applications or in production environment.
What would be the most valuable set of requirements to satisfy this group of clients?
(i) To have kind of boot-able system: start from something simple and really useful and continue to add power utilizing pre-existing data model and set of “atomic” operations on database objects;
(ii) To plug-in financial engineering computational models, data acquisition packages in simple, transparent mode;
(iii) To support the process of developing new sophisticated financial models.
Solution: “small” client would need light-weighted system to support flexibility in financial modeling and computational methods plugging-in.
Open Finance
Laboratory Data Model Manifesto
1. Compact, expandable data model.
2. Simple, practical paradigm to construct new instruments from existing ones.
3. Multidimensional model to represent different factors like position or instruments attributes.
4. Powerful set of functions to construct factor hierarchies and even graphs.
5. Simple paradigm for grouping positions into portfolios.
6. Flexibility in calculation methods plugging in.
7. Emerging information technology and financial industry standards support.
Open Finance
Laboratory Data Model Design Principle
“Make modeling simple but not simpler than it actually is”. Looks like a number of systems can cover some business lines requirements pretty good today, but what if a client needs some enhancements tomorrow? Should the client wait for the new version of the system from the vendor? Or could the client easily customize the system to meet business needs? If the latter way sounds the preferable one, then the question would be: how to design the system, which already includes many useful objects/components (NOT definitely EVERYTHING!) and also provides the clean understandable way for the “start-up” data model customization? Is there a way to find “golden middle”: provide basic (but really useful!) functionality and at the same time keep the door open for client-driven extensions? We would suggest that the data model framework design principle is to be committed to the above-mentioned “golden middle” philosophy.
The system core is Open Finance Laboratory Data Model. It is the set of data base objects and operations to manipulate on them. Based upon Data Model is the following set of sub-systems:
1. RateOpener – set of classes to serve as a gateway to publicly available rates;
2. DataMartOpener – set of classes to navigate, browse and administer data model;
3. InstrumentOpener – set of add-ons to serve as interface components to financial engineering and data acquisition packages;
4.
ReportOpener – generic
customizable reporting framework.
Consists of the following groups:
Multidimensional Data Model Paradigm Support
Normally business objects can be tagged by some factors. Let’s say someone would like to view positions with respect to business lines or by branches. Or simply analyze position by maturity buckets or by currencies. What is in common for business lines, branches, currencies or maturity? They can be considered as position dimensions. A dimension can be a simple vector like Currency or Maturity or it can be hierarchical, tree-like one. Business Lines or Geography are examples of trees. Ex.: {Europe}=> {France, Spain}; {France}=>{Paris, Marcel}; {Spain}=>{Madrid, Barcelona, Toledo}. Each dimension node refers to dimension name; it contains node’s identifier, description, value and “color”. Therefore, simple descriptive data can be considered as dimensions. Any node can be either root node, or leaf one, or intermediate node. Primitives allow to add or delete new dimension; add or delete a node to dimension, and to manage tree structures (inject or collapse node; connect or disconnect a sub-tree, etc.).
Defines association between Financial Model and Computation Methods. There can be “one-to-many” relationships between a model and methods; one of the methods is tagged as the active method. Basically method refers to the appropriate executable.
Rate definition consists of the rate name, source system, rate type and category. Rate definition can be primary, i.e. originated from some source system, or secondary (and so far) one, derived from the primary definition. Actual rates (or to be precise, the history of rates) are kept separately from Rate definition. That is RateOpener, which populates real-time or delayed rates into database.
Defined somewhat similar to rates: rating definition and actual ratings (rating history) are kept separately.
Instruments and positions (transactions) are ranked independently; the same position might have multiple ratings from different credit rating agencies for the same or different time frame.
Position definition normally refers to an instrument and includes position amount. Position can be primitive one or composite position, which in other words is just a Portfolio! Portfolio itself could be constructed as an aggregation of primitive positions or another portfolios. Looks like the same composition rules are applicable for both Instruments and Positions. Also at this point it is worth to note that all historical data base objects are structured similarly: rates, and ratings, and positions.
Contains system messages and constants. Also it contains “Meta-Object” to extend another data base objects. To conclude, the following mechanisms can be used to achieve flexibility:
(i) Add new dimension; instrument/position/rates can be tagged by newly created dimension;
(ii) Extend data object by “Meta-Object”;
(iii) And, the most important, system can be extended naturally, by creating new objects. Sounds like this is the obvious approach; but did anybody try just jump into DSS and start adding new tables and modify system code? The catch here is the level of granularity of data objects: the lower the level the easier to re-use and customize data objects, and maintain referential integrity.
6/27/99