ores.trading.credit_instrument

Trade type code (soft FK to ores_trading_trade_types_tbl).

One of the family's codes; the coverage check the routed-instrument template generates from the trade-type catalogue lists all of them.

std::string("CreditDefaultSwap")

Party that owns this instrument. The family's party boundary: the fact and child rows carry no party of their own.

Set from session variable app.current_party_id.

The trade this instrument belongs to, and the instrument's own key.

The trade id identifies both the trade and its instrument, so the header carries no identity of its own: this column is the key, and the trade it names gives the instrument its scope. Every fact and child row of the family names the same trade.

The activity that wrote this version.

What kind of identifier reference_entity_id states: the legal entity's LEI, or an identifier the system's own data uses.

A reference is typed rather than guessed, because a credit curve named ACME in an engine document and an LEI are different things and a column that holds either without saying which cannot be joined to anything.

The closed set is LEI and Internal. It is a check on this column rather than a catalogue table, because the two kinds of identifier are a property of how a reference is stated and not a list the tenant curates.

std::string("LEI")

The identifier of the reference entity the risk is on, read with reference_entity_id_type.

Every credit product states one. When the type is LEI the value is the legal entity's LEI and the soft reference below applies; when it is Internal the value is the identifier the source states, such as an engine document's credit curve or issuer id, and nothing is claimed about a legal entity.

Soft FK to the DQ lei_entity dataset when the type is LEI: the entity belongs to that dataset rather than to a trading table, so the reference is recorded rather than copied. A later change tightens it into a real foreign key once a legal entity lives in refdata.

Resolving an internal identifier into an LEI replaces both this value and its type together, so a trade states one identifier and never two.

std::string("ORESLEI0000000000001")

The instrument's start date. A risk participation agreement's protection start is this column.

Null when the product states none.

ISO 8601 date string (YYYY-MM-DD).

The instrument's maturity date. A risk participation agreement's protection end is this column.

Null with start_date, and for the same reason.

Optional free-text description.

The trade that carries this instrument. An instrument is written beside its trade, so a row cannot exist without one.

#include "ores.trading.api/generators/trade_generator.hpp"
#include "ores.trading.core/repository/trade_repository.hpp"

{
    auto anchor = ores::trading::generators::generate_synthetic_trade(ctx);
    anchor.party_id = *party_ctx.party_id();
    anchor.trade_type = v.identity.trade_type_code;
    ores::trading::repository::trade_repository().write(party_ctx, anchor);
    v.identity.trade_id = anchor.id;
}

The activity that wrote this version. A database foreign key: the activity is immutable.

#include "ores.trading.api/generators/trade_activity_generator.hpp"
#include "ores.trading.core/repository/trade_activity_repository.hpp"

{
    auto activity = ores::trading::generators::generate_synthetic_trade_activity(ctx);
    activity.party_id = *party_ctx.party_id();
    ores::trading::repository::trade_activity_repository().write(party_ctx, activity);
    v.identity.trade_activity_id = activity.id;
}

The header copies the anchor's party and trade type, so the insert trigger checks the copies against the anchor's current row and refuses a row that disagrees. The anchor is a versioned table, so a database foreign key cannot name it and the pin is a trigger check, as the trade_id key is. The fact and child tables carry neither column: they reach both through this row (design decision D3), so the header is the only row of the family that can disagree.

The insert trigger stamps party_id from the session, and row-level security hides another party's anchor, so in practice the pin refuses a disagreeing trade_type_code; the party column is held to the anchor as well, so a path that bypasses the stamp cannot drift from it.

The anchor's model states that its party and trade type are fixed for the trade's life and that a change is a cancel and rebook. The anchor's write path does not enforce it, so an amendment that changed the trade type would leave the header unchecked. That gap belongs to the trade model, not to this family, and it is open.

The tenant isolation and the party isolation policies are hand-written in trading_rls_policies_create.sql, as bond_instruments' are: the header carries party_id, so it needs the restrictive party policy beside the tenant policy, and the generated :rls_tenant_isolation: form states the tenant policy alone.

The trade's economic digest observes every write of this component. The observer's specialisation must be visible where the repository writes, so the repository includes it.

#include "ores.trading.core/repository/trade_write_observation.hpp"