The hard parts of market and reference data.
Handled.

Typed identifiers. Traceable connections.

Identifiers carry their type: ISIN(…), WKN(…), CUSIP(…), or a configured vendor-specific type—not an unexplained string. Source records assert which identifiers refer to the same entity. Identity resolution connects those claims within the appropriate entity type and selects a leading identifier using configured priorities.

Alternative identifiers and contributing source records remain available. Your product gets a common reference without discarding provider IDs or rewriting authoritative source data. An issuer’s LEI identifies a legal entity, not the instrument it issued.

Same instrument does not mean same listing.

An instrument can have several trading lines. Keep its identity separate from venue, currency, and other source-defined dimensions. Resolve the instrument, then filter the selected Catalog’s records for the trading context your product needs. A lookup can return several records; even ISIN, MIC, and currency are not universally sufficient to identify one listing.

When you need one exact source record, address it by {catalog, record_key}. Its key stays source-owned—not a universal instrument ID or a vendor-independent listing ID.

Changing claims, priorities, and exact references

Resolution uses source-supplied claims and configured policies, not name matching or an assumed global identifier table. Source updates and withdrawals recompute affected mappings; downstream remixers follow the published Identity Catalog. Conflicts and rebalances remain inspectable.

Combine your sources into one view.

Choose which input Datasets determine membership in a broad master Dataset. Resolve their records to shared entities, combine fields with your own source priorities and rules, and enrich them from other inputs. Remixing materializes its Catalog and updates affected entities as inputs change, retaining provenance and access requirements.

Remix again for specialist products.

Use a broad master as an input to a more focused Catalog, such as one for structured products. Add specialist sources and fields where that product needs depth, while the general master stays lean. Each output has its own membership and model.

Discover depth without copying everything.

Publish a per-entity overview of membership in configured input Catalogs, including record keys and lifecycle state. Your general master can link to in-depth information in a specialist Dataset without copying all its fields.

For example, show a “Structured-product details” link in your instrument navigation header only when that Dataset covers the instrument and the user has access—not simply because the instrument has a structured-product category label.

Add your own fields when remixing.

Define custom fields in your schema and populate them in your remixing rules or plugin. Combine source values, derive product-specific classifications, or add the business rules that make your master Dataset useful to your team.

Extend the importer. Keep the platform.

Reuse an existing importer and extend its mapping to capture more from the exchange feed. When the base model does not cover your needs, derive custom fields directly from the decoded feed messages, in the DSL or in code. Build and deploy your mapping plugin independently—without recompiling the importer or OpenMDTA’s service binaries.

First-class fields. All the way to your SDK.

Custom fields travel through the same schema-driven infrastructure as standard fields. The Gateway exposes them through your configured data model, and your auto-generated SDKs include their types and accessors automatically. No separate API or hand-written client wrapper for every field you add.

Lists and index families, ready for selectors.

Select instruments by list instead of maintaining member tables. Index families such as GER40, US500, TECH100, and EU50 are Catalog lists with metadata and identifier-only members. Use the base lists, publish your own, or remix them. A venue selection resolves each member to matching records, subject to coverage and access rights.

const selected = selector.list("GER40").venue("XETR");
const quotes = connection.select(selected).latestStream();

Composition is fixed for a request. A new request or reconnect reads it again. Weights, index calculation, and index values are separate concerns.

The whole market, not just one quote.

Beyond single-instrument snapshots, a stream feed delivers the market data of every instrument in a Dataset: in source order, with gaps made explicit, in real-time, delayed, or end-of-day quality.

All your reference data, in one feed.

A Catalog feed delivers every reference-data record with the fields you choose and marks progress with cursors. Use it to fill your own database, cache, or search index.

Different users. Different data access.

Your server creates and signs user-specific access tokens, limiting each user to their licensed subset of data packages and delivery quality. Signing keys stay on your server; clients receive only short-lived, signed access tokens. The Gateway and services enforce the applicable access rules.

For example, your real-time NASDAQ Level 2 license does not mean every user should get that access. Grant premium exchanges or specialist Datasets only to entitled users, while others keep access to your standard offering.

Your application maps subscription plans to grants and handles billing. OpenMDTA handles data access within the rights you hold.