Algorithmic Pricing Compliance: Why AI SaaS Vendors Are the Next RealPage

The DOJ's RealPage case never argued that software is illegal. It argued that a specific function, ingesting nonpublic competitor pricing data and outputting synchronized rent recommendations, is illegal regardless of what vertical it runs in. That distinction is the whole ballgame for any AI SaaS vendor selling a pricing engine to multiple customers in the same market, and most vendors have not internalized it yet.

What Was the RealPage Case Actually About?

The RealPage case was a civil antitrust action built on the theory that a single algorithm, fed pooled nonpublic data from competing landlords, functioned as a coordination mechanism even without any landlord directly talking to another. The DOJ, joined by state attorneys general, alleged that RealPage's revenue management software collected rent and occupancy data from competing property managers and used it to recommend prices back to those same competitors, effectively replacing the phone call cartels used to make with a shared algorithm.

The 'Coordinating Function' Theory

The government's legal theory did not require proof that landlords intended to collude. It required only that the software performed a coordinating function: pooling competitor data, running it through a shared model, and returning outputs that predictably moved prices in parallel. Intent became almost irrelevant once the mechanism itself could be shown to produce coordinated outcomes.

Why It Wasn't Really About Software

Property management was incidental to the theory, not central to it. The legal exposure attached to the data flow, competitor inputs feeding a shared model that outputs synchronized prices, not to the fact that the tool happened to be rental pricing software. Swap in freight rates, hotel room pricing, or B2B SaaS quote engines and the same mechanical description applies. This is why compliance counsel across industries paid closer attention to RealPage than the property management trade press did.

Why Is the FTC Now Investigating a Delivery Company Instead of a Landlord Platform?

The FTC issued a Civil Investigative Demand in December 2025 targeting a delivery and logistics pricing platform, signaling that regulators view dynamic delivery pricing through the identical coordinating-function lens used against RealPage. A CID is a pre-litigation discovery tool, not an accusation, but it tells you the agency believes there is a pattern worth probing before it decides whether to file.

The choice of target matters more than the outcome will. Logistics and delivery pricing has nothing to do with rental housing, which is precisely the point regulators appear to be making: the theory travels. Any multi-tenant pricing model that ingests data across customers, then returns pricing guidance or automated pricing decisions back to those same customers, is now a plausible target regardless of industry.

A CID does not establish wrongdoing. It establishes that a regulator has decided the fact pattern, pooled data plus a shared model plus parallel pricing outcomes, is worth a formal look. For SaaS vendors, that is the signal to get your data lineage documentation in order before anyone asks for it.

What Does California's AB 325 Actually Ban?

AB 325 codifies the RealPage coordinating-function theory directly into California statute, prohibiting algorithms that use competitor nonpublic data to recommend or set prices for multiple market participants who compete with each other. The law does not name property management specifically. It describes a mechanism, and any SaaS vendor whose pricing engine fits that mechanical description is in scope.

Defining a 'Coordinating Function' Algorithm

Under AB 325, a coordinating function exists when an algorithm ingests data from multiple competing businesses and its output influences the price, availability, or terms offered by those same businesses back into the same market. The statute is written to capture the pattern rather than a specific product category, which is exactly what makes it durable against the "we're not a landlord platform" defense.

Who Counts as a Vendor Under the Law

Liability under AB 325 is not confined to the software provider. Buyer-customers who deploy a pricing tool that functions as a coordination layer can also carry exposure, even absent any explicit agreement to collude. This is a meaningful shift for procurement teams: signing a contract with a pricing vendor is no longer a purely operational decision, it is a compliance decision with joint liability implications.

How Does Colorado's AI Act Add a Second Layer of Exposure?

Colorado's AI Act guidance treats consequential AI decisions, including pricing that materially affects consumers, as high-risk systems requiring documented impact assessments before and during deployment. This creates a second, independent line of exposure that exists whether or not any coordinating-function antitrust theory ever applies.

