> ## Content Index
> Fetch the complete content index at: https://transactionintelligence.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Authorised to do what?
- URL: https://transactionintelligence.net/authorised-to-do-what/
- Published: 2026-10-06T05:45:33.000Z
- Updated: 2026-10-06T05:45:32.000Z
- Description: Visa's rules make a cardholder responsible for an agent's purchase as if they initiated it. PSD2 asks whether they consented. A 2024 CJEU case on human proxies suggests what an issuer will have to prove, and the answer runs through the record of what the agent was told.
- Author: Matt Berryman
- Tags: Regulatory, Payments, Banking Technology

Stripe wrote to me on Friday evening to say its legal terms were changing and that I needed to do nothing. Keep the account open past 6 January 2027 and I have agreed. One of the changes is a new [clause 1.7](https://stripe.com/en-gb/legal/ssa?ref=transactionintelligence.net), which makes a merchant "solely responsible for each action initiated by or through the AI Agent" and declares those actions legally binding on it. Visa got there a year earlier from the other end of the transaction. Rule 4.1.24.10 of its [public rules](https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf?ref=transactionintelligence.net), last updated October 2025, makes a cardholder responsible for what an agentic payment provider does as part of an agentic transaction, "as if the Cardholder initiated the Transaction". That is the sentence I think every issuer's disputes team should have pinned above the desk. I found it while checking what the schemes have actually published about agent-initiated card payments, which turns out to be more than the coverage suggests and less than the pilots imply.

## Two rulebooks, one payment

Read that sentence next to PSD2 and something interesting happens. [Article 64](https://paymentslaw.eu/psd-2/art-64/?ref=transactionintelligence.net) says a payment is authorised only if the payer consented to it, and [Article 72(2)](https://paymentslaw.eu/psd-2/art-72/?ref=transactionintelligence.net) adds that a recorded use of the card is not necessarily sufficient to prove they did. [Article 73](https://paymentslaw.eu/psd-2/art-73/?ref=transactionintelligence.net) then puts the first refund of an unauthorised payment on you, the issuer, immediately and at the latest by the end of the business day after you learn of it, unless you have reasonable grounds to suspect fraud and tell your national authority so in writing. That first refund is not the final loss. [Article 74](https://paymentslaw.eu/psd-2/art-74/?ref=transactionintelligence.net) can put some of it back on a payer who acted fraudulently or with gross negligence, and [Article 92](https://paymentslaw.eu/psd-2/art-92/?ref=transactionintelligence.net) lets you pursue another payment service provider or intermediary to whom the liability is attributable. I'm writing about the EU text here. The UK regulations track it closely, but check your own.

None of this contradicts Visa. The rule allocates responsibility inside the scheme, and rule 1.1.1.3 gives applicable law precedence wherever the two collide. Stripe's clause does the same job from the merchant's side, and it leans on a US attribution statute, the Uniform Electronic Transactions Act, that has no UK or EU payments-law equivalent. What the comparison does is expose a question every pilot needs to answer. The scheme attributes responsibility for the payment to the customer. The statute asks whether they consented to it. Responsibility and consent are not the same test, and the evidence that satisfies one may not satisfy the other.

## What the agent was told

Last week I asked which an issuer would rather have first, an indicator that an agent is on the transaction or a record of what the customer authorised it to do, and the fraud and payments people who replied leaned towards the record. An indicator tells you what is acting. It does not tell you whether this merchant, this amount and this moment were inside the instruction your customer gave.

Both schemes now have a place for that instruction. Visa Intelligent Commerce captures a payment instruction with a decline threshold, an expiry and, optionally, a merchant, authenticated with a passkey when the customer gives it, and VisaNet checks later authorisations against it. Mastercard's Verifiable Intent, still a v0.1 draft, publishes explicit constraints: a list of permitted payees, a cumulative budget across purchases, individual line items and a recurrence rule. Stripe says the networks add information to the authorisation message for issuers, so something reaches you. What, and in which field, I have not found in anything either scheme has published, and Visa's rules oblige the agent provider to keep the consent record and hand it to the issuer on written request, which is a route to evidence rather than a promise of when you get it.

One reader, who advises airlines on distribution, showed me where an exact instruction breaks. The merchant taking the money is usually fixed at checkout, but the fare moves, ancillaries get added, and the carrier that issues the ticket is chosen later and can change if the first attempt fails, so an instruction naming a precise amount can be stale before the charge lands. His conclusion was still the record, because the indicator would have told you none of that either.

## In the form agreed

The part I'd put to your legal team rather than your fraud team is [Article 64(2)](https://paymentslaw.eu/psd-2/art-64/?ref=transactionintelligence.net). Consent is given "in the form agreed between the payer and the payment service provider", it can cover a series of payments, and Article 64(1) allows it to be given in advance. So an instruction to an agent can be your customer's consent to the payments that follow, provided that is the procedure you and the customer have agreed, the customer actually gave that consent, and the payment fell inside it. The scheme can supply procedures for your agreement to adopt. It cannot settle statutory consent, which lives in the agreement between you and your customer, subject to the law that applies to it.

Writing one in is the start of the job, not the end. In July 2024 the Court of Justice decided [Eurobank Bulgaria](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62022CJ0409&ref=transactionintelligence.net), a case about disputed transfers made by a human proxy using a copy of a purported notarised power of attorney, which the customer said was forged. The Court accepted that an agreed set of procedures letting a proxy act can itself be a payment instrument, and then held that the document's formal regularity did not prove the customer's consent to the disputed payments. The bank had to show that consent was given through the procedure it had agreed with the customer. That was PSD1 and a person, not an algorithm, so it is an analogue rather than a ruling on agents, but I can't see why the logic would change when the proxy is software. Recognising delegation in the contract does not relieve you of proving that this payment sat inside it.

Which brings the question back to the instruction record. [The EBA has already accepted](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2020%5F5133?ref=transactionintelligence.net), for a single card payment whose final amount is unknown, that the customer can authenticate a maximum, with fresh authentication or a decline if the charge comes in above it. That is an authentication precedent for one purchase, not approval of a standing mandate, and the expiry and the reuse are my additions rather than the regulator's. Even so, "up to this amount, at this payee, until this date" is the shape I'd start from, because it is the one closest to something a regulator has already looked at. "Whatever it costs, wherever it's cheapest, for the next month" is not.

## What I'd do before the pilots become products

Three things, in the order I'd do them. Read your cardholder terms for the procedure by which an instruction captured by an agent becomes your customer's consent, and if there isn't one, decide whether you want one. Decide which instruction shapes you will treat as consent, starting with a named payee, a ceiling and an expiry. Then ask your scheme, and whoever runs your ACS, one question in writing: when an agent pays, which of the instruction, the indicator and the verification result reaches me, and in which message.

The rulebook attributes responsibility to your customer. The statute asks whether they consented. Eurobank shows that a formally regular delegation does not settle that question; the bank still has to establish consent through the procedure it agreed. Before the pilots become products, I'd want to know that the evidence of that consent can reach the desk that has to refund.