The User Got a Moderation Notice. Why Did the DSA Export Fail?
Repair one moderation decision by separating the Article 17 recipient notice from the Article 24(5) Transparency Database record and their owners.
Signals to watch
- A recipient received a restriction notice but the case has no stable decision identifier for the database export
- The public record contains a category or automation value that cannot be reproduced from the moderation case
- A bulk or API submission is rejected close to release while notice, export and privacy owners each hold a different version
A DSA export repair starts with one moderation decision and creates two controlled outputs. The first is the clear, specific statement of reasons sent to the affected recipient under Article 17. The second is the structured, non-personal record that an online platform submits without undue delay to the European Commission’s DSA Transparency Database under Article 24(5). Reusing one payload for both is the usual architectural mistake: the audiences, permitted data and field models differ.
That answer is useful to a trust-and-safety case-management or DSA reporting integrator watching authorised platform-operations, moderation and regulatory-technology Telegram groups. “The user got the notice, but the EU export still fails” can signal a dated integration repair. Seeing it after the release window may cost the discovery call. It does not establish the provider type, the decision’s lawfulness, a database breach or the speaker’s authority to buy.
The binding source is Regulation (EU) 2022/2065. Article 17 sets the recipient statement; Article 24(5) sets the platform submission. The Commission’s Transparency Database documentation defines the current submission surface. Capture the documentation version and schema used in the failed run because a technically valid payload is time-dependent.
The failed release began before the API call
Suppose a team can open the recipient email but cannot answer which immutable decision produced it. The moderation tool stores a case number, the notification service stores a delivery ID and the reporting pipeline creates another export key. When the restriction is changed on appeal, one system overwrites the original action while another retries the old payload.
The application programming interface (API) error is then the last visible symptom. The first failure was the absence of a stable decision record containing the action, facts, basis, automation fields, time, recipient-notice version, public-export version and later lifecycle events. Repair that record before transforming the payload again.
This is also why a data warehouse snapshot is not automatically the system of record. It may have the current content status but not the exact reason supplied at decision time or the later appeal outcome. Preserve events instead of reconstructing them from today’s state.
Output one: the affected recipient needs the reason and a route to challenge it
Article 17 applies to providers of hosting services when they impose listed restrictions because information supplied by a recipient is illegal content or incompatible with their terms and conditions. The listed measures include restrictions on visibility, monetary payments, provision of the service and the recipient’s account. Article 17 contains an exception for deceptive high-volume commercial content.
The statement must identify the restriction and its territorial scope and duration where relevant. It must state the facts and circumstances relied on, including whether the decision followed the provider’s own investigation or a notice and, where appropriate, the notifier’s identity. It must say whether automated means were used to detect or identify the content or to take the decision.
It must also provide the legal ground and explanation when the decision relies on illegal content, or the contractual ground and explanation when it relies on terms and conditions. Finally, it must explain available redress. Under Article 17(4), this information must be clear, easy to understand and as precise and specific as reasonably possible in the circumstances.
Those fields cannot be produced reliably from a generic reason code such as POLICY-7. The code needs a versioned policy or legal basis, case facts, action parameters, automation provenance and redress configuration. The visible notice must remain consistent with the case record that approved it.
Output two: the public record must be structured and contain no personal data
Article 24(5) requires online platforms to submit the decisions and Article 17 statements of reasons to the Commission database without undue delay, in the format specified by the Commission. It expressly says the submitted information shall not contain personal data.
The public record therefore cannot be a dump of the recipient email. Usernames, free-text evidence, reporter identifiers, message contents, contact details and internal analyst notes may identify people even when obvious account fields are removed. The export needs an allow-listed mapping, category validation and privacy review. Redaction is not merely replacing an email address after serialization.
The current Transparency Database supports a public search and structured submission workflow documented by the Commission. A repair team should preserve the source schema version, submitted payload, response, timestamp and retry lineage. A successful response is an export event, not proof that the underlying decision was correct.
Rebuild the dual-output map in five passes
Pass 1: freeze the decision event
Take one rejected or unreconciled example. Preserve the original case version, restriction, decision time, effective time, content or account object identifier, facts, policy or legal basis, automation flags, reviewer and later appeal or reversal events. Use pseudonymous internal identifiers in the repair workspace; do not copy personal data into tickets.
Pass 2: reproduce what the recipient saw
Recover the exact notice version and delivery event. Compare its action, duration, territorial scope, facts, basis, automation disclosure and redress routes with the approved decision record. A delivered email does not prove that the correct template or language was used.
Pass 3: map only allowed fields to the public schema
Create a field-level mapping from the decision record to the current database categories. Every field should show its source, transformation, enum mapping, null rule and owner. Free text should enter the public payload only where the current schema permits it and after privacy testing.
Pass 4: replay with versioned evidence
Validate against the target schema, submit through the authorised web or API route, and retain the payload hash, response, timestamp and environment. Classify failure separately: authentication, schema, category, required field, privacy block, rate/transport issue or internal source-data gap.
Pass 5: reconcile lifecycle events
An appeal, reversal or changed restriction should not silently rewrite history. Define how the recipient update and any required database record follow the platform’s decision lifecycle. Reconcile counts and identifiers across moderation, notification and export systems for the same time window.
Example: a valid notice can still create an invalid public record
This is an illustrative composite, not a real platform, user or incident:
“Notice went out in French. Export says category invalid again. Case has the reporter’s text in the reason field, so privacy stopped the retry.”
The notice language may be correct but says nothing about the public enum. The invalid category may come from an outdated mapping. The reporter text may be necessary evidence inside the controlled case but prohibited in the public record. Unknowns include provider type, restriction, legal or terms basis, automation, database schema version and whether the messages refer to the same decision.
The scoped engagement is concrete: reproduce one case, separate the notice and export mappings, update the enum crosswalk, add a privacy allow-list, replay in the authorised environment and reconcile the accepted record. It is not a promise that every historic decision is compliant.
The DSA trader-traceability article covers marketplace seller identity, not moderation statements. The Telegram Signal lifecycle helps preserve source, time and ownership before a candidate changes hands. The official-source ladder helps recover the current Commission document rather than relying on a screenshot.
Keep discovery outside the moderation system
TOP Prospect can organise matching fragments from Telegram groups the user has deliberately connected and is authorised to access, retaining original text, source, time and review context. Its matching-target interface currently saves configuration but does not automatically generate new candidates. It cannot access a platform’s moderation cases, identify users, inspect restricted content, issue notices, submit database records or determine DSA compliance.
A dated export error plus an assigned integration owner may justify earlier human review. The integrator still verifies the source and obtains permission before any outreach. A ranking score cannot turn the fragment into a confirmed incident or project. Pricing describes the monitoring product, not DSA legal or integration services.
Key facts
- Article 17 recipient statements and Article 24(5) public submissions originate from the same decision but are different outputs.
- Article 17 covers specified restrictions by hosting services and requires facts, basis, automation information and redress details.
- Article 24(5) applies to online-platform submissions and prohibits personal data in the submitted information.
- Stable decision identifiers and event history should join moderation, notification and export systems.
- Schema acceptance does not prove legal validity, proportionality or correct redress.
- Unknown provider, decision and implementation facts must remain unknown until controlled records support them.
FAQ
Are the Article 17 notice and database record the same document?
No. They share a source decision but serve the affected recipient and the public database through different data models.
Which providers owe Article 17 statements?
Providers of hosting services when the provision’s listed restrictions and grounds apply, subject to its terms and exception.
May the public database record contain personal data?
No. Article 24(5) expressly excludes personal data from submitted information.
Does a successful export prove the decision was lawful?
No. It shows that the technical submission was accepted, not that the underlying moderation decision passes every legal review.
Editorial review completed 22 August 2026 against Articles 17 and 24(5) of Regulation (EU) 2022/2065 and current European Commission Transparency Database documentation. Qualified DSA, privacy, trust-and-safety and integration reviewers must confirm the applicable provider, schema and decision record.
Frequently asked questions
Are the Article 17 notice and Transparency Database record the same document?
No. They arise from the same moderation decision but serve different audiences. The recipient notice explains the restriction and redress; the Article 24(5) database submission is a structured, non-personal public-transparency record.
Which providers owe Article 17 statements of reasons?
Article 17 applies to providers of hosting services when they impose the listed restrictions because recipient-provided information is illegal or incompatible with their terms, subject to the provision and its exception.
May the public database record contain personal data?
No. Article 24(5) states that the submitted information shall not contain personal data. Privacy review must therefore be part of the export path.
Does a successful export prove that the moderation decision was lawful?
No. It proves only that a structured record was accepted. The underlying facts, legal or contractual basis, proportionality and redress remain separate review questions.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
