一家技术公司为数字人民币项目开发系统、连接运营银行接口、配置智能合约并生成对账文件。合同写的是“技术服务”，资金也没有进入技术公司的银行账户。它是否仍可能越界从事支付业务？
结论是：提供数字人民币技术服务，本身不等于从事支付业务；但如果技术服务商实际掌握钱包或账户、接收和处理用户支付指令、控制资金划转，或者独立管理商户与结算规则，就可能由系统服务商变成事实上的支付组织者。
判断数字人民币项目是否涉及未经许可从事支付业务，不能只看合同名称，也不能只看资金有没有进入技术服务商的账户。
更重要的是：谁接受支付指令，谁决定资金何时、向谁、按照什么条件转移，以及谁对用户和商户承担支付结果责任。
一、数字人民币项目为什么需要技术服务商？
数字人民币采用双层运营体系。人民银行负责发行、注销、跨机构互联互通和钱包生态管理，运营机构面向公众提供钱包开立、兑出兑回和流通服务。数字人民币嵌入到预付消费、供应链、财政资金、平台分账或者园区管理系统后，通常还会出现技术开发商、场景运营方、聚合服务商、商户平台和设备供应商。
人民银行发布的《中国数字人民币的研发进展白皮书》明确提出，运营机构可以与相关商业机构共同提供数字人民币流通服务，包括支付产品创新、系统开发、场景拓展、市场推广、业务处理和运维等。这意味着，商业机构参与数字人民币技术开发和场景建设本身具有制度空间。
所以真正的问题不是技术公司能不能参与，而是参与到什么程度。当技术公司只提供软件、设备和接口时，它通常仍是技术服务商；当它开始替用户管理钱包、替银行接收交易指令、替商户控制资金结算时，那业务性质就可能发生变化。
二、什么是法律意义上的支付业务？
《非银行支付机构监督管理条例》（以下简称《非银支付条例》）第二条将非银行支付机构界定为：取得支付业务许可，从事根据用户提交的电子支付指令转移货币资金等支付业务的公司。条例同时规定，未经依法批准，任何单位和个人不得从事或者变相从事支付业务。
《非银支付条例实施细则》进一步把“未经批准从事或者变相从事支付业务”认定为：未经中国人民银行批准，根据用户提交的电子支付指令转移货币资金等情形。这里有三个关键词：
● 第一，用户提交指令。付款人或者收款人向某个主体发出付款、扣款、退款或者分账请求。
● 第二，处理电子支付指令。某个主体对指令进行接收、验证、修改、汇总、路由或者触发执行。
● 第三，转移货币资金。处理结果直接导致资金从一个用户转移给另一个用户。
因此，支付业务的核心不只是“钱经过谁的账户”，还包括“谁实际组织和控制资金转移”。
数字人民币是法定货币，并不代表围绕数字人民币开展的所有服务都自动排除支付业务监管。技术服务商没有碰到传统银行存款，也不当然等于它没有参与货币资金转移。
三、判断技术服务是否越界，重点看四项控制权
1. 谁控制钱包或者账户？
企业和用户的钱包是否由运营银行实名开立？技术服务商能否自行创建所谓“子账户”“商户余额”或者“内部钱包”？平台显示的余额，究竟是运营机构钱包中的真实数字人民币，还是技术公司数据库中的一笔内部记账？
如果技术公司以一个总钱包归集资金，再通过内部账本给不同商户或用户登记余额，平台实际上可能已经形成一套独立的储值和支付安排。
真正的子钱包、母子钱包或者智能合约钱包，应由运营机构系统支持并能够与相应权利主体、资金余额和交易记录对应。仅仅把内部账簿命名为“数字人民币子钱包”，不会改变它的法律性质。
2. 谁接收并处理支付指令？
用户点击“确认支付”以后，指令是直接发送给运营机构，还是先到技术公司的服务器？技术公司是原样传输，还是能够修改金额、收款人、支付时间和触发条件？
单纯提供通讯通道、加密传输或者标准化接口，风险通常较低。但如果平台可以汇总多个订单、重新生成支付指令、替换收款对象，或者根据自己的判断决定是否执行，就不再只是传递信息。
判断标准不在于系统有没有人工干预，即使全部由程序自动完成，也要继续核实：规则由谁制定，触发条件由谁修改，管理密钥由谁掌握，发生错误后谁可以撤销或者重发指令。
3. 谁控制资金流转和结算？
资金是否从付款人数字人民币钱包直接进入商户钱包？还是先进入平台控制的钱包，再由平台定期向商户支付？平台能否延迟付款、改变分账比例、冻结商户余额或者将一个商户的资金调度给另一个商户？
“资金没有进入技术公司的银行账户”不是决定性抗辩，因为资金可能登记在银行或运营机构系统中，但技术公司仍然掌握实际控制权。
如果平台决定哪些资金可以转出、什么时候转出以及最终付给谁，其角色已经接近支付交易处理，而不再是单纯的技术供应商。
4. 谁管理商户并承担支付责任？
谁决定商户能否接入？谁与商户约定结算周期和手续费？谁审查商户身份、监测异常交易、处理退款和投诉？支付失败或者资金错付后，用户首先向谁主张？
如果运营机构完成客户识别、签订服务协议、审核交易规则并承担最终支付责任，技术公司的角色相对清晰。
反之，如果技术公司独立拓展商户、确定费率、分配商户号、处置交易争议，而运营机构只在后台被动提供通道，合作结构就更容易被按照业务实质重新评价。
四、三类数字人民币技术服务场景
较低风险
常见业务安排
开发前端页面、标准接口、硬件设备和运维系统；交易指令直接进入运营机构；资金在用户与商户钱包之间直接转移
初步判断
通常更接近技术外包
中等风险
常见业务安排
平台汇总订单、配置智能合约、协助商户接入、生成支付参数或者对账文件；部分规则由平台配置
初步判断
需要审查指令权限、密钥、商户管理和结算责任
较高风险
常见业务安排
平台归集资金后内部记账，控制商户余额、分账和提现；可以改变收款人、金额或支付时间；独立冻结、退款或调度资金
初步判断
可能被认定为从事或者变相从事支付业务
这个分级不是法律上的正式分类，也不能代替对具体系统的判断。其作用是提醒项目参与方：风险会随着技术服务商对账户、指令、资金和商户控制权的增加而上升。
五、最容易越界的五种项目设计
1. 一个总钱包加一套内部余额
平台以自己的或者关联方的钱包统一收款，再为每个商户建立内部余额，商户只能通过平台申请提现。
这种结构看似提高了分账效率，实质上可能形成“统一收款—内部记账—延后结算”的闭环。平台不仅提供系统，还可能承担储值、资金归集和支付结算功能。
2. 把一次授权理解为无限制扣款权
用户开通免密支付、子钱包或者自动扣款后，平台根据订单向运营机构发送指令。但授权并不意味着平台可以任意确定金额、收款方和扣款条件。
项目应当明确授权对象、使用场景、单笔和累计限额、有效期、撤销方式以及异常交易处理。授权范围越模糊，平台越可能从技术通道变成支付指令的实际发起人。
3. 智能合约由技术公司单方控制
智能合约可以按照消费进度、履约条件或者监管规则自动释放数字人民币。表面上是“代码执行”，但代码背后仍然存在规则制定者和管理权限持有人。
谁可以修改释放条件、暂停合约、替换收款人、人工补发或者回滚交易，谁就可能实际控制资金。企业审查智能合约时，不能只审代码，还要审管理后台、密钥和紧急权限。
4. 对账服务逐渐变成结算服务
技术公司最初只生成账单，后来又开始计算各商户应收金额、确定分账比例、下发划款文件并处理差错退款。
“对账”和“结算”的边界，在于系统是在客观展示已经发生的交易，还是进一步决定资金应当如何划分和转移。技术服务商越能改变结算结果，支付业务属性越强。
5. 银行合作变成形式背书
部分项目认为，只要接入一家数字人民币运营银行，就不存在支付许可风险。
然而，银行合作并不是当然的合规豁免。技术公司仍需判断用户与谁签约、谁接受支付指令、银行是否实质审核业务、商户由谁管理、资金规则由谁决定，以及银行能否独立停止异常交易。
如果银行只提供底层钱包和接口，前端全部支付规则、商户体系和资金调度均由技术公司控制，技术公司的独立支付功能不会因“与银行合作”自动消失。
六、合同写“技术服务”能不能解决问题？
不能。
监管部门判断业务性质，通常会综合审查合同、系统架构、资金流向、实际权限和收费模式。将“支付服务费”改成“技术服务费”，或者在合同中声明“不提供支付服务”，都不能覆盖相反的业务事实。
但合同也不是没有价值，它应当与系统权限保持一致，同时明确：
1 钱包由运营机构开立和管理；
2 用户支付指令直接向运营机构发出；
3 技术公司仅按照运营机构确定的规则传输信息；
4 技术公司无权改变金额、收款人和支付时间；
5 数字人民币直接在合法钱包之间转移；
6 客户识别、商户准入、交易监测和支付争议由相应责任主体完成；
7 技术公司不得保存认证密钥或者擅自发起、撤销交易；
8 项目终止后，接口、数据、在途交易和资金如何迁移。
合同只能佐证权利边界，不能代替真实的权限隔离。系统后台与合同约定不一致时，实际运行方式往往更有解释力。
七、未经许可从事支付业务，会直接构成非法经营罪吗？
不一定。
在行政监管层面，《非银支付条例》第四十七条规定，未经批准从事或者变相从事支付业务的，可以被取缔、没收违法所得并处以罚款；相关负责人和直接责任人员也可能被处罚。其中，违法所得达到50万元的，可以并处违法所得一倍以上五倍以下罚款；没有违法所得或者不足50万元的，可以单处或者并处50万元以上200万元以下罚款。
刑事责任则需要进一步判断是否属于“非法从事资金支付结算业务”，并达到非法经营罪的入罪条件。最高人民法院、最高人民检察院的司法解释列举了利用受理终端或者网络支付接口虚构交易、为他人提供账户套现等情形，并规定相应的数额标准。
因此，“未经许可从事支付业务”“非法从事资金支付结算业务”和“构成非法经营罪”是三个层次，不能直接画等号。
对普通数字人民币技术项目来说，首先需要识别的是行政许可和业务整改风险；如果项目同时涉及虚假交易、资金套现、赌博、电诈、洗钱或者其他异常资金活动，刑事风险才会显著上升。
八、企业在项目上线前应当审查什么？
数字人民币项目不能只做一次合同审查。更有效的方法，是把业务流程、系统权限和合同责任放在一起审查。至少应当形成以下材料：
1 资金流图：每一步资金从哪个钱包流向哪个钱包，是否经过平台归集。
2 支付指令图：用户指令由谁接收、验证、生成、修改、转发和执行。
3 权限矩阵：谁可以改金额、改收款人、冻结、退款、分账和重发交易。
4 主体关系表：用户、商户、技术公司、场景方和运营机构分别与谁签约。
5 钱包及账本说明：区分真实数字人民币钱包、银行内部账户与平台虚拟余额。
6 商户管理方案：明确谁负责准入审核、持续监测、投诉和异常交易处置。
7 证据保存清单：保存用户授权、接口报文、系统日志、规则版本、审批记录和交易凭证。
8 退出与迁移预案：明确更换银行或者技术服务商后，在途交易、历史数据和管理权限如何承接。
如果无法用这些材料准确回答“谁控制资金、谁处理指令、谁承担责任”，项目的合规边界通常也还没有真正搞清楚。
结语
数字人民币制度为技术公司参与系统开发和场景建设留有空间，但这种参与并不当然排除支付业务许可监管。边界不在于企业是否使用“支付”一词，也不完全取决于资金是否进入自有账户，而在于它是否能够独立接受和处理用户指令，并对资金何时、向谁、按照什么条件转移享有实质控制权。
技术公司越接近提供工具，越属于技术服务；越接近制定并执行资金流转规则，越需要重新审视其是否已经成为事实上的支付业务经营者。
说明：本文基于文章发布时公开可检索的规则和资料进行研究，仅供一般信息参考，不构成针对具体项目的法律意见。数字人民币项目的性质应结合合作主体、系统权限、资金路径及实际运营方式具体判断。
作者：江恒律师