Should You Build or Buy a Tokenization Platform?

For financial institutions and asset managers entering the tokenization market, the infrastructure decision is often the first major strategic fork. Build a proprietary stack, and you own the architecture. Buy a white-label platform, and you reach market in weeks. Neither path is inherently superior, but in the EU regulatory environment the cost of getting this decision wrong is significant.

In short: building in-house is viable for large institutions with existing DLT teams and regulatory licences. For most issuers, deploying on an existing white-label platform is the operationally realistic path to market under MiCA, MiFID II, and the DLT Pilot Regime.

A note on language before we start. "Buy" is slightly misleading in regulated infrastructure. Deploying on an existing platform is not a software purchase; it is an operational decision to run on proven, pre-integrated, compliance-ready infrastructure rather than build, license, and maintain the equivalent yourself. The licensed functions still sit with licensed partners or with you as the issuer, never with the software vendor.

What Does a Full Tokenization Stack Actually Include?

Before comparing the two paths, it helps to understand what "tokenization infrastructure" actually means. A complete stack is not just smart contract deployment. It covers:

• Token issuance logic: rules governing how securities are created, transferred, and redeemed

• Investor onboarding: KYC/AML pipelines, investor classification under MiFID II

• Smart contract management: upgrades, audits, corporate action automation

• Custody integration: connection to regulated custodians or CSDs

• Cap table administration: real-time register of token holders

• Regulatory reporting: transaction reporting, prospectus thresholds, DLT Pilot compliance

• Secondary market connectivity: access to liquidity venues or bilateral transfer mechanisms

Each component must meet the legal requirements of every jurisdiction where securities are issued and held. This is not a software problem. It is a legal-engineering problem.

Build vs. Buy at a Glance

The Real Cost of Building From Scratch

Most technical decision-makers who have built SaaS or enterprise software underestimate the cost of a regulated financing platform, because the hidden cost drivers sit outside standard software engineering. The primary categories are not compute, storage, or development hours. They are legal structuring, regulatory licensing, compliance infrastructure, and ongoing audit burden.

It helps to separate the build into five distinct layers, each of which must be addressed before a single investor can onboard:

The total first-year cost of a compliant tokenization build in the EU typically falls between €600,000 and €2 million, before any revenue is generated. That estimate excludes opportunity cost (revenue foregone during a 12 to 24 month build) and team hiring, which for compliant financial infrastructure generally requires at least one senior compliance officer, two to three backend engineers with financial-systems experience, and ongoing legal counsel.

The engineering components, while significant, are the most predictable part of this cost structure. Regulatory licensing and legal structuring carry the highest variance, because they depend on jurisdiction, instrument type, investor base, and the regulatory posture of the relevant authority at the time of application.

According to BankingHub's Digital Assets Study, over 40% of institutions surveyed expect cost savings of 25% when issuing tokenised assets, but those savings assume functioning infrastructure, not the cost of building it.

The Case for Building In-House

When it makes sense

Building a proprietary tokenization stack is defensible under a specific set of conditions:

• The institution already holds relevant EU regulatory licences (for example MiFID II authorisation, crypto custody licence)

• There is an established blockchain engineering team with securities-law expertise

• The investment horizon is three to five years before production

• The institution intends to offer tokenization as a service to external clients, meaning the proprietary stack is itself a commercial product

Large banks and financial-market infrastructure providers sometimes fall into this category. For them, owning the infrastructure layer creates a competitive moat and enables downstream revenue from third-party issuers.

What you gain

• Full architectural control: token standards, chain selection, data architecture

• Independence from vendor roadmaps: no dependency on third-party release cycles

• White-label revenue potential: the ability to onboard external issuers on proprietary infrastructure

What it costs

Beyond the euro figures above, a compliant EU build requires securities lawyers and regulatory counsel specialising in DLT, direct engagement with national competent authorities and ESMA for DLT Pilot Regime authorisation, parallel operation of legacy and DLT infrastructure during transition, and ongoing compliance maintenance as MiCA delegated acts and DLT Pilot guidance evolve.

