DORA-Ready Infrastructure: What Asset Managers Need from a Tokenization Platform

DORA, the Digital Operational Resilience Act, went live across the EU on 17 January 2025. It doesn't apply to most asset managers directly. But it applies to nearly every digital infrastructure provider they rely on. If a tokenization platform handles fund administration, investor onboarding, or securities issuance for an in-scope financial entity, DORA shapes the operational standard that vendor diligence teams now have to verify.

The result: even asset managers outside DORA's direct scope are, in practice, doing DORA-driven due diligence on the platforms they integrate with. A platform that isn't DORA-ready, eWpG-registered, and MiFID II-classified is operationally incomplete, regardless of how polished its smart contracts look.

This post explains what DORA actually requires, why the burden lands on infrastructure providers rather than asset managers themselves, how DORA interacts with MiFID II and the German eWpG framework, and what asset managers should verify before integrating a tokenization platform into their operating stack.

What DORA actually requires (and who it applies to)

DORA establishes a uniform framework for operational resilience across the EU financial sector. It replaces a patchwork of national rules with five binding pillars that every in-scope entity must implement.

The five pillars are:

• ICT risk management. Board-level governance of information and communication technology risk, with documented frameworks, mapped dependencies, and clear lines of responsibility.

• ICT-related incident reporting. Standardized classification, escalation, and reporting of major incidents to national competent authorities, with strict timelines.

• Digital operational resilience testing. Regular threat-led penetration testing (TLPT) for significant entities, plus broader vulnerability and scenario-based testing for everyone in scope.

• ICT third-party risk management. Contractual, monitoring, and exit-strategy obligations toward critical ICT providers, including a register of all third-party arrangements.

• Information sharing. Voluntary mechanisms for cyber threat intelligence exchange between financial entities.

The scope is broader than most asset managers initially assume. DORA applies to credit institutions, investment firms, AIFMs and UCITS managers above certain thresholds, payment and e-money institutions, central counterparties, trading venues, central securities depositories, crypto-asset service providers under MiCA, and, importantly, to the ICT third-party providers that serve them.

That last category is what reshapes the conversation. If a tokenization platform is classified as a critical ICT third-party provider to one or more in-scope financial entities, the platform itself becomes subject to DORA's requirements through the contractual and oversight chain, even if the platform isn't a regulated financial entity in its own right.

Why asset managers feel DORA even when it doesn't apply directly

Here is the asymmetry that matters operationally.

DORA forces in-scope financial entities to verify, monitor, and contractually bind their critical ICT providers. It requires them to maintain a complete register of ICT third-party arrangements, run pre-contractual due diligence on resilience capabilities, include specific contractual provisions (audit rights, sub-outsourcing controls, exit strategies, incident notification), and demonstrate ongoing oversight throughout the relationship.

Asset managers typically don't operate proprietary issuance, registry, or KYC infrastructure. They rely on tokenization platforms, registry operators, custodians, KYC providers, and fund administrators. If any of those vendors aren't DORA-aligned, the asset manager's own vendor risk file fails diligence, even when the asset manager isn't formally in DORA's direct scope.

Three concrete consequences:

• Sub-threshold AIFMs that fall outside DORA's direct scope still face DORA-driven scrutiny from their LP base, particularly when LPs include in-scope entities (banks, insurers, large pension funds) who must report on their own indirect ICT exposures.

• Cross-border fund structures routinely include at least one in-scope entity in the chain. If the master AIFM is in scope, every feeder, sub-manager, and shared service provider gets pulled into the diligence perimeter.

• Co-investment structures with regulated banks, increasingly common for tokenization-driven private market deals, bring DORA into the room automatically, because the bank participant is in scope and must verify the operational resilience of the deal infrastructure.

The practical result: an asset manager evaluating a tokenization platform in 2026 is no longer just asking can this platform handle the issuance? The questions are now closer to can this platform pass our largest LP's vendor risk review? and will this platform's incident reporting and exit strategy hold up if our fund administrator is audited?

The full regulatory stack a tokenization platform should already have

DORA is one piece. A tokenization platform serving regulated asset managers in the EU sits at the intersection of several frameworks, and missing any one of them is a structural problem rather than a feature gap.

The full operational layer for digital securities under EU law:

• eWpG (Gesetz über elektronische Wertpapiere). The German Electronic Securities Act, which defines the legal form of crypto-securities and central-register securities, and assigns registry operator responsibilities under BaFin supervision.

