Ask a simple question at an investment committee meeting — what is our exposure to Alphabet? — and you can get three answers in the same room.
Risk says 2.1%. Performance says 2.4%. The client report says something else again. Nobody is wrong. Risk is netting GOOG and GOOGL as one issuer. Performance is treating them as two securities and one of them settled a day later. The client report is on a different as-of date. Three systems, three defensible answers, and an hour of the meeting gone to reconciling a number instead of deciding anything.
The instinct is to blame a feed, or a vendor, or the analyst who pulled the wrong report. It is almost never any of those. The failure is that the firm has no shared, machine-enforced definition of the things it talks about — no agreement on what an issuer is, where a position begins, what revenue means for a bank versus an insurer. The pipelines are fine. The nouns are undefined.
That shared definition layer is what people mean by an ontology, and for an asset manager it is the least glamorous, highest-leverage thing in the stack.
The security master, grown up
Every asset manager already has a proto-ontology. It's called the security master, and it has been quietly doing this job for thirty years: one place that says what an instrument is, so that everything downstream agrees.
The problem is that most firms have three of them. The OMS has one. The risk system has one. The accounting book has one. Each is internally consistent and none of them fully agrees with the others, which is precisely why the reconciliation team exists.
An ontology is the security master grown up. Strip away the philosophy-department baggage and it is a categorization of the world your firm operates in — Palantir, whose Foundry ontology is the best-documented commercial version, calls it the digital twin of an organization. It is not a data catalog and it is not a schema. A catalog tells you a table exists. A schema tells you a column is a string. An ontology tells you that this row is a Security, that it is issued by that Issuer, and that a portfolio manager is allowed to override its price with a reason code.
Foundry builds this from four primitives, and they are worth knowing because nearly every semantic layer on the market is a rearrangement of the same four:
- Object types — the entities and events the business consists of. Issuer, Security, Position, Portfolio, Mandate, Counterparty.
- Properties — the characteristics of an object type. A security's duration, an issuer's as-reported revenue, a mandate's concentration limit.
- Link types — the relationships between them. A Security is issued by an Issuer; an Issuer is a subsidiary of a Parent; a Position is held in a Portfolio.
- Action types — how an object may be changed, and by whom. Not a description of the world, but the sanctioned set of edits to it.
The first three are familiar — they are roughly the security master with the relationships finally written down. The fourth is the one that separates an ontology from documentation, and it is the one asset managers should care about most. Action types make the model operational: applying a fair-value override, reclassifying a holding, approving a corporate action. The definition layer becomes the same layer that governs writes, which means the rules cannot drift from the data the way a policy document drifts from practice — and every change carries an audit trail by construction rather than by heroics at quarter end.
What it buys you
The payoff is not better documentation. It is that questions stop being re-litigated, and that some questions become answerable at all.
Look-through stops being a project. How much of the portfolio is exposed to Taiwanese semiconductor fabrication? is unanswerable in a flat holdings table and trivial in a graph that already models issuer, parent, subsidiary, and segment. The join you would otherwise commission as a two-week data-science request is a traversal of a structure that exists.
Definitional change gets a blast radius. When investment grade or emerging market is defined once in the semantic layer rather than in nine reports and a spreadsheet, changing it is one edit with a knowable set of consumers, not an archaeology project.
Governance becomes reviewable. Foundry treats ontology changes like code: you branch the ontology, make changes in isolation, and open a proposal that must be approved before it merges. Set that against how definitions usually change at an asset manager — someone edits a filter on a Thursday — and the appeal is obvious. For anyone who has had to explain a restated client report, semantics are infrastructure. They deserve review, not vibes.
The five ways this goes wrong
Palantir's design guidance is unusually candid about failure modes, and all five will be recognizable to anyone who has sat through a data-governance steering committee.
System silos. The model is built around source systems rather than the business, so you get AladdinSecurity, BloombergInstrument, and AccountingAsset as three object types. That is a faithful map of your vendor contracts and a useless map of your firm. There is one security. The model should say so.
Department silos. The same failure along the org chart. Front office's position and back office's position become separate types because IBOR and ABOR were modeled independently — trade date versus settlement date, hardened into the schema instead of expressed as a property of one concept. Each side is locally coherent; the incoherence surfaces only at the seams, which is exactly where the CIO's questions live.
The kitchen sink. Every field from every vendor feed gets modeled because it might matter someday. The ontology becomes a mirror of the warehouse rather than a curated interface to it, and the curation — the actual value — never happens.
The god object. One Instrument type absorbs equities, bonds, swaps, and FX forwards until it has three hundred properties, most null for any given row. The tell is conditional logic in every consumer: if this field is set, it's actually a swap. That is a type boundary asking to be drawn.
The golden hammer. The ontology gets used for work it is bad at — usually heavy time-series scans like return attribution or factor exposure, which belong in a columnar engine. A semantic layer is an interface for operational reasoning, not a replacement for your analytics database.
The through-line: four of the five come from modeling your vendor list or your org chart instead of your business.
Three things asset managers underestimate
Identity is the hard part. Not modeling — identity. Deciding which rows are the same thing is where these projects actually stall, and securities data is unusually hostile terrain. A ticker is not a security is not an issuer. ISIN, CUSIP, SEDOL, and FIGI identify instruments at different grains; LEI identifies the legal entity; none of them survives a merger cleanly. Tickers get reused by unrelated companies after a delisting. Share classes multiply — GOOG and GOOGL are two securities and one business, and whether your system knows that determines whether the exposure number in the opening paragraph is right.
We hit this directly building Akyla's equity data and ended up constructing an explicit company identity layer beneath the ticker layer. It was the single change that made cross-listing and long-horizon comparisons trustworthy. Every serious ontology has an equivalent: the entity-resolution problem nobody budgeted for.
Point-in-time is not optional. This is the one that quietly destroys research. If your ontology stores only the current view — current classification, current restated financials, current issuer hierarchy — then every backtest run against it is contaminated by knowledge the strategy could not have had. Financial statements get restated. Sector classifications change. Index membership is revised. An ontology for an asset manager has to answer what did we know, and when did we know it, which means as-of semantics belong in the model from day one rather than bolted on after the first suspiciously good backtest.
Definitions need the same treatment. When we built sector-aware revenue — because "revenue" for a bank is net interest income plus non-interest income, not the ASC-606 line an insurer reports — the rule itself became a versioned part of the model, not a patch in a query.
It costs money to run. Foundry meters ontology volume, indexing compute, and query compute as separate line items. The specific vendor matters less than the general lesson: an ontology is a live, indexed, queryable structure, so the kitchen-sink anti-pattern is not merely inelegant. Modeling every field of every feed means indexing every field of every feed, monthly.
Do you need one?
Not every firm does. A single-strategy shop with one system of record and a team small enough to hold shared definitions in their heads should write the definitions down and get on with investing.
You need one when the disagreements start. Concretely: when risk, performance, and accounting routinely produce different numbers for the same exposure; when a cross-domain question requires a specific person who knows which joins are safe; when client or regulatory reporting depends on a reconciliation process rather than a shared definition; when onboarding an analyst takes a quarter because the knowledge is tribal.
And when you want to put AI agents anywhere near portfolio data. That last one is why this stopped being a back-office topic. A language model pointed at a holdings warehouse is a very fast analyst with no institutional memory — it will net two share classes it shouldn't, or fail to net two it should, and explain itself fluently either way. The firms getting real value from AI on internal data are, almost without exception, the ones that had already done the semantic work, because the ontology is the thing that tells the model that these two tickers are one company and that this figure was restated last March.
The nouns were always the hard part. AI just made it expensive to keep pretending otherwise.
Akyla builds analytics products on as-reported financial data, where the identity layer beneath the ticker — and the as-of date beneath the number — is the difference between a figure you can defend and one you can't. If you're working through a semantic layer for your own data, we're happy to compare notes.
References
Palantir: Ontology core concepts
Palantir: Why create an Ontology?
Palantir: Ontology design — anti-patterns
Palantir: Ontology design — best practices
Palantir: Branching the ontology