Agentic payments need an identity layer, not just a smarter agent_

A useful infrastructure question is appearing in payments: if an AI agent can act for a customer, how does the payment network know which agent is acting, what it is allowed to do, and whether that authority still exists?

Reuters reported on September 10 that the National Payments Corporation of India is developing a registry to verify and monitor AI agents transacting over UPI as part of a Unified Agentic Protocol. The initial direction is deliberately bounded: small, frequent payments first, with more complex conditional actions potentially following later.

“Know your agent” is an architecture problem_

At the Global Fintech Fest this week, SBI chairman C. S. Setty argued for a “know your agent” framework as AI enters banking. The controls he described are familiar individually—identity, authentication, customer consent, transaction limits, audit trails and revocation—but agentic systems force them to work together at execution time.

A policy document cannot answer whether an agent may execute a ₹4,000 payment right now. The runtime needs a verifiable agent identity, a customer authorization bound to a scope, current limits, a record of the decision path, and a revocation mechanism that takes effect before the next action.

• Agent identity: a stable, verifiable identity for the software actor—not only the user or application.
• Delegated authority: explicit scopes describing which actions the agent may perform, for whom, and under what conditions.
• Transaction policy: amount, merchant, frequency, geography and risk limits enforced before execution.
• Consent and revocation: customer authority that can be inspected and withdrawn without rebuilding the workflow.
• Auditability: enough trace context to reconstruct the request, model/tool decisions, approvals and final transaction.
• Step-up controls: deterministic escalation to a person or stronger authentication when confidence, value or risk crosses a boundary.

Voice makes the trust boundary more important, not less_

Setty also pointed to voice-based conversational banking in Indian languages as an inclusion opportunity. That is technically attractive because voice removes a UI barrier, but it also makes authority easy to blur. Understanding a spoken instruction is not the same thing as being authorized to execute the resulting financial action.

A multilingual voice agent therefore needs two separate paths: probabilistic understanding of what the customer means, and deterministic controls governing what the system may actually do. Confirmation, authentication, limits and human escalation belong on the second path.

The operating lesson is broader than payments_

In our agent work at Parallaxis, we have treated tool calls as the operational boundary that deserves trace context. A transcript can explain what was said; it does not by itself show which tool ran, under whose authority, with which inputs, after which checks, or whether a retry caused the action twice. The same principle becomes more consequential when the tool is a payment rail, CRM, ERP or banking API.

The near-term design pattern is straightforward: keep language understanding flexible, but put consequential actions behind an identity-and-policy layer that is explicit, inspectable and revocable. Agentic systems become useful when they can act. They become deployable when an operator can prove why they were allowed to act.