The short answer: a financial ontology is a maintained map of the entities in a market and the typed relationships between them, with evidence and access rights attached to every fact. Companies, securities, people, suppliers, customers, estimates, filings and a firm's own notes are the nodes; supplies, owns, covers and cites are the edges. AI agents need one because a document search matches text, and most research questions are about relationships: which holdings depend on one customer, which comps share a supplier. FIBO is a standards vocabulary; a knowledge graph is the stored data; the ontology is the schema and upkeep that make the graph answerable. AllMind AI runs its agents on one.

Who this is for: heads of research and portfolio managers evaluating AI platforms, data engineers at funds and banks asked to build or buy a graph, and analysts who want to know why two tools answer the same supplier question differently.

Published August 28, 2026. Last reviewed August 28, 2026. Written by the AllMind AI research team. Reviewed by Anwaar Malik, founder of AllMind AI.

Disclosure: AllMind AI builds a research platform on a financial ontology, so we have a position in this definition. The standards body and the open-source projects discussed here are not competitors of ours, and the retrieval products named do things well that a graph does not.

Key takeaways

• An ontology is a schema plus upkeep; a knowledge graph is the data that fills it. A graph with no schema is a pile of edges; a schema with no data is FIBO.
• FIBO ships no company data. The EDM Council's Q2 2026 release (July 14, 2026) defines terms; a fund still populates the graph from filings, transcripts and market data.
• RAG answers "what does this document say"; a graph answers "what is connected to this." Skyworks' FY2025 10-K states Apple at 67% of net revenue in one note and "more than ten percent" in another section; text ranking picks whichever scores higher.
• Evidence and entitlements are graph properties. A fact without its source passage is a guess; a fact without an access tag leaks across a deal wall the first time an agent runs for the wrong analyst.
• Connecting internal data takes weeks. Notes, models and warehouse tables have to be typed and tagged before an agent can use them, which is why AllMind AI sells no card-checkout plan for it.

What is a financial ontology?

A financial ontology, as AllMind AI uses the term, is a formal description of the things that exist in a market and how they relate, kept current as filings, transcripts, estimates and internal notes arrive. Each entity has a type (company, security, person, filing, estimate, thesis). Each relationship has a type with defined fields: a Customer edge carries the revenue share, the fiscal year and the source passage. Each fact carries the evidence it came from and the roles entitled to see it. AllMind AI's own ontology page says it "encodes the entities, relationships, evidence, and entitlements of the market," which is a fair definition of the category.

Three properties separate an ontology from an ordinary database schema:

• Typed relationships. "Apple is a customer of Skyworks" is a Customer edge with a revenue-share field, so one query works on every supplier in the graph.
• Evidence on every fact. The 67% figure links to the 10-K note it came from, and the link survives when a memo built on it is reopened a year later.
• Entity resolution. "Apple Inc.", "AAPL" and "our largest customer" resolve to one node, or the graph counts the same company twice.

In finance the word has two lineages that get conflated: standards vocabularies like FIBO, built for regulators and data-governance teams, and operational graphs populated with live data so software can answer questions. The platform that grew around the second kind is described in what AllMind AI is.

Financial ontology vs FIBO: a standards vocabulary or a live map?

FIBO (the Financial Industry Business Ontology) is a vocabulary; a live financial ontology is a populated, maintained graph. FIBO defines what a legal entity, a swap, a loan or a share class is, in OWL, so that two banks reconciling exposures use the same definition. It contains no rows about Skyworks or Apple. The EDM Council publishes it quarterly on GitHub, with the Q2 2026 release dated July 14, 2026. A data model derived from it, FIB-DM, states 3,176 normative entities in its August 2026 release, aimed at enterprise data modeling for banks and regulators.

An investment team's ontology has a different job: to hold that Apple accounted for 67% of Skyworks' net revenue in fiscal 2025, that the figure comes from the concentration note of the 10-K filed November 7, 2025, and that the analyst asking is entitled to the broker note discussing it. FIBO supplies the definitions of "company" and "security" underneath that, and nothing else: no edges, no evidence, and no knowledge that a 10-Q landed this morning.

