跨境资金与账户合规

技术服务还是支付业务？数字人民币项目的合规边界

一家技术公司为数字人民币项目开发系统、连接运营银行接口、配置智能合约并生成对账文件。合同写的是“技术服务”，资金也没有进入技术公司的银行账户。它是否仍可能越界从事支付业务？

提供技术服务与经营支付业务，需要依据实际功能区分。系统部署在谁的服务器上、合同叫什么，都只是判断线索；不能据此单独认定业务性质。

判断数字人民币项目是否涉及未经许可从事支付业务，不能只看合同名称，也不能只看资金有没有进入技术服务商的账户。更重要的是：谁接受支付指令，谁决定资金何时、向谁、按照什么条件转移，以及谁对用户和商户承担支付结果责任。

一、数字人民币项目为什么需要技术服务商？

2021年发布的《中国数字人民币的研发进展》白皮书及同期官方说明，以中心化管理、双层运营解释数字人民币的初期设计。它们可以帮助理解参与主体之间的分工，但不能替代项目上线时有效的管理要求、钱包协议和接口规则。

但一个具体应用场景很少只涉及人民银行和运营银行。数字人民币被嵌入预付消费、供应链、财政资金、平台分账或者园区管理系统后，通常还会出现技术开发商、场景运营方、聚合服务商、商户平台和设备供应商。

人民银行在2021年7月16日白皮书媒体吹风会上，将系统开发、场景拓展、业务处理和运维等纳入合作服务的讨论，同时强调厘清参与主体的权责。该说明支持理解合作生态，不是向任何技术公司授予支付经营资格，也不是数字人民币业务的普遍许可豁免。人民银行白皮书媒体吹风会文字实录

真正的问题不是技术公司能不能参与，而是参与到什么程度。

当技术公司只提供软件、设备和接口时，它通常仍是技术服务商；当它开始替用户管理钱包、替银行接收交易指令、替商户控制资金结算时，其业务性质就可能发生变化。

二、什么是法律意义上的支付业务？

《非银行支付机构监督管理条例》将非银行支付机构界定为：取得支付业务许可，从事根据用户提交的电子支付指令转移货币资金等支付业务的公司。条例同时规定，未经依法批准，任何单位和个人不得从事或者变相从事支付业务。

《非银行支付机构监督管理条例实施细则》第六十八条进一步说明，相关情形包括未经中国人民银行批准，根据用户提交的电子支付指令转移货币资金等，以及人民银行在有关业务规则中认定的其他情形。《条例》第二条、第六条、《实施细则》正式文本

在项目审查中，可以沿着以下三个环节核对事实。这是分析路径，不是额外创设的法定构成要件：

第一，用户提交指令。
付款人或者收款人向某个主体发出付款、扣款、退款或者分账请求。

第二，处理电子支付指令。
某个主体对指令进行接收、验证、修改、汇总、路由或者触发执行。

第三，转移货币资金。
处理结果直接导致资金从一个用户转移给另一个用户。

这些环节不能割裂使用：服务器接收到报文，不当然等于经营者在法律上独立接受支付指令；按确定规则传输信息、提供校验工具，也不当然构成支付业务。需要结合其是否作为经营主体为用户提供资金转移服务、具体授权、实质权限及适用业务规则综合判断。

采用数字人民币，并不能单独回答经营主体是否需要支付业务许可。本文以中国内地技术服务商为他人提供资金转移相关服务为讨论对象，不将银行业金融机构的业务资格与非银行支付机构许可混为一谈，也不把企业支付自身交易价款一概视为经营支付业务。具体项目还须核对数字人民币相关要求及合作机构的业务边界。

三、判断技术服务是否越界，重点看四项控制权

下面的“四项控制权”是本文用于识别实质分工的审查框架，不是监管部门公布的认定标准。单项技术权限、故障处置权限或商户推广行为，不足以自动得出需要许可的结论。

1. 谁控制钱包或者账户？

企业和用户的钱包是否由运营银行实名开立？技术服务商能否自行创建所谓“子账户”“商户余额”或者“内部钱包”？平台显示的余额，究竟是运营机构钱包中的真实数字人民币，还是技术公司数据库中的一笔内部记账？

如果总钱包由技术公司控制，不同用户或者商户的资金在其中混同，平台再通过内部账本登记各方余额，并决定何时、按照什么金额向商户结算，该结构可能同时呈现资金混同归集、类支付账户和商户资金再次清分结算（通常称为“二清”）的特征。这里的“资金池”和“二清”是风险结构描述，并非只要出现这些名称就能完成违法定性。

