Financial Industry Business Data Model

Semantics for Data Architects

This presentation introduces the ontology-derived Enterprise Data Model for Data Architects and Ontologists. The second FIB-DM tutorial covers the ontology transformation and structure of the data model.

Click to open FIB-DM Semantics for Data Architects

The deck reflects updates to ontology and data model metrics, the Configurable Ontology to Data Model Transformation (CODT) patent, and other content.

You are welcome to download the PDF version of the PowerPoint.

Text of the presentation

 Semantics for Data Architects
Financial Industry Business Data Model (FIB-DM)
An introduction to the ontology-derived Enterprise Data Model. Jurgen Ziemer Ontologist & Data Architect at Jayzed Data Models Inc.
https://fib-dm.com © 2025Jayzed Data Models Inc.

FIBO is the authoritative model of Financial Industry concepts, their definitions, and relations.
The Enterprise Data Management Council (EDMC) is the Global Association of over 200 Financial Institutions (FI) teaching

  • Data Management best practices
  • Development and implementation of Data Standards.
    EDMC members developed the Financial Industry Business Ontology (FIBO), a business conceptual model.
    More than 2,457 classes detail financial instruments, business entities, and processes. (as of release 2025/Q3)
    Slide 2

You work at a Financial Institution and already embrace model-driven development, industry standards, and reference models.
Finance business stakeholder and expert with a working knowledge of Entity-Relationship and Ontology diagrams.
Data or Application Architect experienced in Enterprise Reference models. You may have used FIBO design patterns and definitions.
As an Ontologist with an in-depth understanding of the FIBO, you already use the reference ontology for your design and want to spread adaptation across your enterprise.
Slide 3

Introduction to author and publisher
Jurgen Ziemer has 20 years industry experience as a data architect and ontologist at leading Financial Institutions and service providers.
Jayzed Data Models
Accenture

  • Seven years as an IBM Software Group Consultant for the Banking and Financial Markets Data Warehouse (BFMDW) model at 45 banks in North America, Europe, and Asia.
  • Four years implementing BFMDW at Citi and Deutsche Bank. • Speaker at FIBO conferences
    IBM Credit Suisse
    Deutsche Bank
    Jayzed Data Models Inc. is a US consulting company incorporated in 1999.
    Jayzed holds the FIB-DM copyrights and is the assignee of US Patent 12038939
    Citi
    Reuters
    German Stock Exchange
    Slide 4
    There is a chasm between semantic conventional data management.
    The EDMC specified FIBO in Ontology Web Language (OWL).
    FIBO is comprehensive with detailed coverage of business entities, loans, securities, derivatives, and indicators.
    Large financial institutions started implementations on RDF (“triple”) stores and OWL needs highly specialized ontologists.
    Many banks and investment managers don’t have the expertise inhouse.
    IT-departments must still support and design conventional databases.
    Slide 5

FIB-DM is the bridge across the chasm.
Slide 6

The ontology transformed into a data model leverages the design for relational databases.
FIBO RDF OWL
FIB-DM
Data Model
Configurable Ontologyto Data-model Transformation
Semantic Triple Store Relational Database
Slide 7

What is the challenge? (stories)
NY Bank needs Schema for new Security Master System; trying to leverage FIBO for Logical Data Model..
Challenge: Data Architects are not familiar with RDF/OWL and have no experience in Protégé or Topbraid Workaround: Ontologist writes SPARQL queries to extract metadata into MS-Excel spreadsheets.
CT AIM with Hedge Fund Ontology SEC Form PF assessments needs a relational platform
Challenge: Converting operational ontology of some 200 FIBO and hedge fund specific classes Workaround: Manual transcription of graphs into ERWin diagrams. Some metadata extract and import.
• Lookingfor tooling, Protégé and Topbraid do not exportLDMs. • ERWin and PowerDesigner have no import for RDF/OWL.
• Only two less widelyused data modeling tools, Sparx Enterprise Architect and IBM Infosphere Data Architect import RDF XML.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 8

Current tooling imports are not fit for purpose
The first FIBO versions were in Sparx EA. Sparx may be used to create ontology diagrams.
URIs as entity names
Datatype properties become classes
Class restrictions become anonymous pseudo classes
No import of annotation properties
Infosphere Data Architect aborted.
So, I encoded my custom transformation process.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 9

