Data Interoperability in Capital Markets

Identity before integration

Market systems use several identifiers because each one serves a particular function. A ticker can be useful in a trading interface, but it can be ambiguous across venues, countries, currencies, and share classes. A CUSIP or ISIN can identify an issue for established processing. An internal identifier can support a firm's own records. A contract address identifies deployed code on a particular network. None of these fields is a complete substitute for the others.

The task is to maintain governed relationships among identifiers. A security master should identify the issuer, instrument type, class or series, terms, restrictions, and relevant identifiers. It should then relate those facts to listed market representations, conventional settlement identifiers, token contracts, networks, and programme-specific codes where applicable. It should also record the source, confidence, effective period, and approval behind each mapping.

FIGI provides a useful hierarchy for this work. For equities, a Share Class FIGI connects the same class across markets; a Composite FIGI provides a market-level view; and a Trading Venue FIGI identifies the instrument at a specific venue. OpenFIGI describes this hierarchy as a way to distinguish the global share class, market representation, and listing without losing their relationship. A FIGI is reference-data infrastructure. It does not establish legal title, identify a wallet, determine custody, or prove token supply.

An accurate identity map prevents class collisions. A token related to one security class should not be joined to a similarly named listing, depositary receipt, option, or a different class of common stock simply because a ticker appears familiar. It also prevents a technical identifier from being promoted into an unearned legal claim. The model should show whether a contract represents a direct issuer security, a security entitlement, a custodial interest, or another defined product.

Six linked data domains

The instrument master is the first domain. It holds durable financial facts: issuer, class, terms, currency, seniority where relevant, identifiers, and restrictions. These records change, but usually through controlled events such as an issuance, amendment, corporate action, or correction. The instrument master supplies the identity against which every downstream position and event should be evaluated.

The representation master is the second domain. It records how the relevant interest appears on each rail: conventional book-entry quantity, tokenized security, tokenized entitlement, contract, network, token standard, supply status, and relationship to the source position. A single instrument can have multiple valid representations. The model must show whether they are alternative formats, linked positions, or unrelated products with similar economic exposure.

The account and party master is the third domain. It relates legal entities, participants, accounts, custody arrangements, authorised roles, and relevant customer or beneficial-owner information maintained by responsible providers. A wallet key may sign a transaction, while a separate account record identifies the owner, authority, restrictions, and custody relationship. The data model should preserve this distinction rather than collapse it into an address field.

The endpoint master is the fourth domain. It contains approved wallet, contract, network, account, custody, and settlement endpoints. An endpoint record should include status, permitted activity, source, effective period, and change history. A technically valid address can still be unsuitable for a particular instrument or programme because its associated account, network, authority, or restriction state has changed.

The event and lifecycle model is the fifth domain. It retains dynamic activity such as instruction receipt, validation, tokenization, transfer, settlement, corporate action, reversal, and de-tokenization. Each event should have a unique identifier, source, time, status, initiating party, relevant inputs, and linked evidence. Unique event IDs and idempotency controls prevent a delayed callback or retried message from creating duplicate postings.

The control and restriction master is the sixth domain. It connects availability, holds, programme restrictions, eligible endpoint status, authority, and other controlled conditions to the financial event. Appropriate responsible providers determine legal and compliance outcomes; the operating model records the current status needed to apply the resulting controls. Compliance-Aware Token discusses this connection at token level.

Reference data, state data, and event data

Reference data describes relatively durable facts: issuer name, identifier, class, maturity date, governing terms, or contract mapping. State data describes a current condition: available quantity, held status, pending settlement, active token supply, or current wallet eligibility. Event data records what happened: a tokenization instruction, transaction receipt, account posting, or an approved correction.

These categories need different treatment. Reference data requires controlled source and effective-dated changes. State data needs current monitoring and reconciliation. Event data needs an immutable or otherwise retained history that can explain how the state changed. Replacing old values without history prevents a firm from reconstructing which information was valid when an earlier instruction was processed.

Effective dating provides that history. A mapping can have a valid-from and valid-to time, an event time, a processing time, and a correction time. They can differ. A corporate action may become effective on one date, be processed later, and be corrected after a source update. The system needs enough temporal detail to recreate the appropriate point-in-time view for an audit, reconciliation, entitlement calculation, or operational investigation.

The tokenized-security mapping challenge

A hybrid tokenized-security model needs explicit cross-rail mappings. It should connect the conventional instrument to the contract and network; the source account to the controlled conventional quantity; the participant or account to an approved wallet; token supply to the applicable source or control position; and token events to lifecycle instructions and associated records. These are independent relationships. An accurate contract map does not validate account authority, and a current wallet map does not prove that the relevant quantity is available.

The SEC staff statement describes issuer-sponsored arrangements in which a crypto network can constitute or form part of a master securityholder file, as well as models in which onchain activity updates an offchain file. It also describes third-party custodial tokenized securities and synthetic structures. Those models require different mappings and record hierarchies. Master Securityholder File and Tokenized Securities Interoperability provide the broader context.

Semantic consistency across lifecycle states

Data fields can be syntactically valid and still be operationally unsafe. Consider the status “settled.” An execution venue may use it to indicate matched activity. A token network may use it for transaction finality. A custody or depository system may use it after a delivery and payment process has posted. An internal workflow may reserve the term for a reconciled end-to-end result. The systems need a canonical definition and a way to preserve the originating status alongside the mapped internal status.

“Available” and “burned” require similar care. A position can be held but unavailable because it is reserved for settlement or a tokenization instruction. A token burn can remove a technical representation while the related conventional-account credit and reconciliation remain pending. Clear states prevent operations from treating partial completion as a completed lifecycle outcome.

Lineage, provenance, and reconciliation

Data quality includes source provenance. A value should retain the responsible source, ingest time, effective time, approval or verification method, prior value, reason for change, and linked event or change record. Completeness checks can identify missing fields. They cannot establish that an account mapping is current, that a contract relationship is approved, or that a source is appropriate for a particular financial fact.

Reconciliation tests the model continuously. It compares conventional quantity with token supply where the programme requires that relationship; validates wallet-to-account and contract-to-instrument mappings; compares lifecycle states; and checks that corporate-action information reaches the eligible account or holding record. Reconciliation is therefore a data discipline, not merely a back-office process after settlement.

Data interoperability in Devancore

Devancore can use an instrument-led data model to relate FIGI hierarchy, conventional identifiers, listings, contracts, networks, tokenized representations, accounts, wallets, provider records, lifecycle events, and controls. It can retain source metadata, effective dates, event lineage, and reconciliation outcomes across hybrid workflows.

Devancore does not determine legal title, establish a security's legal classification, verify external data as legally conclusive, or replace issuer, transfer-agent, depository, custodian, broker-dealer, or other provider records. Responsible institutions retain their own decision rights and authoritative records.