Payment rules are converging on one question — who is getting paid?
x402 grew fast for one reason: it asks nothing. A server says "402 Payment Required", an agent pays, the response arrives — no forms, no accounts, no waiting. Payment regulators, meanwhile, are moving in exactly the opposite direction: step by step, they are making identified counterparties the default condition of moving money.
Both of these things are true at once. This post lays out what is actually written into law, where the obligations land, and what an x402 seller can do about it today — without destroying the frictionless model that makes the rail worth using.
What is already law in the EU
Two regulations matter most, and neither is speculative:
- The "travel rule" — Regulation (EU) 2023/1113. Transfers of digital value between regulated providers must carry information about who sends and who receives — and in the EU, unlike other jurisdictions, there is no minimum amount below which this does not apply. Transfers of €1,000 or more that involve a self-custodied wallet trigger additional checks on who controls that wallet.
- The anti-money-laundering regulation (AMLR) — Regulation (EU) 2024/1624. From 10 July 2027, the providers that move digital value become "obliged entities" in their own right: customer due diligence, verification of occasional transactions from €1,000, and a ban on anonymous accounts. This is not a proposal — it is adopted law with a start date.
The US is heading the same way
In April 2026, FinCEN and OFAC jointly proposed treating the infrastructure providers of these payment rails as financial institutions under the Bank Secrecy Act. The GENIUS Act already places the issuers of the digital dollars these rails settle in under anti-money-laundering and sanctions obligations — including the duty to know who funds an agent's wallet, since software itself cannot pass an identity check.
The two largest regulatory blocks are converging on the same question, asked of every payment: who is on each end?
Where the obligations land — and where they do not
Precision matters here. None of these rules puts a duty on an API seller as such. The obligations sit with the regulated intermediaries: the providers that move the value, the issuers of the instruments it settles in. A direct transfer between two self-custodied wallets — the purest form of an x402 payment — sits largely outside mandatory identification today.
So why should a seller care? Because institutional money enters a rail through exactly those intermediaries. A marketplace that wants a bank as a customer, a platform that wants regulated integrators, an agent fleet operated by a listed company — all of them inherit the question from their own obligations. As machine-payment volume grows, "who is on the other end?" stops being a compliance department's question and becomes a condition of participation. The rail will keep working for anonymous endpoints; the profitable side of it increasingly will not.
The tension x402 cannot ignore
The obvious answer — make everyone open an account, fill a form, upload documents — fails twice. It kills the property that makes machine payments useful: no signup, no friction, no waiting. And it turns every seller into a warehouse of personal data it never wanted, with all the obligations and breach exposure that carries.
What the regulated side of the market actually needs is narrower than a copy of anyone's documents: a checkable answer to "who is accountable for this endpoint?"
What a seller can do about it today
This is the seller side of KYA — "Know Your Agent", the emerging category of mechanisms for knowing who stands behind the parties in machine commerce. It is what ZadQ does, and it works with the grain of the rail rather than against it:
- An attestation — a small digitally signed statement — travels in the seller's HTTP responses. It says that a registered issuer has verified the accountable operator behind the endpoint, and that a guarantee deposit stands behind it.
- Anyone can check it for free, on their own machine, in seconds. No personal data travels in the payment flow, and none is stored in transaction records.
- The status keeps itself honest: attestations must be renewed on a published schedule, and a missed renewal drops the status to "not verified" on its own.
For an obliged intermediary or a regulated integrator, that is an audit story made of things auditors can actually check — signatures, published schedules, a named accountable operator — instead of a vault of documents. For the seller, it is a way to be an answerable counterparty without running a signup funnel.
What this does not mean
We would rather over-state the limits than the promise:
- No regulation requires ZadQ. The rules above bind the obliged parties they name, and whether any given artefact satisfies any given obligation is a legal judgement that belongs to that party and its advisers — never to us.
- An attestation is not travel-rule data. It answers "who is accountable for this endpoint", not "who is the originator and beneficiary of this transfer". By design, ZadQ puts no identity data into the payment itself.
- The verdict is advice, not a decision. What to do with a "verified", "not verified" or "unknown" endpoint is always the checking party's own policy. And every integration keeps working when no verdict is available — the badge simply reads "unknown".
- This post is not legal advice. It is a map of the direction of travel, written so that the people who have to act on it can locate themselves on it.
Where this goes
Our bet is simple: machine payments will not stay anonymous, and the layer that identifies them must not recreate the data warehouses the rail was built to escape. That layer is what we build — starting on the seller side, where the accountability gap is felt first.
If you sell over x402, run a marketplace, or integrate machine payments inside a regulated business, the fit conversation is short and honest — including "not you" when that is the true answer. Talk to us, read what we publish instead of certifications, or start with the payments-sector page.