• MiFID II. Investment services classification, conduct of business rules, and transaction reporting obligations for any tokenized instrument that qualifies as a financial instrument.

• DORA. Operational resilience, incident reporting, and third-party risk management for the platform's role as ICT provider to in-scope financial entities.

• AMLD6 / GwG. Anti-money-laundering and KYC obligations on the issuance and transfer flows.

• GDPR. Investor data handling, cross-border transfers, and right-to-be-forgotten interactions with on-chain identity.

• MiCA. Relevant only when the platform also handles non-financial-instrument crypto-assets; for digital securities under MiFID II, MiCA is generally out of scope.

A tokenization platform that is "blockchain-compliant" but not eWpG-registered is unable to issue legally recognized electronic securities in Germany. A platform that handles MiFID II financial instruments without proper classification cannot meet transaction reporting obligations. A platform that isn't DORA-ready cannot survive vendor diligence from any in-scope financial counterparty.

This is why a white-label infrastructure model is structurally different from buying tokenization tooling and self-assembling the regulatory layer: the regulatory stack is the integration, not an add-on to it.

How DORA, MiFID II, and eWpG interact

The three frameworks address different questions. They are complementary, not redundant. The table below summarizes what each covers, who it applies to, and what an asset manager should specifically ask vendors when running diligence.

Two clarifications on the interactions:

AIFMD remains the asset manager's own license. None of these three frameworks replace AIFMD. The fund manager's authorization, depositary arrangements, valuation policies, and risk management framework remain governed by AIFMD and its national transpositions. DORA, MiFID II, and eWpG sit underneath that license. They govern the infrastructure layer, not the fund layer. An asset manager doesn't outsource its AIFMD obligations by using regulated infrastructure; it outsources the operational and technical resilience of the components AIFMD already requires the manager to have.

MiFID II's outsourcing rules continue to apply alongside DORA. DORA tightens and standardizes ICT third-party risk requirements, but it does not eliminate MiFID II's own outsourcing provisions for investment firms. In practice, both apply simultaneously. DORA's requirements are typically the higher bar for ICT-related arrangements and are absorbed into the same vendor contract.

What ONINO operates as the regulated infrastructure layer

ONINO operates regulated digital securities infrastructure with the regulatory layer absorbed at the platform level rather than passed back to the asset manager.

Concretely:

• DORA-ready operational resilience. Documented ICT risk management framework, incident reporting protocols aligned with the EU classification standards, sub-contractor register, contractually-fit clauses for in-scope financial entity counterparties, and resilience testing aligned with DORA's requirements for critical ICT providers.

• eWpG registry architecture via Cashlink. Cashlink is BaFin-supervised as a crypto-securities registry operator under eWpG, providing the legally recognized registry layer for electronic securities issued through ONINO platforms.

• MiFID II classification on issued instruments. Tokenized instruments are classified, structured, and documented as MiFID II financial instruments where relevant, with transaction reporting capability built into the issuance pipeline.

• ERC-3643 (T-REX) for on-chain compliance. The de facto standard for permissioned, identity-bound transfers on Ethereum-compatible chains, with whitelisting and transfer restrictions enforced at the token contract level.

• AMLD6 / GwG-aligned KYC and AML as part of the investor onboarding flow.

The institutional validation: ONINO's partnership with Volksbank, a regulated regional cooperative bank, was preceded by more than a year of due diligence covering exactly the operational resilience, regulatory delegation, and third-party risk dimensions that DORA now codifies sector-wide. €35M of tokenized capital has been processed across 8+ live platforms running on this stack.

For asset managers evaluating a tokenization platform under DORA-aware diligence, this means the regulatory architecture has already been carried by a counterparty subject to bank-grade vendor diligence. The asset manager retains full AIFMD scope and investor relationship; ONINO carries the operational and regulatory infrastructure load.

Where the model is still developing

Tokenization is operationally tested, but several aspects of the regulatory landscape are still maturing. Acknowledging this honestly is part of how institutional infrastructure stays trusted.

• DORA RTS refinement is ongoing. The regulatory technical standards under DORA, particularly on sub-contracting, threat-led penetration testing scope, and the criticality criteria for ICT third-party providers, continue to be refined through 2026. Vendor diligence frameworks will tighten as those standards bed in.

• Cross-border coordination is uneven. Different national competent authorities are still building out their DORA supervisory practices at different speeds. Pan-EU consistency is the goal but not yet the reality.

• AIFMD–DORA interaction at threshold AIFMs. ESMA guidance on how DORA applies to sub-threshold AIFMs and to small alternative investment fund managers is still being interpreted in practice. Most market participants are operating on a conservative reading.

• Sub-contractor register formats. DORA requires every in-scope entity to maintain a complete register of ICT third-party arrangements. The format is not yet fully standardized across providers, which makes vendor data exchange more manual than it should be.

None of these are reasons to delay infrastructure decisions. They are reasons to pick infrastructure built by counterparties who are tracking the regulatory layer continuously rather than treating it as a one-time compliance project.

Bridging from regulation to operation

DORA, MiFID II, and eWpG together describe what regulated digital securities infrastructure has to look like in 2026. The asset manager's job isn't to internalize each framework. It's to integrate with infrastructure where the frameworks have already been internalized. ONINO operates that infrastructure layer: DORA-ready, eWpG-registered through Cashlink, MiFID II-classified at the instrument level, and validated through institutional partnerships that put real bank-grade diligence on the regulatory stack. The asset manager keeps AIFMD scope, investor relationships, and product strategy; the infrastructure carries the operational and regulatory weight underneath.

Walk through ONINO's regulatory architecture for asset managers →

Book a Demo

ONINO's infrastructure handles compliance, investor onboarding, and reporting from day one - so you can focus on structuring your deal and building your investor base. Platforms go live in under 24 hours, with no internal technical build required.

Book a Demo

Summary

• DORA went live in January 2025 and applies to financial entities and their critical ICT third-party providers, including most tokenization platforms serving in-scope counterparties.

• Asset managers outside DORA's direct scope still face DORA-driven vendor diligence whenever their LPs, co-investors, or service providers are in scope themselves.

• The full regulatory stack for a tokenization platform serving regulated asset managers in the EU includes DORA, MiFID II, eWpG, AMLD6, and GDPR. Missing any one is a structural gap, not a feature gap.

• AIFMD remains the asset manager's own license; DORA, MiFID II, and eWpG govern the infrastructure layer beneath it, not the fund layer above it.

• ONINO operates DORA-ready, eWpG-registered (via Cashlink), MiFID II-classified digital securities infrastructure, validated through the Volksbank partnership and €35M of tokenized capital across 8+ live platforms.

• Several DORA RTS and AIFMD–DORA interaction questions are still being refined through 2026, which makes infrastructure providers tracking the regulatory layer continuously more valuable than ones treating compliance as a one-time project.

Frequently asked questions

Does DORA apply to my fund if I'm a sub-threshold AIFM?

Sub-threshold AIFMs are generally not in DORA's direct scope. However, DORA-driven obligations frequently arrive indirectly through LPs, co-investors, or service providers who are in scope. In practice, most sub-threshold AIFMs serving institutional capital are running DORA-aligned vendor diligence by 2026 even where the regulation does not technically bind them, because their counterparties' obligations create the same effective standard.

Can I use a non-EU tokenization platform under DORA?

You can, but the DORA obligations don't disappear because the provider is non-EU. If you are an in-scope financial entity, DORA still requires you to verify the resilience, monitor the relationship, and contractually bind the provider. Certain critical ICT providers from outside the EU may also be designated as such by EU authorities and brought directly into the oversight framework. EU-based, EU-regulated infrastructure typically reduces both diligence cost and ongoing reporting burden.

What's the difference between DORA-compliant and "DORA-ready"?

There is no formal DORA certification scheme for ICT third-party providers, so "DORA-compliant" is not a regulator-issued status. "DORA-ready" describes a provider whose operational resilience framework, contractual templates, incident reporting protocols, and sub-contractor management are aligned with DORA's requirements for critical ICT third-party providers, meaning the provider can support an in-scope financial entity's own DORA obligations without forcing the financial entity to carry the operational gap internally.

Does DORA replace MiFID II's outsourcing rules?

No. DORA standardizes and tightens ICT third-party risk management across the EU financial sector, but MiFID II's outsourcing provisions for investment firms continue to apply in parallel. In practice, both sets of obligations are implemented through the same vendor contract, with DORA setting the higher bar for ICT-related arrangements.

How does the registry operator's DORA status affect my issuance?

If your tokenized issuance uses an electronic securities registry under eWpG (such as a crypto-securities register operated by a BaFin-supervised registry operator), the registry operator is itself an ICT third-party provider in the chain. Their DORA alignment matters because registry continuity, incident response, and exit strategy are operationally critical to the legal validity of the securities. An asset manager evaluating a tokenization platform should verify registry operator licensing, supervision, and DORA readiness as a single package.