Temu's €200M DSA Fine: What the First Systemic-Risk Enforcement Case Actually Requires From Marketplace, Recommender, and UGC Platforms

On 28 May 2026, the European Commission fined Temu €200 million under the Digital Services Act. Not for selling counterfeit chargers, not for a data breach, not for a transparency-reporting gap — for writing a risk assessment the Commission considered too generic to count as compliance. That is a new kind of DSA enforcement, and the Commission's own press release is specific enough about what was wrong with Temu's document that it doubles as a checklist for anyone running a platform with a recommender system, user-generated listings, or algorithmic promotion — whether or not you are anywhere near the size that gets you a Commission investigation.

Temu has until 28 August 2026 to submit a remediation plan. That deadline, and the mechanics of what happens if it slips, are worth understanding even if you never touch the Digital Services Act's systemic-risk chapter directly — because the enforcement logic the Commission just demonstrated is going to be the template for the next VLOP case, and the underlying risk-assessment discipline it demands is good practice for any platform long before it becomes a legal requirement.

What the Commission actually said was wrong

The press release (IP/26/1178) and the corroborating Commission news page list three concrete deficiencies in Temu's 2024 risk assessment — not vague "insufficient effort" language, but specific, checkable failures:

1. It used sector-wide data instead of platform-specific evidence. Temu's assessment leaned on general e-commerce risk statistics rather than testing and reporting about Temu's own service. The Commission ran its own mystery-shopping exercise through an independent testing organisation and found a very high failure rate on basic safety tests for chargers, and baby toys with chemical or suffocation hazards — numbers Temu's own document never surfaced.
2. It underestimated exposure. The Commission concluded EU consumers are "very likely" to encounter illegal products on the platform — a materially different risk profile than what Temu's assessment described.
3. It ignored how the product itself amplifies risk. The assessment did not evaluate how recommender-system design and influencer-led promotion programmes could increase the spread of illegal listings — treating the risk as a static content-moderation problem rather than one shaped by the platform's own ranking and promotion mechanics.

The Commission's characterization, in Executive Vice-President Henna Virkkunen's own words: "Risk assessments are not box-ticking exercises — they are the backbone of the DSA. Temu's risk assessment underestimates concrete risks, lacks specificity, is not grounded in solid evidence, and is not comprehensive."

That is a legible standard. A generic, desk-research risk assessment that does not test your own product and does not analyze your own ranking/promotion systems is now demonstrated — not just theorized — to fail Article 34.

The legal mechanism: Article 34 and Article 35

Temu was fined for failing two specific, cross-referenced obligations that only apply to designated Very Large Online Platforms (VLOPs) — platforms with 45 million or more average monthly active EU recipients under Article 33 of Regulation (EU) 2022/2065.

Article 34 — Risk assessment. VLOPs must diligently identify, analyse, and assess systemic risks stemming from the design or functioning of their service, at least annually and before deploying any feature likely to have a critical impact on identified risks. Article 34(1) names four risk categories:

Article 34(2) requires the assessment to give "particular consideration" to how these risks are shaped by: the design of recommender systems and other algorithmic systems, content moderation systems, the applicable terms and conditions and their enforcement, advertising-selection systems, and the platform's data practices — plus intentional manipulation, inauthentic use, and regional/linguistic variation. This is precisely the list of things the Commission said Temu's assessment skipped.

Article 35 — Mitigation. Once risks are identified, Article 35(1) requires "reasonable, proportionate and effective" mitigation, tailored to the specific risks found, with fundamental-rights impact considered. The article lists eleven example categories, including:

• Adapting service design, features, or interfaces
• Adapting terms and conditions and their enforcement
• Testing and adapting algorithmic systems, including recommender systems
• Adapting advertising systems, including limiting how ads are presented
• Strengthening internal processes, resourcing, and documentation for risk detection
• Cooperating with trusted flaggers and out-of-court dispute-resolution bodies
• Crisis protocols and cooperation with other providers via codes of conduct
• Age verification and parental-control tooling for minor protection

A risk assessment that never names which of these levers it evaluated is, by the Commission's own precedent, not diligent — regardless of how long the document is.

What happens next, and why the 28 August date matters

Under Article 75, a non-compliance decision requires the platform to submit an action plan setting out the measures needed to remedy the infringement. The Commission's press release lays out the full sequence for Temu specifically:

1. 28 August 2026 — deadline for Temu to submit its action plan to the Commission.
2. +1 month — the European Board for Digital Services issues its opinion on the plan.
3. +1 month — the Commission adopts a final decision and sets a "reasonable period" for implementation.
4. Non-compliance after that can trigger periodic penalty payments under Article 76 — up to 5% of average daily worldwide turnover per day the infringement continues.

The €200 million fine and the 5% daily-penalty backstop are two different instruments: the fine is the sanction for the past failure, the periodic penalty is the pressure mechanism for future compliance. Combined, they are the Commission's answer to a criticism that has followed the DSA since 2023 — that systemic-risk obligations were symbolic because enforcement was slow and penalties were abstract. Investigation opened 31 October 2024, preliminary findings adopted July 2025, fine issued May 2026: roughly 19 months from opening to decision. That is the enforcement timeline to plan around, not a theoretical maximum.

Who this actually binds — and who should pay attention anyway

Article 34 and Article 35 are Section 5 of DSA Chapter III, and Section 5 applies only to designated VLOPs/VLOSEs (Article 33: 45M+ average monthly EU users, formally designated by the Commission). If your platform is nowhere near that scale, you are not legally required to run an annual systemic-risk assessment. Do not let a vendor compliance checklist tell you otherwise.

But three things are worth being precise about before you conclude the Temu case is irrelevant to you:

First, the baseline DSA obligations apply regardless of size. Article 19 exempts micro and small enterprises from Section 3 (Articles 20–28: internal complaint handling, trusted flaggers, ad transparency, recommender-system transparency, minor protection) — but that exemption does not cover Section 1 (Articles 11–15: points of contact, terms and conditions, transparency reporting) or Section 2 (Articles 16–18: notice-and-action mechanisms, statement of reasons, notification of suspected criminal offences). If you run any hosting service or online platform reachable by EU users, those apply to you today, at any size, with no revenue or user-count threshold.

Second, if you operate a marketplace, recommender feed, or UGC platform and plan to grow, the Article 34(2) factor list is the risk-assessment structure you will eventually need — so it costs nothing to use it as a design checklist now. Concretely: does your ranking or recommendation logic have any documented review for whether it could amplify harmful or illegal listings? Does your promotion/affiliate/influencer program have any assessment of dissemination risk, or does it only get evaluated for conversion performance? Is your only evidence base for "how risky is our platform" industry-wide statistics, or have you tested your own product? Temu's failure was not obscure legal technicality — it was building a governance document around convenient, generic evidence instead of the platform's actual behavior. That failure mode is available to a five-person startup exactly as it was to Temu.

Third, the 45-million threshold is not a permanent shield. Article 33 designation is based on average monthly active EU recipients, reassessed continuously — a platform that crosses the line gets a designation, a compliance countdown, and (per the DSA's general approach) no grandfathering for a risk-assessment methodology that was never built with Article 34(2)'s factor list in mind. Retrofitting evidence-based, product-specific risk assessment under regulatory deadline pressure — after your growth curve already crossed 45M MAU — is a materially worse position than building the habit early.

A practical starting checklist

If you run a platform with any of: a recommender/ranking system, user-generated listings or content, an affiliate/influencer promotion mechanism, or third-party sellers — here is what the Temu case suggests a defensible risk-assessment practice actually contains, independent of whether Article 34 legally applies to you yet:

• Platform-specific testing, not sector benchmarks. If your evidence for "how often do users encounter harmful/illegal content or products" is an industry report rather than your own sampling, that is the exact gap the Commission penalized.
• A written link between ranking/recommender logic and risk categories. Document, in plain language, whether and how your algorithmic ranking could surface or amplify problematic content faster than moderation can catch it.
• A separate look at promotion mechanisms. Affiliate programs, influencer campaigns, and paid boosting are growth levers with their own amplification risk — evaluate them as a risk vector, not only as a marketing metric.
• Actual mitigation options mapped to actual risks, not a generic "we have a trust & safety team" statement. Article 35's list (interface design changes, algorithmic testing, T&C enforcement changes, advertising limits, trusted-flagger cooperation) is a reasonable menu to draw from even outside formal VLOP status.
• A notice-and-action mechanism and statement-of-reasons process that already meets Article 16/17 — these apply to you today if you host any third-party content, independent of VLOP status, and are the baseline the systemic-risk chapter builds on.

None of this requires VLOP-scale infrastructure. It requires treating "how risky is our platform" as a question you answer with your own data, on a recurring basis, before growth or a regulator forces the question.

See Also

• EU DSA + GDPR + NIS2 Combined Platform Compliance Stack 2026: SaaS Developer Guide — how Article 34's systemic-risk assessment fits alongside GDPR DPIAs and NIS2 risk management in a single register, for teams that will eventually need all three.
• EU DSA Recommender System Transparency 2026: SaaS Developer Compliance Guide — the Article 27 transparency obligations for recommender parameters, the disclosure-side counterpart to this post's risk-assessment focus on recommender design.
• EU DSA Notice & Action System 2026: SaaS Developer Implementation Guide — full implementation guide for Article 16/17, the baseline obligations this post notes apply regardless of VLOP status.
• EU Digital Services Act 2026: Complete SaaS Developer Compliance Guide — the full DSA obligation stack across all four size tiers, for teams mapping out where they currently sit.