Financial
Real & Physical
Americas
Europe
Asia
Investor Onboarding, Direct Dealing and Lifecycle Operations for Tokenized Funds
Gofaizen & Sherle can design the investor-operations model for a tokenized fund and coordinate its implementation. The scope can cover eligibility and AML/KYC requirements, wallet approval, subscriptions, payments, token delivery, transfer controls, NAV-related servicing and redemptions, while regulated and technical execution remains with the properly appointed providers.
The engagement should turn the selected fund and tokenization structure into a controlled workflow, assign each decision to the appropriate fund manager, administrator or transfer agent, depositary or custodian, onboarding provider, payment provider and technology vendor, and define how their records stay aligned.
The precise model depends on the investment fund’s domicile and type, investor categories, distribution markets, dealing frequency, token design, official register and providers appointed. The analysis below is global and multi-jurisdictional. Legal requirements should be confirmed for the chosen jurisdictions as at the implementation date.
How does investor onboarding work for a tokenized fund?
An investor onboarding workflow for tokenized funds should move the intended investor base through explicit approval gates. Connecting digital wallets is only one gate; it is not the start or end of compliance.
| Stage | Operational outcome | Typical accountable or performing role* |
| Application | A complete investor file and consent record | Fund manager, administrator or onboarding provider |
| Identity and classification | Verified identity and beneficial ownership; investor category recorded | Obliged entity, supported by an AML/KYC provider |
| Eligibility | Jurisdiction, distribution, sanctions, tax and product rules checked | Fund manager, distributor, legal/compliance function |
| Wallet approval | The approved investor is linked to a permitted delivery address | Fund manager, custodian or wallet technology provider |
| Subscription and payment | Order accepted, cash attributed and settlement conditions met | Fund manager, administrator, depositary or payment provider |
| Token delivery and register update | Fund interests issued under the governing documents, corresponding tokens delivered to the approved wallet, and the authoritative ownership record updated | Fund manager, register operator, administrator or transfer agent |
| Ongoing servicing | Transfers, distributions, corporate actions, NAV events and redemptions controlled | Fund manager and appointed service providers |
*Role names and regulated responsibilities vary by jurisdiction and fund structure.
The operating model should identify the source of truth for identity, eligibility, wallet, cash, token, official register and fund administration records. It should also state which record prevails if two systems disagree, who can correct an error and what evidence must be retained. That control model matters whether the DLT unitholder register is the official record, mirrors another register or records only a technical representation of the fund interests.
What does direct-to-fund dealing change—and what remains regulated?
Direct-to-fund dealing for tokenized funds changes the transaction route, not the fund’s legal and operational obligations. It may remove an intermediary from the order path, but it does not remove investor checks, valuation rules, liquidity controls, register responsibilities or oversight of outsourced providers.The model is jurisdiction-specific.
In that UK context, tokenised funds using direct dealing still need clearly allocated control owners, and each tokenised fund must reflect its own scheme documents. The framework should not be projected onto another market. Before selecting a direct dealing model, the sponsor should confirm who may accept an order, hold subscription money, issue or cancel units, maintain the register, calculate or apply NAV, and pay redemption proceeds in each relevant jurisdiction.
How should eligibility, AML/KYC and wallet controls be applied?
Eligibility, AML/KYC and wallet verification are related but distinct controls. A workable approval decision normally combines:
- identity and beneficial-owner verification
- customer risk assessment, purpose and intended nature of the relationship, and ongoing monitoring
- sanctions and other legally required screening
- investor classification and any offering, residency or distribution restrictions
- tax documentation
- suitability or appropriateness checks where the product, channel and local rules require them
- evidence that a delivery wallet is owned or controlled by, or validly designated for, the approved investor.
The FATF Recommendations provide the international baseline for customer due diligence, beneficial ownership, ongoing monitoring and third-party reliance. The standards are amended periodically: the 2025 revisions to Recommendation 1 reinforced proportionality in the risk-based approach, and the revised Recommendation 16 on payment transparency, to be implemented by the end of 2030, will matter where subscription or redemption flows settle in crypto rather than through a conventional payment rail. National AML rules and the identity of the obliged entity still determine what must be done in a particular launch. FATF’s Guidance on Digital ID (2020) also treats the assurance level of an identity system, and whether it is sufficiently reliable and independent for the risks involved, as the test for using it in customer due diligence.
How are failed payments, token delivery and record mismatches handled?
An accepted subscription should be traceable end to end across the order, payment, token and register systems. The workflow needs to define:
- the dealing cut-off and evidence of receipt
- the conditions for accepting or rejecting the order
- payment instructions and attribution of cash to the investor and order
- the valuation point and number of units to issue
- the approved wallet and token-delivery instruction
- the update to the authoritative register and administration record
- reconciliation and closure of the transaction.
The exception design is as important as the happy path. It should cover:
- late, failed, duplicate or unattributed payments
- an incorrect chain or wallet
- a wallet that loses approval before delivery
- smart-contract or network failure
- an order accepted for the wrong class
- disagreement between token balances, the register and administrator records.
Controls may include unique transaction identifiers, maker-checker approval, delivery-versus-payment logic where legally and technically feasible, suspense accounts, retry limits, a manual release path and documented correction authority.
Each exception needs an owner, service level, escalation route, investor communication rule and audit trail. “Atomic settlement” should not be presented as an unconditional outcome where cash rails, valuation and register updates remain separate.
How are transfers, NAV events, distributions and redemptions serviced?
Lifecycle management continues after issuance. Every permitted transfer should be checked against the fund documents, applicable law, the recipient’s current eligibility, wallet status, class rules, lock-ups and other transfer restrictions. The model should also cover distributions, fee events, corporate actions, freezes, corrections, compulsory transfers or redemptions, and changes in an investor’s status.
As with traditional investment funds, tokenization does not create continuous NAV or 24/7 dealing unless the fund’s legal and operational design actually supports it. The IOSCO Revised Recommendations for the Valuation of Collective Investment Schemes, published on 1 June 2026, retain the principle that subscriptions and redemptions should be processed using a NAV calculated in accordance with the scheme’s disclosed valuation policy. The fund documents, valuation cycle, cut-offs, liquidity terms, gates, suspensions and local rules remain controlling.
In practice, how investors redeem tokenized fund units should be specified as a controlled sequence:
- The investor submits an instruction through an authorised channel or wallet.
- The system validates the investor, holding, wallet, cut-off, lock-up and dealing terms.
- The appointed valuation or administration function determines or applies the relevant NAV, while the authorised decision-maker applies any permitted fees, gates, deferral or suspension.
- After approval, the fund interest is cancelled or transferred in the authoritative record, while the corresponding token is blocked, burned or transferred as the technical model requires.
- The authoritative register and fund administration records are updated.
- Proceeds are released through the approved payment route, then cash, token and register records are reconciled.
The procedure also needs fallback instructions for outages, disputed ownership, a compromised wallet, failed payment of proceeds and corrections after a valuation error.
Who owns each control, record and operational incident?
The right lead provider is one that can design the whole operating model while keeping regulated execution with the properly appointed entities. A responsibility matrix will usually distinguish the following roles:
| Role | Typical responsibility in the target model* |
| Fund manager or management company | Product rules, investor approval, dealing decisions, provider oversight and responsibilities retained under applicable law |
| Administrator, transfer agent or register operator | Order processing, fund administration records, register operations, NAV interface and reconciliation |
| Depositary or custodian | Functions required by the fund regime, plus asset, cash or wallet custody where appointed and permitted |
| AML/KYC or onboarding provider | Screening tools, verification workflow and evidence under the obliged entity’s policy |
| Bank or payment provider | Subscription and redemption payment rails, account controls, returns and payment evidence |
| DLT and tokenization vendor | Smart contracts, wallet integration, transfer controls, system logs and technical incident response |
| Legal and operations adviser | Jurisdictional requirements, workflow and control design, responsibility allocation, document alignment, vendor coordination and implementation support |
*The same entity may perform more than one role where law, authorisation and conflicts rules permit it.
A RACI matrix can clarify who is responsible, accountable, consulted and informed, but it is only a starting point. The contracts and procedures need data ownership, access rights, record retention, service levels, change control, incident notification, audit evidence, business continuity, exit assistance and migration of records. For EU projects, the GDPR makes data minimisation and data protection by design relevant to decisions about personal data on an immutable ledger. Where the entities and services fall within scope, DORA also requires financial entities to manage ICT and third-party risk; outsourcing does not remove their responsibility.
What should an investor-operations engagement deliver?
An implementation engagement for fund-unit tokenization should produce usable operating artefacts, not just a conceptual diagram. Depending on scope, the engagement can produce:
- a jurisdictional requirements and regulated-roles matrix
- an application-to-redemption workflow with decision gates and exception paths
- a control and responsibility matrix
- a data map showing systems of record, interfaces and reconciliation rules
- wallet, payment, token-delivery and transfer-control requirements
- an exception catalogue with service levels, escalation and incident response
- a fund-document, policy, procedure and vendor-contract gap list
- test scenarios, acceptance criteria and an audit-evidence checklist
- a sequenced implementation backlog for the appointed service providers.
To scope the work, the sponsor should provide the fund domicile and type, target investor categories and markets, proposed token and DLT unitholder register model, dealing and NAV cycle, distribution route, appointed or shortlisted providers, custody and payment setup, technology stack and current launch stage.
For broader structuring context, see Asset Tokenization Services.
To assess the operating model for an active fund tokenization project, include the investor types, jurisdictions, service-provider stack, dealing model and intended source of truth for the unit register.
Frequently asked questions
Can wallet whitelisting replace KYC?
No. Whitelisting is a technical control over approved addresses. It does not replace identity and beneficial-owner verification, eligibility, sanctions screening, ongoing monitoring or other controls required for the investor and distribution route.
Can investors redeem tokenized fund units at any time?
Not automatically. Redemptions remain subject to the fund documents, dealing cut-offs, valuation policy, liquidity terms, applicable law and operational availability. Token transferability alone does not create a redemption right or continuous NAV.
Does direct-to-fund dealing remove the need for an administrator or transfer agent?
Not necessarily. It changes the order route. Register maintenance, fund administration, NAV interfaces, cash controls, reconciliation and investor servicing still need assigned owners, even if role names and provider combinations differ.
mihhail@gofaizen-sherle.com 