Tokenised Funds on the Private-Bank Shelf: Operating Model, Liquidity and Control

1. Begin with the client proposition

A private bank should begin with the client problem that a tokenised fund is expected to solve. Possible propositions include smaller minimum subscriptions, faster processing, improved collateral mobility, access to a digital-asset ecosystem, programmable distribution, simplified transfer between eligible investors or better integration of cash and fund records. Each proposition requires different infrastructure and controls. A digital representation on its own does not create client utility.

The product sponsor should state the target outcome in measurable terms. If the objective is faster settlement, the measure should include the complete interval from a valid client order to final cash and unit ownership, including exceptions. If the objective is lower minimums, the assessment should include total servicing economics, suitability and concentration. If the objective is broader liquidity, the evidence should identify the actual dealing or trading mechanism, market makers, redemption rights, asset liquidity, pricing method and stress controls.

Client utility also depends on the surrounding portfolio. A tokenised money-market fund used as on-chain collateral serves a different purpose from a tokenised private-market fund distributed in smaller denominations. One aims to support cash management and settlement. The other can improve access while retaining long holding periods, capital-call risk, valuation uncertainty and transfer restrictions. A bank should describe those differences before presenting a common digital-assets narrative.

The initial business case should therefore answer five questions: which client segment benefits, which process changes, which legal right is held, which new risks enter the chain and which evidence demonstrates improvement. These questions create the mandate for product, legal, compliance, investment, operations, technology and relationship-management teams.

Author framework. Each link requires an owner, evidence source, review date and decision consequence.

2. Establish the legal right and authoritative record

The most important first-stage question is what the client legally owns. The answer can be a fund unit issued in tokenised form, a security entitlement supported by custody of an underlying fund interest, a separate linked instrument or another contractual claim. Similar interfaces can conceal materially different rights, insolvency exposures, voting rights, information rights and recovery paths.

The United States Securities and Exchange Commission staff's January 2026 statement describes issuer-sponsored and third-party-sponsored tokenised securities. It explains that models differ according to whether the crypto network is part of the master securityholder file and whether the token represents a security entitlement, linked security or synthetic exposure. The statement also records that the format or ownership-recording method does not displace applicable federal securities law. The staff statement has no legal force or effect and should be read within its stated limitations.

The bank's legal analysis should identify the issuer, fund vehicle, share class, governing law, constitutional documents, holder rights and authoritative ownership record. It should explain how an on-chain transfer changes the legal record, which off-chain actions remain necessary and how discrepancies are resolved. The analysis should also cover insolvency, segregation, nominee arrangements, beneficial ownership, liens, transfer restrictions and the sequence for restoring ownership after lost access or technology failure.

The token can be the authoritative register entry, a synchronized representation of an off-chain record or a message that causes another record to change. The product file should state which model applies. Reconciliation duties, finality, error correction and evidence of title depend on that answer.

Table 1. Rights-and-record product test

Legal conclusions require jurisdiction-specific advice and complete product documents.

3. Separate the six operating layers

A tokenised fund proposition combines several systems that should be reviewed separately. The investment layer contains the portfolio assets, mandate, valuation and risk. The fund layer contains the legal vehicle, share class, governing documents and service providers. The token and register layer records ownership and transfer logic. The distribution layer contains product approval, marketing, advice, suitability and client communications. The cash and settlement layer moves subscription, redemption and trading consideration. The custody and control layer manages wallets, keys, reconciliations, cyber resilience and recovery.

Weak designs allow one layer to borrow credibility from another. A robust blockchain does not resolve weak fund liquidity. A regulated fund does not validate an untested wallet-control model. Instant token transfer does not create final settlement when cash, compliance or the legal register remains pending. A familiar manager does not establish that the new service providers and smart contracts are controlled.

The target operating model should map every material event across all six layers. Events include onboarding, subscription, rejection, minting, transfer, redemption, fee collection, income distribution, voting, valuation correction, sanctions alert, wallet compromise, chain disruption, service-provider failure and client death or incapacity. For each event, the map should identify the initiator, system of record, approval, timestamp, reconciliation, client communication and escalation.

The architecture should preserve separation of duties. A party able to create or destroy tokens should not alone approve the corresponding register change and cash movement. Privileged technology access should be controlled, logged and reviewed. Manual intervention should remain visible, especially when the marketing proposition emphasizes automation.

Author framework. Interfaces between layers are control points rather than assumed straight-through processing.

4. Use international developments as a design map

Official approaches are evolving through different legal and market structures. The FCA's April 2026 policy statement provides guidance for authorised fund managers using distributed ledger technology within the existing UK framework, including an industry-led Blueprint model, and introduces optional direct-to-fund dealing rules. The guidance addresses a tokenised register and a pathway toward more advanced uses.

Singapore's Project Guardian brings public authorities and financial institutions together around tokenisation. Its Guardian Funds Framework provides recommendations for the fund lifecycle, asset servicing and on-chain fund activity. This work is useful as an operating-design source. It does not replace the licences, laws and product requirements applicable to a particular Singapore or cross-border arrangement.

The Hong Kong SFC's revised April 2026 circular addresses tokenisation of SFC-authorised investment products. The framework uses a see-through approach to the underlying product and adds safeguards for tokenisation arrangements. A companion framework addresses secondary trading of specified tokenised authorised open-ended funds through regulated channels. The exact product, distributor, platform and client conditions remain decisive.

The EU DLT Pilot Regime has applied since March 2023 and creates DLT market-infrastructure categories for financial instruments within scope. ESMA's June 2025 review described limited uptake and recommended changes to improve participation. Switzerland licensed its first DLT trading facility in March 2025; FINMA highlighted business continuity, technical checks and delivery-versus-payment design. The SEC staff's 2026 taxonomy focuses attention on the issuer, record and rights. Together, these sources support an international control map without implying one global legal model.

Table 2. International official design evidence

The sources have different legal status, scope and dates. The table identifies operating implications rather than legal conclusions.

5. Segment clients by purpose, capability and constraint

Client segmentation should start with use case and operating capability. A digitally experienced entrepreneur seeking on-chain cash management has different needs from a family holding long-duration private assets through trusts. A professional investor seeking collateral mobility differs from a discretionary client who values consolidated reporting and simple recovery. Classification based only on wealth or age misses these distinctions.

A useful segmentation record covers investment purpose, legal structure, jurisdiction, tax residence, client classification, knowledge, wallet capability, security practices, liquidity needs, service preference and portfolio concentration. It should also identify whether the client needs self-custody, bank custody, nominee custody or no direct wallet interaction. The chosen route affects disclosures, authentication, recovery and accountability.

The bank should define minimum operating capabilities for each proposition. A client using self-hosted wallets may need whitelisting, proof-of-control, address screening, transaction testing and incident procedures. A bank-hosted solution requires clear custody terms, authentication and service continuity. A conventional interface connected to tokenised back-end infrastructure may require no new client capability, though the bank still manages the operating risk.

Segmentation should control which products and features are offered. Smaller denominations can reduce the entry amount while raising the risk of unsuitable concentration or misunderstanding. Continuous transfer availability can increase pressure for immediate execution. The service design should preserve suitability, cooling-off or review steps where required and should explain which functions remain subject to dealing windows and manual controls.

Author framework. The vertical and horizontal positions are qualitative decision dimensions rather than measured client scores.

6. Build the product shelf by function and structure

The product shelf should distinguish the investment exposure from the tokenisation model. Relevant exposures can include money-market funds, public-market funds, private credit, private equity, real assets, multi-asset portfolios and feeder vehicles. Relevant token models can include an issuer-maintained on-chain register, a synchronized register, a tokenised security entitlement or a third-party linked instrument. Combining these dimensions prevents the digital format from becoming the product category.

Money-market funds can support cash management, collateral and settlement, yet their underlying liquidity and redemption controls remain important. The BIS has observed that tokenised money-market funds can carry conventional money-market-fund vulnerabilities together with operational and anti-money-laundering risks associated with the surrounding ecosystem. Private-market funds can use tokenisation to change distribution or servicing while retaining illiquid assets, valuation cycles and restricted transfers.

The shelf map should record target clients, purpose, minimum subscription, dealing frequency, settlement asset, eligible wallets, custody route, valuation frequency, transfer perimeter, redemption terms, secondary mechanism, fees and data availability. It should identify whether an equivalent conventional share class exists and whether conversion is permitted. Differences between formats should be explicit.

Product comparison should use a common evidence card. The card should show fund economics first, token and operating design second, and portfolio fit third. A committee can then compare a tokenised product with the best conventional alternative rather than with other tokenised products alone.

Table 3. Tokenised fund shelf map

Product types are illustrative. Actual availability and terms require current verification.

7. Treat liquidity as a layered promise

Technical transferability, dealing liquidity, secondary-market liquidity, asset liquidity and cash liquidity are different concepts. A token can move between eligible wallets at any hour while the fund accepts subscriptions and redemptions once a day. A secondary venue can display bids while market makers have limited inventory. A redemption can be accepted while payment waits for asset sales, banking hours or settlement. Marketing and advice should preserve these distinctions.

The liquidity analysis should map the client path for normal and stressed conditions. It should record order cut-offs, valuation points, settlement cycles, redemption notice, gates, suspensions, dilution tools, in-kind possibilities, market-maker obligations, price bands, trading pauses and cash-rail availability. If primary and secondary prices can diverge, the bank should define fair-pricing and escalation procedures.

Twenty-four-hour operation creates a governance question: which teams, providers and decision-makers are available when the interface is open? A transfer or trade initiated outside the fund's core operating window can encounter stale NAV, delayed screening, limited market making or unavailable fiat settlement. The operating model should either support the service window or constrain the feature accurately.

Liquidity claims should be supported by executed data after launch. Useful measures include valid orders completed, median and tail processing time, rejection causes, spread, depth, premium or discount to NAV, redemption settlement time and exception ageing. Reported averages should be accompanied by stressed and outlier information.

Author framework. Higher technical availability does not establish liquidity at the other layers.

8. Design the cash leg and settlement finality

A fund token and its payment asset can settle through different systems. Cash options may include conventional bank money, tokenised commercial-bank deposits, central-bank money where available, e-money or stablecoin arrangements permitted for the use case. Each option carries different issuer, redemption, timing, legal, operational and liquidity characteristics.

The bank should document the point at which the client's cash obligation and fund ownership become final. It should identify prefunding, credit exposure, failed trades, reversals, time-zone dependencies, currency conversion and reconciliation. Atomic or delivery-versus-payment designs can reduce principal risk when legal and technical conditions align. They still require analysis of the assets, parties, smart contract, network and failure modes.

FINMA's account of Switzerland's first licensed DLT trading facility describes delivery-versus-payment using a public blockchain connected to the Swiss Interbank Clearing system. BIS Project Agorá explores tokenised central-bank reserves and commercial-bank deposits for wholesale cross-border payments while examining settlement finality, financial-crime compliance and data privacy. These are valuable design references; they do not establish that the same model is available for a private bank's fund distribution.

Currency is also a client issue. A tokenised fund denominated in one currency and settled through another asset can create conversion cost, spread and timing exposure. The product file should show the complete cash path and every fee. Treasury, operations and client reporting should reconcile the same economics.

9. Govern custody, wallets and privileged access

Custody analysis should cover the fund assets, the fund interest, the token, the wallet and the cryptographic keys. These can sit with different parties. The bank should map which asset each custodian controls, what evidence of ownership it maintains, how instructions are authenticated and which party bears loss under the contract.

Wallet models include bank-controlled omnibus or segregated wallets, third-party custody, client-controlled wallets and interfaces where the client never interacts directly with a wallet. The choice affects operational responsibilities, client experience, recovery and data. The contract should identify subcustodians, network changes, forks, airdrops, sanctions controls, transaction fees and liability limits.

Key control should use strong separation of duties, authorization thresholds, secure generation and storage, tested backup and recovery, privileged-access monitoring and incident escalation. Smart-contract administrators, upgrade keys, pausing authority and token minting or burning rights require equivalent governance. The bank should know who can change the system, under which approvals and with which evidence.

Recovery procedures should be tested before launch. Scenarios should include lost client access, compromised credentials, incorrect address, unauthorized transfer, provider outage, ledger fork, smart-contract vulnerability, sanctions alert, death, incapacity and legal restraint. A recovery promise should correspond to an operationally and legally valid process.

10. Integrate identity, eligibility and transfer controls

Tokenised distribution can place client eligibility into wallet allowlists, smart contracts, transfer-agent records or a combination. The bank should identify which control is legally responsible for preventing an invalid transfer and how the different records stay synchronized. A technology restriction can support compliance while leaving the regulated entity accountable.

Client onboarding should cover identification, beneficial ownership, sanctions, source of wealth or funds where required, client classification, tax documentation, suitability and product eligibility. Wallet onboarding may add proof of control, address screening and test transactions. Ongoing monitoring should identify changes in client status, wallet risk, jurisdiction and product restrictions.

Transfers between eligible clients raise data and privacy questions. Public networks can expose transaction data while regulated records connect addresses to identities. The operating model should specify which data appear on-chain, which remain off-chain, who can access them, retention and correction. Cross-border distribution should be controlled at the legal and client level rather than inferred from technical reach.

The exception process should address false alerts, delayed screening, failed synchronization and attempted transfers to ineligible addresses. The bank should define when a token is frozen, reversed, reissued or placed in suspense and how the client is informed. Decisions should be logged and independently reviewable.

11. Preserve a complete suitability workflow

Suitability should assess the underlying investment and the token-specific operating features. The investment test covers objectives, risk, capacity for loss, horizon, liquidity, knowledge, experience, concentration, currency and portfolio interaction. The token test covers legal rights, custody, wallet use, transfer conditions, settlement asset, technology dependencies, recovery and the client's ability to understand and operate the service.

A tokenised format can change access and behavior. A lower minimum may make an illiquid fund available to a broader set of clients. A tradable interface can encourage clients to expect liquidity that the underlying assets cannot support. Near-continuous display can imply continuously current valuation. Suitability and communication should correct these possible misunderstandings.

The recommendation should compare the chosen tokenised product with a relevant conventional alternative. The record should explain the incremental client benefit, incremental cost and incremental risk. Where the same economic exposure is available conventionally, the token format should earn its place in the recommendation through a documented client purpose.

Post-sale monitoring should capture changes in the client, fund, token, service providers, network, liquidity and law. Material changes should trigger reassessment, communication, restrictions or exit planning. The relationship manager needs a concise evidence card and a route to escalate questions without interpreting technical claims alone.

Table 4. Suitability and product-governance workflow

The workflow is a design framework and should be adapted to the applicable legal and regulatory requirements.

12. Control valuation, income and corporate actions

Token availability does not determine net asset value. The underlying fund's valuation policy, source data, cut-off, fair-value procedures and governance remain central. The interface should show the basis and time of any displayed value. A secondary price can differ from the last NAV; the difference should be clear to the client and monitored.

Income distributions, fee accruals, voting, notices, capital calls, conversions, splits and redemptions must reach the correct holder. The bank should establish whether the authoritative record or a snapshot controls entitlement and how late or corrected records are handled. Smart contracts can automate parts of the process while data inputs, legal decisions and exceptions remain governed.

Tax reporting and client statements should connect token transactions to the legal instrument and economic event. The bank should not infer tax treatment from the technology label. Cost basis, income, withholding, currency and transfer history require complete records across on-chain and off-chain systems.

Reconciliation should compare token supply, authoritative register, custodian positions, fund administrator records, cash and client books. Breaks should be aged, owned and resolved. Material discrepancies should trigger dealing or transfer restrictions under pre-agreed rules.

13. Make the fee waterfall visible

Tokenised fund economics can include the underlying fund charge, performance fee, platform fee, custody fee, wallet or network fee, trading spread, market-making cost, foreign-exchange cost, transfer-agent fee and advice or discretionary-management charge. Some costs are explicit; others appear through execution or service-provider pricing. A complete comparison should measure the client's total cost through the expected holding period.

Technology can remove certain reconciliations or intermediaries while adding infrastructure, integration, security, compliance and resilience expenses. The commercial case should distinguish costs shifted between parties from costs genuinely reduced. It should also consider scale, exception rates and the coexistence of conventional and tokenised rails.

The hypothetical fee waterfall in Table 5 illustrates the method. The percentages are management assumptions and do not describe a real product. A bank should replace them with verified terms, transaction data and internal cost allocations. Scenario analysis should cover different holding periods, transaction frequency, currency paths and exit routes.

Table 5. Hypothetical annualised client fee waterfall

Every number is a hypothetical management assumption for method demonstration; figures are not market observations or forecasts.

14. Assign accountability across the operating model

The product sponsor owns the client proposition and business case. Investment teams own underlying-fund due diligence and portfolio fit. Legal identifies the instrument, rights, register, contracts and jurisdictional perimeter. Compliance owns regulatory interpretation, distribution controls and financial-crime requirements. Operations owns dealing, settlement, reconciliation, valuation interfaces and exceptions. Technology and information security own architecture, access, monitoring, change and recovery. Risk provides independent challenge. Relationship management owns accurate client communication within approved materials.

Accountability should follow decisions rather than organisational labels. Every product claim, operating limit and exception needs a named owner. Service providers should have measurable obligations for availability, incident notification, recovery, reconciliation, data and audit access. Outsourcing does not remove the bank's need to understand and govern the process.

The bank should maintain an end-to-end service map and data lineage. The map should connect client order, approvals, cash, token, register, custody, NAV, fees and reporting. A single client event should be traceable across the chain without relying on a vendor demonstration.

Change governance is particularly important. Network upgrades, smart-contract changes, new wallets, new cash assets, new jurisdictions, new transfer features or secondary trading can alter the risk profile. The product approval should state which changes require committee review, legal analysis, client notice, testing or a new suitability assessment.

15. Design operational resilience around client outcomes

The service should define important business services and impact tolerances in terms meaningful to clients. Possible outcomes include establishing ownership, executing a valid subscription or redemption, accessing custody, receiving cash, correcting an error and recovering after compromised access. System uptime alone does not measure these outcomes.

Scenario tests should span the entire chain. Relevant scenarios include cloud outage, network congestion, smart-contract defect, key compromise, transfer-agent failure, bank-payment disruption, stablecoin depegging where relevant, cyber attack, sanctions event, erroneous minting, inaccurate NAV and simultaneous provider failures. Tests should include communication, manual alternatives and the point at which the bank restricts activity.

The FSB's 2024 report notes potential efficiency and transparency benefits from tokenisation and identifies vulnerabilities relating to liquidity and maturity mismatch, leverage, asset price and quality, interconnectedness and operational fragilities. IOSCO's 2025 report examines tokenisation across issuance, trading and post-trade and emphasizes familiar investor-protection, market-integrity and operational issues in changed structures. These sources support conventional financial-risk discipline alongside technology controls.

Exit planning should be part of approval. The bank should know how positions are converted, transferred, redeemed or serviced if the network, vendor, wallet model or token format is withdrawn. Data portability, register continuity, client consent, cost and timing require advance design.

16. Use a product-committee gate with measurable evidence

Product approval should proceed through a gated decision. The first gate validates the client need and best alternative. The second establishes legal rights and regulatory perimeter. The third tests the fund and manager. The fourth tests the token, register, cash, custody and providers. The fifth validates suitability, disclosure and RM materials. The sixth completes operations, resilience, recovery and financial approval. The seventh authorizes a limited launch with monitoring thresholds.

Each gate should produce evidence rather than a narrative assertion. Examples include legal opinions, fund documents, provider due diligence, smart-contract audit, penetration test, reconciliation results, settlement test, liquidity analysis, fee comparison, client-journey test and incident exercise. Material limitations should become launch conditions or client restrictions.

The committee should define stop conditions. These can include unresolved ownership ambiguity, inability to reconcile token supply, insufficient recovery rights, untested privileged access, unverified liquidity claims, incomplete client disclosure or unacceptable provider concentration. The decision record should identify residual risks accepted and by whom.

A limited release can reduce exposure while generating operating evidence. The bank should cap clients, jurisdictions, assets, transaction size and wallet types according to the verified controls. Expansion should depend on completed transactions, exception performance, client understanding and successful resilience tests.

Author framework. Passing one gate does not cure a failure at another gate.

17. Test the design through client cases

Worked cases expose trade-offs that architecture diagrams can hide. Table 6 presents three hypothetical cases. All client facts, allocations and decisions are management assumptions for demonstration and do not describe real people or recommendations.

The first case uses a tokenised money-market fund to support an eligible client's digital-asset cash workflow. The decisive evidence concerns redemption, settlement asset, wallet controls and operational availability. The second uses a tokenised private-credit feeder to reduce the entry unit. The lower denomination does not change credit, valuation, term or transfer restrictions. The third considers a third-party token linked to a public fund. The rights-and-record test shows that the client may hold exposure issued by the third party rather than the underlying fund interest.

Each case should be compared with a conventional route. The comparison includes investment exposure, rights, liquidity, costs, custody, tax and operational burden. A tokenised option can be appropriate when the client benefit is specific and the control chain is complete.

Table 6. Hypothetical private-client cases

Every client fact and proposed action is a hypothetical management assumption; cases are method demonstrations rather than recommendations.

18. Give relationship managers an evidence card

The relationship manager should be able to explain the product in one page without collapsing the investment and technology layers. The evidence card should state the instrument, issuer, underlying fund, client rights, authoritative record, custody route, dealing and settlement, liquidity, valuation, complete fees, transfer conditions, recovery process, principal risks and portfolio role. It should include the date and owners of the evidence.

Approved language should avoid claims that tokenisation guarantees liquidity, lower cost, transparency or safety. The RM can describe a verified feature and its conditions. For example, a token may be technically transferable between approved wallets at specified times, while fund redemption and cash settlement follow separate rules.

The dashboard should support continuing conversations. It should show product status, NAV timestamp, secondary price where applicable, spread, depth, subscription and redemption completion, failed transactions, reconciliation breaks, provider incidents, security events, client complaints and pending changes. Material limitations should remain visible.

Training should use real process demonstrations and failure scenarios. RMs should know what the bank controls, what providers control, which client actions are required and where to escalate. Competence records should align with the features actually offered.

Author framework. Status indicators are illustrative and require verified production data.

19. Execute through a 180-day sequence

Days 0 to 30 should define the proposition, target client, product universe, jurisdiction and governing hypotheses. The team should complete the rights-and-record analysis, map the six operating layers and identify the best conventional comparator. No external client claim should precede verified evidence.

Days 31 to 60 should complete provider due diligence, architecture, service map, data lineage, custody, cash, transfer controls and legal documents. The team should build the fee waterfall and specify control evidence. Material gaps should become decisions rather than deferred implementation notes.

Days 61 to 90 should build the client journey, suitability workflow, disclosures, RM evidence card, reporting and exception procedures. Technology and operations should test valid and invalid subscriptions, transfers, redemptions, reconciliations and recovery. Security review should cover smart contracts, privileged access and providers.

Days 91 to 120 should conduct end-to-end testing, resilience exercises, client-understanding tests and committee challenge. The bank should finalize limits, stop conditions, incident communication and exit plan. Approval should state which features remain unavailable.

Days 121 to 150 should run a controlled release within approved clients, jurisdictions, assets, size, wallets and hours. Management should review every exception and compare executed cost and timing with the business case. Days 151 to 180 should assess expansion against pre-agreed evidence. A weak result should lead to remediation, continued limits or withdrawal.

20. Measure value through outcomes and control quality

The long-term case for tokenised funds depends on whether the model improves client outcomes and operating economics while maintaining strong controls. Useful client measures include access to an appropriate product, complete cost, processing certainty, liquidity experience, reporting quality and recovery. Useful operating measures include straight-through completion, exception rates, reconciliation effort, settlement time, provider performance and incident recovery.

Volume alone can hide weak economics. The bank should allocate the cost of duplicated rails, integration, licences, custody, security, compliance, training and support. Benefits should be evidenced through actual process data and compared with the conventional alternative. Scale assumptions should remain visible.

The international evidence points toward several durable design principles. Tokenisation changes records and workflows while leaving the economic asset and investor-protection questions central. Legal rights depend on structure. Liquidity has multiple layers. Cash finality and custody require separate design. Interoperability, identity, resilience and recovery determine whether a pilot can become a service.

