Agentic Rails Atlasby merces.ai

Persona

Compliance officer or regulator

KYC, KYB, KYA, AML, consumer protection, AI rules.

Verified (verified under 30 days ago)

Role

Goals

  • Map each party in an agent payment to an existing regulated role, or document the gap.
  • Define what Know Your Agent must mean in practice: who is accountable for an agent and what records exist.
  • Keep sanctions screening and AML monitoring working when the payer is a wallet address and the initiator is a model.
  • Protect consumers' rights to dispute, refund and revoke under Regulation E, Regulation Z, PSD2 and their successors.
  • Apply AI Act transparency obligations and record-keeping to agents that make purchases.
  • Produce audit evidence: who authorized what, when, with which constraints.

Pains

  • Regulation E's definition of unauthorized transfer turns on whether the consumer furnished the access device, and delegation to an agent sits right on that line.
  • Stablecoin rules (the GENIUS Act, MiCA) say nothing about agents, and facilitators that never hold funds fall between categories.
  • Agent registries record identifiers, not legal persons, and most entries are placeholders.
  • AP2 and Verifiable Intent produce signed mandates, but production use outside UCP is unverified, so audit trails are inconsistent.
  • Consent is captured in different places (wallet, surface, merchant) with different retention rules.
  • Guidance is still arriving: a Treasury letter, FCA priorities, an HM Treasury consultation, MAS guidelines, and no CFPB rule.

Decisions they own

  • Whether agent-initiated transactions require their own consent, disclosure and record-keeping policy.
  • Which registries, attestations or certifications count as Know Your Agent evidence.
  • Sanctions and AML treatment of facilitators, relays and agent wallets.
  • How to apply unauthorized-transaction liability when a mandate existed.

Vocabulary

  • KYC
  • KYB
  • KYA
  • AML
  • sanctions
  • Regulation E
  • unauthorized transfer
  • PSD2
  • SCA
  • AI Act
  • GENIUS Act
  • MiCA
  • audit trail
  • consent record

Each protocol from this seat

Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.

ERC-8004: Trustless Agents

Relevance: None

Not one of the main personas on the ERC-8004: Trustless Agents page. The responsibility table gives this persona no step.

x402

Relevance: High

Decides whether and how the business may accept or send x402 payments, and what screening and records it needs. Source [1, 2, 3, 4, 5]

Goals

  • Know who handles sanctions screening and travel-rule data
  • Keep records that satisfy auditors
  • Understand stablecoin rules per market

Pains

  • The protocol has no KYC, know-your-agent or sanctions layer
  • Payment metadata can contain personal data sent to third parties
  • Volume figures that cannot be relied on

Implements

  • Facilitator selection criteria (screening, terms, jurisdictions)
  • Record keeping of PAYMENT-RESPONSE hashes and offers or receipts
  • Data minimization for resource metadata

Must trust

  • The facilitator's screening and its records
  • The stablecoin issuer
  • Product terms such as Cloudflare's merchant-of-record role in cloudflare:402

Questions they ask

  • Is our facilitator a money transmitter in our markets?
  • Who is merchant of record in each variant we use?
  • What personal data leaves our systems in resource descriptions?

First three steps

  1. Map which facilitator screens what (the CDP facilitator runs OFAC and KYT checks)
  2. Review section J for each market we sell in
  3. Strip personal data from resource URLs and descriptions

Metrics they care about

  • Share of payments screened
  • Records retrievable per payment
  • Open regulatory questions per market

A day in the life. Lena reviews the plan to sell API calls through x402 in the US and the EU. The first thing she notices is what the protocol leaves out: no identity, no sanctions check, no dispute process. Screening therefore depends on the facilitator, and the team's chosen facilitator documents OFAC and KYT checks on every payment, which she records as a vendor control. She asks the engineers to stop putting customer names in resource descriptions, because those travel to the facilitator. For the credit-backed Cloudflare variant she notes that Cloudflare is merchant of record with its own terms, and she sends that contract to legal.

