The Responsible Agentic Payments Framework
When the payer shifts from a human to code, an entire compliance system fails at once. It was built on two assumptions: that a person sits behind each transaction, and that transactions are slow enough to review. RAP is an open, protocol-neutral standard for keeping machine-initiated payments attributable, controllable, auditable and compliant, and adoptable on both sides of the Pacific.
Why it exists
Agentic payments (x402 + stablecoins) turn the payer into code, moving at machine speed, micro-value, high-frequency, with no human in the loop. Existing KYC/AML tooling will fail at scale, and regulation has not yet answered. This framework binds to no single protocol or vendor.
Four principles
Accountability-first
Every machine-initiated payment must trace back to an accountable legal entity.
Defense-in-depth
Layered defenses: agent-side firewall, network-layer screening, settlement-layer compliance.
Protocol-neutral
Adapts to x402, AP2, Visa Intelligent Commerce and Mastercard Agent Pay, with no single-stack lock-in.
Privacy-proportionate
Only the minimum data compliance requires, with clear cross-border boundaries.
Seven pillars
Identity & Attribution · KYA
Know-Your-Agent. Every paying agent binds to an accountable entity, verifiable by counterparties. It is the foundation of the framework, and the biggest gap at the open, verifiable layer.
- ·Each agent has a unique, verifiable identity (verifiable credentials / on-chain attestations)
- ·Identity is bound to a KYC'd legal entity
- ·Counterparties can verify attribution and mandate validity before the transaction
Mandate & Limits
A human's grant to a machine must have bounds: what it can pay for, whom it can pay, and how much.
- ·Explicit mandate scope: purpose, counterparties, time window
- ·Per-transaction / daily / cumulative limits; block or escalate on breach
- ·Mandates revocable at any time, effective immediately
Controls & Guardrails
A firewall belongs between the agent and its wallet.
- ·Spending-policy engine: allowlists, blocklists, rule-based interception
- ·Resistance to prompt-injection hijacking; anomaly circuit-breakers
- ·Emergency kill-switch + human escalation for high-risk transactions
Screening & AML
AML at machine speed must be upfront, automated and explainable.
- ·Sanctions / mixer / risk-score screening of counterparty addresses (third-party data)
- ·Travel Rule information passing for agent-to-agent transfers
- ·Typology-based continuous monitoring and red-flag alerts
Auditability & Accountability
When something goes wrong, answer: who authorized it, what the machine did, who is responsible.
- ·Immutable, complete transaction and decision logs
- ·Clear accountability chain (entity → mandate → agent → transaction)
- ·Incident response and recourse process
Privacy & Data Governance
Trustworthy is not surveillance; cross-border data needs clear boundaries.
- ·Data minimization
- ·Explicit jurisdictional and cross-border processing rules
- ·Due process and user recourse
Interoperability & Governance
A standard lives or dies by adoption and shared upkeep.
- ·Identity and mandate credential formats interoperable across major protocols
- ·Maintained by a neutral body, open for public comment
- ·Versioned evolution with a traceable changelog
Framework implementation levels
The three tiers below describe which controls are implemented, as a checklist for implementers.
Agent attributed + basic limits + sanctions screening. Fits small-value, low-risk flows.
Level 1 plus a spending firewall, Travel Rule, full audit and hijack resistance. Fits commercial platforms.
Level 2 plus continuous typology monitoring, human escalation, incident response and third-party audit. For regulated institutions and cross-border settlement.
v1.1 addendum · Bilateral decision clause
In a responsible agent payment, both the payer and the payee decide before settlement, and both decisions are verifiable and leave a trace. The payer side (allow / review / decline) is covered by the seven pillars; this clause adds the payee side.
Pre-settlement conditions met; settle, and carry the decision id with the settlement.
Final, with reason codes. Re-paying does not change the result.
Not final. requested_fields states what is missing; the payer supplies it and gets a second round, at most two; unanswered past 48 hours becomes decline.
The payee itself is not ready: not registered, not live, or downgraded with unresolved disputes. This is where the registry enforcement ladder exits.
- Every status carries evidence (kind / ref / complete_through) that a third party can open and check.
- Decisions come from rules, not model judgement; the reason-code table is public and every code traces to the registry or the rules page.
- A payee's readiness is set by the registry's four-level ladder; we seize nothing and issue no verdict of guilt.
The payee must be authorized by whoever controls the origin that served the payment terms. It does not have to be controlled by the seller. A payment processor's deposit address, an escrow or authorize-and-capture contract, a platform that collects for many merchants, and a fresh address per invoice are all legitimate, and none of them is controlled by the seller. Nobody outside can check who controls an address; anyone can check whether the origin authorized it.
A key the origin authorized has signed this address for this network and origin. A changed address that the same origin authorized is treated as a normal rotation and does not raise the decision.
The origin published a signed list of payout addresses for this network and this address is not on it. At least review; if the address also changed since the last payment, decline.
Nothing published, a signature that does not verify, a signer the origin did not authorize, or a lookup that did not finish. This is not a failure: most sellers publish nothing yet. The other checks apply as before.
- Evidence, in order: first an x402 signed offer whose signer the origin authorizes through did:web or a DNS _controllers record. A signature by the payout key alone does not count, because whoever swaps the address can sign for it too. Then a signed /.well-known/x402 manifest from the origin.
- Continuity is judged by the authorizing key and the origin, not by the raw address. A failed lookup is always inconclusive, never "not authorized".
- bound shows only that the origin authorized the address. It says nothing about who the seller is or whether the seller can be trusted.
Previous rule, v1.1 (kept for reference)
Payee continuity: a payee, network or asset that differs from the previous payment raises the decision to at least review (payee_changed_since_previous), whether or not the origin authorized the change. When the current requirements are signed by a key the seller used before, or the new payee is bound to the seller's origin by a name the seller controls, the service reports corroborated: true, and whether the payment may stay allow is the payer's policy.
Governance & participation
Maintained by OceanAlt. The spec text is licensed CC BY 4.0 and the test vectors Apache-2.0; changes are proposed and discussed in public on GitHub (github.com/rap-spec/rap) and versioned. This is a living document; citations and change requests are welcome.
Conflict-of-interest & neutrality statement: RAP is an open standard — any organization may cite, adopt or implement it for free. OceanAlt is RAP's convener and first implementer / assessor, but not the only one. We also offer commercial compliance products built on RAP, making us a stakeholder in the standard. To manage this conflict: (1) RAP's methodology, rating criteria and conflicts of interest are public and reviewable; (2) any rated party has a right-of-reply to contest or correct; (3) ratings are not skewed by commercial relationships. Once RAP reaches adoption milestones, its standard and rating governance will move to a neutral body independent of OceanAlt's commercial products.
How to cite
OceanAlt. "The Responsible Agentic Payments (RAP) Framework, v1.0." 2026. https://oceanalt.com/en/rapHelp build RAP
Are you an issuer, protocol team, platform, or compliance / security practitioner? We invite you to review, cite, or adopt RAP in your product. To see it run, try the live compliance demo in AI Security Lab.