Search for AI agent payment infrastructure and you will get a stack of vendor pages and protocol docs, and they are all answering the same question: how does an agent technically move money. That question has been solved. The one your finance lead will ask has not.

It goes like this. When the agent pays the wrong company on a Friday night, which regulated firm is holding the balance it spent, and who is legally obliged to put it back?

Nothing on the first page of that search answers it. Not because the pages are bad, but because they are scoped to the middle of a three layer stack and the answer lives at the bottom.

The three layers, and the one the SERP skips

Any agent payment system has to do three separate things.

The mandate layer establishes that the agent was allowed to do this. Identity first, then policy: which agent is acting, who owns it, what it may buy, from whom, up to what. Alchemy's framing of "autonomous within limits" is the right one, and it correctly puts identity before funding.

The rails layer moves the value. HTTP 402, stablecoins, tokenised cards, bank transfers.

The regulated account layer is where the balance actually sits, under some entity's permission, subject to some rulebook. This is the layer that determines what happens to your money if the provider fails, and it is almost entirely absent from the commercial pages ranking for this phrase.

Look at what a typical one covers. Crossmint's agentic payments page offers agent wallets, virtual cards derived from a real card, stablecoin onramps and programmatic guardrails including spending limits, merchant allowlists and human approval above a threshold. Every one of those is a real capability. None of them tells you which entity holds the float or under what licence.

Layer one: a signed mandate is not the same thing as consent

The authority layer has a serious standard now. Google's Agent Payments Protocol uses Mandates, tamper-proof cryptographically signed digital contracts issued as verifiable credentials. An Intent Mandate captures what you asked for. A Cart Mandate captures what you approved. The chain from intent to cart to payment produces a non-repudiable audit trail, and AP2 is deliberately payment agnostic, covering cards, stablecoins and real-time bank transfers alike.

That is genuinely good engineering. It is also not a legal conclusion, and the gap between those two things is where the money gets lost.

Under UK rules, a payment is authorised only where the payer consented to that transaction, or to a series of which it forms part, in the form and procedure agreed with its provider, and the limits a customer hands to an agent are not automatically the payer's legal consent. Whether a given delegation counts is fact specific and turns on the contract with the provider.

So a mandate is evidence. Excellent evidence, far better than a log line. But it is evidence about a question that a protocol cannot decide on its own, and any vendor implying otherwise is selling you a cryptographic signature as if it were a legal one.

Layer two: what the 402 flow actually settles

The rails are the most documented part of this and deserve to be. The pattern is an HTTP 402 Payment Required response: the client calls a tool, the server returns a challenge describing what to pay and where, the client pays and retries with a payment credential, the server verifies and returns the resource with a receipt. No pre-created service account, no pre-shared API key. Two protocols dominate. x402, created by Coinbase, carries challenges and credentials in dedicated headers and settles on chain in USDC, with a facilitator service so the server needs no blockchain connectivity of its own. MPP adds cards through Stripe alongside stablecoins, supports recurring and usage-based payments, and is backwards compatible with x402.

This is past the demo stage. AWS made AgentCore payments generally available in August 2026, with Coinbase and Stripe Privy wallets for microtransactions, orchestration across protocols, and configurable payment limits enforced at the infrastructure layer.

That last phrase is the one worth stealing. Limits enforced at the infrastructure layer, not in the agent's own prompt, is the difference between a control and a suggestion. A model can be talked out of an instruction. A ledger cannot.

But notice what a receipt proves. It proves settlement happened and can be verified independently. It does not prove the instruction that triggered it fell inside the authority you granted. Those are different failures with different remedies, and only the second one is the expensive kind.

Layer three: whose licence is the balance sitting under

Here is the question the vendor pages do not raise, phrased as plainly as it deserves. Money your agent spends sat somewhere first. Where, and who is allowed to hold it there?

In the UK the honest answers are: a bank, an electronic money institution, an authorised payment institution, or nobody in particular. The protections attached to each are not interchangeable, which is worth understanding before you fund an account rather than after. If you have not looked at this before, start with what an authorised payment institution is permitted to do and the difference between an EMI and a payment institution.

The licensing question also runs the other way, at the firm supplying the agent capability. Systems that simply store or pass on payment instrument details to merchants may need no payment authorisation at all, while systems that can initiate payments on behalf of payers, or that hold funds in an integrated wallet, may be performing a regulated financial service, and the open question is which party in the structure needs the licence: the platform provider, the operator, or another institution in the chain.

There is a version of this disclosure that a serious provider can give you in one sentence, so here is ours. EXFI is a trading name of EX Financial Solutions Ltd, company number 17105188, which is not itself authorised or regulated by the FCA and acts as a distributor of payment services provided by Gemba Finance Ltd, authorised and regulated by the FCA as a payment institution under FRN 804853. EXFI accounts are payment accounts, not bank accounts. They are not covered by the FSCS. Funds are safeguarded in segregated accounts under the Payment Services Regulations 2017. UK customers, business entities only.

That paragraph is not a boast. It is the format. Ask every vendor on that search results page for their version of it, and treat a badge on a homepage as a non-answer.

The word "agent" already means something specific in payments

A small point of vocabulary that causes real confusion, because the payments industry got to the word first.

