Visa and Mastercard Joined the Same Room. They Still Have to Decide Who Authorized the Agent.

Twenty six companies that mostly compete with each other just agreed to sit in the same room. That is the actual news in Rain's 18 August 2026 announcement, and it is worth being precise about what sitting in a room does and does not accomplish, four days into a week where the loudest claim in payments circles was that agent commerce had just been standardized. It has not been. What happened is narrower, and arguably more interesting: a formal industry admission that nobody, including the companies that move almost all of the world's card volume, currently has a good answer for how an AI agent's payment authority survives contact with an organization that never saw the original delegation.

What Rain announced on 18 August

Rain, a stablecoin payments infrastructure company, announced the Agentic Payments Alliance on 18 August 2026. The founding coalition, as Rain's own announcement and its distribution through PR Newswire list it, is 26 members: Avalanche, Basis Theory, Chainalysis, Circle, Coinflow, Crossmint, delta Network, Episode Six, Evertec, Fireblocks, Fiserv, Kala, Lithic, Mastercard, Monad, PayOS, Rain, Remitly, Rialo by Subzero Labs, Sardine, Shift4, Solana, Turnkey, Uniswap Labs, Visa and Yuno. That spans card networks, a core processor, a stablecoin issuer, digital asset custody infrastructure, wallet and card issuing platforms, blockchain networks, a fraud and compliance vendor and a remittance company. It is not one type of company agreeing with itself. It is most of the distinct roles a single agent payment has to pass through, in one coalition, at the same time.

Rain is explicit, in the same announcement and in its own follow up post, about what kind of organization this is. The Alliance is a working coalition run collectively by its founding members, not an entity Rain owns or controls, and members are expected to set its charter and mission together rather than adopt one Rain hands them. Rain's own account of why it exists is direct: by 2030, McKinsey projects between three trillion and five trillion dollars in global agentic commerce, and much of the infrastructure that volume will depend on, including how agents get authorized, how fraud gets caught, and how loyalty and rewards travel with an agent, is still being defined. The Alliance, in Rain's own words, was formed to bring the people building that infrastructure into the same conversation, before those decisions get made in isolation.

A coalition is not a standard, and early work is not a specification

Rain's own description of what happens next is specific, and it is worth quoting closely rather than rounding up. Early work is expected to include shared research and frameworks, testing emerging standards for agent identity and authorization, and advocacy on the regulatory questions agentic commerce raises. Read that sentence for what it actually commits the founding members to: research, frameworks, and testing standards that already exist or are emerging elsewhere. It does not say the Alliance has published an authorization standard. It does not say Visa and Mastercard have agreed on a common authorization protocol between themselves. It does not say the coalition has standardized how an agent payment gets authorized, checked or disputed.

That distinction is not pedantry. Moona Intelligence tracks a specific ladder for claims like this one, and conflating its rungs is exactly how a coalition announcement turns into an inflated claim of technical progress: an industry coalition forming is one rung. Shared research and frameworks is a second. Testing emerging standards is a third. A draft specification is a fourth. An adopted specification several parties actually implement is a fifth. An interoperable implementation two or more independent systems can verify against each other is a sixth. Production enforcement, where a real transaction is actually blocked or allowed based on that verification, is a seventh. What the 18 August announcement establishes is the first rung, with a stated intention to reach the second and third. Nothing in the public material, as of this record, shows the Alliance itself past that point.

What independent reporting adds, and what it does not

American Banker's coverage of the launch is useful precisely because it does not borrow Rain's own framing uncritically. Its reporting states plainly that several foundational elements needed to support the growth of global agentic commerce remain undefined, naming methods for authorizing agents to transact, systems for detecting fraud, and mechanisms for extending loyalty and rewards programs to agent based transactions as open questions the Alliance exists to work on, not ones it has closed. PYMNTS and Forkast's coverage of the same launch corroborates the founding member list and the governance framing without adding a claim of technical substance beyond it. Moona Intelligence treats that press coverage as one underlying development, not as several independent confirmations that something more concrete has shipped: a dozen outlets describing the same 18 August announcement is one piece of news, reported widely, not a dozen separate developments.

Coinflow, one of the 26 founding members, is described in material surrounding the launch as joining the Alliance to help define how AI agents authorize, settle and move money. Read that phrasing carefully: to help define is future tense and collaborative. It describes agent payment authorization as a problem the coalition intends to work on together, not one any member is claiming to have already solved. This record treats that framing as corroborating Coinflow's participation and its own account of the coalition's purpose, not as evidence that Coinflow, or any other member, has independently endorsed a specific authorization architecture.

Where Rain's own product already answers part of this, for one company's customers

Separate from the Alliance, Rain has spent the months before 18 August building a real product that speaks to part of this problem, and it deserves to be described precisely because the Alliance announcement leans on it without being the same thing. Rain released its Agent Control Layer in June 2026, embedded across Rain's APIs, giving businesses and developers programmatic control over how an AI agent spends using cards Rain issues. Through it, a documented set of dimensions can be configured before an agent is allowed to act: approved merchants and merchant category codes, a transaction amount, a spend frequency or interval, the number of active agent cards permitted, and a card expiry. Rain's own account of the mechanism is specific about where the check runs: these constraints are enforced at issuance and initiation, not applied retroactively, so by the time an agent attempts a transaction the rules are already in force rather than checked afterward. A second, program level layer of controls lets a business partner cap aggregate spend and the number of active cards across its entire user base, separate from what any one agent is permitted.

Rain's own CEO, in a separate interview published the day after the Alliance launch, described the underlying scoped card mechanism as supporting minimum and maximum balances alongside spending limits, letting a user set the scope of the authority an agent is delegated. That is real, specific, and documented by Rain about Rain's own product. It is also exactly the limit this record has to hold onto: nothing in Rain's public material, or in the Alliance's own announcement, states that any other founding member has adopted this architecture, that Visa or Mastercard authorize transactions against these same fields, or that the Alliance has agreed to a shared version of it. This is Rain's own implementation for Rain's own customers, not the Alliance's model, and this record does not credit the Alliance with owning what one of its members built before the Alliance existed.

Card controls and money movement controls are two different surfaces

Rain's own material, checked directly for this update, describes two separately configured control surfaces, and collapsing them into one would overstate what either actually covers. The first is the scoped virtual card, addressed above: a card Rain describes as locked to a specific merchant, amount and task, with merchant category codes, an approved merchant list, a transaction amount, a spend frequency, an expiry and program level caps on active cards and aggregate spend. The second is Rain's money movement suite, which sits outside the card product entirely: virtual accounts, onramps, offramps, and fiat and stablecoin payments to individuals and businesses. Rain's own material states the same category of parameters, an approved counterparty, an amount, a frequency and a timing window, applies to this second surface, configured before an agent is permitted to act, with a stated worked example of a business restricting an agent to approved vendors, on a defined schedule, for a defined amount. Both surfaces are documented as enforced before the fact rather than checked afterward. Neither is documented as sharing a single mechanism with the other: a card level allowlist and a payments level counterparty list are configured, and presumably enforced, separately, and this record does not assume a control set on one surface automatically applies to the other.

The scoped card mechanism itself is also documented as supporting more than one configuration, not a single fixed pattern. Rain's own worked example describes a card issued for a single booking, limited to approved airlines or hotels, capped at a set amount and restricted to a defined window, which is a single use, task specific card retired once that one purpose is served. Separately, Rain's material also describes real time issuance of cards created programmatically for repeated, scheduled use, and the money movement surface's own worked example, an agent paying approved vendors on a defined schedule for a defined amount, is a recurring budget rather than a single transaction. This record treats scoped cards as documented to support both single use and recurring configurations, depending on how a partner sets them up, and does not assume every scoped card in the product is single use merely because Rain's most quoted example is.

Rain names one customer specifically: Sponge, a Y Combinator backed company that issues agent usable virtual cards against a user's stablecoin balance. Sponge's own site corroborates the relationship from its side, describing its card as issued by Rain, a Visa principal member. That corroboration is real and this record credits it. It is also narrow, and should stay narrow rather than growing into more than it supports: Sponge's own material demonstrates that Rain issues virtual cards for a live customer. It does not demonstrate which Agent Control Layer parameters Sponge actually configures, whether Sponge uses the money movement surface described above at all, or that Sponge's integration exercises the scoped card mechanism's full documented range, merchant category codes, frequency limits, program caps, single use versus recurring configuration. This record does not infer the complete control architecture from a partner testimonial that, on its own terms, supports card issuance and nothing more specific than that.

Rain is explicit that changes to configured payment terms require explicit action by a human administrator, and that sentence is doing real work: it distinguishes configuration authority, which sits with a person, from transaction execution, which an agent carries out unattended inside whatever the person already configured. What that sentence does not establish is also worth stating plainly, because it is exactly the kind of gap this record's Authority Provenance standard exists to hold open rather than paper over. Rain's public material does not document who qualifies as an administrator, how that person authenticates, whether organizational or role based permissions govern who may administer a given program, whether an agent can itself request a configuration change that a human then approves, or whether a change to a policy reaches a card or a payment flow already issued under the old terms, as opposed to only governing what is issued after the change. Each of those is preserved here as undocumented, not assumed in either direction.

The Authority Provenance ledger, as it stands today

This is the part a coalition announcement never states explicitly, because it is not what a press release is for. Moona Intelligence separates it out deliberately, dimension by dimension, because collapsing them into a general claim that agent payments are getting safer is exactly the promotion this record is built to resist.

Authority grantor. Documented at the Rain product level only: Rain's material describes the user, or a business administering agents on behalf of its own users, as the party who configures an agent's scoped card. At the Alliance level, no material establishes a common definition of who is entitled to grant an agent payment authority across 26 different companies' own account and cardholder relationships. Each member's existing account relationship presumably continues to govern this on its own systems, and nothing in the 18 August material changes that or unifies it.

Mandate or basis. Undocumented, at both levels. The documented Rain mechanism establishes that a user or business configured a scoped card. It does not establish, and Rain's material does not claim to establish, that the person or entity doing the configuring held a legitimate basis, a corporate role, a contractual right, ownership of the funding account, to delegate that authority in the first place. The Alliance's own material does not address this question at all. Whether a downstream participant, a processor, a network, a merchant, can ever confirm that the human at the top of a delegation chain was actually entitled to grant it remains an open question this coalition has not yet taken up in public.

Delegated scope and explicit limits. Documented for Rain's own product, on two separate surfaces, and only as far as Rain's own material states. On scoped cards: approved merchants and merchant category codes, a transaction amount, a spend frequency or interval, a program wide aggregate cap, and an expiry, configured either as a single use card tied to one task or as a recurring configuration for repeated use. On money movement outside the card, virtual accounts, onramps, offramps and fiat and stablecoin payments, a separate control set applies the same category of dimensions, approved counterparty, amount, frequency and timing, before an agent may act. Rain's material does not describe controls over currency conversion terms, geography, or counterparty identity beyond an approved list, and this record does not infer them. Applying either list of dimensions to Visa, Mastercard, Fiserv or any other founding member's own systems would be attributing one company's product to an entire coalition, which is precisely what this record is built to avoid.

Authority envelope integrity. Undocumented. The relevant question is whether a configured limit on one path, a scoped card's amount cap, for instance, actually bounds every route to the same financial effect available to the agent, or whether a second card, a different payment rail, a separate credential, or several smaller transactions could reach a result the configured envelope was meant to prevent. No public material reviewed for this record describes Rain's controls this way, in either direction: nothing documents that program level caps, active card limits and money movement counterparty lists compose into a single governed envelope an agent cannot route around, and nothing demonstrates that they can be routed around either. This record does not manufacture a bypass concern the evidence does not support, and it does not credit envelope integrity as established merely because individual limits are each real and enforced on their own terms.

