FIBO: An Ontology for What Financial Data Actually Means

A vocabulary, not a schema

The Financial Industry Business Ontology defines the sets of things that are of interest in financial business applications and the ways those things can relate to one another. That is the scope: it is not a database design and not a message format, it is a statement of what the concepts are and how they connect. FIBO is a formal ontology providing a common vocabulary for financial contracts and related concepts, developed in the Web Ontology Language, which the W3C codifies and which is based on Description Logic. The logic is what makes the vocabulary load-bearing, since it ensures each concept is framed in a way that is unambiguous and readable both by humans and machines. The intended payoff is stated directly: in this way FIBO can give meaning to any data, whether spreadsheets, relational databases or XML documents, that describes the business of finance.

Why it exists: the 2008 financial crisis

The origin story is unusual for a standards body and worth knowing, because it explains the design choices. FIBO evolved out of concerns that arose during the 2008 financial crisis among individuals who worked together in data governance and management, to address requirements for standardized terminology for regulatory reporting and other analyses. In other words, the problem was not that people lacked models but that the models were not comparable, and a report assembled from several systems could not be trusted to mean the same thing in each of them. The ontology has continued to grow and evolve since its initial publication in 2014, with increasing support for use cases related to securities master data management, reporting, and risk analysis and management. The mission since January 2020 has been to develop, maintain and promote a global, platform-independent, machine-readable and unambiguous data standard that enables understanding of financial terminology, cross-system federation and aggregation of data.

The domain directories and what each one covers

The repository is organised by domain, and the directory table explains what each one is for. The BE directory holds the Business Entities domain, which defines the business concepts used for data governance, interoperability and regulatory reporting about business entities. The BP directory holds Business Process ontologies, defining financial process flows such as securities issuance and transaction workflows, and the readme is specific about why process models exist at all: in the case of securities issuance process models they are provided in order to represent reference data concepts that depend on the process by which a security was issued, and transaction process semantics provide the basis for the temporal dimension of securities and derivatives transactions. The CAE directory holds Corporate Actions and Events, covering events that may occur during the life of a security and typically cause some change in the underlying reference information. The other directories visible in the tree cover derivatives, examples, financial business and concepts, foundational, instruments, loans, master data and securities.

The artefacts at the root and what they are for

The repository root carries the metadata that describes the whole ontology. There are several About files in RDF, including AboutFIBOProd.rdf, AboutFIBOProd-TBoxOnly.rdf, AboutFIBOProd-IncludingReferenceData.rdf and the corresponding Dev variants, plus AboutFIBODev.rdf and AboutFIBODev-TBoxOnly.rdf. The distinction those names encode is the difference between the full ontology, the version restricted to the terminological box, and the version that includes reference data, and the split between the development and production variants. There is a MetadataFIBO.rdf, a catalog-v001.xml, an ACTUS directory, and an etc/ directory. The OWL files are the substance; the About and catalog files are the entry points that tell a consumer what is inside and how to navigate it.

Who reviews it, and how it is standardised

Two organisations sit behind the project and they play different roles. FIBO is hosted and sponsored by the Enterprise Data Management Council, and it is standardized by the Object Management Group under a shared marketing and trademark agreement. The trademark point is worth noting, since FIBO is a trademark of EDM Council, so the name itself is protected even though the code under the MIT licence is not. On the review side, FIBO concepts have been reviewed by EDMC member firms over the years and represent a consensus of the common concepts as understood by the industry and as reflected in industry data models and message standards. That consensus is the actual product. A vocabulary written by one vendor is a schema; a vocabulary reviewed by competing firms is a standard, and the difference is what makes it usable as a bridge between systems that do not share a vendor.

The viewer, and the publication formats

FIBO is published in a number of human and machine-readable formats for use in business and operational settings, ranging from online glossaries to rich knowledge graph applications. The FIBO Viewer is a web application specifically designed to access both the FIBO structure and its content stored in the repository in the easiest possible way, and the readme emphasises that you do not need to install any software to enjoy FIBO. That matters for adoption, because the first question an ontology raises is how anyone is supposed to read it. Each domain in the directory table has a corresponding link into the viewer, so a reader can start from a domain they care about rather than from the root of the ontology. The formal updates are published quarterly, and the release tags follow that cadence with master_2026Q1, master_2026Q2 and master_2025Q4.

Continuous revision by domain teams, quarterly formal releases

The two cadences are the part that shapes how you use it. Revisions are made on a continuous basis by several teams addressing specific domain areas, such as securities, derivatives and indices, available in GitHub, with formal updates published quarterly. The practical consequence is that the Git history is the working surface and the quarterly release is the stable snapshot you point a production system at. That is a sensible arrangement for a standard of this size, since a full formal release of an ontology covering business entities, processes, corporate actions, derivatives, instruments and loans is a review and approval event, not something you can do continuously. It also means there is always a moving edge and a stable point, and a team that pins to a tag has a defensible answer when an auditor asks which version produced a report.

Contributing, the DCO, and where to ask questions

The development process is described as rigorous and well-defined, with CONTRIBUTING.md and ONTOLOGY_GUIDE.md holding the details, and the activity documented on a FIBO Confluence space and across the EDMC projects space in Jira. The Developer Certificate of Origin is enforced with the Probot DCO framework, which requires every commit message to carry a Signed-off-by line with an email address matching the commit author, and contributors sign off that they adhere to those requirements. Discussion has two channels, with the preferred one for topics that are not specific to an issue, pull request, wiki page or artefact being the EDMConnect FIBO Interest Group, and GitHub Discussions reserved for concrete changes to the FIBO code. The project adheres to the Contributor Covenant code of conduct, with reports going to [email protected].

Editorial conclusion

FIBO fits a financial institution whose systems describe the same instruments with different names, and whose reporting has to be reconciled across them. It is the wrong tool for a small team that only needs a data dictionary, since an ontology is a governance commitment rather than a schema, and it is the wrong tool if you need something immediately implementable, because the quarterly release cycle and the review process sit between a question and an answer. Before you adopt it, map two of your existing entity models onto the FIBO domains and see whether the disagreements are naming differences or genuine modelling differences.

Frequently asked questions

Official sources

1. edmcouncil/fibo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases