How to Choose an Asset Tokenization Platform: Key Legal and Technical Criteria

How to Choose an Asset Tokenization Platform: Key Legal and Technical Criteria

How to Choose an Asset Tokenization Platform: Key Legal and Technical Criteria

🔗 Asset Tokenization · Platform Selection Guide · 2025–2026

How to Choose an Asset Tokenization Platform: Key Legal and Technical Criteria

Selecting an asset tokenization platform is not a purely technical decision. The platform you choose determines the regulatory framework your tokens operate under, the legal enforceability of investor rights, the custody model for underlying assets, and the secondary market access available to token holders. Getting this decision right is foundational to every tokenization project — and mistakes are difficult and expensive to reverse once tokens have been issued.

Asset Tokenization
Platform Due Diligence
Security Tokens
Smart Contracts
Token Standards
KYC / AML
MiCA · MiFID II

Section 1 — What Asset Tokenization Is and Why Platform Choice Is Critical

Asset tokenization is the process of representing ownership rights in a real-world asset — real estate, private equity, bonds, infrastructure, art, commodities, or funds — as digital tokens on a blockchain. The token records the investor's entitlement on an immutable ledger, automating rights management, dividend distribution, and transfer mechanics through smart contracts. The tokenization platform is the technical and legal infrastructure through which this process takes place — and its characteristics determine far more than the mechanics of issuance.

What a Tokenization Platform Actually Does

🏗️
Asset Structuring
Legal wrapper creation, SPV structuring, offering document generation, investor eligibility controls, and regulatory compliance for the token offering
⛓️
Token Issuance
Smart contract deployment, token minting according to the chosen standard, on-chain cap table creation, KYC/whitelisting integration, and investor onboarding
🔄
Lifecycle Management
Dividend and distribution automation, secondary transfer management, corporate actions (voting, redemption, buybacks), reporting, and post-market monitoring

A tokenization platform is simultaneously a technology provider, a legal infrastructure provider, and — depending on the licences it holds — a regulated financial institution. The platform choice locks in the jurisdictional framework for your token, the smart contract architecture your tokens operate on, the custody model protecting underlying assets, and the secondary market venues your investors can access. Unlike most technology vendor decisions, switching platforms after issuance is extremely difficult: tokens already issued on one blockchain cannot typically be migrated without a legally complex token swap process and potentially a new regulatory filing.

The Two Main Platform Categories

🌐
Category A
Public Blockchain Platforms
Built on public, permissionless blockchains — typically Ethereum, Polygon, Avalanche, or Stellar
Tokens are natively interoperable with the broader DeFi and secondary market ecosystem — any ERC-compatible exchange or wallet can theoretically hold or trade the token
Transfer restrictions and compliance rules must be enforced on-chain via smart contract logic — whitelisting, transfer restrictions, and KYC verification are embedded in the token contract
Higher transparency and auditability — all transactions are publicly visible on-chain, which is a feature for regulated securities but requires careful data privacy structuring
Risk: gas fee variability, chain governance changes, and dependency on third-party infrastructure outside the platform operator's control
Examples: Securitize (Ethereum/Polygon), Tokeny/T-REX (Ethereum), Polymath (Polymesh), Centrifuge (Ethereum/Polkadot)
🔒
Category B
Permissioned / Private Blockchain Platforms
Built on enterprise or consortium blockchains — typically Hyperledger Fabric, R3 Corda, Quorum, or proprietary chains
Node participation is restricted to known, vetted validators — often the platform operator, partner banks, and institutional clients
Transaction privacy is configurable — not every transaction is publicly visible, making GDPR compliance easier for confidential financial data
Regulatory compliance baked into the network layer rather than purely into smart contracts — the permissioning model itself restricts who can participate
Risk: limited secondary market access — tokens cannot natively interact with public exchanges, and interoperability requires bridge solutions that introduce their own risks
Examples: Broadridge DLR (private), SIX Digital Exchange (permissioned), HSBC Orion (private), some institutional platforms built on Corda
⚠️
The cost of a wrong platform choice: organisations that have tokenized assets on an unsuitable platform typically face one or more of the following: (1) inability to list tokens on regulated secondary venues due to incompatible token standards; (2) regulatory action because the platform's licensing does not cover the jurisdiction of offering; (3) investor disputes because transfer restrictions were not properly enforced on-chain; (4) custody failures because underlying asset safekeeping was not properly segregated; and (5) technical lock-in making migration to a compliant platform prohibitively expensive. Legal and technical due diligence before issuance is not optional — it is the single most leveraged investment in a tokenization project.

The Six Dimensions of Platform Evaluation

Choosing a tokenization platform requires assessment across six distinct dimensions — each of which is addressed in depth in the following sections of this guide. No single dimension can be evaluated in isolation: a technically excellent platform with inadequate regulatory licensing exposes issuers to enforcement risk, while a well-licensed platform with poor smart contract security exposes investors to loss of assets.

