Two Trees. One Confusion That Matters.

In financial data engineering, "market data" is often treated as a single, uniform concept. It isn't. There are two fundamentally different dimensions hiding under that label — and conflating them leads to the wrong schema, the wrong queries, and eventually some uncomfortable conversations with the risk team at the worst possible moment.

Working on financial data infrastructure across different contexts, the same confusion tends to surface repeatedly. Someone says "instrument" and means one thing. Someone else says "instrument" and means something completely different. A third person nods along and means a third thing entirely. Everyone feels aligned — until the data model has to actually hold it all together.

This post is an attempt to draw two very clear, deliberately opinionated trees. Not as academic taxonomy — as a working mental model that changes how you think about structuring financial data.

The Problem with "Market Data"

Market data, at its core, is a description of the financial world at a given point in time. Prices. Yields. Rates. Valuations. The raw material for every portfolio decision, risk model, and regulatory report ever written.

The challenge isn't collecting it — providers like Bloomberg, Reuters, and a dozen others will happily sell you as much as you can consume. The challenge is structuring it. Because underneath what looks like a uniform stream of numbers, there are actually two completely orthogonal questions being conflated:

"What economic exposure do you have?" and "Through what legal and structural vehicle do you hold it?"

The first question is about asset classes. The second is about instrument types. They are not the same. They are not interchangeable. And they absolutely do not belong in the same column in your database.

Yet in practice they frequently get collapsed into one. A single type column that mixes "equity" and "ETF" and "futures contract" as if they belong to the same dimension. They don't. One describes what you own. The other describes the wrapper you used to own it. The distinction matters more than it might initially appear.

Tree One: Asset Classes

An asset class is an economic category. It answers: what kind of risk and return profile are you fundamentally exposed to?

Equities give you ownership — residual claims on corporate earnings, upside when things go well, significant pain when they don't. Fixed income is contractual — you're a creditor, not an owner, and you care about credit quality and duration. Alternatives is the drawer where everything awkward goes: hedge funds, private debt, real estate, commodities, infrastructure, digital assets. And cash equivalents are what they sound like: near-zero-duration, near-zero-risk, and near-zero-excitement.

The point of this tree is to reason about risk exposure at a portfolio level. It tells you nothing about operational complexity, settlement mechanics, or margin requirements. That comes later.

A few things to notice here. The leaves are things like large cap, sovereign, direct lending, energy commodities. Not "Apple shares." Not "German 10-year Bund." The asset class tree doesn't know about specific securities — it classifies the economic nature of an exposure. That's a feature, not a limitation.

Also notice that alternatives is doing a lot of work. Hedge funds, private debt, digital assets, real estate, commodities, infrastructure — these all sit here because the commonality isn't economic behavior (they vary enormously), it's that they don't fit cleanly in the other three boxes. Every taxonomy has its junk drawer. This is ours.

Tree Two: Instrument Types

Here's where things get interesting. And where most data models quietly fall apart.

An instrument type is a legal and structural wrapper. It doesn't describe what you're economically exposed to. It describes the mechanism through which you hold that exposure. And the implications of that mechanism — for your data, your operations, your valuations, and your risk systems — are completely different depending on which type you're dealing with.

Consider a simple example. You want equity exposure to Apple. You can get it through:

• A share — a security, settled through a custodian, with dividends and voting rights
• A call option — a derivative, with margin, ISDA agreements, and daily mark-to-market
• An ETF — a fund, with NAV calculations, creation/redemption mechanics, and an expense ratio
• An equity swap — another derivative, typically OTC, different settlement and counterparty risk entirely

Same asset class. Four very different instrument types. Four completely different data models, valuation methodologies, and operational workflows.

Asset class tells you what you own. Instrument type tells you what piece of paper — or ISDA agreement, or smart contract — you're actually holding.

Some things worth calling out in this tree:

FX instruments deserve their own branch. It is tempting to file them under derivatives or leave them in a catch-all category — but FX spot, forwards, FX swaps, cross-currency swaps, and FX options each carry distinct settlement conventions, curve dependencies, and regulatory treatment. They form a coherent family and should be modelled as one.

Structured products are genuinely their own world. ABS, CDO/CLO, CMBS, warrants — these have tranched cash flows, underlying reference pools, complex waterfalls, and event-driven behavior (prepayment, default, extension). They're not exotic bonds. They're their own instrument class entirely, and they need their own data model to match.

Loans and deposits are frequently undermodelled. Treasury functions, direct lending, revolving credit facilities — these are not securities. They don't trade on exchanges. They carry amortization schedules, covenant packages, and bilateral agreement structures. Wealth management and private credit platforms that haven't properly accounted for this branch tend to encounter significant gaps when data coverage needs to expand.

