Asset Manager Post-Trade Operations

Adding tokenized assets to the portfolio shouldn't require adding a second operations team.

One investment book of record (ABOR/IBOR), one position model, and one settlement infrastructure layer: across equities, fixed income, and real-world assets (RWA), without parallel reconciliation stacks.

The case for tokenized assets, tokenized money market funds, tokenized government bonds, on-chain real-world assets, is well understood by portfolio teams. The operational consequence is less discussed: most asset managers who add a tokenized position to an existing portfolio discover that their back office does not have a clean path for it. The trade flows into a separate module. Settlement goes through a separate monitoring workflow. The position reconciles against a separate custodian statement. A new asset class, managed as a second system.

The result is the parallel stack problem, two settlement infrastructures, two position ledgers, two reconciliation workflows, and the operational overhead to maintain the bridge between them.

The 1:1 headcount trap. Traditional systems require additional operational overhead for every new asset class or settlement rail. Devancore is designed to let your existing team manage tokenized RWAs and traditional fixed income within a single, instrument-agnostic workflow: the same enrichment logic, the same case management queue, the same reconciliation process.

Devancore was built around a different assumption: that a single portfolio settling across multiple rails is the operational base case, not an edge case requiring special handling.

One ABOR: eliminate the Excel overlay between your ledger and your digital asset custody statements

The investment book of record is only useful if it is complete. An ABOR that reflects traditional securities positions accurately but requires manual adjustment for tokenized positions is not a single ABOR — it is a traditional ABOR with a spreadsheet reconciliation layer attached.
  • The Excel overlay problem

    This is the Excel overlay problem: the high-risk manual bridge where operations teams typically reconcile traditional ABOR entries with digital asset custody statements, token wallet balances, or on-chain transaction records. It is a recognized operational failure mode: the data discrepancies it produces are invisible until they surface in a break or a client query.

  • Instrument-agnostic position model

    Devancore's position model is instrument-agnostic. An equity position settled via DTC, a fixed-income position settled via SWIFT-connected CSD, and a tokenized real-world asset settled on-chain are all records in the same ABOR/IBOR: same lifecycle events, same aging framework, same finality status tracking. Adding a new instrument type does not require a parallel data model or a separate operational stack. Asset class is a dimension on the instrument record, not a separate system.

  • One reconciliation workflow

    The operational consequence: the team runs one reconciliation workflow across the full portfolio. Exceptions surface in one case management queue, aged by the same logic. The data silo between traditional and digital asset books is eliminated structurally — not bridged manually. This matters now for firms holding tokenized money market funds as cash equivalents: BlackRock BUIDL, Franklin OnChain US Government Money Fund, or equivalent instruments. The transfer agent workflow, the NAV-equivalent computation, and the settlement reconciliation for a tokenized MMF position sit in the same operational framework as the equivalent traditional MMF. No separate "digital assets operations" sub-process.

Custodian reconciliation: finality by rail, one position model, NAV integrity

The custodian reconciliation is where portfolio accuracy is ultimately verified. The break between the manager's ABOR and the custodian's books reveals data that is either genuinely contested or operationally stale: positions the custodian and manager are simply reading differently because they are using different settlement timing assumptions.
  • Finality status at the position level

    Many institutional systems approximate finality using settlement cycle conventions: T+1 means settled for equities, T+2 for bonds. That approximation fails for on-chain positions, which may settle faster or slower depending on rail conditions, and for cross-border positions where the CSD's confirmation arrives asynchronously from the settlement date. Devancore tracks finality status at the position level, deterministic, conditional, or probabilistic, by instrument and rail. An operations team reviewing the end-of-day reconciliation sees which positions have achieved irrevocable finality, which are conditional pending CSD confirmation, and which on-chain positions are still accumulating confirmations. Finality context helps interpret breaks because knowing where a settlement stands on the finality spectrum clarifies whether a break is a genuine discrepancy or a timing artifact; custodians supply position and cash statements, not finality status. Operational integrity is a byproduct of data precision: by computing finality directly from the infrastructure layer, Devancore eliminates the settlement assumptions that lead to reconciliation breaks between ops systems and custodian statements.

  • NAV integrity

    For fund administrators, the NAV is struck against the position data available at valuation time. An NAV struck against a position ledger that approximates on-chain 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 asynchronous on-chain confirmations that arrived after the close. Devancore's finality-aware position model provides a more accurate input for NAV computation, reducing the re-run exposure for hybrid funds that include on-chain settled positions. Whether Devancore integrates with or supplements an existing fund accounting system is a configuration decision: see the Golden Source section for the integration framing.

  • Shadow NAV

    For firms running shadow NAV, an independent valuation of the same portfolio to verify the administrator's computation, the same finality-aware position data provides the basis for the shadow calculation. No separate digital asset position feed required.

