Agentic AI in Payments

Every major card network has now announced an agentic commerce protocol. Visa launched its Intelligent Commerce initiative (Trusted Agent Protocol) in late 2025. Mastercard followed with Agent Pay, then extended it to machine-to-machine micropayments. Google, Mastercard, and a coalition of processors including Worldpay, Fiserv, Checkout.com, and Adyen have co-developed a shared standard for making agent authorization explicit and auditable. 

The announcements read like a settled future. The regulatory foundation underneath them is not settled at all — and that gap is precisely where a BA's job gets interesting. 

For institutions building or evaluating support for agent-initiated payments, the core question isn't "can our systems technically process a transaction an AI agent submitted." Most payment rails can already do that; a transaction is a transaction to a settlement engine. The real question is a business analysis question: who is legally authorizing this payment, how is that authorization evidenced, and does your current requirements model even have a field for it? 

 The Authorization Gap Your Requirements Docs Don't Cover 

Existing payment authorization frameworks — PSD2's Strong Customer Authentication regime chief among them — were built around a foundational assumption: a human is present at the moment of authorization, and that human's authentication (something they know, have, or are) is the proof of consent. Agentic payments break that assumption cleanly in half. The human isn't present at the transaction moment. They delegated authority earlier — sometimes minutes earlier, sometimes as a standing instruction — and an autonomous system is now acting on a scope of permission that was granted in the past, not consent given in the present. 

PSD2 itself is technologically neutral and doesn't prohibit this, but it also doesn't define how "demonstrable consent" is satisfied when the consenting party is a delegated agent rather than the account holder acting in the moment. This is not a hypothetical gap for your requirements team to flag someday — it's the exact question every card network's new protocol is trying to answer with cryptographically verifiable mandates. If your institution's current account opening and payment authorization business rules only have a binary model — "customer authenticated, yes/no" — that model needs a third state: agent acting under a scoped, time-bound, revocable mandate on the customer's behalf. 

 From Know-Your-Customer to Know-Your-Agent 

This is the requirement that will land on a BA's desk before it lands on an engineer's. The emerging industry framing is "Know-Your-Agent" (KYA) sitting alongside — not replacing — Know-Your-Customer. In practice, this means your onboarding and risk frameworks need to answer a new set of questions that don't map cleanly onto your existing customer due diligence templates: 

What is the verifiable identity of the agent itself, distinct from the identity of the customer who deployed it? Emerging standards use cryptographic identity credentials for this — a verifiable "passport" for the agent, separate from the account holder's KYC record. 

What is the scope of the mandate the agent is operating under — spend limits, permitted merchant categories, time bounds, revocation conditions — and where is that mandate stored and audited? 

What happens when an agent acts outside its mandate? Is that an unauthorized transaction (triggering your existing fraud and reversal workflows), a contractual breach by the agent provider, or something your current dispute-handling process has no category for? 

None of this is abstract policy discussion. It is a concrete gap in your requirements traceability matrix, your fraud rulebook, and your customer dispute intake process, and it needs business rules defined before engineering can build against them. 

 Compliance-by-Design, Not Compliance-Bolted-On 

The EU AI Act entered into force in August 2024 with a phased implementation timeline. Prohibitions on certain AI practices have applied since February 2025, and obligations for general-purpose AI models since August 2025. Critically for financial institutions, the obligations for high-risk AI systems — the category most relevant to payment agents — take effect from August 2026. The Act applies horizontally across sectors, meaning payment agents deployed by or on behalf of an EU institution fall within its risk-based framework regardless of what the payment-specific regulation eventually says. 

That framework requires risk classification, human oversight mechanisms, transparency, and auditability for the AI systems involved. For a BA, this translates into concrete deliverables well before a single line of orchestration code is written: a documented risk classification for any agent-facing payment capability, a defined human-oversight checkpoint (not a rubber stamp — an actual point where a human can intervene before irreversible settlement), and an audit trail specification that a regulator or auditor could actually follow after the fact. 

The institutions handling this well are treating compliance requirements as an input to the architecture, not a review gate applied after the technical design is already locked. That means the BA's requirements-gathering phase needs direct input from compliance and risk stakeholders on mandate scope definitions, escalation thresholds, and audit trail granularity — captured as functional requirements alongside the payment flow itself, not appended as a compliance annex afterward. 

What This Changes About Fraud and Dispute Handling 

Traditional fraud detection models are built on human behavioral patterns — typing cadence, device familiarity, transaction timing consistent with a person's habits. An agent transacting on a customer's behalf breaks those pattern-matching assumptions, because the agent's "behavior" is fast, consistent, and doesn't look like any human's spending pattern at all. This isn't a future problem to schedule for next year's roadmap; it's a requirement to raise now with your fraud and risk teams, because retrofitting fraud rules after an institution has already onboarded agent-initiated volume is a materially harder project than designing for it up front. 

Dispute handling has a parallel gap. When a customer disputes a transaction today, the investigation traces back to a single authenticated session. When an agent initiated the transaction under a mandate granted days earlier, the investigation needs to trace two things: whether the agent acted within its granted scope, and whether the mandate itself was validly and knowingly granted by the customer. Your current dispute workflow almost certainly has no branch for this, and building that branch is a business process design exercise before it's a system change. 

Where to Start 

Agentic payments in 2026 are still, by most credible industry assessments, more pilot than production at scale — the marketing announcements have outpaced actual transaction volume. That's precisely the window in which requirements work is most valuable, before institutional muscle memory hardens around a half-built process. 

The practical starting point for a BA-led initiative is not a technical proof of concept. It's a stakeholder mapping exercise across compliance, fraud, legal, and product to answer three questions together: what does a valid agent mandate look like for our institution, what is our tolerance for irreversible agent-initiated settlement without a human checkpoint, and what does our dispute process need to look like when the "who authorized this" question has two possible answers instead of one. 

Get those answers documented and agreed before the card network protocols your institution adopts force the questions to be answered under deadline pressure instead.