Deep dive · August 18, 2026 · 12 min read

FIBO ontology explained.

What the Financial Industry Business Ontology is, why every major bank now touches it, and a pragmatic path to adopting it inside your knowledge graph or GraphRAG project: without boiling the ocean.

The short answer

FIBO is a public, standardised OWL/RDF ontology maintained by the Enterprise Data Management Council. It defines instruments, contracts, parties, and processes in a rigorously typed way that lets banks agree on what "a swap" or "a legal entity" actually is: inside their firm and across the industry. You do not adopt all of FIBO; you align the parts of your graph that map to it, and use it as a semantic anchor.

What FIBO covers

FIBO is organised into families of ontologies: Foundations (fundamental patterns like agents, roles, dates), Business Entities (legal entities, ownership, control), Financial Business and Commerce (contracts, agreements), Loans, Securities, Derivatives, Market Data, Indices and Indicators, Corporate Actions, and Business Process. Each family is broken into modules; each module contains classes, properties, and axioms in OWL 2.

The whole thing is machine readable, published under a CC BY 4.0 license, and versioned quarterly. You can browse it at spec.edmcouncil.org.

Why banks care

Regulatory alignment. Regulators (ECB, Fed, FCA) increasingly reference FIBO in guidance around risk aggregation and reporting. Aligning internal models to FIBO shortens the distance from data to submitted numbers.
Cross firm interoperability. Common vocabularies are what make CDM, ISDA, and industry utility data flows work. FIBO underlies a growing chunk of that stack.
Internal coherence. Every large bank has 40 different definitions of "counterparty" scattered across systems. FIBO is the closest thing to a neutral referee.
AI grounding. When your knowledge graph is FIBO aligned, downstream GraphRAG and agent systems inherit a real semantic model instead of ad hoc naming.

The pragmatic adoption path

Boiling the ocean on FIBO adoption is the standard failure mode. The pragmatic sequence:

Pick one use case. Legal entity resolution, product master, counterparty risk aggregation: anything with a clear owner and a business problem.
Extract the relevant FIBO subset. Use the module you need (e.g. Legal Entity family) as is; ignore the rest for now.
Map your internal terms into it. Your existing entity types become subclasses of FIBO classes; your properties align to FIBO properties. Where they don't map cleanly, extend FIBO with your own subclasses (don't redefine).
Load into a graph store. Any RDF capable store (Stardog, GraphDB, Blazegraph, Amazon Neptune, Neo4j via neosemantics). Query in SPARQL or Cypher.
Expand incrementally. Each new use case picks up more of FIBO. The parts you never touch stay unloaded.

Common pitfalls

Treating FIBO as ETL target. It's a semantic model, not a data model. Your database schemas do not need to look like OWL. Alignment happens in the graph layer.
Overloading a single project. FIBO adoption is a multi year direction, not a project. Baby steps ship value; big bang programs run aground.
Ignoring versioning. FIBO releases quarterly. Pin a version per environment and upgrade deliberately.