In agent commerce and payment protocols (UCP, AP2, x402), who is responsible for pre-payment compliance checks?
Today no protocol assigns it to a specific party. Each covers its own segment: UCP standardises the interfaces for discovery, cart and checkout, and its security Signals handle abuse prevention (buyer IP, user agent) — the specification text contains nothing on sanctions, anti-money-laundering or payee screening. AP2 uses mandates to express what a user authorises an agent to do. x402 defines how an agent pays over HTTP 402, and its maintainers have said concrete compliance controls stay out of the core spec and belong in companion implementations. So the duty to check who is being paid falls on the integrator — the agent platform, merchant or payment provider — which needs to run a screening call before paying.
Why the gap is wider for agents
In traditional e-commerce the payee is a registered merchant backed by an acquirer, and screening lives inside licensed institutions. When an agent pays, the payee may be nothing more than an address returned by a settlement endpoint — especially on stablecoin rails — with no licensed institution having screened it, and an agent doesn't sense that a site feels off. A spoofed endpoint hands out a freshly generated address no list has seen, so the endpoint and the payee need separate checks.
What integrators can do
Add one step before the agent pays: screen the endpoint (GET oceanalt.com/api/endpoint?url=…) and the payee (POST oceanalt.com/api/decide, returning allow / review / decline with evidence), and on allow bind the returned attestation to the payment record so it can be verified later. This needs no protocol change and fits into UCP, AP2 or x402 flows alike. Our search method and results for the UCP specification are in the research piece "UCP: Big Tech's agentic commerce protocol has no compliance layer", reproducible by anyone.
Where to start: free address check · API docs · watch an address
Boundary of everything above: a screening "clear" only means no match in the data held, never a safety guarantee; this page is not legal or compliance advice.