A system of record is not a place to store data. It is the source every workflow trusts.

The platform needs canonical records for participants, instruments, accounts, positions, cash, instructions, controls, and lifecycle events before automation can be trusted.

• The problem begins with identity

  Who is the counterparty? Which legal entity controls the account? Which custodian is involved? Which account is the trade allocated to? Which instrument is being traded? Which identifier is authoritative for the workflow? Which settlement instruction applies? Which position view is being used? Which control rule should run? If those answers come from different systems, the firm does not have automation. It has synchronization risk.

• Canonical, not duplicated

  Devancore is not saying that every firm stops using other systems. It is saying the post-trade operating base should be canonical. Existing systems can integrate, but the operating record used for post-trade workflows should not be reconstructed from conflicting copies.

Reference data is operational infrastructure.

Counterparties, instruments, accounts, identifiers, jurisdictions, and roles are not static lookup fields. They determine how trades settle, how positions reconcile, how controls run, and how reports are supported.

• Not administrative setup

  Reference data is often treated as administrative setup. In post-trade operations, it is infrastructure. A participant record should support multiple roles without duplicating the entity. A custodian can also be a bank. A prime broker can also be a counterparty. A fund administrator can also be a service provider.

• One instrument across views

  An instrument record should support the identifiers required by the workflow. A traditional security may need ISIN, CUSIP, market, currency, and issuer context. A tokenized representation may need contract address, chain, token identifier, and a link back to the regulated instrument or fund record. The point is that the instrument should remain one operating object across views.

• Account hierarchy the firm actually uses

  An account record should support the hierarchy the firm actually uses: fund, sleeve, strategy, custody account, omnibus structure, segregated account, bank account, or internal operating account. Compliance rules, positions, cash balances, tax lots, and reporting all depend on that hierarchy.

SSI quality determines whether settlement automation is real.

A settlement instruction should be generated from governed participant, account, instrument, rail, and destination data, not from a spreadsheet or stale local copy.

• Where quality becomes visible

  Standing settlement instructions are one of the most practical places where system-of-record quality becomes visible. An SSI tells the firm how an account or counterparty expects settlement to occur: custodian, account, place of settlement, rail, delivery or receive destination, cash leg, and any instrument or market-specific routing.

• Traditional and digital routing

  In traditional workflows, this may involve DTC, Euroclear, Clearstream, SWIFT, custodians, bank accounts, and local market settlement details. In digital or tokenized workflows, the evidence may include wallet addresses, chain identifiers, transfer-agent records, smart-contract references, and rail-specific finality expectations.

• Governed SSI master

  Devancore's SSI master is governed reference data. It supports traditional and digital rails, can be scoped by account, instrument, market, place of settlement, rail, and infrastructure where the operating model requires it, and is designed to preserve change history and control evidence for settlement instruction generation.

• Structural source of preventable failure

  SSI quality does not eliminate all settlement fails. It removes one major structural source of preventable settlement failure: stale, missing, duplicated, or uncontrolled instruction data.

Trade-date and settlement-date views should share lineage, not fight each other.

Portfolio managers, operations, finance, compliance, and reporting teams need different views of positions and cash, but those views should trace back to the same lifecycle events.

• More than one position view

  Trade-date positions show what the firm expects based on executed activity. Settlement-date positions show what has settled and can be reconciled against external records. Cash may need equivalent trade-date and settlement-date treatment. Tax lots need acquisition and disposal history. Finance needs valuation, cost, unrealized and realized views. Compliance needs current exposure. Operations needs reconciliation status and breaks.

• Connected by one event history

  A trade capture updates the expected position. A settlement event supports the settled position. A reconciliation run compares internal and external views. A break opens a case. A resolution preserves evidence. Finance processes can read the same underlying record rather than importing an after-the-fact spreadsheet.

• Platform bridge

  System of Record anchors the data. Trade Lifecycle creates and changes the lifecycle state. Finance & Reporting reads the controlled position, cash, tax, and valuation evidence. Controls & Compliance evaluates rules against the same account and position base.

Onboarding is how reference data becomes permission to operate.

A counterparty, account, market, intermediary, infrastructure, or SSI should not become live until the required evidence, review, and control state are complete.

• Permission, not paperwork

  Counterparty onboarding is not a form. It is the process of turning a relationship into operating permission. The firm needs to know which trading entities are in scope, which markets apply, which intermediaries are used, which infrastructures are connected, which accounts are active, which documents are required, which requirements are satisfied or waived, who reviewed the relationship, and what remains blocked.

• Email onboarding creates gaps

  When onboarding is handled in email, the system of record starts with missing evidence. The first trade then inherits the gap.

• One operating chain

  Reference data, onboarding, and controls are one operating chain. The firm should not activate a relationship in one place, configure SSI somewhere else, and enforce restrictions in a third system. When a control detects a breach or exception, that event should link back to the account, instrument, position, rule, actor, review decision, and resolution.

Operations leaders need broad visibility without broad action rights.

A command-center view should show participant health, settlement status, open cases, control exceptions, reconciliation breaks, and rail conditions without bypassing the workflows that own each record.

• Visibility, not action surface

  The Command Center should be positioned as visibility over the system of record, not as a place where every action happens. Broad visibility should not automatically create broad authority to change records.

• Read-only as a control

  The Command Center can summarize, explain, and point users to the owning workflow. It should not turn an executive dashboard into an uncontrolled action surface.

• Ops Copilot role

  If Ops Copilot is included, its role is explain-only, read-only, and logged. It may summarize why a settlement is blocked, why a chain event is pending, why a case is aged, or what evidence exists. It should not approve actions, change records, release instructions, or make compliance decisions.

• Coherent record base required

  The Command Center works because the underlying system of record is coherent. If the record base is fragmented, the dashboard becomes another reconciliation layer.

The system of record is the foundation for every post-trade workflow.

Use these pages to move from the canonical record model into lifecycle workflows, controls, finance, connectivity, use cases, and glossary definitions.