Retail pricing software after the FTC's October: a CEO memo

Two things happened in Washington in the last week of October, four days apart. On Monday 26 October the Federal Trade Commission and 20 US states sued a 21,000-store discount chain for charging more at the register than on the shelf. On Wednesday 28 October the same agency ordered nine companies, two of them the largest general merchandisers in the country, to hand over the methodology behind every price that varies from one person to the next. If you run a retailer and you buy or plan to buy retail pricing software, both actions land on your desk. Not on the legal team's desk. On yours.

This is a memo about what to do with them.

What happened, in two paragraphs

The lawsuit first. The complaint, filed in the Middle District of Tennessee, says the chain advertised one price and charged another for years, failed thousands of state and local pricing inspections, and logged tens of thousands of customer complaints about unhonoured prices between 2023 and 2026 without fixing the root cause. The retailer says occasional discrepancies happen everywhere and that it will fight the case. Whoever wins, the theory of the case is the part that matters: not that a price was wrong, but that the company knew prices drifted between systems and did not build the controls to stop it.

Then the orders. Under Section 6(b) of the FTC Act, the Commission sent special orders to three airlines, two ride-hailing firms, two delivery platforms and two mass retailers. Each has 45 days to document the inputs, tools and procedures it uses to set prices, and to show whether a price depends on loyalty status or on "analysis of personal data". The FTC's own press release says the previous study, in 2024, asked only the software vendors and learned nothing about actual pricing decisions. This time it is asking the companies that set the prices. The vote was 2-0.

Add the state layer. Maryland and Connecticut rules on personalised pricing took effect on 1 October. New Jersey banned personalised algorithmic pricing for grocers in July. By spring more than 40 bills had been filed across two dozen states. None of this is a US-only story: EU retailers already live with the Omnibus Directive's prior-price rule and the AI Act's transparency duties.

Why this is a procurement question

Read the two actions together and a pattern appears. The regulator is no longer asking "is your price fair?" It is asking "show me how the price was made". The lawsuit is about the path a price takes from the pricing system to the shelf label to the till. The orders are about the inputs that feed the price in the first place. In both cases the retailer's answer will come out of its pricing software, or it will not come at all.

That turns a compliance topic into a buying criterion. A pricing tool is now the system of record for a question a regulator, a state attorney general or a journalist may ask with 45 days' notice. If the tool cannot answer, the retailer cannot answer. And "we trust the model" is not an answer.

Most mid-market retailers, the ones with 10,000 to 200,000 SKUs and a pricing team you can count on one hand, do not have a personalised-pricing problem. They price the shelf, not the person, and have no interest in doing otherwise. Their exposure is different and more mundane: they cannot prove it. The price list lives in a spreadsheet, the rules live in someone's head, the publication to stores runs through three exports, and the audit trail is an email thread. When the question arrives, the evidence is not there.

So the due-diligence conversation with any pricing software vendor, or with your own IT team if the tool is home-built, comes down to four questions. They are short. The answers should be too.

Four questions to put to any retail pricing software

1. Which inputs can reach a price?

Ask for the list. Not a slide about "data sources", the actual list of fields the engine can read when it calculates a price. Cost, competitor prices, stock, sales history, margin targets, price families, zones, promotion calendars: all fine. Loyalty tier, device type, browsing history, postcode-level demographics, time on page, anything that identifies or profiles the individual shopper: that is the line the FTC orders and the state laws draw. If any of those fields are in the model, you need to know, and you need to be able to turn them off and show that they are off.

The honest test: can the vendor produce, from the system itself, a report that says "these are the only inputs this price depended on"? If the answer is a verbal assurance, the question has not been answered.

2. Can it reproduce any price it produced?

Pick a product, a store and a date six months ago. Ask the tool to show the price that was live, the rule or model that produced it, the inputs it used, who approved it and when it reached the shelf. The 45-day clock in the FTC orders is generous compared with what a store inspector gives you. A system that cannot rebuild a single historical price decision on demand will not survive either. We wrote a field-by-field guide to the pricing audit trail earlier this year; the seven fields in it are the minimum.