📐 Platform evaluation dimensions
⚖️
Legal & Regulatory
Licences held, jurisdictions covered, securities law alignment, MiCA/MiFID II compliance
⛓️
Blockchain Architecture
Chain choice, smart contract security, settlement finality, interoperability, gas fee model
🪙
Token Standards
ERC-20 vs. ERC-1400 vs. ERC-3643, asset class compatibility, transfer restriction enforcement
🏦
Custody Model
Key management, regulated custodian, asset segregation, insurance coverage
🪪
KYC/AML & Investors
Identity verification, ongoing monitoring, cap table management, corporate actions
📈
Secondary Market
MTF/ATS integration, liquidity mechanisms, cross-platform interoperability, trading venue licences

Section 2 — Legal and Regulatory Criteria

The most common mistake in platform selection is treating regulatory compliance as someone else's problem — assuming the platform operator has handled it. This assumption is almost always wrong. The platform operator may be regulated, but the specific offering you conduct, in the specific jurisdictions where your investors are located, with the specific asset type you are tokenizing, may generate regulatory obligations that sit with you as the issuer rather than with the platform. Legal due diligence on the platform's regulatory position must be conducted before any commitment is made.

Key Legal and Regulatory Criteria

1
Jurisdiction of the Platform Operator — Where Is It Regulated?

The platform operator's home jurisdiction determines the regulatory framework under which its licences are valid and the supervisory authority with oversight. A platform regulated in Luxembourg under MiFID II has passporting rights across the EEA; a platform regulated only in a third country may have no regulatory standing in Europe at all. Always verify: in which jurisdiction is the platform operator incorporated, where are its relevant licences held, and which Member States have specifically accepted its passported services?

Due diligence questions: What is the legal name and incorporation jurisdiction of the entity operating the platform? Which regulatory authority supervises it? Has it passported into the jurisdictions where your investors are located? Can you verify its licence status on the relevant public register?
2
Licences Held — Investment Firm, E-Money, CASP, or Other

Different tokenization activities require different licences. Offering tokenized securities to EU investors typically requires either an investment firm licence under MiFID II or an exemption (e.g. AIFMD-licensed manager for fund tokens). Operating a multilateral trading facility (MTF) for token secondary market trading requires a specific MiFID II licence. Providing custody of crypto-assets post-MiCA requires a CASP licence with the specific custodial services scope. The platform operator may hold some but not all of the licences your project requires.

Some platforms operate under a technology provider model — they provide the smart contract infrastructure and admin tools but are not themselves licensed to conduct regulated activities. In these cases, the issuer or a separately licensed intermediary must hold the required licences.

Due diligence questions: What investment firm, payment institution, e-money, or crypto-asset service provider licences does the platform hold? Which regulated activities is it authorised to perform? Which regulated activities does it expect the issuer or third parties to handle?
3
Securities Law Compliance — Are the Tokens Transferable Securities?

The fundamental legal question for any tokenization project is whether the tokens constitute transferable securities under MiFID II and the Prospectus Regulation, or crypto-assets regulated under MiCA, or neither. This classification determines: whether a prospectus is required; which disclosure and offering restrictions apply; what licences the issuer and the platform need; and what secondary market venues are legally available. A platform that assumes your tokens are MiCA crypto-assets when they are actually MiFID II transferable securities creates severe regulatory risk.

Due diligence questions: How does the platform characterise the legal nature of the tokens it issues? Has it obtained legal opinions on this characterisation for previous token issuances? Does it support prospectus-exempt issuances and, if so, under which exemptions (crowdfunding, Regulation A equivalent, private placement)?
4
KYC/AML Compliance Framework — Embedded or Outsourced?

Anti-money laundering and know-your-customer compliance is a legal obligation of the platform operator (if it is a regulated entity conducting customer due diligence) and potentially also of the issuer (if it is responsible for the investor relationship). Understand clearly: which entity bears AML/KYC obligations, what the platform's CDD standard is, and how ongoing monitoring is conducted. A platform that outsources KYC to a third-party provider without adequate oversight creates gaps in the AML framework that can result in regulatory liability.

Due diligence questions: Who is the MLRO for the platform operator? What are the platform's KYC tiers (basic CDD, enhanced due diligence for PEPs and high-risk clients)? Which identity verification providers does it use? How is ongoing transaction monitoring conducted?
5
Investor Eligibility Management — Retail, Professional, Qualified

Tokenized securities offerings in the EU are typically restricted to professional investors, eligible counterparties, or qualified investors — retail offerings require either a prospectus or a crowdfunding platform registration under ECSPR. The platform must support on-chain enforcement of investor eligibility: it is not sufficient to conduct KYC at onboarding and then allow free token transfer. Transfer to ineligible investors must be technically prevented, not merely contractually prohibited. A platform without on-chain transfer restrictions is inappropriate for regulated securities offerings.

