Skip to content

DOMAIN:EU_REGULATION:KYC_FOR_PLATFORMS

OWNER: eric ALSO_USED_BY: julian, aimee, hugo, ALL dev agents building regulated features UPDATED: 2026-03-26 SCOPE: KYC requirements for marketplace and platform projects — PSD2, DAC7, delegated KYC, seller onboarding

PURPOSE

Many GE client projects are marketplaces, platforms, or B2B systems where users transact with each other. These platforms face unique KYC obligations beyond standard business-to-customer relationships. This page covers when platforms must perform KYC, how to delegate it, and how to implement it well. For general KYC process see kyc-processes.md. For implementation see kyc-implementation.md.

WHEN PLATFORMS MUST PERFORM KYC

THE CORE QUESTION

A platform that connects buyers and sellers is not automatically an obliged entity under AML law. The obligation depends on whether the platform handles money, provides regulated services, or falls under specific reporting requirements.

SCENARIO 1: PLATFORM HANDLES PAYMENTS

IF the platform receives funds from buyers and distributes to sellers: - this is a payment service under PSD2 - requires a payment institution licence or e-money institution licence - full AML/KYC obligations apply to the platform as an obliged entity - ALTERNATIVE: use a licensed payment service provider (see Delegated KYC below)

SCENARIO 2: PLATFORM FACILITATES BUT DOES NOT HANDLE PAYMENTS

IF the platform merely connects buyer and seller, payment flows directly between them: - platform is NOT providing a payment service - no PSD2 licence required - no AML/KYC obligation arising from payment handling - HOWEVER: other obligations may apply (DAC7, consumer protection, sector-specific)

SCENARIO 3: PLATFORM IN REGULATED SECTOR

IF the platform operates in a sector covered by AML obligations: - crypto-asset platforms: MiCA + AMLR obligations from 2027 - crowdfunding platforms: AMLR obligations from 2027 - real estate platforms: may trigger Wwft obligations depending on structure - financial services platforms: full AML/KYC obligations

SCENARIO 4: MARKETPLACE WITH PROFESSIONAL SELLERS

IF the platform hosts professional sellers/service providers: - DAC7 reporting obligations apply (see section below) - seller identity verification required for tax reporting - NOT the same as AML KYC but overlapping data requirements

PSD2 AND MARKETPLACE PAYMENTS

THE COMMERCIAL AGENT EXEMPTION

PSD2_ARTICLE: Article 3(b) — exemption for commercial agents

ORIGINAL_RULE (PSD1): platforms acting as commercial agent for buyer OR seller were exempt. PSD2_TIGHTENING: exemption only applies if platform acts for EITHER payer OR payee, not both. MARKETPLACE_IMPACT: most marketplaces act for both buyers and sellers — exemption does not apply.

CONSEQUENCE: - if platform collects payment from buyer AND distributes to seller = regulated payment service - platform must either: (a) obtain payment institution licence, or (b) use a licensed PSP

USING A LICENSED PSP

STRIPE_CONNECT: - Stripe operates as a licensed e-money institution (STEL, Central Bank of Ireland) - platform does not receive or hold seller funds - Stripe performs KYC on sellers as part of Connect account onboarding - platform provides seller data to Stripe via API or Stripe-hosted onboarding - three account types: Standard, Express, Custom (see below)

MOLLIE_CONNECT: - Mollie is licensed by De Nederlandsche Bank (DNB) as payment institution - similar model: platform does not hold funds, Mollie handles seller KYC - strong NL/EU payment method coverage (iDEAL, Bancontact, SOFORT) - co-branded seller onboarding flow

ADYEN_FOR_PLATFORMS: - Adyen licensed by DNB - full marketplace payment solution with integrated seller KYC - enterprise-focused: higher volume requirements

MANGOPAY: - Luxembourg-licensed e-money institution - purpose-built for marketplace payments - integrated KYC and wallet infrastructure

PSP ACCOUNT TYPES (STRIPE CONNECT EXAMPLE)

STANDARD_ACCOUNTS: - seller creates full Stripe account - Stripe handles all KYC via seller's own dashboard - platform has least control but least compliance burden - seller sees Stripe branding

