Software is starting to spend money on its own. KYA is the missing handshake — five short proofs an agent presents to a counterparty, machine-readable, signed, and revocable. It's the difference between an instruction and a settled, accountable transaction.
A citation-disciplined reference layer for AI-native financial institutions, agent-payment protocols, and the OCC trust-bank-charter wave.
The KYA gateway accepts an intent and returns a structured verdict for each checkpoint plus a single composite outcome. Edit the subject and intent below, then send — the verdicts are computed live by the KYA Map evaluator.
KYA is a single protocol but it shows up in two very different places. The agent presents proofs; the operator reviews, scopes, and revokes them. Build for one without the other and you have either an oracle no one trusts or a dashboard no one uses.
A long-running process holding a key. It presents the bundle to any party that will accept value. The bundle is small, signed, and re-derivable from on-chain state.
A human or org accountable for everything the agent does. They register the principal once, set caps and policies, and watch a stream of signed receipts. Revocation is one click and propagates in seconds.
The canonical eight-station Straight-Through-Processing overlay, resolved live against a real path template. Switch the path to compare how x402, AP2, and ACK-Pay light up the same stations.
"The authenticated bank-app login — identity established, spending authority scoped by delegation token before any transaction instruction is composed."
A Coinbase Smart Wallet (ERC-4337) on Base, provisioned via the Coinbase CDP SDK or AgentKit, with session keys scoped to the current agent task. The agent's identity binds to a resolvable DID (did:pkh:eip155:8453 for self-custody agents, did:web for ACK-ID-attested agents); the spending envelope is encoded in the session key itself as a typed ERC-4337 UserOperation signer whose scope is enforced by the account contract.
Builder: `createSmartWallet({ delegation, spendLimit, allowedTargets })` through AgentKit; pair with Cloudflare Worker session-key issuance if you want the delegation signed at the edge rather than by a centralized key service.
Compliance officer: KYA checkpoint KYA-1 (Identity) fires here — the agent's DID must resolve to an identifiable human or organizational principal before any HTTP 402 response is honored. The wallet-provisioning step is the attachment point for the principal entity's customer identification program and transaction-monitoring obligations.
"The SWIFT gpi sanctions-screening leg — no value moves until the list check returns pass — plus the card-network fraud engine's velocity and structuring heuristics running in parallel on the same authorization."
A Cloudflare Worker intercepts the HTTP 402 response before the payment fires and runs the compliance pipeline at the edge. The OFAC gate fires against the Chainalysis sanctions oracle at 0x40C5...8fb on Base — results cached in Workers KV with a 1-hour TTL to keep the hot path under 100ms. Simultaneously, a transaction-pattern analyzer queries the agent's transaction history from D1 and checks for structuring, round-tripping, and smurfing patterns against GENIUS §104(d) monitoring heuristics.
Builder: `await middleware.screen(agentAddress, merchantAddress, amount)` returns a `ComplianceResult` with pass/fail flags for sanctions (hard gate) and pattern score (soft monitor); the pipeline halts on first hard-gate failure. The Worker reverts with HTTP 451 Unavailable For Legal Reasons if the OFAC gate fails, and logs a monitor event (non-halting) if AML patterns trip a soft threshold. The reference middleware implementation is live at `/integrations/x402` and deployable at $0–5/mo on Cloudflare's free tier — KV + D1 + R2 + Secrets, no servers.
Compliance officer: this step satisfies GENIUS §6 (AML/BSA) and §8 (sanctioned-counterparty screening for cross-jurisdictional flows). Edge-computed compliance with cached oracle reads keeps the agentic-payment latency budget intact while preserving the gate's enforcement properties.
"The corporate authorization matrix check — the purchasing agent proves it holds the delegated authority, within category and amount and window, to commit the principal's funds to this specific counterparty."
Before the USDC transfer fires, the Cloudflare Worker verifies that the agent is operating within its capability envelope. The ACK-ID delegation chain is resolved — the agent's session key must derive from a valid principal credential, and the target merchant must be within the delegation's permitted-counterparty set. The capability envelope (part of KYA-2 Authorization) enforces per-transaction limits, daily caps, permitted merchant categories (encoded as MCCs or ACK Rulebook category hashes), and temporal bounds.
Builder: `capabilityCheck({ agent, target, amount, timestamp })` returns `{ allowed: bool, reason?: string }` — the Worker reverts with 403 Forbidden if the agent is out of scope. The envelope is also evaluable off-chain in the Worker itself for latency-sensitive paths; the on-chain check remains the authoritative gate.
Compliance officer: this is the code-enforced KYA-2 (Authorization) checkpoint — delegation verification and capability-envelope evaluation are a single authorization decision. C5 Licensing attaches where the agent operates on behalf of a licensed entity (MTL, NYDFS BitLicense, OCC National Trust charter); the envelope must encode the licensee's permitted product scope and geographic restrictions.
"The beneficiary's credit-to-account event — authorization obtained, list checks passed, funds credit irrevocably to the merchant inside the settlement window."
The x402 payment fires atomically on Base. The agent signs an EIP-3009 `transferWithAuthorization` typed-data message committing to the amount, merchant address, and a single-use nonce; the merchant's contract relays the signed message to USDC's ERC-20 contract, which transfers the funds in a single settlement call. The full stack below the enforcement line (L1 Network, L2 Consensus, L3 Execution) processes the transfer in one Base block (~2s).
Builder: the Worker returns the signed authorization in the `X-Payment` HTTP header; the merchant's resource server calls `ERC20.transferWithAuthorization(from, to, value, validAfter, validBefore, nonce, v, r, s)` and serves the paid resource once the transfer mines. Base settlement finality is strong at one block for amounts under institutional thresholds; Coinbase recommends two-block confirmation for x402 flows above $10K.
Compliance officer: GENIUS §4 reserve-backing obligations apply to the USDC in transit — Circle must maintain 1:1 reserves in USD or short-term Treasuries for every token transferred. Recordkeeping (C11) attaches to the block's transaction hash, which becomes the anchoring reference for the downstream receipt.
"The merchant's daily settlement file plus the bank's Reg E recordkeeping bundle — one artifact for the counterparty, one for the examiner, cryptographically linked to the underlying transfer."
The Cloudflare Worker issues a W3C Verifiable Credential receipt (type `X402Receipt` or `ACKReceipt`) binding the agent's DID, the merchant's DID, the amount, the Base transaction hash, and the compliance screening results from Step 2. The VC is signed with the Worker's receipt-signing key (held as a Cloudflare Secret binding), written to Cloudflare R2 under a key derived from the transaction hash, and the R2 object key is indexed in Workers KV as the audit-log entry.
Builder: a public `GET /receipts/:id` endpoint returns the VC for independent verification — any third party can cryptographically verify the receipt's issuer, non-revocation, and claims without access to Cloudflare infrastructure. Receipts are indexed by tx-hash and queryable via the public verifier endpoint; see `src/workers/x402-middleware.ts` for the canonical schema and the KV/D1/R2 binding declarations.
Compliance officer: satisfies C7 (Travel Rule originator/beneficiary data if the transfer crossed $3,000), C11 (recordkeeping under GENIUS §6 and §4(c) books-and-records), and C12 (independent audit trail for the monthly reserve attestation under §4(b)). The verifiable receipt is the artifact an examiner subpoenas — cryptographically linked to the on-chain transfer, independently verifiable, stored in durable object storage.
Resolved 5 steps across 1 chain(s). 5 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.
Coverage notes: 5 disclosed gap(s).
These are the KYA gateway's internal phases, positioned within the broader eight-station STP lifecycle above. Two are one-time; four happen per transaction. Each leaves a signed artifact; missing any one is treated as a hard fail.
Each checkpoint is a small, single-purpose proof. None of them is novel on its own — the value is in the bundle and in the fact that any one of them can fail loudly without breaking the others.
Every agent presents a verifiable credential bound to a key it controls. The issuer is a registered entity; the key is rotatable but not transferrable. No anonymous senders, no replay.
Identity is the cheapest check and the one without which nothing else means anything. KYA-1 fails closed.
Signed VC from a registered issuer
Deterministic, replayable
KYA-1 accepts either a Decentralized Identifier (W3C DID) or a Legal Entity Identifier (ISO 17442 LEI / GLEIF vLEI) as the principal-binding primitive. The vLEI is the regulator-recognized shape at the OCC trust-bank tier; the DID is the developer-native shape for agent identity. KYA binds the agent to either.
A capability chain runs from a registered principal down to the session key. Scopes can narrow at every link but never widen. Revoke the parent and every child stops in seconds.
Authorization is what makes the agent answerable — and what makes velocity caps, MCC restrictions, and time bounds enforceable upstream of the rail.
Each link is a signed attestation. Scope can only narrow.
The issuer signs a balance-lock for the duration of the intent. The agent cannot double-spend a reserve; the counterparty knows the money exists before it lifts a finger.
Stablecoins make solvency a first-class primitive. KYA-3 is the layer that converts a balance read into a contract.
Custody-signed proof of allocatable balance
Sanctions, jurisdiction, MCC allow-lists, counterparty risk, velocity caps. Every rule is a deterministic predicate the operator can read, version, and override. The result is a signed policy decision, not a hunch.
Compliance is where most real-world deployments die. KYA-4 makes the policy surface auditable and the failure modes legible.
Evaluated at intent-time. Decisions are signed and archived.
Agent has used 37% of its rolling 24h cap. Approved, but flagged for the operator's evening review queue. Configurable in policy/velocity.rego.
Intent, verification, settle, and receipt are co-signed by issuer, gateway, and counterparty, then appended to a public inclusion log. A 15-year retention guarantee makes the operator's job — and the regulator's — tractable.
Audit is what lets a CFO trust an autonomous purchaser, and what lets a regulator sleep at night. Without it, the rest is theatre.
Merkleized event log · signed by issuer, gateway, and counterparty
KYA-5 is not a log line — it is an exportable bundle. From one x402 receipt, the examiner-export layer emits an OFAC sanctions-screening trace and a FinCEN SAR-format narrative, keyed to agent identity, with every obligation citing the rule it implements. The artifact neither Circle's Agent Stack nor Catena's ACK stack produces today.
Live mode reads the real Arc testnet transaction and Circle's Compliance Engine; where a credential is absent the bundle runs degraded and says so — provenance and degradation are recorded, not hidden. The honesty is the point.
KYA is a credential layer, not a payment rail. These maps place it against the agent-payment protocols it sits beside — ACK and x402, CCTP cross-chain settlement, and the AP2 × ACP convergence.
KYA supplies the credential layer that ACK and x402 both assume but neither defines: who the agent is, who it acts for, and within what envelope. ACK wraps x402 rather than competing with it; KYA is the proof bundle each presents at the boundary.
When value moves cross-chain via CCTP and x402, the KYA verdict travels with the intent — identity and authorization are resolved once, before burn, and the receipt is co-signed across the bridge.
Google's AP2 and the ACP agent-commerce protocol converge on the same need for a portable principal credential. KYA is the shape that satisfies both — the same five checkpoints, surfaced to either protocol's mandate model.
A non-exhaustive list of vendors that already implement pieces of this stack, mapped to the checkpoint they serve. Substitutability is the goal; no single vendor needs to be load-bearing.
The operator's surface is deliberately small. Fleets, caps, advisories, receipts. Anything more is a footgun.
StableKYA ships as a remote MCP server. Add the block below to your Claude Desktop or Cursor config, restart, and the four tools appear in your agent's toolbelt — backed by the same engine as the callable gateway above.
Most KYA checks can be answered with a yes-or-no: is this operator KYC'd? is this counterparty unsanctioned? is the agent within scope? KYA bundles a ZK-friendly proof format so the gateway can answer truthfully without leaking the underlying record.