Inherited permissions and propagation across organizational boundaries. Undocumented at the Alliance level, and this is the dimension the whole announcement is actually about. A payment that starts as one human's delegation to one agent, using one company's scoped card, still has to cross a processor, a card network, an issuing bank and a merchant before it settles, and several of those parties had no part in the original delegation. Rain's own material describes controls enforced at issuance on Rain's own infrastructure. It does not describe what evidence of that original delegation, if any, travels with the transaction once it reaches a network or an issuer outside Rain's own systems. The Alliance's stated early work, testing emerging standards for agent identity and authorization, is aimed at this exact gap. It has not closed it yet.

Revocation and modification. Documented only as a Rain product capability, and only partially even there: an administrator can narrow, expire or presumably revoke a scoped card's parameters through Rain's own systems, consistent with the enforced at issuance design, and the same human administrator requirement is stated for money movement terms. What Rain's public material does not state is whether a modification reaches a card or a payment configuration already issued under the prior terms, or only governs what is issued after the change, and whether an agent can itself initiate a change request that routes to a human for approval, as distinct from a human acting unprompted. Whether a revoked or narrowed authority is recognized, and honored, by another Alliance member's own systems once a transaction has already left Rain's infrastructure is also not addressed anywhere in the public material. Common revocation semantics across the coalition remain proposed work, not built work.

Challenge authority. Undocumented at the Alliance level. Neither Rain's announcement nor any founding member's own statement specifies who, among an original human grantor, an issuer, a network, a merchant, a processor or a regulator, has standing to challenge a purportedly authorized agent transaction before or after it settles, in a case that spans more than one member's systems.

Recovery. Also undocumented as an Agent Authority specific mechanism at the Alliance level, and this distinction deserves to be stated carefully rather than assumed away. Card networks and issuers already operate fraud, dispute and chargeback machinery, and every founding member with a card or payments business already has some version of it. None of that existing machinery is described anywhere in the 18 August material as having been adapted to answer the specific question this record tracks: how an unauthorized or out of scope agent transaction gets attributed, disputed and reversed, as distinct from an ordinary disputed charge. Until the Alliance says otherwise, this record does not credit conventional chargeback rails with being an Agent Authority recovery architecture.

Provenance evidence quality. What exists, across the whole picture verified here, is evidence that an agent transacted using a credential a business configured, and in Rain's own product, evidence of what scope that credential carried. What does not yet exist, anywhere in this record's public material, is evidence that a specific human's mandate to delegate was itself legitimate, evidence that a delegation's scope and validity survive being checked by a party outside the system that issued it, or a documented way for a downstream participant, an issuer, a network, a merchant that never saw the original grant, to verify any of it. Identifying the agent and its immediate credential is a solved problem inside one company's product. Verifying the authority behind that credential once it leaves that company's systems is the open one, and it is the one the Alliance says it exists to work on.

A different room already exists, and it has not settled this either

The Alliance is not the only venue where this question is being worked. The FIDO Alliance announced, on 28 April 2026, an Agentic Authentication Technical Working Group and a parallel effort inside its existing Payments Technical Working Group to develop specifications for agent initiated commerce, drawing on initial contributions from Google's AP2, or Agent Payments Protocol, and from Mastercard's own Verifiable Intent framework, co-developed with Google. FIDO's Payments Technical Working Group, doing this specific work, is co-chaired by members from Mastercard and Visa. That detail is worth sitting with for a moment: the same two card networks that just joined Rain's coalition on 18 August already co-chair a separate technical standards effort, at a different organization, aimed at a closely related problem, and neither venue has yet produced a specification the other has adopted, let alone one the wider payments industry has implemented and tested for interoperability.