Corporate actions: entitlement automation across traditional and tokenized instruments

Corporate actions are a persistent source of operational overhead. And the complexity compounds when the portfolio includes both traditional and tokenized instruments. The workflow for a traditional dividend on an equity is mature and largely automated. The equivalent workflow for a tokenized bond coupon payment, an on-chain governance vote, or a token airdrop is less standardized across issuers.
  • Unified lifecycle workflow

    Devancore's corporate actions module, Announcements, Elections, and Entitlements, supports both traditional and tokenized event types through a unified lifecycle workflow. Where issuer infrastructure provides structured event data, the same processing pipeline applies: announcement ingestion, election management against client deadlines, and entitlement calculation feeding cash or asset movements.

  • Tokenized events and maker-checker

    Tokenized events that may arise in practice include coupon payments on tokenized bonds (when distributed on-chain), governance votes on tokenized real-world assets, and network-level events (forks or protocol changes affecting token balances). Devancore routes these through the same maker-checker workflow as a standard stock split: the event requires a second authorized actor to confirm the entitlement before it posts. The consistency matters for the evidence trail: every entitlement decision is an attributed, immutable record.

  • Scope note

    Tokenized corporate action processing depends on the issuer's infrastructure and data standards. Devancore applies a consistent operational framework to events where structured data is available; issuers or instruments that distribute off-chain or through non-standard channels require operational handling outside the automated workflow. This is an issuer infrastructure constraint, not a platform limitation.

The Golden Source layer: OEMS integration, fund NAV computation, and downstream delivery

Asset managers rarely operate from a clean-slate technology stack. BlackRock Aladdin, Charles River, or equivalent OEMS platforms handle the upstream execution and allocation workflow. Custodian platforms handle safekeeping and statement production. Risk and reporting systems handle downstream consumption. Devancore's integration model is designed for coexistence within that stack — not replacement.
  • OEMS integration

    Devancore ingests execution and allocation data from existing OEMS platforms via FIX 4.4, the industry standard for execution and allocation messaging. Trades flow in from the current front-office stack; Devancore enriches, matches, and routes them through the full post-trade lifecycle. The existing OEMS does not need to be replaced. The existing counterparty connectivity does not need to be rebuilt.

  • The Golden Source sub-ledger

    Devancore operates as the reconciled position layer, the single source of post-trade truth, between the execution system upstream and the reporting and risk systems downstream. Reconciled position data, finality status, and case resolution data surface via REST API to downstream risk, reporting, and finance systems. The operations team reconciles once, to one source, and distributes to as many downstream consumers as needed.

  • Fund NAV computation and reporting

    The FinOps layer, NAV and Accounting, Valuation, Accruals, draws from the same unified position model as the Operations layer. Valuations for tokenized assets (tokenized Treasuries, on-chain real-world assets) apply the same source hierarchy logic as valuations for traditional securities. Accruals align to accounting periods. The position data reflects current settlements across both traditional and digital rails, with no separate reconciliation between digital and traditional ledgers before the NAV is struck.

  • Counterparty directory as canonical entity record

    Every firm, fund, counterparty, custodian, and on-chain participant that appears in the workflow is a single record in the counterparty directory. The prime broker appearing as three different entities in the legacy system is a recognized operational failure mode. Devancore prevents it structurally: one canonical record, multiple role assignments, consistent across every workflow that references it.

The asset manager use case is the portfolio construction and operational efficiency surface. The finality model and controls infrastructure that make it work are the same as the other two use cases — entered from a different operational pain.