The RWA Tokenization Platform Checklist: 8 Factors for EU Issuers

An RWA tokenization platform is a software, typically whitelabel, that handles issuance, lifecycle servicing, and transfer of tokens representing real-world assets, with regulatory wrappers (eWpG, DLT Pilot Regime, ECSPR) built into the issuance flow, an identity layer (typically ONCHAINID), a custody integration, a technical standard (ERC-3643 or ERC-1400), and a route to secondary liquidity through regulated DLT venues. The platform sits between the issuer's regulatory perimeter and the on-chain settlement layer.

The 8 factors for EU issuers, at a glance

Before any demo, an EU issuer should be able to answer eight questions about a tokenization platform. Each factor carries a disqualifier: fail it, and the platform comes off the shortlist.

1. Jurisdictional fit - which EU regime (MiFID II, eWpG, DLT Pilot Regime, ECSPR) does the issuance flow operate under?

2. Asset-class fit - has the platform closed reference deals in your asset class and jurisdiction?

3. Technical standard - ERC-3643 or ERC-1400, and why?

4. Custody integration - who is the licensed custodian in your jurisdiction, separate from the wallet technology?

5. Secondary market access - is there an integration path to a DLT Pilot venue (21X, CSD Prague, 360X)?

6. Identity and KYC architecture - is KYC reusable across issuances?

7. Deployment speed and customisation - weeks, not months?

8. Total cost and licensing model - is cost clear across setup, per-issuance, and ongoing servicing?

Factor 1 - Jurisdictional fit: which EU regulatory regime applies to your tokenized asset, and why does that decide the platform?

The platform that fits MiFID II does not fit eWpG, and the platform that fits eWpG does not fit the DLT Pilot Regime, so the regime of the asset is the first filter, not the last. Issuers who reverse this order, picking a platform on UI and then asking which regime it operates under, often find their shortlisted vendor licensed against the wrong rulebook. Four regimes matter: MiFID II, eWpG, the DLT Pilot Regime, and ECSPR.

MiFID II - The EU's core rulebook for traditional financial instruments: shares, bonds, fund units, derivatives. It governs how they're issued, traded, and who's licensed to deal in them. This is the lane most tokenized real-world assets actually fall into

eWpG, Germany's law letting a security exist as an electronic register entry instead of paper. It's what makes German tokenized securities legally real, and it creates a BaFin-licensed "crypto-securities register operator" role (€150k capital) that someone in your chain must hold.

The DLT Pilot Regime The DLT Pilot Regime is an EU experiment that lets financial markets try running on blockchain ("distributed ledger technology") instead of the traditional plumbing, without breaking the existing rulebook.

ECSPR The EU's crowdfunding rulebook: many small investors backing or lending to a project, capped at €5M per 12 months. Fits crowdfunding-shaped raises, not fund or bond issuance.

The practical consequence: a Singapore-MAS-tuned or US Reg-D-tuned platform cannot run an eWpG crypto-securities register, cannot list on a DLT Pilot venue, and cannot operate as an ECSP. If your platform's pitch deck does not name the regime it operates under, that is the answer. Issuers comparing the top white-label tokenization platforms in the EU should read each vendor's regulated infrastructure for tokenized securities page and ask which EU registration the vendor holds.

Comparison: the four EU regimes for tokenized real-world assets

Factor 2 - Asset-class fit: does the platform fit the asset class you are tokenizing?

No tokenization platform is asset-class neutral in practice: different asset classes trigger different regulatory wrappers, custody models, and transfer logic, so "we can tokenize anything" is a marketing line, not an operating posture. The starting point for a platform conversation is the named reference deals the vendor has closed in your asset class and your jurisdiction, not the feature inventory.

Where institutional volume actually sits is visible on RWA.xyz: distributed tokenized-asset value on public blockchains is $31.55B as of 26 June 2026, with tokenized US Treasuries alone at $13.4B and six categories above $1B (private credit, commodities, US Treasuries, corporate bonds, non-US government debt, institutional alternative funds).
as represented below on Total RWA Value

Each asset class routes through different infrastructure.

1. EU real estate - ERC-3643 wrapped under eWpG, with a crypto-securities register operator and a licensed bank custodian.

2. Private credit & tokenized treasuries - routes through MiFID II or DLT Pilot rails, depending on whether the instrument qualifies as a financial instrument.

3. Fund tokens (AIFs & UCITS) - sit under MiFID II plus AIFMD (for AIFs) or UCITS.

4. Bonds - clear EU reference point: KfW's €100M digital bond (2024), with Hauck Aufhäuser Lampe Digital Custody as crypto custodian, anchored under eWpG.

A recent example from the ONINO whitelabel pipeline makes the asset-class gating explicit.

