What Value-Added Telecom Licenses Do Developers Need for Self-Built SMS Verification Services Used for Testing?
A Compliance Guide for Chinese Developers and Startups
Why this question matters — and why the answer is not "always yes" or "always no"
China's telecommunications regulatory framework — anchored by the Telecommunications Regulations (《电信条例》) and the Administrative Measures for Telecommunications Business Licensing (《电信业务经营许可管理办法》) — draws a sharp distinction between internal use and providing services to the public. The legal obligations that attach to each are fundamentally different. The mistake that many developers make is assuming that "I'm sending SMS messages, so I must need a license" — or the opposite mistake, "I'm just a small operation, so I don't." Neither assumption is reliably correct. The answer depends on the specific architecture and operational model.
Three scenarios — three legal boundaries
Scenario A: Pure internal R&D testing No License Required
Characteristics: The SMS verification service is deployed on the company's internal network. It is used exclusively by the company's own development and testing teams. All SIM cards and phone numbers are registered under the company's real name. The service is not made available to external parties, no fees are charged, and no third-party user data is involved.
Legal analysis: Article 8 of the Telecommunications Regulations defines "telecommunications business" as the provision of telecommunications services to the public. The Ministry of Industry and Information Technology (MIIT), in multiple official Q&A releases and regulatory guidance documents, has consistently clarified that purely internal, self-used systems that do not serve external users do not constitute "telecommunications business operations" and do not require a value-added telecommunications license. This is the safest harbour available to developers.
Scenario B: Using a third-party SMS platform API No SP License Required — Provider's License Covers You
Characteristics: Your service is offered to external users — for example, a SaaS product that sends SMS verification codes to end users during login. However, the SMS messages are not sent through your own direct carrier connection. Instead, your backend calls the API of a licensed service provider such as Tencent Cloud SMS, Alibaba Cloud SMS, or Huawei Cloud SMS. These providers hold the necessary value-added telecommunications licenses.
Legal analysis: In this architecture, you are not the "telecommunications business operator." You are the customer of a licensed operator. The licensed provider is the entity that connects to the carrier network and transmits the messages. Your legal obligation is not to obtain a telecommunications license but to ensure that your use of the provider's service is compliant — which includes signing a proper service agreement, not using the service for fraudulent or illegal purposes, and maintaining appropriate data protection practices under the Personal Information Protection Law. The MIIT regulatory framework treats this as a B2B service relationship, not as unlicensed telecommunications operation.
Scenario C: Self-built gateway directly connected to a carrier SP License Required
Characteristics: Your backend connects directly to the SMS gateway of China Mobile, China Unicom, or China Telecom through a dedicated port — typically using an 106-prefix service number allocated specifically for commercial SMS delivery. You manage your own SMPP connection, message routing, and delivery infrastructure. You are sending messages on your own behalf, not through a licensed intermediary.
Legal analysis: Under the Classification Catalogue of Telecommunications Services (《电信业务分类目录》), the transmission of information — including SMS, MMS, and voice messages — through carrier networks to end users constitutes "information services business" (信息服务业务), which is a Category B25 value-added telecommunications service. The operator of such a service must hold an SP License (Service Provider License). This requirement applies regardless of the content of the messages — whether they are verification codes, marketing notifications, or transactional alerts. The regulatory logic is straightforward: if you are the entity that directly interfaces with the carrier's network to inject messages, you are the telecommunications service provider, and you must be licensed.
The three licenses developers most commonly confuse
| License | Core Business Activity | Typical Example |
|---|---|---|
| SP License (信息服务业务) B25 — Value-Added Telecom |
Sending information — SMS, MMS, voice — through carrier networks to end users via dedicated channels (e.g., 106 port numbers) | Sending SMS verification codes, marketing SMS, app push notifications via SMS |
| Call Center License (呼叫中心业务) B24 — Value-Added Telecom |
Providing consultation and services to users through fixed-line, mobile, or VoIP terminals — inbound and outbound | Customer service hotlines, outsourced telemarketing operations |
| ICP License (互联网信息服务) B25 — Value-Added Telecom · Internet |
Operating a website or app that provides information or services to the public for a fee — including membership subscriptions, paid content, or transaction platforms | Paid content websites, e-commerce platforms, information portals with premium features |
Key distinction for developers: If your app has a website where users pay to access premium content, you need an ICP License (the commercial kind, ICP证 — not just the filing, ICP备案). If your backend sends SMS messages to users through a direct carrier connection, you need an SP License. These are separate regulatory obligations, and holding one does not satisfy the requirement for the other. If your business involves both — a paid content platform that also sends SMS notifications through its own gateway — you need both.
If you cross the boundary into "providing services to the public" — what are the hard requirements for an SP License?
For developers who determine that their architecture falls within Scenario C — or for those planning to scale from internal testing to a public SMS service — the SP License application is not a trivial administrative form. The MIIT and provincial communications administrations impose statutory threshold requirements designed to ensure that license holders are established, capitalised, and operationally capable of providing stable telecommunications services. These are not negotiable.
| Requirement | Provincial SP License (省内) | Cross-Regional SP License (跨地区) |
|---|---|---|
| Corporate structure | Must be a pure domestic-capital company — no foreign investment of any percentage is permitted (Article 10, Administrative Licensing Regulations for Foreign-Invested Telecommunications Enterprises) | |
| Registered capital (minimum) | 1 million RMB | 10 million RMB |
| Business scope | Must explicitly include "telecommunications business" (电信业务) or "value-added telecommunications services" (增值电信业务) in the company's business registration | |
| Personnel | Must have dedicated telecommunications professionals with relevant technical qualifications; must have social insurance contribution records demonstrating employment | |
| Facilities | Must have physical office premises, server infrastructure, and network equipment appropriate to the proposed service scope | |
| Service capability | Must demonstrate long-term service provision capability — including technical support, complaint handling, and regulatory compliance systems | |
| No disqualifying history | The company and its legal representative must have no record of major regulatory violations or criminal penalties related to telecommunications operations within the preceding three years | |
| Typical processing time | 3–6 months | 6–9 months |
For a small startup or independent developer, the capital requirements alone are typically prohibitive. A cross-regional SP License — necessary if your user base spans multiple provinces, which is the case for virtually any internet-based service — requires 10 million RMB in registered capital. This is not a fee; it is a statutory capitalisation requirement that must be verified and maintained. Combined with the personnel, facility, and documentary requirements — including a detailed business plan, network topology diagrams, and information security management systems — the application is a multi-month institutional undertaking, not a one-day form filing. This is by regulatory design: the barrier ensures that entities directly connecting to carrier networks meet a minimum threshold of stability and accountability.
Decision tree: which path applies to you?
Practical action guide — what to do right now
- Audit your current architecture. Map exactly how SMS messages flow from your backend to end users. Identify every intermediate system — API gateways, third-party providers, direct carrier connections. The license obligation follows the architecture.
- If you are in Scenario A (internal testing): Document your internal-use-only policy. Ensure no external endpoints can access the SMS service. Keep the SIM cards registered under your company name. You are in the safest regulatory zone.
- If you are in Scenario B (third-party API): Verify that your SMS API provider's SP License is current and valid — check the MIIT website. Maintain a signed service agreement. Audit your privacy policy to ensure it discloses third-party SMS processing. Review your data retention settings on the provider's platform — minimise log storage of message bodies.
- If you are planning to move toward Scenario C (direct carrier connection): Engage telecommunications regulatory counsel before signing any carrier agreement. The capitalisation, corporate structure, and personnel planning must begin months before the license application. This is not a post-launch compliance exercise — it is a pre-incorporation business structure decision.
- If you are uncertain about classification: The MIIT and provincial communications administrations accept written consultation requests. A formal regulatory opinion — though slow — provides the strongest defence against a subsequent allegation of unlicensed operation. Your legal counsel can submit this on your behalf.
“Compliance is not the enemy of innovation. It is the foundation that keeps your code running when the regulatory audit arrives.
Internal testing — proceed with confidence. Third-party APIs — use them compliantly. Direct carrier gateways — get the license. The rules are clear. The choice is yours.”