EU DSA Marketplace Trader Traceability Reference

Online marketplaces that let consumers in the European Union conclude distance contracts with traders now need a more disciplined onboarding file than a basic seller profile. Under the Digital Services Act, marketplace trust is tied to traceable traders, product information fields, consumer notices, and records that can be shown to regulators when needed.

This reference is for marketplace, trust and safety, legal, compliance, payments, product, and seller operations teams. It turns the public DSA requirements into an operating checklist for trader onboarding and marketplace recordkeeping. It is not legal advice, and teams should confirm local enforcement guidance and sector-specific product rules before making compliance decisions.

Scope Snapshot

The European Commission says the DSA applies to online intermediaries and platforms in the EU, including online marketplaces, app stores, social networks, content-sharing platforms, and online travel and accommodation platforms. The general DSA compliance date for regulated entities was 17 February 2024, while very large online platforms and very large online search engines face additional obligations after designation.

The marketplace-specific duties in Articles 29 to 32 apply to providers of online platforms that allow consumers to conclude distance contracts with traders. Article 29 excludes micro and small enterprises from that section, but the exclusion does not apply to platforms designated as very large online platforms.

For a marketplace operator, the first documentation question is therefore simple: does the service let EU consumers contract with third-party traders through the platform? If yes, the service needs a trader traceability process, not just a generic merchant signup flow.

Trader Onboarding Record

Article 30 requires marketplace providers to obtain trader information before allowing traders to promote messages or offer products or services to EU consumers. The onboarding record should capture, where applicable:

• Trader name, address, telephone number, and email address
• A copy of the trader’s identification document or other electronic identification
• Trader payment account details
• Trade register name and registration number, or equivalent public-register identifier
• A self-certification that the trader will offer only products or services that comply with applicable EU law

This information should be collected in structured fields, not only in uploaded documents. Structured fields make it easier to check completeness, display required public information, trigger reviews, and respond to lawful orders from competent authorities.

Verification Steps

The DSA does not make the marketplace the guarantor of every trader statement. It does require best efforts to assess whether the Article 30 information is reliable and complete before the trader can use the service. The official text points to freely accessible official online databases or online interfaces made available by a Member State or the Union, and to supporting documents from reliable sources.

A practical verification file should record:

• Which public register or official database was checked
• The registration number, company name, and address returned by the check
• Whether the payment account name reasonably matches the trader record
• Which supporting document was requested when a public database was not enough
• The reviewer, timestamp, result, and reason for approval or rejection
• Any mismatch that was accepted, escalated, or sent back to the trader

For existing traders that were already using the marketplace on 17 February 2024, Article 30 gave providers 12 months to make best efforts to obtain the required information. New onboarding flows should now treat the information set as a precondition to selling to EU consumers.

Incomplete or Outdated Details

Article 30 also creates an update duty. If the marketplace has sufficient indications or reason to believe that trader information is inaccurate, incomplete, or not up to date, it must ask the trader to fix the issue without delay or within the period set by Union or national law.

The operating workflow should include clear triggers for review. Examples include bounced contact details, a failed payment account check, a regulator notice, a consumer complaint about trader identity, returned mail, public-register changes, repeated product-safety reports, or a mismatch found during periodic sampling.

If the trader does not correct or complete the information, the platform must swiftly suspend the service for that trader in relation to offers to EU consumers until the request is fully complied with. The suspension record should preserve the trigger, notice sent to the trader, deadline, trader response, reviewer decision, and reinstatement conditions.

Public Display Fields

Some collected information is internal; some must be visible to consumers. Article 30 says the marketplace must make the trader’s name, address, telephone number, email address, trade-register information where applicable, and self-certification available in a clear, easily accessible, and comprehensible way. The information must be available at least where product or service information is presented.

This should be designed as a product-page requirement, not a help-center afterthought. A marketplace should be able to show that the consumer can identify the trader before purchase, understand whether the seller is a business trader, and find the relevant contact and register details without searching through unrelated policy pages.

Secure Storage and Deletion

The same Article 30 record contains personal, business, identification, and payment-related data. The DSA requires secure storage of the trader information obtained under the traceability process for six months after the end of the contractual relationship with the trader. After that period, the information must be deleted.

The retention schedule should distinguish between:

• Public trader details shown on product pages
• Internal identity and payment verification records
• Audit logs showing that a check occurred
• Legal holds or lawful orders that require longer preservation
• Deletion events after the six-month post-relationship period

Access should be role-based. Seller support may need public profile fields and review status, while identification documents and payment account details should be limited to teams with a specific verification, legal, fraud, or compliance need.

Compliance by Design

Article 31 adds a product-design duty for marketplaces. The online interface must be designed and organized so traders can provide pre-contractual information, compliance information, and product-safety information required by applicable EU law.

At minimum, the marketplace should provide fields that let traders identify products or services clearly and unambiguously, add any trademark, symbol, or logo used to identify the trader, and provide applicable labelling and marking information. The interface should also allow information about the economic operator, including name, address, telephone number, and email address where required by product law.

The practical test is whether the seller tool makes lawful disclosure possible before publication. If required safety or compliance fields are buried in optional free text, unavailable for a product category, or stripped from the consumer-facing page, the design may create compliance risk even when the trader has the right information.

Illegal Product Checks

Article 31 requires marketplaces to make best efforts to assess whether traders have provided the required compliance information before they offer products or services. After a trader is allowed to sell, the marketplace must make reasonable efforts to randomly check official, freely accessible, machine-readable databases or interfaces to see whether offered products or services have been identified as illegal.

That creates a need for a sampling plan. The plan should define which categories are checked, which official databases are relevant, how random samples are selected, how often checks run, and how matches are escalated. High-risk categories such as toys, electronics, cosmetics, medical products, food supplements, and regulated services may need more careful mapping to product-specific EU and national databases.

The record should show that checks are operational, not symbolic. Keep the sample date, query terms, database used, returned result, reviewer decision, and downstream action.

Consumer Notice When Something Is Illegal

Article 32 addresses the consumer side of illegal products or services. If a marketplace becomes aware that an illegal product or service was offered by a trader to EU consumers through its service, it must inform consumers who purchased it, where it has their contact details. The notice must tell them that the product or service is illegal, identify the trader, and describe relevant means of redress.

The obligation is limited to purchases made within the six months before the marketplace became aware of the illegality. If the marketplace does not have contact details for all affected consumers, it must make the information about the illegal product or service, trader identity, and redress options publicly available and easily accessible on its online interface.

An incident playbook should therefore connect product takedown, order data, customer messaging, legal review, public notices, refunds or redress routing, and regulator response. The team should not discover after an incident that order contact data, product identifiers, or trader records cannot be joined.

Enforcement and Governance

The Commission’s DSA enforcement page explains that Member States and the Commission share enforcement responsibilities. Digital Services Coordinators supervise providers established in their Member State, while the Commission directly supervises designated very large online platforms and search engines for the additional VLOP and VLOSE obligations.

For marketplace documentation, this means ownership should be clear before a request arrives. The governance file should name the internal owner for DSA trader traceability, the legal contact for competent authority orders, the product owner for seller-interface fields, the data owner for retention and deletion, and the trust and safety owner for illegal product workflows.

The most useful evidence file is a living operating record: one that proves the platform knows which traders sell to EU consumers, how their details were checked, where required information appears to consumers, how product compliance fields are maintained, when random illegal-product checks occur, and what happens when a trader or product fails review.