Cyprus marketplace trader checks under DSA Article 30

Distinguish a marketplace from a merchant's own shop

Article 30 applies to providers of online platforms that allow consumers to conclude distance contracts with traders. Begin with the contract flow. Can an independent third-party trader offer a product or service to a consumer through the interface, and can a distance contract be concluded? If the operator only sells its own stock as the trader, the Article 30 marketplace-specific traceability duty is a different question. Do not classify a site from its visual design or because it has a product catalogue; map the contracting parties and the service actually supplied.

Record the legal entity operating the platform, where recipients are established and whether offers reach consumers located in the EU. A Cyprus-incorporated company may serve EU consumers through an app, a web marketplace or a booking service. The rule is framed around EU consumers, not only Cyprus residents. Identify each category of trader, including companies and sole traders, and where their details enter the system. An invitation-only marketplace still needs a scope assessment if third-party traders can contract with consumers.

Keep Article 30 separate from the information duties of the trader and from other DSA duties for platforms. A marketplace may need to design listing fields for product-safety and pre-contract information under Article 31, while the seller still remains responsible for the accuracy of the details it provides. The operator's best-efforts reliability check is not a guarantee that every listing is lawful. Write a short scope memo before engineering a collection flow, especially if the site mixes first-party products with third-party listings.

For the separate information that a merchant should show a buyer before checkout, see the Cyprus online-shop disclosures guide.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32; European Commission: The Digital Services Act

Apply the micro and small enterprise rule carefully

DSA Article 29 excludes micro and small platform providers, as defined by Commission Recommendation 2003/361/EC, from the additional marketplace section that includes Articles 30 to 32. It also provides a 12-month continuation of the exclusion after loss of that status under the Recommendation's rule. A very large online platform designated under Article 33 does not receive the exclusion. The test concerns the provider of the platform, not the size of a trader selling on it. A large marketplace cannot skip seller checks because an individual seller is small.

Assess the correct enterprise, with linked and partner enterprise rules where relevant under the Recommendation. The familiar staff and financial thresholds are not enough if a group relationship changes how the enterprise is classified. Keep a dated record of headcount, turnover or balance-sheet information and ownership assumptions. Reassess when the operator grows, changes control or is designated under another DSA category. A broad statement that every startup marketplace is exempt could be wrong if the operator is not within the defined class.

The Article 29 exclusion affects this particular marketplace section. It is not an exemption from all DSA obligations, consumer law, product-safety rules or privacy law. An excluded platform may still choose to collect proportionate seller identity information for fraud prevention and customer support, but should not describe its voluntary process as a mandatory Article 30 audit without first checking scope. Define the statutory position and the platform's risk-control choice separately in the internal policy.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32; Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises

Collect the five Article 30 information groups before listing

For a covered platform, Article 30(1) says that a trader may use it to promote or offer products or services to EU consumers only after the operator has obtained applicable information. The five groups are trader name and contact details; a copy of the trader's identification document or other electronic identification as defined in Article 3 of Regulation (EU) No 910/2014; payment-account details; trade-register information and number where registered; and the trader's self-certification that it will offer only products or services compliant with applicable EU law. Design the onboarding form around these distinct requirements, with clear guidance for a natural person and a company.

Do not merge legal identity, public display name and payout recipient into one ambiguous field. A company may trade under a brand while its registered name and register number identify the contracting entity. Check whether the payment account belongs to the trader or an explained intermediary. A missing register number may be legitimate for a trader not registered in a comparable public register, but the operator should capture the reason instead of silently leaving a blank. The self-certification needs an affirmative, dated record linked to the account.

Collect the required information before making a seller's consumer-facing offer active. A draft listing or account may exist while checks are pending, provided it cannot be used to promote or offer to EU consumers in the prohibited state. Give operations staff a clear status such as pending, verified for publication, correction requested or suspended. Record which fields were supplied and when; avoid treating a completed web form as proof that the information has been assessed for reliability under the next step.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32

Make best efforts to assess completeness and reliability

Article 30(2) requires best efforts, before permitting use of the service, to assess whether the information is reliable and complete. It points to freely accessible official databases or Member State or EU interfaces and, where needed, supporting documents from reliable sources requested from the trader. This is not merely an automated syntax check. Compare the trader's name and registration number with an official record where available, examine discrepancies in address or identity and document what could or could not be checked.

Build an exception route rather than automatically rejecting every mismatch. Names can differ because of transliteration, a recently changed address, a trading name or delayed register updates. Ask for a supporting document and record the assessment. Do not invent a stronger standard than the law states: best efforts is not a guarantee that the platform has independently certified the truth of every statement. The trader remains liable under Article 30 for the accuracy of the information it provides.

A Cyprus company search can help with local entities, but it will not cover all sellers in a cross-border marketplace. Maintain a country-aware source list and an escalation path where no freely accessible official record exists. Avoid publishing identity-document images or payment-account details as a substitute for the public trader information required by Article 30(7). Those private materials serve a different verification purpose and need restricted access. Keep a timestamp, reviewer, source used and outcome so that the operator can explain its best-efforts decision.

For a focused workflow using the Cyprus company register, see the company-search due-diligence guide.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32

Display the correct trader details to consumers

Article 30(7) requires the platform to make the trader's name, address, telephone and email; relevant trade-register information; and self-certification available to service recipients in a clear, accessible and comprehensible way. It specifies availability at least on the interface where the product or service information is presented. That means a buried legal page or post-purchase invoice alone is not enough. A consumer should be able to identify the responsible trader while deciding whether to buy.

Keep public information distinct from the private onboarding file. The identity document and payment-account details listed in Article 30(1) are not among the items Article 30(7) requires to be displayed. Article 30(6) restricts third-party disclosure of collected information except where required under applicable law. Design separate data fields and permissions so a change to a public seller card cannot accidentally reveal verification documents. If a trader's details change, update the displayed information after the correction has been assessed.

Test the display on desktop and mobile, in search results and individual listings, and for a first-time consumer who is not logged in. Verify that the public details relate to the trader actually contracting with the buyer, rather than the marketplace's own support address or a fulfilment provider. If the site uses multiple language versions, the label explaining who sells the product should be understandable in each. Preserve a dated screenshot or rendered-page test as evidence that the information was visible before purchase.

The public card should be readable as part of the purchase journey; the separate e-commerce accessibility guide explains how to audit access to that journey.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32

Request corrections and suspend when required

Onboarding is not the last check. Under Article 30(3), if the platform has sufficient indications or reason to believe that information obtained from a trader is inaccurate, incomplete or out of date, it must request a remedy without delay or within the applicable legal period. Define triggers such as returned email, a register mismatch, an invalid business address or a trader's notice of a new entity. Capture the trigger, request, deadline and response in a case record rather than making unexplained changes to the public listing.

If the trader does not correct or complete the information, the rule requires the platform swiftly to suspend the service to that trader for offers to EU consumers until the request is fully satisfied. Build an operational control that can stop new consumer-facing offers without erasing the case history. Staff should know what evidence is sufficient to restore access and who approves it. A vague 'under review' label while live listings keep taking orders does not achieve the suspension described in the Regulation.

Article 30(4) preserves a trader complaint route when access is refused under paragraph 1 or service is suspended under paragraph 3, referring to the DSA's complaint provisions. Explain the decision and the available challenge path consistently with the applicable platform rules. Review the facts if the trader supplies corrected evidence; avoid permanent exclusion based solely on a formatting error. Keep the case process distinct from content-moderation or illegal-product removal rules, which may create other obligations.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32; European Commission: The Digital Services Act

Protect and delete the onboarding file on time

Article 30(5) requires secure storage of the information obtained under paragraphs 1 and 2 for six months after the end of the contractual relationship with the trader and deletion afterwards. Build a retention rule tied to the actual contract-end date, not to the date of the first seller application or the last sale. Test what happens when an account is paused rather than terminated. If a separate legal basis requires retention of another record, document that record and reason independently instead of silently retaining the whole identity-document file indefinitely.

Access should be restricted to staff who need to perform onboarding, investigate a correction or answer a lawful authority request. Identity copies and payment details are sensitive business and personal data. Avoid placing raw documents in support tickets, ordinary analytics or public object storage. Keep an access log and a deletion mechanism that covers backups according to a documented schedule. The DSA provides a specific six-month post-contract retention rule; GDPR principles still require the platform to handle personal data lawfully and transparently.

Map the public trader card, the private verification file, the case log and tax or payout records as separate data sets. They can have different retention and access needs. Give traders a clear privacy notice about the information collected, its display and the limited disclosures permitted by law. Reconcile the Article 30 deletion step with other duties before making an exception. A blanket 'keep all seller data for ten years' policy can contradict the specific DSA rule for this onboarding information.

Use the GDPR retention-schedule guide to document personal-data categories separately from public seller details.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32; Regulation (EU) 2016/679, General Data Protection Regulation

Make trader traceability a repeatable platform control

Turn the legal sequence into acceptance criteria: collect all applicable fields, prevent public offers before collection and assessment, document best-efforts checks, publish the permitted trader details, request correction on a trigger, suspend if correction fails, offer the trader a complaint path and delete the private file at the correct time. Test the actual production workflow with at least a company seller, a sole trader and a seller whose information changes. Record expected and observed behaviour at each state transition.

Article 31 adds a related platform-design duty for covered services: the interface should allow traders to provide pre-contractual, compliance and product-safety information, and the provider must make best efforts to assess that certain information is supplied before offers go live. It also calls for reasonable random checks against official, freely accessible machine-readable sources for offers identified as illegal. Do not fold these listing checks into Article 30's identity verification; maintain separate fields and evidence so neither duty is assumed to be satisfied by the other.

Assign an owner for legal scope, a product owner for form and display design, an operations owner for verification and suspension, and a privacy owner for restricted access and deletion. Audit exceptions periodically and after marketplace expansion to another EU country. Where a new payment provider or seller-management tool is added, repeat end-to-end tests. A working traceability system is a continuing process, not a one-time collection of incorporation certificates.

If the platform sells physical goods, also review the product-safety listing checklist; trader identity and product information answer different questions.

Basis and guidance: Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32; European Commission: The Digital Services Act

Primary sources and scope

Sources checked: October 7, 2026. This guide concerns the Republic of Cyprus. Examples are hypothetical, not client case studies. Check current official requirements before making a filing.

• Regulation (EU) 2022/2065, Digital Services Act, Articles 29–32
• European Commission: The Digital Services Act
• Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises
• Regulation (EU) 2016/679, General Data Protection Regulation

Practical guides for this topic

• DSA notice and action in Cyprus: a platform workflow

  Design a Cyprus hosting platform's DSA Article 16 notice process, decision reasons and complaint route without confusing illegal-content reports with trader checks.

• P2B ranking transparency for a Cyprus marketplace: seller-terms audit

  How a Cyprus online marketplace can document its main ranking parameters, relative importance, paid placement and seller-facing terms under the current EU P2B framework.