The dual-rail environment is an operating state, not a transition story

Traditional settlement infrastructure remains the institutional base. Digital settlement rails are being added around it. The operating system above them has to understand both.

• Traditional rails remain the system of market record

  DTC, NSCC, SWIFT, ISO 20022 messaging, custodians, correspondent banks, and central bank cash rails are not being displaced on any useful planning horizon. They carry the legal, operational, and supervisory structure that institutional securities activity still depends on.

• Digital rails are becoming operational inputs

  Tokenized funds, tokenized bonds, stablecoin payment legs, wallet instructions, and blockchain finality events create real post-trade records. Even when the underlying security or cash leg still depends on traditional infrastructure, the digital wrapper introduces new settlement evidence, timing, and reconciliation states.

• The firm's book does not split by technology

  A broker-dealer or asset manager does not compute exposure, supervise operations, resolve breaks, or produce books and records separately because one event came from a CSD and another came from a blockchain. The operating book needs a single answer.

• The rail should be metadata, not architecture

  The core architectural mistake is making the settlement rail decide which system owns the record. In a hybrid model, the rail is stored on the settlement event. The event still belongs to the same trade, account, position, cash, control, and evidence model.

The bolt-on model creates a control problem before it creates a technology problem

A separate digital asset stack looks conservative because it avoids disturbing the legacy system. In production, it creates two records where the firm needs one.

• Position drift

  Two ledgers require a bridge. A bridge requires a reconciliation schedule. A schedule means the official view is stale between runs. Under compressed settlement windows, that delay matters because position, cash, exposure, and break status can change before the primary book sees the event.

• Finality mismatch

  Traditional settlement confirmations and blockchain confirmations do not mean the same thing. A bolt-on stack often reduces both to a generic settled status, losing the rail, finality source, confirmation depth, and evidence needed to explain the event later.

• Control leakage

  A settlement instruction, SSI change, wallet address change, exception close, or report export should pass through the same control framework. If the digital workflow lives outside the primary control stack, maker-checker, segregation of duties, and audit evidence become uneven by design.

• Capital and reporting latency

  Net capital inputs, reserve formula inputs, books and records, finance close, and management reporting depend on the current book. If a digital rail event is visible only after reconciliation, the firm is computing from a delayed operating picture.

• Examination assembly risk

  A regulator, auditor, or counterparty reviewer does not care that an event crossed system boundaries. They ask for the record. If the record lives in two systems plus a reconciliation file, the firm has to assemble the evidence instead of producing it.

The real demand is not abstract blockchain adoption. It is settlement operations, records, and controls.

The strongest operating questions are concrete: SSI, ISO 20022, DTC settlement, trade breaks, books and records, net capital inputs, and finality evidence.

• Settlement instructions become multi-rail data

  Standing settlement instructions used to mean bank, custodian, account, market, and CSD details. Hybrid settlement adds wallet addresses, token contract identifiers, chain IDs, finality policies, and address-screening evidence. The SSI master has to handle both without creating a second control process.

• ISO 20022 and blockchain events both need normalization

  A camt, sese, or settlement-status message and an on-chain transaction are different source records. The operating system still needs to normalize each into trade, settlement instruction, cash, position, exception, and evidence records that downstream teams can use.

• Trade breaks become timing and evidence problems

  A failed settlement, unmatched instruction, DK notice, SSI mismatch, cash break, or wallet-finality exception is not just an operations ticket. It affects position quality, customer reporting, finance inputs, and supervisory evidence.

• Broker-dealer workflows make the architecture visible

  A broker-dealer's books and records, customer protection inputs, net capital workflow, supervision evidence, and report exports all depend on the completeness of the operating record. Hybrid activity cannot sit outside that record and still be treated as controlled.

Native hybrid architecture starts with shared primitives, not rail-specific systems

Devancore's operating model is built around stable post-trade primitives: legal entity, market venue, intermediary, settlement layer, account, instrument, trade, settlement instruction, position, cash, control, and evidence.

• One event log

  Every instruction, approval, settlement update, break, reconciliation action, and report export should create an attributed event. The event log should cover traditional and digital activity without requiring a second evidence system.

• One finality model

  Finality should record the rail, source, confirmation type, timestamp, evidence reference, and operational state. DTC finality, custodian confirmation, bank cash settlement, and blockchain confirmation can be different without becoming separate operating models.

• One position and cash model

  A position is an operating fact attached to an account, instrument, book, and settlement state. The rail may explain how it got there. It should not decide whether the position appears in the main book.

• One control framework

  Maker-checker, role-based access, segregation of duties, exception queues, audit evidence, and supervisory workflows should apply to settlement release, SSI change, wallet address change, break close, and report export.

• One connectivity layer

  FIX, SWIFT, ISO 20022, files, APIs, custodian messages, and blockchain events should feed a common operating model. Connectivity is not the system of record. It is the ingestion and dispatch layer around it.

The firms that win the next phase will not have the most rails. They will have the cleanest record.

The investment case is not more connectivity for its own sake. It is reducing reconciliation debt before dual-rail activity becomes normal volume.

• T+1 reduced tolerance for delayed reconciliation

  Compressed settlement windows expose architectures that rely on overnight cleanup. A hybrid operating model needs current position, cash, settlement, and exception states while the business day is still moving.

• Digital settlement extends the clock

  Traditional markets have business-day operating windows. Digital rails can produce settlement events, wallet movements, and finality updates outside those windows. Operations, controls, and evidence need to reflect that reality without creating a separate night-and-weekend book.

• Audit evidence compounds

  Each month on a split architecture creates more history that has to be reconciled, explained, and migrated later. The cost is not only technical. It is evidentiary: which record was authoritative when the event happened?

• The product answer should stay narrow

  Devancore should not claim to replace execution venues, custodians, clearing agencies, WSPs, legal advice, or regulatory supervision. The claim is stronger when it is narrower: one post-trade operating record, workflow, control layer, and evidence base across rails.

Read more