Trade Modeling

Wikipedia defines a financial instrument as "a monetary contract between parties", and reports the accounting definition from IAS 32.11 as "any contract that gives rise to a financial asset of one entity and a financial liability or equity instrument of another entity". A product type is a class of such contracts.

In other words, kinds of contract recur, and a firm may support only a subset of these. A trader picks the kind of the thing being traded before entering any terms, and a firm may only enable or disable the trading for a subset of these. A risk engine may also only support a subset of the available product types.

The entity holds the properties that belong to the class rather than to any contract of it: a code, a description, and the asset class it groups under. It is a closed list, so a trade whose type is absent cannot be booked. Within ORE Studio it is modelled as trade_type, whose code column carries the catalogue's identifier.

Wikipedia defines a security as "a tradable financial asset", and adds that in a fungible security "all holdings of the security are treated identically and are interchangeable".¹ A security issue is one such asset as put into the market by its issuer. Fungibility is what makes it an entity in its own right: every holder of one unit holds the same thing, so the terms belong to the security issue and not to any one holding of it.

That is to say, some contracts are defined once and traded many times, and every holder holds the identical thing. For example, an issuer fixes a bond's coupon and maturity, and two traders dealing that bond cannot negotiate either. Their trades share terms that neither party chose. Fungibility is the observation that all holdings of the security are interchangeable, so the terms belong to the thing held - the security issue - rather than to any holding of it. Without it, an issuer's terms would be copied onto every trade in the issue, and the copies could disagree.

A security issue is therefore one tradable instance of a product type: this bond issue, this futures contract. One product type has many security issues, and traders deal the same security issue many times.

A bond issue is one such instance. An issuer sells a specific tranche of debt under fixed terms — coupon, maturity, currency, size — and an ISIN or CUSIP identifies it (c.f. Standard financial identifiers). The issuer is the borrower: a sovereign debt office, a corporate, an agency, a supranational. A central bank may run the auction, but it does not issue the government's debt.

Issuers re-open existing lines rather than always creating new ones. An issue therefore reads best as the security issue its ISIN identifies rather than as a single sale event. Bond issuance sets out the mechanics, and bond_issue models the entity.

The relationship from product type to security issue is optional, and many product types exercise that option. Two parties strike a vanilla OTC option between themselves, and no official issue exists because nobody defines the option once and trades it many times. A bond has an issue, a bond future has a contract, and a swaption has neither.

We therefore model security issues per product type as we reach each one, starting with the bond issue. The absence is a fact about the product type, not missing data for a later task to supply.

Wikipedia defines a financial transaction as "an agreement, or communication, between a buyer and seller to exchange goods, services, or assets for payment". A trade is that agreement recorded. We model it as a trade, and the trade id identifies it. That id names the trade inside this firm only, and trade identifiers covers the regulatory codes two counterparties share.

The trade models the notion of an agreement being struck at a time point between two identified legal entities, and establishes its controlling legal entity. Confirmation, authorisation, versioning, amendment and audit all attach to this agreement.

The trade's properties can be grouped into two:

• Envelope: the trade_envelope models administrative properties such as the counterparty, the netting set, portfolios, book and desk, and any further fields the firm may attach. It places a trade in the organisation. These have limited variability by product type, if any.
• Economics: The economic terms determine what the trade pays, to whom, and when, and vary greatly by product type. For example, the notional, the direction, the payment schedule, the strike, the rate, etc.

The two are read and may change independently: A trade may change portfolio or book without any changes to its economic terms, and the economic terms may change without any updates to the envelope. This categorisation is also important with regards to Confirmations.

Within ORE Studio, the instrument concerns itself with the economic terms or just economics of a trade. The economics differ in shape, not merely in value, between different kinds of contract: a bond's terms are a coupon, a maturity and a redemption; a swaption's are an exercise schedule, an underlying swap and a settlement method. No single set of columns holds both without leaving most of them empty.

The variation is structural, which is why the economics are an entity per product type rather than a wider trade table. However, the economic terms are properties of one agreement: a notional, a direction, a schedule and a strike all belong to that deal, and two trades on the same security issue carry different ones. The relationship between trade and instrument is therefore one to one, and the trade id identifies both.

FIX and MDDL meet this model only at the identifier. FIX carries an Instrument component block that names a security by SecurityID with a SecurityIDSource saying which scheme the value belongs to, and MDDL wraps any existing scheme in a controlled vocabulary. Neither proposes a persistent model of a trade: both describe a message on the wire. They matter here only because they confirm that a security identifier is meaningless without the scheme that issued it, which is the point standard financial identifiers makes.

FPML covers trading, valuation, confirmation, novation, amendment, termination and position reporting, and unlike FIX it specifies no transport: it is a data representation only. Its relevance here is the shape rather than the content. FpML represents a trade as a header carrying identifiers and parties, alongside one product element chosen from many. That is the same division this model makes between the envelope and the economic terms, and the same observation that the economic terms vary in shape by product rather than in value alone.

Its limitation is scope. FpML addresses OTC derivatives, so it says little about securities defined once by an issuer and traded many times, which is where our security issue entity earns its place.

The CDM (Common Domain Model) is the most directly relevant prior art. FINOS maintains it with ISDA, ISLA and ICMA. CDM defines a product from three attributes: an identifier, a taxonomy that classifies it, and economicTerms, described as "a parametric representation of the future financial obligations". It then defines a tradable product as the "definition of a financial product as ready to be traded, i.e. included in an execution or contract, by associating a specific price and quantity", which also binds exactly two counterparties.

The reuse mechanism is of particular interest. CDM normalises counterparty roles to Party1 and Party2, so that "the same product can now be defined in a party-agnostic way and used to represent transactions between potentially many different parties". A product definition is therefore instantiated many times.

CDM allows for two trades to share a set of economic terms by placing economicTerms on the reusable product. However, CDM's economic terms are parametric mechanics - payouts, date methodologies, termination rules — and carry no price, quantity or party, which are properties of the trade. What this model calls the instrument is the per-deal half: the notional, the direction, the strike. CDM's reusable half corresponds to our product type and security issue, and its tradable product corresponds to our trade. Both models therefore cut at price and quantity, and differ only in where they draw the boundary of the word "product".

Calypso separates Trade from Product. A product, in its terms, is a financial instrument that can be held or traded, defined once and traded many times, and it manages product holdings independently of trades. Calypso's Product is the definition (e.g. a bond, a future contract, a stock, etc.) which is the security issue here.

Murex builds a trade from Financial Contract Components, its elementary unit for P&L and sensitivity, and those components cannot live independently. A Financial Contract is the set of components dealt with one counterparty and processed as one object. The public material does not settle how definitions are shared between contracts, so the shape of a contract is established and its reuse is not.

Neither platform holds an entity between the trade and the product definition. Both descriptions come from vendor documentation rather than from a published standard, and neither is cited to an edition or page, so they corroborate the model without establishing it.

ORE is the ground truth for ORE Studio. Our entities must be a super set of the attributes in the related ORE entities, possibly normalised, so that a portfolio can round-trip between the two representations without data loss. ORE Studio's trades cannot be priced unless they can be represented into ORE format so we must address all divergences between data model.

ORE names the product type with a TradeType element on each trade, whose permitted values are the oreTradeType enumeration. Each product page in ORE Products by Asset Class states its TradeType, so the catalogue and the documentation can be read against each other.

ORE models security issues as ReferenceData, a list of ReferenceDatum elements. Each element carries an id attribute, an optional validFrom, a Type discriminator, and one payload chosen from a closed list: bond, bond future, convertible bond, callable bond, CBO, bond basket, equity, equity index, commodity index, credit index, currency-hedged equity index, credit, and portfolio basket. A bond trade names its datum through BondData/SecurityId, and a bond future names its contract through ContractName.

ORE divides the trade itself into the Envelope element and the trade-data group, which offers one choice per TradeType. That division is the same one the domain gives, which is why our model keeps it.

Both the reference datum payload and the trade-data group are choices discriminated by type. An XML schema expresses a choice directly; a relational model expresses it as a table per type. The two sides of the ORE model therefore have the same shape as each other, and one modeling approach covers both.

Our entity	ORE representation
trade_type	The oreTradeType enumeration, and the TradeType element on a trade
bond_issue and its siblings	ReferenceData, as a ReferenceDatum with a Type discriminator and its payload
trade	The Trade element, identified by Trade/@id
trade_envelope	The Envelope element
bond_instrument and its siblings	The trade-data group, one choice per TradeType

In terms of divergence, ORE carries no identity between its trade and its trade data, because the trade data is a child element of the trade and needs none. Our instrument_id is therefore a divergence from ORE rather than a reflection of it, and it is the one place where the correspondence above does not hold.