The Case for Buying a White-Label Platform

For most issuers, the buy path is not a compromise. It is the correct strategic choice when:

• The goal is to issue a tokenized product, not to build infrastructure

• Internal resources are better deployed on asset structuring, investor relations, and distribution

• Time-to-market matters (regulatory windows, investor pipeline, competitive pressure)

• The institution lacks in-house DLT expertise or regulatory pre-authorisation

This applies to the majority of EU market participants: asset managers launching tokenized funds, real estate firms structuring digital securities, SMEs seeking ECSP-regulated alternative financing, and banks looking to pilot tokenization without a multi-year build programme.

What you gain

• Speed: production-ready in weeks, not years

• Compliance continuity: the platform and its partners absorb the cost of MiCA updates, DLT Pilot guidance changes, and regulatory reporting adjustments

• Pre-integrated partners: custodians, payment institutions, KYC providers, and secondary-market venues already connected, so you do not have to source them

• Reduced operational risk: no dual-infrastructure transition period

What you give up

• Some degree of architectural flexibility; configuration happens within the platform's design boundaries

• Dependency on the vendor's roadmap for new features and chain support

• The option to monetise the infrastructure itself

What "buying" still leaves with you

Deploying on an existing platform does not move regulatory responsibility off your desk. The issuer retains the legal structuring of the specific instrument, the prospectus or disclosure documentation required under applicable regulation, the offering-level permission where the setup requires one (for example an ECSP license for a crowdfunding platform operator), and the investor relationship and marketing compliance. The platform provides compliant functionality and pre-integrated licensed partners; it does not replace the legal work of structuring and documenting the securities themselves.

How to Evaluate a Provider

If you take the buy path, diligence should move beyond feature lists to the operational and regulatory boundaries of the service. Five questions separate a genuine infrastructure partner from a thin template:

1. What is the regulatory basis of each licensed function? The register, custody, payments, and distribution are licensed activities. Confirm which partner holds each permission and what happens if that relationship changes. The permission should sit with a licensed partner or with you as the issuer, never implicitly with the software vendor.

2. What does the KYC/AML stack cover, and at what certification level? A basic identity-verification API is not equivalent to a full AML5-compliant onboarding flow that has been audited.

3. How are regulatory updates handled? When EU regulation changes, who updates the platform, on what timeline, and is that covered in the service agreement or charged separately?

4. Where is the customisation boundary? Understanding exactly where the template ends and bespoke development begins is essential for product planning.

5. What does the provider not cover? Even the most comprehensive infrastructure does not cover the legal structuring of individual instruments or the prospectus documentation. Surfacing this boundary upfront prevents costly assumptions later.

EU Regulatory Factors That Tip the Decision

The EU regulatory environment introduces structural barriers that are frequently underestimated in build scenarios.

DLT Pilot Regime (EU 2022/858)

Operating under the DLT Pilot Regime, which allows regulated institutions to issue, trade, and settle tokenized securities under temporary exemptions from parts of CSDR and MiFID II, requires authorisation as a DLT Market Infrastructure operator. This involves direct engagement with a national competent authority, ESMA notification and coordination, and compliance with the Pilot's operational and financial requirements. This authorisation process adds 12 to 18 months to any in-house build timeline. A platform whose partners already operate within this framework has navigated it.

MiFID II and investment-firm classification

If a platform facilitates the reception, transmission, or execution of orders in financial instruments, it may require MiFID II authorisation as an investment firm, a tied agent, or a crowdfunding service provider under ECSPR. The classification depends on the exact service model and instrument type. Getting this wrong does not produce a compliance notice; it means operating an unlicensed financial service, which carries criminal liability in most EU member states. Legal opinion on classification alone typically costs €20,000 to €80,000 and takes 6 to 12 weeks.

Prospectus thresholds

