Custodial or Non-Custodial Under MICAR

Over the past year, we’ve heard the same question raised in nearly every serious institutional conversation about digital assets: “What does custody actually mean under MiCAR?” It is a fair question. The regulatory landscape in Europe is moving fast. The Markets in Crypto-Assets Regulation (MiCAR) and the Digital Operational Resilience Act (DORA) are reshaping the way institutions engage with digital assets. Yet, even as "compliance explainers" flood LinkedIn and vendors promise plug-and-play solutions, many banks, trading platforms, and custodians still feel like they are navigating in a fog.

Last week, we wrote about this lack of clarity. We explained why DORA, in particular, remains largely undefined. We highlighted key takeaways from the closed-door roundtable organized by Siedler Legal in Brussels, where Dfns was the only wallet infrastructure provider in the room. There, the question of how to classify DeFi under MiCAR and DORA sparked lively debate. The consensus was that we are still early. But MiCAR’s approach to custody is different. The clarity is already here.

It matters because understanding whether a service is custodial or non-custodial under MiCAR is not just a legal exercise; it defines the obligations, licenses, liability, and compliance exposure of nearly every single digital asset operation in the European Union. It shapes whether your company needs to become a regulated Crypto-Asset Service Provider (CASP), whether your infrastructure partner drags you into the scope of MiCAR, and whether your user relations are considered financial services or software services.

To help bring this clarity into focus, we commissioned a legal memorandum from Morgan Lewis. The objective was to assess whether our “delegated signing” configuration constitutes a custody service under MiCAR and French law, or not. The result is a 20-page analysis, issued by Hubert de Vauplane on March 31, 2025, that dissects MiCAR’s legal definitions, explores the legacy French approach under the PACTE Act, and applies those principles directly to MPC-based infrastructure. Here is what we learned.

MiCAR’s definition of custody of digital assets

MiCAR defines custody as “the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to such crypto-assets, where applicable in the form of private cryptographic keys.” At first glance, this seems very expansive, but this definition borrows directly from earlier French law, notably the PACTE Act of 2019 and the AMF’s guidance issued in 2020, which focused custody around a single legal concept: control.

“Control” should be understood here as the capacity to move digital assets without anyone else’s involvement or dependency. It’s not about theoretical access, physical storage, or who designed the software. Rather it’s about the real-world ability to trigger a blockchain transaction without the approval or participation of the end-user.

Recital 83 of MiCAR makes the scope even clearer: providers of non-custodial hardware or software wallets are not considered custodians. This exemption was intentionally added during the legislative process to ensure that technology providers, who merely enable others to manage keys, are not regulated as financial intermediaries. Control, in this context, is not a technical feature – it is a legal threshold.

The role of French law and AMF guidance

Although MiCAR is now fully applicable across the EU, France remains an important interpretative reference point. The French Financial Market Authorities (AMF) was among the first regulators in Europe to define crypto-asset custody in law and to distinguish technology service providers from financial custodians. According to AMF guidelines, custody requires not only access to the private keys but also a contractual relationship that authorizes the service provider to act on behalf of the user. These guidelines outlined four indicators of custody: 

1. the ability to transfer assets, 
2. possession of wallets containing private keys, 
3. control of the public address, 
4. and the receipt of user assets into a wallet owned by the provider.

These elements are illustrative, not exhaustive. More importantly, they are not met by software solutions where the end-user retains the exclusive ability to authorize transactions. The AMF further clarified that technology providers whose solutions store cryptographic keys under the sole control and responsibility of the client do not offer custody services. That language has since been echoed almost verbatim by MiCAR’s own drafters.

How MiCAR views our “delegated signing” scheme

Dfns provides digital asset infrastructure based on Threshold Signature Schemes (TSS) and Multi-Party Computation (MPC). These cryptographic techniques ensure that private keys are never created, stored, or held in full. Instead, keys are actually generated in the form of encrypted partial keys and distributed across multiple secure environments. The patent-pending innovation of Dfns’ “delegated signing” solution is that signing a valid transaction requires first an API call authenticated by the end-user. Without this step, no signature can be generated. And without a signature, there is no transaction.

Morgan Lewis’ assessment hinges on this point. Under both MiCAR and French law, Dfns satisfies the first two elements required for a regulated service, aka professional activity and a contractual relationship with its customers. But the third element, control, is where the distinction is made. In the non-custodial version of the architecture reviewed by Morgan Lewis, neither Dfns nor its clients (read: platforms) can trigger a blockchain transaction without the end-user’s authentication credential in use. Even if the infrastructure runs in Dfns-managed data centers or includes trusted execution environments, what matters is not the location of the MPC key shares, but the fact that Dfns has no access or ability to use them in the normal course of business. This authentication step, secured through WebAuthn and other alternative key-based protocols, places control in the hands of the end-user. It is the legal equivalent of custody, and since Dfns lacks that control, it is not a custodian per MiCAR.

And what about sub-custody, does Dfns qualify?

MiCAR requires regulated custodians to only rely on authorized sub-custodians when outsourcing custody functions. This clause initially raised questions about whether MPC providers like Dfns could be seen as sub-custodians. Morgan Lewis addresses this directly. According to the interpretation developed through AMF precedent, sub-custody exists only when the delegate has actual control over the assets. A technology provider that cannot move assets, even if it manages key orchestration or storage, does not meet this test. Hence, Dfns does not act as a sub-custodian. It does not hold or control digital assets. It operates infrastructure that prevents it from doing so. The legal structure mirrors the operational design.

The substance of control in the context of MPC

The memorandum also goes deeper and challenges the notion that the mere possibility of access—even in edge cases like cyberattacks or software bugs—should be treated as control. The law, it argues, should be grounded in the normal course of business, not in theoretical failure modes. Just as we do not consider a traditional custodian liable for a natural disaster unless negligence is involved, we should not define control based on speculative risks.

This is particularly important in the context of MPC. Unlike multi-signature wallets, where control is shared across multiple key holders, MPC systems never generate or store a full key. Even if one party acts maliciously, it cannot reconstruct the private key or sign alone. Assuming that the architecture ensures that user authentication is always cryptographically required to trigger a signing process, then the control rests with the user, and no custody service exists.

Infrastructure ≠ Custody: Tech is tech, finance is finance

One of the more profound takeaways from this legal assessment is that MiCAR continues the evolution that began with the AMF’s early guidance: a clean separation between financial intermediation and infrastructure provision. Custody is not defined by how software works, but by who uses it and how. A platform that holds the signing secret and initiates API calls on behalf of users is a custodian. A platform that delegates that control to users, and cannot act without them, is not. The legal classification depends on the contractual and operational structure, not the existence of an API or the presence of an MPC algorithm for example. This distinction enables builders to decouple technical infrastructure from regulatory liability. It allows wallet platforms to offer user-controlled configurations. It enables institutions to build services with clarity on where the regulatory perimeter begins and ends.

The MiCAR framework is still evolving, however. Many questions remain about DeFi, staking, governance tokens, and token issuance among other items. But when it comes to custody, the law is already clear, and the analysis of Dfns’ delegated signing solution helps illuminate that clarity. Control is the legal crux. Not key generation. Not storage. Not software design. What matters is who can move the assets. In the case of Dfns, that answer is simple: the user. Which means that for those who rely on Dfns to build infrastructure, the regulatory perimeter stops at the edge of your system—not at the center of ours.

If you would like to access the full legal memorandum by Morgan Lewis, you can request it by contacting: sales@dfns.co.

‍