An allowlist is only real when the scanner reads it

Brand owners usually think of an allowlist as housekeeping: enter the shops that may sell the product, save, move on. Operationally, it is a boundary around what the detection system is allowed to call suspicious. If that boundary is not applied where findings are created, the setting is decorative.

There are two failure directions. An authorized retailer can appear in the inbox with an alarming score, pushing a reviewer toward action against a legitimate partner. Or a loose match can silence an unrelated seller before anybody sees it. One produces false alarms. The other produces false quiet. Both make the queue harder to trust.

The settings screen and the scanner need one contract

Brand Protector stores owned domains, authorized merchant domains, and authorized merchant names in the tenant’s domain configuration. The relevant scanners resolve those same fields through one merchant-allowlist module. That shared resolver is the contract: the value written in Settings is the value used during detection.

The resolver also includes the brand’s primary domains and keeps a legacy trusted-domain field as a read-only fallback. It reports which sources contributed to the resolved set, along with domain and name counts, in a structured scanner log. That line lets an operator distinguish an empty configuration from a scanner that read the wrong source.

Identity should be inferred from the entry, not the box

People paste messy data into settings. A merchant may arrive as a bare host, a full URL, or a display name. Brand Protector classifies each entry by its shape. A domain-like value becomes a domain identity; a non-domain value becomes a merchant-name identity. A domain typed into the name field still reaches the domain set.

Hosts are normalized before comparison. Schemes, paths, queries, fragments, and numeric ports are removed; case is folded; Unicode domains and their Punycode spelling resolve to the same identity. The resolver recognizes the bare and www forms as the same host without inventing a broader parent.

Exact matching protects both sides of the boundary

Merchant names are exact after case and whitespace normalization. They are not substring rules. A short authorized name therefore cannot silence a different merchant merely because the text appears inside its longer name.

Domain entries are exact too. Adding shop.example.comauthorizes that host; it does not automatically authorizeexample.comor every other subdomain. That choice makes a missing entry visible as noise instead of widening one entry into an invisible suppression zone. The scanner can offer both the full result host and its genuine registrable form for comparison, but the resolver does not derive a parent from the customer’s entry.

Suppression belongs before scoring and persistence

Dismissing an authorized retailer after detection is not equivalent to suppressing it. The record has already been scored, counted, and placed in a human queue. That can distort priorities and leaves every new run to repeat the same work.

Brand Protector checks the shared allowlist before it scores or stores organic-search and Google Shopping findings. The lookalike-domain scanner uses the domain view of the same resolver to remove owned or authorized identities from its candidate set. Unknown sellers continue into the normal scoring path; an allowlisted identity increments an explicit skipped count instead.

How to test an allowlist without trusting the label

A useful acceptance test starts with identities, not screenshots of the Settings page:

• Add one retailer by URL and another by display name, then confirm both are absent from newly created findings on the relevant scans.
• Search a similar but non-identical merchant name and confirm it still reaches scoring.
• Add a retailer subdomain and confirm a sibling host is not suppressed.
• Inspect the scanner contract line to confirm the configured sources were loaded for that tenant and run.

The point is not to make the inbox as small as possible. It is to make every absence intentional. A dependable allowlist suppresses the exact sellers the brand has authorized, preserves unknown sellers for review, and leaves enough evidence to show which rule made the choice.