Three connectivity paradigms. One event attribution model.

FIX session management: the inbound trade capture standard

FIX (Financial Information eXchange) is the industry-standard protocol for trade execution and allocation data in securities markets. The operational consequence of FIX capture, trade enrichment, matching, and settlement instruction generation, is covered in the Trade Lifecycle page. This section covers FIX session configuration, monitoring, and event attribution: the infrastructure layer that receives execution data and hands it to the operations workflow.

• FIX 4.4 and FIX 5.0

  FIX 4.4 is the dominant version for equity allocation messaging between prime brokers, asset managers, and their counterparties. FIX 5.0 supports additional message types relevant to derivatives and fixed income workflows. Devancore operates as a high-availability FIX acceptor on both versions: receiving execution and allocation messages from prime brokers, OMS/EMS platforms, and external counterparties as the primary inbound trade capture path, designed to eliminate the allocation lag common in batch-based systems where execution reports queue before positions update.

• Session management and event attribution

  FIX session management in Devancore's System Settings layer covers session configuration (CompID pairs, target systems, session state), message log management, and inbound routing rules. A FIX execution report creates an EXECUTION_CREATED event; a FIX allocation instruction creates a TRADE_ALLOCATED event. The FIX message ID is preserved in the lifecycle event as a structural attribute: the connection between the FIX message and the Devancore event is explicit, not inferential.

• Multi-counterparty sessions

  For firms integrating with multiple prime brokers or counterparties, Devancore maintains separate FIX session configurations per counterparty: with independent session monitoring and individual failover behavior. A session failure with one prime broker is surfaced as a rail availability issue on the Rail Health dashboard; it does not affect message processing for other configured sessions.

SWIFT gateway broker dealer: settlement messaging for traditional rails

SWIFT is the messaging infrastructure through which most cross-border securities settlement instructions travel. An MT54x message (MT540 (Receive Free), MT541 (Receive Against Payment), MT542 (Deliver Free), MT543 (Deliver Against Payment)) is the standard format for settlement instructions routed from broker-dealer to custodian or CSD. SWIFT does not hold securities or process settlement; it transmits the instructions that CSDs and custodians act upon.

• Messaging vs. settlement: ACK is not finality

  This distinction, messaging vs. settlement, carries an operational precision implication. An MT54x ACK is a delivery confirmation, not a settlement fact. A SWIFT acknowledgment means the instruction reached the custodian's messaging infrastructure. It does not mean the CSD has processed it or that book-entry transfer has occurred. Devancore maintains CONDITIONAL finality status until the CSD provides actual book-entry confirmation: preventing the accidental deployment of capital against unconfirmed settlement inventory. The firm's trial balance and reserve formula computation draw from the finality-accurate position record, not from SWIFT acknowledgment timing.

• SWIFT gateway configuration

  SWIFT gateway configuration in System Settings covers BIC assignments, message format versions, network routing, and inbound message processing rules. Changes to SWIFT gateway configuration are subject to the same maker-checker controls as any other system action: the modification is a lifecycle event in the WORM audit trail.

• ISO 20022 securities settlement: sese message families

  The securities industry's migration from ISO 15022 (MT-based) to ISO 20022 message formats is reshaping how settlement instructions are structured and transmitted. For securities settlement, ISO 20022 uses the sese message family, including sese.023 and related instruction types, which support richer data structures and greater semantic precision than legacy MT formats. Many institutions support both ISO 15022 and ISO 20022 for securities workflows during the coexistence period; Devancore's SWIFT gateway layer is designed to accommodate both MT and MX formats during this transition.

Digital asset network connectivity: Ethereum, Polygon, Arc Network, and the finality model

Connecting to a blockchain network for settlement purposes is categorically different from connecting via FIX or SWIFT. On-chain settlement requires a cryptographic signing model, a transaction broadcast mechanism, a block confirmation monitoring system, and a finality assessment model that translates network-level data into operational status.

• Node connectivity and transaction broadcast

  Devancore's digital asset network connectivity layer handles connection to network RPC endpoints for transaction submission and state querying. Devancore monitors node health and surfaces degradation on the Rail Health dashboard. Alongside standard availability status, Rail Health surfaces network fee estimates and congestion indicators for on-chain networks: giving the settlement desk visibility into the cost environment before committing instructions to the rail.

