Net Capital, Trial Balance & Regulatory Reporting

Your FOCUS report and your settlement ledger start from the same source. Not because someone reconciled them.

Rule 15c3-1 net capital, 15c3-3 customer reserve formula, fund NAV computation, and FOCUS regulatory reporting: all drawing from the same unified position model as the settlement desk. Maintain trial balance integrity across traditional and digital positions without a pre-report reconciliation step.

The regulatory reporting problem for a hybrid firm is not a calculation problem. The haircut logic for Rule 15c3-1, the in-transit aging framework for Rule 15c3-3, the fund NAV computation methodology: these are understood. The problem is the data problem that precedes every calculation: assembling a complete, current, cross-rail position picture before any calculation can begin.

Most FinOps teams at hybrid firms run a reconciliation step before every FOCUS report. Not because reconciliation is required by the rule, but because the firm's traditional position ledger and its digital asset ledger are maintained separately, and the FOCUS report requires a number that reflects both. Someone on the team reconciles the two before the computation runs. On a routine Friday, this is overhead. On a Friday following a market disruption, it is the operational bottleneck between the firm and its regulatory filing.

Inaccurate in-transit data compounds the problem further: a system that can't prove finality on the digital rail produces optimistic settlement inventory, leading to liquidity over-provisioning: locking up firm capital in reserve accounts against positions that have actually settled. The reconciliation problem and the finality problem reinforce each other. Devancore addresses both at the source: one position model, finality-aware, covering every rail.

Net capital rule 15c3-1: haircut computation across traditional and digital positions

The net capital computation under Rule 15c3-1 begins with a complete inventory of the firm's proprietary positions, applies the appropriate haircut schedule to each, deducts the resulting haircut amounts from net worth, and produces a net capital figure that must satisfy the firm's applicable minimum. For a firm operating across traditional and digital rails, the completeness of that position inventory is the operative question. And the accuracy of the haircut applied to each position type is the regulatory precision question.

  • Unified position model for net capital

    Devancore's net capital computation runs from the unified position model: a position view that includes DTC-settled equities, SWIFT-connected fixed income, and on-chain digital assets in the same computation without a pre-computation reconciliation step. A digital asset position is not entered separately into the capital computation by a parallel workflow. It is already in the position model, with the appropriate asset classification and the applicable haircut applied.

  • Haircut by position type: current regulatory landscape

    Most digital assets currently attract a 100% haircut as non-allowable assets under current SEC guidance: a treatment that effectively excludes them from net capital credit. This is the default treatment for unapproved digital assets today. For payment stablecoins, the treatment is evolving. SEC Trading & Markets staff has indicated it would not object if a broker-dealer applies a 2% haircut to proprietary positions in a payment stablecoin 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, by instrument classification, so capital calculations remain consistent as guidance evolves. Firms should confirm the specific conditions described in the SEC staff FAQ with legal counsel before applying the 2% treatment.

  • Haircut configuration and early warning

    Devancore's haircut configuration applies the correct treatment to each position type as classified: standard SEC schedule for traditional securities, 100% non-allowable for unapproved digital assets, 2% per SEC staff FAQ for qualifying payment stablecoins (where conditions are met and confirmed). The result is a net capital computation that reflects current regulatory practice across all position types — not a blunt-force treatment of all digital assets as identical. The early warning monitor, Rule 17a-11's notification threshold at 120% of required minimum net capital, runs against the full position picture from the unified model. The FinOps team does not maintain two capital computations and then aggregate. One computation, one early warning monitor, one source.

Customer reserve formula (15c3-3): in-transit aging that starts when finality isn't demonstrated

