Post-Trade System of Record & Reference Data Management

Every workflow reads from the same record. Because there is only one.

The Golden Record for participants, standing settlement instructions, and account structures: unified across traditional and digital rails. The operational foundation every other workflow is built on.

Post-trade operations fail at the edges. Not in the exotic scenarios that risk managers model — in the mundane, compounding failures that accumulate from reference data drift: a counterparty that appears as three different entities in three different systems, standing settlement instructions maintained in a spreadsheet that drifts from the production environment, a new digital asset network whose onboarding configuration lives outside the operational record.

The system of record problem is, at its core, an identity problem. Every trade has counterparties. Every settlement has instructions. Every counterparty relationship has governing limits, KYC documentation, and monitoring rules. In most post-trade environments, these facts are distributed across multiple systems: the prime broker appears differently in the trade capture system than in the settlement system than in the compliance database. A discrepancy between them is not caught until it surfaces as a mismatch or a failed instruction.

Devancore's system of record is not a feature on top of the operations layer. It is the ground the operations layer runs on. Every participant in the counterparty directory, every standing settlement instruction in the SSI master, every account structure record: these are canonical. Not synced across systems. Not maintained in parallel. The same record, referenced by every workflow that touches it.

Counterparty directory: one canonical counterparty record, globally interoperable

Settlement instructions fail. Corporate action elections miss deadlines. Counterparty exposure calculations produce inaccurate results. The root cause, more often than technology teams expect, is not a process failure — it's a data failure. The firm's systems contain multiple versions of the same entity. Reference data management is the work that should have come first.
  • Single resolution point

    The counterparty directory in Devancore is designed as the single resolution point for every entity that appears in the workflow: counterparties, custodians, prime brokers, fund administrators, external reporting entities, and internal accounts. Each entity is a single record with a primary identifier (LEI where available, internal ID otherwise) and configurable role assignments. A custodian that is also a prime broker is one record with two role assignments — not two records that require reconciliation.

  • LEI and DTI mapping

    Devancore natively maps ISO-standard identifiers, including Legal Entity Identifiers (LEIs) for institutional counterparties and Digital Token Identifiers (DTIs) for on-chain assets, ensuring the system of record is interoperable with regulatory reporting requirements and global entity registries. A counterparty record built around an LEI is a counterparty record that connects to trade repository reporting, prudential reporting, and cross-border settlement without manual re-identification at each regulatory interface.

  • Downstream workflows draw from the same source

    This matters operationally because every downstream workflow draws from the same source. When a trade populates counterparty data, it reads from the counterparty directory. When a settlement instruction routes to a custodian, it references the same record. When a compliance rule triggers a restriction against a counterparty, it applies to the canonical entity — not to one of several versions of that entity that might exist under different naming conventions in different subsystems.

  • Digital asset and on-chain participants

    For firms adding digital asset counterparties and on-chain participants, wallet addresses, smart contract addresses, these are mapped to known legal entities in the counterparty directory where counterparty identity is established. Governance workflows are applied appropriate to the participant type: a legal entity counterparty with an on-chain wallet receives full KYC/AML onboarding and ongoing monitoring; an unattributed address is handled with the governance configuration the firm's compliance framework requires. The on-chain participant is not a special case maintained outside the operational record.

Standing settlement instructions: SSI master for traditional rails and digital asset networks: SSI mismatch eliminated at the source

A standing settlement instruction (SSI) encodes how a given counterparty expects to settle a given transaction. In traditional operations, SSIs cover DTC participant numbers, Euroclear or Clearstream account references, SWIFT BICs, and correspondent bank chains. In a digital asset operating environment, they also cover wallet addresses, often multiple delivery endpoints per network per counterparty, blockchain network identifiers, and on-chain protocol-specific routing data.
  • The SSI mismatch problem

    Most firms that have added digital asset settlement capability maintain their digital asset SSIs separately: in a spreadsheet, in the custody platform's configuration, or in the institutional knowledge of the two people who manage that workflow. This is the SSI mismatch problem: when a settlement instruction routes to a digital asset network using SSI data that isn't the same version as what the operations team is referencing, the failure is invisible until a failed delivery surfaces it. That failure is not a technology lag. It is a structural consequence of maintaining two SSI systems.

  • Instrument-agnostic, rail-agnostic SSI master

    Devancore's SSI master is instrument-agnostic and rail-agnostic. A DTC participant number, a SWIFT BIC, and an Ethereum wallet address are entries in the same SSI record for the same counterparty: supporting multiple delivery endpoints per rail and per instrument type where the counterparty's operational model requires it. Changes to SSI records are designed to be governed through maker-checker workflows: the modification is a recorded event with maker attribution, checker approval, timestamp, and full state at the point of change. There is no separate digital asset SSI system that can drift from the canonical record.

  • Canonical lookup at instruction time

    By maintaining SSI data for all rails in a single governed record, the firm eliminates the instruction-mismatch fail exposure that results from counterparty data discrepancies between systems. When a confirmed trade routes to the settlement desk, the SSI lookup draws from the canonical master. The operations team does not manually key settlement instructions from a spreadsheet. The SSI is the record; the settlement workflow reads it.