Due diligence questions: How does the platform enforce investor eligibility restrictions at both onboarding and on secondary transfer? Are transfer restrictions enforced at the smart contract level, or only through contractual terms? What happens if an investor's eligibility status changes post-onboarding?
6
Prospectus, Offering Document, and Disclosure Support

Depending on the offering size, asset type, and investor base, the tokenization may require an EU prospectus, a DLT Pilot Regime registration, a crowdfunding offering information sheet, or a bespoke private placement memorandum. The platform should be able to accommodate the applicable disclosure framework — linking offering documents to the on-chain token record, managing subscription periods and caps, and supporting the documentary requirements of the target jurisdiction.

Due diligence questions: Has the platform previously supported prospectus-exempt offerings in your target jurisdiction? Does it integrate with the EU DLT Pilot Regime infrastructure? Does it maintain links between on-chain token records and off-chain legal documentation?
🇪🇺
MiCA and the CASP licensing requirement (from June 2024): under the Markets in Crypto-Assets Regulation (MiCA), any platform providing custody and administration of crypto-assets, operating a trading platform for crypto-assets, or receiving and transmitting orders for crypto-assets to or from EU clients must hold a CASP licence from 30 June 2024. However, MiCA explicitly excludes crypto-assets that qualify as financial instruments under MiFID II — including tokenized securities. If your tokens are transferable securities, MiCA does not apply, but MiFID II does. Platforms that market themselves as "MiCA-compliant" for all tokenization use cases without distinguishing MiFID II from MiCA instruments should be approached with caution.

Regulatory Coverage by Platform Type — Summary Matrix

📋 Typical regulatory coverage across common platform models
Licence / Coverage
Full-Stack Licensed Platform
Technology Provider Only
Crowdfunding Platform (ECSPR)
Bank-Backed Platform
MiFID II investment firm
✓ Usually held
✗ Not held
✗ Not held (ECSPR instead)
✓ Via parent bank
CASP (MiCA)
✓ If crypto-assets in scope
✗ Not held
✗ Likely not held
Varies — may apply
AML/KYC responsibility
✓ Platform bears primary obligation
Issuer must arrange separately
✓ Platform bears primary obligation
✓ Bank-level CDD
Custody licence
May be outsourced to third party
Not provided — arrange separately
Not typically provided
✓ Regulated bank-level custody
Prospectus / disclosure support
✓ Often included in service
Not provided
✓ Key Information Sheet (KIS) required
Varies by bank offering
Secondary market / MTF access
Sometimes — depends on platform
Not provided
Not typically provided
May have internal OTC desk

Section 3 — Blockchain Architecture and Smart Contract Criteria

The underlying blockchain is not just the technical infrastructure for a tokenization project — it is a strategic commitment that determines your token's interoperability, the cost and speed of transactions, the availability of secondary market venues, and the long-term security and upgradeability of the smart contracts that govern investor rights. A blockchain that is well-suited for decentralised finance applications may be entirely wrong for regulated security token issuance, and vice versa. Evaluate the blockchain architecture against the specific requirements of your asset class and investor base — not against general reputation or market capitalisation.

Blockchain Platform Comparison for Security Token Issuance

