What Is a Financial Ontology?

A financial ontology is a formal model of the kinds of things that exist in a financial domain and the permitted relationships among them. It can define, for example, that a legal entity issues a security, a fund holds that security, a filing reports a fact for a period and a source supports a claim. The ontology supplies meaning and constraints. The company records, prices and filings that populate those definitions belong to a knowledge graph or another data store.

We use “financial ontology” as a product architecture term at AllMind. The definition below starts from public standards, then explains how we apply the architecture to institutional research. Product-specific statements about AllMind are our own claims and have not been independently tested for this article.

The ontology is the schema, not the market data

The W3C describes OWL, the Web Ontology Language, as a language for representing knowledge about things, groups of things and their relationships. In practice, an ontology can define:

• classes, such as LegalEntity, Security, Filing, FinancialFact and ResearchClaim;
• relationships, such as issues, owns, supplies, reports and supportedBy;
• attributes, such as currency, filing date or security identifier;
• constraints, such as a fact having a unit and reporting period;
• identity rules, such as when two records represent the same legal entity.

The ontology does not supply the current revenue of a company. A filing or licensed data source supplies that value. The ontology says what the value represents, which entity and period it belongs to, and how it relates to other objects.

EDM Association's Financial Industry Business Ontology, or FIBO, is a public example. FIBO defines concepts and relationships for financial instruments, entities and processes and is published in RDF/OWL. Its specification site says the model can give common meaning to data in spreadsheets, relational databases and documents. FIBO does not ship a live corpus of every issuer's filings or a ready-made investment thesis.

Ontology, taxonomy, knowledge graph and RAG are different layers

These terms are often blended in vendor copy. They solve related but distinct problems.

Microsoft's GraphRAG documentation describes a system that builds a graph from an input corpus. That can improve retrieval for questions spanning many documents. An automatically extracted graph can also be noisy. Microsoft documents tradeoffs between graph construction methods; it does not claim that an extracted graph becomes a fully governed financial ontology.

The layers can be combined. An ontology defines objects and relationships. A graph stores instances. Keyword or vector retrieval finds supporting passages. A model reads those passages and drafts an answer. Access controls decide which objects and passages a user may see.

A small example exposes the value and the risk

Consider this research question:

Which portfolio holdings are exposed to a customer that reduced its demand outlook, and what public evidence supports each link?

A text-only retrieval system might search documents for the customer name. That misses subsidiaries, old names and disclosures that use a product name. It may also return unrelated companies with a similar name.

An ontology-led implementation can define the job more explicitly:

1. Resolve the named customer to a LegalEntity with stable identifiers.
2. Traverse CustomerOf or Supplies relationships to candidate issuers.
3. Resolve the firm's holdings from Securities to their issuing entities.
4. Intersect the supplier set with current holdings for a stated as-of date.
5. Retrieve the filing or transcript passages supporting each customer relationship.
6. Return the exposure as observed, inferred or unknown.

The output should include a table like this:

This is a toy example, not an AllMind output or a claim about real companies. Its purpose is to show where the ontology helps: identity, relationship types and a path through the graph. It also shows what the ontology cannot do. A well-typed edge can still be stale, inferred from weak evidence or missing entirely.

Evidence and time have to be first-class properties

For investment research, a relationship without provenance is difficult to use. The graph should preserve at least:

• the original source and exact passage;
• the entity identifiers used in resolution;
• the relationship type and direction;
• observed, vendor-reported, estimated or inferred status;
• valid-from, valid-to and last-checked dates;
• the extraction method and reviewer;
• access rights attached to the source and derived object.

Time is especially important. An issuer may change its name, sell a subsidiary, switch customers or issue a new security. A graph that overwrites the old relationship cannot reproduce what an analyst knew at an earlier date.

Entitlements also need enforcement below the prompt. If a broker note supports an edge, a user without rights to that note should not receive its text through a generated answer. The system must decide whether it can show the relationship, a derived fact, neither, or an alternate public source. Those decisions depend on contracts and architecture, not on the word “ontology.”

What an ontology improves for research agents

An agent has to choose tools and sources across several steps. An ontology can narrow those choices. It can resolve “the UK parent” to the correct entity, connect a security to its issuer, identify the relevant filing period and retrieve evidence attached to a relationship.

The likely benefits are:

• fewer entity collisions across tickers, names and subsidiaries;
• explicit multi-hop paths for supply chain, ownership and exposure questions;
• consistent units and reporting periods when the schema enforces them;
• reusable research objects across search, tables and reports;
• a place to attach evidence, time and permissions.

These are design benefits, not proof of answer accuracy. Performance depends on the quality of entity resolution, mappings, source coverage and review. A simple relational model may be easier and more reliable for a narrow, stable workflow. An ontology earns its complexity when relationships, heterogeneous sources and repeated cross-entity questions are material.

Inside AllMind's ontology

In our ontology, market data, filings, broker notes, and internal research resolve to shared objects, with evidence and entitlements attached. The graph is populated by a substantial built-in platform data layer, not only customer uploads. Our live catalog documents 6,800+ premium data sources licensed from 100+ providers and partners across 72+ core categories.

The estate includes FactSet fundamentals and Revere relationships, LSEG estimates plus M&A and private-market coverage, and S&P/Capital IQ market and index data. It also covers ownership and holdings, MSCI data, more than 40 exchange and venue feeds with licensed L3 depth, filings, transcripts, broker and expert research, macro and public records, and broad alternative data.

Firm systems can connect through RMS, portfolio and risk, document, warehouse, lakehouse, cloud-storage, database, pipeline, API, and customer-entitled vendor bridges. Named data routes include Snowflake, Databricks, S3, Redshift, BigQuery, GCS, Azure, Redis, and MongoDB. An agent inherits the role of the user who runs it.

Those are our own product claims. We do not publish the schema, entity-resolution accuracy, relationship coverage, change history or false-link rate. A buyer cannot infer those measures from a document count. Our separate AllMind product definition keeps our public claims and unresolved evidence in one ledger.

To evaluate the implementation, ask us, or any vendor, to show:

1. the entity IDs and relationship types used for a real question;
2. the source and timestamp behind each edge;
3. an incorrect or disputed relationship and its correction process;
4. a corporate action that changes identity over time;
5. the same query from users with different entitlements;
6. an export that preserves the graph path and evidence.

When not to build or buy one

A financial ontology is unnecessary for a workflow that reads one known document, extracts a fixed table and produces a fixed output. A relational schema, careful identifiers and direct citations may be sufficient. It is also a poor cure for weak source data. Formal semantics make bad data more consistently wrong.

The architecture becomes more valuable when the team repeatedly asks cross-company questions, combines internal and external systems, or must preserve evidence and rights across generated outputs. Define those jobs first. The ontology is an implementation choice, not the research objective.

Definition sources and product access

The technical definition relies on the W3C's OWL overview, EDM Association's FIBO overview and FIBO specification, plus Microsoft's GraphRAG documentation. Sources were checked on August 30, 2026. The AllMind section is based solely on our public ontology page; it does not draw on schema access, relationship samples or error logs, and no graph or product run was inspected for this article.