Disparate-impact liability under this framework attaches even without collusive intent. If a pricing model's outputs correlate with protected class membership or a reasonable proxy for it (ZIP code, device type, browsing history patterns), the vendor and deploying business face civil rights and consumer protection exposure independent of any market-coordination question. Vendors selling AI pricing tools into consumer-facing markets are now managing two separate legal fronts simultaneously: antitrust risk from market-wide coordination, and civil rights risk from discriminatory individual outcomes. A model can be antitrust-clean and still fail a Colorado impact assessment, or vice versa.

Are DOJ Signals in 2026 Confirming a Broader Enforcement Trend?

Public DOJ statements through mid-2026 indicate algorithmic collusion enforcement is a stated department priority, not a one-off RealPage settlement that regulators intend to move past. Antitrust officials have repeatedly used language framing "AI-driven dynamic pricing" as a category of concern rather than describing RealPage as an isolated bad actor in a niche vertical.

That framing matters for anyone running usage-based SaaS billing, surge pricing, or AI-generated B2B quotes. Enforcement rhetoric aimed at a category, not a sector, means the compliance question is no longer "are we in the same industry as RealPage" but "does our pricing architecture share the same data-flow shape." Vendors betting that this stays a property-management story are reading the trend line backward.

Which AI SaaS Pricing Patterns Carry the Most Legal Exposure?

Three pricing patterns common in AI SaaS carry meaningfully higher exposure under the coordinating-function theory, and they are not exotic: consumption-based billing engines, cross-customer benchmarking features, and real-time demand-based quoting.

Consumption-Based Billing Engines

A billing model that trains its pricing logic on aggregated usage data pulled across a vendor's entire customer base is structurally similar to RealPage's pooled-data architecture, even when no single customer's data is shared verbatim with another. If the model's pricing recommendations for Customer A are shaped by patterns learned from Customers B through Z who compete with A, the coordinating-function question is live.

Cross-Customer Benchmarking Features

Any feature marketed with language like "see how your pricing compares to peers in your market" is, functionally, the exact mechanism regulators have targeted. It does not matter that the feature is framed as a benchmarking convenience rather than a coordination tool. The regulatory theory looks at data flow and output effect, not marketing copy.

Real-Time Demand-Based Quoting

Quote engines that adjust prices in real time based on competitor availability or observed competitor price signals carry the highest exposure of the three, because they most closely resemble tacit coordination as courts and regulators have historically understood it. A system that watches competitor moves and reflexively adjusts is difficult to distinguish, structurally, from an algorithm designed to synchronize prices.

How Do You Audit a Pricing Vendor's Training Data vs. Runtime Data?

Buyers need to force a clear separation between what data trained a pricing model historically and what data the model queries at inference time for a live pricing decision, because these are two different legal exposures with two different evidentiary trails. A vendor that says "we don't use competitor data" without specifying which layer they mean has not actually answered the question.

The Core Question Buyers Should Ask

Ask directly whether competitor or cross-customer data ever enters the training corpus, and separately whether it ever enters the runtime context window or retrieval layer at the moment a price is generated. A model trained years ago on clean, single-customer data can still be compromised at runtime if a retrieval-augmented system pulls in a live competitor price feed before returning a quote. Both layers need a documented, negative answer, or a documented justification.

What an Audit Trail Should Contain

• Model version identifier tied to each pricing decision, not just a current-state description of the model
• Training data lineage documentation showing source, collection date, and customer-consent basis for every dataset that touched the model
• Input features logged per individual pricing decision, including any external or aggregated signals present in the context
• A timestamped decision record sufficient to reconstruct exactly why a specific customer received a specific price at a specific moment

Experiment and lineage tracking tools like MLflow, scored 8.5/10 by the TopReviewed AI panel, can provide the versioning and data lineage layer that regulators and plaintiffs' counsel will eventually ask for in discovery. Without something functionally equivalent, a vendor's claim that competitor data "never" enters the model is an assertion, not evidence.

Observability platforms such as Honeycomb or Grafana, both scored 8.5/10 by the TopReviewed AI panel, can capture the runtime decision trail: which inputs fired which pricing output, at what timestamp, for which customer. That trail is what turns "we believe our system doesn't do this" into a reconstructable record a court will actually accept.