A public offer of securities above the applicable threshold requires a BaFin or equivalent-approved prospectus. National exemptions apply below that level and vary by member state (up to €8 million in some), so a platform issuing across multiple EU jurisdictions needs either full prospectus capability or a system that enforces the applicable exemption limit per jurisdiction.

The Dual-Infrastructure Problem

Traditional financial institutions face a structural challenge that pure-play fintechs do not: they must operate legacy infrastructure and DLT infrastructure in parallel during any transition period. This creates increased operational overhead (two systems, two teams, two audit trails), integration complexity (existing custody, settlement, and reporting systems must connect to the new DLT layer), and compliance exposure (any gap in the handoff between legacy and on-chain processes is a regulatory risk).

Interoperability Requirements

A proprietary tokenization stack built in isolation may satisfy internal requirements today but become a stranded asset as market-wide standards mature. The EU market is converging on specific frameworks: ERC-3643 / T-REX (the primary on-chain compliance standard for permissioned security tokens in Europe), DLT Pilot interoperability standards (cross-border settlement conventions under development), and MiCA technical standards (delegated acts continuing to land through 2026). Established platforms are already aligned with these standards; a bespoke build carries the risk of architectural mismatch as the regulatory perimeter firms up.

Decision Matrix: When Building Makes Sense

The decision is not binary, and the right answer depends on existing capabilities, strategic intent, and timeline. This matrix maps the key variables against the two paths:

A particularly important row is maintenance. Many build decisions are made on first-year cost comparisons without accounting for the permanent overhead of keeping a compliant platform current. EU financial regulation is not static: MiCA, ELTIF 2.0, the DLT Pilot Regime, and updated AML directives each require legal analysis, potential platform updates, and in some cases regulatory re-approval. An organisation that builds owns that obligation indefinitely.

Quick checklist

Choose build if you hold existing EU regulatory licences, have a blockchain engineering team with securities-law expertise, work to a three to five year horizon, and intend to offer tokenization infrastructure to third parties as a strategic priority.

Choose buy if your goal is to issue a tokenized product rather than operate infrastructure, you need to reach market in months, your internal resources are better spent on asset structure and investor base, you lack in-house DLT or regulatory-engineering expertise, and compliance continuity under evolving EU regulation matters.

Timeline Comparison: Build vs. Deploy

The legal instrument structuring row is identical for both paths, because it is a function of the specific instrument being issued, not the platform. Deploying on existing infrastructure does not eliminate legal work; the platform handles the operational and compliance infrastructure, while the legal structuring of the securities remains the issuer's responsibility in both cases.

The "regulatory licensing" row depends on your offering route, not on the vendor. Self-issuance of your own investment products (Eigenemission), such as subordinated loans (Nachrangdarlehen) or participation rights (Genussrechte), needs no financial-services license for the act of issuing. A crowdfunding platform operator intermediating third-party offerings needs its own ECSP license. Either way the licensed functions (crypto-securities register, custody, payments) run through the platform's pre-integrated partners, and the permission sits with those partners or with you, never with the software provider.

The Three-Year Cost of Ownership

One of the most consistently underweighted factors in build decisions is three-year total cost of ownership. Initial estimates focus on first-year capital outlay, but financing infrastructure carries ongoing costs that accumulate.

For a custom build, recurring cost drivers after launch include engineering maintenance for security patches, scaling, and features; legal review every time regulation changes; audit and certification renewal for KYC/AML systems; and a dedicated compliance officer or ongoing external counsel. Given the pace of EU change between 2022 and 2025 (MiCA, ELTIF 2.0, DLT Pilot Regime, updated AML directives), any platform built in 2022 required material compliance updates within two years of launch.

On existing infrastructure, the maintenance model is fundamentally different: regulatory updates are absorbed into the service relationship, and your engineering team focuses on deal-specific configuration and client-facing product rather than compliance plumbing. For organisations without a permanent compliance-engineering team, that is the difference between a sustainable operating model and one that accumulates hidden technical and regulatory debt.