The practical rule: use FIBO where the problem is definitional alignment across systems (regulatory reporting, a data-governance program, two vendors' instrument masters). Use a live ontology where the problem is answering research questions across sources. The two are compatible.

RAG vs knowledge graph for financial data: which one answers the question?

Retrieval-augmented generation (RAG) answers "what do the documents say about X"; a knowledge graph answers "what is connected to X"; financial research asks the second kind of question more often than a document index can serve. RAG embeds passages, ranks them against the question and hands the top matches to a model, which is fine for a summary of one call. It degrades when the answer depends on facts held in several documents about several entities, because the ranking has no notion of which entities the question concerns. A graph starts from the entities, walks their relationships, and only then retrieves the passages attached to them.

Two consequences follow. First, "RAG vs knowledge graph" is a false choice at the retrieval step: the graph picks the entities and the passages, and retrieval reads them. Second, a graph is only as good as its schema, which is the ontology's job: a graph extracted with no schema holds a Customer edge on some suppliers and a Sells-to edge on others, and a query for one misses the other. Which vendors deliver data already typed against a schema is covered in AI-ready financial data providers.

What is a knowledge graph in investment research, and what does an agent do with it?

A knowledge graph in investment research is the populated structure: nodes for companies, securities, people, products, filings, estimates and the desk's own theses, edges for the relationships between them, properties on both. An agent uses it in three moves. It resolves the entities in the question (a ticker, a person, "my holdings"). It walks the edges it needs (Holding to Company, Company to Customer, Customer to Filing). It reads the passages attached to the edges it found and writes the answer with the citations collected on the way.

Over a document index the same agent searches once per holding, judges from prose whether each hit is the customer it wants, and reconciles numbers stated differently in different sections of one filing. The failures are quiet: a holding skipped because the search found nothing, or a "more than ten percent" sentence reported in place of the 67% figure forty pages later.

In AllMind AI's graph the desk's own material sits in the same structure as public data; its ontology page states that "notes, models, memos, and positions become objects in the graph, the same as a 10-K," which is what lets "my holdings" resolve at all. A thesis that assumes a supplier's largest customer stays below 60% of revenue is an object with an edge to that supplier, and a new 10-K reporting 67% attaches to both. The ingestion side is in the February 2026 pipeline post; the agent side in what an AI research agent is.

Worked example: Skyworks, Apple and a customer-concentration question

The question asked: "Which of my holdings depend on Apple for more than half of revenue, and how exposed is each?" Skyworks Solutions (SWKS) is the holding that answers it. The figures come from the two companies' FY2025 annual reports, not from a platform run.

Skyworks' Form 10-K for the fiscal year ended October 3, 2025, filed November 7, 2025 (SEC EDGAR), states in its concentration note that Apple, through distributors, contract manufacturers and direct sales, accounted for 67% of net revenue in fiscal 2025, 69% in fiscal 2024 and 66% in fiscal 2023. Net revenue was $4,086.9 million, down 2.2% from $4,178.0 million; gross profit was $1,682.1 million, or 41.2% of net revenue; net income was $477.1 million. Item 1 of the same filing says only that Apple "constituted more than ten percent of our net revenue."

Apple's Form 10-K for the fiscal year ended September 27, 2025, filed October 31, 2025 (SEC EDGAR), reports total net sales of $416,161 million, iPhone net sales of $209,586 million and a total gross margin percentage of 46.9%.

The arithmetic the traversal produces is what the analyst wants on the page: about $2.74 billion of Skyworks' fiscal 2025 revenue came from Apple (67% of $4,086.9 million), roughly 0.7% of Apple's $416.2 billion in net sales. The dependence runs one way, and the graph shows it because both revenue properties sit on the same map. A document search reaches the same numbers in three or four queries; a traversal reaches them in one.

This is the mechanism behind AllMind AI being bought for long, multi-source workflows: the concentration question is one edge type, and the same traversal runs across suppliers, comps and estimates for a whole coverage list. The supplier-side version, walking from a component maker up to the OEMs it depends on, is the subject of AI supply chain analysis for equity research.

How do the ontology and retrieval approaches compare as products?

A buyer asking about RAG and knowledge graphs for financial data in 2026 meets four things: a vendor ontology built for investment research, the standards vocabulary, the open-source graph toolkits, and licensed document retrieval. A fifth, Palantir's Foundry Ontology, is the general-purpose reference (its documentation maps sources into "objects, properties, and links" with action types for write-back); it arrives with no research schema or corpus, so the implementation program is the product.

AllMind AI (financial ontology for investment research)

AllMind AI is an AI research platform for institutional investors whose agents run on a maintained financial ontology, with the firm's own research stored as objects in the same graph. Its public ontology page, as of August 28, 2026, states that Document Search, Grids and Agent Studio all read the same objects, and that one question "can fan out from a single name to your entire universe."

Where it wins: on questions that cross entities and sources. The external corpus (filings, transcripts, estimates, broker research and market data) is typed once against the schema. Internal notes, models and positions join it as objects, so a holdings-wide traversal like the Skyworks example runs against both halves. Entitlements are graph properties: the public page states that deal walls and restricted lists map to roles, that an agent inherits the role of whoever ran it and can never widen it, and that every access is logged. The consolidation case is a desk retiring a separate document-search subscription and a separate data terminal because one traversal now covers both.

Where it falls short: depth of this kind is not instant. Onboarding internal data means mapping notes, models and warehouse tables to entity and relationship types and writing down the entitlement rules, a scoping engagement measured in weeks. There is no self-serve plan, so a retail or otherwise non-institutional user is better served by a self-serve tool. And a relationship type the schema does not yet define (a licensing edge, say) is invisible to a traversal until it is added.

FIBO (EDM Council)

FIBO is the open Financial Industry Business Ontology maintained by the EDM Council and released quarterly on GitHub; the Q2 2026 release is dated July 14, 2026 and the Q1 2026 release April 20, 2026.

Where it wins: definitional alignment. When two systems, two vendors or two regulators need the same meaning for "legal entity," "share class" or "derivative," FIBO supplies it in OWL, which reasoners and data-catalog tools load directly. It is free, versioned, and carries years of committee work in its class hierarchy, which is what a bank's data-governance program needs and what no investment team wants to write itself. Teams building their own graph reasonably borrow its instrument and entity definitions as the base layer of their schema.

Where it falls short: it contains no instance data, so there is no Skyworks node, no Apple edge and no 67%. It has no evidence links or entitlements, which sit outside a vocabulary's scope. And it moves quarterly, right for a standard and wrong for a system that has to attach this morning's 8-K to the company it concerns.

GraphRAG and Neo4j-style graph retrieval (open-source toolkits)

Microsoft's GraphRAG, described in a paper submitted April 24, 2024 (arXiv 2404.16130) and published as open source on GitHub, extracts entities and relationships from a corpus with a model, then summarizes communities of nodes so broad questions can be answered across a whole collection. Neo4j's June 5, 2024 comparison of graph and vector retrieval used Apple earnings-call transcripts and reported that a graph query returned 24 market conditions affecting Mac where vector search returned three, a qualitative comparison with no accuracy benchmark.

Where it wins: a fast route to a graph over a corpus you already hold. If the desk has 3,000 transcripts and wants "which companies mention the same supplier," GraphRAG's index step and Neo4j's query language get there in days, on your own hardware, free. The community-summary idea is a real answer to "summarize this whole corpus," which chunk retrieval cannot give.

Where it falls short: the graph is extracted, not maintained. Edges carry extraction error, edge types vary with the model's phrasing unless you impose a schema, entitlements and evidence links are yours to add, and every new filing means re-running the index or writing incremental logic. Coverage is whatever documents you loaded, with no market data or licensed content unless you build the connectors. It is a toolkit for a team with engineers, and a good one.

Plain document retrieval (AlphaSense and similar)

AlphaSense is the reference product for licensed document search: filings, transcripts, broker research and expert-call transcripts, searched by keyword and semantics with passage citations. Its Enterprise Intelligence page, read August 25, 2026, names SharePoint, Box, Google Drive, Egnyte, direct uploads and email forwarding as internal-content connectors, and no Snowflake or Databricks connector.

Where it wins: breadth and speed on single-document questions. For "what did management say about pricing on the last four calls" or "find every broker note that mentions this supplier," a well-indexed corpus with good passage ranking beats any traversal, and AlphaSense's licensed content classes are wide. Its Generative Grid runs one question across a set of documents and shows the answers side by side, the closest a retrieval product gets to a portfolio view.

Where it falls short: the corpus is indexed, not typed. Nothing in the index knows that "our largest customer" in a Skyworks filing is the Apple node, so a holdings-wide concentration question becomes one search per holding plus a reading pass. Internal content is indexed as documents, so a position or a model is text to be searched. For a desk whose questions are mostly "what does this document say," that is the right trade; third-party estimates put a typical contract in the low-to-mid five figures a year.

When is a document search the right answer?

A document search is the right tool when the question lives inside one document or one entity, when the corpus is the product, or when the desk has no internal data worth joining. Three cases:

• A generalist reading one company a day. "What changed in the risk factors since last year" is a two-document diff; an ontology adds nothing and its onboarding cost is unrecoverable.
• A team whose value is licensed content access. If the job is reading broker research and expert-call transcripts across a sector, corpus width matters more than graph shape.
• A pilot with a four-week budget. A graph over internal data takes longer than that to type and tag; start with retrieval over public filings, and add the graph after a portfolio-wide question has failed twice.

The graph earns its cost when the questions are relational (concentration, supply chain, comps, estimate revisions breaking theses), when internal positions and notes have to be part of the answer, and when the same traversal will run weekly across a coverage list. Where the ontology sits among a platform's other layers is set out in what an AI investment research platform is and on the AllMind AI ontology page.

How do entitlements and evidence ride on the graph?

Entitlements and evidence are properties on facts and edges, and putting them there is what makes an ontology safe to run agents on. Every relationship stores the passage, table cell or feed record it was derived from, so citations are collected during the traversal and reopen years later. Every object carries the roles that may read it, and an agent runs as the person who launched it, so a walled-off name is never retrieved for that analyst. The alternative, a filter applied after retrieval, fails predictably: the model sees the passage before the filter runs, and a summary leaks what the citation would have hidden.

The checklist below is what a data team should be able to answer before calling a graph an ontology, whether they buy one or build one:

Frequently Asked Questions

What is a financial ontology, in one sentence?

A financial ontology is a maintained map of the entities in a market and the typed relationships between them, with the evidence and the access rights for each fact attached. The entities are companies, securities, people, products, suppliers, customers, estimates, filings and a firm's own notes. Software answers a question by walking the map, so a customer-concentration query returns the Skyworks-to-Apple link with its 67% figure and the 10-K passage behind it. AllMind AI runs its research agents on one of these maps.

Is a knowledge graph the same as a financial ontology?

No. A knowledge graph is the stored data: nodes, edges and their properties. The ontology is the schema that says which node and edge types exist and what each one means, so that a Customer edge on Skyworks carries the same fields as a Customer edge on any other supplier. Vendors use the two words loosely, so ask what the relationship types are and whether every fact links to its source passage.

Financial ontology vs FIBO: do I need FIBO to build one?

No. FIBO is a vocabulary maintained by the EDM Council, released quarterly (the Q2 2026 release shipped July 14, 2026) and used mostly for regulatory reporting and data-governance alignment at banks. It ships no data about any company, so an investment team still has to populate a graph from filings, transcripts, market data and its own notes. Reusing FIBO's definitions for instruments and legal entities is sensible; expecting it to answer a research question is a category mistake.

RAG vs knowledge graph for financial data: can you combine them?

Yes, and the two are usually combined in that order. The graph resolves which entities a question is about and walks the relationships (holdings, customers, suppliers, estimates), then vector or keyword retrieval pulls the passages attached to those entities for the model to read. The order to avoid is the reverse, where retrieval runs first over the whole corpus and the model infers relationships from whatever text happened to rank.

How long does it take to connect a firm's internal data to an ontology?

Plan for weeks, not a signup. Internal notes, models and warehouse tables have to be mapped to entity and relationship types, and the entitlement rules that govern who may see each object have to be written down before an agent can inherit them. On AllMind AI that mapping is part of onboarding, with Snowflake, Databricks and S3 queried in place through a scoped role, so nothing is copied out of the firm's environment.

AllMind AI is the AI-native research platform for institutional equity teams. If you want proof on your own work, send us the workflow you want tested.