Compliance reference · 2026-05-07
The compliance layer x402 doesn't ship with.
x402 specifies the protocol — the HTTP 402 challenge, the payment proof, the facilitator handshake. The regulated counterparty layer is unspecified by design. pay.sh demonstrates this gap at scale: Solana Foundation and Google Cloud shipped a production gateway with one sentence addressing compliance. The four legs of any agent-payments flow each carry a regulatory question. This page names them, and names the industry players who can answer them.
What this page is. A descriptive map of where regulatory questions live in an x402 flow, written for compliance officers, fintech program leads, and acquirers doing due diligence on agent payments. What it is not. Legal or regulatory advice. The named industry players are illustrative of who can hold each role — actual licensing posture and jurisdictional coverage are matters for the parties themselves to confirm.
Section 1
The four legs.
An agent-to-API payment over x402 has four loci where a regulatory obligation lands. The diagram below is the canonical flow — agent wallet pays a facilitator, which authorizes and settles to an API provider, which receives fiat through a separate off-ramp leg. Each box names the regulatory question that has to be answered before that leg goes to production volume.
Leg 4 — the fiat-out leg — is rendered in red because it is the most regulated leg in the entire flow and the one most often left unspecified in agent-payments announcements. pay.sh's launch materials state providers "receive funds in fiat" without naming the licensed entity that does the conversion. That entity exists; it is just unnamed in public.
See it run
The same request — passed, sanctioned, out-of-scope.
The four legs are not a logger bolted onto a payment — they are gates. Toggle the scenario and watch where the request stops: a clean agent settles (200), a sanctioned wallet is refused at screening (451), an out-of-scope mandate is refused at authorization (403). The reject branches are the proof — enforcement happens before settlement, not after.
Screen · Enforce · Settle · Record · Export — the same five-stage spine the deployed x402-middleware runs, here as a request sequence you can step through, including the 451 (sanctions) and 403 (scope) reject paths most agent-payment demos never show.
Section 2
Each leg, in detail.
Four short notes, one per leg. Each names the question, what x402 says, what pay.sh says, and what a compliance-aware implementation would name.
Agent wallet — is it sanctioned?
The question
Is the wallet on an OFAC sanctions list, or otherwise associated with illicit flows? At per-call micropayment volume an autonomous agent can fan out to thousands of providers before any human review.
What x402 says
Nothing prescriptive. The protocol does not specify wallet-level screening; it leaves that to the facilitator or the publisher.
What pay.sh says
The /docs frame KYC as a "friction" being removed. No mention of wallet-level OFAC screening in the launch materials.
A compliance-aware implementation
Wallet-level screening via the Chainalysis sanctioned-address on-chain oracle, fired at the gate before the facilitator settles. Stable402's home-page demo runs this at S6 of the journey. See the standalone Chainalysis Sanctions Checker tool on the Atlas.
Facilitator — who is the licensed authorizing entity?
The question
The facilitator verifies the payment proof and submits the on-chain authorization. In any non-trivial volume, this is the entity carrying money-transmission risk. Who holds the license?
What x402 says
The protocol specifies what a facilitator does — verify, settle — not who the facilitator is. By design.
What pay.sh says
Names itself as a "Gateway as a Service". The licensed counterparty inside the gateway is unnamed. The eight launch facilitators are catalog participants, not necessarily money-transmission licensees.
A compliance-aware implementation
A named, licensed facilitator. On EVM, the Coinbase CDP x402 facilitator sits inside Coinbase's broader money-transmission stack. On the edge, Cloudflare's facilitator pattern pushes the licensing question to whoever runs on top — which is exactly where Stable402 and the Atlas position themselves.
API provider — recordkeeping and aggregate flow.
The question
The provider receives revenue. Per-call volumes are tiny; aggregate volumes are not. Recordkeeping for the provider's own books, plus Travel-Rule-relevant aggregate flow, becomes load-bearing as agent traffic compounds.
What x402 says
Treats the provider as an opaque endpoint. Provider-side recordkeeping is outside the protocol.
What pay.sh says
Lists the providers (Helius, Alchemy, BigQuery, Vertex AI, Dune, Nansen, and 40+ more). Provider-side revenue handling is implied by the fiat-out promise but not described.
A compliance-aware implementation
Provider-side ledger and invoice handling, with an aggregate-flow trigger for Travel Rule reporting once cross-border thresholds are met. Circle's CCTP and recordkeeping primitives, and StableKYA's compliance-report artifact pattern, are the closest reference designs.
Fiat-out — who is the MSB?
The question
Stablecoins go in; fiat comes out to providers. The entity converting stablecoins to fiat and remitting them is doing money transmission. In the United States that is a FinCEN-registered MSB; in other jurisdictions it is the local equivalent (VASP, e-money issuer, payment institution). Who holds that license?
What x402 says
Nothing — x402 is an HTTP payment-required protocol, not a fiat-rail specification. The protocol stops at the on-chain settlement.
What pay.sh says
"Providers receive funds in fiat." The MSB is unnamed in the launch materials. Somebody has to hold that license; the public materials do not say who.
A compliance-aware implementation
A named, licensed off-ramp partner. Bridge (acquired by Stripe) is the canonical example for stablecoin-to-fiat at scale; BVNK and Paxos run comparable offerings. Circle handles redemption directly for USDC. Stable402's view is that the fiat-out leg should always be a named, licensed party, not an implied one.
Section 3
What Stable402 contributes.
Stable402 is not the regulated counterparty on any of these four legs. We are the public reference that names where the regulatory questions live and points at the named industry players who can answer them. Three concrete contributions:
01
A live small-scale proof.
Stable402's home page runs the full four-leg flow at $0.001 USDC, with Chainalysis OFAC screening firing at S6 as a code-enforced gate before the Coinbase CDP facilitator submits the EIP-3009 transfer. The fiat-out leg is out of scope for the demo (the seller is also the operator), but legs 1, 2, and 3 are working artifacts that compliance officers can inspect.
02
A cartography that names the answers.
The StablecoinAtlas maps 56+ paths across 8 rails — USDC, PYUSD, RLUSD, MMF tokens, tokenized deposits, and more — naming who is the issuer, who is the licensed counterparty, and where compliance is enforced in code versus policy. It is the deeper reference layer agents and compliance officers can both read.
03
A neutral seam between the protocol and the regulated layer.
The protocol layer (x402, pay.sh, Coinbase CDP, Cloudflare facilitator) and the regulated counterparty layer (Circle, Paxos, Bridge, BVNK, Catena Labs) speak different languages. Stable402 sits between them — citing both, branded with neither — so that a CTO at a fintech can land here and see the whole shape in ten minutes.
Protocol crosswalk
x402 is one of four. None ships the gate.
x402 is one of at least four agent-payment protocols converging on USDC-on-Base. They differ in how much compliance they name natively — but the sanctions / AML / audit gate is not part of any of them. It is the same five-stage spine — Screen · Enforce · Settle · Record · Export — regardless of which protocol calls it. Named vendors below are illustrative of who holds each role.
HTTP 402 pay-per-request — live.
Settlement
USDC on Base via the Coinbase CDP x402 facilitator; payment authorized with EIP-3009, signed by an ERC-4337 smart wallet.
Identity & authorization
Agent DID (did:pkh / did:web); spending scope encoded in the session key. A Catena Labs ACK-ID attestation is optional, not required.
What it names
A payment-required handshake. Nothing about sanctions, AML, or recordkeeping — by design, 402 is a settlement primitive, not a compliance layer.
Left to the gate
OFAC screening (31 CFR 501), AML + Travel Rule (31 CFR 1010.410(f)), and the examiner record (31 CFR 1010.430). This is exactly what the deployed x402-middleware adds.
Catena agent-commerce — emerging.
Settlement
USDC on Base, opened under a Catena Labs ACK-Pay session.
Identity & authorization
The richest native model: an ACK-ID Verifiable Credential (principal · permissions · constraints · liability · reputation) plus an ACK Rulebook that enforces delegation and capability as code.
What it names
Identity, policy, and a signed receipt — most of the agent-side spine. Sanctions/AML execution is assumed, not specified.
Left to the gate
Sanctions/AML execution and the examiner-readable export. Honesty marker: ACK-ID revocation is still centralized at catena.inc; a decentralized registry is roadmap, not live.
Agent Payments Protocol (Google-led) — pre-launch.
Settlement
USDC on Base; the AP2 settlement contract enforces the negotiated amount, asset, and deadline atomically.
Identity & authorization
Both agents cross-verify DID documents during an off-chain negotiation handshake before any value moves.
What it names
The most compliance-forward on paper: mutual sanctions screening (Chainalysis OFAC oracle) and Travel Rule data (IVMS101 via Notabene) during negotiation.
Left to the gate
Honesty marker: AP2 is pre-launch — the spec is public but no production deployment exists as of 2026. The gate is what makes those named hooks real and enforced today.
Agentic Payment Channels — micropayments.
Settlement
A USDC payment channel on Base via Circle's channel factory; the deposit is the capacity ceiling for all micropayments in the channel.
Identity & authorization
Identity is established once at channel open; each micropayment is bounded by the channel ceiling rather than re-authorized.
What it names
Front-loads identity and AML at the channel boundary — GENIUS §6 obligations attach at open, not at each micropayment. The compliance innovation of channels.
Left to the gate
Per-claim screening within an open channel and the audit export. The boundary model trades per-payment granularity for efficiency — the gate restores granularity where a regulator needs it.
Four protocols, one missing layer. Whichever an agent speaks, the regulated counterparty still needs the same answer — who is paying, may they, is it permitted, and is there a record an examiner can read. Stable402 is the reference implementation of that answer, branded with none of them.
Export
The artifact at the end of the flow.
Screen · Enforce · Settle · Record · Export. The last stage is the one that matters to a regulator: from a single x402 receipt, the examiner-export layer emits an OFAC sanctions-screening trace (31 CFR 501) and a FinCEN SAR-format narrative (31 CFR 1010.320), keyed to agent identity, with every obligation citing the rule it implements. It is the artifact neither Circle's Agent Stack nor Catena's ACK stack produces today — a compliant agent payment, end to end, to a bundle an examiner can read.
Examiner bundle — PASS
A compliant agentic USDC payment, exported from an x402 receipt. Seven obligations mapped to KYA-1…5; OFAC-trace + SAR narrative; auto-approved, no SAR required.
Examiner bundle — SAR required
The reject branch: a retroactive OFAC designation. The export re-screen diverges from the edge result and the SAR path engages — BLOCK, file SAR.
Both bundles are real output from the runnable export reference (reads the live Arc testnet transaction + Circle's Compliance Engine; runs degraded and says so when a credential is absent, rather than faking a pass). Implements 31 CFR 501 · 1010.320 SAR · 1010.430 recordkeeping · §314(a) 1010.520 · NCCoE Concept Paper Pillar 4.
Section 4
Who should read this.
Compliance officers at issuers and regulated counterparties
Circle, Paxos, Bridge, BVNK, Stripe. Legs 1 and 4 are direct integration points for your existing infrastructure — wallet screening, MSB posture, redemption rails. We are not selling to you; we are documenting that you exist in the right place in the flow, and inviting you to contribute the authoritative description of how your offering plugs in.
Program leads at fintech and infrastructure incumbents
Coinbase, Catena Labs, Cloudflare, Solana Foundation, Google Cloud. The compliance gap above is your sponsorship lane. Funding a public reference that names the gaps and names the named industry players is materially cheaper than building it in-house, and the neutrality is what makes it readable across the ecosystem.
Acquirers doing due diligence on the agent-payments space
The regulated counterparty layer is where durable value lives in agent payments — not in the gateway, not in the SDK, not in the protocol. This page is the most concise public mapping of where that layer lives. If you are evaluating an acquisition target in this space, the four-leg map is the due-diligence checklist.
Section 5
Sources and further reading.
pay.sh — analysis
Solana Foundation + Google Cloud's x402 launch, May 2026 — what's named, what's left blank.
x402 protocol specification
The HTTP 402 Payment Required specification.
StablecoinAtlas.com
The cartography of compliance — 56+ paths, 8 rails, MCP-callable.
Chainalysis Sanctions Checker
The on-chain OFAC oracle, callable as a standalone Atlas tool.
StableKYA.com
Know-Your-Agent depth — the wallet-side compliance reference.
AtomicDvP.com
Delivery-versus-payment for tokenized securities. The institutional sibling thesis.
Stable402 — built on Cloudflare
Architecture, the 40-LOC Worker, and why compliance enforcement belongs at the edge.
[email protected]
Direct contact for compliance, sponsorship, and partnership conversations.
Not legal advice. This page is descriptive analysis of the regulatory landscape around agent payments. The named industry players are illustrative of who can hold each role; actual licensing posture, jurisdictional coverage, and applicability are matters for the parties themselves and qualified counsel to confirm.