Agentic Payments: How to Prepare

Read this first — it is a draft

This page covers one thing: what happens when the party initiating a payment is a piece of software acting on a standing instruction rather than a person tapping approve.

It is on this site because the gap is about to become an engineering problem, and because the honest answer to most of the questions is that nobody has decided. A page that pretended otherwise would be the first dishonest thing here.

What is known, and what is not

What is actually known, and it is less than the coverage suggests:

Eight questions, and where each stands

Questions 1 and 2 — identity and delegation

Questions 1 and 2 — three identities, and what was actually delegated

The trust model that practitioners have converged on splits three ways, and conflating any two of them is where designs go wrong:

• The customer who wants an agent.
• The delegation itself — its task, its merchant, its category, its monetary range, and its validity period.
• The agent exercising that authority, which should have its own unique identity, cryptographically linked to the customer or organisation it acts for.

The third is the one teams skip, and it is load-bearing. A separate machine identity means a customer can revoke one agent without changing their bank credentials or disabling their other mandates — and it lets a bank distinguish an instruction issued by the customer directly from one generated by a particular agent.

Questions 3 to 5 — enforcement, authentication, liability

Questions 3 and 4 — enforcement, and the authentication gap

# QUESTION 3. WHO ENFORCES THE LIMITS?
# This one IS settled in principle, and it is the most important line here.
#
#   The limits are enforced by the BANK or the PAYMENT NETWORK.
#   Not by the agent. Not by the app the agent runs in.
#
# The RBI's FREE-AI report named PROMPT INJECTION -- hidden commands intended
# to trigger unauthorised transfers -- as a risk to financial AI systems. So
# the design assumption is that the agent WILL at some point be manipulated.

def design_assumption():
    return ("a compromised or manipulated agent must still be unable to "
            "transact outside deterministic limits enforced downstream of it")

# What that rules out: every control that lives in the agent's own reasoning.
UNACCEPTABLE = [
    "system prompt says do not exceed the limit",
    "the model checks the budget before calling the payment tool",
    "a second model reviews the first model's payment decision",
]
# All three are defeated by the same class of attack, because all three are
# instructions to something that reads attacker-influenced text.

ACCEPTABLE = [
    "funds blocked in advance, agent can only draw within the block",
    "per-transaction and per-period ceilings held by the issuer",
    "merchant and category allow-lists evaluated by the network",
    "agent identity revocable independently of customer credentials",
]

# QUESTION 4. AUTHENTICATION -- AND THIS PART IS GENUINELY UNCLEAR.
# RBI authentication directions generally require TWO DISTINCT FACTORS and
# make the issuer responsible for the robustness of authentication.
# Subsequent recurring debits under an e-mandate are exempt. But an agent
# making a CONDITIONAL purchase -- buy if the price falls below X -- is not
# obviously a recurring debit, and may not fit that exemption.

def authentication_position(txn):
    if txn["type"] == "recurring_fixed":
        return "e-mandate exemption plausibly applies"
    if txn["type"] == "agent_conditional":
        # Nobody has answered this. Do not assume the exemption.
        return "UNRESOLVED -- assume authentication is required until told"
    return "two factors"

# WHAT TO CHECK (for a design you are drafting now, not building)
# [ ] no limit is enforced anywhere the agent can reason about it
# [ ] the block or ceiling exists before the agent is given authority
# [ ] the agent has its own identity, revocable on its own
# [ ] the delegation records task, merchant, category, amount AND validity
# [ ] conditional purchases are NOT assumed to inherit the e-mandate
#     exemption. Ask your sponsor bank in writing
# [ ] every agent-initiated transaction is distinguishable in your logs from
#     a customer-initiated one. If it is not, question 5 is unanswerable

THE finding, and it is the one that has no answer yet: agentic payments break the binary that Indian payment liability rests on.

The framework divides transactions into authorised and unauthorised, and customer liability follows that division. An agent creates a third case that fits neither: the customer legitimately authorised the agent, and the agent then did the wrong thing.

Not fraud — nobody stole credentials. Not an authorised transaction the customer wanted — they did not want this one. The agent misread a condition, or was manipulated into acting, or acted correctly on an instruction the customer phrased carelessly.

Questions 6 to 8 — revocation, data, and what to do now

Question 6 — revocation

Understood in principle and almost entirely unbuilt. Three properties a revocation has to have, and each is a design constraint rather than a feature: immediate, so an agent cannot complete a transaction already in flight; independent, so revoking one agent does not disturb the customer's credentials or other mandates; and verifiable, so the customer can see that it happened and when.

The awkward case nobody has addressed: an agent that acted between the revocation being issued and it taking effect. In a system settling in seconds that window is small and it is not zero.

Question 7 — where the data lives

Underdiscussed and straightforward. Some AI systems run on infrastructure outside India. If an agent handles payment credentials or transaction data, India's data-localisation requirements apply to it, and the fact that the agent is a general-purpose assistant rather than a payment product does not change that.

# QUESTIONS 6 TO 8. REVOCATION, RESIDENCY, AND THE PART YOU CAN DO NOW.

def revoke(agent_id, ledger, registry):
    # Three properties, each a design constraint rather than a feature.
    registry.disable(agent_id)                  # IMMEDIATE
    # INDEPENDENT: the customer keeps their credentials and other mandates.
    assert not registry.touches_customer_credentials(agent_id)
    # VERIFIABLE: the customer can see it happened, and when.
    ledger.record("agent_revoked", agent_id, at=now_ist(), visible_to_customer=True)
    # The case nobody has addressed: an agent that acted between the
    # revocation being issued and it taking effect. In a system settling in
    # seconds that window is small and it is not zero. Log it separately.
    return ledger.transactions_in_revocation_window(agent_id)

def residency_gate(agent):
    # If the agent touches payment credentials or transaction data, Indian
    # localisation applies -- being a general-purpose assistant rather than
    # a payment product does not change that.
    if agent["handles_payment_data"] and not agent["infrastructure_in_india"]:
        return "BLOCKED: localisation applies, treat as gating not as a detail"
    return "ok"

# THE ONE THING WORTH BUILDING TODAY, WHATEVER NPCI PUBLISHES.
def record_actor(txn, actor):
    # Cheap now. Expensive retrofitted after volume arrives. And without it
    # the liability question is unanswerable for your own book.
    txn["initiated_by"] = actor["kind"]         # "customer" | "agent"
    txn["agent_id"] = actor.get("agent_id")     # which agent, and
    txn["agent_version"] = actor.get("version") # which version of it
    txn["delegation_id"] = actor.get("delegation_id")
    return txn

# WHAT TO CHECK
# [ ] revocation is immediate, independent of customer credentials, and
#     visible to the customer
# [ ] transactions inside the revocation window are logged separately.
#     Nobody has said who owns them
# [ ] residency is treated as a gate before the integration, not as a
#     compliance item after it
# [ ] every transaction records WHO initiated it, which agent, which
#     version and under which delegation
# [ ] none of the above depends on the protocol being published. That is
#     the point of doing it now

Question 8 — what to do now

The only question with a clear answer.

1. Make agent-initiated transactions distinguishable in your own systems today. A flag, an actor field, an agent identifier. If you cannot separate them in your logs, you cannot answer a liability question later, and retrofitting it after volume arrives is expensive.
2. Put your limits where an agent cannot reason about them. This is good design regardless of what NPCI publishes, and it is the part that will not change.
3. Ask your sponsor bank, in writing, about conditional purchases and the e-mandate exemption. The answer is not public and their answer binds you.
4. Draft the commercial terms consciously. You are allocating unallocated risk.
5. Do not build to the reported design. Reserve Pay's ₹10,000 and 90-day limits are described as possibly being revisited for agentic use. A build keyed to numbers that are under negotiation is a build you will do twice.

What it costs

Three things you could do this quarter

Prepare, do not build

Do: add an actor field and agent identifier to your transaction model → move any limit currently enforced in application logic to somewhere downstream → write the question to your sponsor bank about conditional purchases.

You get: everything that survives whatever the protocol turns out to be. None of this is wasted if the framework changes shape, and all of it is expensive to add later.

Design against the known shape

Do: the above, plus a delegation record carrying task, merchant, category, amount and validity → independent agent revocation → a funds block that exists before authority is granted → logging that separates agent and customer instruction end to end.

Trade: real work against a specification that is not final. Justified only if agentic commerce is central to your product rather than adjacent to it.

Build the product

Do: not yet. The protocol requires RBI approval, has not been opened to general commercial release, and its limits are described as under negotiation.

It breaks when: a team builds to reported numbers. ₹10,000 and 90 days are current Reserve Pay limits that sources say may be revisited for agentic use. Keying an integration to a figure under negotiation is a build you will do twice, and the second time under deadline.

What goes wrong

Where to go next

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are reporting.