Asset Classes

The ISDA product taxonomy, published as an FpML coding scheme, is hierarchical. Values are colon-separated paths that descend from an asset class through sub-category to instrument type and settlement method. Examples:

• InterestRate:IRSwap:FixedFloat
• Credit:SingleName:Corporate:NorthAmericanCorporate
• Commodity:Agricultural:Dairy:Swap:Cash
• ForeignExchange:SimpleExotic:Barrier
• Equity:Option:ParameterReturnVolatility:SingleName

Its five top-level classes are:

• Commodity
• Credit
• Equity
• ForeignExchange
• InterestRate

Two properties are of particular relevance. The taxonomy is open at the leaves: a consumer that needs only the asset class reads the first segment and ignores the rest, while a consumer that needs the instrument type reads further. Secondly, it covers OTC derivatives only, which is why it has no bond class: a bond is a security rather than a derivative contract, and falls outside the scope ISDA set.

FpML publishes a separate, flat asset class scheme, which ORE Studio registers as FPML_ASSET_CLASS:

• ForeignExchange
• InterestRate
• Credit
• Equity
• Commodity
• Inflation
• Bond
• SecuritiesFinancing

It extends the ISDA taxonomy with three additional entries. Bond appears because FpML covers securities as well as derivatives. SecuritiesFinancing appears because repo and securities lending are a product family FpML represents. Inflation appears as a sibling of InterestRate rather than beneath it.

There are issues with this approach to modeling. Inflation is treated as a top-level class by FpML, as a top-level class by ORE's risk filter, and as no class at all by the ISDA taxonomy and by SIMM.

ORE holds enum class AssetClass { EQ, FX, COM, IR, INF, CR, BOND, BOND_INDEX, PORTFOLIO_DETAILS } in ored/utilities/parsers.hpp.

It attaches this to underlyings, not to trades. Trade declares virtual std::map<AssetClass, std::set<std::string>> underlyingIndices(...), so a trade reports the indices it requires grouped by asset class, and one trade can report under several classes at once.

ORE defines neither the concept nor a rationale for the values. The user guide uses the term only descriptively, as in "depending on the underlying asset class" when explaining why a barrier option is an FxGenericBarrierOption rather than a CommodityGenericBarrierOption, and constrains some products so that "all underlyings must be from the same asset class".

Three of the nine values are not asset classes in any other scheme here. BOND_INDEX separates an index from a single bond; PORTFOLIO_DETAILS marks portfolio-level data rather than a market. The user guide itself counts six asset classes, listing IR, FX, EQ, COM, CR and INF as ORE's product coverage and describing the scripted trade module as covering "five of the six asset classes covered in ORE". The enumeration and the prose do not agree, and nothing reconciles them.

CDM defines a product from three attributes, one of which is a taxonomy that classifies it, alongside an identifier and the economic terms. It does not define its own asset class list, and delegates classification to a taxonomy reference.

CDM therefore treats classification as a property referencing an external scheme rather than as an enumeration embedded in the product, which is one structural response to the variation described above. Trade modeling covers CDM more fully.

The seven classifications differ along two independent dimensions. Treating the two as one accounts for much of the apparent disorder.

The first dimension is the subject classified. A product, a trade underlying, a market data series and a risk sensitivity are four distinct subjects, and a classification of one is not a classification of another. ORE's AssetClass and ORE's RiskClass differ principally because the first classifies underlyings and the second classifies sensitivities.

The second dimension is granularity. SIMM demonstrates it within a single framework: RatesFX is one node where InterestRate and FX are two. A second apparent instance, the division of credit, is examined below and proves to be a property rather than a finer granularity.

SIMM, FRTB and ORE's reporting filter each publish an enumeration for grouping exposures before charging them, and each calls its values risk classes. Because those values resemble asset classes — InterestRate, Equity, FX, Commodity, Credit — they were examined as prior art for this taxonomy.

They were found not to bear on it. A bucket exists to carry the parameters a framework applies, so its membership follows from which exposures that framework weights and correlates together rather than from which markets resemble one another. SIMM's own declaration makes the point: the enumeration's ordering "is used in indexing in to correlation matrices", so its values are positions in a published table. A framework may merge two asset classes, divide one, or omit one, and none of those decisions is evidence about the domain.

The two credit divisions settle it. SIMM divides credit by qualifying status and FRTB divides it by securitisation status, along incompatible axes, over the same trades. Neither division describes the credit market. Each describes which exposures its own framework charges together.

The buckets are therefore treated in regulatory risk buckets rather than folded into the taxonomy below. What the taxonomy owes them is a projection onto each enumeration, recorded in the correspondence table, not a change to its own membership.

Setting the buckets aside leaves a second question, which does bear on the model. A product must have exactly one product class, whereas a trade carries as many classes as it has sensitivities:

• A fixed-rate bond is a product of class Bond. It is sensitive to interest rate risk in one currency and credit risk.
• A cross-currency swap is a product of class InterestRate. It is sensitive to interest rate risk in two currencies and FX risk.
• An equity option denominated in a foreign currency is one product of class Equity. It is sensitive to FX risk for a book based on a business centre which is not the same as that of the option.

ORE encodes the same distinction in a signature: Trade::underlyingIndices() returns std::map<AssetClass, std::set<std::string>>, a map keyed by class, because one trade reaches into several classes. A classification held as a property of the trade would have required a single return value.

The dimension is therefore a requirement: the class of a product and the classes its risk falls into are distinct attributes with distinct cardinality rather than distinct taxonomies. Thus, a single taxonomy referenced once by a product and many times by a trade's risk satisfies both use cases.

Stripped of naming differences, the substantive disagreements are three.

• Inflation: a top-level class for FpML and ORE's risk filter, no class at all for the ISDA taxonomy and SIMM, where inflation sensitivity is interest rate sensitivity.
• Bond: a class for FpML and ORE's AssetClass, absent from the ISDA taxonomy because it is not a derivative, and absent from both risk classifications because a bond's risk decomposes into interest rate and credit.
• Credit subdivision: apparent rather than real, and doubly so. SIMM splits credit by qualifying status; FRTB splits it by securitisation status. Two frameworks needing two different subdivisions of one class means neither is a subclass. Both are properties of the exposure.

Each disagreement reflects a use case that recognises a different set of classes, or that carries a property alongside them, rather than a difference of opinion about the domain.

The proposal separates the taxonomy from what references it.

• The taxonomy is one list of asset classes, shared by every consumer.
• A product references exactly one class. That is its asset class.
• A risk sensitivity references exactly one class, and a trade's risk profile is therefore a set of classes, one per sensitivity.

No enumeration is named risk class under this arrangement. A risk class is the taxonomy read from a sensitivity rather than from a product, and the difference in cardinality is carried by the reference rather than by a second enumeration.

Seven asset classes, held as a flat list. Every consumer selects a cut through it: the subset of classes that consumer recognises. A scheme with no place for one of them leaves it out of its cut rather than filing it beneath another class.

interest_rates
inflation
fx
equity
commodity
credit
bond

Inflation is the class that separates the schemes. FpML, ORE's AssetClass and ORE's RiskClass carry it. The ISDA taxonomy, SIMM's RiskClass and FRTB do not, and report inflation sensitivity as interest rate sensitivity instead.

That treatment is a projection those schemes apply rather than a parent-child relation in the taxonomy, and the correspondence below records it as one. SIMM states the projection most directly: its RiskType declaration notes that "the risk type inflation has to be treated as an additional, single tenor bucket in IRCurve". The note describes where SIMM puts the exposure when it charges it, not where inflation sits among the markets.

All but one use case is a cut of the same list. The exception is SIMM's RatesFX, which groups two classes, whereas a cut selects classes without combining them. That case requires a grouping declared over the list rather than a class in it.

ORE Studio held cross_asset for market data that relates two classes, documented as "cross-asset correlations". The taxonomy does not carry it, because a correlation between an equity index and an FX rate is not a third kind of thing: it is a relation between two classes.

A correlation series should therefore reference two asset classes rather than one special value. That removes the only value in the market data enumeration that has no counterpart in any external scheme, and removes the need to explain it.

ORE does not carry the classes on the key. It names each operand after the factor class that operand belongs to, so the classes are recovered from the operand names:

A rates operand takes the fourth form rather than a prefix. A swap rate names its currency, not a class, and -CMS- is the part that marks it as one. The exception is real in the corpus and not a special case we introduced.

An operand matching no rule contributes no class. A correlation over two such operands therefore references no class at all, which the junction permits and a single not-null column would not. A pair whose two operands share a class references that class once, not twice.

This is a naming convention of the corpus rather than a published ORE contract. series_classifier implements it, and the corpus test runs every correlation pair the examples carry through it and pins the outcome for a cross-class, a same-class and a rates pair, so a change in the convention surfaces as a test failure rather than as a silently wrong class.

Bond is absent from both risk classifications for a good reason: a bond's risk decomposes into interest rate and credit risk, so it earns no risk class of its own. It is nevertheless a product class in FpML and an underlying class in ORE, and ORE Studio holds 11 bond products.

The taxonomy keeps it, and the risk cuts drop it. That is precisely the case the taxonomy exists to handle.

The analysis yields seven classes, all at the same level.

rates is renamed interest_rates. With inflation beside it rather than beneath it, the bare word no longer reads as the interest rate class on its own. fx keeps its present spelling, which is unambiguous and universally used.

The external spellings are recorded in the correspondence below rather than adopted. InterestRate and ForeignExchange buy nothing that interest_rates and fx do not already say.