Vendor Due Diligence for Digital Asset Service Providers

As of October 18, 2026, nineteen providers had been designated Critical ICT Third-Party Providers under the EU's Digital Operational Resilience Act and placed under direct supervision by the European Supervisory Authorities. The list includes market data and payment processing firms. No digital asset service provider is on it. For anyone building a vendor diligence program for custodians, issuers or node providers, that absence is the most informative fact available, and it does not point the direction most vendors would like.

The Legacy Workflow, and Its Formal Version

The informal version is familiar. A questionnaire goes out, a service organization controls report comes back, the buyer collects audited financials, an insurance certificate and two reference calls, negotiates contract clauses, files the package, and refreshes it annually.

DORA gives that process statutory shape, which is useful even for firms outside its perimeter because it states plainly what the exercise is supposed to achieve. Before contracting, a financial entity must assess whether the service supports a critical or important function, whether supervisory conditions are met, the risks including concentration, the provider's suitability through due diligence, and conflicts of interest. Mandatory clauses go into every contract, with an enhanced set covering service levels, audit rights, exit strategy and participation in threat-led penetration testing where the function is critical. Tested exit plans are required for critical services, which in custody is a harder obligation than it reads.

And one requirement sits above the rest: a Register of Information covering every ICT contractual arrangement at entity, sub-consolidated and consolidated level, whether or not the service is critical, reported at least annually. That register, not the questionnaire, is what supervisors actually use.

The Questionnaire Came From Somewhere Else

Here is the problem with the informal version. The questionnaires in circulation were written for software vendors and inherited wholesale. They ask about encryption at rest, access reviews, business continuity and certification status, and those are reasonable questions about a hosted application.

The claims that matter for a digital asset provider are different in kind. Keys were generated inside hardware that never exported them. No single person can authorize a transfer. Client assets are segregated. Nothing is rehypothecated. Each of those is unobservable from outside the provider, and for each one the provider's own attestation is the only evidence the questionnaire produces. A buyer ends up with a file that has the shape of verification and the content of disclosure.

DORA practitioners say this directly: the obligation requires independent verification of vendor suitability rather than questionnaire-based disclosure. The distinction is the whole exercise, and most programs in this sector have not made it.

The Fork

Now take the designation absence seriously, because it forces a choice between two readings and neither is comfortable.

The Article 31 criteria are about dependence: the systemic impact of the provider's failure, how many financial entities depend on it and how important they are, how much they rely on it for critical functions, and whether viable substitutes exist. A provider gets designated because the sector cannot easily do without it.

So either no digital asset service provider yet meets that threshold, in which case institutional reliance on this infrastructure is smaller than the adoption narrative claims and the diligence apparatus is being built ahead of the exposure. Or some provider does meet it and the registers are not surfacing it, in which case the apparatus everyone points to is not seeing the dependency it exists to find. There is no third reading in which both the adoption claims and the diligence claims are sound. The honest position is to pick one and say which.

Where It Breaks: The Subcontractor Line

The supervisory record points at the second branch. Technical standards require due diligence facts to cover the provider's reputation, resources, authorizations held, third-country and sanctions exposure and use of subcontractors. Subcontractors are where digital asset dependency actually concentrates, because a custodian is itself a stack: a signing library, a cloud region, a node or RPC provider, an analytics vendor, a sub-custodian.

Supervisors report that concentration risk is being acknowledged at portfolio level but not quantified at function level, which is precisely the gap that hides a shared dependency. The comparison case is instructive: more than 65 percent of EU financial entities rely on at least two of the three large cloud platforms for critical functions, a fact that only became visible once registers were aggregated. Nothing equivalent has been computed for node providers or signing implementations.

Register quality is the other constraint. One national authority returned roughly a fifth of first-cycle submissions for data-quality errors with a six-week remediation window, the most common being inconsistent function identifiers between the register and the firm's own ICT risk register. A concentration analysis built on that data is not yet reliable, which is a reason to treat the current absence of designations as weak evidence either way.

What to Ask Instead, and What Is Improving

The constructive move is to stop asking only questions whose answers cannot be checked. A small set of claims about a digital asset provider are independently verifiable from public ledger data without the provider's cooperation, and the established tests concern whether a deposit address is uniquely the client's and where the holding address sends. Those belong on the questionnaire and are generally absent from it, which is odd given they are the only answers a buyer can confirm alone.

Three additions are cheap and worth making. Require the subcontractor list by name and function, not a count. Require the provider to state which of its dependencies it shares with the buyer's other providers, which converts a hidden correlation into a disclosed one. And require an exit test rather than an exit plan, since in custody the two differ substantially.

On cost and timing, little changes: the questionnaire cycle still runs weeks, and the ledger checks add hours rather than removing any. What is improving is the register. A machine-readable, annually submitted inventory of every ICT arrangement, aggregated across a sector and used to designate the providers it cannot do without, is a genuinely better instrument than a questionnaire, and it is already working in the cloud case. For a compliance function the practical step is to build the firm's own version now, at function level, including every digital asset dependency and its subcontractors, because the first designation in this sector will be made from that data rather than from anything a vendor volunteers.

For informational purposes only. Not an offer to buy or sell any security. Available only to accredited investors who meet regulatory requirements.

‍