This record treats that as important context, not as evidence that the Agentic Payments Alliance and FIDO's work are the same thing, or that either has produced the finished answer. AP2 is Google's own protocol, published separately from both efforts, aimed at proving a chain of trust from a human's original intent through to a final payment. Verifiable Intent is Mastercard's own framework, built with Google. Neither is an Agentic Payments Alliance deliverable, and nothing in Rain's announcement claims otherwise. What the overlap actually shows is convergence of attention, several serious organizations independently deciding this question is urgent enough to work on, rather than convergence on one answer. Moona Intelligence has covered a version of this same convergence before, in a governed payments workflow AWS and Solv Labs described for proving a single transaction was authorized before it settled, and in an Internet-Draft before the IETF OAuth Working Group arguing that a grant of authority and evidence a specific action was authorized are different things. None of those efforts, and neither FIDO's working groups nor Rain's Alliance, has yet produced a specification the others have adopted.

Two verified architectures, one open question about where the human decision sits

Rain's own product is one answer to a question the rest of the payments industry is still arguing about, not the only one, and a second verified architecture sits right beside it for comparison. Moona Intelligence covered Binance's own Agent OS launch, on 20 August 2026, independently, against the same Authority Provenance standard applied here, and the two documented designs place the decisive human act at different points in the same lifecycle.

Rain's architecture, as this record has verified it, constitutes authority before execution. A human administrator configures a scoped card or a money movement flow, an approved merchant or counterparty, an amount, a frequency, an expiry, and the agent then transacts inside that envelope without a fresh human decision on each individual transaction, up to whatever the configured limits allow. Binance's own MCP Server documentation, verified independently in that record, describes the opposite placement for the same category of action: every order, cancellation and transfer inside an isolated subaccount is confirmed by the user before it executes, one action at a time, even though the subaccount itself is also a boundary configured in advance. Binance is separately reported, in an interview its own published technical documentation does not yet corroborate, to also intend an autonomous mode resembling Rain's; that intent is recorded in this desk's Binance coverage as a stated but not yet independently verified company plan, not as documented current behavior.

That is the same gap this record's Authority Provenance ledger keeps finding at the coalition level, restated in architectural terms. Rain can prove, on its own systems, that a transaction matched a configured envelope. It has not documented that a processor, a network, an issuer or a merchant outside Rain's own infrastructure can independently verify that fact, or that the human administrator who set the envelope held a legitimate basis to do so. Binance can prove that a person confirmed one specific action. Neither company's documentation, and nothing in the Alliance's own material, describes a shared way for a third party crossing either system to check either kind of proof. Convergence on that question, not on which architecture is preferable, is what would actually move this record.

What would actually change this record

A charter the founding members have jointly ratified would move the Alliance from stated intent to a documented governance structure. A named technical working group inside the Alliance, publishing a schema, a credential format or a trust model any two members can independently verify against, would move this from research and testing toward a draft specification. Evidence that a transaction's authorization evidence, in the sense this record has used throughout, actually survives being checked by a member that did not issue the original credential would be the first sign of interoperability rather than intent. None of that exists in public material as of this record. When it does, this record will be updated to reflect it, and the update will say plainly what changed.

The significance is the admission, not a solution

Twenty six competitors, including the two companies that clear most of the world's card payments, do not convene a coalition over a problem they consider solved. That is the actual weight of 18 August 2026: a formal, public acknowledgment from the infrastructure the payments industry actually runs on that agent payment authority becoming an interoperability problem, not merely a product feature any one of them can ship alone, is now taken seriously enough to warrant a shared table. Moona Intelligence has already read one company's attempt to evidence a single payment's authorization before it settles, Alipay's attempt to carry a user's authorization across several agents inside one ecosystem, and a vendor's attempt to bind an agent's authority to a specific human grantor. None of those is the same claim as this one. This is the first record in that set where the admission that the problem exists is coming from the organizations that would have to live with the answer, before any of them has proposed what it is.