For a private bank, the governing decision is concise: can the institution show what the client owns, which record proves it, how the investment and token are controlled, where liquidity and cash come from, how the product fits the portfolio, what the complete cost is and what happens when a system or provider fails? A verified answer supports a disciplined shelf decision. An incomplete answer belongs in further design work.

References

1. UK Financial Conduct Authority, PS26/7: Progressing fund tokenisation, 30 April 2026, https://www.fca.org.uk/publications/policy-statements/ps26-7-progressing-fund-tokenisation
2. UK Financial Conduct Authority, FCA sets out guidance to support innovation in fund tokenisation, 30 April 2026, https://www.fca.org.uk/news/press-releases/fca-sets-out-guidance-support-innovation-fund-tokenisation
3. Monetary Authority of Singapore, Project Guardian, https://www.mas.gov.sg/schemes-and-initiatives/project-guardian
4. Monetary Authority of Singapore, Guardian Funds Framework, 2024, https://www.mas.gov.sg/publications/monographs-or-information-paper/2024/guardian-funds-framework
5. Monetary Authority of Singapore, MAS expands industry collaboration to scale asset tokenisation for financial services, 4 November 2024, https://www.mas.gov.sg/news/media-releases/2024/mas-expands-industry-collaboration-to-scale-asset-tokenisation-for-financial-services
6. Securities and Futures Commission of Hong Kong, Circular on tokenisation of SFC-authorised investment products, revised 20 April 2026, https://apps.sfc.hk/edistributionWeb/api/circular/list-content/circular/doc?lang=EN&refNo=26EC22
7. Securities and Futures Commission of Hong Kong, Circular on secondary trading of tokenised SFC-authorised investment products, 20 April 2026, https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=26EC23
8. Securities and Futures Commission of Hong Kong, Circular on intermediaries engaging in tokenised securities-related activities, 2 November 2023, https://apps.sfc.hk/edistributionWeb/api/circular/list-content?lang=EN&refNo=23EC52
9. Hong Kong Monetary Authority, Project Ensemble completed use cases, 28 October 2024, https://www.hkma.gov.hk/media/eng/doc/key-information/press-release/2024/20241028e5a1.pdf
10. European Securities and Markets Authority, DLT Pilot Regime, https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/dlt-pilot-regime
11. European Securities and Markets Authority, Report on the functioning and review of the DLT Pilot Regime, 25 June 2025, https://www.esma.europa.eu/sites/default/files/2025-06/ESMA75-117376770-460_Report_on_the_functioning_and_review_of_the_DLTR_-_Art.14.pdf
12. United States Securities and Exchange Commission staff, Statement on Tokenized Securities, 28 January 2026, https://www.sec.gov/newsroom/speeches-statements/corp-fin-statement-tokenized-securities-012826-statement-tokenized-securities
13. Swiss Financial Market Supervisory Authority, FINMA licenses first DLT trading facility, 18 March 2025, https://www.finma.ch/en/news/2025/03/20250318-mm-dlt-handelssystem/
14. International Organization of Securities Commissions, Tokenization of Financial Assets, November 2025, https://www.iosco.org/library/pubdocs/pdf/IOSCOPD809.pdf
15. Financial Stability Board, The Financial Stability Implications of Tokenisation, 22 October 2024, https://www.fsb.org/2024/10/the-financial-stability-implications-of-tokenisation/
16. Bank for International Settlements, The rise of tokenised money market funds, BIS Bulletin No 115, 26 November 2025, https://www.bis.org/publ/bisbull115.htm
17. Bank for International Settlements Innovation Hub, Project Agorá: exploring tokenisation of wholesale cross-border payments, https://www.bis.org/about/bisih/topics/fmis/agora.htm
18. Bank for International Settlements, Project Agorá: a shared programmable platform for wholesale cross-border payments, 2026, https://www.bis.org/publ/othp110.htm

About the Author

Chennakeshav Adya is an independent researcher and Managing Partner of Matchpoint Partners. His work examines strategy, capital formation, valuation, transactions and operating execution across private and public markets.