UCP: Big Tech's agentic commerce protocol has no compliance layer

Google's Universal Commerce Protocol (UCP) is turning "let the AI buy it for you" into infrastructure. We searched the full text of two published versions of its specification for these words: sanctions, AML, anti-money-laundering, KYC, OFAC, compliance, screening, blocked. The count: zero occurrences. This piece covers three things: what UCP is, what its security layer actually covers, and why the regulatory question — who is this money going to — falls into a gap that belongs to nobody.

What UCP is, and who is behind it

On January 11, 2026, Google CEO Sundar Pichai announced UCP at the National Retail Federation's annual conference: an open standard that lets AI agents discover products, build carts and check out at any participating merchant. Co-developers include Shopify, Etsy, Wayfair, Target and Walmart; Visa, Mastercard, Stripe, American Express and some twenty other firms backed the launch. In April 2026 the Tech Council steering the protocol grew to ten members, adding Amazon, Meta, Microsoft, Salesforce and Stripe. Since March 2026, cart support, catalog access and simplified merchant onboarding have completed the full shopping journey.

In other words: the leading players across retail, payments and platforms have already sat at one table and standardized the interface for agentic shopping. This is not a proof of concept — ucp.dev carries the spec, reference implementations and a sandbox.

What "security" means inside the spec

UCP does have a security design. Its core is a layer called Signals: the platform passes transaction-environment data to the merchant on catalog, cart and checkout requests. As of the 2026-08-25 version, two signal fields are defined: dev.ucp.buyer_ip and dev.ucp.user_agent. The spec is emphatic that signal values MUST NOT be buyer-asserted claims — they must come from the platform's direct observation or independently verifiable third-party attestations. Merchants use them for authorization decisions, rate limiting and abuse prevention; the heavier fraud machinery is placed with the payment credential provider.

Note what this layer defends against: buyers defrauding merchants — stolen cards, bots, abuse. That has been e-commerce's standard anti-fraud battlefield for twenty years, and UCP standardizes its interface.

The layer that is not there

On October 1, 2026 we ran a full-text search across the public UCP specification — the overview and reference documents of both the 2026-08-25 (latest) and 2026-04-08 versions. The following words appear exactly zero times: sanctions, AML, anti-money-laundering, KYC, OFAC, compliance, screening, blocked. Anyone can reproduce this on ucp.dev in under a minute.

That is: the protocol defines how money moves, and says not one word about who it moves to — whether the payee appears on any government list, whether the funds carry regulatory risk.

Layering, not negligence

In fairness, the blank spot matches traditional e-commerce's division of labor: compliance screening has always lived inside licensed institutions — acquirers, issuers and PSPs run sanctions and AML checks within their own obligations, and protocols only standardize interfaces. UCP inherits that assumption, much as HTTP does not care what you transmit. The protocol's authors did nothing wrong.

But the agentic setting widens this seam in three places.

First, payees have changed. Traditional e-commerce payees are registered merchants with an acquirer standing behind them. In the agent economy, any entity that can serve a settlement endpoint can be a payee — and when settlement runs over stablecoin rails, the payee can be an address generated yesterday, with no licensed institution having screened it for you.

Second, agents lack the human line of defense. A person senses that a site feels off; an agent only checks that the response schema validates. When an endpoint is spoofed, the payee address it hands the agent is freshly generated and clean on every list. That class of risk has to be caught at the endpoint layer and the payee layer separately — and neither sits in UCP's signal list.

Third, regulation is moving toward payee identification. Under the FATF Travel Rule framework, receiving institutions carry identification duties of their own, and scrutiny of stablecoin settlement is tightening across jurisdictions. A protocol stack with no slot for this layer means every participant will eventually patch it on their own.

What the missing layer looks like

Described neutrally: a pre-settlement decision on the payee (address, endpoint, entity) returning a machine-executable three-state verdict (allow / review / decline), carrying independently verifiable evidence (which list, which version, listed since when), and producing an attestation that can be bound into the settlement record for later audit. It could live inside a PSP, inside a dedicated trust provider, or enter the protocol as an extension — UCP's signal list is extensible, which is exactly where such a layer could one day plug in.

Disclosure: OceanAlt builds precisely this layer (pre-settlement compliance screening), so this analysis has a position. Our hedge is method transparency: every claim above names what we searched, which version, and when. You do not need to trust us — searching ucp.dev yourself takes less time than reading this paragraph.

Boundaries

UCP iterates fast (this piece cites the 2026-04-08 and 2026-08-25 versions), and our conclusion holds only as of October 1, 2026. The Signals mechanism accepts new fields, and compliance-class signals may well be proposed into it — the day that happens, this article should be updated. We will be watching.

---

Searched: ucp.dev/latest/specification/overview/ and ucp.dev/2026-04-08/specification/reference/ (searched 2026-10-01). Launch and governance facts from NRF 2026 coverage and ucp.dev public documentation.