Steps in the responsibility table

  • ObservesPublish payment requirements (402 with PAYMENT-REQUIRED)
  • ObservesEnforce spend caps and payTo allowlists
  • ObservesVerify the payload (POST /verify)
  • OwnsScreen for sanctions (KYT, OFAC)
  • ObservesSettle on chain and pay gas (POST /settle)
  • VerifiesReturn and store the PAYMENT-RESPONSE receipt
  • VerifiesMonitor spend and anomalies

Visa Trusted Agent Protocol

Relevance: None

Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.

Agentic Commerce Protocol (ACP)

Relevance: None

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: None

Not one of the main personas on the UCP page. The responsibility table gives this persona no step.

AP2

Relevance: High

Compliance or risk officer: judges whether mandates support consent, liability and data-protection duties. Source [6, 7, 8, 9]

Goals

  • Evidence of consent that holds up
  • Data minimization
  • Know who is accountable

Pains

  • AP2 makes no regulatory claims
  • Liability left to network rules
  • Governance in transition to FIDO

Implements

  • Retention policy for mandates and receipts
  • Review of Trusted Surface consent screens
  • Mapping to SCA, Regulation E and Z, and GDPR

Must trust

  • The Trusted Surface consent capture
  • Signed receipts from merchant and processor
  • Network dispute rules

Questions they ask

  • Does an open mandate count as consent to a specific transaction under PSD2?
  • Who keeps mandates and for how long?
  • Does risk_data contain personal data?

First three steps

  1. Read Dispute Evidence and Security and Privacy Considerations
  2. Map open mandates to your SCA and authorization rules
  3. Set a retention rule for mandates and receipts

Metrics they care about

  • Disputes resolved with mandate evidence
  • Data fields disclosed per presentation
  • Open policy questions closed

A day in the life. Sophie reviews a plan to accept agent purchases at a European retailer. The mandates help: a signed record of what the customer saw and approved, with only the needed fields disclosed. But AP2 itself claims no compliance. Its glossary defines Strong Customer Authentication and dynamic linking without saying a mandate satisfies them, and whether a standing open mandate counts as consent to a specific transaction under PSD2 is untested. She asks the team to keep mandates and receipts for the dispute window, to treat risk_data as personal data, and to follow the FIDO working group because the specification no longer evolves on GitHub.

Steps in the responsibility table

  • ObservesApprove Mandate Content on the Trusted Surface
  • ObservesSign closed mandates in human-not-present mode
  • ObservesVerify the Payment Mandate and issue a token
  • ObservesVerify the Checkout Mandate and constraints
  • ObservesTrack budget and recurrence state
  • ObservesReturn signed receipts
  • ObservesStore the open, closed and receipt tuple
  • ObservesVerify mandates and receipts in a dispute
  • OwnsSet retention and consent policy

Mastercard Agent Pay

Relevance: None

Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.

Sources

  1. CDP x402 facilitator docs (pricing, networks, KYT and OFAC) (external link)Coinbase Developer Platform. Documentation, primary source. Accessed .
  2. CDP x402 facilitator: pricing and supported networks (external link)Coinbase Developer Platform. Documentation, primary source. Accessed .
  3. Hardening x402: PII-Safe Agentic Payments via Pre-Execution Metadata Filtering (external link)arXiv. Paper, primary source. Published . Accessed .
  4. Scheme: batch-settlement on cloudflare:402 (external link)x402 Foundation. Specification, primary source. Published . Accessed .
  5. x402 Protocol Specification v2 (external link)x402 Foundation. Specification, primary source. Published . Accessed .
  6. AP2 Glossary (external link)Google (google-agentic-commerce). Documentation, primary source. Published . Accessed .
  7. AP2 Security and Privacy Considerations (external link)Google (google-agentic-commerce). Specification, primary source. Published . Accessed .
  8. Directive (EU) 2015/2366 (PSD2) (external link)EUR-Lex (Publications Office of the EU). Standard, primary source. Published . Accessed .
  9. AP2 FAQ (external link)Google (google-agentic-commerce). Documentation, primary source. Published . Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts