DIGITAL ASSET CUSTODY IN 2026:

The Shift From Wallet As A Service, To Sovereign Infrastructure

EXECUTIVE SUMMARY - FROM EXPERIMENT TO EMBEDDED

Digital asset infrastructure is transitioning. Crypto-native firms now demand more customisation, automation, and business logic inside their wallet workflows. Traditional finance firms, after early success stitching together their preferred providers following an RFP process, now need digital assets embedded into their existing operating model—not operating as a bolt-on with significant third-party risk. For both groups, if digital assets are to sit alongside fixed income, currencies, commodities, and equities, custody technology must advance to the standards expected of institutional post-trade infrastructure. Institutions want transparent workflows, predictable governance, and the ability to operate critical processes without waiting on a vendor’s roadmap. These expectations come directly from customer requirements as digital asset workflows grow more sophisticated and operationally integrated.

Regulators are reaching similar conclusions. The SEC’s proposed Safeguarding Rule, draft CLARITY Act language, and MiCA’s implementation all emphasise that institutions must maintain operational control over the mechanisms that move digital assets. This convergence—between customer needs, regulatory direction, and market maturity—is pushing custody far beyond private key storage and the trust-heavy assumptions of early MPC wallet models.

Wallets are becoming institutional infrastructure. This publication collates what is required to meet the strictest institutional bar in 2026, why this evolution is inevitable, and how wallets are emerging as the foundational execution and governance layer for the next decade of digital finance.

1.DIGITAL ASSETS MOVE FROM INNOVATION TO INFRASTRUCTURE

This has been the dominant narrative in the news cycle in 2025. Incumbents in fintech and traditional finance are increasingly launching products in digital assets, moving away from exploratory pilots and towards core operational activity:

- Asset managers run crypto ETFs and multi-strategy funds

- Banks are piloting tokenized deposits, repo markets, and settlement assets

- Corporates use stablecoins for treasury, supplier payments, and cross-border settlement

- Financial infrastructure providers integrate digital assets into clearing and post-trade workflows

As digital assets become intertwined with financial operations, institutions demand infrastructure that meets long-established expectations:

- High availability

- Deterministic and verifiable workflows

- Strong governance and segregation of duties

- Clear transaction intent

- Regulatory-grade auditability

- Multi-network readiness

- Seamless ERM and compliance integration

What worked for early-stage use cases can no longer support operational scale, regulatory scrutiny, and risk management expectations of mature institutions. Historically, financial technology adoption follows a predictable pattern:

Early experimentation gives way to embedded infrastructure once operational relevance becomes undeniable.

Digital assets have reached that stage. Institutions now evaluate custody technology against the same standards of transparency, auditability, resilience, and governance they apply to payments, trading systems, and post-trade architecture. The question is no longer whether digital asset infrastructure must evolve, but how quickly wallet technology can rise to the level required of core financial infrastructure.

This isn’t just for big corporates. Crypto native institutions are also having this forced upon them by enterprise clients, the regulator, and other stakeholders. So if you are operating a crypto exchange, trading desk, or another business that relies heavily on wallets then you are also moving in the same direction.

2. Wallets Evolving From a Service to a Technology Layer

Digital assets collapse traditional safekeeping and entitlement roles into a single cryptographic action: signing. Whoever controls signing controls movement, entitlement, and operational authority. This makes custody fundamentally a technology architecture question, not a service overlay.

This collapse explains persistent regulatory ambiguity: digital asset “custody” maps poorly to historic frameworks because technology—not a third-party institution—executes the determinative control. Modern institutional wallets are evolving into the browser of Web3 and the central nervous system of internal digital asset workflows. They:

- Evaluate business logic,

- Consume upstream pricing, exposure, and other data,

- Interface with smart contracts,

- Trigger post-trade processes, and

- Enforce contextual governance rules.

As more post-trade functions move on-chain or become dependent on blockchain events, the wallet is becoming an intelligent, policy-driven execution environment. The wallet layer is absorbing more responsibility from the post-trade, risk, compliance, and treasury domains.

This shift explains why regulators are reevaluating what “custody” means, and why institutions increasingly expect their wallets to behave like infrastructure while also having clear extension points built into the product for further embedding into their operating model. This can be in the form of programmatic processes for funding management, capital rebalancing, and codifying responses to external margin engines as examples.

2.1 Regulators Are Beginning to Codify Wallet Reality

Regulators across jurisdictions are increasingly explicit that technology architecture defines custody control. We will quickly summarise some of the developments here.

U.S. SEC — Safeguarding Rule Proposal (2023, Release IA-6240)

The SEC states advisers must maintain “possession or control” of digital assets, warning that arrangements:

“…may not provide the adviser with sufficient control where a third-party technology provider exercises material discretion.”

This is a direct critique of early MPC wallet models where keys are shared, but all the power is concentrated at the vendor. What started as convenience, has transformed into risk.

SEC Staff Commentary on Key Control (2024)

This isn’t the only data point. Public roundtables and responses emphasize:

- Holding one key share ≠ operational control

- Advisers must control the operational path enabling asset movement

- Vendors with authority to approve or execute transactions may be functioning as unregistered custodians

The SEC is not focused on whether an institution holds a key share — but whether it controls the entire operational path that enables asset movement.

CLARITY Act Drafts (2024–2025)

Draft legislative text proposes:

- Distinguishing custody technology from custody services

- Recognising “self-custody systems” where institutions maintain operational authority

- Requiring verifiable audit trails and transparent authorization workflows

This marks an important step toward formalising wallet design choices as a means of establishing regulated activity or not.

MiCA (EU)

MiCA Article 75 requires crypto-asset service providers to implement:

- Internal control systems aligned with traditional custody

- Segregation of duties

- Operational resilience measures

- Full control over the means of access to crypto-assets

EU regulators are explicit: custody includes both key control and operational control.

UK FCA & MAS (Singapore)

Both regulators emphasize:

- Clear responsibility for safeguarding

- Governance alignment

- Operational continuity

- Avoidance of single points of failure

- Independence from third-party operational discretion

Global regulators are converging on one expectation - Institutions must retain meaningful operational control over wallet workflows.

2.2 Wallets Must Become Embedded Infrastructure

Digital assets collapse the functions of safekeeping, entitlement, and operational authorization into a single signing event. At the same time, the wallet is consuming upstream data, enforcing governance, and triggering post- trade workflows. This combination elevates custody from a peripheral utility to a determinative control layer within the institution. Because private keys unify:

- Safeguarding,

- Recordkeeping, and

- Operational authorization

into a single signing process, wallets must function like other embedded enterprise systems, not outsourced services. This evolution mirrors historical infrastructure shifts:

Identity → Enterprise IAM Platforms. Authentication moved from external providers to internal, policy-driven systems.

Payments → In-House Payment Orchestration. Institutions internalised routing, decisioning, and compliance around payments.

Risk → Internal Risk Engines. Vendor models were replaced with auditable, explainable, deterministic internal systems.

Security → Zero-Trust Architectures. Control moved from perimeter outsourcing to internal enforcement.

As happened with identity, payments, risk engines, and security architecture, once a system becomes central to how core financial functions operate, institutions bring it inside their governance perimeter. Wallet technology is reaching that point now. It is evolving from a vendor-operated service into embedded institutional infrastructure.

3. The New Institutional Requirements: Lessons From Traditional Finance

The expectations institutions bring to digital asset wallets are not new; they mirror principles that have governed traditional financial systems for decades. Trading, payments, risk, clearing, and settlement systems all share a common foundation: deterministic workflows, transparent controls, independent verification, and clear lines of responsibility.

Digital assets introduce new infrastructure, but they do not change these expectations. If anything, they heighten them. As digital asset exposure grows, institutions increasingly require custody systems that behave like the rest of their critical infrastructure. Four requirements define this shift.

3.1 Operational Sovereignty

In traditional finance, no critical function is designed to depend entirely on a vendor’s uptime or discretion. Trading desks do not halt because a SaaS provider is offline. Treasury operations do not pause because an external risk engine is unavailable. Settlement systems are built with redundancy and internal control over all determinative workflows.

Wallets must follow the same pattern. Digital asset systems that rely on centralised vendor services for policy evaluation, transaction authorisation, or signing availability create operational single points of failure that would be unacceptable in any other financial domain.

Institutions increasingly expect custody infrastructure to continue operating— even if the vendor is offline—because operational responsibility cannot be delegated.

3.2 Governance That Mirrors Existing Controls

Financial institutions operate complex governance environments involving:

- Delegated authorities

- Maker–checker and supervisory approvals

- Credit and risk limits

- Treasury and funding management decision rules

- Portfolio management controls

- Role-based entitlements

- Audit and compliance oversight

This ensures that who can do what under which conditions is always clear, reviewable, and enforced internally—not outsourced to external software vendors. Digital asset wallets must integrate into these governance layers rather than reimpose a new, vendor-defined approach. Approvals, role structures, and transaction logic must be customisable to reflect the controls institutions already use across every other financial workflow. This is not unique to digital assets—it is a long-standing institutional requirement now being applied to a new asset class.

3.3 Transparent, Verifiable Instructions

In traditional finance, no meaningful action occurs without the ability to review and verify the precise instruction being executed:

- Orders include explicit fields (price, quantity, venue).

- SWIFT and ISO 20022 messages include structured data for settlement.

- Treasury payments display the exact routing details.

- Risk systems consume transparent, explainable inputs.

Digital asset transactions introduce a risk that did not previously exist at this scale: blind signing. Blind signing occurs when a user or system approves a transaction without being able to see or verify the underlying payload that will be executed on-chain.

This practice is unfortunately far too common in wallets and various institutional systems. Scam Sniffer’s 2025 analysis estimates that wallet drainer phishing attacks, which typically rely on users blindly signing opaque approvals, still caused around $84 million in losses in 2025, even after falling sharply from roughly $494 million the year before.

It has repeatedly led to:

- Approval of malicious transactions

- Unintended transfers

- Unauthorized contract interactions

- Draining of smart contract wallets

- Large-scale losses in DeFi and NFT platforms

Institutions view this as wholly incompatible with their operating standards. No approval workflow in traditional finance asks a user to authorize a message they cannot see, interpret, or verify. Institutions require:

- Visibility into the full payload,

- Clarity on contract calls and parameters,

- Deterministic policy evaluation, and

- No ability to approve what cannot be verified.

This level of granular transaction understanding is baseline hygiene in traditional systems—and is rapidly becoming a non-negotiable baseline hygiene for institutions in digital asset wallets they use.

3.4 Regulatory-Grade Audit Trails With Deterministic Replay

Every mature financial system is built on the principle that every event must be explainable and reproducible. Risk committees, auditors, regulators, and internal control functions all rely on systems that provide:

- Immutable logs

- Evidence-based authorization trails

- Reconstructable decision logic

- Clear mapping of intent → evaluation → outcome

- Independent verifiability

In digital assets, this requires deterministic replay: the ability to take any historical event and reproduce the exact authoriSation and signing workflow, including policy evaluation, node participation, inputs, and outputs. Legacy MPC custody models struggle here because:

- Approval logic runs in centralized vendor backends

- Customers cannot independently verify the sequence of events

- Logs reflect vendor interpretation, not deterministic truth

- Replayability is limited or absent entirely

This is not merely a technical deficiency—it is a mismatch with institutional governance and regulatory expectations. Custody infrastructure must provide a provable version of the truth, not a vendor-supplied representation of it.

4. Why Legacy MPC Wallets Are Struggling

Legacy MPC wallets played an important role in the early stages of digital asset custody. They solved an urgent problem—reducing single points of failure in private key storage—and enabled institutions to participate in digital asset markets without holding raw private keys. For the first wave of adoption, this was sufficient.

As institutional usage has expanded beyond basic transfers into trading, treasury, settlement, collateral management, and post-trade workflows, the gaps in legacy MPC wallets have become increasingly visible. They were designed for key security and not for institutional governance, transparency, resilience, or regulatory accountability. MPC wallets now struggle in four fundamental ways.

4.1 Centralized Policy Evaluation: An Inversion of Institutional Governance

Traditional MPC wallets split key material across multiple signing nodes, but the policy engine—the system that determines whether a transaction should be approved—often remains centralised and vendor-controlled.This creates a structural contradiction:

- Key material is decentralised

- But the authority to move assets is centralised in the vendor’s backend

From an institutional perspective, this is equivalent to trusting an external vendor to run:

- Your payment rules engine,

- Your trading permission system, or

- Your treasury approval policies

No bank, exchange, or asset manager would accept this arrangement in any other domain. Centralized policy logic also means:

- The vendor can be a single point of failure,

- The vendor must be trusted to evaluate policies correctly,

- The institution cannot independently verify authorization logic,

- And control is contingent on an external service remaining online.

As regulators increasingly interpret custody obligations through the lens of operational control, this model becomes untenable.

4.2 Vendor Availability as a Determinative Failure Mode

In most legacy wallet deployments, the vendor’s cloud service must be online for transactions to proceed—even if key shares are distributed. This creates operational risks that institutions would never tolerate elsewhere:

- If the vendor is down, the institution cannot move assets.

- If the vendor is degraded, signing throughput degrades with it.

- If the vendor rate limits or throttles, transaction processing slows.

- Scheduled maintenance can inadvertently pause institutional operations.

This violates the core requirement from Section 3: critical financial functions must remain available independent of vendor uptime. It also creates a regulatory problem… if the vendor’s availability determines whether assets can move, then the vendor arguably exercises operational control—an issue now raised explicitly in SEC commentary on custody.

Beyond governance and security concerns, centralised vendor-operated custody introduces a direct and often under appreciated business cost. When a vendor experiences operational degradation — API congestion, message queue backlogs, node outages, or policy-engine failures — institutions lose the ability to move assets. Several trading firms and OTC desks have reported being unable to settle trades or rebalance risk for multiple hours during periods of vendor congestion, resulting in quantifiable missed revenue and elevated exposure. The commercial impact is significant. A trader unable to move assets to an exchange during a period of volatility misses PnL generating opportunities. A treasury team unable to sweep funds or unwind a position incurs basis risk. Market makers lose spread capture. Custodians and exchanges delay client withdrawals.

4.3 Limited Transaction Transparency and the Persistence of Blind Signing

Many legacy MPC wallets expose only summaries of transactions, rather than the full payload that will be signed on-chain. This creates several unacceptable

conditions:

- Approvers may be shown human-readable metadata, not the actual call data.

- Contract interactions may be hidden behind generic labels (“Approve token”, “Interact with contract”).

- Complex DeFi or smart contract interactions may be abstracted away entirely.

- Institutions cannot independently verify intent vs outcome.

This is an institutional non-starter. Blind signing, or signing with insufficient visibility, has been repeatedly implicated in loss events across:

- DeFi protocol interactions

- Compromised frontend interfaces

- Malicious smart contracts

- Phishing-style attacks

Institutions cannot expose governance workflows to opaque transaction summaries. Wallet infrastructure must provide full payload visibility, and policy engines must evaluate the exact bytes that will be signed—not vendor interpretations of them.

4.4 Inflexible Governance That Cannot Reflect Internal Controls

Legacy MPC solutions typically impose:

- Fixed approval workflows,

- Rigid policy models,

- Limited conditional logic,

- Narrow event triggers,

- Or vendor-defined permission structures.

This is incompatible with institutional governance environments, where:

- Approval logic is complex and multi-layered,

- Risk constraints vary across desks and products,

- Workflows require conditionality and context,

- And policy rules often depend on upstream data (e.g., exposure, liquidity, counterparty limits).

If wallet workflows cannot reflect existing enterprise governance structures, institutions face a choice:

1.Weaken their controls to fit the wallet, or

2.Choose a wallet system that fits their controls

No institution will choose the first.

4.5 Slow Chain Support Misaligned With Market Reality

Legacy MPC wallet vendors often require:

- Long development cycles to support new chains,

- Bespoke integration work,

- Or slow internal certification processes.

This does not align with institutional needs:

- New chains appear frequently,

- New transaction types emerge rapidly (bridge, mint, redeem)

- New signature schemes evolve (BLS, quantum-safe variants),

- Tokenized markets multiply across chains.

In 2026, chain coverage is not just a product feature—it is a market access requirement. This problem is structural: when functionality for a new chain or transaction type must be added to a centralised vendor backend, customers remain downstream of the vendor’s priorities and engineering throughput. The result is a widening gap between the pace of market development and the pace at which institutional wallets can support it.

Next-generation wallets resolve this bottleneck through modular, deterministic, externally verifiable chain support that does not require re-engineering vendor infrastructure. As one example, Cordial Treasury represents the most advanced version of this model, having historically delivered new mainnet support in as little as 24–72 hours, with typical delivery times measured in one to two weeks, not quarters. This is made possible by Cordial’s open-source Crosschain library, which externalises blockchain transaction construction, simulation, encoding, and metadata handling.

In a market where new chain launches and feature activations occur continuously, the ability to expand horizontally at institutional speed is no longer optional — it is a competitive necessity.

4.6 Opaque Authorization Histories and Weak Auditability

Because legacy MPC wallet vendors centrally evaluate policies, they also centrally generate the logs describing those policy evaluations. This creates risks:

- Institutions must trust the vendor’s logs.

- Logs may not reflect a deterministic replay of events.

- Auditability depends on a vendor’s internal systems.

- Institutions cannot independently reproduce the authorization workflow.

Regulators increasingly reject such dependencies. Wallet audit trails must be:

- Institution-owned,

- Deterministic,

- Reproducible,

And cryptographically anchored—not vendor interpretations of events.

End of Part 1

* Updated: Please see part 2 here to learn more about"The New Optimum" in digital asset wallets, we put Cordial Treasury under the microscope as a working example of this new optimum, and a 5-phase maturity curve model to help institutions of any size get an understanding of where they are and how best to level up their wallet operations in 2026.

Share to: