Algorithmic Pricing Is Under Legal Scrutiny, and It's Not Just Landlords

Over the past couple of years, a string of US lawsuits has gone after software that sets rental prices using pooled data from competing landlords. The claim is that when a shared algorithm feeds off everyone's pricing data and suggests a rate, it starts to look a lot like coordinated price fixing, even if no human ever picked up the phone. That litigation is now expanding, with more states and cities passing laws specifically aimed at this kind of pricing tool.

It's easy to read that as a niche property story. I don't think it is. The legal argument being tested (that a black box fed by shared competitor data can create anti-competitive outcomes without anyone intending it) applies just as well to dynamic pricing in hotels, car hire, gyms, parking, ticketing, and plenty of B2B pricing tools too. If your business uses software that adjusts prices automatically, this is worth twenty minutes of your attention.

What's actually being argued

The core issue isn't that pricing algorithms exist. Businesses have used demand-based pricing for decades, airlines being the obvious example. The issue is specifically about algorithms trained or fed on pooled data from competitors, run through a shared third-party system, producing suggested prices that everyone then follows. Regulators and courts are asking whether that's functionally the same as a cartel agreeing prices, just with software doing the handshake instead of people.

A second thread running through the same cases is opacity. When a business can't explain why a price was set the way it was, because the logic sits inside a vendor's proprietary model, that's a problem in court and it's a problem with customers too. "The algorithm decided" is not an answer regulators, or increasingly consumers, are willing to accept.

Why this matters beyond rental pricing

If you run a business that uses any third-party pricing engine, whether that's for room rates, event tickets, service call-outs, or subscription tiers, it's worth asking a few plain questions:

• Does the tool use data pooled from other businesses, including competitors, to set your prices?
• Could you explain, in plain terms, why a specific customer was quoted a specific price?
• Do you have a record of what inputs led to that price, or does the vendor hold that and not you?
• If a regulator or a customer complained tomorrow, could you produce an audit trail?

If the answer to the last two is "no", you've effectively handed a commercial decision, and the legal exposure that comes with it, to a vendor you don't control.

The case for owning your pricing logic

This is where building your own pricing logic, rather than renting someone else's black box, becomes a genuinely practical business decision and not just a technical preference. When you own the code that sets your prices, you know exactly what data goes in, what rules apply, and why a particular output came out. That's not a compliance nicety, it's the difference between being able to answer a challenge and having to shrug.

Bespoke pricing logic doesn't have to be complicated. Most businesses aren't running anything like the multi-variable models used in airline yield management. It's usually a set of clear rules: base rate, demand adjustments tied to your own bookings and stock (not a shared pool), seasonal factors, and discount logic, all written down, versioned, and logged. The value isn't in sophistication, it's in the fact that you can trace every decision back to a rule you wrote and a dataset you control.

This is the same principle behind good audit trails in any regulated or scrutinised process. On a recent project, a policy management system I built keeps a tamper-proof record of every acknowledgement and change, precisely so a business can show, months later, exactly what happened and when. Pricing decisions deserve the same discipline. If you can log the inputs and the rule that fired, you're never stuck explaining a decision you can't see inside.

What to do if you're using a third-party pricing tool now

You don't need to rip anything out overnight. A sensible first step is an audit: find out what data your current pricing software actually uses, whether any of it comes from a shared pool with other businesses, and whether the vendor will tell you plainly how a price gets calculated. If they can't or won't answer that clearly, treat it as a flag, not necessarily a reason to cancel immediately, but a reason to plan an exit.

For businesses where pricing is a genuine competitive lever, whether that's trades booking, venue hire, or subscription services, building a smaller, owned pricing engine alongside your existing booking or CRM system is often more realistic than it sounds. It sits on top of data you already hold, applies rules you've agreed with your own accountant or ops lead, and produces a log you can hand over if anyone ever asks. It's the same reasoning that applies to most custom software decisions: control and explainability tend to matter more than they seem to, right up until the day they matter enormously.

The regulatory direction of travel here looks pretty clear. More states are legislating, more cases are being filed, and the definition of "algorithmic pricing" being scrutinised keeps widening. Getting ahead of that by understanding, and ideally owning, the logic behind your own prices is cheaper now than it will be once a regulator asks the question for you.