Counterparty onboarding software: time-to-trade-ready across every rail simultaneously

A counterparty that has been onboarded for traditional settlement, DTC, SWIFT, is not automatically trade-ready for digital asset settlement. Each rail carries its own operational data requirements, compliance checks, and SSI entries. Most onboarding workflows address each rail sequentially, creating a "Digital Asset Onboarding Bottleneck" where an institutional mandate can be delayed weeks by an onboarding process that was designed for one rail at a time.
  • Trade-ready across all rails simultaneously

    Devancore's onboarding workflow is designed to make a counterparty trade-ready across all rails simultaneously. The account structure, the set of accounts, limits, restrictions, and monitoring rules associated with each participant, is maintained in the same system as the operational record it governs. Onboarding a new counterparty runs through a structured queue: documentation collection appropriate to the counterparty type, approval routing to designated principals (with timestamped, attributed decisions in the event log), SSI configuration across all rails the relationship requires, and activation into the live counterparty directory upon approval. An onboarding event is a recorded workflow — not an email chain. An onboarding approval is a principal sign-off in the compliance record — not a verbal authorization.

  • Account structure and hierarchical mapping

    The account structure supports hierarchical account mapping: omnibus accounts, segregated client accounts, and sub-accounts where the firm's custody and reporting model requires it. Each account level carries its own limit, restriction, and monitoring configuration, applied consistently whether the underlying settlement occurs via DTC, SWIFT, or on-chain.

  • Restriction Manager and ongoing monitoring

    Ongoing monitoring runs against the account structure continuously. The Restriction Manager is designed to apply counterparty-level and account-level restrictions as operational constraints — not as documented policies that depend on human adherence. Where a restriction is active and configured to block, the workflow is designed to route the instruction through an escalation event rather than proceeding automatically. A settlement that would breach a counterparty credit limit is designed to surface as a case — not a post-hoc discovery. Where position and balance data is available at instruction time, balance validation runs before release; the firm's compliance function configures validation coverage appropriate to its custody model and rail capabilities.

Post-trade operations command center: entity health and visibility without operational interference

Every firm operating across multiple desks, multiple asset classes, and multiple settlement rails needs a cross-domain view: a way to see settlement health, open cases, capital posture, and rail availability, including any SSI drift alerts or participant monitoring flags, without navigating to each module independently.
  • Read-only transparency

    Devancore's Command Center provides this view with an explicit and deliberate constraint: it is read-only. Nothing in Command Center takes action. The principle reflects the "Read-Only Transparency" design for operations leadership: a control tower view that provides situational awareness of entity health, settlement status, and capital posture without creating inadvertent action capability for roles that shouldn't have it. The operations COO who needs to see a participant restriction alert or an SSI mismatch flag should be able to see it without being able to resolve it. Resolution belongs in the module that owns the record.

  • Global Ops view

    The Global Ops view surfaces settlement health across all connected rails simultaneously, DTC, SWIFT-connected CSDs, on-chain networks, alongside open case count, aging exposure, and early warning capital indicators. A single screen answers the end-of-day question: where is the firm, across every rail, right now? Participant monitoring flags, restriction alerts, counterparty exposure thresholds, SSI anomalies, appear in the same view alongside settlement data.

  • Ops Copilot in Command Center

    Ops Copilot, Devancore's explain-only AI assistant, is embedded in Command Center as a read-only analytical layer. A head of operations who needs to understand why a cluster of on-chain positions is showing probabilistic finality at end of day can ask Ops Copilot, and receive a plain-English explanation of chain state, block depth, and expected resolution timeline without navigating block explorers or interpreting raw infrastructure data. Ops Copilot explains; it does not act. Every Ops Copilot session is logged for audit purposes.

  • Custom Views

    Custom Views: saved lens configurations that filter the Command Center view by desk, rail, asset class, or case type: let each team surface the operational picture relevant to their function without requiring custom reporting development. The CCO's view and the Head of Settlement's view are different saved lenses on the same underlying data.

The system of record is where every other platform capability starts. The counterparty directory feeds the trade lifecycle: every trade references a counterparty from the canonical record. The SSI master feeds the settlement desk: every instruction routes from the canonical SSI. The account structure feeds the compliance layer: every restriction and limit enforces against the canonical account record.

For the regulatory grounding