Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

Product safety database screening

product-safety-database-checksDomain: marketplace-platformType: process

Description

Product-safety database screening is the operational layer that runs against the public recall and banned-product registers maintained by safety regulators across the major markets. In the EU, the Safety Gate (formerly RAPEX) publishes the rapid-alert notifications submitted by member states for non-food consumer products presenting a serious risk, with daily updates and an open data feed that platforms can subscribe to. In the US, the CPSC's recall database publishes federally-mandated and voluntary recalls. The UK has its own post-Brexit Product Safety Database operated by the Office for Product Safety and Standards. Health Canada maintains the Recalls and Safety Alerts database. The ACCC in Australia operates the Product Safety Australia portal. Japan's METI runs the Consumer Product Safety database. The data feeds are heterogeneous in format and coverage, and an operator with a multi-jurisdictional footprint usually consolidates them into a single normalized internal index rather than running per-regulator queries. Marketplace operators sit in the middle of the obligation. The EU's General Product Safety Regulation (Regulation (EU) 2023/988, in force since December 2024) at Article 22 makes platforms screen new and existing listings against the Safety Gate, designate a Safety Gate single point of contact, act on serious-risk notifications within two working days, and maintain 24/7 operational coverage of the alerting layer. The obligation extends to existing listings when a new alert is published rather than only to new listings going forward, which means the screening cannot be a one-pass intake check; it has to be a recurring matching run that reaches back into the catalog when a new alert arrives. The DSA Articles 30 to 32 carry parallel obligations on online marketplaces with respect to product traceability and trader-information verification. In the US, the state-level product-liability framework (Restatement Section 402A, the California Court of Appeal's Bolger v Amazon decision, and the New York Marketplace Liability Act of 2023) has been steadily expanding marketplace liability for product harms in ways that make safety-database screening a defensive necessity even where it is not a direct statutory obligation. The operational decomposition is four pieces. The ingest layer pulls the registers on a cadence that matches the regulator's update frequency (daily for Safety Gate during periods of active alerting, slower for some other registers), normalizes the data into a shared schema, and stores the alerts in a queryable form. The matching layer runs the ingested alerts against the platform's listing inventory by product identifier (GTIN, EAN, UPC, ASIN, MPN, or the platform's internal SKU) and by description-similarity for listings where the identifiers are missing, mis-stated, or do not match the regulator's record. The review-and-action layer surfaces matches to a trained moderator, applies the action (delist, restrict, notify the seller, retain with a safety annotation) within the regulator's required timeline, and captures the disposition. And the audit-and-reporting layer documents the per-match action for the regulator's possible future inquiry, with the Safety Gate-specific reporting cadence under GPSR Article 22 requiring the single point of contact to confirm receipt of alerts and the action taken. The piece that consistently goes wrong is the matching layer. Identifier-based matching catches the easy cases, but a meaningful fraction of recalled products carry mis-stated identifiers (counterfeit goods with stolen GTINs, unbranded products with no GTIN at all, products listed under multiple variant SKUs that collapse to the same regulator entry). Description-similarity matching using text-embedding or image-embedding approaches catches a substantial share of the harder cases but produces a higher false-positive rate that the review layer has to absorb. The operators that have built this layer well have generally invested in feedback-loop tuning between the moderators and the matching models, with the moderator decisions feeding back into the model so that recurring false-positive patterns get suppressed and recurring false-negative patterns get strengthened. The defensibility argument with regulators ultimately turns on the matching layer rather than on the ingest cadence, because the regulators read sophistication-of-effort into the false-negative rate.

Applicability

Applies when: business model role is intermediary or mixed AND markets include EU or UK.

How predicates are evaluated

Required by (3 regulations)

  • DSA

    Articles 30-32 read with EU Safety Gate.

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

  • EU GPSR

    Article 22(1) and 22(4) — Safety Gate single point of contact registration; 2-working-day delisting clock for serious-risk notifications; 24/7 operational coverage of the alerting layer.

    Regulation (EU) 2023/988

    Source →

  • US Product Liability

    Restatement §402A + Bolger v Amazon (CA) + NY Marketplace Liability Act — product-safety verification at platform-fulfillment intake.

    Restatement §402A + Bolger v Amazon (CA) + NY Marketplace Liability Act

Fulfilled by (2)

  • In-house build · medium effort
  • descartes · partial · medium effort · $$

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • screening pipeline configuration
  • removal log
  • cross-listing reconciliation

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn