Tables

An Account is the element in the model that links trading activity to the users undertaking that activity. All Accounts are owned by a Firm and it against one of these Accounts that Holding records are managed in the system.

AccountTypes provide a categorisation of Accounts in MarketGrid.

For CCMX transactions (Carta Cross, Tender, RSU Settlement), the Auction table is used to hold and manage details for each transaction. Each Auction record must correspond to one (and only one) InstrumentMarket record - the Auction is effectively an extension of an InstrumentMarket with CCMX-specific fields.

The AuctionAccount table is used to assign Accounts to Auctions, i.e., to allow one or more Accounts to participate in an Auction. The table stores the specific Auction-related parameters for each Account on the Auction along with data about each Account's participation.

Working scratch for allocation to child AuctionAccounts from a parent.

This table maintains the seller allocations for a CCMX Tender transactions. The seller allocations are calculated at the end of the initial phase of the Tender. They may be subsequently adjusted according to instructions from the Issuer to derive a final set of allocations for the Tender. Each record is an allocation for a particular AuctionAccount for a particlar SettlementClass. The allocations in this table and any subsequent adjustments flow into the AuctionAccount and AuctionAccountDetail tables.

For (multiclass) Tender transactions, this table tracks the breakdown of an AuctionAccount's order and trade quantities and values by SettlementClass. Each record has details for one AuctionAccount + SettlementClass combination.

The AuctionAccountRelationship table is used to allow various parameters for an Auction to be set per AccountRelationship.

The AuctionSession table is used to define and set up the parameters for the Sessions for an Auction. An AuctionSession corresponds to two SessionTime records, one for the entry to the AuctionSession and for the exit from the AuctionSession.

This table enumerates the Settlement Classes that are available for trading on a particular Auction. The Settlement Classes must all be associated with the same Issuer as the Auction's Issuer (Instrument).

A BankAccount record is used to represent further information for an ExternalAccount record where the authority issuing the account is a bank.

This is an entity to record changes in the BlobObject structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

An Enterprise is used to provide a grouping mechanism for Firm_ entities in the Trading System.

This table enumerates valid Equity Clases supported by Carta. Each Equity Class belongs to an Issuer and is associated with the Issuer via its IssuerAccount. This table is not required for MarketGrid processing, it is informational only and passed through for reporting.

Used to persist the prevailing exchange rate for each currency pair when the system is shut down or shared memory is refreshed. For fast lookup of the exchange rates in the engine, see the CurrentExchangeRate table. For consumption of rates by other processes, see the ExchangeRate_change change table.

Records changes to exchange rates.

An ExternalAccount represents a account for whom the authority is outside of MarketGrid: for example, an account with a share registry or a bank.

An ExternalAccountProvider represents the authority that issued that account (for example, the registry or bank).

Fees are reserved on orders and paid on trades. This table stores fee configurations & multiple Fee records are grouped in the FeeSet table. More details on fees

A Firm is the organisational unit into which users of the Trading System are grouped. Every Firm belongs to one Enterprise.

Mapping which AccountTypes may be used for particular Firms. It also determines which FeeSet if any should be applied for this kind of Account.

The FirmName table is a public form of the Firm table that may be distributed to any user. It is created automatically from the Firm table.

A Group is an entity that belongs to a Firm and to which Users in the Firm may be associated (via the GroupUser table). A Group may be assigned a set of Permissions which will be inherited by all Users that are members of the Group. See the document Permissions and Access control for more details.

The GroupUser table associates Users with Groups. Each record defines an association between one Group and one User. Users may only be associated with Groups that belong to their Firm.

A Holding describes the position held by an Account_ for a given Instrument_. Such a position is a combination of the balance at the start of the day and the aggregate actual buys and sells completed since the opening balance. In addition, the balances of planned transactions (effectively the unmatched Order_ records) are also recorded here for the purposes of monitoring and risk management.

A Holding describes the position held by an Account_ for a given Instrument_. Such a position is a combination of the balance at the start of the day and the aggregate actual buys and sells completed since the opening balance.

A Holding describes the position held by an Account_ for a given Instrument_. Such a position is a combination of the balance at the start of the day and the aggregate actual buys and sells completed since the opening balance.

Used to reserve discrete quantities from the AvailableBalance for a Holding record. The key for this table is Holding/Type/RelatedRecord, allowing discrete quantities to be reserved for each Type for a given Holding record (each discrete quantity has a unique RelatedRecord).

