Trader KYBC (Know Your Business Customer) program

Description

A working trader KYBC program collects and verifies a defined dataset before a third-party trader can transact with consumers on the platform, retains the records on a documented clock, and surfaces the trader information to consumers at the point of purchase. The components are an onboarding flow that gates trader-side functionality on completed KYBC, a verification engine with documented tolerance for partial or transliterated information and a manual-review queue for the edge cases, a storage-and-retention surface that makes the data available to authorities on request, and a periodic-refresh process that catches stale data before it becomes a finding. The headline regime is DSA Article 30, which prescribes the minimum dataset on an online platform that allows consumers to contract with third-party traders: name, address, contact details, identification document or trade-register entry, payment account details, and (where applicable) the economic-operator name and contact for products covered by the EU's product-safety regimes. Verification uses reliable and independent sources, retention runs for the duration of the contractual relationship plus six months, and re-verification happens periodically against the same sources. Adjacent regimes layer on the same infrastructure: the EU GPSR Article 22(7) capture obligation before consumers are bound by a distance contract, the DAC7 final-notice-and-account-closure obligation against sellers who do not provide diligence data after two reminders (Annex V Section IV(A)(4)), and the EU Omnibus Directive trader-versus-non-trader disclosure to consumers. UK and Singapore marketplace regimes track the same shape with their own retention windows. DSA Article 30 also requires the trader information to be presented to consumers at the point of purchase, which means KYBC failures surface in the storefront rather than only on the back end. A trader whose verification expired between sign-up and the consumer's purchase has a visible compliance state, and the platform's response to that state (block listing, soft-warn consumer, allow through with a refresh flag) becomes its own regulator-facing decision. Most platforms initially under-budget the periodic-refresh side, which is what DSA enforcement has been catching in the first wave of supervisory action. Evidence formats that hold up include the KYC documentation per trader keyed to the listing, the trader-registration records, the verification audit logs showing reviewer identity and source of truth, and the periodic re-verification cadence document with completion timestamps.

Applicability

Applies when: business model role is intermediary or mixed.

How predicates are evaluated

Required by (4 regulations)

• DSA

  Articles 30-32 — trader-traceability obligations for online platforms allowing distance contracts.

  Regulation (EU) 2022/2065 of the European Parliament and of the Council (Digital Services Act)

• Omnibus

  Trader vs non-trader disclosure obligations.

  Directive (EU) 2019/2161

• DAC7

  Annex V Section IV(A)(4) — appropriate measures (final notice + account closure or payment withhold) against sellers who fail to provide due-diligence data after two reminders.

  Council Directive (EU) 2021/514

  Source →

• EU GPSR

  Article 22(7) — capture trader name, registered trade name or trade mark, contact details, address of establishment, manufacturer name and address before consumers are bound by a distance contract.

  Regulation (EU) 2023/988

  Source →

Fulfilled by (5)

• yoti · full · medium effort · $$
• veriff · full · medium effort · $$
• jumio · partial · high effort · $$$
• persona · full · medium effort · $$
• In-house build · high effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

• KYC documentation
• trader registration records
• verification audit logs
• periodic re-verification cadence