First, determine who can move the assets, not who holds a key
When reviewing a wallet, the most valuable materials are usually not the marketing pages but the permission descriptions: who generates the keys, who stores the shards, who can recover the account, who can change the signing rules, and whether users can transfer assets out on their own after the platform ceases operations. MPC, multisignature and smart contract wallets are all technical arrangements, and whether they constitute custody cannot be determined by name alone. In particular, administrative permissions outside day-to-day processes should be examined to avoid a situation where the front end displays "user signature" while the back end can in fact still move assets unilaterally.
US rules can serve as a reference, but they are not a global passport
The 2019 guidance of the US Financial Crimes Enforcement Network (FinCEN) distinguishes between the actual control models of wallet services, and also distinguishes between developing software and using software to operate money transmission. Its multisignature analysis permits, under specific facts, services that merely provide additional verification and do not accept and transmit value to be treated differently from custodial wallets. This is a determination under the US federal anti-money laundering framework and does not mean that licensing questions in US states or other countries have already been answered.
In the EU, Article 3 of MiCA separately lists services such as custody, exchange, reception and transmission of orders, and transfer of assets on behalf of clients. Therefore, even if a design does not constitute custody, it cannot skip the other service categories. The assessment should proceed by identifying functions item by item, rather than first obtaining a "non-custodial" product label and then excluding all regulation on that basis.
Two wallets both called self-custodial may lead to different conclusions
Assume Company A sells offline signing software, users independently generate and store keys, and the company cannot recover, sign on behalf of, or arrange transactions for users; Company B likewise markets itself as self-custodial, but can recover account permissions and, after user authorization, automatically select exchange paths and complete payments. This is not a direct licensing conclusion about the two companies, but an explanation that Company B needs to submit more facts about control and transaction services and cannot simply copy Company A's analysis.
Recovery functions in particular need to be examined separately: helping a user recover access to a login interface is not the same thing as reconstructing permissions capable of disposing of assets. The technical team should be asked to demonstrate the permission boundaries through actual testing, and the test results should be aligned one by one with the contracts, help center and customer service statements.
Leave reviewable functional boundaries before launch
It is advisable to prepare a review record organized by "current version—target countries—customer-facing," clearly identifying which functions only provide information and which involve asset control or transaction execution. When automatic transfers, third-party deposits and withdrawals, session keys or yield functions are added, the review should be conducted anew rather than relying on the original software conclusion. Security audits can verify code risks but cannot replace business characterization; legal review also cannot replace key security testing.
Recommended actions
- Create a permission matrix covering keys, recovery, upgrades and transfers, including administrator and vendor permissions.
- Test three scenarios separately: a normal transfer, a user losing credentials, and the platform ceasing service.
- Map the wallet, exchange, fiat on-ramp and off-ramp, and automatic payments one by one against the requirements of the target jurisdiction.
- Verify the self-custody marketing claims against the actual permissions, and delete the unconditional statement that "no license is required."
This content is for general information only and does not constitute legal advice. Please consult a qualified lawyer about specific matters.
References
- FIN-2019-G001: Guidance on Convertible Virtual Currency Business Models, Sections 1.1 and 4.2 — U.S. FinCEN
- MiCA Article 3: Definitions — EU regulations / ESMA official rulebook
