先看谁能动资产，而不是谁持有一个密钥
审核钱包时，最有价值的材料通常不是宣传页，而是权限说明：谁生成密钥，谁保存分片，谁能恢复账户，谁能改变签名规则，平台停服后用户能否自行转出资产。MPC、多签和智能合约钱包都是技术安排，不能仅凭名称判断是否属于托管。尤其要检查日常流程以外的管理员权限，避免前台显示“用户签名”，后台实际上仍能单独移动资产。
美国规则可以作参考，不能当全球通行证
美国FinCEN的2019年指引区分钱包服务的实际控制模式，也区分开发软件与利用软件经营资金传输。其多签分析允许在特定事实下，将仅提供额外验证、并不接受和传输价值的服务与托管钱包区别处理。这是美国联邦反洗钱框架下的判断，不等于已经回答美国各州或其他国家的许可问题。
在欧盟，MiCA第3条分别列出托管、兑换、接收和传递订单、代客转移等服务。因此，即使某项设计不属于托管，也不能跳过其他服务项目。判断顺序应是逐项识别功能，而不是先获得“非托管”的产品标签，再据此排除全部监管。
两个都叫自托管的钱包，结论可能不同
假设A公司销售离线签名软件，用户独立生成和保存密钥，公司不能恢复、代签或替用户安排交易；B公司同样宣传自托管，但可以恢复账户权限，并在用户授权后自动选择兑换路径、完成付款。这不是对两家公司直接作出持牌结论，而是说明B需要提交更多控制权和交易服务事实，不能照搬A的分析。
恢复功能尤其需要拆开看：协助用户找回登录界面，与重建能够处分资产的权限不是一回事。应让技术团队用实际测试证明权限边界，并把测试结果与合同、帮助中心和客服口径逐一对齐。
上线前留下可复核的功能边界
建议按“现有版本—目标国家—面向客户”制作审查记录，明确哪些功能只提供信息、哪些涉及资产控制或交易执行。新增自动转账、第三方出入金、会话密钥或收益功能时，应重新审查，而不是沿用最初的软件结论。安全审计可以验证代码风险，但不能替代业务定性；法律审查也不能代替密钥安全测试。
行动建议
- 形成密钥、恢复、升级和转账权限矩阵，包含管理员及供应商权限。
- 分别测试正常转账、用户丢失凭证和平台停服三种情形。
- 把钱包、兑换、出入金和自动付款逐项对应目标法域要求。
- 核对自托管宣传与真实权限，删去无条件“无需牌照”的表述。
以上内容仅供信息浏览和参考，不构成法律意见；如有具体事项，建议咨询专业律师。
参考依据
- FIN-2019-G001：可兑换虚拟货币商业模式指引，第1.1、4.2节 — 美国FinCEN
- MiCA第3条：定义 — 欧盟法规／ESMA官方规则库
