先界定“数字钱包”究竟管理什么
数字钱包可能只是账户服务的交互入口，也可能承担余额展示、收付款、凭证保存、密钥管理或交易签名等职责。商业银行确认边界时，第一步应明确钱包管理的是银行账户中的记账余额、支付凭证，还是用户自行控制的某类私钥资产。不同对象对应不同的账务关系、授权方式和风险责任，不能因为都使用“钱包”一词就视为同一种产品。
参考钱包架构可以发现，接收、签名和网络交互并非不可拆分的整体：一个组件可以负责生成或分发公钥，另一个组件负责签名，网络组件负责获取状态和广播交易。将这一思路用于银行产品时，可把余额查询、收款展示、付款发起、交易授权、账务记账和对外通信分别列为功能模块，再逐项确认由银行、合作方还是用户设备承担。
用六个问题划定核心边界
一是资产归属与记账位置。应明确钱包余额是否对应银行账户或银行系统中的可核验记录，钱包本身是否只是操作界面。二是资金控制权。若付款最终由银行账户权限决定，钱包通常不能脱离账户授权独立完成转移；若由用户设备中的私钥直接签名，则应单独评估密钥丢失、盗用和恢复机制。三是授权范围。应区分登录认证、访问令牌使用、付款授权和高风险操作复核，不能用一次登录替代全部授权。
四是系统职责。余额查询、交易创建、签名、风控校验、账务入账和通知发送应有清晰的责任边界及审计记录。五是安全边界。RFC 9449所描述的DPoP机制，是在应用层通过公私钥证明把OAuth访问令牌约束到持有私钥的一方，可降低令牌被窃取后被他人重放的风险；它不是客户身份认证的替代品，也不能替代HTTPS或业务层的付款确认。六是异常处置，包括设备丢失、密钥不可用、令牌失效、重复请求和争议交易的暂停、恢复与追溯。
安全功能与业务功能要分开确认
DPoP适合放在接口访问安全边界中考察：客户端为请求生成与请求相关的证明，服务端验证令牌与密钥之间的绑定。由此可以确认的是“谁持有相应密钥并使用接口”，不能直接推出“该用户有权支付某笔资金”。付款仍需结合账户权限、交易限额、收款方校验、风险控制和必要的二次确认。
同样，密钥保存在设备、专用硬件或隔离环境中，只能说明控制方式可能不同，不代表银行已经完成了客户身份核验、资金清算或争议处理。商业银行在宣传数字钱包时，宜分别说明安全令牌、设备密钥、账户余额和付款授权的关系，避免把“令牌不可重放”“私钥在本地保存”等技术表述误解为资金绝对安全或交易不可撤销。
适用条件与常见问题
这套边界方法适用于以移动应用、网页或开放接口提供钱包功能的银行产品，也适用于银行与外部支付服务、设备厂商或其他系统协作的场景。它只能帮助梳理技术和产品职责，不能替代适用的支付、数据保护、客户身份识别、外包管理及消费者权益要求。涉及具体业务上线时，还应由合规、法律、安全、运营和会计团队共同确认。
常见问题一：接入DPoP后，是否可以不做其他认证？不能。DPoP主要约束令牌使用者与密钥之间的关系，不等同于客户身份认证，也不等同于付款授权。问题二：数字钱包是否必须保存私钥？不一定。若钱包只提供银行账户查询和付款发起，签名或关键授权可以由受控的银行系统完成；若产品让用户直接控制某类私钥，则必须另行定义密钥备份、恢复和丢失责任。
常见问题三：把收款、签名和网络通信拆成不同模块后，边界是否自动清楚？也不自动清楚。还需规定模块间传递的数据、可执行的操作、权限校验、日志留存和故障处理。问题四：能否把其他类型的钱包资料直接套用于银行钱包？不能。相关资料可用于理解模块化密钥管理和签名流程，但不能据此认定银行产品的资产属性、监管定位或客户责任。