Reference · Custody models
Custody models, and what each one triggers
Institutions usually pick a custody provider first and discover the regulatory consequence second. It works better the other way round.
- Licensable activity
- Custody on behalf of clients
- Regime
- MiCAR, formerly KWG (DE)
- What triggers it
- Control of the keys
- Our role
- We build. We do not custody.
The model decides the licence
Custody is not a product category, it is a legal consequence of an architecture. The question regulators ask is narrow: can this firm move the assets without the client? If yes, it is holding them on the client's behalf and that is a licensable activity. If no, it is not — regardless of how much of the interface the firm operates, how the assets are displayed, or whose brand is on the app. Teams that decide the architecture after selecting a vendor end up needing a permission they did not budget for.
Three models, three different answers
In a full custody model the institution holds the keys itself and carries the permission, the segregation duties and the insurance question. In a delegated model a licensed custodian holds them and the institution carries counterparty risk instead of a licence — this is the common bank arrangement. In a non-custodial model the client holds the keys and nobody is custodying anything; the institution provides software, interface and support. The third is not a loophole. It is a genuine trade: you drop the permission requirement and you take on key recovery, user error and support burden that a custodian would otherwise absorb.
Germany specifically
Crypto custody has been a licensable banking activity in Germany since 2020, when Kryptoverwahrgeschäft was written into the Banking Act and made subject to BaFin authorisation. MiCAR now covers the same activity as one of its enumerated crypto-asset services, with transitional arrangements carrying existing national permissions across. The practical effect for a German institution is that custody was never the unregulated part, and the firms treating MiCAR as the first time custody became supervised are working from a misreading.
Staking is where this gets misread
Offering staking to clients does not automatically mean custodying their assets. In a delegated proof-of-stake network, delegation assigns validation rights to a validator while the tokens stay under the holder's own key — the validator cannot move them, and slashing risk is not the same thing as control. An institution can therefore route client delegation to validators without ever taking custody. What does change the answer is pooling client assets into an omnibus position, taking the keys in order to delegate, or issuing a claim against the institution instead of an on-chain position. The distinction is not academic: it decides whether a staking product sits inside the permission you already hold.
Access is not the same as custody
The newer architectures separate the two deliberately. Threshold signatures split a key so that no single party ever reconstructs it; scoped permissions let a piece of software initiate a specific action without being able to initiate any other; hardware-isolated execution keeps the fragments apart. MoonPay's PayBox, launched in July 2026, is the clearest recent example: it lets an assistant prepare and execute payments while stating plainly that the agent never holds a key. This is the same structural claim we make about our own consumer product, and it is the direction institutional infrastructure is moving — permissioned access to assets the institution does not hold.
What we do here, precisely
We are not a custodian and we do not want to be. We hold no client assets, we operate no omnibus wallet, and we hold no custody permission. What we do is build the systems: key management using threshold cryptography, delegation and settlement flows, the dashboards that supervise them, and the agent layer on top. When a project genuinely needs a licensed custodian we integrate one rather than pretend the requirement away — that is exactly how the fiat leg of our own consumer product works. If a vendor tells you their architecture removes a permission you would otherwise need, ask them which specific action they can take without the client, and read the answer carefully.
Common questions
Is an MPC wallet custody?
It depends entirely on where the shares sit. If the provider holds enough shares to sign without the client, that is control and therefore custody, whatever the marketing says. If signing genuinely requires a share only the client has, the provider cannot move the assets and is not custodying them. MPC is a technique, not a regulatory status — two products using the same cryptography can land on opposite sides of the line.
Does a bank need a custody permission to offer staking?
Not inherently. Delegation in a proof-of-stake network transfers validation rights, not the assets, and the holder's key continues to control them. The permission question turns on how the bank implements it: routing a client's own delegation is a different activity from pooling client tokens, holding the keys to delegate on their behalf, or issuing a claim against the bank. Most staking products that require a permission require it because of the implementation, not because staking was offered.
Can an AI agent move funds without anyone custodying them?
Yes, and that is the point of the design. The agent is granted a scoped, revocable permission to initiate a defined action; the signature still requires material the agent does not have. PayBox is built on that separation and so is our own product. What it does not remove is the operational question of what happens when the permission is too broad, which is why spending limits and single-use approvals matter more than the cryptography in practice.
Does Noctra Labs offer custody?
No. We hold no client assets and no custody permission, and nothing on this page should be read as offering one. We build the software — key management, delegation and settlement flows, dashboards, agent layers — for institutions and protocols that operate under European rules. Where a licensed custodian is genuinely required, we integrate one.
What does non-custodial cost us in practice?
Support and recovery. A custodian absorbs forgotten credentials, mistaken transfers and account takeovers as an operational cost; a non-custodial product hands the first back to the user and cannot reverse the second. Passkeys and social or threshold recovery reduce the sharpness of that, but they do not remove it. If your client base cannot tolerate irreversible user error, the honest answer is a licensed custodian, not a cleverer wallet.
Where does this leave the MiCAR question?
Custody is one of the enumerated crypto-asset services, so the model you choose feeds directly into whether you need a CASP authorisation and for which services. It is worth settling the architecture before the application, because the service list you apply for is the thing the whole file is built around. We wrote up that side separately.
This is not legal advice
We are engineers who build non-custodial systems, not a law firm and not a custodian. This page reflects how we read the rules for our own work. Whether a specific design triggers a permission is a question for counsel and your supervisor, and the answer turns on details this page cannot know.
Working out which model fits?
We build key management, delegation and settlement systems for institutions operating under European rules, and audit the protocols underneath. Two sentences about what you are building is enough to start.