An agent that spends money on a user’s behalf lands in a regulatory surface most product teams meet only after shipping. Inserting an autonomous initiator into payments does not create an exemption — it creates new questions about who authorized what, who holds the money, and who answers when it goes wrong. AP2 — Google’s Agent Payments Protocol — answers part of that with the mandate: a signed, verifiable record of what the user authorized, and the evidence several of these regimes turn out to want. Almost every obligation here resolves into something an engineer can build: a boundary, an artifact, a retained record, an evidenced decision. This piece maps that surface, and ends with a way to structure controls so a new market is configuration, not a rewrite. It is not legal advice: specifics differ by jurisdiction and by how your money flows, and they change. Get counsel in every market you operate in.
Are you moving money? The licensing question you cannot dodge
The first question every jurisdiction asks is not about agents at all. It is about flow of funds: does value ever come to rest under your control? The vocabulary differs — payment institution, money transmitter, e-money issuer — but the trigger converges. If customer funds land in an account you control, even briefly, you are usually doing a licensable activity.
‘We just move money for our users’ is the argument teams reach for, and it rarely lands. Acting on someone’s instruction is what a regulated payment service is; the regime exists precisely because an intermediary handles other people’s money. Narrow exclusions exist, but they are jurisdiction-specific, not a general shield. The architectural lever is real: a design where you only pass instructions and credentials, while a licensed processor or bank holds and moves the funds, is a materially different posture from one where you operate balances. Financial-crime obligations ride along with licensing, and that programme is its own discipline — see the KYC article.
Strong customer authentication and the machine that is not a person
Several regimes require electronic payments to be authenticated with two independent factors from different categories — something the user knows, has, or is — with the elements bound to the specific amount and payee so an approval cannot be replayed against a different transaction. That binding is the part engineers most often miss, and it matters most for agents.
The exemptions are where agent payments get awkward. They typically cover transactions the payer did not actively initiate — recurring charges after an authenticated setup, merchant-initiated transactions, low-risk or low-value cases — because the point of authentication is confirming a present human. An agent is neither cleanly customer-present nor cleanly merchant-initiated. The practical answer is to make the initial authorization unimpeachable: authenticate the human when the mandate is created, bind it to scope and limits, and treat the agent’s later actions as executing recorded consent rather than inventing consent of their own. Which exemption an acquirer or issuer accepts is a commercial conversation, not an assumption.
PCI DSS scope, and why tokenization is the only sane answer
PCI DSS is not law but a card-industry standard, enforced through your contracts with acquirers and schemes — which in practice makes it as binding. Its central concept is scope: every system that stores, processes, or transmits cardholder data is in the cardholder data environment, and so is anything that can affect their security. Scope is contagious — one service that briefly sees a card number can drag its host, its network segment, and its logging pipeline into audit.
So the strategy is not to comply with a large scope but to avoid acquiring one. Let the card number be captured directly by a processor — hosted fields, an iframe, a device-side SDK — and have your systems receive only a token useless outside your merchant account. Network tokens push further by replacing the credential at the scheme level. For an agent system the rule is blunt: the agent should never see a primary account number. Give it a token, a mandate, and a spending limit.
Payment data is personal data, and the duties pull in two directions
Transaction records, identity documents, device signals, and consent records themselves are personal data in most modern data-protection regimes, and some — biometrics, identity-document images — sits in a more sensitive tier. The engineering obligations recur even where details differ: a lawful reason for each use, collect only what the purpose requires, keep it only as long as needed, secure it in transit and at rest, handle access and deletion requests, and paper the cross-border transfers.
Two duties actively conflict, and it is worth designing for rather than discovering. Record-keeping rules require retaining transaction and identity records for years; data-protection rules give individuals rights to erasure. These reconcile by scope, not by picking a side — retention obligations generally override deletion for the records they cover, and everything else about that user still has to go. Build the data model so the legally-retained core is separable from marketing profiles, behavioural logs, and derived features, or you cannot honour either duty cleanly. Automated decisions that materially affect people also attract explanation and human-review expectations.
Consumer protection: the user keeps the right to unwind
Consumer payment law is built on an asymmetry: the individual is presumed to need protection, and the rights cannot be contracted away by a checkbox. Two families matter here. Unauthorized-transaction rules limit a consumer’s liability for payments made without their authority and push the loss onto the payment chain. Chargeback rights, which in the card world come from scheme rules rather than statute, let a cardholder dispute a charge for non-delivery, misdescription, or fraud.
The uncomfortable implication: an agent acting outside its mandate produces a transaction the user can credibly call unauthorized, and the loss lands on you or your merchant, not on them. ‘The model decided to’ is not a defence you should expect to shift the loss. That makes the mandate more than a design nicety — a signed record showing the user approved this scope, this cart, this amount is the evidence separating an authorized purchase from an unauthorized one. Withdrawal and cooling-off rights for distance purchases add a second unwinding path. Dispute mechanics belong to the sibling articles; what matters here is that your architecture must anticipate reversal.
Disclosure and who the customer thinks they are dealing with
A quieter regulatory strand concerns honesty about the arrangement. Consumers are generally entitled to know who they are contracting with, what a payment will cost before it is made, what currency conversion applies and on what basis, and what their cancellation and complaint routes are. Unfair and deceptive practice rules sit underneath as a deliberately broad catch-all.
Agents strain the assumptions these rules were written under. If the agent picks the merchant, the user may never see a storefront, a price comparison, or a terms page. If your agent is paid to prefer certain merchants, that is a conflict of interest a regulator would expect disclosed. When the agent commits, the user should be able to see what was bought, from whom, at what total, and by what authority — before the money moves where practical, always afterwards. A human-readable receipt of the agent’s reasoning and the mandate it relied on is the cheapest answer to a whole category of consumer-protection questions.
Record-keeping: the audit trail is the compliance artifact
Nearly every regime above eventually asks the same thing in a different accent: show me what happened. Supervisors ask in examinations, schemes in disputes, auditors annually, plaintiffs in litigation. A system that cannot reconstruct a transaction years later is non-compliant in a way no policy repairs.
Concretely: log the full decision chain, not just the outcome — the mandate and its scope, the agent’s selection and its inputs, the cart presented, the authorization request and response, capture, settlement, and any reversal. Make records append-only so a later edit is detectable; store them where retention is enforced rather than merely intended; keep trustworthy timestamps, because ordering is frequently the contested fact; and retain the verifying material alongside the signatures, since a signature you can no longer validate is not evidence. Retention periods vary by jurisdiction and record type, and the safe engineering assumption is years, not months. Design the schema for reconstruction by a stranger.
Outsourcing, incidents, and the accountability that does not transfer
Most agent-payments systems are assembled from other people’s regulated components: a processor, an acquirer, an identity vendor. Using licensed providers is right, but it relocates work rather than removing responsibility. Outsourcing rules share a spine: you remain accountable for outsourced functions, you must diligence a critical vendor before onboarding, the contract must give you audit and information rights, you must monitor continuously, and you need an exit plan.
Incident duties are the other operational obligation teams underbuild. Breaches involving personal data, and operational or payment incidents, commonly carry notification requirements on short clocks — and short clocks are an engineering problem, because you cannot notify what you cannot detect and characterise quickly. Complaint handling with logged, time-bound responses and continuity arrangements round out the set. Build the detection, the on-call path, and the templates before you need them.
A control framework that survives jurisdictional divergence
The trap in multi-market payments is encoding one jurisdiction’s rules into application logic. Rules diverge, change on their own schedules, and a codebase full of regional conditionals becomes unshippable. The alternative is a two-layer split: build control primitives once, and drive them from a per-jurisdiction policy layer that is data, not code.
| Obligation shape | Control primitive | Varies by market |
|---|---|---|
| Authenticate the human | Step-up bound to amount and payee | When step-up applies; which exemptions |
| Limit card-data exposure | Tokenization boundary; no PAN in the agent | Little — scheme rules are global |
| Protect personal data | Classification, residency routing, retention per class | Residency, transfer basis, erasure rights |
| Prove authority | Signed mandates plus append-only decision log | Retention period; evidentiary expectations |
| Allow reversal | Idempotent refund and reversal path | Timeframes; who bears the loss |
| Disclose terms | Pre-purchase summary and receipt generator | Required fields; conflict disclosure |
Run each new market as a mapping exercise against that table with local counsel, then express the differences as configuration: limits, disclosures, retention windows, enabled payment methods. Version the policy data and log which version applied to each transaction, and you can answer ‘what rules were in force when this happened?’ years later — exactly the question you will be asked.