i-Mandate Lets an Agent Choose the Fix. Which Institution Actually Authorized That Choice?

i-Mandate matters for the same reason this desk has been reading agent payment launches all month: it names, in one product, both halves of the authority question. An institution states what an agent may decide among. A launch announcement is the only evidence, so far, of how far that decision actually reaches.

What YES BANK and Open actually state

Open Financial Technologies' own company update introduces i-Mandate as a joint initiative with YES BANK, aimed at recurring payments before they fail rather than after. Its own language: the platform helps a customer act on a predicted failure by choosing to change the payment date, switch an eligible repayment account, register another mandate, or complete the payment through an alternate option. That is four distinct alternatives, each a materially different action against a materially different target, presented in the same sentence as options a customer chooses among.

Detailed launch material carried by CXOtoday names the mechanism behind that choice: an AI Payment Agent that determines the appropriate next step within institution-defined rules and helps complete an authorised action. The same coverage states plainly that banks, NBFCs and other institutions retain control over which actions are permitted, when such actions can be performed, applicable customer-consent requirements, and any additional approval or risk controls.

What is not established

The word "authorised" in CXOtoday's own phrase, help complete an authorised action, is doing real work, and it is worth being precise about what it does and does not settle. It states that whatever action executes is meant to be one the institution's rules permit. It does not state where the authorization for that one instance comes from: a standing customer consent captured once when the mandate itself was set up, a fresh consent gesture at the moment the agent proposes the alternative, or an institution-side approval step separate from the customer entirely. Nothing in either source names a consent object, states what it binds to, or states whether it survives to the moment of execution unchanged.

A recurring mandate is not a static object between the moment i-Mandate predicts a likely failure and the moment an alternative action actually executes. A due date can pass. A balance can change. A different, unrelated debit against the same account can clear first. Whether the agent's decision, and whatever consent or approval it relies on, is re-evaluated against the mandate's state at execution time, or whether it is treated as still valid because it was valid when decided, is not stated by either source available for this record. This is exactly the distinction this desk's own Risk Registry already generalizes as approval not bound to the executed action: an authorization that was correct for the state it was granted against is a different claim from an authorization that is still correct for the state the action actually runs against.

Two further specifics are absent from both sources. Which of the four alternatives, if any, the agent may execute directly, as opposed to recommending for a customer or institution to separately approve, is not stated; the two source excerpts available here are consistent with either reading. And what an i-Mandate audit or evidence record contains, whether it names the predicted failure, the alternative chosen, the rule that permitted it, and the consent or approval evidence behind it, is not addressed by either source. This record states each as unknown rather than assuming a stronger binding than the evidence supports.

Where this sits against agent payments elsewhere

The shape here, an institution bounding what an agent may decide among while a separate question remains open about whether the decision itself is the authorization to act, is not new to this desk. It is the same shape Rain's Agent Control Layer, MoonPay's PayBox and AWS's OpenClaw payment session walkthrough each apply to a spending envelope, and the same shape China's Payment & Clearing Association Convention and India's own reported NPCI Unified Agent Protocol apply to a transaction-initiation boundary. i-Mandate is a distinct instance of that pattern, applied to an already-established mandate rather than a fresh payment, from two named institutions with an on-record 11 September 2026 launch date, not a proposed standard or a reported-but-unconfirmed regulatory framework. It belongs here as its own evidence, not as confirmation of any of those other implementations, and this record does not fold it into any of them.

Connected Knowledge assessment

Intelligence: CREATE. No existing record covers YES BANK, Open Financial Technologies or i-Mandate. This is new primary evidence for a bounded, institution-controlled agent decision model applied to an existing recurring-payment mandate rather than a fresh transaction, distinct from the NPCI Unified Agent Protocol and China Convention material this desk already tracks elsewhere.

Records: CREATE. This record preserves both available excerpts exactly, keeps CXOtoday's own "authorised action" language distinct from a claim about where that authorization originates, and states plainly what neither source specifies about consent-object binding, execution-time reauthorization, audit content, or which alternatives are agent-executed.

Risks: NO CHANGE. The two available sources report a launch and a bounded design intent, not an authority failure, a bypass, or a harmful outcome. Evaluated against AEW-005 (approval not bound to the executed action) and declined: the launch material raises the same question that weakness generalizes, whether consent or institution authorization survives to execution once the mandate's state has moved, but does not establish that i-Mandate's own mechanism fails to bind them; the binding mechanism itself is simply unstated. Evaluated against AEW-002 (objective authorization treated as action authorization) and declined for the same reason: a standing mandate-level consent could, in principle, be read as covering every alternative action the agent later selects, but nothing in either source states that i-Mandate actually does this, so this record does not manufacture a weakness from an absence of detail.

Protocols: NO CHANGE. i-Mandate's own reported design, an institution-bounded scope and a customer-consent requirement layered around four distinct named alternatives, is conceptually relevant to EP Authorization Receipts' (EMILIA) action-hash rejection requirement, the existing response to a signed authorization committing to one canonical, specific action rather than a general standing mandate. That relevance is discussed here narratively rather than recorded as a protocol-registry connection, since neither source states that i-Mandate implements action-hash binding or an equivalent mechanism, and the Risk assessment above is itself no change.