EXPRESS_ACCOUNTS: - platform initiates onboarding, Stripe collects KYC - Stripe-hosted onboarding flow with some platform customisation - good balance of control vs compliance delegation - platform provides link, seller completes in Stripe's UI

CUSTOM_ACCOUNTS: - platform fully controls the onboarding UX - platform collects KYC information and submits to Stripe via API - most integration effort but best UX control - platform is responsible for collecting accurate data - Stripe still makes the verification decision

RECOMMENDATION_FOR_GE_PROJECTS: - start with Express: fastest to implement, compliant, reasonable UX - move to Custom only when UX requirements justify the effort - Standard is too disconnected for most marketplace UX expectations

DELEGATED KYC THROUGH PAYMENT PROVIDERS

HOW IT WORKS

PRINCIPLE: the licensed PSP performs AML/KYC on behalf of the platform. LEGAL_RESPONSIBILITY: PSP is the obliged entity, not the platform. PLATFORM_ROLE: facilitate data collection and pass to PSP.

DATA_FLOW: 1. seller signs up on platform 2. platform collects basic info (name, email, business type) 3. platform initiates KYC via PSP API or redirect 4. PSP collects/verifies identity documents 5. PSP performs sanctions/PEP screening 6. PSP returns verification status to platform 7. platform enables/restricts seller features based on status

WHAT THE PLATFORM MUST STILL DO

EVEN_WITH_DELEGATED_KYC: - collect enough information to identify sellers for DAC7 reporting - implement terms of service requiring sellers to maintain accurate information - monitor for fraudulent sellers (fake products, counterfeit, prohibited items) - handle consumer complaints and dispute resolution - implement seller suspension/removal for policy violations - maintain records of seller onboarding decisions

WHAT THE PLATFORM MUST NOT DO

DO_NOT: - perform your own sanctions screening if PSP already does (avoid duplicate obligations) - store copies of identity documents collected by PSP (data minimisation) - make AML decisions — this is the PSP's responsibility - represent to sellers that the platform performs KYC (if it's actually the PSP)

DAC7 REPORTING REQUIREMENTS

WHAT IS DAC7

DIRECTIVE: EU Directive 2021/514 (DAC7) EFFECTIVE: 1 January 2023 (already in force) PURPOSE: tax transparency — platforms report seller income to tax authorities SCOPE: digital platforms facilitating goods, services, property rental, or transport in the EU

WHO MUST COMPLY

OBLIGED: any platform operator facilitating reportable activities for EU-resident sellers INCLUDING: EU-based platforms AND non-EU platforms with EU sellers ONE_STOP_SHOP: non-EU platforms register in one Member State for all EU reporting

SELLER INFORMATION TO COLLECT

FOR_INDIVIDUALS: - full name - primary address - date of birth - Tax Identification Number (TIN) in each relevant Member State - VAT identification number (if applicable) - bank account / IBAN

FOR_LEGAL_ENTITIES: - legal name - primary address - TIN in each relevant Member State - VAT identification number - business registration number - bank account / IBAN - each permanent establishment through which relevant activities are carried out

FOR_PROPERTY_RENTAL: - property address - land registry number (if available) - number of rental days per listing - type of each listing

VERIFICATION REQUIREMENTS

MANDATORY: - verify TIN and/or VAT ID against electronically searchable databases - cross-check information against platform's existing records - request correction from seller if discrepancies found

PROCESS: 1. collect seller information at onboarding or during initial reporting period 2. verify TINs against Member State databases (where available) 3. if verification fails: request updated information from seller 4. if seller does not respond after two reminders: close account 5. retain records for 5 years

REPORTING THRESHOLDS

EXCLUDED_SELLERS (goods only): - fewer than 30 transactions AND total consideration below EUR 2,000 in reporting period - threshold applies per seller per reporting period - if either threshold is exceeded: seller becomes reportable

EXCLUDED_CATEGORIES: - large-scale property renters (2000+ transactions/year — e.g., hotel chains) - government entities - publicly traded entities

REPORTING DEADLINES

DUE_DILIGENCE: complete by December 31 of reporting period REPORTING: submit to tax authority by January 31 of following year EXAMPLE: 2026 activity → due diligence by Dec 31, 2026 → report by Jan 31, 2027

REPORTING CONTENT

PER_REPORTABLE_SELLER: - seller identity information (as collected above) - total consideration paid or credited per quarter - number of relevant activities per quarter - fees, commissions, or taxes withheld by the platform per quarter - bank account to which consideration is paid - Member State of the seller's TIN

PENALTIES

MEMBER_STATE_DETERMINED: each state sets its own penalties GENERAL_PRINCIPLE: effective, proportionate, and dissuasive SELLER_NON_COMPLIANCE: account closure after two reminders for failure to provide information PLATFORM_NON_COMPLIANCE: potential registration revocation and EU-wide blocking

TIERED VERIFICATION FOR PLATFORMS

PROGRESSIVE VERIFICATION MODEL

Do NOT require full KYC at signup — it kills conversion. Require progressively more verification as the seller's activity increases.

TIER_1_BASIC (signup): - email verification - phone number verification - accept terms of service - ENABLES: account creation, browsing, listing creation (no sales)

TIER_2_IDENTITY (before first payout): - name, date of birth, address - TIN / BSN (for DAC7 compliance) - bank account / IBAN - basic ID verification via PSP (Stripe/Mollie onboarding) - ENABLES: receiving payments, standard seller features

TIER_3_ENHANCED (high volume or high risk): - full KYC via PSP (document + liveness + face match) - business verification for professional sellers (KvK extract, VAT number) - source of funds/goods documentation (if applicable) - ENABLES: high-value transactions, premium seller features, removal of payout limits

TIER_4_FULL_KYC (regulated sectors): - enhanced due diligence equivalent - UBO verification for business sellers - sector-specific compliance checks - ENABLES: financial services features, regulated product categories

PAYOUT GATING

PRINCIPLE: allow sellers to start listing and selling, but hold payouts until identity is verified. IMPLEMENTATION: - Stripe Connect: deferred onboarding — charges succeed, payouts blocked until KYC complete - Mollie: similar hold mechanism - display clear messaging: "Complete verification to receive your earnings"

TIMELINE_PRESSURE: - give sellers reasonable time to complete verification (7-14 days from first sale) - send reminders at 3, 7, 10 days - if not completed by deadline: refund buyers and suspend listings

SELLER ONBOARDING UX

MAKING KYC NOT TERRIBLE

PRINCIPLES: - explain WHY verification is needed (legal requirement, protect their earnings) - show progress (step 1 of 3, progress bar) - support document upload from phone camera OR file system - provide real-time feedback on document quality (blur, glare, cropping) - show estimated completion time (2-3 minutes for basic, 5-10 for full) - allow save and resume (do not lose progress on session timeout)

DOCUMENT UPLOAD UX

CAPTURE_GUIDANCE: - show document outline overlay on camera - detect document edges in real-time - alert if image is blurry, too dark, or partially cropped - auto-capture when document is properly aligned - support both front and back capture for ID cards

ERROR_HANDLING: - clear error messages: "Document expired — please use a valid document" - retry without re-entering other data - offer alternative document types if primary fails - provide help centre link for common issues - escalation path to human support

BUSINESS SELLER ONBOARDING

ADDITIONAL_STEPS: - business type selection (sole trader, BV, VOF, etc.) - KvK number input with real-time validation (KvK API lookup) - auto-populate business details from KvK extract - UBO declaration or identification - VAT number input with VIES validation (EU VAT check)

LOCALISATION

FOR_NL_PROJECTS: - support Dutch and English - accept BSN as TIN (Burgerservicenummer) - iDIN as alternative identity verification for Dutch residents - iDEAL for bank account verification (payment method = implicit IBAN verification)

FOR_EU_PROJECTS: - support languages of target markets - accept national ID documents of all EU/EEA countries - accept national TIN formats per country - display country-specific guidance for document upload

PLATFORM LIABILITY

FOR SELLER IDENTITY

WITH_DELEGATED_KYC: - PSP bears AML/KYC liability — platform does not - platform bears responsibility for DAC7 due diligence - platform bears responsibility for consumer protection (seller accuracy)

WITHOUT_DELEGATED_KYC: - if platform handles payments without PSP: full AML/KYC liability - requires payment institution licence and compliance programme - NOT recommended for GE client projects — always use licensed PSP

FOR SELLER ACTIVITY

PLATFORM_RESPONSIBILITY: - monitor for prohibited items/services - respond to intellectual property complaints - handle consumer disputes and refunds - cooperate with law enforcement requests - remove illegal content under Digital Services Act (DSA)