The customer reserve formula depends critically on accurate in-transit inventory. Finality status — not instruction-send timing — is the operational input that supports a correct possession and control determination.

  • Reserve formula and in-transit inventory

    The customer reserve formula under Rule 15c3-3 determines how much cash the firm must hold in a special reserve account for the protection of customers. The formula depends critically on the accuracy of the firm's in-transit securities inventory: positions that have been sold but not yet delivered, or purchased but not yet received. Under the SEC's December 2024 amendments (now in effect; compliance date December 31, 2025 for qualifying firms), certain carrying broker-dealers, including those above the $500M average total credits threshold, are required to compute the reserve more frequently, up to daily. For firms subject to daily computation, the quality of the in-transit inventory at each computation point is not a weekly approximation problem; it is a daily operational discipline that requires a finality-accurate position model, not one that settles on instruction-send timing.

  • Optimistic in-transit data and reserve understatement

    A system that marks a position as settled upon instruction send produces optimistic in-transit data. A position marked as settled at instruction send is not available to the reserve formula as an in-transit item, which means the reserve requirement is understated. Understating the reserve requirement is not a technology lag; it is a customer protection deficiency. For a firm subject to daily computation, that deficiency is computable daily.

  • Finality-aware position model for hybrid firms

    Devancore's finality-aware position model tracks the distinction between workflow status (where is the instruction?) and finality status (has the transfer become irrevocable?). A settlement instruction that has been sent but not yet demonstrated finality on the rail is available to the reserve formula computation as an in-transit item: providing a more accurate input to the possession and control determination than instruction confirmation alone. For hybrid firms, this distinction compounds on the digital rail: an on-chain settlement that has been broadcast but not yet confirmed to the configured block depth threshold is probabilistic, not final. Treating it as final for reserve formula purposes overstates the settlement inventory and understates the in-transit exposure. Devancore's finality status flags this correctly. The on-chain position remains in-transit until finality is demonstrated, and the reserve formula computation draws from the finality-accurate position record.

  • Scope

    Finality status is an operational input that supports, but does not replace, the legal possession and control determination under Rule 15c3-3. The firm's compliance function applies finality data as one input into the full possession or control analysis, which involves custodian location, account type, and applicable exemptions. Devancore provides the operational data; the compliance determination remains with the firm.

General ledger and trial balance: securities accounting from the unified position model

The general ledger, chart of accounts, journal entries, trial balance, is the accounting representation of the firm's operational activity. For a securities firm, the general ledger entries are driven by trade settlements, corporate action distributions, fee accruals, and mark-to-market valuations. In most firms, these entries are produced by a separate accounting system that receives position data from the operations system and creates journal entries from it.

  • Dual-entry sub-ledger and lifecycle events

    Devancore's general ledger is the accounting layer of the same unified system: designed as a dual-entry sub-ledger where each lifecycle event generates the corresponding accounting entries. A DVP settlement that posts to the position model simultaneously generates the debit and credit entries in the general ledger. A corporate action entitlement that posts as a position event generates the corresponding income accrual. The trial balance reflects current operational position data — not yesterday's batch with a manual adjustment for today's digital asset activity.

  • Accounting by product, not by system

    This is "accounting by product" rather than "accounting by system": the accounting record travels with the operational event, not with a separate data feed that requires reconciliation. A firm that maintains a separate digital asset accounting system runs a reconciliation between its traditional ledger and its digital asset ledger before every trial balance close. Devancore eliminates this step structurally, not by automating the reconciliation, but by maintaining a single ledger that doesn't have a cross-system gap to bridge. Trial balance integrity is a byproduct of one-ledger architecture, not a reconciliation task.

  • Chart of accounts and accruals

    The chart of accounts is configurable to the firm's accounting structure. Accruals, interest accruals on fixed-income positions, management fee accruals for fund administrators, align to accounting periods and are generated from the position model on the configured accrual schedule. Mark-to-market valuations for fund NAV computation draw from the same position data, applying the source hierarchy logic configured for each instrument type.

Fund NAV computation: one position model, no pre-strike reconciliation

