A Seller Cannot Publish an Offer Because Trader Details Are Missing: What Does the DSA Require?
Separate trader identity, platform verification and offer-page fields before treating a blocked marketplace listing as one DSA compliance problem.
Signals to watch
- The service is an online platform that lets consumers conclude distance contracts with traders in the European Union
- A named Article 30 information item or reliability check is blocking trader access
- A separate Article 31 offer-page field or product-identification requirement has an owner and release date
A marketplace offer blocked for “missing trader details” does not identify one compliance defect. First establish that the service and seller fall within the relevant Digital Services Act scope; then separate the trader record required by Article 30, the platform’s reliability check, and the offer-interface fields addressed by Article 31. Each can fail while the other two are complete.
That distinction matters to a marketplace-compliance intelligence lead reviewing authorised seller-operations, platform-policy and ecommerce Telegram groups. A day-late response can miss an onboarding review or the release window for a required listing field. Sending every fragment to identity verification can also leave a product-interface defect untouched.
Consider this illustrative composite fragment, not a seller message or enforcement finding:
“EU offer still won’t publish. Trader details says incomplete again. Docs were uploaded last week.”
It does not identify the platform, whether consumers conclude a distance contract there, the seller’s trader status, the missing item, the document reviewed, the rejection reason, the product, the market or the owner of the publishing deadline.
The first question is whether this is the Article 30 workflow
Article 30 of Regulation (EU) 2022/2065 applies to providers of online platforms that allow consumers to conclude distance contracts with traders. It requires the platform to obtain, where applicable, the trader’s name and contact details, identification evidence, payment-account details, trade-register details and a self-certification concerning offers under applicable Union law.
That list is not a generic “know your customer” label. The platform must also make best efforts to assess whether the listed information is reliable and complete, using freely accessible official databases or reliable supporting documents. The trader remains liable for the accuracy of supplied information.
So the first recovery note needs four facts: the platform service model, the consumer market, why the seller is treated as a trader, and the exact Article 30 item that the workflow says is absent or unreliable. Without them, the alert is only an account-support problem with a possible DSA connection.
An uploaded document, a failed check and a suspension are different states
The composite message says documents were uploaded. That proves neither acceptance nor the failure reason. Reconstruct the account event in this order:
- Submission record: which legal entity supplied which field or document, in which version and on what date?
- Assessment record: which item did the platform find incomplete, inconsistent or out of date, and which official record or supporting document was used?
- Remedy request: what correction was requested, through which account notice, with what deadline?
- Service state: is the trader still in onboarding, unable to publish one offer, or suspended from covered offers?
Article 30 distinguishes these states. Paragraph 3 addresses situations where the platform has sufficient indications that information is inaccurate, incomplete or not up to date; it then requests a remedy and can suspend the relevant service if the trader does not comply. A front-end error message does not by itself show that this legal sequence occurred.
The GPSR online-offer article explains a related product-safety disclosure problem. Use the official-source ladder when a screenshot has lost its legal or platform record.
Article 31 begins where the listing interface has nowhere to put the evidence
Article 31 is titled “Compliance by design.” It requires covered platforms to design their online interface so traders can provide pre-contractual, compliance and product-safety information required under applicable Union law. It specifically addresses economic-operator contact information and requires the interface to allow clear product or service identification, a sign identifying the trader and, where applicable, labelling and marking information.
This creates a different project. If the trader record is verified but the offer form has no field for the required economic operator, product identifier or marking, repeating identity-document checks will not repair the listing. The evidence packet should instead name the affected listing template, market, required data element, current interface behavior, downstream display and product owner.
The Safety Gate screenshot-verification guide is useful when the claim concerns an allegedly illegal or recalled product rather than missing onboarding data.
Route the request only after all three records are visible
A defensible routing card has three rows:
- Trader identity: the Article 30 information item, submitted evidence, legal entity and current account state.
- Platform assessment: the official database or reliable source checked, mismatch found, remedy request and accountable reviewer.
- Offer design: the Article 31 or other applicable listing field, affected interface and release owner.
TOP Prospect can combine fragments from Telegram groups the user deliberately connects and is authorised to access, preserve their source and time, remove obvious duplicates and rank the case for human review. It cannot decide who legally is a trader, verify identity documents, enter a marketplace account, declare a product lawful or contact the writer. The pricing page describes this discovery boundary.
Return to the blocked offer. If the missing object is an identity field or its evidence, route it to onboarding and compliance operations. If the account is verified but the interface cannot collect or display a required offer field, route it to product engineering. If the service model or trader status is still unknown, do not label the event a DSA breach. “Trader details incomplete” is a search clue; the failed record decides the project.
FAQ
Does Article 30 apply to every online service or every seller account?
No. It addresses online platforms that allow consumers to conclude distance contracts with traders. Confirm the service model, consumer location and trader status first.
Is collecting trader information enough for DSA onboarding?
No. The platform must make best efforts to assess whether the listed information is reliable and complete before allowing covered use. The trader remains responsible for accuracy.
Are Article 30 trader records and Article 31 listing fields the same thing?
No. Article 30 concerns trader traceability and assessment; Article 31 concerns interface support for required offer information.
Does a blocked listing prove that the seller violated the DSA?
No. Recover the exact rejection, account state, scope and evidence before drawing that conclusion.
Frequently asked questions
Does Article 30 apply to every online service or every seller account?
No. Article 30 addresses providers of online platforms that allow consumers to conclude distance contracts with traders. The service model, consumer location and whether the seller acts as a trader must be established before using the checklist.
Is collecting trader information enough for DSA onboarding?
No. Article 30 requires the platform to make best efforts to assess whether the listed information is reliable and complete before allowing the trader to use the service for covered offers. Traders remain liable for the accuracy of the information they provide.
Are Article 30 trader records and Article 31 listing fields the same thing?
No. Article 30 concerns trader traceability information and the platform’s assessment. Article 31 concerns interface support for pre-contractual, compliance and product-safety information, including clear product or service identification and certain visible trader or marking information.
Does a blocked listing prove that the seller violated the DSA?
No. It proves only that a platform workflow or rule blocked publication. The team must recover the exact rejection, account state, legal scope and failed evidence before drawing a compliance conclusion.
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.