Financial Industry Business Data Model
= in
(and other data modeling tools)

  • Financial Industry Business Data Model of 3,212 Entities, complete definitions, annotations, and axioms (business rules).
  • Data Architects leverage the full content of the Industry Standard.
  • Common Language and design patterns for Semantic & Relational databases.
    Slide 10

Semantic Enterprise Architecture
Use Type
FIB-DM
FIBO
RDF OWL
Level
Business Conceptual FIB-UM Enterprise
Design Logical
Data Model
Department
Physical
Development RDBMS
Implementation
RDF Project
Data Message Process Object
Slide 11

Semantic Model-Driven Development
Conceptual
Logical
Physical

  • FIBO is the domain ontology; FIB-DM is the conceptual data model.
  • A conceptual business model for the Financial Industry and applied at the enterprise level.
  • Logical models for data, message, process, and object derive from the ontology
  • The ontology at the architecture apex ensures common names, definitions and design across the enterprise.
  • Midsize Financial Institution without Semantic Technologies yet, adopt FIB-DM, a compatible enterprise model.
  • Large institutions use CODT to transform their inhouse ontologies into data models for downstream implementation.
    Slide 12

Transformation principles & considerations for the derived data model
1.The model must be practical.
Overly normalized designs become too abstract for business users and developers.
2.The model must be complete.
We don’t want to miss information from the ontology

  1. The model has complete documentation. The diagrams depict all subject areas and design patterns.
    4.The model maps back to its source, the ontology
    Slide 13

Configurable Ontology to Data-model Transformation

  • Source Ontology with connection parameters
  • Target tool and model • Name translation rules • Ontologymodule
  • Anonymous and equivalent classes
  • Object properties • Data properties
  • Annotation List
  • Inverse property list.
    Parameter CODT_HOME Source Ontology Platform
    File directory File or graph
    Excluded modules Excluded classes Target Model Modeling Tool Type
    Name Path
    Transformation Rules Infer Packages Anonymous class Defined class
    Object Properties Data Property Object Naming Rules Code
    Name
    Unique Names
    E/R Comment property
    VALUE
    D:\FIB-DM\CODT Home
    Topbraid Composer
    D:\TBC Workspaces\FIBO-PROD_2025_Q3 FIBO\FIBO_DC_SM_LCC_CMNS.ttl
    owl:Thing; owl:Nothing
    PowerDesigner Conceptual Data Model
    Financial Industry Business Data Model (FIB-DM)
    CODT\PowerDesigner\PD Models\FIB-DM NORM – 0 Excel Imports & Extensions.cdm
    Yes
    Do not transform Separate entity Associative Entity Attribute
    Qname
    Uncamel Localname Yes
    skos:Definition,rdfs:comment
    Slide 14

From FIBO to FIB-DM, to FIBUM – how does CODT work?
The Configurable Ontology to Data-Model Transformation is basic ETL.
RDF OWL
Extract Transform Load
We extract metadata from the source ontology, transform ontology metadata into conceptual data model metadata, and load into the data modeling tool, PowerDesigner.
The extract process runs SPARQL on the ontology to get the metadata. PowerDesigner imports MS-Excel workbooks. The Transformation in between is a 2-step process using the patent-pending Metadata Sets.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 15

The CODT Metadata Sets.
The Extract process populates the Ontology Metadata Sets for classes, object-, data properties, and annotations.
Step 1 Step 2
Ontology Metadata Set

Generic EntityRelationship Metadata Set

Tool-specific Metadata Set
Step one transforms the ontology metadata and populates the generic ER representation. The Tool-specific metadata set is in PowerDesigner format. We serialize as MS-Exceland directly load it into the tool. Step two is a simple conversion from generic ER to PowerDesigner objects, properties, and extended attributes.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 16

Transformation settings for Domain Ontologies
CODT, the patented, US12038939,Configurable Ontologyto Data Model Transformation enables the ontologist and data architect to control the process and mapping.
To transform a domain ontologyinto a practical enterprise data model, we set:

  • Anonymous classes do not transform into entities.
    The setting is to remove the clutter of entities that never become physical from the model.FIB-DM preserves anonymousclasses used in class restrictions in the documentation.
  • Names transform from OWL Camel Case to LDM English Names (capitalization and spaces). E.g. fibo-fbc-fct-fse:DepositoryInstitution becomes DepositoryInstitution
  • Object Properties transform to Associative Entities (not simple relationships).
    This preserves the semantically important object property hierarchy and resolves open-world properties. Domain and Range, and Class Restrictions, determine the parent and child entities related to the associative entity.
    Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 17

From FIBO to FIB-DM
Ontology graph Transformation/mapping
Class to Entity

Conceptual Data Model
DepositoryInstitution
Subclass to Inheritance (subtype)
Object Property to Associative Entity

DepositoryInstitution subtype
Bank
<> Bank – provides (cmns)
<> provides (cmns)
<>
provides (cmns) -Demand Deposit Account
Demand DepositAccount
Class Restrictions, domain and range determine Relationships and Association Links
<>
identifies (cmns) -Demand Deposit Account
<>
identifies (cmns)
<>
Bank Account Identifier – identifies (cmns) (D)
Bank Account Identifier
Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 18

Domain ontology generates a perfect CDM
Ontology graph Conceptual Data Model

This entity-relationshipdiagram is the best representation of the Bank Account, its provider, and ID.
There are no missing and no superfluous entities and relationships in the design.

DepositoryInstitution
DepositoryInstitution subtype
Bank
<> Bank – provides (cmns)
<> provides (cmns)
<>
provides (cmns) -Demand Deposit Account
Demand DepositAccount
<>
identifies (cmns) -Demand Deposit Account
<> identifies (cmns)
<>
Bank Account Identifier – identifies (cmns) (D)
Bank Account Identifier
Slide 19

FIB-DM Core – a one-thousand-entity open-source model
Slide 20

A self-contained standalone data model. Generic OMG Commons OMG Languages, Countries & Currencies Simple Knowledge Organization System Specification Metadata
FIBO Foundation
Domain Core

Free Open Source
FIBO Finance Business & Commerce FIBO Business Entities
FIBO Loans & Mortgages FIBO Business Processes
Domain Core
FIBO Corporate Actions & Events

FIBO Securities
FIBO Derivatives FIBO Indicators

Commercial License
FIBO Market Data FIBO Collective Investment Vehicles
Slide 21

Quick tour and validation
Expand the packages and navigate to LOAN-
Real Estate Loans Open the diagram.
Leaf-level packages transformed from FIBO ontologies.
Higher-level packages are containers to structure the leaf-level packages.
For FIB-DM core, the root-level packages are:
• FND (Foundation)
• BE (Business Entities) • FBC (Finance Business
and Commerce)
Slide 22

Package Properties
The Package Name is the rightmost string in the ontology namespace.
CODT transforms the ontology prefix as the unique code of the package.
Note: All ontology classes, properties with the prefix fibo-fnd-agr-agrbecome model objects of the Agreements package.
The URI is the Uniform Resource Identifier of the ontology. It is a traceability link to the source of the model object.
The Package Properties box has 3 tabs: Annotations, Lineage, and Extended Attributes
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 23

Package annotations
OntologyAnnotation Properties transform to PowerDesigner Extended Attributes.
The tab shows the most common package annotations.
Note that only some packages will have annotations.
The example, OMG CommonsRoles and Compositions shows the Label, Contributors, and a Note.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 24

Package lineage
The Lineage tab shows transformation and FIBO properties.
The Resource Name is the origin for the Package code.
The Resource Type is owl:Ontology
The Abstract is a brief description in some ontologies.
The Copyright and License the original of the source ontology (as required by the OMG and FIBO opensource license).
The FIB-DM license is the Jayzed IPLA for the commercial version and GPL 3.0 for the open-source core.
Please ensure that your derived works retain the Jayzed, OMG, and EDMC copyright and license notes.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 25

Package extended attributes
The PowerDesigner-generated tab list all Package Extended Attributes derived from ontology annotation properties.
After migrations into other data modeling tools the ontology annotations properties may show in their tool-specific representations. For example, ERWin preserves Extended Attributes as User-Defined Properties (UDP).
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 26

Entity properties
The Name is the ontology class Localname, converted from Camel Case to LDM naming convention (capitalizedwith space between words).
The Code transforms from the ontology class Prefix: Localname.
The Comment populates from the class annotation RDFS comment and SKOS definition.
There are two tabs for ontology derived data models, Annotations and Lineage.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 27

Entity annotations
FIBO classes have extensive documentation captured in ontology annotation properties.
Source, Abbreviation, …, to Usage Note are only documented for some classes.
Hence the textboxes are blank for most entities.
A deprecated FIBO class indicates that the concept has been replaced.
Defined By defaults to the source ontology (=the Package code in FIB-DM).
RDFS Comment or SKOS Definition provide the Entity Comment.
Likewise, Label, See Also, Note, Editorial, and Scope Note are only populated for Entities where they are applicable.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 28

