Product Family

A product type carries three independent classifications, and this document covers the third.

A product family is the contract shape a product type takes, stated independently of the market it references: a swap, an option, a forward, a future. It exists so that every swap can be seen across markets, or every option, which neither of the other two classifications permits. The product type is too fine, since FxForward and CommodityForward are separate values. The asset class is orthogonal, since it answers a different question.

Asset classes covers the second classification, and its reasoning is not repeated here.

The ISDA product taxonomy is the obvious source for this classification, and it does not supply one.

Its values are colon-separated paths whose first segment is an asset class. The second segment looks like a contract shape when read through the interest rate or equity branches, which offer IRSwap, Option and Forward. Read across all five branches it is not a shape at all, because each asset class cuts the second level along a different kind of distinction.

Commodity settles it. Agricultural and Metals are markets, not contract shapes, so no reading of the level yields a shape taxonomy. Credit cuts by how many reference entities a contract names; FX cuts by complexity. Even where shapes do appear the naming is inconsistent across branches, since interest rates carry IRSwap where equity carries Swap.

Nor is the level abstract in the sense needed here: it is defined per asset class rather than across them, so two branches may use one word for different cuts or two words for one cut without contradiction.

The families described here are therefore ORE Studio's own, derived by observing what the product types have in common. ISDA's taxonomy is prior art that declined to abstract at this level, and the reason is visible in the table above: each asset class had a more useful second cut available to it.

Declining to adopt ISDA's values is not declining to record them. The taxonomy is a published coding scheme, and the same treatment already applied to FpML's asset class scheme applies here: register the scheme, hold its values, and map them to the product type.

That gives a product type a set of external classifications alongside its internal ones, each attributed to the authority that issued it. Coding schemes covers the mechanism.

The mapping is what a consumer needs. A trade reported under a regime that requires an ISDA taxonomy value obtains it by mapping from its product type, rather than by the product type being expressed in ISDA's vocabulary.

Surveying the product types by the shape their names carry gives the following distribution.

The distribution is itself informative. Options and swaps account for most of the catalogue, which is what makes the classification worth holding: a question about options spans fifty-two product types and five markets, and neither of the other classifications can express it.

Security is the family that shows the survey is not a list of derivative shapes. A bond is a shape of contract in the same sense the others are, but it is an instrument held rather than an agreement struck, which is why it also carries an identity of its own in standard financial identifiers.

No family names a container. CompositeTrade is a construction method, as the next section argues, so it carries no family rather than a family of its own.

The remaining product types do not fall into a shape by name, and the families above are a survey rather than a settled enumeration. Establishing the complete list, and deciding whether a family such as Position is a contract shape at all, is work this document scopes rather than performs.

Neither this classification nor the external schemes are required to model trades and their related entities.

A product family serves aggregation and reporting: it answers questions about the catalogue rather than participating in the definition of a trade. A trade is complete without it, because its product type already determines everything the family could tell you.

The same holds for the regulatory buckets described in regulatory risk buckets. Those are published enumerations that should be registered as schemes and mapped to the product type in the same way as ISDA's taxonomy, rather than adopted into any internal taxonomy.

Both are therefore recorded here as work that follows the trade modelling effort rather than blocking it. Trade modeling sets out the entities that effort covers.

• Whether Position is a contract shape. A position in a security is arguably a holding rather than a contract, and grouping it with swaps and options may say more about naming convention than about the domain.
• How a product type with no shape in its name is classified, and whether the family is derived from the name at all or asserted per product type.
• Whether construction is a boolean, a small enumeration, or several independent flags, given that a trade may be both composite and contain scripted components.
• Which external schemes are worth registering beyond ISDA's taxonomy and the regulatory enumerations.

The ISDA product taxonomy values are read from the FpML coding scheme at fpml.org, retrieved on 16 September 2026, by extracting every second path segment and grouping by asset class.

The product type distribution is derived from trading_trade_types_populate.sql by matching the shape word terminating each code, which is a survey of naming convention rather than an authoritative classification.

• Trade — the structure note that orders this cluster, and where to read this page in it.
• Asset Classes — the second classification a product type carries.
• Regulatory Risk Buckets — published enumerations to be registered and mapped, not adopted.
• ORE Products by Asset Class — the catalogue these classifications apply to.
• Coding Schemes — the mechanism for holding an external scheme's values.
• Trade modeling — the entities a trade is built from.
• Knowledge — the hub of all knowledge notes.