A payment institution may provide payment services through agents, but only subject to prior registration of that agent with the FCA, and the principal accepts responsibility for the acts and omissions of the agent and must have systems and controls to oversee it. Distributors are a separate category with separate rules: an EMI may use them to distribute and redeem e-money, and they need no registration, but an EMI cannot provide payment services through a distributor.

None of that is about software. When a payments firm writes "our agent", it means a registered commercial intermediary carrying the principal's regulatory responsibility.

The practical consequence is that "agent" in a regulatory document and "agent" in a product announcement are unrelated concepts, and reading one as the other produces a comfortable but false impression that some registration already covers your autonomous system. It does not. Nobody has registered your agent with anyone.

Who pays when the agent gets it wrong

This is the part to settle before deployment, not after an incident.

The UK framework does most of the immediate work already. The duty to refund arises where a transaction was not authorised, and the burden of proving authentication sits with the provider, where the recorded use of a payment instrument is not in itself necessarily sufficient to show the payer authorised it. A payer has 13 months from the debit to raise it. Business payers get more contractual freedom than consumers do: a non-consumer payer and its provider may agree to disapply parts of the regime, though the refund duty for unauthorised transactions is not among the provisions that can be contracted away.

What the existing rules do not settle is the scope of a delegation exercised by software. Government agrees. HM Treasury published the Financial Services AI Adoption Plan and its Modernising Payment Services Regulation consultation on 14 July 2026, with Recommendation 10 proposing an agentic payments trust framework and a Know Your Agent standard, and question 15 asking whether the consent, authentication and liability provisions need updating; the consultation closes on 6 October 2026.

Read that as an open question, not a finding. The current rules have not stopped applying. But if you are picking infrastructure this quarter, you are picking it into a framework that is being actively rewritten, which is an argument for keeping the money layer conservative and the agent layer replaceable. For the narrower version of this question, see whether agent payments are safe yet.

The requirements checklist

Nine questions. Put them to any vendor before you fund anything.

  1. •Which legal entity holds the balance, and under what permission? Ask for the entity name, company number and the licence or registration number. A brand name is not an answer.
  2. •Is it a payment account or a bank account? These are different legal objects that look identical in an app.
  3. •Safeguarded or compensation covered? Establish which, and if it is safeguarding, which credit institution holds the segregated account.
  4. •Where is the mandate recorded, and for how long? You will need it 13 months later, not 13 days later.
  5. •Are limits enforced at the infrastructure layer or in the agent's context? Only the first survives a prompt injection.
  6. •What does the receipt actually prove? Settlement is not authorisation. Ask which artefact evidences the second.
  7. •Who is the payer of record? If the answer involves a wallet nobody has legally attributed to your company, stop.
  8. •How is authority revoked, and how quickly? Measure it in seconds, and test it before go-live.
  9. •What does the contract say about an instruction outside the mandate? Model error, ambiguous parameters and a manipulated agent are three different scenarios. Get all three named.

What to do while the rules are still moving

A defensible position today looks conservative on money and flexible on everything else.

Run agents against a separate funded balance rather than your main operating account, so the worst case is bounded by design and not by policy. Keep limits outside the model. Keep the mandate record. Keep the payer of record a legal entity you control and can evidence. Choose a rails layer you can swap, because x402 and MPP are eighteen months old and the standards fight is not over. If you are running several entities, put the funding account on infrastructure that already handles them, which is the ordinary case for a multi currency business account. And when you get to the authority layer, how the AP2 protocol structures an agent payment is the piece worth reading properly.

For our own position, stated the same way we would want a vendor to state theirs: EX FI provides multi currency payment accounts with dedicated IBANs and access to SWIFT, SEPA, FPS, BACS and CHAPS today, for business customers. MCP-native agent banking primitives, signed spending limits and stablecoin settlement are announced roadmap items. They are not live, and we are not going to describe them as though they were, because a company that overstates what is running is a company you cannot trust on where your money sits.

This article is general information about how agent payment infrastructure is structured and regulated. It is not legal or financial advice.

FAQ

Do I need to be FCA authorised to let an AI agent make payments for my business? Spending your own money on your own account is not providing payment services, so a company pointing an agent at its own funded balance is not thereby carrying on a regulated activity. The authorisation question bites on the firm supplying the payment capability, and it turns on whether that firm merely passes on instrument details or actually initiates payments and holds funds. If you are unsure which side of that line a vendor sits on, ask them which permission they rely on.

What is Know Your Agent? A proposed identity and verification workstream for autonomous software agents, raised as part of Recommendation 10 of HM Treasury's Financial Services AI Adoption Plan of 14 July 2026. It would supplement customer due diligence rather than replace it. No UK standard exists yet, so anyone marketing KYA compliance today is describing an intention.

Can an AI agent open a business payment account on its own? No. Onboarding requires a legal entity, KYC on real people and a named human who is accountable. The agent operates inside an account a business already holds, which is exactly why the payer of record question belongs on the checklist.

Is a stablecoin agent wallet the same as a payment account? No. A token balance held in a self-custodied or platform-custodied wallet is not a payment account held under a payment institution's permission, and the protections are not comparable. Establish which one you are actually being offered before you fund it.

Does an x402 receipt prove the payment was authorised? It proves settlement occurred and is independently verifiable, which is a different claim from proving the payer consented to that specific transaction. Under UK rules the burden of proving authentication sits with the provider, and recorded use of a payment instrument is not in itself necessarily sufficient.