Ethereum (mainnet)
Public
Strengths
Largest developer ecosystem and tooling support; ERC-1400 and ERC-3643 security token standards are both native to Ethereum
Highest on-chain liquidity and broadest secondary market support for ERC-compatible tokens
Post-Merge proof-of-stake consensus — significantly reduced energy footprint; institutional-grade infrastructure providers (Infura, Alchemy)
Limitations
Gas fee volatility — transaction costs spike during periods of network congestion, making high-volume corporate actions (dividend distributions to many holders) expensive
Block finality time (~12 seconds) and probabilistic finality model may be suboptimal for settlement of high-value single transactions requiring absolute finality
Best suited for
Real estate tokens, private equity tokens, fund tokens requiring broad secondary market access and DeFi integration
Issuers who prioritise ecosystem breadth and secondary market liquidity over gas fee predictability
Polygon (PoS / zkEVM)
Public L2
Strengths
EVM-compatible — all Ethereum token standards work natively; Solidity smart contracts deploy without modification
Transaction fees orders of magnitude lower than Ethereum mainnet — cost-effective for high-volume corporate actions and distributions to large investor bases
Growing institutional adoption and several tokenization platforms have adopted Polygon as their primary or secondary chain
Limitations
Validator centralisation risk — the PoS chain has historically had a smaller and more concentrated validator set than Ethereum mainnet
Secondary market venue support is not as deep as Ethereum mainnet — fewer regulated trading venues have native Polygon support
Best suited for
High-volume tokenization (real estate fractions to retail investors, bond issuances with frequent coupon payments) where gas fee predictability matters
Stellar (XLM network)
Public
Strengths
Designed for financial assets — native multi-asset ledger, built-in DEX, and fiat anchor infrastructure. Strong track record for bond tokenization and cross-border payments
Federated Byzantine Agreement consensus delivers near-instant finality (3–5 seconds) with very low and predictable transaction fees
Limitations
Not EVM-compatible — cannot use Ethereum token standards. Smart contract functionality (Soroban) is newer and has a smaller developer ecosystem
Smaller secondary market ecosystem than Ethereum; fewer regulated venues with native Stellar support
Best suited for
Debt instrument tokenization (bonds, sukuk), cross-border settlement use cases, and tokenization projects where fast finality and low fees are paramount
Hyperledger Fabric / R3 Corda
Permissioned
Strengths
Transaction privacy by design — only the parties to a transaction see its details. Suitable for confidential financial transactions and GDPR-sensitive data
Institutional-grade permissioning — node operators are known, vetted entities. Governance and upgrade processes are controlled by the consortium
Limitations
No native secondary market — tokens cannot interact with public exchanges or DeFi. Liquidity requires a separately operated OTC desk or internal trading system
Interoperability with public chains requires bridge solutions that introduce additional technical and counterparty risk
Best suited for
Institutional-only tokenization (private credit, syndicated loans, inter-bank settlement) where privacy, permissioning, and absence of public chain exposure are priorities
Polymesh (security-token specific)
Purpose-built
Strengths
Built specifically for regulated securities — identity verification, compliance rules, and settlement finality are native protocol features, not add-on smart contract logic
Deterministic settlement finality and built-in corporate actions module (dividends, voting, corporate events) without requiring custom smart contract development
Limitations
Smaller ecosystem than Ethereum or Polygon — fewer third-party integrations, wallets, and secondary trading venues
Limited DeFi composability — not designed for interaction with public DeFi protocols
Best suited for
Issuers who want compliance and settlement built into the chain layer rather than relying on application-layer smart contracts for these functions

Smart Contract Security — Audit Requirements

🛡️ What to verify about a platform's smart contract security posture
Independent security audits: the platform's core smart contracts — including the token contract templates, compliance modules, and any proxy or upgradeability patterns — should have been audited by at least one independent, reputable blockchain security firm (e.g. Trail of Bits, Certik, OpenZeppelin, Hacken). Ask for the audit reports and review the findings and resolutions.
Upgradeability and governance: if the platform uses upgradeable smart contracts (e.g. a proxy pattern), understand who controls the upgrade keys, what governance process is required for an upgrade, and what happens to token holders if an upgrade is applied. Unilateral upgradeability by the platform operator creates significant counterparty risk for investors.
Forced transfer and recovery mechanisms: security token standards include forced transfer capabilities allowing a legally authorised party (e.g. a court order, regulatory action, or recovery of lost key) to move tokens without holder consent. Verify who holds this authority, under what conditions it can be exercised, and whether these conditions are documented in the investor-facing legal terms.
On-chain vs. off-chain data: understand what is stored on-chain (token ownership, transfer history, compliance flags) versus off-chain (investor identity documents, KYC records, offering documents). Off-chain data must be accessible and legally linked to on-chain records — a token with no verifiable connection to the underlying legal documentation is not a secure investment instrument.
Bug bounty programmes: mature platforms typically operate ongoing bug bounty programmes through platforms such as Immunefi or HackerOne. The existence of a well-funded, active bug bounty programme indicates both security maturity and the platform operator's ongoing commitment to smart contract integrity.
💱
Delivery vs. Payment (DvP) capability: for secondary market transactions in tokenized securities, regulators increasingly expect settlement to follow a DvP model — the transfer of the token (delivery) and the transfer of the payment occur simultaneously, eliminating the counterparty settlement risk that exists when the two legs of a trade settle at different times. Ask whether the platform supports atomic DvP settlement on-chain, and whether this is done through a regulated settlement infrastructure or through a custom smart contract mechanism. The EU DLT Pilot Regime specifically enables DLT market infrastructures to offer DvP settlement in central bank or commercial bank money alongside tokenized securities — check whether the platform participates in or is compatible with any DLT Pilot Regime infrastructure.

Section 4 — Token Standards, Asset Compatibility, and Secondary Market Access

The token standard chosen for a tokenization project determines what rights and restrictions can be enforced on-chain, how the tokens interact with secondary market venues, and what investor protections are technically embedded versus merely contractual. For regulated securities tokenization, the choice of token standard is a legal infrastructure decision as much as a technical one — a standard that cannot enforce transfer restrictions on-chain is fundamentally unsuitable for an offering restricted to qualified investors.

Security Token Standards — A Practical Comparison