Entity lineage
The Lineage tab captures ontology metadata of the source class. The extended attributes provide traceability into the ontology and preserve semantics beyond the entity-relationship model.
The Resource Name is class Prefix and Localname. FIB-DM uses the resource name as the entity code,
but you can generate your codes in the modeling tool.
The Prefix is an abbreviation of the source ontology URI.
The Resource Type indicates the ontology object that derived the data model object: OWL Class, Datatype Property, Object Property, or Ontology.
The Uniform Resource Identifier of the class is a link into the FIBO source ontology.
Restriction and Equivalent class axioms formulate higher OWL semantics. They are important Business Rules for DBAs and developers.
Individual Labels are example values derived from class instances.
Slide 29

Entity Restriction
Class restrictions limit the set of allowable instances. For example, the Obligor must have an Obligation to some Commitment.
fibo-fnd-agr-agr:hasObligation some fibo-fnd-agr-agr:Commitment
Note that the ontology object property hasObligationtransformed into an Associative Entity in the data model. The transformation processes the class restriction and creates Relationships from Obligor to the associative entity hasObligation. Class restrictions also determine relationship cardinality. Here, the Obligor must have at least one obligation.
Class restriction can be very complex logical expressions. Even the Obligor restriction below is beyond ERM expressivity. The Obligor plays a role as a party to an agreement.
fibo-fnd-pty-rl:isPlayedBy some (fibo-fnd-pty-pty:isAPartyTo min 0 fibo-fnd-agr-agr:Agreement)
FIB-DM does not transform anonymous classes (= restrictions) into pseudo entities.
However, FIB-DM preserves these business rules for the benefit of downstream physical modelers and application developers.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 30

Entity Equivalent
Defined Classes in OWL formulate conditions for the set of members. Unlike for the Primitive Class, we don’t CROSTRUCT (~ SQL INSERT) instances of the class. The inference engine, a.k.a. Reasoner determines the instances that match the equivalent condition. For example, the FIBO LEI Registered Entity is equivalent to
cmns-id:isIdentifiedBy some fibo-be-le-lei:LegalEntityIdentifier.
FIB-DM has entities transformed from equivalent classes. The Equivalent Lineage attribute is a hint for the physical modeler to consider a VIEW or ALIAS.
Defined classes may have more complex conditions. For example, the Fixed Float Interest Rate Swap has a Fixed and a Floating Leg.
fibo-der-rtd-irswp:InterestRateSwap and (fibo-der-drc-swp:hasLeg some fibo-der-rtd-irswp:FixedInterestRateLeg) and (fibo-der-drc-swp:hasLeg some fibo-der-rtd-irswp:FloatingInterestRateLeg)
Important business rules for ETL architects populating a FIB-DM database.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 31

Multiple Inheritance
An ontology class can be a subclass of more than one parent class. For example, the Central Bank is both a Bank and a Monetary Authority.
Multiple Inheritance makes sense from a business perspective, and as a conceptualmodel, FIB-DM keeps multiple supertypes.
However, the LDM permits only one supertype. Note that object models also allow multiple inheritances. The Logical Data Modeler can use thesetechniques to resolve multiple inheritances:

  1. The issue goes away. A logical project model derived from FIB-DM may not scope the Monetary Authority. Then the Central Bank has only one supertype, the Bank.
  2. The Logical Modeler changes one or both subtypes into dependent relationships. In the diagram, both Bank and Monetary Authority identifiers constitute the key for the bank.

Bank (D) (D) Monetary Authority
Bank subtype Monetary Authority subtype
Central Bank
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 32

Entity Attributes
The FIBO domain ontologyis a Business Conceptual Model defining concepts with classes and object properties. There are only 232 data properties in the source ontology.
Hence, FIB-DM is an entity-level conceptual data model, sparsely attributed and has no keys.
The PowerDesigner CDM has Data Items. These are model objects independentof the entity. The Data Item then gets attached to the entity as an attribute. Data Items as a model object disappear when the modeler derives an LDM from the CDM.
Currency
The transformation creates Data Items from source ontology data properties. The property domain and class restrictions determine attributes on an entity.

Currency Name Minor Unit Numeric Code Name