Why Two Columns, Not One

So what's the practical takeaway? It's this: in your instruments table, you need both columns. Separately. With their own value sets. Not a single type field. Not a composite code. Two distinct dimensions that can vary independently.

Because they do vary independently. An ETF can carry equity or fixed income exposure. A futures contract can reference commodities or equity indices. A structured product can be backed by mortgages (real estate alternative) or corporate loans (private debt alternative). The instrument type doesn't constrain the asset class, and the asset class doesn't determine the instrument type.

| Example | Asset Class | Instrument Type | Classification | |---------|-------------|-----------------|----------------| | Apple common share | Equities › Listed › Large cap | Securities › Shares › Common equity | WHAT × HOW | | S&P 500 call option | Equities › Listed | Derivatives › Options › Call | WHAT × HOW | | iShares IG Bond ETF | Fixed income › Corporate › Inv. grade | Funds › ETF › Passive index | WHAT × HOW | | EUR/USD spot | Cash equivalents (notional) | FX instruments › Spot FX | WHAT × HOW | | Mortgage-backed security | Fixed income › Structured › ABS/MBS | Structured products › ABS › MBS | BOTH MATTER | | Direct lending facility | Alternatives › Private debt › Direct lending | Loans and deposits › Loans › Term loan | BOTH MATTER |

Notice the last two rows. With structured products and private credit, both dimensions carry real analytical weight. The asset class tells you about the economic exposure; the instrument type tells you how to value, settle, and operationally manage it. Neither is redundant.

What This Means for Your Data Architecture

Once you've got the taxonomy right, the data architecture becomes a lot more obvious. Different instrument types need different time series tables. A single "prices" table won't cut it.

Equities want OHLC with volume. Fixed income wants yield curves across tenors. FX wants spot, bid/ask spreads, and forward points. Derivatives want mark-to-market, greeks, and margin. These aren't flavors of the same thing — they're structurally different data, and cramming them into a narrow (date, instrument_id, field, value) format means every query is a self-join nightmare.

The cleaner approach: organize by provider namespace and domain. Something like:

Each provider gets its own namespace. Within each namespace, tables are organized by semantic domain — equity, fixed income, FX — and each table is wide enough to hold related fields together. Not a narrow key-value store with a field column. A proper semi-wide table with typed columns: px_open DOUBLE, yield_10y DOUBLE, bid DOUBLE. The difference in query performance alone makes it worth it, not to mention the sanity of reading schema that actually reflects the domain.

The instruments table in each namespace — and this is the part that ties the whole thing together — carries exactly those two taxonomy columns: asset_class and instrument_type. Both populated. Both from the trees above. Both independently queryable.

-- What you want to be able to ask:
SELECT *
FROM bloomberg.instruments
WHERE asset_class   = 'fixed_income.corporate.investment_grade'
  AND instrument_type = 'funds.etf.passive_index';

-- A corporate IG ETF. Completely unambiguous.
-- No string parsing. No regex on a composite field. No guessing.

A Common Pitfall: Deferring the Structure

A reasonable objection at this point: if a system only handles equities and bonds today, is all of this necessary? The answer is that the full leaf-node taxonomy doesn't need to be populated on day one. But the two-axis structure absolutely does.

The moment scope expands to derivatives, or an FX desk is added, or fund data starts flowing in, the cost of retrofitting a taxonomy onto a schema that was built without one is significant. It means migration scripts, downstream schema changes, and re-aligning data consumers who had built assumptions on top of the original model. The structural decision is far cheaper to make upfront than to undo later.

Two columns. From the start. asset_class and instrument_type. Separate, typed, enumerable. It's not premature abstraction — it's modelling the domain accurately from day one.

Conclusion: Two Trees

Market data is not one thing. It never was. It is a rich, multi-dimensional space where vendors apply their own proprietary taxonomies, different teams — trading, risk, accounting, compliance — care about different attributes, and the instruments themselves keep evolving in ways any fixed taxonomy will struggle to fully anticipate.

But the two-axis model — asset class and instrument type, independent, both populated — is the foundation that makes everything else tractable. It is how you answer "what do we own?" and "how are we holding it?" at the same time, without conflating the two. It is how domain-specific tables get built to reflect the actual structure of the data. And it is how conversations across teams stay aligned rather than drifting.

Draw the two trees. The taxonomy is opinionated, and reasonable practitioners will have views on the leaf nodes. But the two-root structure is worth defending early — before the schema has to be retrofitted to accommodate it.