The FTC wants nine companies to explain how they set prices per person. Write your own answer now
On October 28 the FTC asked Walmart, Uber, Delta and six others to explain whether personal data shapes the prices they show and the pay they offer. You're probably not on that list. If your platform sets a price or a payout per person, the questions are still worth answering, in writing, this month.
The FTC issued study orders on October 28, 2026 to nine companies, including Walmart, Target, Uber, DoorDash and Delta, asking whether personal data, loyalty status or AI-driven analysis affects the prices consumers see and, for gig platforms, what workers are paid. It's a study, not an enforcement action. Any marketplace that varies prices or payouts by person should write down the inputs, the rules and who approved them before a regulator, partner or customer asks.
What the FTC asked for
On October 28 the Federal Trade Commission sent orders to nine companies: Walmart and Target; Uber, Lyft, DoorDash and Instacart; and Delta, United and JetBlue. The orders, issued under the FTC's Section 6(b) study power, ask whether personal data, loyalty program participation or AI-driven analysis affects the prices consumers are shown, and, for the ride-share and delivery companies, what workers are paid. The companies have 45 days from receipt to respond.
Reuters, reporting the same day, said the agency wants to know how companies use personal data "such as location, browsing history and income" to set individual prices, wages and job offers, and that it's asking for detail on the tools, strategies and data involved.
This is a study, not a lawsuit. The FTC says it'll use the answers to publish a report for regulators and lawmakers, and it has said it lacks the authority to ban personalized pricing outright. But FTC Chairman Andrew Ferguson has also said that personalizing prices where consumers don't expect it could violate consumer protection law, and that companies should expect enforcement. Several states have bills of their own.
Why it matters if you're not on the list
Nine big names got the orders. Thousands of smaller platforms do some version of the same thing. A marketplace that shows a returning customer a different shipping fee, a services platform that adjusts a quote by neighborhood, a booking site that gives loyalty members a lower rate, a staffing app that offers different pay for the same shift: each of these is a price or a payout that can vary by person.
Some of that is ordinary and welcome. Loyalty discounts and first-order coupons are personalized pricing in the plainest sense, and retailers have defended them as a reward, not a trick. The trouble starts when nobody inside the company can say exactly which inputs move the number. That happens more often than you'd think once a pricing tool, a recommendation model and three years of experiments are layered on top of each other. If you can't write down why two people saw two prices, you don't really know.
That's the useful thing about these orders. They're a public list of the questions a regulator thinks are worth asking. You can answer them for your own platform now, quietly, while it's cheap.
Decision guide
Expected or surprising?
| Consideration | Customer would expect it | Customer would be surprised |
|---|---|---|
| Loyalty | Member price shown as a member price. | Price raised for people who always buy. |
| Location | Delivery fee by distance. | Higher price in a richer neighborhood. |
| Device | Same price on every device. | Price that changes with the phone. |
| Payouts | Pay set by distance and time. | Different pay for the same job, unexplained. |
If you can't write down why two people saw two prices, you don't really know.
Five questions to answer in writing
1. Which prices and payouts can vary by person? List every number a customer or worker sees: list price, fees, shipping, discounts, surge or demand adjustments, payout per job, bonuses. Mark each one fixed, varies by market or time, or varies by individual.
2. What goes into the ones that vary by individual? For each, list the inputs. Location, device, order history, loyalty tier, browsing behavior, acceptance rate, anything inferred about income. Be specific about whether an input is used directly or feeds a model that sets the number.
3. Which tools set them? Your own code, a vendor's pricing engine, an AI model, a rule someone wrote in a spreadsheet. If a vendor is involved, note what data you send them and whether you can see their logic. We wrote about asking whose data a pricing tool learned from before you buy one; the same questions apply to one you already run.
4. Who approved the rules, and when? A pricing change with no owner is the hardest kind to defend. Note who signed off on each rule, and where that decision is recorded.
5. Would a customer expect it? This is Chairman Ferguson's test in plain words. A loyalty member expects a member price. A customer probably doesn't expect to pay more because of the phone they're using. If the honest answer is "they'd be surprised," either tell them or change it.
Where AI makes this harder
The orders mention AI-driven analysis for a reason. A rule written by a person can be read. A model trained to maximize conversion or margin can learn to use an input nobody chose on purpose, because it happens to predict who will pay more. Postcode can stand in for income. Device type can stand in for age. The model never sees the word "income", and the effect is much the same.
That doesn't mean you can't use models for pricing. It means the register has to include what the model is allowed to see, what it's optimizing for and how you check its output. A simple monthly check helps: compare what similar customers paid across neighborhoods, devices and loyalty tiers, and look for gaps nobody can explain. If you find one, you've learned something about your model before anyone else did.
What to keep
The answers are only useful if they stay true. The practical pieces are small:
- A pricing inputs register. One page per price or payout that varies, listing its inputs, the tool that sets it, the owner and the date it last changed.
- Change history. When a rule or model changes, record what changed and who approved it, the same way you'd treat a change to your terms of service.
- The ability to explain one transaction. Pick a random order or job and see whether you can reconstruct why that person got that number. If you can't, that's the gap to close first.
- A view from the other side. For worker payouts especially, check what the worker can see. A pay offer that changes by person with no explanation is the kind of thing these orders are asking about.
How the work moves
One price, written down
- Name the number
Shipping fee, payout per job, member discount.
- List the inputs
Each one, and whether a model uses it.
- Name the tool and owner
Who sets it and who approved the rule.
- Explain one example
Reconstruct a real transaction end to end.
A month, not a project
Nothing here needs a committee. A product lead and an engineer who knows the pricing code can draft the first version of the register in a week. Do the riskiest numbers first: anything that uses location, device or inferred income, and any payout that varies between workers doing the same job.
The 45-day clock applies to the nine companies, not to you. Use it anyway as a deadline: if you can answer the five questions for your own platform by mid-December, you'll be in good shape whatever the study concludes. This isn't legal advice; if the register turns up something that worries you, take it to counsel.
If your marketplace's pricing and payout logic has grown past the point where anyone can explain it, our marketplaces team can help you map it and rebuild the parts that need to be explainable. Talk to us.
Related work: Paddle8.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.