Discussion of algorithm filing tends to focus on obtaining the number: what to prepare, how long it takes, what to do when returned. What happens afterwards receives far less attention. In practice, that is where problems appear: the algorithm has been redesigned while the filing still describes the launch version, the product has been retired but the filing remains live, or the contact person has left and notices go unread.
Article 24 of the Provisions on the Administration of Algorithmic Recommendation Services is specific on this point: a change must be filed within ten working days from the date of the change, and deregistration must be completed within twenty working days from termination, with proper arrangements made. Both deadlines run from the date the fact occurred, not the date the company discovered it or decided to act.
Three ongoing duties after approval
Change. Required whenever the filed information no longer matches reality. This is the most frequent duty and the easiest to miss, because changes usually originate with product or engineering and legal learns of them after release.
Annual verification. The filing system initiates a review requiring confirmation of entity details, operating status and the application of security measures. Forms and standards follow the system notice and local practice, but the common requirement is that someone receives it, someone completes it, and someone reviews it.
Deregistration. Required when the algorithm service ends, the product is retired, or the entity is dissolved. Deregistration is not deletion: it is a termination declaration in the system, together with an explanation of arrangements for user data.
All three rest on self-declaration. The authority does not update records from public information, and a product redesign does not adjust the filing automatically.
Ten change triggers
Whether a change filing is needed turns on consistency, not on the size of the edit. Ten situations account for most cases:
| No. | Trigger | Action | Common misjudgement |
|---|---|---|---|
| 1 | Change of entity name or legal representative | Change | Treating registration changes as unrelated |
| 2 | Algorithm renamed | Change | Treating it as a marketing change |
| 3 | Algorithm type adjusted | Change, or new filing | Placing a new algorithm under the old filing |
| 4 | Product or application changed | Change | New product reusing the old number |
| 5 | Service form changed, e.g. web version added | Change | Assuming one algorithm needs no update |
| 6 | Generative capability added | Usually a separate filing | Dialogue layered onto recommendation without filing |
| 7 | Technology provider changed | Change | New model procured, filing untouched |
| 8 | Filing contact changed | Change | Position left vacant after departure |
| 9 | Domain or app name changed | Change | Domain switched without updating |
| 10 | Algorithm discontinued or service terminated | Deregistration | Product retired, filing left in place |
Items 4 and 6 cause most errors. Companies building several products on one technology stack tend to reuse an existing filing number, but a filing covers a specific algorithm service rather than a technology base. A new product offering a different service to the public usually needs its own filing.
Item 10 is often underestimated. A filing left live after termination still shows the algorithm as operational, and unrelated content problems may bring the retired product into the scope of an investigation.
How the deadlines are calculated
The ten and twenty working day periods run from the date of the change or termination. Three misunderstandings recur:
First, treating internal approval as the starting point. The relevant date is the date of registration change, release, or service termination.
Second, treating preparation as the starting point. The deadline governs the filing act, not the review period; delay in preparing materials does not shift responsibility.
Third, assuming submission completes the duty. Review follows acceptance, and where corrections are required the process takes longer. In practice, preparation should start two weeks earlier than the calculation suggests.
The annual verification in practice
The difficulty lies in evidence rather than in filling forms. The form usually asks the company to confirm that the algorithm is operating and that security measures are applied. Without records of how those measures were executed, the submission becomes an unsupported declaration.
A three-step approach works: the algorithm owner confirms operating status and technical changes, legal checks the filed information against the current product, and the security lead provides records of measures in place. The three confirmations form one submission and are retained for review.
Consequences of a mismatch
The first layer is inspection. A mismatch usually leads to a deadline for rectification; failure to rectify may affect continued provision of the service.
The second is new filings. An unresolved filing issue can slow acceptance of a new algorithm filing, and filing cycles are measured in months, which feeds directly into launch plans.
The third is transactions. Customer and investor due diligence now routinely checks the filing list; a mismatch is recorded as a compliance management defect requiring explanation and sometimes valuation adjustment.
Three practical arrangements
Keep a filing register. Fields should include the filing number, algorithm name, product, filing date, last change date, contact person and next verification date. The register need not be elaborate, but it must correspond to product versions.
Set a change trigger. Add “does this affect filed information” to the release review checklist, alongside the privacy assessment. This is the cheapest item and the easiest to skip.
Name an owner. The filing contact should not be a shared mailbox. On staff changes, the handover list should include system access, pending items and historical materials.
Related reading: Algorithm filing: the complete process, Algorithm filing or large-model filing: the decision order, Generative AI filing materials checklist, Algorithm filing service
Frequently Asked Questions↑ Back to article
What remains to be done after filing is complete?
Three things: file a change when the recorded information changes, complete the annual verification when the system requests it, and deregister when the service ends. All three are self-declared and time-bound; the authority does not update records on the company's behalf.
What is the deadline for a change filing?
Within ten working days from the date of the change. Deregistration must be completed within twenty working days from termination, with proper arrangements made. Time runs from the date the fact occurred, not the date it was noticed.
Which changes trigger a filing?
A change of entity name or legal representative, algorithm name, algorithm type, product or application, service form, added generative capability, technology provider, filing contact, domain or app name, or discontinuation. The test is whether the filed information still matches reality.
Does a small new feature require a change filing?
It depends on whether the algorithm service itself changes. A new service type, such as generative dialogue layered onto a recommendation algorithm, normally requires a separate filing; parameter optimisation within the same algorithm is generally handled as a change.
What happens if the information is not updated?
A mismatch with reality typically leads to a deadline for rectification, may slow the acceptance of new filings, and is recorded as a compliance management defect in customer and investor due diligence.
What should be prepared for the annual verification?
Usually entity information, the operating status of the algorithm, evidence that security measures are being applied, and confirmation of the contact person. Specific requirements follow the system notice and the local cyberspace administration.