Accounting for tokenised assets
September 2026
Reese Lucas, product director at FundGuard, explores how tokenisation is redefining investment accounting, the lack of native platform support for digital assets, and why firms need to build for adaptability to keep pace with regulatory changes
Image: FundGuard
Tokenised funds, tokenised bonds, tokenised real estate, and digital-native instruments are showing up today in real portfolios, and most investment accounting platforms still have nothing native to handle them. The result is the same pattern firms have lived through before with private credit and private equity: a new asset class arrives, the core system can not accommodate it, and operations is forced to build a workaround that may one day falter.
Tokenised assets can introduce faster settlement, extended trading availability, and programmable distributions, depending on the instrument and market structure. Yet, none of these properties maps cleanly onto accounting infrastructure built in the early 2000s around overnight batches and standard market hours.
What tokenisation means for investment accounting
Tokenisation is the process of representing a financial asset, whether traditional or digitally-native, as a token on a distributed ledger. For investment accounting, this changes the mechanics of three core processes at once: how positions are tracked, how settlement is recorded, and how lifecycle events — including distributions, corporate actions, and redemptions — are processed.
The accounting events specific to tokenised assets include:
- Onchain settlement that finalises in minutes or seconds as opposed to T+1 or T+2
- Continuous trading and pricing across global markets, with no overnight pause
- Programmable distributions executed by smart contracts rather than scheduled by a custodian
- Position holdings represented by token balances on a blockchain
- Identity-bound ownership where wallet addresses become part of the audit trail
Each one breaks an assumption that traditional accounting systems were built around.
The operational gap
Most investment accounting platforms have no native support for digital assets, which forces firms into one of three workarounds, each with compounding costs. The first workaround is manual processing in spreadsheets, the second is a separate ledger for digital assets that has to be reconciled to the core accounting system, and the third is a heavily customised version of the existing platform, with the customisation layer becoming its own maintenance burden over time.
The specific operational risks include:
- Reconciliation overhead between the digital asset ledger and the core accounting system, which scales linearly with token activity
- Settlement-cycle mismatches where onchain transactions complete in minutes, but downstream accounting still processes overnight
- Limited visibility into 24/7 trading activity, which means positions, cash, and exposure views go stale outside market hours
- Manual handling of programmable distributions, which defeats the operational point of using smart contracts in the first place
- Audit trail fragmentation when onchain history lives in one system and accounting history lives in another
The accounting infrastructure decisions you make today will likely determine whether tokenisation can scale inside your firm or whether every new tokenised product becomes its own integration project.
The accounting implications
Settlement finality and continuous market operation are the two structural differences between tokenised assets and traditional instruments that most directly affect accounting. Both require accounting infrastructure that operates closer to the speed of the underlying market, as opposed to working through overnight processing.
Settlement finality
Onchain settlement is typically atomic and near-instant where both the asset and payment legs support it.
A traditional trade settling at T+1 or T+2 gives accounting systems a built-in buffer to process, validate, and reconcile.
Tokenised settlement removes that buffer, and the accounting record needs to update as the settlement completes, not at the end of the next overnight cycle.
This matters for two reasons. Firstly, position accuracy diverges between the onchain reality and the accounting view if the latter only updates overnight.
Secondly, downstream functions — including risk, compliance, and reporting — lose access to current positions for the gap between onchain settlement and accounting refresh.
24/7 markets
Crypto markets and some tokenised asset markets trade continuously across weekends and holidays but traditional accounting platforms are built around a market calendar where the close of trading triggers end-of-day processing.
There is no closure for some tokenised markets. That means pricing has to be available continuously, not anchored to a daily close; position keeping has to remain current through periods when the rest of the portfolio is dormant, and reporting and oversight functions have to be designed to handle activity that arrives outside the working day.
Neither of these challenges is insurmountable on a modern platform like FundGuard, but they are very hard to retrofit onto a legacy one.
The case for a unified platform
A unified platform treats digital assets as another asset class within the same accounting engine, alongside equities, fixed income, derivatives, and private markets. In practice, this means:
- One accounting engine processes traditional and tokenised instruments within a single system of record, while supporting the unique lifecycle requirements of each
- Multi-book architecture reflects tokenised assets across IBOR, ABOR, and PBOR consistent with every other asset class
- Position keeping, valuation, and corporate action processing work the same way regardless of whether the instrument settles on a custodian feed or onchain
- Audit trail and lineage cover digital and traditional assets in the same record with the same bitemporal traceability
- Reporting, exposure, and performance views are projections of one underlying dataset rather than aggregations across separate ledgers
Tokenised and traditional assets are accounted for within the same platform, so a fund holding listed equities, derivatives, private credit, and tokenised real estate can maintain a unified set of books while continuing to reconcile against the relevant custodians, transfer agents, and onchain records.
How a cloud-native, API-first architecture supports digital asset integration
Tokenised assets emit data continuously, settle on schedules the system can’t predict, and frequently involve smart contracts and onchain identifiers that don’t exist in standard custodian feeds.
Legacy batch-based platforms simply cannot accommodate this without significant customisation.
The three architectural properties of a platform like FundGuard that matter most include:
- Event-driven processing, which means onchain settlement events, price updates, and contract executions can update the accounting record as they happen rather than waiting for an overnight cycle
- An API-first design allows integrations with custody providers, onchain data vendors, and tokenisation platforms to work through standard interfaces rather than custom builds
- Cloud-native scalability ensures continuous trading and 24/7 market activity don’t require dedicated infrastructure planning or hardware refreshes as token activity grows
A legacy platform lifted into a cloud environment still runs on batch architecture underneath, so the upsides of cloud hosting are only operational. On the other hand, the benefits of cloud-native architecture are structural, and those structural benefits are what tokenised asset accounting actually needs.
Regulatory readiness
Regulatory frameworks for tokenised assets and digital instruments are evolving rapidly. The EU’s MiCA framework, the US Securities and Exchange Commission’s (SEC’s) evolving position on digital asset securities, the UK’s Digital Securities sandbox, and a growing set of jurisdiction-specific regimes are all reshaping what compliance, reporting, and auditability look like for firms holding tokenised assets.
This creates a specific challenge in that firms must comply with rules that are still being written. Institutions need accounting infrastructure designed to adapt, rather than designed around a specific current rulebook.
What adaptable infrastructure looks like in practice:
- Configurable reporting that can produce new regulatory views without custom development
- Bitemporal audit trails that show what was known at any prior point in time, which matters for regulatory investigations and historical compliance evidence
- Data lineage covering onchain and offchain sources together, allowing the regulator to follow the record across both
- Modular asset class support so new instrument types and new tokenisation standards can be added through configuration rather than re-platforming
What does this mean? It means you need to build for adaptability now, before every regulatory update becomes a re-platforming project.
Tokenised assets can introduce faster settlement, extended trading availability, and programmable distributions, depending on the instrument and market structure. Yet, none of these properties maps cleanly onto accounting infrastructure built in the early 2000s around overnight batches and standard market hours.
What tokenisation means for investment accounting
Tokenisation is the process of representing a financial asset, whether traditional or digitally-native, as a token on a distributed ledger. For investment accounting, this changes the mechanics of three core processes at once: how positions are tracked, how settlement is recorded, and how lifecycle events — including distributions, corporate actions, and redemptions — are processed.
The accounting events specific to tokenised assets include:
- Onchain settlement that finalises in minutes or seconds as opposed to T+1 or T+2
- Continuous trading and pricing across global markets, with no overnight pause
- Programmable distributions executed by smart contracts rather than scheduled by a custodian
- Position holdings represented by token balances on a blockchain
- Identity-bound ownership where wallet addresses become part of the audit trail
Each one breaks an assumption that traditional accounting systems were built around.
The operational gap
Most investment accounting platforms have no native support for digital assets, which forces firms into one of three workarounds, each with compounding costs. The first workaround is manual processing in spreadsheets, the second is a separate ledger for digital assets that has to be reconciled to the core accounting system, and the third is a heavily customised version of the existing platform, with the customisation layer becoming its own maintenance burden over time.
The specific operational risks include:
- Reconciliation overhead between the digital asset ledger and the core accounting system, which scales linearly with token activity
- Settlement-cycle mismatches where onchain transactions complete in minutes, but downstream accounting still processes overnight
- Limited visibility into 24/7 trading activity, which means positions, cash, and exposure views go stale outside market hours
- Manual handling of programmable distributions, which defeats the operational point of using smart contracts in the first place
- Audit trail fragmentation when onchain history lives in one system and accounting history lives in another
The accounting infrastructure decisions you make today will likely determine whether tokenisation can scale inside your firm or whether every new tokenised product becomes its own integration project.
The accounting implications
Settlement finality and continuous market operation are the two structural differences between tokenised assets and traditional instruments that most directly affect accounting. Both require accounting infrastructure that operates closer to the speed of the underlying market, as opposed to working through overnight processing.
Settlement finality
Onchain settlement is typically atomic and near-instant where both the asset and payment legs support it.
A traditional trade settling at T+1 or T+2 gives accounting systems a built-in buffer to process, validate, and reconcile.
Tokenised settlement removes that buffer, and the accounting record needs to update as the settlement completes, not at the end of the next overnight cycle.
This matters for two reasons. Firstly, position accuracy diverges between the onchain reality and the accounting view if the latter only updates overnight.
Secondly, downstream functions — including risk, compliance, and reporting — lose access to current positions for the gap between onchain settlement and accounting refresh.
24/7 markets
Crypto markets and some tokenised asset markets trade continuously across weekends and holidays but traditional accounting platforms are built around a market calendar where the close of trading triggers end-of-day processing.
There is no closure for some tokenised markets. That means pricing has to be available continuously, not anchored to a daily close; position keeping has to remain current through periods when the rest of the portfolio is dormant, and reporting and oversight functions have to be designed to handle activity that arrives outside the working day.
Neither of these challenges is insurmountable on a modern platform like FundGuard, but they are very hard to retrofit onto a legacy one.
The case for a unified platform
A unified platform treats digital assets as another asset class within the same accounting engine, alongside equities, fixed income, derivatives, and private markets. In practice, this means:
- One accounting engine processes traditional and tokenised instruments within a single system of record, while supporting the unique lifecycle requirements of each
- Multi-book architecture reflects tokenised assets across IBOR, ABOR, and PBOR consistent with every other asset class
- Position keeping, valuation, and corporate action processing work the same way regardless of whether the instrument settles on a custodian feed or onchain
- Audit trail and lineage cover digital and traditional assets in the same record with the same bitemporal traceability
- Reporting, exposure, and performance views are projections of one underlying dataset rather than aggregations across separate ledgers
Tokenised and traditional assets are accounted for within the same platform, so a fund holding listed equities, derivatives, private credit, and tokenised real estate can maintain a unified set of books while continuing to reconcile against the relevant custodians, transfer agents, and onchain records.
How a cloud-native, API-first architecture supports digital asset integration
Tokenised assets emit data continuously, settle on schedules the system can’t predict, and frequently involve smart contracts and onchain identifiers that don’t exist in standard custodian feeds.
Legacy batch-based platforms simply cannot accommodate this without significant customisation.
The three architectural properties of a platform like FundGuard that matter most include:
- Event-driven processing, which means onchain settlement events, price updates, and contract executions can update the accounting record as they happen rather than waiting for an overnight cycle
- An API-first design allows integrations with custody providers, onchain data vendors, and tokenisation platforms to work through standard interfaces rather than custom builds
- Cloud-native scalability ensures continuous trading and 24/7 market activity don’t require dedicated infrastructure planning or hardware refreshes as token activity grows
A legacy platform lifted into a cloud environment still runs on batch architecture underneath, so the upsides of cloud hosting are only operational. On the other hand, the benefits of cloud-native architecture are structural, and those structural benefits are what tokenised asset accounting actually needs.
Regulatory readiness
Regulatory frameworks for tokenised assets and digital instruments are evolving rapidly. The EU’s MiCA framework, the US Securities and Exchange Commission’s (SEC’s) evolving position on digital asset securities, the UK’s Digital Securities sandbox, and a growing set of jurisdiction-specific regimes are all reshaping what compliance, reporting, and auditability look like for firms holding tokenised assets.
This creates a specific challenge in that firms must comply with rules that are still being written. Institutions need accounting infrastructure designed to adapt, rather than designed around a specific current rulebook.
What adaptable infrastructure looks like in practice:
- Configurable reporting that can produce new regulatory views without custom development
- Bitemporal audit trails that show what was known at any prior point in time, which matters for regulatory investigations and historical compliance evidence
- Data lineage covering onchain and offchain sources together, allowing the regulator to follow the record across both
- Modular asset class support so new instrument types and new tokenisation standards can be added through configuration rather than re-platforming
What does this mean? It means you need to build for adaptability now, before every regulatory update becomes a re-platforming project.
NO FEE, NO RISK
100% ON RETURNS If you invest in only one digital assets news source this year, make sure it is your free subscription to The Digital Assets Edge
100% ON RETURNS If you invest in only one digital assets news source this year, make sure it is your free subscription to The Digital Assets Edge
