What the MSPA Is — and What It Is Not

The MSPA is a private, contract-based framework published by the IAB. It is not a law and it does not replace state statutes. Instead, it is a multi-party agreement that participants — publishers, agencies, ad networks, SSPs, DSPs, and data providers — sign onto so they can make consistent legal claims about how personal information flows through programmatic advertising. When everyone in a chain signs the same contract, downstream vendors do not have to negotiate fifty different bilateral data processing agreements to handle a single bid request.

Think of the MSPA as three things at once:

• A contract that flows downstream automatically when a signatory passes data to another signatory.
• A vocabulary for expressing user choices using GPP-encoded strings, including opt-outs of sale, sharing, targeted advertising, and processing of sensitive data.
• A risk-allocation framework that maps each signatory to one of three roles — Covered Business, Service Provider/Processor, or Third Party — and the obligations attached to each.

What the MSPA is not: a substitute for your privacy notice, a replacement for direct user consent where required, or a guarantee of compliance with any specific state law. It is a tool that, used correctly, makes compliance with multiple state laws operationally feasible. Used incorrectly — for example, by signaling participation while continuing to share data after an opt-out — it expands your liability rather than reducing it.

Who Has to Care: The Three MSPA Roles

Before you sign anything, identify which role you actually play. Most publishers are surprised to discover they wear more than one hat depending on the data flow.

Covered Business

You are a Covered Business if you determine the purposes and means of processing personal information about a user — typically the publisher operating the website or app the user visits. As a Covered Business, you are responsible for collecting consent, displaying notices, honoring opt-outs, and configuring the GPP signal that downstream vendors rely on. The user-facing burden lives with you.

Service Provider or Processor

You are a Service Provider when you process personal information on behalf of a Covered Business under contract and only for limited, permissible purposes. Most analytics vendors, hosting providers, and consent management platforms operate in this lane. The MSPA imposes restrictions: no selling, no cross-context behavioral advertising on your own behalf, and tightly defined retention and deletion rules.

Third Party

You are a Third Party when you receive personal information from a Covered Business and use it for your own purposes — most SSPs, DSPs, identity vendors, and data brokers fall here. Third Parties have the heaviest contractual obligations, including direct user-rights handling and downstream flow-through duties when they share data with their own partners.

The MSPA and the Global Privacy Platform (GPP)

The MSPA does not exist in a vacuum. It is the contractual layer; GPP is the technical signaling layer. The IAB Tech Lab's Global Privacy Platform encodes user choices into a single string that travels with bid requests through the OpenRTB protocol. For U.S. signaling, GPP carries section strings for each state with a comprehensive privacy law — for example, USCA (California), USCO (Colorado), USVA (Virginia), USCT (Connecticut), USUT (Utah), and the catch-all US National string for states without a dedicated section.

The MSPA tells your CMP which fields to set inside those GPP sections to claim coverage. The most important fields publishers will see and configure include:

• MspaCoveredTransaction — set to Yes when the publisher is asserting that the bid request is covered by the MSPA framework.
• MspaOptOutOptionMode — indicates whether the user was given a clear opt-out option as required by the MSPA's transparency rules.
• MspaServiceProviderMode — set when downstream vendors must treat the data as service-provider-only.
• SaleOptOut, SharingOptOut, TargetedAdvertisingOptOut — the granular consent flags that bidders read to decide what they may do with the impression.
• SensitiveDataProcessing — a multi-element array signaling the user's choices for racial origin, religious beliefs, health, sexual orientation, citizenship, precise geolocation, and other sensitive categories defined by state law.

If your CMP sets MspaCoveredTransaction = Yes but the publisher has not actually signed the MSPA contract, you have just made a false claim that downstream signatories will rely on. That is a fast path to a contract dispute and, depending on the state, a regulatory complaint.

Sensitive Data: The Trapdoor Most Publishers Miss

Every comprehensive U.S. state privacy law passed since California has expanded the definition of sensitive personal information, and the MSPA folds these into a unified GPP field. Categories typically include:

• Government identifiers (Social Security number, driver's license, passport).
• Account credentials and financial information.
• Precise geolocation, generally narrower than 1,750 feet.
• Racial or ethnic origin, religious beliefs, mental or physical health diagnoses.
• Sex life and sexual orientation.
• Citizenship and immigration status.
• Genetic and biometric data used to identify a person.
• Data concerning a known child under 13 — and in some states, under 16 with extra protections.

Several states require opt-in consent for processing sensitive data, while others permit processing with a right to opt out. The MSPA's GPP encoding lets you express either, but your CMP must know which to ask for based on the user's state. Misclassifying sensitive data — for example, treating health-content browsing as ordinary behavioral data — is the single most common failure mode flagged by state attorneys general in 2024–2025 enforcement actions.

Building an MSPA-Ready Consent Flow

Implementing the MSPA on your site or app is a coordination problem across legal, engineering, and ad operations. The work breaks into roughly five workstreams.

1. Sign the MSPA and Maintain Your Signatory Status

The MSPA is a real contract that legal counsel must review and execute. You will declare the role or roles you operate in, the U.S. states where you do business, and the categories of data you process. Renew annually and update the IAB Tech Lab's signatory portal whenever your role or jurisdiction changes.

2. Configure Your CMP for Multi-State Logic

A single CCPA-only banner is no longer sufficient. Your CMP must detect the user's state — typically via IP geolocation backed by a privacy fallback — and surface the right notices, links, and opt-out controls for that jurisdiction. FlexyConsent and other modern Google-certified CMPs ship multi-state templates that map state-by-state to the correct GPP section strings.

3. Wire GPP Strings Into Your Ad Stack

The GPP string must be inserted into every OpenRTB bid request originating from a U.S. user. For Google Ad Manager users, this means enabling GPP support in the network settings; for Prebid users, it means installing the gppControl_usnat and per-state modules and confirming that the consentManagement adapter is forwarding the encoded string. Test using the IAB Tech Lab GPP decoder to verify the round-trip from CMP to bid request.

4. Honor the Global Privacy Control (GPC) Signal

Most state laws — California, Colorado, Connecticut, and a growing list — require honoring a browser-level GPC signal as a valid opt-out. The MSPA expects signatories to detect GPC and pre-set the SaleOptOut, SharingOptOut, and TargetedAdvertisingOptOut fields accordingly, even before the user touches the banner. If your CMP cannot detect and act on GPC, you are out of compliance regardless of MSPA membership.

5. Audit Downstream Vendors

The MSPA's downstream-flow logic only works if your vendors are also signatories. Before sending data to any SSP, DSP, or data partner, verify their signatory status in the IAB Tech Lab portal. Non-signatory vendors must either be removed from your ad stack for U.S. traffic or covered by separate bilateral DPAs that mirror MSPA terms.

Common Implementation Pitfalls

Several patterns of failure show up repeatedly across publisher audits:

• Signaling MSPA coverage without signing. Setting MspaCoveredTransaction = Yes in the GPP string while the publisher's legal entity has not executed the MSPA exposes the publisher to misrepresentation claims from downstream signatories who relied on the signal.
• Forgetting Texas, Oregon, and Montana. Publishers configured for the original five-state landscape miss laws that took effect in 2024 and 2025. Each has its own opt-out triggers; the MSPA covers them, but only if your CMP's state-detection logic includes them.
• Ignoring sensitive data signals on news and lifestyle content. A reader of a health, religion, or LGBTQ-focused article may be processing sensitive data implicitly. Run a content audit and configure category-level overrides in the CMP.
• Treating GPC as advisory. California's regulator clarified in 2024 that ignoring GPC is a per-violation infringement. The MSPA does not insulate you from this — it depends on you to honor GPC.
• Stale GPP strings cached at the edge. CDN or service worker caching of pages can serve a user a stale GPP string from a prior session. Disable caching on the consent endpoint and add a fresh-fetch step on consent change.

How the MSPA Affects Ad Revenue

Publishers who implement the MSPA correctly typically see modest short-term revenue dips followed by stabilization, while sloppy implementations either over-restrict bids or expose the publisher to enforcement risk. The variables that move the dial:

• Opt-out rates — In states with prominent opt-out links, 5–15% of users typically opt out of sale or sharing. Bid prices on opted-out impressions usually drop 30–60% because behavioral targeting is unavailable.
• Sensitive content classification — Misclassifying ordinary content as sensitive will collapse demand. Be conservative and category-precise.
• Header bidding partner mix — Non-MSPA-signatory partners that you have to disable for U.S. traffic shrink your auction. Replace them with signatories rather than running with thinner demand.
• Server-side tagging — A server-side container that reads the GPP string and conditionally fires tags is the cleanest way to keep analytics and consent in sync.

What Comes Next: 2026 and Beyond

The MSPA is a living agreement. The IAB updates it every year or two as new state laws, attorney general guidance, and federal proposals reshape the landscape. The themes to watch in 2026:

• A possible federal privacy law that would partly preempt state regimes — the MSPA includes preemption fallback logic, so signatories will not be left stranded.
• Expansion of GPP to cover health-specific signaling under the Washington My Health My Data Act and analogous statutes.
• Tighter enforcement of dark-pattern rules in opt-out flows by the California Privacy Protection Agency and the Texas Attorney General.
• Integration with AI and large-language-model training disclosures, which several state legislatures are debating.

Publishers who treat MSPA implementation as a one-time project will fall behind. Treat it as ongoing operational hygiene, owned jointly by legal, ad ops, and product engineering, and reviewed quarterly. The publishers winning at U.S. multi-state compliance are not the ones with the most lawyers — they are the ones whose CMP, ad stack, and audit logs all tell the same story when a regulator asks.

The Bottom Line

The MSPA is the practical answer to a fragmented U.S. privacy landscape. It will not pass laws for you, but it will give your bid stream, your vendors, and your legal team a single common language for opt-outs, sensitive data, and downstream obligations. Pair it with a state-aware CMP, accurate GPP signaling, and disciplined vendor management, and you will spend less time arguing about jurisdiction and more time monetizing the impressions you are allowed to monetize. That is the only sustainable path through 2026 and the wave of state laws still queued up behind it.