反之，如果所谓母钱包、子钱包由运营机构按适用规则开立、管理，能够核验相应权利主体和资金记录，技术公司仅展示交易信息、不能独立调度资金，就不能仅因存在汇总管理结构而认定其形成违法资金池。还应核对内部余额能否充值、流通、提现，以及商户是否必须等待平台二次结算。

“子钱包”“母子钱包”“智能合约钱包”等名称在不同产品中可能有不同含义，应以运营机构产品协议和系统记录为准，不能预设每个子钱包都是独立法律账户。仅把内部账簿命名为“数字人民币子钱包”，不会改变其法律性质。

2. 谁接收并处理支付指令？

用户点击“确认支付”以后，指令是直接发送给运营机构，还是先到技术公司的服务器？技术公司是原样传输，还是能够修改金额、收款人、支付时间和触发条件？

就支付许可这一维度而言，单纯提供通讯通道、加密传输或者标准化接口，通常更接近技术服务；数据安全、网络安全和外包管理义务仍应另行履行。但如果平台可以汇总多个订单、重新生成支付指令、替换收款对象，或者根据自己的判断决定是否执行，就不再只是传递信息。

判断标准不是系统有没有人工干预。即使全部由程序自动完成，也要继续追问：规则由谁制定，触发条件由谁修改，管理密钥由谁掌握，发生错误后谁可以撤销或者重发指令。

3. 谁控制资金流转和结算？

资金是否从付款人数字人民币钱包直接进入商户钱包？还是先进入平台控制的钱包，再由平台定期向商户划付？平台能否延迟付款、改变分账比例、冻结商户余额或者将一个商户的资金调度给另一个商户？

“资金没有进入技术公司自己的银行账户”不是决定性抗辩。资金可能登记在银行或运营机构系统中，但技术公司仍然掌握实际控制权。

如果平台在为他人提供资金转移服务时，能够独立决定哪些资金可以转出、什么时候转出以及最终付给谁，应重点审查其是否已经承担支付业务功能。与之不同，用户对自身付款作出的业务审批，或者技术公司依据明确授权执行不具有自主裁量的操作，不能仅凭存在后台权限就同样定性。

4. 谁管理商户并承担支付责任？

谁决定商户能否接入？谁与商户约定结算周期和手续费？谁审查商户身份、监测异常交易、处理退款和投诉？支付失败或者资金错付后，用户首先向谁主张？

如果运营机构依法履行客户识别、协议签订和交易管理等职责，技术公司仅在允许的外包范围内提供协助，双方角色相对清晰。但这不意味着运营机构须对一切损失兜底，技术公司仍应对自身违约、侵权或安全管理过错承担相应责任。

反之，如果技术公司独立拓展商户、确定费率、分配商户号、处置交易争议，而运营机构只在后台被动提供通道，合作结构就更需要按照业务实质重新评价。商户推广本身也不等于支付业务，应区分获客协助与核心业务控制。

例如，《条例》第二十一条、第二十二条对非银行支付机构的核心业务外包和商户管理作出限制。引用这些规定时，应注意其适用主体，不能未经分析就将针对非银行支付机构的全部义务直接套用于银行或普通技术供应商。《条例》相关条文

四、三类数字人民币技术服务场景

以上是支付许可风险筛查，不是全项目风险评级，更不是法律上的正式分类，不能代替对具体系统和适用规则的判断。其作用是提醒项目参与方：风险会随着技术服务商对账户、指令、资金和商户控制权的增加而上升。

五、最容易越界的五种项目设计

1. 一个总钱包加一套内部余额

平台以自己的或者关联方的钱包统一收款，再为每个商户建立内部余额，商户只能通过平台申请提现。

这种结构看似提高了分账效率，实质上可能形成“统一收款—内部记账—延后结算”的闭环。平台不仅提供系统，还可能承担储值、资金归集和支付结算功能。

2. 把一次授权理解为无限制扣款权

用户开通免密支付、子钱包或者自动扣款后，平台根据订单向运营机构发送指令。但授权并不意味着平台可以任意确定金额、收款方和扣款条件。

项目应当明确授权对象、使用场景、单笔和累计限额、有效期、撤销方式以及异常交易处理。授权范围越模糊，平台越可能从技术通道变成支付指令的实际发起人。

3. 智能合约由技术公司单方控制

智能合约可以按照消费进度、履约条件或者监管规则自动释放数字人民币。表面上是“代码执行”，但代码背后仍然存在规则制定者和管理权限持有人。