Variable characters Variable characters Variable characters Variable characters
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 33

Associative Entities
CODT transforms OntologyObject Properties into Data Model Associative Entities.
Object Property Domain and Range, and class restrictions determine FIB-DM relationshipsbetween Base and Associative Entity. The diagram notationsis yellow for Base and blue for Associative Entities. A stereotype indicates the relationship role, Parent, Child or Dual (both).
In the example diagram a Registrar or Registration Authority registers a Legal Entity Identifier or National Securities Identifying Number.
Object Properties are multi-valued, and thus Associative Entities may have relationships to many Base Entities.
The Logical Data Modeler applies the appropriate LDM design pattern.
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 34

Associative Entity hierarchy
Hierarchies of object properties are an essential OWL construct and widelyused in the FIBO.
The default configurationto transform a domain ontologyinto an EDM, therefore, creates subtypes of Associative Entities from rdfs:subPropertyOf .
<> governs
governssubtype
<>
governs Payment Of

<>
regulates Supply Of

<>
hasJurisdiction

<>
has Governing Jurisdiction
The LDM recommendationis to scope the most specific (lowest level in the hierarchy).
Data Architect Ontologist https://fib-dm.com © 2025Jayzed Data Models Inc. 35

Associations, a Star Schema?
The context diagram below shows the identifies Association and some participating entities.
Indeed, the diagram looks like a Star Schema (with a “factless” fact table in the center). While this is perfectly fine for a dimensional data model, and the model check doesn’t complain, the denormalized design would not be appropriate in a logical data model.
However, as previously done for multiple inheritances, we prioritize the clarity for business users of the design over 4th Normal Form correctness.
The Logical data modeler would
a) Rolename relationships (e.g. identifies Currency)
b) Add a type of identification (e.g. with value Currency_Identification)
Slide 36

Multi-valued association resolved.
After scoping and attribution, the logical data modeler can resolve to 4NF: 1. Once the modeler removes entities without attributes,
the issue may disappear.

  1. The standard 4NF resolution breaks down the identifies association with role-named associations (a subtype of identifies). E.g., Bank Identifier identifies Bank. The entity Lineage tab Restriction on Bank Identifier shows the class restriction.
  2. A relationship Role can be added to stipulate the identifier. For example, a Security Identifier Type can tell the application whether to look for a Security Identifier or National Securities Identifying Number.
  3. The Physical modeler can decide to roll-up or roll-down the identifies subtypes.
    As said before, FIB-DM does not prescribe how the data
    modeler resolves the identifies Currency
    identifies IdentifiesSelector identifies
    identifiesSubtypes
    identifies Bank
    identifiesSelector Type
    identifies Account
    design. Currency is Identified by Currency Currency Identifier identifies Currency
    Bankis Identified by BankIdentifier Bank Identifier identifiesBank Account is Identified by Account Identifier AccountIdentifier identifies Account
    Currency Currency Identifier Bank BankIdentifier Account Account Identifier
    Slide 37

Relationships
FIB-DM uses Associative Entities to model ontology object properties.
Hence, Relationship model objects are merely connecting entities to associative entities. They transform from object property domains and class restrictions.
The naming conventions for the code is “parent entity – child entity.” For example:
ibo-fnd-acc-cur:CurrencyIdentifier_cmns-id:identifies
Likewise, Relationship Name and Comment generate as per CODT configuration settings.
The stereotype indicates the relationship role.
Slide 38

“ONLY” Associative Entities.
Derived from the like named class restriction, “only” Associative Entity limits the participating Base Entities.
The OMG cmns-col:hasMember
object property, for example, has Organization(cmns) numerous related classes.
Thankfully, Organization has a class restriction:
cmns-col:hasMember only
<> has Member (cmns)
has Member (cmns) onlysubtype
cmns-pts:Party
In other words, only a Party (nothing else) can be a member of an Organization.
<>
Organization(cmns) – Organization(cmns) only has Member (cmns)
<>
Organization(cmns) only has Member (cmns)
FIB-DM models the business rule by creating a subtype of has Member with only Organization and Party as related Base Entities.
This concludes the structural overview of the model.

<>
Party- Organization(cmns) onlyhas Member (cmns)
Party
Slide 39

Chasm between semantic and conventional data management.
FIB-DM is the bridge across the chasm.
Slide 40

Core in
(and other data modeling tools) https://fib-dm.com/data-model-download/
Slide 41