Your capital computation now spans two settlement rails. Your system only knows one.

Net capital computation across traditional and digital rails: eliminate the reconciliation gap

The FinOp's operational nightmare is the Saturday morning discovery: a digital asset fail that should have triggered a capital deduction on Friday, sourced from a system that wasn't tracking it in the first place. The gap between what the capital computation sees and what the firm's positions actually include is a systems problem, not a data problem.

• Unified position model for net capital

  Devancore's FinOps hub runs the net capital calculation, haircuts, deductions, and early warning thresholds, from a unified position model that encompasses both traditional and digital rails simultaneously. A DTC equity position and an on-chain tokenized bond position sit in the same computation, not in two separate ledgers that must be manually reconciled before the FOCUS report runs.

• Digital asset capital treatment

  For digital asset positions specifically, the applicable capital treatment depends on how each asset is classified under current SEC guidance: many digital assets currently attract a 100% haircut as non-allowable assets. For payment stablecoin positions, SEC Trading and Markets staff has indicated it would not object if a broker-dealer applies a 2% haircut for purposes of Rule 15c3-1, subject to the conditions described in the staff FAQ. Devancore's haircut table is designed to model this treatment alongside traditional schedules. Firms should confirm the applicable conditions with legal counsel before applying the 2% treatment.

• Early warning monitor

  The early warning monitor, Rule 17a-11's notification threshold at 120% of required minimum net capital, runs against the full position picture derived from the unified model. The FinOps team does not maintain two capital computations. The marginal position that triggers a capital breach is the one your system didn't count; that is why a unified picture matters regardless of current book mix.

Customer reserve formula (15c3-3): accurate aging starts at finality, not instruction

Legacy systems treat "Sent" as "Settled." In a T+1 world, that optimism is a regulatory liability.

• Why aging accuracy matters

  The 15c3-3 customer reserve formula is only as accurate as the in-transit aging data supporting it. A firm's possession or control determination depends on more than whether an instruction was transmitted: it depends on whether control over the security has actually been demonstrated. A system that records "settled" at instruction send is producing input data that understates the firm's actual in-transit exposure. Understating that exposure is not just a technology lag. A reserve formula shortfall based on overstated settlement is a customer protection deficiency. The regulatory consequence, not the reputational one, is the operative risk.

• Hybrid firms and rail-aware finality

  The compounding problem for hybrid firms: DTC settlement achieves finality near real-time upon DVP completion, while on-chain settlement is probabilistic during block accumulation. A system that conflates these two finality models produces reserve formula inputs that are systematically optimistic on the digital rail. Devancore's rail-aware finality model, built into the Operations layer, distinguishes between workflow status (where is the instruction?) and finality status (has the transfer become irrevocable?). Finality status provides a more accurate operational input supporting the possession and control determination than instruction confirmation alone. This is not equivalent to the full 15c3-3 possession or control analysis, which requires compliance judgment on control location and applicable exemptions; it produces meaningfully better input data for that determination.

• Daily computation and unified model

  For firms subject to daily reserve formula computation requirements (the SEC's December 2024 amendments apply to qualifying carrying broker-dealers; compliance date December 31, 2025), the data must be current at the time of each computation. A unified position model that reflects finality status across both rails supports that requirement without a manual bridging step. The reserve computation in the FinOps hub draws from the same position model that drives settlement monitoring in the Operations hub. No separate reconciliation step between them.

FINRA supervision technology: WSP evidence, principal sign-offs, and WORM audit trail

A FINRA examination of supervisory controls has two questions at its core: what are your written supervisory procedures, and show me that you followed them. Legacy systems answer the second question poorly: the audit trail was built as a reporting function rather than as the operational record.

• Compliance hub and WSP mapping

  Devancore's Compliance hub is the Series 14/24 supervisory layer of the system: designed to support the functions of designated principals, not to replace them. WSP coverage is mapped to system controls, so the firm can trace from the written procedure to the operational evidence of its execution. Principal sign-offs (Series 24) on exceptions and escalations are time-stamped, attributed events in the WORM audit vault. An escalation from Operations to Compliance is a formal, recorded workflow.

• Maker-checker and WORM vault

  The maker-checker workflow in the Operations hub produces supervisory evidence as a byproduct of normal operations: every material action requires a second authorized actor, and both the maker submission and checker approval are immutable lifecycle events with actor ID, timestamp, IP, device, and the full record state at the time of action. When on-chain events are involved, a stablecoin settlement instruction, a tokenized asset delivery, those events are ingested into the same WORM audit vault with the same attribution model as traditional settlement events. There is no separate digital asset log that sits outside the examination scope.

• Ops Copilot, Devancore's explain-only AI assistant

  Ops Copilot is designed for exam preparation, not for autonomous action. It creates "Discovery-Ready" narratives from complex event sequences: translating a chain of automated system events, finality state transitions, and maker-checker decisions into plain-English summaries appropriate for a Response to Inquiry (RTI) package. An operations team that would otherwise spend days manually pulling logs and writing narrative context for a FINRA request can use Ops Copilot to produce the first draft of that narrative from the event record itself. Ops Copilot does not make decisions, issue recommendations, or trigger actions. It explains. Every prompt and reasoning path is logged as part of the system's operational recordkeeping design and the complete operational trail; the log is not a regulatory record under Rule 17a-4.

One case management workflow for broker-dealer settlement operations

A settlement fail, a break, an aged in-transit position: these cases have the same regulatory consequence regardless of whether they originated on DTC, SWIFT, or an on-chain rail.

• Unified case framework

  The possession or control consequences, the reserve formula impact, and the capital exposure after the applicable regulatory aging period all apply to the position, not to the infrastructure it settled on. Devancore's Case Management layer treats traditional and digital-rail cases in the same operational framework: case type, risk classification, blocking rail attribution, escalation path, and immutable resolution history. The operations team sees one queue. The compliance team sees one escalation log. The FinOps team sees aging exposure in the capital computation regardless of rail.

• Command Center

  The Command Center, a read-only, cross-domain situational awareness layer, gives operations leadership the settlement health, open case count, capital posture, and rail availability view without creating a control surface they shouldn't have. Nothing in Command Center takes action. The principle is explicit: visibility without control bleed.