应查明谁可以修改释放条件、暂停尚未执行的指令、替换收款人或发起补发，以及这些操作是否需要运营机构和用户的有效授权。不能预设已经完成的交易可以回滚；纠错和退款须遵守具体产品规则。企业审查智能合约时，不能只审代码，还要审管理后台、密钥和紧急权限。相关支付完成与退款问题，可参见《数字人民币“支付即结算”，合同就履行完了吗？》。

4. 对账服务逐渐变成结算服务

技术公司最初只生成账单，后来又开始计算各商户应收金额、确定分账比例、下发划款文件并处理差错退款。

这里要区分依据既定合同机械计算、由有权主体复核确认，与平台独立确定收款人、分账比例并执行划款。生成对账文件或计算分账金额本身，不当然构成支付业务；能够独立改变结算结果并组织资金转移，才是应重点核查的风险。

5. 银行合作变成形式背书

部分项目认为，只要接入一家数字人民币运营银行，就不可能存在支付许可风险。

但银行合作并不是当然的合规豁免。仍需判断用户与谁签约、谁接受支付指令、银行是否实质审核业务、商户由谁管理、资金规则由谁决定，以及银行能否独立停止异常交易。

如果银行只提供底层钱包和接口，前端全部支付规则、商户体系和资金调度均由技术公司控制，技术公司的独立支付功能不会因“与银行合作”自动消失。

六、合同写“技术服务”能不能解决问题？

不能。

监管机关判断业务性质，通常会综合审查合同、系统架构、资金流向、实际权限和收费模式。将“支付服务费”改成“技术服务费”，或者在合同中声明“不提供支付服务”，都不能覆盖相反的业务事实。

但合同并非没有价值。对于拟定位为技术外包的项目，可以围绕以下事项设计并验证权限边界；这些是审查建议，不是一套适用于所有产品的统一法定条款：

• 钱包由运营机构开立和管理；
• 明确用户向谁作出支付授权、指令如何传输和由谁最终处理；技术中转不得变成未经许可的独立支付服务；
• 技术公司仅在适用规则、合作协议和有效授权范围内传输信息、执行技术操作；
• 技术公司不得未经有效授权自行改变金额、收款人和执行条件；重要变更应有审批与日志；
• 数字人民币直接在合法钱包之间转移；
• 客户识别、商户准入、交易监测和支付争议由相应责任主体完成；
• 区分支付认证凭证、主密钥与普通接口凭证，明确生成、托管和使用权限，禁止违规留存敏感认证信息或擅自发起、撤销交易；
• 项目终止后，接口、数据、在途交易和资金如何迁移。

合同只能证明权利边界，不能代替真实的权限隔离。系统后台与合同约定不一致时，实际运行方式往往更有解释力。

七、未经许可从事支付业务，会直接构成非法经营罪吗？

不一定。

在行政监管层面，《非银行支付机构监督管理条例》第四十七条规定，未经批准从事或者变相从事支付业务的，可以被取缔、没收违法所得并处以罚款；相关负责人和直接责任人员也可能被处罚。

其中，违法所得50万元以上的，并处违法所得一倍以上五倍以下罚款；没有违法所得或者不足50万元的，单处或者并处50万元以上200万元以下罚款。对条文规定的相关责任人员，另有警告及10万元以上50万元以下罚款的规定。《条例》第四十七条

刑事责任则需要进一步判断是否属于“非法从事资金支付结算业务”，并达到非法经营罪的入罪条件。最高人民法院、最高人民检察院的司法解释列举了利用受理终端或者网络支付接口虚构交易、为他人提供账户套现等情形，并规定相应的数额标准。关于非法从事资金支付结算业务的司法解释

因此，“未经许可从事支付业务”“非法从事资金支付结算业务”和“构成非法经营罪”是三个层次，不能直接画等号。

项目应先识别业务是否触及许可边界，再分别审查行政责任与刑事构成。不能反过来认为，只要没有赌博、电诈等背景，就一定不涉及非法经营罪；相关司法解释还规定了其他非法从事资金支付结算业务的情形，并对数额等入罪条件作出要求。涉及异常资金活动时，也应另行审查是否触及其他犯罪。

八、企业在项目上线前应当审查什么？

数字人民币项目不能只做一次合同审查。更有效的方法，是把业务流程、系统权限和合同责任放在一起审查。至少应当形成以下材料：

