Since April 2020 release, commercial license holders get the four thousand-entity DEV version in addition to the normative data model derived from FIBO production.
This article defines FIBO/FIB-DM production and development as normative and informative versions of the model. We explain how to use the two models in a model-driven architecture.
The Enterprise Data Management Council (EDMC) publishes a Production and Development version of the Financial Industry Business Ontology (FIBO) quarterly. Jayzed Data Models (“Jayzed”) used to derive a Financial Industry Business Data Model from the FIBO when a new module went into production.
FIBO review process
The EDMC and Object Management Group (OMG) review to promote ontology content into the industry standard is very thorough and slow. As of 31 March 2020, FIBO Production has eight modules, 1813 named classes and object properties, five more modules, and 2603 objects are still in development. Financial Institutions should support the council and provide ontologists, and subject matter experts to accelerate the industry standard. The EDMC FIBO team and JDM invited data architects to participate.
Last September, Jayzed released the Open Source FIB-DM core derived from FIBO Foundation, Business Entities, and Finance Business & Commerce modules – a one thousand entity data model. One thousand four hundred users from over two hundred financial institutions downloaded FIB-DM core.
Alas, user statistics show three-quarters of downloaders
Deriving a FIBO Data Model
Semantics for Data Architects, the popular FIB-DM education module, describes the ontology to data model mapping as well as structure and content. You can read the article, watch the webinar on YouTube or download the PowerPoint.
The Configurable Ontology to Data model Transformation (CODT) is the technology used to derive FIB-DM from the FIBO. The latest CODT version Atlantic fully automates the metadata transformation.
Hence, we can transform two FIBO versions quarterly, rather than one model per year.
FIBO Production vs. Development version
The EDM Council publishes updates to the FIBO specification four times a year. At the beginning of a new quarter, ontologists can download a new version from the EDMC website. There are two levels of maturity:
- “FIBO Production is published at the end of each calendar quarter and has been vetted by SMEs and passed standard industry hygiene tests for OWL.” (https://spec.edmcouncil.org/fibo/OWL)
The ontology passes tests for mandatory FIBO annotation properties (documentation), internal completeness, and integrity. In other words, FIBO users can expect the ontology to open in the reference ontology editor, Protégé, and major inference engines (reasoners). As a result, and essential for ontologists and data architects, FIBO Production is very stable. While the council adds content from Development, changes to the published design are rare and limited.
The council’s collaboration with the Object Management Group (OMG) ensures quality at par with other standard-setting bodies.
FIBO Production establishes a Financial Industry Standard – it is normative.
- “FIBO Development is published in real-time as changes are incorporated by the FIBO Community and consist of a draft as well-vetted content.” (https://spec.edmcouncil.org/fibo/OWL)
Published in real-time means that the source code repository, GitHub, reflects new and updated content throughout the 3-month development cycle. However, each quarterly release is a baseline that just like Production passes technical tests, except for documentation. Out of 3097 classes in the latest release, 2526 have documentation. We should consider modules with undocumented classes as a draft.
The Development content eventually completes expert reviews and promote to Production. FIBO Development is more volatile than Production. However, structural changes rarely redesign modules, but classes may move from one module to another. For example, a class or object property in a specialized module like Loans may move to a core module, Foundation, Business Entities, or Finance Business & Commerce.
FIBO Development is the future the industry standard – it is informative.
FIB-DM Normative vs. informative
The Venn diagram shows FIB-DM DEV packages of the whole informative model in the larger circle. Inside, the smaller circle contains the normative PROD packages that comprise the confirmed industry standard.
The table lists data model package code, name, and definition (comment on a data model object).
|FND||Foundation||The Foundation package defines basic building blocks for the other packages. All packages depend on Foundation.|
|BE||Business Entities||The Business Entities package defines legal entities and formal organizations.|
|FBC||Finance Business & Commerce||The package defines functional entities, products and services, debt and equities and financial instruments.|
|SEC||Securities||The package for securities has more than six hundred entities modeling stocks and bonds.|
|DER||Derivatives||The package for Derivative instruments.|
|IND||Indexes & Indicators||The package with entities to model Economic and Financial Indicators.|
|LCC||Languages, Countries & Currencies||The base package defines Languages, Countries, and Currencies according to ISO norms 639, 3166, and 4217.|
|LOANs||Loans||The most significant new package with more than three hundred entities. Sub packages Loan Core & Mortgage and Extended provide the framework. Loan temporal covers origination, status, and payments. Loan Types defines subtype entities for retail and commercial loans.|
|CAE||Corporate Actions & Events||A Corporate Action is an event that brings a material change to the company or securities issued by the company. Two hundred seventy new base entities support Corporate Actions for bonds and shares, as well as communications and elections.|
|CIV||Collective Investment Vehicles||The new package for Investment Funds has two hundred fifty entities defining Fund types, strategy, administration, units, and management.|
|MD||Market Data||Two hundred entities in the package model price and trade-related data for a financial instrument reported by a trading venue such as a stock exchange.|
|BP||Business Processes||The focus of four hundred Business Processes is on Securities Issuance and the Financial Context of Trade, Clearing, Settlement, Custody, and Market.|
The 2020/Q1 release specifications has the full entity list report with code, name, definition, and entity type (base or associative entity).
- FIB-DM PROD, 1968 entities
Foundation, Business Entities, Finance Business & Commerce, Securities, Derivatives, Indexes & Indicators, and Languages, Countries & Currencies.
- FIB-DM DEV, 4,563 entities
Collective Investment Vehicles, Corporate Actions & Events, Loans, Market Data, and Business Processes
Maturity of the Informative Model
The Council states that the FIBO Development version contains both well-vetted and draft content. Documentation, the population of the “skos
3274 of the 4563 FIB-DM Entities, roughly three quarters have a comment field populated from FIBO “skos
The bar chart below breaks down well-vetted vs. draft entities per package,
We notice that the core modules, FND, BE, and FBC are almost fully documented, 100% in case of Business Entities. The new modules, CAE, CIV, MD, and LOAN have definitions for the most part, except for Business Process, which is mostly still in draft.
EDM Council and FIB-DM
The Enterprise Data Management Council wants its members to leverage the full potential of the FIBO. Hence, the council has been very supportive of the FIBO Data model and even features FIB-DM as a Partner product on the EDMC website.
There are two main use cases how the data model expands adaptation and implementation of the industry standard ontology.
First, the data model is an enabler for midsize member institutions that do not have the semantic capabilities yet. OWL requires specialized tooling, databases, and human expertise. FIB-DM enables data architects at medium-sized members to implement the FIBO with their existing modeling tools and on relational database management systems (RDBMS).
Second, the FIBO can transform the whole enterprise architecture – beyond Knowledge Graphs and Business Glossaries.
Semantic Enterprise Information Architecture (SEIA) places the ontology, for Finance that is the FIBO, at the apex of the model-driven hierarchy. Ontology-derived models for data, object, message, and process leverage the design and ensure common names, definitions, and design patterns across the enterprise. SEIA facilitates data integration and interlinking.
At a FIB-DM presentation and Q&A, the head of knowledge innovations at a large US Bank said that “98% of the bank still runs on RDBMS.”
SPARQL, the RDF query language, is as powerful as SQL for data retrieval, but UPDATE and DELETE are cumbersome, and there is no equivalent transaction management.
Prediction: RDF databases will grow exponentially measured by installations, volumes, schemata, and users. However, usage will plateau at 10%, and not replace traditional systems of choice for data origination and conventional BI and reporting.
In summary, even large financial institutions still need relational databases and therefore data models and architects.
My article, last year showed that an Enterprise Conceptual Data Model derived from an authoritative Domain Ontology is not only an isomorphic submodel but also the optimal relational design
Semantic Model-Driven Development (MDD) Guidelines
This section is the autoritative advise how to best use the normative and informative models to create databases and applications, that conform with the industry standard, and integrate with each other and in the future, the FIBO Knowledge Graph.
Tangible value through implementation
The bottom box, Implementation is the crucial part of the MDD diagram. Tangible applications and databases in core banking, (and investment management) and BI enable the business and drive value.
- UML models and
generateJava and other application code.
- Logical and Physical data model to generate RDBMS schemas.
The Normative Models takes precedence
FIB-DM Production based on the industry standard is authoritative for names, definitions, and design. We look at the normative model first before considering informative models.
First, we derive scope from the normative model. Then, we derive entities, relationships, and attributes from informative models.
The diagram depicts an Enterprise Data Model (EDW) scoped from FIB-DM Production. Many Financial Institutions already went through year-long exercises defining and EDW. Data Architects frequently ask: “Do we have to do it all over again for FIBO?” No, you don’t. You can either
- Declare FIB-DM Production your Enterprise Data Model.
In this scenario, you don’t need EDW in the MDD diagram. You directly derive implementation models from FIB-DM Production.
- Gradually, and top-down, you ultimate supertypes with the FIBO-FIB-DM 15 concepts. Then, project by project, you transform your EDW into industry-standard conformance.
Informative models extend and detail the design
We already defined FIB-DM Development as an Informative reference data model. Other examples are your inhouse data models, vendor models, and industry standards like ISO 20020 for messages.
Widely used vendor model are
- IBM Banking and Financial Markets Data Warehouse Model (BFMDW)
- Teradata Financial Services Logical Data Model (FSLDM)
- Goldensource, Security Master Model.
- Bloomberg Data Model Encyclopedia (BDME)
Detailing the design
FIBO and FIB-DM are conceptual business models. The FIBO has few data properties, and therefore, the derived conceptual data model (CDM) is at an entity level.
To detail the design means to attribute the FIBO data model, thus creating a Logical Data Model (LDM) from the normative CDM. Here the informative vendor models and other industry standards provide excellent content.
For example, if your organization has a BFMDW license, you should copy Involved Party attributes onto the appropriate FIB-DM Autonomous Agent and Thing in Role entities.
See Semantics for Finance Users‘ education module for a detailed treatment of the 15 FIBO/FIB-DM fundamental concepts.
However, you must be very careful not to overwrite normative elements with informative design. In other words, before adding BFMDW entities, make sure the concept does not already exist in the FIBO Data Model
Extending the FIBO Data Model
There are two types of use cases to FIB-DM extension, creating new subject areas (packages), and adding new additional fundamental concepts.
The first type is straightforward. With business requirements or existing informative model areas, we create a concept map using the fifteen fundamental concepts. In practice, we classify our data items in terms of concept, Autonomous Agent, Thing in Role, Agreement, Service, Product, Reference, and so on.
Then, we add the new entities subtypes to the FIB-DM concept hierarchy. For example, if we want to add Credit Cards to FIB-DM, we classify it as a Product and add and entity under the appropriate Product entity. In this case, LOANS already has a draft entity (
fibo-loan-typ-cr:CreditCard). We can add further subtypes for different types of credit cards, specialized Accounts, Occurrences, Conditions, etc.
For the second type, we must use the utmost care before adding an entity that does not subtype to an existing FIB-DM entity. In other words before adding new ultimate supertypes to the model
Any new ultimate supertype with a lot of subtype entities underneath becomes a new fundamental concept.
Notable FIBO Foundation defines all 15 fundamental concepts. That means that current and future FIBO subject area classes are subclass of a superclass in FND.
The Involved Party is dead, long live the Autonomous Agent!Robert II d’Uzès 1422, proclaiming Charles VII the King of France
For example, the IBM BFMDW model, Teradata, and many in-house Enterprise Data Models have an ill-conceived concept of the Involved Party. That ultimate supertype comingles the FIBO concepts of Autonomous Agent and Thing in Role. In FIBO and FIB-DM, you, the person are exactly one record in Autonomous Agent. You can have many Thing in Role records as a customer, employee, investor, and so on. The Person and her roles are separate concepts; rolling them up to a common supertype is wrong and can lead to data integrity errors. Likewise, FIBO differentiates between Product and Service. The Service is not a subtype of product!
The EDM Council publishes a normative and informative version of the financial industry standard. Starting with the April 2020 release, commercial licenses receive an informative FIB-DM DEV model derived from the FIBO Development version. The informative model adds two thousand five hundred entities and new modules for loans, corporate actions, funds, and business processes.
We explained Semantic Model Driven Architecture using both FIB-DM, as well as in-house and vendor models. Data Architects should detail, and extend the FIBO Data Model leveraging content from other non-normative models. However, we must analyze thoroughly before adding new entities, in particular new ultimate supertypes.
Thanks for reading. Please email me your questions or comment on the LinkedIn version of this article.
Jurgen Ziemer, Ontologist & Data Architect at Jayzed Data Models Inc, firstname.lastname@example.org
The canonical version of this article: https://fib-dm.com/normative-and-informative-fibo-data-model-version/
LinkedIn version: https://www.linkedin.com/pulse/normative-informative-fibo-data-model-versions-jurgen-ziemer-1c
Full Data Model upgrade: https://fib-dm.com/full-data-model-upgrade/
Atlantic CODT, the Configurable Ontology to Data Model Transformation: https://fib-dm.com/atlantic-codt/
Semantics for Finance User (15 concepts): https://fib-dm.com/semantics-for-finance-users/
Scoping a data model using the 15 concepts: https://fib-dm.com/education-module-scoping-our-first-data-model/
FIB-DM on the EDM Council FIBO Portal: https://spec.edmcouncil.org/fibo/FIB-DM