An agricultural land venture outside the EU evaluated whitelabel infrastructure specifically to avoid a multi-year in-house build. The filter for that issuer was not UI quality or even cost - it was whether candidate platforms could handle non-EU asset provenance with EU-style investor protections. That filter knocked out several Singapore- and US-tuned vendors before any technical demo ran.

The same asset-class filter applies in reverse to EU real-estate developers and fund managers. The disqualifier is not "the platform cannot tokenize real estate." The disqualifier is "the platform has never tokenized real estate under the regulatory wrapper you actually operate under" - which for EU real estate is usually eWpG or its national equivalent.

Factor 3 - Technical standard: ERC-3643 or ERC-1400, which should your tokens use?

ERC-3643 (T-REX): compliance built into the token - transfers are checked on-chain against the recipient's verified identity, so ineligible transfers just fail. Standard for most EU regulated issuance.

ERC-1400: older standard for partitioned securities (tranches with different rights). Compliance checks mostly happen off-chain. Used when tranche-level structuring matters more than on-chain identity checks.

For EU issuers in 2026, ERC-3643 (T-REX) is the dominant choice because ERC-3643 bakes identity-driven transfer compliance into the token itself, while ERC-1400 remains a useful interface family for partitioned securities. The ERC-3643 ecosystem reports $32B+ tokenized across 200+ deployments in 180+ jurisdictions, with governance held by the ERC-3643 Association (members include DTCC, Apex Group, Invesco). ERC-1400's installed base is smaller and skews toward issuers who need partition-level corporate actions across multiple tranches.

The mechanism that distinguishes the two standards is identity. ERC-3643 uses ONCHAINID as an on-chain identity layer, so transfer rules are evaluated against the recipient's verified identity attributes at transfer time. ERC-1400 is an interface family (ERC-1410, ERC-1594, ERC-1643, ERC-1644) that partitions a security into tranches with distinct rules per tranche, but most ERC-1400 compliance checks remain off-chain. For EU regulated issuance, where investor eligibility (qualified vs retail, jurisdiction of residence, KYC refresh status) drives most of the transfer logic, on-chain checks through ERC-3643 are the more reliable pattern. The mechanics are covered in creating compliant security tokens with ERC-3643 (T-REX).

Choosing between the two main token standards comes down to what your issuance needs to do.

Pick ERC-3643 if transfers need to be controlled based on who the investor is - for example, only letting people trade if they've passed identity checks (KYC) and are in an approved jurisdiction. This covers most regulated issuance in the EU.

Pick ERC-1400 if you're issuing a single security that's split into tranches with different rules - say, several classes that each have their own redemption rights. This standard handles corporate actions at the tranche level.

When evaluating a platform, watch for two red flags. First, if a vendor can't clearly explain which standard fits your situation and why, that's a problem. Second, be wary of anyone pushing their own proprietary standard that no one else in the market actually uses.

A good way to test a vendor: ask them to walk you through exactly what happens when someone tries to receive tokens but their identity verification has expired, or they're in a country outside the issuer's approved list. A capable vendor should be able to explain how the transfer gets automatically blocked.

Factor 4 - Custody integration: which custodian holds the token, and is that custodian licensed where your investors are?

Custody is two decisions, not one. Separate the wallet technology (MPC infrastructure like) from the licensed custodian on record with your regulator. Strong wallet infra with no supervised custodian is a common gap - and under EU investor-protection rules, segregated, supervised custody isn't optional. The test: ask the platform to name its licensed custodian for your jurisdiction, not "do you do custody.

Factor 5 - Secondary market access: after issuance, where will your investors actually trade these tokens?

Tokenized securities do not trade themselves; tokenized securities trade on regulated DLT venues, the EU now has live ones, but the issuer's platform has to be wired into them. ESMA's Article 14 report under the DLT Pilot Regime (June 2025) names three formally authorised venues operating across the EU.

The three named DLT market infrastructures are:

1. 21X AG – authorised as a DLT Trading and Settlement System on 3 December 2024, live since 8 September 2025 with atomic on-chain settlement of tokenised stocks, bonds, and funds.

2. CSD Prague – authorised as a DLT Settlement System on 11 October 2024.

3. 360X AG – authorised as a DLT Multilateral Trading Facility on 29 April 2025.

ESMA's Article 14 recommendation is to make the regime permanent rather than let it expire.

Adjacent venues that EU issuers regularly route through include:

• SDX (SIX Digital Exchange, Switzerland) – CHF 2B+ tokenised securities

• Archax (FCA-registered, UK)

• BX Digital (Switzerland)

The platform-side question is connectivity, not listing. Does the issuer's tokenization platform issue tokens that can settle on these venues, or does the platform operate as a walled garden in which liquidity events have to be manually unwound and re-issued? The disqualifier is not that the platform lacks integration with all six venues, which would be unrealistic; the disqualifier is no integration path to any of them. Issuers planning secondary liquidity from day one should read EU secondary markets for tokenized securities and ask each platform for a written settlement diagram.

Factor 6 - Identity and KYC architecture: how does the platform onboard and re-use investor identity?

The final three factors decide the rest once regime, asset, standard, custodian, and venue are settled. None is decisive in the same way as regime or custodian, but each quietly kills issuances that survived the first five filters.

Identity and KYC architecture is the operational backbone of every ERC-3643 deployment. The pattern to look for is reusable KYC: an investor onboarded once at the platform level can transact across multiple issuances without re-running the full KYC and AML check each time, with refresh cadences defined per jurisdiction and investor type. Platforms that re-onboard every investor for every issuance impose a friction tax that compounds across the lifetime of the platform.

Factor 7 - Deployment speed and customisation: how fast can the platform go live under your brand?

Deployment speed separates whitelabel infrastructure from an in-house build: in-house builds run 12 to 24 months and seven-figure capex, while whitelabel deployments compress that to weeks. Vendors quoting timelines in months rather than weeks, without naming a reason, fail this factor; ONINO's view on going live in weeks rather than months sets the reference expectation.

Factor 8 - Total cost and licensing model: what does the platform cost across its lifetime?

Cost is the last factor: setup fee, monthly platform fee, per-issuance fee, gas pass-through, lifecycle servicing fees. Issuers consistently under-estimate ongoing servicing cost relative to one-off issuance cost, which distorts shortlists where the cheapest setup fee hides the most expensive multi-year cost. The build vs. buy decision for issuance platforms covers the trade-off in more depth.

The ONINO 8-Factor Tokenization Platform Evaluation Framework

The eight factors below are the operational checklist ONINO uses with issuer-side clients evaluating whitelabel infrastructure. Each factor carries a disqualifier rule. If a candidate platform fails the disqualifier on any factor, the platform comes off the shortlist before the demo. Use this framework against ONINO's whitelabel tokenization platform or any other vendor on equal terms.

1. Jurisdictional fit. Disqualifier: the platform cannot name the EU regime its issuance flow operates under, or names a non-EU regime as a substitute.

2. Asset-class fit. Disqualifier: the platform pitches as "asset-class neutral" without naming reference deals in your specific class and jurisdiction.

3. Technical standard. Disqualifier: the platform cannot articulate the ERC-3643 versus ERC-1400 choice in your specific issuance context, or pitches a proprietary standard with no ecosystem traction.

4. Custody integration. Disqualifier: the platform conflates MPC wallet technology (Fireblocks, Anchorage) with licensed custody (Hauck Aufhäuser Lampe, Taurus), or cannot name a licensed custodian in your jurisdiction.

5. Secondary market access. Disqualifier: the platform has no integration path to any DLT Pilot venue (21X, CSD Prague, 360X) or adjacent venue (SDX, BX Digital, Archax).

6. Identity and KYC architecture. Disqualifier: KYC is not reusable across issuances, so each new issuance re-onboards the same investors.

7. Deployment speed and customisation. Disqualifier: whitelabel timeline is quoted in months rather than weeks, with no specific reason named for the longer timeline.

8. Total cost and licensing model. Disqualifier: cost is quoted only as a one-off setup fee, with no clarity on per-issuance and ongoing servicing fees.

Across ONINO's whitelabel pipeline of approximately 20 active issuer evaluations over the last 12 months, the first two or three platforms on a shortlist are typically disqualified on Factors 1, 2, or 4, not on UI or UX. Jurisdictional fit, asset-class fit, and custody are the load-bearing filters; everything downstream is solvable once those three are clean.

Evaluate ONINO against your 8-factor checklist

Evaluate ONINO's whitelabel platform against your 8-factor checklist. Book a 30-minute scoping call with our team to map the framework to your asset class and jurisdiction.

Book a demo → onino.io/book-a-demo

About the author: Kristina Stark is Growth Manager at ONINO, leading marketing, content, and sales across the German and UK markets. Her work focuses on educating on tokenization infrastructure, regulated digital issuance, and how European issuers reach retail investors under MiFID II, PRIIPs, and the EU Listing Act. Kristina studied Business Management and Digital Innovation & Entrepreneurship at City, University of London. LinkedIn: linkedin.com/in/kristina-stark-1b760b1bb.

This article is for general information only and does not constitute legal advice.

Last reviewed by Lukas Wipf CPO & Co-Founder at ONINO, 26 June 2026.