This is an entity to record changes in the HoldingTransaction structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

Industries are a part of the mechanism for the economic classification of the Instruments that are modelled in the system. An Industry is a collection of Sectors and an arbitrary number of sectors may be placed within an Industry. Each Sector_ that is defined in the data, must belong to one Industry.

An Instrument is the entity that represents something to be traded in MarketGrid. In order for an Instrument to trade it must be listed on a Market_ to produce an InstrumentMarket_. Each Instrument may be traded simultaneously on one or more Markets, each such instance being an InstrumentMarket_.

An InstrumentGroup is used to group Instrument instances into logical sets, such as Equities or Currencies, to facilitate the setting of common parameters and rules across each InstrumentGroup.

InstrumentMarket is the entity that represents an Instrument in a specific Market. It is the entity for which all trading activity is undertaken and at which level all the market data is collected for distribution.

This table represents a piece of Level One data.

An internal table that contains snapshots of Level One data to allow a shared memory consumer to quickly get to the current state.

A Market is the entity used to provide the mechanism by which a set of Instruments can be traded using a common set of parameters and rules. Each Instrument_ may belong to one or more Market_ enabling the Instrument_ to be traded simultaneously using different rules and matching algorithms

This table holds settlement class information for each Auction + SettlementClass + EquityClass combination. It is not used for processing in MarketGrid, just pass-through for reporting.

This table holds settlement information for each trade-option combo. It is used for reporting and not for MarketGrid processing.

An Order is the fundamental record of trading activity in the system.

An Order is the fundamental record of trading activity in the system. This is an entity to record changes in the Order structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

An Order is the fundamental record of trading activity in the system. This is an entity to record changes in the Order structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

This is an entity to record changes in the OrderBook structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

An internal table that contains snapshots of Level Two data to allow a shared memory consumer to quickly get to the current state.

An OrderNotional is the placeholder for holding notional order entries.

A PriceStepSet defines a set of price steps that are permissible when validating the price being used for a particular Entity. Each price step is applied from a given price point until the next price step is defined.

A QuantityStepSet defines a set of quantity steps that are permissible when validating the quantity being used for a particular Entity. Each quantity step is applied from a given price point until the next step is defined.

A RegistryAccount record is used to represent further information for an ExternalAccount record where the authority issuing the account is a registry.

This is an entity to record changes in the RFQ structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

This is an entity to record changes in the RFQRecipient structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

Sectors are the primary mechanism for the economic classification of the Instruments that are modelled in the system. A Sector is a collection of Instruments that usually share a common underlying economic characteristic that makes grouping them convenient for a number of purposes.

This table holds securities sold information for each trade-option combo. It is used for reporting and not for MarketGrid processing.

The Sessions that define the matching algorithms that may be used for Products are maintained in this table.

Controls when Sessions and Trading Rules are applied to Products.

This table enumerates the available Settlement Classes for each Instrument (Issuer).

The System structure holds the current state for the Trading System. This includes all the time values used throughout the system backend. There is only ever one record in this table.

The Trade Entity stores all the information about a bargain that is recorded in MarketGrid. It consists of a reference to both the buy and the sell Orders that produced the Trade as well as details about the Trade itself, such as price and quantity.

The Trade Entity stores all the information about a bargain that is recorded in MarketGrid. It consists of a reference to both the buy and the sell Orders that produced the Trade as well as details about the Trade itself, such as price and quantity. This is an entity to record changes in the Trade structure. It holds records that are already prepared for sending out via the market data streams (for example resolving internal shared memory indexes into external foreign key Ids)

Working scratch for allocation to child trades from a parent.

The User Table contains a list of the UserIds that are used by individuals to log into the Trading System. Every User belongs to a single Firm.

The UserName table is a public form of the User table that may be distributed to any user. It is created automatically from the User table.

A Venue is a collection of Markets. It is a way of grouping markets into a single entity to represent an exchange or other market operator that is responsible for more than a single Market. Markets are grouped by Venue, each Market belonging to one Venue.

This table holds Virtual Reference Numbers (VRN) for JPMorgan linked accounts. VRN information is a list of all acquired VRN and what accounts they're associated with. If a VRN association is removed (eg. account is assigned a new one), the old one is put in 'Suspended' status.