Scope note: The business case for a unified ABOR/IBOR and the operational argument for the Asset Manager is covered in the Asset Manager use case page. This section covers the computation mechanics. Shadow NAV reconciliation is where the finality problem compounds: for funds running an independent shadow NAV to verify the administrator's computation, both the primary and shadow calculations require a finality-accurate position foundation. A shadow NAV built on the same optimistic settlement-date assumptions as the primary NAV does not provide independent verification; it provides correlated approximation.

  • Finality-accurate NAV at valuation time

    For fund administrators and asset managers striking a fund NAV, the quality of the computation depends on the accuracy of the position data at valuation time. An NAV struck against a position ledger that approximates on-chain settlement finality by settlement date rather than computing it from the chain is an NAV struck against optimistic assumptions. This is the source of NAV re-runs: post-strike corrections driven by on-chain confirmations that arrived after the close. Devancore's NAV and Accounting layer draws from the same finality-aware position model as the settlement desk. At valuation time, the position record reflects current finality status for every holding: DTC equities are DETERMINISTIC upon DVP completion, on-chain positions show their current confirmation state, cross-border bonds via SWIFT show CONDITIONAL status awaiting CSD confirmation. The NAV computation draws from this picture, not from a settlement-date approximation.

  • Integration with fund accounting and shadow NAV

    Devancore provides the finality-aware position and event data used by fund accounting and administrator workflows: integrating into existing strike processes rather than replacing them. Per-share NAV computation runs from the position model's aggregate portfolio value, net of accruals, divided by shares outstanding. The same finality-aware data is available as the shadow calculation basis; no separate digital asset position feed is required.

  • Tokenized money market funds

    For asset managers holding tokenized money market funds as cash equivalents, products equivalent in function to traditional MMFs but settled on-chain, the settlement reconciliation for the tokenized MMF position sits in the same operational framework as the equivalent traditional MMF. The position model does not treat a tokenized MMF differently from a traditional one by default; the instrument classification and valuation source hierarchy are configuration decisions.

Regulatory reporting: FOCUS II/IIA and customer reserve: FOCUS-ready outputs from the unified model

The FOCUS Report (Financial and Operational Combined Uniform Single Report) is the primary regulatory financial report for registered broker-dealers, filed with FINRA and the SEC. For a carrying broker-dealer, the FOCUS II or FOCUS IIA report covers net capital (Part II of FOCUS II), customer reserve (15c3-3 computation), and financial condition. Devancore's regulatory reporting layer produces FOCUS-ready outputs for the FinOp's regulatory reporting workflow: the same net capital and reserve formula computations that run from the unified position model, formatted and organized for FOCUS preparation.

  • The Reproducible FOCUS Report

    Every number in a FOCUS-ready output from Devancore is traceable back to the specific lifecycle events and finality timestamps in the WORM audit vault. Net capital line items trace to haircut computations, which trace to position records, which trace to lifecycle events with timestamps and actor attribution. The FOCUS preparation process is not a black-box calculation. It is a click-through audit trail from regulatory output to source event. For a FINRA examination that queries a specific FOCUS line item, the underlying data is in the WORM vault, queryable, attributed, and immutable. The FOCUS-ready outputs do not require a pre-report reconciliation step. The net capital number reflects the same position model as the settlement desk's end-of-day view. The reserve formula computation reflects the same finality-aware in-transit data. The FinOps team does not assemble data from multiple systems and reconcile before running the report.

  • SSOI and tokenized RWA reporting

    For firms subject to SSOI (Statement of Securities Operations) reporting, Devancore's operational data layer provides settlement activity summary, fail data, and aging information that supports SSOI preparation. For broker-dealers with tokenized real-world asset (RWA) positions or payment stablecoin settlement assets, FOCUS reporting requires accurate capital treatment classification by position type. Devancore's haircut table applies classification to each position type: traditional securities under the standard SEC schedule, unapproved digital assets at the applicable haircut, and qualifying payment stablecoins per SEC staff FAQ guidance (conditions apply). These classifications appear in the FOCUS net capital computation directly, without manual category assignment per position.