ERC-20 — Fungible Token Standard
Not suited for regulated securities
What it does
The original Ethereum fungible token standard — defines a uniform interface for transferable, divisible tokens with a total supply, balance tracking, and basic transfer functions
Universal wallet and exchange support — every EVM-compatible wallet, DEX, and CEX can handle ERC-20 tokens natively
Critical limitations
No native transfer restrictions — any wallet can receive an ERC-20 token, making it impossible to enforce investor eligibility restrictions or lock-up periods at the token contract level without additional wrapper layers
No built-in compliance module, forced transfer, or document management — all must be added via separate smart contract logic
Use cases
Utility tokens, governance tokens, stablecoins, and DeFi protocol tokens — not regulated securities
Platforms using bare ERC-20 for security tokens should be treated as a red flag — compliance enforcement relies entirely on off-chain contractual terms
ERC-1400 / ERC-1643 / ERC-1644 / ERC-1410 — Security Token Standard Suite
Suitable for regulated securities
What it does
A modular suite of standards developed by Polymath and the security token community, extending ERC-20 with compliance-specific functions. Core components: ERC-1410 (partitioned token balances), ERC-1594 (core security token functions including issuance and forced transfer), ERC-1643 (document management — attaching legal docs to tokens), ERC-1644 (controller operations for forced transfers)
Strengths for compliance
On-chain document linking via ERC-1643 — the token contract can reference and hash offering documents, providing an immutable audit trail connecting each token to its legal instrument
Forced transfer (ERC-1644) allows a designated controller to move tokens without holder consent — supporting court orders, regulatory requirements, and recovery scenarios
Issuance control and transfer restriction hooks — transfers can be validated against an external compliance registry
Limitations
Compliance logic is external — the standard provides hooks for an external compliance registry but does not define the identity verification standard itself. Each platform implements this differently
Interoperability between platforms using different ERC-1400 implementations is not guaranteed
ERC-3643 / T-REX (Token for Regulated EXchanges)
Preferred for EU regulated securities
What it does
Developed by Tokeny Solutions and adopted as an Ethereum Improvement Proposal (ERC-3643). Goes beyond ERC-1400 by integrating an on-chain identity registry (ONCHAINID) directly into the compliance architecture. Each investor is represented by a blockchain-based identity (ONCHAINID) that holds verified claims (KYC status, investor category, jurisdiction) issued by trusted claim providers
Key advantages
Compliance by design — transfer restrictions are enforced by a modular compliance contract that checks the ONCHAINID of both sender and receiver against the applicable rules before every transfer
Multi-jurisdiction compliance rules can be encoded as separate modules — the same token can simultaneously enforce US accredited investor rules and EU professional investor rules for different holder populations
Growing adoption among EU tokenization platforms and regulated securities venues
Considerations
ONCHAINID ecosystem dependency — the compliance architecture relies on the ONCHAINID identity standard. Interoperability with platforms using different identity standards requires bridging
More complex to deploy and operate than ERC-1400 — requires identity registry infrastructure in addition to the token contract suite
ERC-1155 — Multi-Token Standard
Asset-specific use cases only
What it does
A hybrid standard that supports both fungible and non-fungible tokens within a single contract — enabling efficient multi-asset management, batch transfers, and fractional representation of unique assets
Tokenization use cases
Suitable for real estate tokenization where each property is a distinct non-fungible asset but investor shares within each property are fungible
Art and collectible tokenization — fractional ownership of unique assets
Limitations
No native securities compliance layer — requires additional compliance logic. Not widely adopted by regulated tokenization platforms for securities offerings

Asset Class Compatibility — What Each Platform Typically Supports

🏛️ Asset classes commonly supported by tokenization platforms
🏢
Real Estate
Fractional ownership of commercial, residential, and development properties. SPV or REIT-wrapper structures. Most common tokenization use case globally.
📈
Private Equity & Venture Capital
LP interest tokenization, fund unit tokenization, carried interest structures. Typically professional-investor-only offerings with strict transfer restrictions.
📄
Bonds and Debt Instruments
Corporate bonds, green bonds, sukuk, and structured notes. Coupon payments automated via smart contract. Strong regulatory framework in most jurisdictions.
🌾
Commodities and Natural Resources
Gold, carbon credits, agricultural products, and mineral rights. Platform must link the on-chain token to a verifiable physical custody or registry record.
🎨
Art and Collectibles
High-value unique assets. Insurance, provenance documentation, and physical custody are critical dependencies. Regulatory treatment varies — may be MiCA or MiFID II depending on structure.
Infrastructure and Energy
Renewable energy projects, infrastructure PPPs, toll roads. Long-term income-producing assets suited to tokenized bond or equity structures with automated revenue distribution.
🏛️
Secondary market access — the most underestimated criterion: issuing tokens is only half the value proposition of tokenization. Investors need a way to exit — and the existence of a liquid, regulated secondary market for your tokens is critical to investor confidence and to the token's valuation premium over illiquid alternatives. Ask every platform: which regulated secondary trading venues (MTF, ATS, or DLT Pilot Regime market infrastructure) will accept your token for trading? Does the platform have formal listing agreements with these venues, or is secondary market access theoretical? A platform that cannot demonstrate a credible secondary market pathway should be treated as a significant limitation, particularly for real estate and private equity tokens where investors historically have no exit other than the token itself.