What Should a Compliance-Ready Pricing Stack Look Like?

A compliance-ready pricing stack enforces data isolation at the infrastructure layer, subjects models to documented governance and adversarial testing, and treats access to pricing configs and pipelines as a discoverable asset rather than routine IT plumbing.

Data Isolation Controls

Pricing models should be architected so no single customer's model can train on or retrieve another customer's or a competitor's data, and that boundary should be enforceable through policy, not through developer discipline alone. Infrastructure-as-code tools like HashiCorp Terraform, scored 8.6/10 by the TopReviewed AI panel, let vendors codify tenant isolation as version-controlled policy that can be audited and proven rather than asserted.

Model Governance and Red-Teaming

Open-weight or self-hosted models such as Llama, scored 8.7/10 by the TopReviewed AI panel, or models hosted through Hugging Face, scored 8.9/10 by the TopReviewed AI panel, give vendors more direct control over training data provenance than opaque third-party API calls, which matters considerably once discovery requests start asking for that provenance. Adversarial testing of pricing prompts and outputs for disparate impact, using frameworks like Promptfoo, scored 8.5/10 by the TopReviewed AI panel, needs to happen before deployment. Running that testing only after a regulator's CID arrives is testing for litigation, not for compliance.

Access and Secrets Management

Secrets and access hygiene around pricing model configs and data pipelines matters more once these systems become litigation targets, because access logs themselves become discoverable material. A tool like 1Password, scored 8.5/10 by the TopReviewed AI panel, provides the kind of access control and audit logging that turns "who had the ability to inject competitor data into this pipeline" into an answerable question rather than a guess made under deposition.

How Does This Compare Across Frameworks: SOC 2, GDPR, State AI Law?

No single existing compliance framework fully addresses algorithmic pricing compliance risk, which is precisely why regulators felt the need to write new statutes like AB 325 rather than relying on existing controls. Each framework covers a slice of the problem and leaves a gap somewhere else.

Risk Category	SOC 2 Type II	GDPR (Article 22)	State AI Law (e.g. Colorado)
Data security controls	Directly covered	Partially covered	Not the focus
Coordinating-function / market coordination risk	Not addressed	Not addressed	Not addressed directly (AB 325 is the exception, not Colorado)
Individual right to contest automated decision	Not addressed	Directly covered	Partially covered via impact assessment
Disparate impact / protected class proxies	Not addressed	Not addressed	Directly addressed via impact assessments
Training data lineage documentation	Partially covered	Partially covered	Increasingly required

SOC 2 Type II audits general data security and access controls competently, but it was never designed to ask whether a pricing model's outputs coordinate across competitors, and auditors do not test for that. GDPR's Article 22 automated decision-making provisions overlap partially, but they are framed around an individual's right to contest a decision made about them, not market-wide price coordination among businesses. State AI laws, Colorado's chief among them, are the first frameworks to explicitly require documented impact assessments for consequential pricing decisions, but even Colorado's statute does not reach the antitrust coordination question the way AB 325 does.

What Should Buyers Put in Their Vendor RFP Right Now?

Buyers should put specific contractual warranties, documented audit deliverables, and pre-signature disparate-impact testing requirements into every pricing vendor RFP starting now, before any of this becomes a discovery request instead of a procurement question.

• A specific contract warranty that the model does not train on, or query at runtime, aggregated competitor data across the vendor's customer base
• A required data lineage and audit trail deliverable as a contractual artifact, not a verbal assurance from a sales engineer
• Disparate-impact testing results segmented by protected class proxies, delivered before signature, particularly for any consumer-facing dynamic pricing feature
• A named point of contact and process for responding to regulatory inquiries about the pricing model, defined in the contract rather than improvised after a CID arrives

Treat algorithmic pricing compliance as a procurement gate, not a legal afterthought. If your vendor cannot produce a training-data lineage document and a runtime audit trail on request today, that gap is exactly what a plaintiff's expert witness will highlight first, and the time to close it is before the contract is signed, not after the CID.