Where ONINO Fits

ONINO is white-label financing infrastructure: a software platform that companies and financial institutions use to run their own compliant financing and digital-securities platform under their own brand. It is product-open across several instrument rails (classic securities with an ISIN, digital securities, and tokenized instruments), so tokenization is one optional rail chosen per offering rather than the whole product. The licensed functions an offering needs (crypto-securities register maintained by a BaFin-authorised registrar, custody via a licensed custodian, payments via a licensed payment institution) arrive pre-integrated, so you do not have to source them. To date ONINO has supported €50M+ in tokenized volume across 7+ jurisdictions in the EU and Switzerland.

The platform provides the compliant functionality for issuance, investor onboarding, and reporting, while offering-level permissions and the content of investor documents stay with you as the issuer, so your team can focus on structuring the deal and building the investor base. A standard European platform can be configured in days rather than months.

Book a Demo

FAQ

How long does it realistically take to build a compliant EU tokenization platform from scratch?

Most estimates place the timeline at 18 to 36 months from initial development to compliant production, accounting for DLT Pilot Regime authorisation, legal structuring, smart contract audits, and custody integration. Institutions that underestimate the regulatory-engineering component typically overshoot both timeline and budget.

Does using a white-label platform affect who is legally responsible for the securities offering?

No. The issuer retains full regulatory responsibility for the securities they offer, including prospectus obligations, investor classification, and ongoing disclosure. The platform provider is responsible for the technical and compliance functionality; licensed functions run through pre-integrated partners. The division of operational responsibility is defined by the contractual arrangement between the parties.

What is the build vs. buy framework from McKinsey?

McKinsey's build vs. buy framework evaluates four dimensions: strategic differentiation (does the capability need to be proprietary?), market availability (does a suitable external solution exist?), cost comparison (total cost of ownership for each path), and risk profile (which path carries more execution and operational risk?). Applied to regulated financing infrastructure, the framework typically favours buying for organisations without existing regulatory infrastructure, because the differentiation argument rarely applies to compliance plumbing and the cost and risk differentials favour external infrastructure strongly.

What is ERC-3643 and why does it matter for this decision?

ERC-3643 (also known as T-REX) is the primary on-chain compliance standard for permissioned security tokens in the EU. It encodes investor eligibility, transfer restrictions, and compliance rules directly into the token contract. Established EU tokenization platforms are typically built on or compatible with ERC-3643, which matters for interoperability with custodians, exchanges, and other issuers. A bespoke build using a non-standard token architecture risks isolation as the market consolidates around this standard.

Is a white-label tokenization platform customisable for specific asset classes?

Yes. Established platforms allow configuration across asset types (equity, debt instruments, real estate, fund units, ECSP-regulated crowdfunding securities) while the underlying compliance and settlement functions remain standardised. The level of customisation available varies by provider.

Summary

• A full tokenization stack covers seven distinct components (token issuance, KYC/AML, smart contracts, custody, cap table, reporting, and secondary-market connectivity), each of which must meet EU legal requirements.

• The first-year cost of a compliant build typically runs €600,000 to €2 million before revenue, driven primarily by regulatory licensing and legal structuring rather than engineering.

• Building in-house is viable for large institutions with existing licences, established DLT teams, and a three to five year horizon, particularly those planning to offer tokenization as a service.

• For most EU issuers, white-label platforms deliver compliance continuity, faster time-to-market, and pre-integrated licensed partners that a bespoke build cannot match within a commercially relevant timeline.

• The DLT Pilot Regime authorisation process alone adds 12 to 18 months to any in-house build, a factor that frequently goes unaccounted for in initial feasibility assessments.

• The legal structuring of individual instruments is required regardless of path, and offering-level permissions stay with the issuer; the platform handles the operational and compliance layer, not the securities-law work.

• Competitive differentiation in tokenized finance comes from the asset structure and investor base, not from proprietary infrastructure.