• Finality monitoring by network

  For each configured network, the finality model applies network-specific parameters. Ethereum L1: probabilistic → DETERMINISTIC at the configured block depth threshold. Polygon PoS: checkpoint-based finality model (network-dependent). Arc: Arc's consensus parameters, not Ethereum L1 block depth logic. The settlement desk sees finality status: PROBABILISTIC, CONDITIONAL, or DETERMINISTIC — not raw block counts. The same operational vocabulary as DTC and SWIFT finality status.

• Wallet and signing boundary

  Devancore operates as the pre-execution governance layer upstream of the custody layer. The on-chain settlement instruction is constructed and approved within Devancore's maker-checker workflow before it is passed to the custody signing layer. Arc Network (Circle's institutional settlement infrastructure) is configured within the same Digital Asset Networks interface as Ethereum and Polygon. Arc's finality model applies Arc-specific consensus parameters.

Rail Health: settlement rail monitoring before instructions route

Settlement fails often begin not with a counterparty dispute or position mismatch, but with a connectivity degradation that the operations team discovers after an instruction fails to deliver. A SWIFT gateway that degraded during the business day. An Ethereum node that lost connectivity during block accumulation. Elevated gas fees that stalled an on-chain delivery without surfacing in the settlement desk view.

• Pre-flight visibility

  Pre-flight visibility changes this model. Devancore's Rail Health dashboard surfaces availability, latency, network fee estimates, and known constraints for every configured rail, DTC, SWIFT connections, Ethereum L1, Polygon, Arc, and any additional configured network, in a single operational view before instructions are routed. The operations desk sees rail status before routing, not after a failed delivery surfaces the issue.

• Rail Health events and case management

  Rail Health events, a connectivity degradation, a network incident, elevated gas fees on Ethereum, a known CSD constraint, create operational cases in the case management queue with the standard attribution: which rail, when the degradation was detected, current status, and resolution timeline where available. When an infrastructure event requires settlement desk action, holding instructions pending rail recovery, routing to an alternative settlement method, the decision and rationale are recorded as lifecycle events.

• Post-trade API integration

  For downstream systems, risk platforms, reporting systems, fund accounting, Devancore delivers position data, finality status, and case resolution data via REST API. The API endpoint configuration, rate limits, and authentication are managed in System Settings alongside FIX and SWIFT gateway configuration. Downstream systems do not require separate data feeds for traditional and digital asset positions; the same REST endpoint delivers the unified position model. For firms building internal tooling or integrating Devancore data into existing data infrastructure, the API connectivity layer is the downstream handoff point: position data, finality status, and event attribution all queryable by the same schema.

Hybrid settlement infrastructure: one connectivity layer for every rail

The operations team that adds a digital asset rail to an existing post-trade environment typically adds it through the path of least resistance: a separate monitoring tool for the blockchain connection, a separate workflow for on-chain instructions, a separate export for the digital asset position data that gets merged with the traditional data before reporting.

• The patchwork problem

  The result is what Devancore was designed to prevent: a patchwork connectivity model where each rail has its own health monitoring, its own attribution format, and its own operational consequence when it fails. The on-chain connectivity failure is invisible to the traditional operations dashboard until it surfaces in a missed settlement. The SWIFT degradation is invisible to the digital asset monitoring tool.

• One connectivity picture

  Devancore's connectivity layer was built with the assumption that a firm settling across multiple rails, traditional and digital, needs one connectivity picture. By abstracting the transport layer, Devancore ensures that the internal sub-ledger and operational record remain consistent regardless of whether the message traveled via a legacy financial network or a decentralized ledger. The FIX session state, the SWIFT gateway status, and the Ethereum node health appear in the same Rail Health dashboard. The FIX message acknowledgment, the SWIFT network confirmation, and the on-chain block confirmation carry the same five-attribute event attribution in the same audit trail. Connectivity is a system property, not a patchwork. Adding a new rail adds a new configuration. It does not add a new operational picture.