Pricing Algorithm Risk Triage

Pricing Algorithm Risk Triage

Purpose

Triage the antitrust exposure of a pricing recommender, dynamic-pricing engine, repricer, optimizer, or pricing-as-a-service deployment. The skill maps every data input and output — tracing which inputs reach competitor data directly, through a shared vendor, or through a pool — flags hub-and-spoke and signaling risks, tests the override and audit posture, and generates vendor-diligence and per-jurisdiction framework questions. Every flag is descriptive triage in a draft for attorney review: the skill never concludes concerted practice and never approves a deployment.

Use When

• The business wants to adopt a third-party repricing or dynamic-pricing tool and asks legal to clear the vendor.
• An existing pricing algorithm ingests scraped competitor prices, a vendor data feed, or pooled industry data, and counsel needs the data flows mapped.
• The pricing vendor is known or suspected to serve direct competitors with the same engine or data, raising hub-and-spoke questions.
• Pricing teams have stopped overriding the algorithm's recommendations, or overrides are not logged, and the governance posture needs documenting.
• News of algorithmic-pricing enforcement or litigation in the industry prompts a review of the company's own deployments.
• Procurement or vendor management needs a diligence question list for a pricing-software contract or renewal.

Required Inputs

• Jurisdiction(s) of competitive effect — every country and, where relevant, state/province where the algorithm sets or influences prices, or [verify jurisdiction]. Algorithmic-pricing enforcement frameworks vary by regime.
• Algorithm role — pricing recommendation engine / pricing decision engine / pricing analytics or comparator / dynamic pricing / personalization / revenue management. Mark unknowns unknown/not found/not provided/ambiguous.
• Vendor and user relationship — third-party vendor or in-house? vendor's other customers; whether vendor serves direct competitors with similar inputs or outputs; vendor's data-access scope across customers.
• Data inputs — own historical data only? own current data? public competitor prices (scraped or feed)? competitor private data shared via vendor? consortium or pool data? third-party signals (demand, weather, competitor inventory)? customer-specific data?
• Data outputs — pricing recommendations, optimal prices, market signals, comparator views, customer-segmentation outputs.
• User control posture — can the user accept/reject outputs? set parameters (floor/ceiling/elasticity)? change frequency of recomputation? override per transaction? what evidence exists of independent decision-making?
• Competitor-overlap facts — does the vendor serve the user's direct competitors? does the algorithm's output reflect competitor data the vendor has access to? does the vendor publish or signal prices?
• Audit, governance, and retention — audit logs of recommendations and overrides; retention period; governance committee; documentation of independent decisions.
• Documents and source anchors — vendor contract, data-sharing addendum, algorithm specification, audit logs, internal governance materials.