Data and Technology Subcommittee: Financial Instrument Reference Database Recommendation

The OFR is obligated to “prepare and publish” a financial instrument reference database (FIRD) under Title I of the Dodd‐Frank Wall Street and Consumer Protection Act (DFA).

OFR has concluded  that ontology is a critical component of their instrument database objective and essential as the “Rosetta stone” for ensuring comparability across the financial system (see OFR 2014 Annual Report, Chapter 5, Section 5.6).  OFR has suggested that the definition and publication of criteria for financial instrument ontology would help move the FIRD initiative forward and be instrumental in addressing the harmonization of reference data needed for systemic risk analysis.

The Data and Technology Subcommittee (DTS) has developed a set of general criteria for financial ontologies that can contribute OFR’s FIRD ontology objective.  The draft criteria also reflect feedback from industry and data semantic experts.  The DTS views this document as a good starting point for developing requirements for ontologies to be part of the OFR’s FIRD.  We seek endorsement from FRAC for its submission to OFR.

​Criteria	​Why Important
Submitter/Organization must own the intellectual property and agree to make it available (open source)	Must be open source to be accepted by the industry (non proprietary Can’t submit something you don’t own
Access to the ontology may require registration, but only for quality control	Useful to track who is using so that you have an ability to engage with stakeholders for improvements and enhancement notification Full transparency on any changes Support the (continuous improvement/agile principles) within the GitHub collaborative development process. Within GitHub, anyone can download, anyone can suggest changes, changes are committed to the official standard only when they are accepted according to the standards governance process
Content must be maintained	Data management is not static An out‐of‐date ontology is not useful for a dynamic industry
Content must be extensible (can build upon the foundation, but not override)	Financial market engineering is not static.  The ontology must evolve along with industry innovation Good ontology is modular and must have the ability to add new data components, new relationship facts and new content types as they are developed Must be able to add new components without re‐doing the ontology
Must use W3C standards and be framed in formal logic (to be machine readable)	The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies OWL was developed based upon projects funded by DARPA and the EUs Information Society Technologies using formal semantics based on a description logic OWL is endorsed (and maintained) by the World Wide Web Consortium (W3C) and is the basis for the Semantic Web ( a common framework that allows data to be shared and reused across application, enterprise, and community boundaries)
Quality assurance testing must be performed	The information architecture must be able to automatically validate the integrity of the content of financial transactions The ontology must ensure that the expression of the instrument (all components, facts and relationships) is valid, aligns to meaning and conforms to business logic
Metadata is required to link the granular concepts to source systems to data	Metadata must be linked, aligned and integrated into the ontology – so that users can understand (lineage, provenance) Content (i.e. links to regulatory rules, internal policies, and industry reference points) is intertwined within ontology. Must not make users search for metadata and links – they need to exist within the ontology
Must be able to support the full range of use cases (practical business value)	Ontology needs to be able to support classification and aggregation (based on factual components) as well as flexible queries for risk analysis and data alignment Must be able to perform transitive analysis (i.e. financial transactions between counterparties, their ownership and control relationships, key variables that reflect market conditions, obligations based on role and direct/indirect exposures) Conceptual model must be able to validate that financial instruments are correctly represented by providers (verify that the instrument is performing according to the contractual requirements) Linked risk analysis is not bounded – must support any line of inquiry. The ontology must be both practical and useful – Flexibility is critical for scenario‐based analysis
Ontology must define "business concepts" and not be tied to any technical design or features	Ontology implementation must not be linked to any specific vendor tool (vendor agnostic) Must be able to harmonize disparately named content across multiple message types Financial instruments and processes are REAL things (as defined in the contract) and we need to ensure that we can express the contract in a way that aligns with reality
Conceptual model must support the representation of industry standardized definitions	Standard definitions (terms, definitions AND relationships) of financial contracts, financial instruments and their attributes are essential to ensure conformity Ontology must facilitate harmonization and alignment across the industry (Rosetta stone)
Legal entity component of ontology must support a multi‐dimensional view of legal entities	Must understand entity types, ownership and control relationships, subsidiaries and affiliates Must be able to unravel ownership and control across all legal jurisdictions and based on all roles performed in the financial process
Concepts and data must be representable	Financial industry is complex and interconnected.  Must be able to leverage graph analytics to support network traversal, predictive models and path analysis Must be able to visualize the network components to make them useful (understandable to real people)
Must have the ability to partition data into a time series for temporal (time and date) analysis	Must be able to express prices (at time). Must be able to capture cash flow over time based on the terms and conditions of the contract as market conditions vary Must be able to put this in a model that illustrates exposure across multiple participants