The same settlement desk, whether the security settles on DTC or a blockchain.

FIX trade capture: where every lifecycle event begins

Every trade in Devancore starts as a FIX message or a manual entry that creates the underlying lifecycle event. FIX (Financial Information eXchange) is the industry standard for execution and allocation messaging in securities markets — the protocol through which prime brokers, OMS/EMS platforms, and counterparties transmit execution reports, allocation instructions, and confirmations. For FIX session management and protocol configuration, see the Connectivity page; this section covers FIX as the trade capture entry point.

• FIX 4.4 and OMS/EMS handoff

  FIX 4.4, the dominant version for equity allocation messaging, is the integration path from front-office systems. OMS/EMS platforms — including systems like Aladdin and Charles River, which typically hand off to post-trade via FIX 4.4 — connect at this layer; Devancore meets firms at that handoff without requiring changes to the traders' execution workflow. Devancore also supports FIX drop copy configuration — receiving a copy of execution reports in real time as they flow between execution counterparties, initiating the post-trade lifecycle without requiring a primary FIX session to the order management system.

• First lifecycle event and attribution

  The FIX 4.4 inbound layer receives execution reports and allocation instructions, and creates the first lifecycle event in the unified audit trail: a CREATED event with actor attribution (the FIX gateway as a service actor), source (FIX), FIX message ID, and full payload. This matters for the audit trail — a trade that originated from a FIX execution message carries a different attribution than a trade entered manually through the UI, which carries a different attribution than a trade ingested via the import API. The source is a structural attribute of every lifecycle event, not a note in the record, and it survives every state transition from capture through settlement.

• Manual trade entry

  Manual trade entry — for bilateral trades, block trades, or instruments not covered by an OEMS allocation flow — follows the same lifecycle path with UI as the source. The controls that govern amendments to FIX-originated trades apply equally to manually entered trades. Source never determines the control level; the action type does.

Trade confirmation and matching: pre-settlement affirmation before the instruction moves

A trade moves toward settlement only after both sides of the transaction have affirmed the same economic terms. The trade confirmation and matching layer in Devancore manages pre-settlement affirmation — verifying that counterparty and firm records of the trade agree on quantity, price, settlement date, and settlement method before a settlement instruction is generated and released.

• DTCC ITP/CTM integration

  In the market, "CTM" typically refers to DTCC's ITP/CTM service — DTCC's institutional trade processing and central trade matching infrastructure. Where DTCC ITP/CTM is part of the firm's existing workflow, Devancore integrates at the affirmation layer — ingesting affirmation status from CTM and using it as a condition for settlement instruction release. The matching and confirmation logic described here covers the firm-side lifecycle; Devancore defers to DTCC ITP/CTM where that service governs the counterparty affirmation step.

• Unmatched trades and case management

  Unmatched trades are operationally expensive. A trade that migrates to the settlement desk without a confirmed match creates fail risk — and in a T+1 environment, unresolved "orphaned" trades reaching the settlement rail have narrowing correction windows. Devancore surfaces mismatches as cases in the same case management queue as other settlement exceptions, aged consistently, escalated through the same workflow. Devancore can be configured to require pre-settlement affirmation before the release of settlement instructions for certain instruction types — preventing unaffirmed trades from being instructed without explicit override. Where override is permitted, it flows through a controlled workflow with attributed approval. The operations team does not silently release unaffirmed instructions; the decision and the rationale are lifecycle events.

• On-chain settlement and matching

  For on-chain settlement where terms are expressed in smart contract parameters (atomic settlement, smart-contract DVP), Devancore can verify terms against on-chain contract data and transaction parameters before settlement proceeds. This applies where the contract is the authoritative terms record; for trades that are matched off-chain and settled on-chain (the more common model for institutional tokenized asset settlement), standard pre-settlement affirmation governs, and on-chain delivery is the settlement mechanic, not the matching mechanism.

Settlement desk: rail-agnostic instruction engine across DVP, FOP, RVP, and on-chain delivery

The Settlement Desk is the unified workbench for settlement instruction review, release, monitoring, and exception management across all rails. A settlement instruction in Devancore is generated from the confirmed trade record and the SSI master — the standing settlement instructions that encode how each counterparty settles on each rail. The desk is designed to generate instructions from canonical data sources; where the operations team needs to override a generated instruction, the override flows through a controlled workflow (maker-checker details are covered on the Controls & Compliance page).

• Instruction engine and rail routing

  Devancore's instruction engine selects the settlement path — DTC, SWIFT-connected CSD, on-chain network, or Arc (Devancore's on-chain institutional settlement rail) — based on the counterparty's SSI for the instrument type. The operations team manages the trade; the instruction engine handles the rail routing.

• DVP/RVP, FOP, and CNS

  DVP/RVP (Delivery Versus Payment / Receive Versus Payment) is the standard settlement method for most securities. Devancore generates the DVP or RVP instruction, routes it to DTC, a SWIFT-connected CSD, or on-chain based on SSI, and tracks finality status through the rail-aware model — distinguishing between workflow status and irrevocable transfer. Free of Payment (FOP) — for securities movements without simultaneous cash exchange, such as collateral transfers, reorganization deliveries, internal book entries — follows the same instruction workflow as DVP. The absence of a cash leg does not reduce the control requirement. For NSCC-eligible securities, Devancore ingests CNS obligations from the netting process and tracks the resulting net settlement obligations and DTC book-entry outcomes. The netting itself occurs at NSCC; Devancore tracks what was netted and monitors the DTC settlement leg that produces finality for the resulting obligation.

• On-chain delivery and pending fails

  For tokenized assets settling on Ethereum, Polygon, on-chain networks, or Arc, the settlement instruction routes through the relevant network. On-chain settlement does not carry a standard "expected settlement date" in the T+N sense — finality is determined by network consensus on a rail-specific window, not a calendar date. Devancore's finality model applies the rail-specific expectation: Ethereum mainnet tracks block depth toward a sufficiently confirmed threshold; Polygon applies checkpoint-based finality logic; Arc applies Arc's consensus parameters. A pending fail for an on-chain delivery is defined relative to the rail-specific expected finality window, not an assumed T+N date. A settlement that does not achieve finality within the rail-specific expected window is a pending fail. Devancore surfaces pending fails in the settlement desk view and routes them to case management — with aging tracked from the rail's finality expectation, not from instruction send time. The timestamp anchor is the rail's expected finality window, not when the instruction was transmitted.

Corporate actions processing: entitlement automation across traditional and tokenized assets

Corporate actions are where operational complexity compounds. A cash dividend on a DTC equity, a coupon payment on a fixed-income instrument via Euroclear, a governance vote on a tokenized bond — each is a corporate action event with a lifecycle of its own: announcement, election window, entitlement calculation, and final movement of cash or securities.

• Structured workflow for standard event types

  Devancore's corporate actions module runs a structured workflow for standard event types — dividends, stock splits, rights offerings, tender offers, coupon payments — with manual ingestion capability for events delivered through non-standard channels. Announcements are ingested from DTCC corporate action announcement data, custodian notifications, or on-chain event data where issuer infrastructure provides structured output. Elections run against position records as of the record date. Entitlements are calculated and reviewed before any entitlement posts to the position; the review follows the same controlled approval flow as other operational decisions.

• Tokenized corporate actions

  Tokenized corporate actions represent one of the most operationally underserved areas in hybrid securities operations. For tokenized bond coupon payments distributed on-chain, governance votes with on-chain execution, and token distributions — the same corporate action framework applies where issuer infrastructure provides structured event data. Devancore is designed to treat a tokenized corporate action event with the same processing pipeline as a traditional one: ingestion, election (where applicable), entitlement calculation, review, and posting. For tokenized corporate actions where issuers deliver event data through non-standard or manual channels, the operational team ingests through the same announcement workflow, maintaining the full attribution and governance trail regardless of delivery mechanism.

• Scope note

  Tokenized corporate action processing depends on issuer infrastructure and data standards. Where structured event data is available from the issuer, Devancore applies the full automated pipeline. Where it is not, manual handling is required outside the automated path — this is an issuer infrastructure constraint, not a platform limitation.

Settlement exception management: one queue for every fail, every rail

Stop tab-hopping between your DTC fail queue and your on-chain exception dashboard. An exception in Devancore is a case — a DTC fail, a SWIFT aged instruction, a pending on-chain delivery, a trade mismatch, a corporate action entitlement dispute — and every case surfaces in the same queue, regardless of origin rail. Settlement exception management and trade reconciliation software serve the same operational need: knowing what broke, across every rail, right now.

• Unified case queue

  This is the operational consequence of a unified workflow. When exceptions live in separate queues — one for traditional fails, one for digital asset issues — the operations team allocates attention across two operational pictures. Exceptions that span both rails fall in the gap. The aggregate exposure picture is never current because it requires combining two queues manually. Devancore's case queue applies consistent classification to every exception: case type, risk class, origin rail, days open, escalation path. Aging applies from the rail's expected finality window — not from instruction send time, not from a batch approximation of settlement status. A DTC fail ages from the applicable settlement date; an on-chain pending delivery ages from the rail-specific expected finality window for that network. The compliance team's view of escalated cases is the same queue filtered by escalation status. The FinOps team's capital exposure view draws from the same aging data that drives case severity.

• Ops Copilot in case management

  Ops Copilot, Devancore's explain-only AI assistant, is available in the case management context for specific diagnostic purposes: translating on-chain state into operational terminology when an on-chain exception requires chain-level interpretation. A settlement operations analyst who needs to understand why an Ethereum delivery is aging can ask Ops Copilot — and receive a plain-English explanation in terms the analyst's workflow already uses. Ops Copilot does not resolve cases. It explains what the case data shows.