Section 5 — Custody, KYC/AML Integration, and Investor Management

The operational infrastructure of a tokenization platform — how it safeguards the private keys that control token issuance, how it verifies and monitors investors, and how it manages the cap table and corporate actions over the life of a token — determines the day-to-day security and investor experience of the project. Weaknesses in custody, KYC, or investor management do not generate regulatory problems immediately; they create time-bombs that detonate when a key is lost, a sanction is missed, or a dividend distribution goes wrong. Evaluate these operational dimensions with the same rigour as licensing and technical architecture.

Custody Models — How Token Issuance Keys and Underlying Assets Are Safeguarded

Tokenization involves two distinct custody considerations: custody of the blockchain private keys that control smart contract functions (minting, burning, forced transfers, pausing), and custody of the underlying real-world asset (the property, the equity stake, the bond, the commodity) whose ownership is represented by the token. Both must be evaluated separately.

Model A
Self-Custody by Platform Operator
The platform operator holds and manages the smart contract administrative keys — typically using multi-signature wallets with hardware security module (HSM) backing
Simpler operational model — one entity is accountable for key security
Risk: platform operator is a single point of failure. Insolvency, regulatory action against, or technical compromise of the platform operator could freeze or destroy token management capability
Key question: what is the key recovery procedure if the platform operator becomes unavailable?
Model B
Third-Party Regulated Custodian
A separately regulated crypto-asset custodian (CASP, MiFID II investment firm with custody scope, or bank) holds the smart contract keys and the underlying asset in segregated accounts
Provides regulatory-grade asset segregation — in the event of platform operator insolvency, custodied assets are ring-fenced from the operator's estate
May provide insurance coverage for custodied digital assets and underlying real-world assets
Added complexity: two service provider relationships to manage; custodian integration must be technically seamless with the tokenization platform
Model C
Bank-Integrated Custody
A bank (acting as both custodian and tokenization platform operator, or as the platform's banking partner) holds underlying assets in trust or custodial accounts under its banking licence
Typically the highest regulatory comfort level — bank-level segregation, existing depositor protection frameworks (where applicable), and established AML/KYC infrastructure
Most suitable for tokenized bonds, tokenized fund units, and tokenized structured products where institutional investor confidence in the custody model is critical
Limitation: typically less flexible in terms of blockchain choice and token standard — bank platforms often use proprietary chains with limited secondary market interoperability

KYC/AML Integration — What to Evaluate

🪪 KYC/AML framework evaluation criteria
🔍
Identity verification provider and CDD standard: identify which third-party KYC provider the platform uses (e.g. Onfido, Jumio, Sumsub, Veriff) and what level of customer due diligence it conducts — simplified CDD, standard CDD, or enhanced due diligence for high-risk clients (PEPs, high-risk jurisdictions, large investment amounts). The CDD standard must match the investor risk profile of your offering.
🌍
Jurisdiction coverage: the platform's KYC framework must be capable of processing investors from the jurisdictions you intend to target. Some platforms have whitelist-only jurisdiction coverage — verify that your target investor markets are included and that the CDD approach is appropriate for each jurisdiction's risk rating under FATF guidelines.
📡
Ongoing transaction monitoring: KYC at onboarding is a minimum — a robust AML framework requires ongoing transaction monitoring to detect unusual patterns (layering, structuring, unexplained transaction volumes). Ask whether the platform uses automated transaction monitoring software and how alerts are escalated to the MLRO for investigation and potential suspicious activity reporting.
🔄
Periodic CDD refresh: KYC records go stale. A robust platform implements periodic refresh cycles — typically annual for standard clients and more frequent for high-risk clients — to ensure that investor identity documents, source of funds information, and sanctions screening remain current. Verify that the platform has a documented refresh procedure and that the on-chain compliance status is updated when a refresh is completed.
🚨
Sanctions screening and PEP lists: the platform must screen all investors against current sanctions lists (EU, UN, OFAC, UK) and politically exposed person databases at onboarding and on an ongoing basis. Verify which screening provider is used, how frequently screening is refreshed, and what the escalation procedure is when a match is identified. A platform that screens only at onboarding creates ongoing sanctions exposure for the issuer.

Investor Management and Corporate Actions

Over the life of a tokenized asset, the platform must support the full spectrum of investor management activities — from cap table maintenance through to dividend distributions, voting events, redemptions, and buybacks. Evaluate whether these functions are automated on-chain, semi-automated with manual sign-off, or entirely manual. Manual corporate action processing at scale is error-prone and defeats a core efficiency benefit of tokenization.

📊
Cap Table Management
The on-chain token ledger is the cap table. Verify that the platform provides real-time cap table views, investor portal access, and exportable cap table records in formats required for regulatory reporting and corporate governance.
💰
Dividend and Distribution Automation
Smart contract-based distribution calculates each token holder's entitlement and pushes payment in the same transaction — typically in stablecoin or fiat via a payment rail integration. Verify whether distributions require manual trigger or are fully automated on schedule.
🗳️
Investor Voting and Governance
For equity and fund tokens, investor voting rights must be exercisable. Some platforms offer on-chain governance modules; others support off-chain voting with on-chain result recording. Verify that the voting mechanism produces a legally binding record of investor decisions.
🔁
Redemption and Buyback Mechanics
The platform must support token buyback and redemption — burning tokens returned to the issuer and releasing the corresponding underlying asset value. Verify that the token burn process is automated and that the redemption schedule (notice period, settlement terms) is enforceable through the smart contract.
📬
Investor Communications
Regulatory requirements for investor communications (annual reports, NAV updates, material events, corporate action notices) must be met. Verify that the platform supports compliant communications workflows and that notices can be delivered both on-chain (as document hashes) and through conventional channels.
🔧
Post-Issuance Structural Changes
Token splits, consolidations, conversions (debt-to-equity), and merger scenarios all require platform support. Verify that the platform has handled these events for previous issuances and that the smart contract architecture supports the relevant corporate action without requiring a full token migration.

Section 6 — Due Diligence Checklist, Red Flags, and Platform Selection Framework

The criteria set out in the preceding sections provide the analytical framework for platform evaluation. This final section consolidates that framework into a practical ten-point due diligence checklist, highlights the red flags that should cause you to reconsider or reject a platform, and sets out a five-step selection process that structures the decision from initial longlist to final commitment. Legal review should be a component of each step, not a final sign-off once the commercial decision has already been made.

Ten-Point Due Diligence Checklist

1
Verify the platform operator's regulatory status on the official register
Do not rely on the platform's own marketing materials. Search the register of the relevant national competent authority (e.g. BaFin, AMF, CBI, FCA, CSSF) for the platform operator's legal name and confirm the licences and authorised activities shown on the register match what the platform claims. A discrepancy between marketing and the register is a fundamental red flag.
2
Obtain and review previous issuance references — legal opinions and regulatory filings
Ask for references from at least two previous issuers who have completed a tokenization with a similar asset type and investor profile. Request copies of the legal opinions obtained for those issuances (with commercially sensitive information redacted if required) to assess the quality of the regulatory analysis the platform supported. Review any public regulatory filings or ESMA databases for previous DLT Pilot Regime registrations.
3
Review smart contract audit reports — all findings and resolutions
Request the most recent independent smart contract audit reports for the token contract templates, compliance modules, and any proxy or upgradeability contracts used for your issuance. Review both the findings and the resolutions — an audit with no findings is not necessarily credible; a report with critical findings that were remediated is acceptable if well-documented. Unresolved high-severity findings are a disqualifying factor.
4
Confirm on-chain transfer restriction enforcement — test it
Do not accept the platform's assurance that transfer restrictions work as described. Request access to a testnet environment and attempt to transfer tokens to a wallet not on the whitelist. Confirm that the transfer fails at the smart contract level — not merely that a contractual prohibition exists. Compliance-by-contract is not compliance-by-design.
5
Identify the custodian and verify its regulatory status independently
Establish clearly who holds the smart contract administrative keys, who holds the underlying asset, and in what legal capacity. Verify the custodian's regulatory status independently — for crypto-asset custodians, confirm CASP authorisation post-MiCA; for bank custodians, confirm banking licence and account segregation structure. Request the custodian's most recent independently audited financial statements.
6
Map the KYC/AML chain of responsibility
Produce a written map of who is responsible for each AML/KYC obligation in your specific offering structure: the platform, the issuer, an intermediary, or a combination. Gaps in this map represent regulatory liability. Confirm that the platform's CDD standard is appropriate for the risk profile of your investor base and the FATF risk rating of the jurisdictions in which you will offer.
7
Confirm secondary market venue integration — in writing
Obtain written confirmation (not a verbal representation) that the platform's token standard and technical architecture are compatible with at least one regulated secondary trading venue (MTF, ATS, or DLT Pilot Regime market infrastructure) that has confirmed willingness to list your token. A platform that cannot provide this confirmation in writing has an unverified secondary market claim.
8
Understand the off-chain documentation architecture
Confirm how the on-chain token record is legally connected to the underlying real-world asset. Understand: which legal entity holds the asset; what the legal instrument is (trust deed, SPV shareholding, registered title, book-entry record) that establishes the token holder's right to the underlying; and how on-chain token ownership translates to an enforceable legal claim in the governing jurisdiction. A token without a legally enforceable link to the underlying asset is a digital claim with no legal substance.
9
Evaluate platform financial stability and business continuity
Review the platform operator's most recent financial statements or investor deck. Assess runway and revenue model — a tokenization platform dependent on a single revenue stream or with limited runway creates operational risk for the life of your token issuance, which may extend 5, 10, or more years. Understand the business continuity plan: what happens to your tokens and your investors if the platform operator ceases operations? This question should be answered in the platform service agreement.
10
Negotiate platform service agreement terms — exit rights and data portability
The platform service agreement must address: data portability (your right to export cap table data, investor records, and smart contract code if you change platforms); exit rights (your right to terminate and migrate to another platform); intellectual property in custom smart contracts; liability caps and indemnity for platform failures; and SLA commitments for system availability during critical periods (offering windows, distribution dates, AGM dates). Never proceed on a platform's standard terms without legal review.

Red Flags — When to Reconsider or Reject a Platform

🚩
Cannot confirm regulatory status on official register

If the platform's legal entity cannot be found on the relevant national competent authority register, or if the registered activities do not match what the platform claims to offer, do not proceed. This is the most fundamental disqualifying factor.

🚩
Uses bare ERC-20 for regulated securities

Any platform proposing to issue regulated securities using the standard ERC-20 token without compliance extensions is not suitable for a regulated offering. Transfer restriction enforcement at the smart contract level is non-negotiable for investor-restricted securities.

🚩
No independent smart contract audit

A platform that cannot provide independent audit reports for its smart contract codebase has unverified security claims. Self-certification or internal reviews are not equivalent to independent third-party security audits.

🚩
No credible secondary market pathway

If the platform cannot provide written confirmation of secondary market venue integration or a viable liquidity pathway, the investment proposition for your token is severely compromised. Promises of "future exchange integration" are not a substitute for a verified existing relationship.

🚩
Vague or non-existent business continuity plan

A platform that cannot clearly articulate what happens to investor assets, token administration, and corporate actions if the platform operator fails is exposing your investors to unquantified operational risk. Business continuity terms must be written into the service agreement, not left to verbal assurances.

🚩
Refuses to provide reference issuers or redacted legal opinions

A platform with a genuine track record of compliant issuances will be able to provide references. Refusal — even with confidentiality arguments — suggests either a limited track record or previous issuances with unresolved regulatory issues.

The 5-Step Platform Selection Process

1
Define your asset, investor profile, and regulatory framework before engaging any platform
Before approaching any platform, determine: the asset class and legal structure of the underlying; the target investor base (institutional, professional, retail — and their jurisdictions); the applicable regulatory framework (MiFID II transferable securities, MiCA crypto-asset, AIFMD fund token, or crowdfunding ECSPR); and the intended secondary market. These parameters determine which platforms are legally suitable — engaging platforms without them inverts the selection process.
2
Build a longlist using regulatory registers and market references — not marketing materials
Identify candidate platforms using national competent authority licence registers (filtered by relevant licence types), legal advisor networks, and institutional investor references. Exclude any platform that cannot be found on a regulatory register from your longlist immediately. Target 5–8 candidate platforms at this stage.
3
Issue a structured RFP covering all six evaluation dimensions
Send a formal request for proposal to your longlist platforms covering each of the six evaluation dimensions from Section 1 of this guide: regulatory, blockchain architecture, token standard, custody, KYC/AML, and secondary market. Require written responses with documentary evidence (audit reports, licence certificates, reference contacts). Score responses systematically — not on the quality of the sales pitch.
4
Conduct technical and legal due diligence on the shortlist (2–3 platforms)
Apply the ten-point checklist to your shortlisted platforms. Engage independent legal counsel to review the platform service agreement, the smart contract architecture, and the regulatory analysis for your specific offering. Run testnet tests for transfer restriction enforcement. Speak with reference issuers and, where possible, investors who have participated in previous platform issuances. Budget 4–8 weeks for this phase — it cannot be rushed.
5
Negotiate and execute the platform service agreement — with legal review of every clause
The platform service agreement is the foundational legal document of your tokenization project. Negotiate exit rights, data portability, liability caps, SLA commitments, audit rights, and business continuity terms before execution. Never sign a standard-form platform agreement without legal review — the default terms in most platform agreements favour the platform operator, not the issuer or the investors.
🔗 Asset Tokenization Legal Advice

Need legal guidance on your asset tokenization platform selection and structuring?

Choosing the right tokenization platform is a legal and regulatory decision as much as a technical one. Our tokenization law practice advises asset managers, real estate developers, fund managers, and corporate issuers on the full platform selection and due diligence process — from initial regulatory framework analysis and asset structuring through to smart contract review, offering document preparation, and secondary market access strategy. We work across EU, UK, and international tokenization jurisdictions and across all major asset classes.

Speak to our Tokenization Team →

Oleg Prosin is the Managing Partner at WCR Legal, focusing on international business structuring, regulatory frameworks for FinTech companies, digital assets, and licensing regimes across various jurisdictions. Works with founders and investment firms on compliance, operating models, and cross-border expansion strategies.