1. 资金流图：每一步资金从哪个钱包流向哪个钱包，是否经过平台归集。

2. 支付指令图：用户指令由谁接收、验证、生成、修改、转发和执行。

3. 权限矩阵：谁可以改金额、改收款人、冻结、退款、分账和重发交易。

4. 主体关系表：用户、商户、技术公司、场景方和运营机构分别与谁签约。

5. 钱包及账本说明：区分真实数字人民币钱包、银行内部账户与平台虚拟余额。

6. 商户管理方案：明确谁负责准入审核、持续监测、投诉和异常交易处置。

7. 证据保存清单：保存用户授权、接口报文、系统日志、规则版本、审批记录和交易凭证。

8. 退出与迁移预案：明确更换银行或者技术服务商后，在途交易、历史数据和管理权限如何承接。

如果无法用这些材料准确回答“谁控制资金、谁处理指令、谁承担责任”，项目的合规边界通常也还没有真正厘清。

FAQ

只开发数字人民币接口，需要支付业务许可吗？
单纯开发接口通常不因这一行为本身就需要支付业务许可。关键是技术公司是否作为经营主体为用户提供资金转移服务，以及实际授权、指令处理权限和适用业务规则。

资金从未进入技术公司的账户，就一定安全吗？
不一定。即使不占有资金，技术公司仍可能通过后台权限、智能合约或者结算规则实际控制资金。

与运营银行签署合作协议，是否就不会构成未经许可做支付？
不是。银行合作是重要的合规基础，但仍要审查双方的真实分工，特别是支付指令、商户管理、资金控制和争议责任。

把收费方式改成固定技术服务费，能否排除支付业务属性？
不能单凭固定收费排除。收费名称和方式不是决定因素；仍须审查业务功能、实际权限及其是否为他人经营资金转移服务。

使用数字人民币，为什么还要审查支付业务许可？
采用何种货币工具，与谁有资格为用户经营资金转移服务，是不同问题。使用数字人民币本身不构成许可豁免；也不能仅凭接入数字人民币就推定技术公司必须取得许可。

结语

数字人民币制度为技术公司参与系统开发和场景建设留有空间，但这种参与并不当然排除支付业务许可监管。边界不在于企业是否使用“支付”一词，也不完全取决于资金是否进入其自有账户，而要结合它是否独立接受和处理用户指令，以及对资金何时、向谁、按照什么条件转移享有何种实质控制权进行判断。

技术公司越接近提供工具，越属于技术服务；越接近独立制定并执行资金流转规则，越需要重新审视其是否已经成为事实上的支付业务经营者。 这是项目风险审查的方向，不是替代法定要件的单一认定公式。

对项目方而言，重要的不是在合同里证明自己“没有做支付”，而是让系统权限、资金路径和责任安排相互印证。审查结果若显示技术公司已经承担独立支付功能，应先调整业务边界，或依法解决相应资格问题，不能靠改名或格式条款掩盖实际业务。

资料来源与适用边界

本文基于截至2026年9月16日核验的公开资料，对此前专题稿作网站适配与准确性修订。四项控制权、场景分级和项目审查清单均为作者分析，不是监管部门发布的专项标准；文中场景为业务结构示例，不对应江恒律师经办案件。

• 《非银行支付机构监督管理条例》：国务院令第768号，2024年5月1日起施行。本文重点使用第二条、第六条、第十五条、第二十一条、第二十二条及第四十七条。第十五条另对单用途预付卡业务作有排除规定，不能将所有预付场景一概归入非银行支付业务。
• 《非银行支付机构监督管理条例实施细则》：中国人民银行令〔2024〕第4号，2024年7月9日公布并施行。本文引用正式文本第六十八条，不引用征求意见稿条号；亦可查看商务部公开文本。
• 人民银行《中国数字人民币的研发进展白皮书》媒体吹风会文字实录：2021年7月16日。仅用于说明早期运营设计和合作背景，不据此概括当前所有钱包的法律属性、计息、负债归属或具体功能。
• 最高人民法院、最高人民检察院《关于办理非法从事资金支付结算业务、非法买卖外汇刑事案件适用法律若干问题的解释》：2019年2月1日起施行，本文重点核对第一条、第三条，区分行政许可违规与刑事责任。

本文聚焦中国内地支付许可边界，不是对任何具体机构违法经营的认定，也不覆盖项目全部网络安全、数据、反洗钱、消费者保护或跨境合规义务。具体判断应结合上线时有效规则、合作主体资格、钱包及平台协议、系统权限与真实资金路径。