DSA_OBLIGATIONS (Regulation (EU) 2022/2065): - effective Feb 17, 2024 for all platforms - transparency reporting - notice-and-action mechanisms - trusted flagger system - traceability of traders on online marketplaces

TRADER_TRACEABILITY (DSA Article 30): - before allowing traders to use platform: collect and verify - name, address, phone, email - copy of ID document - bank account details - trade register information - self-certification of compliance with EU product safety law - verify information using publicly available databases (KvK, company registers) - publish at minimum: trader name and contact info visible to consumers

PSD3 PREPARATION

WHAT IS CHANGING

STATUS: European Commission proposals published Jun 2023, negotiations ongoing EXPECTED_APPLICATION: not before 2026 (likely 2027-2028)

KEY_CHANGES_FOR_PLATFORMS: - commercial agent exemption expected to be further narrowed - stronger authentication requirements for payment initiation - enhanced consumer protection for marketplace transactions - harmonised fraud prevention and liability rules

WHAT TO DO NOW

  • design payment flows using licensed PSP (Stripe Connect, Mollie, etc.)
  • do NOT rely on commercial agent exemption
  • ensure PSP integration abstracts regulatory details from platform code
  • monitor PSD3 negotiations for final text (expected 2026)

IMPLEMENTATION CHECKLIST FOR MARKETPLACE PROJECTS

PRE-BUILD

  • [ ] determine if platform handles payments or uses PSP
  • [ ] select PSP and account type (Express recommended for start)
  • [ ] determine DAC7 reporting obligations
  • [ ] determine DSA trader traceability obligations
  • [ ] define tiered verification model appropriate to platform type
  • [ ] confirm sector-specific regulations (if applicable)

BUILD

  • [ ] implement progressive seller onboarding (Tier 1 → Tier 4)
  • [ ] integrate PSP for seller identity verification and payout
  • [ ] implement payout gating until verification complete
  • [ ] collect and verify DAC7 data (TIN, VAT, address)
  • [ ] implement DSA trader information collection and display
  • [ ] implement document upload with quality guidance
  • [ ] implement status machine for seller verification state
  • [ ] implement webhook handler for PSP verification results
  • [ ] implement seller dashboard showing verification status
  • [ ] implement admin dashboard for compliance team review

REPORTING

  • [ ] implement DAC7 report generation (quarterly aggregation)
  • [ ] implement DAC7 report submission (manual or automated, per Member State)
  • [ ] implement seller notification for data collection
  • [ ] implement two-reminder flow for non-compliant sellers
  • [ ] implement account closure for persistent non-compliance
  • [ ] retain DAC7 records for 5 years

ONGOING

  • [ ] monitor seller verification status (alert on high failure rates)
  • [ ] re-verify sellers on PSP request (expired documents, risk triggers)
  • [ ] monitor DAC7 thresholds for newly reportable sellers
  • [ ] update platform terms when regulations change
  • [ ] annual review of compliance programme against regulatory updates

PRACTICAL EXAMPLE: NL SERVICES MARKETPLACE

SCENARIO: GE builds a marketplace connecting Dutch service providers with consumers.

PAYMENT_FLOW: - consumer books service → pays via iDEAL or card - payment processed by Stripe Connect (Express accounts) - Stripe holds funds until service confirmed - Stripe pays out to seller after confirmation

SELLER_ONBOARDING: 1. seller registers: email, phone, service category 2. seller adds bank account: Stripe Connect Express onboarding 3. Stripe collects: name, DOB, address, ID document, bank account 4. Stripe verifies identity and enables payouts 5. platform collects TIN/BSN for DAC7 reporting 6. platform validates KvK number for professional sellers

BUYER_VERIFICATION: - no KYC required for consumers (platform is not an obliged entity) - standard authentication: email/password, optional MFA - payment method verification handled by Stripe

DAC7_REPORTING: - annually: aggregate seller earnings by quarter - exclude sellers below threshold (< 30 transactions AND < EUR 2,000) - submit report to Belastingdienst by January 31 - notify sellers that their data has been reported

READ_ALSO: kyc-aml.md, kyc-processes.md, kyc-implementation.md, kyc-data-retention.md