Watch for the gap between "we log everything" and "we can retrieve anything". Logs that sit in a data lake nobody can query are not an audit trail. They are a liability with a storage bill.

3. Does the shelf match the till?

This is the lawsuit question, and it is the one mid-market retailers most often fail. Price accuracy is not a store problem; it is a governance problem that starts in the pricing system. Ask the vendor where the single approved price lives, how it gets to the POS, to the e-commerce catalogue and to the label printer or electronic shelf label, and what happens when one of those three fails. If the tool publishes to one channel and leaves the rest to a nightly job someone else owns, you have a drift machine. The retailer in the Tennessee case had 29,000 complaints on file telling it exactly that, and still did not close the loop.

4. Who approved it, and can a human stop it?

Automated pricing is fine. Unattended pricing is not. The question is whether the tool has an approval step a named person owns, whether that person can override a recommendation and leave a reason, and whether the system can run in "propose only" mode for a category while you build trust. Regulators on both sides of the Atlantic are converging on the same expectation: a human with authority was in the loop, and the system can show it. A pricing tool that goes straight from model to shelf with no approval record may be efficient. It is also undefendable.

What "AI" means inside the pricing tool

Every vendor now says "AI pricing". The word covers two very different machines, and the difference decides whether questions one and two above have good answers.

The first machine is a model that learns a price from data. It ingests sales history, competitor prices, stock, calendar effects and whatever else it is fed, and it returns a number. Its strength is pattern recognition at scale. Its weakness, for this memo, is that the explanation of any single price is a weighting across hundreds of features, and the honest answer to "why this price?" is "because the model said so". If personal data was among the features, you will not find out by reading the output. You find out by auditing the inputs, which brings us back to question one.

The second machine is a rule engine with a model behind it. The rules are written in business language: hold a 12% margin floor on this category, stay within 3% of the cheapest tracked competitor on key value items, round to the price family, never move more than 10% in a week. The model proposes; the rules decide what is allowed; a person approves. Every price carries the rule that produced it, the inputs the rule read, and the approval. This is what we mean by explainable, auditable, rules-based pricing, and it is the design Retailgrid is built around. It is also, not by coincidence, the only design that answers a Section 6(b) order in an afternoon rather than a quarter.

Neither machine is "the right one" in the abstract. A large online marketplace with a data science team may run the first and accept the governance cost. A mid-market retailer with five people in pricing should not. For that retailer the test of AI inside a pricing tool is not accuracy on a holdout set. It is whether the system can tell a category manager, in one sentence, why the price moved, and whether that sentence still holds up when a regulator reads it.

Two things follow for procurement. First, ask the vendor to show you the explanation for a price in their own demo environment, in writing, as the system produces it, not as a sales engineer narrates it. Second, ask what the rule engine can refuse. A model that can be told "no" by a rule is a model you can govern. One that cannot is one you are trusting.

The quiet part

Nothing in the October actions is hostile to pricing software as such. The FTC's complaint against the discount chain is about missing controls, not about automation. The 6(b) orders are about personal data, not about rules that read a competitor's shelf. A retailer that prices by category, zone and competitor position, with a documented policy and an approval trail, is exactly what both actions imply the regulator wants to see. The retailers at risk are the ones that cannot show their work, whether or not the work was clean.

That is the opportunity in the memo. For most mid-market retailers, meeting the bar the FTC just set is not a legal project. It is a tooling decision that was overdue anyway, because the same evidence that satisfies a regulator is what lets a CEO answer "why did margin move last month?" without a week of spreadsheet archaeology. Good pricing governance and good pricing are the same system.

Where to start

If your pricing tool, bought or built, passes the four questions, write that down and keep the answers current. If it fails one, you know what to fix. If it fails all four, you are running a 2019 pricing process into a 2027 regulatory environment, and the cheapest moment to change that is before the first inquiry letter, not after.

Retailers we talk to usually start with the smallest version of the exercise: pick twenty products, reproduce last month's price decision for each from the system alone, and see how far they get. The gaps that show up in twenty products are the same gaps that show up in twenty thousand. If you want a second pair of eyes on that exercise, send us the twenty.