A technology company develops systems for a digital renminbi project, connects to the interfaces of operating banks, configures smart contracts and generates reconciliation files. The contract describes the engagement as 'technical services', and the funds do not enter the technology company's bank account. Could it nevertheless be acting beyond its scope by engaging in payment business?
The conclusion is: providing technical services for the digital renminbi does not, in itself, amount to engaging in payment business; however, if the technical service provider actually holds wallets or accounts, receives and processes users' payment instructions, controls the transfer of funds, or independently manages merchant and settlement rules, it may change from a system service provider into a de facto payment organizer.
In determining whether a digital renminbi project involves engaging in payment business without a licence, one cannot look only at the name of the contract, nor only at whether the funds enter the technical service provider's account.
More important is: who accepts payment instructions, who decides when, to whom and on what conditions funds are transferred, and who bears responsibility to users and merchants for the payment outcome.
I. Why do digital renminbi projects need technical service providers?
The digital renminbi adopts a two-tier operating system. The People's Bank of China is responsible for issuance, cancellation, inter-institutional interconnection and management of the wallet ecosystem, while operating institutions provide the public with wallet opening, exchange in and out, and circulation services. Once the digital renminbi is embedded in prepaid consumption, supply chains, fiscal funds, platform split settlement or industrial park management systems, technology developers, scenario operators, aggregation service providers, merchant platforms and equipment suppliers will usually also appear.
The White Paper on the Progress of Research and Development of China's Digital Renminbi issued by the People's Bank of China expressly states that operating institutions may jointly provide digital renminbi circulation services with relevant commercial institutions, including payment product innovation, system development, scenario expansion, market promotion, business processing and operations and maintenance. This means that there is institutional space for commercial institutions to participate in the technical development and scenario construction of the digital renminbi.
The real question, therefore, is not whether a technology company may participate, but to what extent. When a technology company only provides software, equipment and interfaces, it generally remains a technical service provider; when it begins to manage wallets on behalf of users, receive transaction instructions on behalf of banks, or control fund settlement on behalf of merchants, the nature of its business may change.
II. What is payment business in the legal sense?
Article 2 of the Regulations on the Supervision and Administration of Non-Bank Payment Institutions (hereinafter referred to as the Non-Bank Payment Regulations) defines a non-bank payment institution as a company that has obtained a payment business licence and engages in payment business such as transferring monetary funds according to electronic payment instructions submitted by users. The Regulations also provide that, without lawful approval, no entity or individual may engage in, or engage in disguised form, payment business.
The Implementing Rules of the Non-Bank Payment Regulations further characterize 'engaging in, or engaging in disguised form, payment business without approval' as: transferring monetary funds and other circumstances according to electronic payment instructions submitted by users without the approval of the People's Bank of China. There are three key terms here:
● First, instructions submitted by users. The payer or payee sends a request for payment, deduction, refund or split settlement to a certain entity.
● Second, processing electronic payment instructions. An entity receives, verifies, modifies, aggregates, routes or triggers the execution of instructions.
● Third, transferring monetary funds. The processing result directly causes funds to be transferred from one user to another user.
Therefore, the core of the payment business is not only "whose account the money passes through," but also "who actually organizes and controls the transfer of funds."
That digital renminbi is legal tender does not mean that all services provided around digital renminbi are automatically excluded from payment business regulation. The fact that a technical service provider does not touch traditional bank deposits does not automatically mean that it has not participated in the transfer of monetary funds.
III. To determine whether technical services cross the line, focus on four aspects of control
- Who controls the wallet or account?
Are the wallets of enterprises and users opened in their real names by the operating bank? Can the technical service provider itself create so-called "sub-accounts," "merchant balances" or "internal wallets"? Is the balance displayed on the platform actually real digital renminbi in the operating institution's wallet, or is it an internal bookkeeping entry in the technology company's database?
If the technology company pools funds in a master wallet and then records balances for different merchants or users through an internal ledger, the platform may in fact have already formed an independent set of stored-value and payment arrangements.
Genuine sub-wallets, parent-child wallets or smart contract wallets should be supported by the operating institution's system and be capable of corresponding to the relevant rights holders, fund balances and transaction records. Merely naming an internal ledger a "digital renminbi sub-wallet" will not change its legal nature.
- Who receives and processes payment instructions?
After a user clicks "confirm payment," is the instruction sent directly to the operating institution, or does it first reach the technology company's server? Does the technology company transmit it as is, or can it modify the amount, payee, payment time or trigger conditions?
Merely providing a communication channel, encrypted transmission or a standardized interface generally carries lower risk. However, if the platform can aggregate multiple orders, regenerate payment instructions, substitute the payee, or decide at its own discretion whether to execute, it is no longer merely transmitting information.
The test is not whether the system involves human intervention. Even if everything is completed automatically by programs, further verification is still required: who formulates the rules, who modifies the trigger conditions, who holds the management keys, and who can revoke or resend instructions after an error occurs.
- Who controls the flow and settlement of funds?
Do funds pass directly from the payer's digital renminbi wallet into the merchant's wallet? Or do they first enter a wallet controlled by the platform, which then pays the merchant periodically? Can the platform delay payment, change the split ratio, freeze the merchant's balance, or redirect one merchant's funds to another merchant?
The fact that "the funds did not enter the technology company's bank account" is not a decisive defense, because the funds may be recorded in the systems of a bank or operating institution while the technology company still holds actual control.
If the platform determines which funds may be transferred out, when they are transferred out, and to whom they are ultimately paid, its role is already close to payment transaction processing and is no longer that of a mere technology supplier.
- Who manages merchants and bears payment responsibility?
Who decides whether a merchant may be onboarded? Who agrees with the merchant on the settlement cycle and fees? Who verifies merchant identity, monitors abnormal transactions, and handles refunds and complaints? If a payment fails or funds are misdirected, to whom does the user first assert a claim?
If the operating institution completes customer identification, enters into the service agreement, reviews the transaction rules, and bears ultimate payment responsibility, the technology company's role is relatively clear.
Conversely, if the technology company independently develops merchants, sets fee rates, allocates merchant numbers, and handles transaction disputes, while the operating institution only passively provides the channel in the background, the cooperation structure is more likely to be re-evaluated according to the substance of the business.
IV. Three Types of Digital Renminbi Technical Service Scenarios
Lower risk
Common business arrangements
Develop front-end pages, standard interfaces, hardware devices, and operations and maintenance systems; transaction instructions go directly to the operating institution; funds are transferred directly between user and merchant wallets
Preliminary assessment
Generally closer to technology outsourcing
Medium risk
Common business arrangement
The platform aggregates orders, configures smart contracts, assists merchants with onboarding, and generates payment parameters or reconciliation files; some rules are configured by the platform
Preliminary assessment
Requires review of instruction authority, keys, merchant management, and settlement responsibilities
Relatively high risk
Common business arrangement
The platform pools funds and maintains internal bookkeeping, controls merchant balances, profit sharing, and withdrawals; it can change the payee, amount, or payment time; and it independently freezes, refunds, or deploys funds
Preliminary assessment
may be deemed to be engaging in, or engaging in a disguised form of, payment business
This tiering is not a formal legal classification and cannot replace an assessment of a specific system. Its purpose is to remind project participants that risk increases as a technology service provider's control over accounts, instructions, funds and merchants grows.
V. Five project designs most prone to overstepping boundaries
- A single master wallet plus a set of internal balances
The platform collects payments centrally through its own wallet or an affiliate's wallet, then creates an internal balance for each merchant, and merchants may only apply to the platform for withdrawal.
This structure appears to improve split-settlement efficiency, but in substance it may form a closed loop of "centralized collection—internal bookkeeping—deferred settlement." The platform not only provides a system but may also perform stored-value, fund pooling and payment settlement functions.
- Treating a single authorization as an unlimited right to deduct funds
After a user enables password-free payment, a sub-wallet or automatic deduction, the platform sends instructions to the operating institution based on orders. However, authorization does not mean the platform may arbitrarily determine the amount, payee and deduction conditions.
A project should clearly specify the authorized object, use scenarios, per-transaction and cumulative limits, validity period, revocation method and handling of abnormal transactions. The vaguer the scope of authorization, the more likely the platform is to change from a technical channel into the actual initiator of payment instructions.
- Smart contracts controlled unilaterally by a technology company
Smart contracts can automatically release digital renminbi according to consumption progress, performance conditions or regulatory rules. On the surface this is "code execution," but behind the code there are still rule-makers and holders of administrative authority.
Whoever can modify release conditions, suspend contracts, replace payees, manually make supplementary payments or roll back transactions may effectively control the funds. When reviewing smart contracts, an enterprise must review not only the code but also the management backend, keys and emergency permissions.
- Reconciliation services gradually turn into settlement services
The technology company initially only generated bills, but later began calculating the amounts receivable from each merchant, determining the profit-sharing ratio, issuing transfer documents, and handling erroneous refunds.
The boundary between "reconciliation" and "settlement" lies in whether the system objectively presents transactions that have already occurred, or further determines how funds should be divided and transferred. The more a technical service provider can alter settlement outcomes, the stronger the payment business attributes.
- Bank cooperation turns into formal endorsement
Some projects believe that as long as they connect to a digital renminbi operating bank, there is no payment licensing risk.
However, bank cooperation is not an automatic compliance exemption. The technology company still needs to determine with whom users sign contracts, who accepts payment instructions, whether the bank substantively reviews the business, who manages merchants, who determines the fund rules, and whether the bank can independently stop abnormal transactions.
If the bank only provides the underlying wallet and interfaces, while all front-end payment rules, the merchant system, and fund scheduling are controlled by the technology company, the technology company's independent payment function will not automatically disappear because of "cooperation with a bank."
VI. Can writing "technical services" in the contract solve the problem?
No.
When regulatory authorities determine the nature of a business, they typically comprehensively review the contract, system architecture, fund flows, actual authority, and fee model. Changing "payment service fee" to "technical service fee," or declaring in the contract that "no payment services are provided," cannot override contrary business facts.
But the contract is not without value; it should be consistent with system authority and at the same time clearly specify:
1. The wallet is opened and managed by the operating institution;
2. The user's payment instructions are issued directly to the operating institution;
3. The technology company only transmits information in accordance with the rules determined by the operating institution;
4. The technology company has no authority to change the amount, payee, or payment time;
5. Digital RMB is transferred directly between lawful wallets;
6. Customer identification, merchant onboarding, transaction monitoring, and payment disputes are handled by the corresponding responsible entities;
7. The technology company must not store authentication keys or initiate or revoke transactions without authorization;
8. How interfaces, data, in-transit transactions, and funds are to be migrated after the project is terminated.
A contract can only evidence the boundaries of rights; it cannot replace genuine segregation of authority. Where the system backend is inconsistent with the contractual arrangements, the actual mode of operation often carries greater explanatory weight.
VII. Does engaging in payment business without a license directly constitute the crime of illegal business operations?
Not necessarily.
At the administrative regulatory level, Article 47 of the Regulations on the Supervision and Administration of Non-Bank Payment Institutions provides that anyone engaging in, or engaging in disguised form in, payment business without approval may be banned, have illegal gains confiscated, and be fined; the responsible persons in charge and directly responsible personnel may also be penalized. Where the illegal gains reach RMB 500,000, a fine of not less than one time but not more than five times the illegal gains may additionally be imposed; where there are no illegal gains or the illegal gains are less than RMB 500,000, a fine of not less than RMB 500,000 but not more than RMB 2 million may be imposed alone or in addition.
Criminal liability, however, requires further determination of whether the conduct constitutes "illegally engaging in fund payment and settlement business" and meets the elements for the crime of illegal business operations. The judicial interpretations of the Supreme People's Court and the Supreme People's Procuratorate enumerate circumstances such as using acceptance terminals or online payment interfaces to fabricate transactions and providing accounts for others to obtain cash, and set out the corresponding monetary thresholds.
Therefore, “engaging in payment business without a license,” “illegally engaging in fund payment and settlement business,” and “constituting the crime of illegal business operations” are three distinct levels and cannot be directly equated.
For ordinary digital renminbi technology projects, the first thing that needs to be identified is the risk of administrative licensing and business rectification; only if a project simultaneously involves fictitious transactions, cash-out of funds, gambling, telecom fraud, money laundering, or other abnormal fund activities will criminal risk rise significantly.
VIII. What should enterprises review before a project goes live?
A digital renminbi project cannot be limited to a one-time contract review. A more effective approach is to review business processes, system permissions, and contractual responsibilities together. At a minimum, the following materials should be produced:
1. Fund flow chart: from which wallet to which wallet funds flow at each step, and whether they are collected through the platform.
2. Payment instruction chart: who receives, verifies, generates, modifies, forwards, and executes user instructions.
3. Permission matrix: who can change amounts, change payees, freeze, refund, split payments, and resend transactions.
4. Entity relationship table: with whom users, merchants, technology companies, scenario parties, and operating institutions respectively enter into contracts.
5. Wallet and ledger description: distinguish between genuine digital renminbi wallets, banks' internal accounts, and the platform's virtual balances.
6. Merchant management plan: specify who is responsible for access review, ongoing monitoring, complaints, and handling of abnormal transactions.
7. Evidence retention checklist: retain user authorizations, interface messages, system logs, rule versions, approval records, and transaction vouchers.
8. Exit and migration plan: specify how in-transit transactions, historical data, and management permissions will be taken over after a change of bank or technology service provider.
If these materials cannot be used to answer accurately 'who controls the funds, who processes instructions, and who bears responsibility,' the project's compliance boundaries have usually not yet been truly clarified.
Conclusion
The e-CNY framework leaves room for technology companies to participate in system development and scenario building, but such participation does not automatically exclude the application of payment business licensing regulation. The boundary does not lie in whether the enterprise uses the word 'payment,' nor does it depend entirely on whether funds enter its own accounts; rather, it lies in whether the enterprise can independently accept and process user instructions and has substantive control over when, to whom, and on what conditions funds are transferred.
The closer a technology company is to providing tools, the more it constitutes technical services; the closer it is to formulating and executing rules for the flow of funds, the more it needs to re-examine whether it has in fact become a payment business operator.
Note: This article is based on publicly searchable rules and materials as of the date of publication and is provided for general information reference only; it does not constitute legal advice for any specific project. The nature of an e-CNY project should be determined on a case-by-case basis in light of the cooperating entities, system permissions, fund paths, and actual operating methods.
